Top Non-Technical Mistakes With Your Notification Service

This article discusses the common mistakes that engineers make when building their own notification service; Mistakes that are easy to resolve with a little help.

 Min read
October 20, 2022


When done incorrectly, product-to-user notifications are a source of pain to not only the end-users but also your team, who seeks valuable work vs. configuring emails and push notifications. Turning your notifications from something so unpleasant to the point of pride in your product is not very difficult.

This article discusses the common non-technical mistakes that product and engineering teams make with their notification service that will cause them headaches later. We also provide our recommendation for addressing these mistakes.

What do we mean by Notification Service?

By notification service or notification system, we mean code and integrations software developers build to send notifications from your product to your user. This article is not concerned with promotional or marketing notifications.

Now to the mistakes:

1. Feature Flags or Kill Switches

Someone says they have received 160+ emails from us since morning. Is everything ok?!

-- Shocked customer support staff to the engineering team

Trust me, it happens.

These scenarios require you to have a kill switch or feature flag for notifications:

Note that Amazon SES, Twilio, SendGrid, or most other services DO NOT have an "OFF" switch. In the scenarios above, there is no way to stop sending out notifications without doing something destructive like rotating API Keys.

NotificationAPI's toggles for turning individual notifications on/off on the fly

NotificaitonAPI comes out of the box with this feature. If you are building your notification service from scratch, we highly recommend LaunchDarkly, our favorite feature-flagging tool.

2. Default Notification Preferences

Not every notification and channel should be on by default. When users receive unnecessary and repeated notifications:

  • You damage your brand and your product's quality
  • You force users to go to their notification preferences and evaluate what notifications, if any, they should receive going forward
  • You risk getting complaint reports, leading to account closure or lower deliverability
NotificationAPI's no-code notification preferences

If you don't have notification preferences for users, build one (read our article) or consider using NotificationAPI, which comes out of the box with white-labeled notification preferences.

Then, you want to evaluate your default preferences. We have seen this work great: give your onboarding person administrative access so they can set the user's notification preferences during the onboarding session. Customers love that!

3. Analytics and Iteration

It is naïve to think the first iteration of your notifications will work great. To iterate, we need data.

The problem is: gathering data on product-to-user notifications is difficult. Many marketing notification systems are great at tracking open rates and click rates. Engineering tools, surprisingly, are not built with the same data-driven mindset. Amazon SES needs so much configuration. Twilio and SendGrid provide very general reports. Most push notification services don't have analytics. Also, these reports are separated in different services.

NotificationAPI Insights

Notification Insights is a recent addition to NotificationAPI which reports across all your notifications and channels, with new reports regularly added!

Here are a few pieces of information you need to gather and think about:

  1. What are we even sending to users? List all the notifications and channels.
  2. Which notifications are getting high engagement? Users love these. Add more value to them.
  3. Which notifications are causing users to click "unsubscribe" or "manage preferences"? You need to turn them off or rethink them.
  4. Which notifications are not engaged with? Toggle them off or rethink them.
  5. Which channels are notifications working better on? Default to using these channels for notifications.
  6. Which notification are we sending too much of?  Batch them.

Final Thoughts

Here is our one piece of advice:

Review all the annoying, unnecessary notifications you received today.

Understand why they were terrible.

Avoid their mistakes.

We think about notifications all day long, every day of every year. And we built NotificationAPI to give your product the notification system it deserves: simple, configurable, and user-centric.

Like the article? Spread the word