Each individual message that you send to a person travels through Customer.io, to a delivery provider, and ultimately to a person. Customer.io logs the status of each individual delivery and journey, so you know whether or not a person has received a message, opened it, and responded to it.
We also aggregate these statuses as metrics, so you know not only how well a message performed with an individual person, but how well it was received by your audience at large.
This page is designed to help you understand the various states your messages progress through, and how we display those states in different areas of Customer.io.
Status vs. Metric
A Message Status explains the state of an individual delivery (the instance of a message intended for an individual) or journey (the instance of a campaign that a person travels through). We track each delivery’s progress from when we first generate and try to send it, whether or not we’re successful, and how a person interacts with it.
For example, a message that is Queued is not counted in your Sent metrics, because it hasn’t been sent yet. As you look at message metrics, you should consider the time since you sent the message: have people had enough time to receive or open the message? This time is likely to change based on the type of message you sent: SMS and push notifications tend to see more immediate responses compared to emails, but also contain less information and maybe have a smaller, more confined scope.
Metrics aggregate message and journey statuses, providing information about the performance of your messages and campaigns—the percentage of people who opened a message or finished a campaign journey.
Metrics are generally based on the total number of delivered messages, but may require the delivery provider or audience to report back before we generate metrics. So, a message or delivery may have a status—like “drafted” or “sent”—but may not have generated metrics if a person hasn’t opened your message or clicked a tracked link yet.
Message statuses and metrics vary by message type
The type of message that you send determines both the statuses that Customer.io reports, and the metrics we gather. See statuses by message type to learn more about the states each message type may have.
For example, here’s an email with a Sent status. It has been Sent (its most recent interaction) and Opened, but it has not been clicked or driven a conversion:
All of these things are aggregated to form campaign metrics.
The Deliveries log shows you the status of your most recent deliveries.
When does Customer.io get the status of a message?
There are three different entities that report message statuses: Customer.io, your delivery provider, and the person you send messages to.
Whether or not you see a particular message status in Customer.io depends on both an event happening (i.e. a person opened a message), and a the responsible entity reporting that event to Customer.io.
So, beyond the message statuses that we generate before sending a message to a delivery provider, there may be a delay between the delivery provider or a person interacts with your message, and when we update the message status or relevant metrics in your dashboard.
This chart shows the different message statuses for an email, the parties responsible for reporting each message status, and the general flow of statuses.
Set up reporting webhooks
Each message status represents an event that you can send to an external source with Reporting Webhooks.
Reporting webhooks call an endpoint you provide with an HTTP POST whenever Customer.io reports a change to a message status that you want to subscribe to.
The webhook request includes a JSON payload with information about the event—information from Customer.io that you can feed directly into your customer relationship management (CRM) platform or another backend to track your audience’s progress along a messaging path.
Message status before send
When you send a message to a person, it travels from Customer.io to the delivery provider, and the delivery provider is responsible for making sure that it gets to your recipient.
A lot happens before a we send a message to a delivery provider. The following message states all occur within Customer.io before your message leaves Customer.io.
We’re processing a message and preparing to send it to the delivery provider. We’ve not attempted to send it yet, but we will soon.
We’ve generated a draft of your message, but you must manually send it. We will not send it automatically.
If you’re using the Queue Draft feature, your messages will sit in this state before you opt to send them. This gives you a chance to check your drafts before you send them or monitor the individuals you send messages to. See our Queue Draft documentation for more about this feature.
We’ve started trying to pass your message on to the delivery provider (e.g. Mailgun in the case of emails, for example, or APNs/FCM for push notifications).
In some cases, the attempted state can mean a retry-able failure.
This message did not leave Customer.io for the delivery provider. See this article to understand and diagnose why your message never left Customer.io.
In many cases, messages fail due to missing liquid variables, or a failure in liquid logic, resulting in an empty field or a misshapen message.
A message was not sent to the delivery provider because the intended recipient unsubscribed, reached their message limit, or was deleted.
If you have a message limit and you regularly see undeliverable messages, you may want to change your limit’s time window.
Retry undeliverable messages
If messages are marked undeliverable because a person reached their message limit, you can retry the message when a person is within their message limit or retry the message and ignore applicable message limits for recipients.
Message Statuses Reported by the Delivery Provider
When a message leaves Customer.io, we rely on delivery providers to tell us whether or not a message has made it to the customer
A message has successfully made it from Customer.io to the delivery provider. It is their responsibility to ensure that the message is delivered, and we’re waiting for further information to determine if the user interacted with it.
The user’s email address wasn’t valid. This could be a hard bounce (usually a permanent issue like a non-existent email address) or a soft bounce (a temporary issue like a full mail box). In the case of hard bounces for emails, subsequent messages to those addresses will be suppressed.
Customer.io has received confirmation from the delivery provider that a message was sent to the recipient’s email service provider (ESP).
Where we calculate campaign and message metrics for emails, we use Delivered as the basis for open, click, conversion, and unsubscribe calculations by default. If you do use a Custom SMTP server or otherwise don’t send Delivered metrics through your ESP, you can base metric calculations on the number of messages Sent instead. You can change the default denominator for metrics in your workspace settings. We’ll also infer delivered metrics from clicks and opens—because a message must have been delivered before someone opened or clicked it.
We attempt to track Delivered for push notifications, but it may be blocked by the device operating system. Use Opened or Sent metrics instead; Sent indicates that a delivery token is valid and is eligible to receive your message.
Status after successful delivery
After a person receives a message, we receive statuses from a few different places: your delivery provider, the recipient directly, or programmatically from you!
- The delivery provider reports statuses like bounces, spammed messages, and suppressed emails. The delivery provider is in a position to know when messages don’t make it to a person, or are otherwise rejected by a person, and they report that information back to Customer.io.
- In many cases, a person directly reports how they interact with a message. They open an email (which has a tracking pixel reporting directly to Customer.io that they opened a message); or they click a tracked link in a message. These statuses reflect interaction.
- In cases where the delivery provider or a person cannot report a status, you can report a status back to us. For example, you can report push notification opens back to us. Or if you use a custom subscription center, you can report unsubscribes to use through the API.
The user opened your message. We count an email as being opened when the recipient’s email client loads an invisible image (tracking pixel) or when the recipient clicks one of the links in the email. If a customer has images disabled in their email client and and they click a tracked link in the message, the “Opened Email” and the “Clicked Email” events will appear to have occurred at the same time.
As an increasing number of email clients provide privacy settings that let people block tracking pixels, open metrics may appear misleadingly low. You can disable email open tracking at the workspace level, so that you aren’t distracted by potentially unreliable open rates. In general, we recommend that you focus on Converted and Clicked metrics instead; these metrics reliably measure customer actions based on your messages.
Push notification opened status
The SDKs automatically track if a push notification is opened. If you don’t use our SDKs, you need to send us events to track push notification opens.
If link tracking is enabled for a message, the user clicked a link in the message. You can also do link tracking to see metrics for individual links that your audience clicks.
We do not track Clicked metrics or do link tracking for push notifications. When a person taps a push notification, the message is marked as Opened.
A person met your conversion goal and the goal was attributed to this message. In general, we attribute the conversion goal to the last message a person received before meeting conversion goal criteria. You can read more about how conversions work.
A person marked your email as Spam with their email service provider. All subsequent emails for them are marked “suppressed.”
A message is suppressed in the following cases:
- The email address you sent a message to was previously a hard bounce (an invalid address).
- The recipient person marked any previous email message as spam. In this case, all subsequent email messages after the person marked your email as Spam are suppressed.
When a message is marked as suppressed, the corresponding email address is automatically added to your email service provider’s (ESP) suppression list, preventing a person from receiving emails from you in the future (e.g. emails intended for these addresses are suppressed by the provider).
If Customer.io is your delivery provider, you can find your email suppression list in your workspace settings. If someone has been inadvertently added to this list, or requests emails from you after previously marking a message as spam, you can remove them from the suppression list manually.
If you manage deliveries through a Custom SMTP provider, you can go through them to find your suppression list.
Statuses by message type
Different message types produce different statuses. The table below lists the different states of each message type.