Building an email notification system often starts with an “and when this happens, we’ll send an email.” Before you know it, you discover this is more complicated than you initially thought. It’s not your core competency, and you can’t afford to divert engineering time toward email notifications right now. You’re starting to look at a slimmed-down version of what you really want.
Sending email notifications is the typical iceberg: It gets tricky very quickly, and there is a lot more under the water. Thankfully, with the right approach and tools, it can be relatively painless to quickly create a scalable email notification service.
While email notifications are indispensable to maintaining strong relationships with your customers, they frequently don’t receive the attention they deserve. Transactional email notifications specifically can be mission-critical to the successful use of your product, can be used to share vital data needed to complete a process, can improve your users’ productivity, or can push information to drive further engagement.
More than that — confirmation and reminder notifications are often some of the first interactions a new or prospective customer has with your product, and we all know first impressions last. They help build trust with your customers, strengthening engagement and increasing brand recognition.
But building out an email notification service is a more significant task than many first realize and can quickly grow in complexity as you deploy more functionality and expand your user base. Let’s unpack the five core components in more detail below.
You’ve identified the trigger event, and you know what information you want to share, but how do you create the email? You could integrate it into your codebase, but, of course, you quickly realize this will require ongoing dev effort every time the business wants a change. Optimizing a message, moving an image, or just correcting a small typo will need an engineer.
Instead, you can empower the product team by giving them control of content creation, reducing their reliance on your dev team at the same time.
Providing the ability to create templates through a visual, drag-and-drop user interface is arguably the most complex and time-consuming component in building an email notification service. Yet, it’s also the component from which you will receive the most long-term benefit.
With the use of a no-code visual user interface, empower your product team to create new notifications quickly, without worrying about the code
Ensure consistent messaging and branding across all your notifications
Increase the speed of creation through their reuse across your email notifications and other communication channels
Quickly allow your product team to conduct A/B testing, ensuring that your notifications are as effective as they can be
Ensure consistent design and rendering across the many different email clients without the need for extensive system testing of your code
You can think of the rules engine as your notification workflow, where it all comes together. Notifications should not be static — they require constant optimizations, including the content, the event trigger, the priority, and more. You could build this into your codebase, but is this the best option? Besides being complicated and time-consuming, it will bloat your codebase, and your dev team will become a constant bottleneck to changes.
A rules engine allows you to:
Easily map the event trigger to the right notification, selecting the correct template for message content across each channel (should you want to use more than email in the future)
Select the most appropriate channel and delivery priorities based on the information you are communicating, the urgency, and the action required from the recipient
Define and easily change or add channels, sending priorities and frequencies to the notifications
Trigger multiple notifications to multiple recipients from a single event and template while still adhering to each recipient’s preferences
A preference system is more than making sure you don’t inadvertently send a notification to someone who has unsubscribed. Your customers expect to maintain control over their data, so a preference system is not really optional.
It’s best practice to have the ability to:
Put customers in control of their notification preference, allowing them to specify what they want to be notified about, at what frequency, and over which channels
Ensure your notifications arrive at the right time to be useful without overwhelming end users
Always take your customers’ preferences into account, responsibly managing their contact info while adhering to the GDPR
Stay on the right side of the CAN-SPAM Act by providing and sticking to your customers’ opt-out requests
Differentiate between optional and required notifications, like password resets, where opt-out isn’t an option
Many of your email notifications will be critical to your business, so you need a reasonable level of assurance that your message got through. More than just having the infrastructure in place to send the required volume of email, you will need to do the following:
Ensure your emails don’t end up in the junk folder; this is often more about the strength of your domain than anything else. According to Seventh Sense, “for senders with the lowest email sender reputation scores, less than 1% of their email gets delivered!”
Build multiple retry mechanisms, with policies per channel, dealing with the real-world challenges that happen every day. This is where deliverability gets very tricky very quickly, with challenges like:
Losing connectivity to your email service provider
Dealing with rate limits
Managing network drops that inconveniently tend to happen right after you’ve sent, but before receiving confirmation
Cater for idempotency in your retries, with deduplication rules, to make sure your email notification service never sends the same notification twice, accidentally spamming your customers and damaging your domain rating.
Deal with delayed, asynchronous API responses from your service providers to determine delivery success.
Track notification delivery with status normalization so that you have a clear view of which notifications have been delivered, over which channels, and via which service provider.
Clearly understand the many stages of the delivery lifecycle — like queued, sent, delivered, opened, rejected, bounced, spam complaint — and what these mean to your email notification service.
Compare your notifications' deliverability across service providers, understanding if you need diversification to achieve better deliverability results (since you might be at the mercy of their shared IP pool depending on which service tier you’re on).
To understand the impact of your email notifications, track and measure behavior. Like we’ve seen above, with the other capabilities, there’s a lot more hidden under the surface here that you need to deal with.
For example, you can't just rely on open rates. There are numerous email platforms out there, and they don't all manage email the same way. To get a clear view of your customers’ interactions with your email notifications, you will require in-depth knowledge on how each of the various platforms reports on emails opened.
Trying to use click or link tracking to determine click-throughs' success can also have an undesired negative effect on your deliverability. To prevent this, you will need to understand how email providers deal with suspicious emails and work around their policies.
To truly understand the success of your various notifications and identify opportunities to optimize message content, priority, delivery time, and more, your product team will require detailed reporting and statistics on the interactions of your users. Now, you are starting to move into the realm of optimizing for user engagement, not merely deliverability.
As Andy Chung said, “Don’t reinvent the wheel. The internet is full of wheels… and most of them have APIs.” With the plethora of established service offerings in the market today, there is no need to build any of the functionality required for a successful email notification service into your core product’s code. With both niche services and end-to-end solutions available for all the capability you need, you could save a lot of time — and money — by using an existing service offering, letting others do the non-core lifting for you.
With Courier, you can start for free and scale on volume and capability as your needs evolve. You can test and diversify across multiple service providers for increased deliverability with no code changes. More importantly, though, you don’t need to sacrifice on your email notification service’s functionality. Courier is the fastest way to design and deliver notifications.
Build vs Buy: The “to be or not to be” of Tech
In her talk, Nallapeta described the “7 C’s” she considers when making this decision between build vs buy and shared her experience in implementing this process while developing Apartment List.
May 02, 2022
3 Types of User Communication APIs and When to Use Them
If you’re an engineer who’s been tasked with planning out your application’s communication strategy, this post will help you map out the landscape. You’ll come away understanding the three core types of user communication APIs and in which circumstances you should use them to create the best possible end-user experience.
January 06, 2022