Motivation

When done incorrectly, product-to-user notifications are a source of pain to not only the end-users but also your team, who seek 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:

• Faulty logic sending unwanted notifications to users

• Poorly thought new notifications causing many Unsubscribes or Complaint reports

• A terrible typo or sending the wrong message!

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

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 that 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.

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.

Study and take lessons from them.

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