Transactional or otherwise triggered email messages are likely some of the most important messages your organization sends to your clients or users. The definition of “triggered email” can vary, but for the purpose of this article, I’m going to refer to any type of message sent outside of a large-scale, “batch-and-blast” deployment, as triggered mail.
Examples of truly transactional messages include receipts, order confirmations, shipping notifications, password resets, email confirmation messages or a whole host of other transactional messages. However, in this “triggered message” group, there are also 1:1 email notifications like, “Someone liked your post,” or “Someone accepted your friend request.”
A lot of people believe triggered messages like these are incompatible with seed testing. This leaves senders scratching their heads trying to figure out how to determine if these critical messages are reaching their recipients’ inboxes or if they are landing in the spam folder. The process for testing inbox placement on triggered messages is a little different than seed testing daily or weekly newsletters, but it really isn’t a terribly difficult undertaking and the importance of these messages makes it worth the lift!
How triggered messages work
On any website or smartphone application there are actions users take that result in an email being sent. This can be when a user first signs up, when they change their password, when they make a purchase, when they change their plan or account type, or countless other scenarios. When a user takes an action like this, there is some code in the background of the website or application that does something like this:
- Generate Order Confirmation Message for user “Jane Doe”
- Populate message with Jane Doe’s first and last name, along with order details (items, total, confirmation number, etc.)
- Look up Jane Doe’s email address from our database
- Send message
Little triggers like this probably exist all over your website or application. It’s a pretty simple process.
You might already see the problem with sending a message like this to a list of seed addresses: This is a single message going to a single recipient, and they fire off all day. How would you attach a list of seed address to a triggered message like this? The short answer is, you don’t, but before we get there, let’s talk a bit about seed testing.
How seed testing works
A seedlist is nothing more than a list of email addresses. These are email addresses just like any others you have on your list with one important exception; seed addresses are programmatically monitored and scraped of all relevant information about the messages sent to them. Primarily, this is whether or not a message landed in the inbox or the spam folder but there is also a whole host of other data that can be gathered from seed testing. Seedlists can be as small as a few hundred addresses or as large as nearly 1,000 addresses. A seedlist typically includes dozens of individual mailboxes at tons of different mailbox providers. This lets you determine if your deliverability issue is primarily a Gmail problem, or a Yahoo problem, or so on.
When you’re seed testing a daily or weekly newsletter going to a mass audience, you simply add the list of seed addresses to the intended audience and send the mail like you always do. You’ll then be able to review the deliverability performance for that campaign. Easy enough.
How do I send a trigger message to a seedlist?
I’m glad you asked. Remember that bit of code we talked about earlier? The one generating the message, filling in the relevant data and sending it to the intended recipient? You’ll need to use that same functionality to “trigger” a send to each address on your seedlist. The basic idea is to tell your application all these “people” (in this case, not real people, rather the addresses on your seedlist), just ordered something or requested a confirmation code. This will result in a copy of the triggered message being sent to every address on the seedlist.
The cadence with which you should send these seed tests depends on the importance of the triggered message. Critically important messages should probably be tested daily, confirming things like password resets are getting to their users promptly. Less important ones, something like a cart abandonment email or a comment notification, perhaps test only a few times per week. The important thing is that with this process in place, you’ll know much quicker if/when an inboxing problem arises on these critically important mail streams.
There is one more important detail to mention: The addresses on your seedlist don’t have first or last names. They don’t have account IDs or usernames. They don’t actually have order details to populate. So what do you do about that? To answer that, I’ll respond with another question: Why do we do seed testing?
We do it in order to determine if our mail is landing in the spam folder or the inbox. The fact is, the name in the email, or the order details, or the confirmation code has no impact on the message’s inbox placement so they are actually irrelevant. You can either choose to leave these values blank or choose default values for all of these variables. It will not impact the accuracy of the test.
For a lot of people, testing triggered messages isn’t quite as straightforward as testing batch-and-blast campaigns. However, the deliverability and timeliness of these messages is often of greater importance than standard newsletter or marketing messages. I think this makes it well worth the extra effort.