- Developer Hub
- SparkPost API
- Free Tools for Email Teams and Developers
- Slack Channel
- User Guides & Migrations
- Submit a Ticket
- SparkPost Academy
- Email Deliverability Resources
- Email Explained
- White Papers & Guides
- Webinars & Videos
- SparkPost vs. SendGrid
- Customers Stories
- Contact Us
Email User Engagement Metrics
Over the past several weeks, we’ve taken a deep dive to learn how notifications and other emails travel from your application to your users’ inboxes. Along the way, we’ve examined various metrics product teams can use to assess their app’s email performance.
- In part 1, we looked at how product emails are generated and sent and discussed why message latency is a key metric at this stage.
- In part 2, we examined what happens when an ISP mailbox provider like Gmail or Outlook receives a message and dug into related metrics like bounces, deliverability, and inbox placement.
Today, we’re going to reach the final leg of our journey: how to measure user engagement with your notifications and other emails.
These engagement metrics—opens, clicks, spam complaints—directly measure your users’ interactions with your product emails. That direct insight is a profoundly important window into the overall health and growth trajectory of your application, so it’s essential that any product team sending emails understands what these metrics mean and how they work.
Once a message is delivered to the user’s inbox, the first thing they see is the sender, the subject line of the message, and often the first one or two lines of the message content. If the combination of those elements is appealing enough, your users will open the message to read it.
Like inbox placement, ISPs don’t directly share data about opens with us. Instead, we have to gather that data ourselves. The most common approach to gathering open data is to embed invisible tracking pixels in the message that the email client application will load while rendering the email for the user.
While a single tracking pixel is common, some services (including SparkPost) incorporate additional tracking pixels in the message body. This is done because some email clients will render images as a user scrolls to save bandwidth, allowing the system to determine whether the entire message was read based on how many tracking pixels loaded.
The important thing to keep in mind with open tracking is that not all clients load images by default, and not all users force the loading of images while looking at your messages. This means that open tracking, like inbox rate, should be used as a trending tool only, and not as an incontrovertible fact. If your open rate trend down, look first at the preceding metrics to determine if fewer messages are reaching your users. If delivery is unchanged and opens go down, you need to look at whether anything changed in the From address, subject line, or initial message content that made your messages less appealing to your users.
The final stage in the life of your message is the click. Your message was submitted, delivered, opened, and your user found something in the message interesting enough to bother clicking on a link you provided. Not all messages necessarily end in clicks (for example, one popular messaging service for alerting parents to school closures has a relatively low click rate, because all the information needed is in the message itself), but clicks are a key step for many outcomes.
Clicks are typically tracked by putting a redirect/proxy web server in front of the destination web site or deep link to an app. By using a specially formatted URL that embeds useful data regarding what message was sent to which user, so that you can later determine useful metrics regarding both your messages and your users. If you link to the same URL multiple times in a single message (common for your main site URL, which may appear in the header, body, and footer of a message), it’s a good practice to track each link individually, as this helps you identify where in the message people most often click.
Because click tracking involves proxies between the message and the actual destination URL, many senders do not implement it on their own out of concern for failed click tracking servers blocking the users’ ability to reach the destination URL. Not all messages need click tracking, and clicks are rarely the ultimate action you’re looking for from your users, so think twice before building out a click tracking system, and choose carefully if using a third party.
Not every recipient wants every message sent to them, even when they initially signed up to receive the messages. Users will change their minds, growing tired of repetitive messages, simply losing interest, or receiving messages they don’t remember signing up for. When they do, some will look for an unsubscribe link, but others will reach for the spam button in their email client of choice.
The spam button is a key tool for ISPs because it’s the best indicator they have of how users feel about the messages they are receiving. The more users click the spam button, the more likely an ISP will deliver all the sender’s future messages to the spam folder. This is why it is key that messages have clear and prominent unsubscribe links: you want it to be easier to unsubscribe than to click the spam button.
While the ISPs are relatively opaque regarding inbox placement, clicks, and opens, many of the major ISPs are much more transparent regarding when users report messages as spam, delivering this data to senders in the form of Feedback Loops (FBLs). An FBL message is sent to the sender every time a user clicks the spam button and provides useful information that helps senders do better in the future.
The first thing all senders need to do when dealing with FBL messages is unsubscribe the recipient who triggered the FBL message in the first place. ISPs do not respond positively to repeat clicks of the spam button across multiple sends, and the user had made it clear they are not interested in your messages. It can pay to be granular when unsubscribing: a user who clicks the spam button when receiving your newsletter will likely still want a purchase receipt.
The next thing you will want to do is look at the trends with regards to FBL complaints. If you see a sudden spike in FBL complaints, you need to quickly look at your sending: what changed that has caused your user base to suddenly consider what you’re sending to be spam? Did you use a new template? A new subject line? A new type of mailing they didn’t receive before? Whatever it needs to be identified and removed until it can be re-evaluated.
Our Journey’s End—And Beginning
By now, you’ve seen that the journey of a notification or other email involves a lot more than simply pressing the send button. But you’re also armed with the knowledge you need to ensure your message actually arrives (and how to measure its performance).
As a product team, email is an essential part of your user engagement toolkit, helping achieve your goals of fast growth and low churn. And now you have the data to show it.
Want to learn more? SparkPost’s email experts have created some great downloadable guides to help you make the most of email in your app. I recommend:
- The Product Manager’s Guide to Email. Practical advice about how to get started with email notifications, alerts, transactional messages, and other product emails.
- The Growth Marketer’s Guide to Email Metrics. A concise overview for both growth marketers and product teams.
I hope this walk through the lifecycle of a product email has been helpful. Any questions or comments? Let us know on Twitter. Our team would love to hear from you!
—MikeSparkPost © 2018 All Rights Reserved