1811 Blog RealtimeData Header

The importance of real-time data for transactional email

One common perception of email messaging is that it mostly consists of marketing campaigns — sending personalized emails to a large group of people at once, and sending a consistent message. However, in reality, the majority of all email sent by brands consists of transactional messages, or messages sent in response to a customer interaction with a company. Although there are many types of transactional emails, a few examples include:

  • Password Resets
  • Payment Reminders
  • Purchase Receipts

Among many others. And it’s no surprise that these messages make up the majority — open rates for these messages are over twice as high, and these emails are clicked six times more than typical marketing messages.

Another difference in these messages is how they’re created and sent. Marketing campaigns are usually human-driven, with a campaign manager composing the email message and sending it at a predetermined time in order to maximize engagement. In contrast, transactional messages are largely systems-driven, with back-end systems communicating with each other programmatically to determine when to send emails. This is commonly done through something called an “API.”

What is an API?

The way that applications communicate with each other is typically through APIs, which stands for Application Programming Interfaces. APIs are the programmatic equivalent to the user interface — consider how many softwares you use that have user-interface components for human-user experiences, with beautiful graphics that are easy for a person to use through a web browser. APIs often accept and send the same information, but only transmit the necessary data for the software to understand what it needs to do.

As an example, let’s consider one of MessageGears’ recent features, our Enhanced Analytics Suite. The following is our user-interface showing deliverability and engagement analytics over time:

 

These charts are actually just the visualization of a series of simple API calls, seen here:

To request the information, the user interface makes an API call to the database:

The first API call is a request for the data from the database:

GET https://api.messagegears.net/analytics/job/{job_id}

This asks the database “Can you get me analytics for this specific job?” The data layer returns with the following information:

"windowStart": "2018-01-10 11:00:00.000",
"windowEnd": "2018-01-10 11:14:59.000",
"emailDomain": "gmail.com",
"deliveries": 1579,
"totalClicks": 2,
"totalOpens": 18,
"totalUnsubscribes": 0,
"totalBounces": 27,
"totalHardBounces": 0,
"totalSoftBounces": 27,
"suppressedBounces": 0,
"spamRelatedSoftBounces": 0,
"renderErrors": 0,
"totalSpamComplaints": 0,
},
{
"windowStart": "2018-01-10 11:15:00.000",
"windowEnd": "2018-01-10 11:29:59.000",
"emailDomain": "gmail.com",
"deliveries": 3631,
"totalClicks": 9,
"totalOpens": 86,
"totalUnsubscribes": 0,
"totalBounces": 45,
"totalHardBounces": 0,
"totalSoftBounces": 45,
"suppressedBounces": 0,
"spamRelatedSoftBounces": 0,
"renderErrors": 0,
"totalSpamComplaints": 0,
}

Which is just a text representation of the data in the chart. And, although this is just a snippet of the return (the full API payload would contain every data point in the chart), it’s the same thing we are viewing in the user interface! APIs are just a simple way for servers to exchange data, and you may be using them more than you realize: getting directions from a map service, logging in to your bank account, and even sending transactional emails are often powered by APIs.

Why does real-time data matter for API-driven emails?

As I mentioned before, nearly all ESPs offer API services, primarily to send transactional emails. What sets MessageGears apart is our ability to offer an API solution that also allows you access to your interaction data in real time. To give an example of how valuable this is, let’s take a common transactional email scenario: the abandoned cart.

Why do bad experiences happen? Because the data that these back-end systems are working with is disjointed, with payment information and email systems working in disconnected areas and databases. We’ve already touched on the value of keeping your data together, but this is an example where a core feature of MessageGears could easily help prevent this negative interaction. Our Real Time Event Feed delivers events to your database the minute they happen, allowing you to seamlessly join email and payment data together. Now, let’s take a look at how the negative interaction might look with a connected data environment:

  • 9:40 AM, I go to the ticket page and subsequently navigate away
  • 9:45 AM, return and purchase tickets
  • 9:47 AM, purchase confirmation sent to me
  • 9:47 AM, purchase confirmation email data is sent and stored in database, with the fact that I opened and clicked on the confirmation
  • 9:50 AM, scheduled API call is triggered to send me abandoned cart email, but first checks to see if I have purchased the product or been sent a confirmation email today
    • Seeing that I have already interacted with the confirmation email, the API does not make the call to send the email, preventing a negative brand interaction

As we can see in this example, automated emails can be a powerful reminder to a consumer to take action, but email automation can only be as good as the data that the system is working with. And, no matter how organized and clean your customer data is, none of that is going to matter if it’s out of date by the time you’re using it for segmentation.

That’s why having real-time access to your data matters so much if you want to avoid delivering negative and embarrassing experiences to your customers. These API calls can be your best friend, but keeping your data in house is the only way to ensure they’re both accurate and timely when you want to make transactional email segmentation work for your business.

Nick Ziech-Lopez

Nick is the Product Owner of the Cloud Infrastructure team at MessageGears. He applies his background in engineering and data analytics to organizing his product backlog, understanding user experience, and obsessing over the Chicago Cubs.

By continuing to use this website you are giving consent to cookies being used. 

For information on how we are using cookies, visit our Privacy and Cookie Policy.

This website uses cookies.