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.
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.
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
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.
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.
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.
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.
Retry undeliverable messages
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 your 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 do not track Delivered for push notifications. You can self-report Open metrics or track Clicks—both of which indicate that your messages were Delivered. You can track Sent metrics as well; Sent indicates that a delivery token is valid and is eligible to receive your message, but we cannot know if a person’s device is online or that they’ve received your message.
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.
Customer.io cannot track
opened events for push notification unless:
- You report
openedmetrics to us using the API
- The recipient taps a tracked link in your notification. In this case,
clickedmetrics occur at the same time.
If link tracking is enabled for a message, the user clicked a link in the message. We also track clicks on individual links.
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.
Different message types produce different statuses. The table below lists the different states of each message type.
|Customer.io Push||check_circle||highlight_off||check_circle||check_circle||check_circle||check_circle||check_circle *||check_circle||check_circle||highlight_off||highlight_off||highlight_off|
|Urban Airship Push||highlight_off||highlight_off||highlight_off||highlight_off||highlight_off||highlight_off||highlight_off||check_circle||highlight_off||highlight_off||highlight_off||highlight_off|
* to track push notification opens, you need to send us an event.