Troubleshooting Campaigns

This article provides various tips to help troubleshoot campaigns.

# In this article

# Why didn't a user receive a message from this campaign?

When sending a campaign to a list of users, there are various reasons that individual users on the list may not receive the message.

# Suppression list in campaign

Was the user included on a suppression list used for your campaign? If a user is included on a send list and a suppression list, they won't receive any type of communication associated with that campaign.

# Unsubscribed

Is the user unsubscribed from the channel, unsubscribed from an opt-out message type, or not subscribed to an opt-in message type? In any case, they won't receive the campaign.

# Send skips

Iterable logs send skip events on each user's profile page in the Event History tab. When a campaign is skipped for a user, the send skip event includes a field called reason that explains why the send was skipped. Possible reasons for a send skip include an invalid reply-to email address, a mismatch between a user's locale and the campaign's content, errors in Handlebars code, or your project's Frequency Management settings.

For a list of potential send skip reasons, see Reasons for Send Skip Events.

# Email bounces

Two types of email bounces can occur during a campaign. A hard bounce generally means the email is invalid or has a typo. A soft bounce generally means that an email was rejected because a mailbox is full, a SPAM filter was encountered, etc. Bounce events are logged to users' event histories with data that highlights why the email was bounced. This data can also be exported via CSV in any Campaign Analytics page.

For more information, see Email Bounces.

# SMS bounces

SMS bounces occur when a phone number is invalid, unreachable, or has opted out of receiving SMS messages. Iterable does not automatically unsubscribe users who bounce from SMS messages. Instead, Iterable logs the bounce event to the user's profile and allows you to manage the user's subscription status as needed.

For more information, see SMS Bounces.

# ESP suppression

Email service providers (ESPs) often maintain their own suppression lists to help protect sender reputation. Each ESP has its own rules for managing suppression lists. Common reasons include multiple bounces, spam complaints, or unsubscribes.

In Iterable, these events are related to ESP suppression:

• Unsubscribe with an unsubSource set to ESP
• Bounce with a status of recipientState set to Suppressed
• SendSkip with a reason of SuppressedByMessageService

To learn about suppression lists maintained by ESPs, see their documentation:

• Twilio SendGrid
• Mailgun
• SparkPost

# Resubscribing users on an ESP suppression list

Sometimes a user on an ESP suppression list wants to receive your emails again.

Resubscribing a user in Iterable does not remove them from the ESP suppression list. If you re-subscribe the user in Iterable but do not remove them from the ESP suppression list, the ESP bounces the message and Iterable categorizes the bounce with the recipientState of Suppressed.

For a user to receive your emails again, you need to first remove the user from the ESP suppression list, and then resubscribe them in Iterable as needed.

The process for removing a user from a suppression list varies:

• ESP managed by Iterable

  If you're using an ESP managed by Iterable (such as Amazon SES shared pool), you can't access or manage suppression lists directly. Instead, contact Iterable Support to request that a user be removed from the suppression list.

• Your own ESP account

  If you're using your own ESP account, you may be able to remove the user from the suppression list directly. Contact your ESP for more information.

• SMS suppression lists

  Generally, users can resubscribe to SMS by replying with an opt-in keyword. To learn more about how users can resubscribe to SMS, read SMS Unsubscribes and Resubscribes.

# Journey configuration

If you're using a journey to trigger an email send, make sure to check your journey's advanced options, as lifetime and simultaneous entrance limits may be in place that will prevent a user from entering into a journey. These two settings will check to see if a user has entered a journey anytime previously or if they are currently in a journey, which may prevent the user from processing as expected.

# Why is my campaign not sending?

# Data feeds

If you see a campaign that's stuck in the sending stage, check in your notification center (accessible by clicking the bell logo in the upper right-hand corner) to see if your data feeds are throwing errors. If so, contact your development team and Iterable's support team to better understand what's causing these error messages.

# DNS configuration (email channel setup)

If you and your team aren't receiving emails or proofs, make sure your DNS is set up correctly.

If your team is using Amazon SES, you can find DNS settings in Iterable on the Settings > DNS Setup page, and check that all records are verified.

If you use another ESP to send email, check your Iterable project's notification center for ESP-related errors. If you don't see any, check your ESP's configuration, or contact support.

# Limitations within your project

Is your campaign using experiments or throttling? Some teams use experiments or rate limiting to gain insight into the types of emails that work better than others and maintain stabilization for a web infrastructure.

If you're using an experiment, make sure that the experiment configurations are correct, and see which factors (i.e. time zones, send time, etc.) might contribute to the campaign not finishing yet.

If you're using rate limiting, double-check the rate limits within your channels settings, and also check to see which other active campaigns or journeys might cause you to hit the rate limit.

# Is the triggered campaign in a running state?

In order for a triggered campaign to send a message, it must be in the running state. To put a triggered campaign in the running state, activate it.

Journey campaigns automatically transition from ready to running when the first users arrive at their associated journey tiles. By contrast, triggered campaigns do not automatically transition from ready to running when a triggering API call is made.

# I updated my campaign, but some users still get the old one, why?

One of the most common reasons users might receive an old version of a campaign is that the campaign is part of an experiment that has unchanged variants associated with it. If some users are getting versions of your campaign that don't reflect recent updates:

• Check if the campaign has an active experiment. Experiments can override standard template updates, causing content from the previous version to be sent.

• If a campaign is associated with an experiment, review each variant to ensure that the template and its content are up to date.

• Cross-check current templates with the previous version to confirm that all updates have been applied for all variants.

• If possible, send test emails for each variant to confirm that the correct content is being delivered.

# Get support

If you're still not sure what is causing unexpected results with your campaign, contact Support.