This article provides various tips to help troubleshoot campaigns.
Why didn't a user receive an email 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 email.
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.
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.
Iterable is configured to log send skip events to users' event histories. In
the event a message is skipped for a user, the send skip event added to their
event history will include a field called
reason that highlights why the
email was skipped. Reasons for a send skip include a user receiving
too many marketing emails within an 18-hour window, locale mismatches, and others.
For more information about email send skip events and their meanings, read Send Skips.
Two types of 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 Bounce Definitions, Reporting, and Segmentation.
Dedicated IP services (such as SparkPost and SendGrid) contain their own suppression lists that capture users prior to sending a message, which can prevent messages from being sent. If a message is skipped for this reason, a skip event with the reason "Suppressed" is added to a user's event history. If this is happening, and you manage your ESP integration, you can access this information through their respective portal. If Iterable is managing your ESP integration, please reach out to your customer success manager for further information.
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?
If you see an email campaign that's stuck in the sending stage, check is 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.
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 your 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.
If you're still not sure what is causing a halt in sending, contact support.