DEV Community: anwesa-courier

How to Optimize Your Notification Logic with Automations

anwesa-courier — Tue, 01 Nov 2022 16:39:59 +0000

Notifications are an essential building block of every modern application and are now a core part of the user experience. They let you interact with your users by, for example, alerting them to potential risks, informing them about new product features, or simply engaging them through friendly check-in messages. Care must be taken, however — from the user’s viewpoint, the line between being engaged by relevant, timely notifications and feeling harassed can be thin. That’s why it’s so crucial to customize your notification experience to your users’ individual needs.

Using automation tools, developers can implement the kind of thoughtful, tailored notification experience that your users want. In this post, you will learn the different ways in which low-code and no-code automation tools help you build a better notification experience, while taking the burden of implementing the complex logic off your engineers’ shoulders.

Customization through automation

Automated functionalities like audience filters, complex workflows, and channel routing help you craft notification experiences that your users will happily engage in. Historically, these features come at a cost — the more customizability you want to include in your notification experience, the more resources are required to implement and maintain those features in your code base.

As a product manager, you need to think about how you can enable your developers to set up a notification logic that provides your users with a bespoke and smooth notification experience — without having to significantly rework your code base to support every customization you’ll potentially require. To achieve this, integrating existing tools with robust automation is key.

The first step towards automated customization is to understand what your users want and need. To that end, it’s useful to analyze how your users perceive the messages you send them — both through data analytics and by asking your users directly. You can then use that knowledge to send them helpful tips at the right time, as opposed to just sending out blanket notifications.

Once you have established your requirements, you need to choose and implement the right tools. Automation tools come with dynamic configuration capabilities that let you tailor your notification experience to the individual needs of different users. By integrating finer-grained customization into your notification logic, you can ensure the relevance of your notifications to your customers. Here are a few examples of a customized notification experience:

Targeted announcements: Rather than sending out feature announcements indiscriminately, they only arrive in the inboxes of customers whose user profile signals that they might have an interest — and who are not already using said feature.
Multi-channel notifications: Critical alerts should reach the right person at the right time — with multi-channel notifications, the notification logic picks the most suitable channel and sending time to ensure that users see the message and can react accordingly
Tailored content: To avoid spamming users with content they have no interest in, organizations can tailor the subject matter, channel, and timing of their digests so that the people who receive them will actually want to engage with them.

Strategies for automation

To make sure that your users get the best notification experience possible, your developers should employ multiple customization strategies in a way that will result in a much more personal feel. Let’s have a closer look at the three core strategies behind user notification customization:

Audience

Many notification systems use lists to organize their user data. Lists allow you to put user profiles into cohorts, according to different criteria — for instance, their profession or their place of residence. You can then use these lists to send out notifications that are targeted towards a specific group and thus feel more relevant than a one-for-all message. But do you know what’s even better than lists? Audiences!

With audiences, you can define user cohorts dynamically based on a set of criteria. Rather than working with static lists of users, you can quickly filter your users’ profiles to assemble an audience. For instance, you’d only want to send out notifications about a holiday-related sale to people located somewhere where that particular holiday is celebrated. Since your users’ location data is subject to change, it makes sense to use a dynamic audience filter rather than a static list.

Another useful basis for filtering is usage data: Let's say you want to distribute instructions on how to set up video calls faster. Getting this information in your inbox may seem like a godsend to those users who have been using a time-consuming call setup process up until now. On the other hand, it's useless for those who either already use your feature or haven't shown any interest in video calls in the past.

Audience filters are a prime example of how user data, when collected and stored in a safe and GDPR-compliant manner, can be used to improve your users’ lives by offering them a more tailored and meaningful notification experience.

Multichannel routing

When and where are two factors that contribute immensely to how a user perceives the notification experience. As we’ve highlighted throughout this series, receiving a message at the wrong time or through the wrong channel can create a lot of frustration for users. Choosing the right channel and time, on the other hand, can go a long way towards providing a satisfying notification experience that integrates seamlessly into your users’ lives.

Preference management with high customizability is extremely important, as it gives your users a sense of control over how and when they are notified. Additionally, your organization may apply its learnings about which channels work best under which circumstances towards building a complex routing system.

With multi-channel routing, you can specify a ranking order for notification channels. For example, you can show a notification in the browser first, and if the user isn’t online, or has disabled in-browser notifications, you can send them a push notification to their phone.

Complex workflows

Notifications should rarely be statically defined. Rather, you should identify where your users are in their product journey, and send them messages that support, help and encourage them. Workflows help you respond to the different paths a user’s journey with your product might take.

As an example, let’s take someone signing up as a new user to your service. You’ll probably want to send them a friendly welcome message through their preferred notification channel. Then, if your new sign-up doesn’t interact with your application within a certain time-span, you might want to opt for a gentle reminder by sending them a push notification or Slack message that details some first actions they could take. Finally, you could reach out to them via email (perhaps after a week or so of inactivity) and suggest that they schedule an appointment with a team member to address the issues that are keeping them from using your product. This gentle escalation encourages your new user to engage without bombarding them with alerts.

Thanks to triggers and other notification logic, you can build complex workflows that allow you to match the different experiences your users might have with your product. Such complex workflows are an example of how automation can actually provide a more personalized feel than mainly static notification procedures that were implemented manually.

When does it make sense to send notifications manually?

Automation should be at the core of your notification functionality. As the number of users grows, it becomes much harder to manually implement the notification logic required to cultivate a steady and happy user base.

Nevertheless, there are cases when it makes sense to send notifications without the help of an automation tool. You primarily need manual notifications for one-time events — such as device login notifications, password resets, product updates, and company announcements.

Notably, such notifications are relatively independent of your users’ actual product journey, as they are determined by what your organization needs to communicate to its users regardless of their notification preferences. For example, a user must be made aware of a potential data leak irrespective of their notification preferences. However, this type of notification should be few and far between. The focus of notifications should always remain the user’s experience with the product — and everything related to that can actually be automated.

To automate or not to automate?

We now have a strong case for automating your notification logic. Automation benefits your users by giving them a more customized and satisfying experience. It also benefits your developers, who can go back to focusing on your product’s core features, knowing that the notification logic is taken care of.

Omnichannel Analytics: the Key to Building Better Notification Experiences

anwesa-courier — Mon, 24 Oct 2022 15:54:07 +0000

Web analytics are a standard for online businesses, and product managers rely heavily on web analytics data when making product decisions. Stats like website traffic, conversions, in-app events, or unique users are frequently used as indicators of business health, because they help identify if the product is moving in the right direction or not.

With notifications, however, analytics are a different story. While the notification experience tends to be one of the key parts of product functionality, notification analytics are rarely available — and even when they are, it’s usually not so straightforward to get relevant insights out of the data. But without notification analytics, most companies are “flying blind” on their notification experience and don’t know how to improve it over time.

In this article, we talk about omnichannel analytics, why analytics are hard for notifications, and what we believe is needed to empower PMs. We’ll also share some specific tips on making the best of analytics data to design a more informed notification experience for your users.

What is omnichannel analytics?

Single data points on their own are not very informative, but in aggregate, they can tell a powerful story. Analytics is the art of assembling raw data from your product in a meaningful way. For instance, you could aggregate event data collected in an app, and infer from it which of the app’s features are most popular among your users. You can then use those insights to propel your product further by expanding the features that your users like, and retiring those they don’t. In short, analytics helps you forecast and shape the future by understanding the past and present.

These days, most businesses communicate with their customers through multiple channels: email, push notifications, SMS, and messages on social media complement more traditional means of communication like phone calls and letters. With that many options for reaching out to your customers, it’s insufficient to look at only one channel if you want to gain insights about how a specific communication strategy is working.

If you use a multi-channel strategy to communicate with your customers, it’s typically not helpful to look at those channels in isolation. Your customers might ignore your newsletters in their email inbox, but perhaps that’s because they have already seen and liked your announcements on a social media platform? So the most sensible way of doing analytics is to group messages by content, rather than by channel. So in omnichannel analytics, you look at your users’ interactions with your product holistically, across channels.

Analytics for notifications

Notification data means specifically how your users interact with your notifications. Do they click on an email as soon as they receive it? Do they swipe your push notifications away from their home screens? By doing analytics on notification data, you can understand which communication strategies work well, and which don’t.

The notification experience that your users have with your product can have a huge influence on whether or not they will continue to use it. Sending too many notifications through unsuitable channels or at the wrong time can cause such a bad experience for users that they start looking for better alternatives. A good experience, on the other hand, will go a long way towards a happy and sustained user base.

A central metric in notification analytics is the open-rate: it quantifies how many users opened a notification within a certain time span of sending it. A low open-rate means that you’ll have to think about changing your strategy — perhaps by sending fewer notifications, using different channels, or updating your content. As outlined earlier, an analytics strategy that takes multiple channels into account can deliver more insights. But before we talk about that, let’s quickly have a look at the specifics of notification data.

The difficulties of obtaining notification data

Data is the basis for all analytics — but it can be hard to get our hands on the kind of data we need to perform analytics on notifications. Apple’s iOS, for example, doesn't allow developers to precisely track impressions of push notifications on their users’ devices. With SMS messages, there is no analytics at all: you can know what messages you sent, but you don’t have any guarantee that users received them.

What we really need for PM empowerment: omnichannel analytics

To get a holistic picture of their customers’ notification experience, PMs need to know how different notifications fare across channels.

This is especially true given that the future will bring more notification preferences and flexibility for each user. As everyone’s notification experience becomes more personal, PMs will need to move to analytics that are grouped by notification content, rather than by channel. For example, all notifications about new mentions in a document app should be presented together in an analytics dashboard, regardless of whether the notifications were sent via email, Slack, or mobile push depending on each user’s preferences. But in order to enable omnichannel analytics for notifications, PMs have to overcome a few hurdles.

For channels where notification data is hard to obtain, developers can use reliable proxy data points, which help them approximate the data they’re really looking for. Read on to learn more.

How to get omnichannel analytics in your application

To be able to get omnichannel analytics, you will need to have the right data in place and be able to pull reports in the right format. Here are the steps that we recommend following to get there.

Implement analytics for each channel — as much as possible

Of course, the first step is to collect whatever data you can reasonably collect around notification usage, while respecting relevant privacy regulations and creating as little inconvenience to the user as possible. For example, when sending emails via a third-party email platform like SendGrid or AWS SES, the following are a few of the data points that you should consider collecting:

For each email notification sent: recipient, date, subject, attachments
Open and click metrics
Statistics on unsubscribes
Statistics on complaints

Note that not all of this data will be available from every platform, and different platforms might use different terms to describe the same metrics.

For some channels, it will not be possible to collect direct data for notification interactions. In such cases, you will need to come up with proxy data points: that is, data that may not be directly what you need but that can be used to infer the metrics that you care about. For example, in the case of SMS messages that have no analytics at all, you can assume a specific open rate based on industry benchmarks, or insert a link which you can track clicks on. You can then calculate an approximate open rate throughout your customer base.

Some channels have well-established workarounds for tracking. In emails, for example, it’s common to use web beacons, also known as tracking pixels. These are usually implemented as tiny images hosted on a third-party web server, and when a user opens the email, the email client loads that resource from the third-party server, which indicates to the sender that the recipient has opened the email. Such solutions don’t always work, however: users can disable images in emails, and iOS’s built-in mail application has a setting that prevents such tracking from working. There are other tracking techniques, like adding user-specific information to all links in the email, so if a link is clicked, it is straightforward to know which user the interaction came from.

Ensure data quality

To generate trustworthy reports about notifications, you will need to be confident in the data the reports rely on. Even though some data might be based on proxy metrics, as we discussed above, you need to be convinced that those are the best proxy metrics to use in your specific situation.

In addition, spend some time to understand possible limitations of source data — maybe there is a delay in the stats that some systems give you, or maybe there are sometimes empty rows in the data. You need to account for that ahead of time so you don’t run into issues later.

Identify how you’ll cross-reference stats between channels

The implementations of notification channels like email, chat, or SMS don’t know anything about the content of the notification you’re sending.

To be able to cross-reference the same kinds of notifications across channels you’ll need to create an identifier — for example, a unique ID number — for each notification. Such IDs need to be the same across multiple channels so that you can group them together later when generating reports.

Transform all data to a common format

In order to look at multiple channels together, you must have all the data available in a single report, dashboard, or spreadsheet, but that’s not that straightforward because different providers present data differently in their statistics. To be able to look at all data points across channels together, you will need to transform all data into a standardized format, for example, through an ETL pipeline.

Once the data is transformed, you can use any reporting or business analytics system that you already use — for example, Looker, Tableau, or Excel — to look at all the data points together.

Group by notification identifier — or eventually topics or notification types

Now that you have all the data in a single place and in the same format, and you also have a way to cross-reference notifications across channels, you can group data points by notification ID (or a similar identifier) across channels. You can then group this data across topics or types of notifications. For example, you might want to see all lifecycle notifications on one dashboard, and all transactional notifications on another dashboard.

Next step: use analytics to make better notifications

Having access to analytics for notifications is an achievement in itself, but remember that you’re doing it with an end in mind: to make your notifications better.

Now that you have data on notifications across channels, here are a few ways you can use the omnichannel data to identify opportunities to fix or improve your notification experience.

Identify opportunities for improvement

Consider which existing notifications have a lot of engagement. What can you learn from this? Is there any way you can replicate the success of such notifications in other parts of your notification experience?

In contrast, which notifications currently have little engagement from users? Maybe that’s a sign that these notifications need to be reworked or removed, or that you’re sending too many notifications.

Another question that can help identify opportunities is which notifications do your best customers receive the most? The “best” part here is up for interpretation according to your business goals — maybe it’s top customers by revenue, or by their level of engagement, or by another metric. Is there a connection between receiving these notifications and the value they get from using your application? If yes, how does that translate to the rest of your user base?

What trends can you monitor?

In addition to looking for specific answers in your notification data, sometimes it may be helpful to monitor trends so that you proactively see if things start to change. A few trends that you can look out for are:

The relationship between notification interactions and user growth. If you add more users but they interact less with notifications, it might suggest that the users are less engaged, or that the notification experience is no longer a good fit for your newer customer base.
Cohort analysis. Are newer users responding to notifications better or worse than users that have been around for a while? By looking at notification stats in the context of user cohorts, you can quantify the effect that notification changes have on new user onboarding.

Don’t have time to build notification infrastructure yourself? Try Courier

Omnichannel analytics are an enabler for doing great things with notifications, and we believe getting such analytics to work in your product is key to long-term improvements in the notification experience.

It can be a lot of work to build all the required infrastructure for omnichannel analytics, though. And if you don’t have the required resources to commit to implementing it all yourself, consider using Courier.

One of the key features Courier offers is an Analytics dashboard which helps you see traction across notification channels out of the box. Need something more custom? With the Logging feature, Courier can export the details of all notifications sent, across channels, into a system of your choice so that you can run more detailed reports.

The Product Manager's Guide to Preference Management for Notifications

anwesa-courier — Fri, 07 Oct 2022 17:07:16 +0000

Notifications are a crucial component of most products, but they come with a catch. None of us likes to be interrupted, yet we want to see new information — like direct messages, time-sensitive tasks, or attractive product updates — as soon as it’s available. How can you balance these two needs?

It can be frustrating for users when a product or service doesn’t allow them to control their notification experience. Perhaps you’ve encountered it yourself: for example, when you get a distracting notification on your phone that turns out to be irrelevant.

Productivity apps, like Slack or Microsoft Teams, whose core functionality involves notifications, offer several options for users to configure their notification experience. From choosing notification channels (like email or mobile push), to configuring out-of-office hours, those apps try to make their users’ lives less distracted and more productive by letting users control which notifications they want to get when and where. There’s a lot we can learn from such applications!

In this article, we’ll cover notification preferences — what they are and which preference options you should consider including in your app — and share some tips on which more advanced options you could build to delight your customers.

What are notification preferences?

Notification preferences are a way for users to configure how and when they would like to be notified of anything important happening within the product or service. For example, an event app may offer its users to configure whether they want to periodically see all upcoming concerts in their area, or only want to be notified when their favorite artists are playing.

At Courier, we like to break down notification preferences into two categories: notification logic and notification channels.

Preferences related to notification logic influence when the app notifies its user. For example, a user of a local marketplace app might want to get notified about each new offer in their area, or just receive a summary of all offers at the end of the day — or not get any notifications at all about offers, perhaps because they are only selling and not buying at the moment.

Channel preferences influence how the notifications are sent — via email, through Slack or Discord, via an SMS message, or otherwise. Using the marketplace app example from above, a frequent seller might want to get instant push notifications for any new messages, while an occasional buyer might prefer to be notified via email only.

In our experience at Courier, it’s important for users to be in control of both the notification logic and the channels used. So as the provider of a product or service, you need to make sure that your users can configure both if you want to offer them an optimal user experience.

Why adding notification preferences is a worthwhile investment

As the amount of notifications sent increases throughout the software industry, users are rarely given the controls over what they want to be notified about and when. Customers increasingly resort to extreme measures — disabling all notifications for an app or service, or even deleting their accounts.

Product managers tasked with improving notifications sometimes believe that it’s possible to build a standard notification system that suits most users. And while this might be true for occasional notifications, the one-size-fits-all approach is no longer suitable when notifying users frequently. Additionally, the power users of your product or service will likely be the ones most affected by an inflexible notification experience — and those are the users that you most need to keep.

When you give users the control over notifications they want to receive, they are much more likely to want to continue receiving your notifications and be engaged with your app.

Best practices for notification preference management

Before adding notification preference management to your product or service, you’ll need to identify the preferences that would have the most impact for your users. The main challenge when determining which preferences to include is the balance between complexity and flexibility: you want the preferences to be powerful, but also easy to understand and use.

Let’s look at the best practices for preference management which we identified over the years of building Courier.

Comply with GDPR and CCPA regarding consent

Compliance with regulations like the General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA) is a requirement for the vast majority of B2B software companies today, and notifications need to be compliant too. As part of notification preference management, you will have to collect and store the information on whether your users have provided consent to getting notifications, of what kind, and how that consent was provided.

In order to stay compliant with laws like GDPR and CCPA, you will need to make it possible for users to view their consent settings and withdraw consent in the future, if they prefer.

Store notification preferences and let users see the preferences they chose

Depending on the number of users you have and the number of notification settings you’ll be implementing, you’ll need to consider how the user preferences will be stored. Because the settings need to be taken into account for every event that’s potentially relevant to a user, simply adding a database table for notification preferences might not be sufficient.

Work with your engineering team to understand how and when notification preferences will be accessed within your app and choose a data store for the preferences that is suitable for the task. Learn more about the technical side of implementing notification preferences in our article The Developer's Guide to Building Notification Systems: Routing and Preferences.

Allow users to opt in and out of notification types

One of the largest sources of annoyance for users is getting both lifecycle (marketing) notifications and transactional notifications within the same channels and with the same settings. As an example, have a look at this Reddit thread where users complain about this behavior in the Uber Eats app, or this thread with a similar complaint about Instagram.

Ideally, applications should allow users to opt out of notifications that they’re not interested in, while staying opted in to the ones they do want.

Allow users to opt in and out of specific channels

The next step is to allow users to set their preferred channels for getting notifications. Some users will want to only get emails from your service; other folks will want more timely notifications through push. It’s ideal if you allow them to set preferences on channels for various notification groups — so that, for example, in a collaboration tool a user can get push notifications for mentions of their username, but get an email summary for all notifications that don’t involve them directly.

In the examples above, it’s possible that the users actually wouldn’t mind receiving an Uber Eats special offer — but probably not through a push notification, which is usually reserved for time-sensitive notifications.

Allow users to configure frequency, including digests

A common mistake when implementing preferences is to offer only two choices for a particular topic: all notifications or none at all. Frequently, users need a middle ground. For example, a member of a Discord community might not want to get notified of every new message, but they potentially wouldn’t mind a summary of messages.

A common solution in such situations is to offer periodic digests — often via email. Users can configure the time period they would like to get a summary for, most frequently daily or weekly. The service then collects all notifications generated during that period and sends them as a single overview.

Allow users to configure topics — all notifications versus critical notifications

There is more nuance than the basic distinction between lifecycle and transactional notifications. Each reasonably complex application or service will likely have various kinds of lifecycle and transactional notifications, and your users might be interested in only some of them.

We recommend letting your users configure topics they are interested in getting notified about via a given channel. These topics can be as broad as “time-sensitive notifications” or “urgent account-related messages,” or more specific like, “timely special offers,” and ideally users would be able to choose the most suitable notification channel for each topic.

Additional preferences are a way to delight customers

With the basics of notification preference management covered, let’s have a look at a few more advanced options. Such advanced settings can be more difficult to implement, and they might not seem so critical compared to the basic notification functionality. However, if the advanced settings closely match what your users need, they might create some positive differentiation for you versus any competitor solutions — and delight your users. Here are a few ideas that hopefully will get you interested in building more advanced preference management functionality.

Allow users to specify multiple email addresses
Most services operate under the simplistic assumption that users have only one email address, but frequently that’s not the case. For developers, for example, the email address associated with their GitHub account can be their personal email, while they also have a company-issued email address. Because of this, GitHub allows users to choose which email address to use for notifications.

If your application can be used in both work and non-work contexts, consider letting your users pick which email address, device, or phone number they want to use for notifications — it will make their experience more enjoyable.

Redirect notifications to another user

While you are on vacation, you might want someone on your team to periodically check for any critical notifications in your area of responsibility and escalate to someone else if needed. That’s easier said than done, however: while it’s possible to redirect emails with rules and filters, notifications that get sent to other channels like mobile push can’t often be redirected to another user.

Does your product involve collaboration in a business context? If yes, a feature for redirecting notifications might be a good fit for your user base.

Silence notifications at night

Many business communication apps try not to disturb users at night. If you decide to implement this feature in your notification system, don’t forget about timezone support!

And some folks' biological clocks might work differently, so giving them an option to configure their own hours without notifications can be handy. Slack, for example, achieves this using its configurable Do Not Disturb mode.

Don’t want to build the preferences engine yourself?

Regardless of the preferences you want to add for your users, try to create a solution that balances complexity and functionality and, ideally, keeps notifications flexible while also being easy to use for all users.

Excited to add notification preference management to your app but don’t want to build the infrastructure for it? Consider using Courier.

With Courier, you not only get notification preference management out of the box — you also get:

Built-in storage for your users’ notification preferences
Support for internationalization for notification text — including a workflow that you can use with translators within the service
Automations and workflows that connect to other business apps
Notification templates that non-technical stakeholders can manage through a user-friendly UI

How Decoupling Notifications from Your Application’s Code Empowers Product Managers

anwesa-courier — Mon, 26 Sep 2022 15:52:16 +0000

As a product manager, have you ever had to say no to improving your app’s notifications because of how complex the project seemed?

If yes, you’re not alone. At Courier, we frequently see product teams deciding not to work on notifications. And PMs aren’t making that decision because a good notification experience is not important for their SaaS product or service — quite the opposite.

The reason is that changing notifications, in their experience, requires a lot of work between engineering and product due to how closely the notifications are tied to the rest of the application. If PMs are tasked with adding a new email campaign that all new users of the app will receive, that can usually be done outside of the core app. But sending more unique notifications, like alerting a Slack channel when someone @-mentions their colleague in a shared file, can be complex and require significant engineering work. And still more work is needed when the text or the design of such a notification needs to be updated.

We believe that changing notifications doesn’t have to be so difficult. In this article, we explain how decoupling notifications from your application’s codebase can help make notification projects less complex and less risky for product teams.

Why PMs believe notification projects are hard

Usually, the task of improving an app’s notification experience — like adding or changing notifications, or connecting additional notification channels — falls to the engineering team that’s responsible for the main product. Such teams have lots on their plate, which makes it necessary to prioritize some tasks over others.

Notification projects tend to be high-value for product managers, as a bad notification experience can have a negative impact on a SaaS app’s customer base, while, conversely, a good notification experience can drive growth metrics and delight customers.

However, notification projects also score high on complexity and risk at most companies. That’s because different notification channels, which are quite different by nature (think email versus mobile push), require a lot of individual engineering.

With so much complexity involved, product managers have to make a tough call: is it really worth taking on notification work when there are easier projects to work on with more tangible benefits? Because task backlogs frequently have other items in them that don’t carry as much complexity or risk, it’s logical for product managers to postpone rather complex notification projects. And so notification projects get moved down the priority list, again and again.

The limits of common engineering solutions to notification problems

To try and make notification changes less difficult to implement, engineering teams use open-source tools that are well supported within their framework or programming language of choice. For example, those working with Ruby on Rails applications often use Rails’ built-in email sending module, Action Mailer, which includes functionality for sending plain-text and HTML emails.

While tools like Action Mailer are convenient to use and well-maintained, they can’t handle more complex tasks like expanding beyond the standard notification channels. If you want to add Slack or SMS notifications, for example, choices like Action Mailer can become a limiting factor, rather than an enabler of new product functionality.

The next logical option for a software team running into tooling limitations is to go with a fully customized notification system — but such a system brings its own challenges.

Even a custom notification system is a bottleneck for notification improvements

It may seem that the solution to the limitations of open-source tools is to simply build your own custom notification system. But a custom notification system is still code that implements notification logic, supported channels, and templates for specific notifications, and this code lives inside the application codebase in a version control system like Git. Any changes to this part of the codebase have to follow the steps of the software development process, which becomes cumbersome when making many small changes, as is the case with notifications. (Not to mention that engineering time needs to be allocated to the maintenance of such systems in the long run.)

For example, if the task is to update the wording or the design of a notification across all channels, the engineering team tasked with the work might have to:

Change the HTML email template.
Change the Slack notification template.
Change the Microsoft Teams notification template.
Test all three changes.
Wait for code review on the changes.
Once the code is reviewed, deploy all three changes to production.
Hand off to the PM for a final confirmation.

And every time a PM wants more changes implemented for notifications, the process has to start over again, even for trivial content changes. The standard development process, which is totally reasonable for code changes, is too much overhead when working on notifications, and the additional overhead takes the engineers’ time away from working on more valuable things.

The result: notifications rarely get updated

Because of the additional delays introduced by the development process, the friction for implementing notification changes ends up being so high that PMs often choose to not implement notification changes at all.

Instead of focusing on building the best possible notification experience, they settle for the default notifications that are built into their application already, because anything else becomes too difficult to do. They might think “If it took two weeks to change the simple design on my notifications, we're just not going to change things anymore.” And so notification experiences stall out indefinitely.

There is a better way: enable PMs to work with notifications without involving the engineering team

Courier’s point of view is that the way notifications are handled in most SaaS apps today — templates stored in code, notification functionality changes requiring code deployments, etc. — is outdated and, as we have seen in the examples above, ineffective.

Instead of having to go through the development process for each notification change, we need to give PMs and other non-technical stakeholders the right tools to work with notifications directly. Here are the core practices that act as enablers for non-technical audiences.

Making templates accessible to non-engineers. Notification templates in the form of text, HTML, or programming-language-specific template files need to be located outside of the application code, and PMs as well as other non-technical teams need to have access and be able to make changes.

Making notification logic configurable without needing to re-deploy the app. The logic involved in deciding which notifications to send when should not be located in the application code, but rather sit next to it and be configurable without needing to deploy the application. The configuration can live in a text file, a web interface, or another config format. PMs should ideally be able to change the configuration themselves.

Enabling self-serve analytics. Besides notification functionality, PMs need to be able to track how their changes are doing — and be able to follow the statistics without the need to ask engineering or data teams for the numbers. Analytics can be presented as a custom dashboard, but can also be an export of a business intelligence report, or even a dump of application logs that show which messages were sent, depending on which option is easier.

What are the results of PM enablement?

To show that PM enablement works as a way to make notification projects easier, we want to share two examples from Courier customers that have experienced this change.

Bluecrew, a marketplace for hourly jobs, has seen its business grow after decoupling notifications from application code. The company was able to improve the onboarding experience for new users in part by taking advantage of notification templates and making them accessible to non-technical stakeholders.

Within Bluecrew’s notification system, “anyone can add a content block and insert a custom attribute like ‘shift start time’ or ‘cancelation reason.’ We also have the flexibility to add custom code anywhere in the notification,” says Cooper Newby, the Chief Product Officer at Bluecrew.

Another company that’s been taking advantage of the enablement approach is Expel, a provider of security services. The Expel team has enabled its UX designers to use the template designer UI directly and make changes to the product in real time.

“We can get our UX designers working directly on the templates and we can make updates and have them live in seconds,” says Yousuf Ashparie, Principal Software Engineer at Expel.

Does enabling PMs to make notification changes sound appealing at this point? We hope it does — as we believe it’s a significant improvement over the current practices at most companies. Let’s look at how you can enable PMs to work with notifications in your own team.

So, how can you enable PMs to work with notifications?

Looking to enable PMs to do more notification work, but not sure where to start? Here are our top recommendations for companies looking to get started on the PM enablement journey.

1. Get analytics in place. Having analytics for notifications is a key tool for PMs to measure any notification changes. While metrics can be difficult to come by for some notification channels, it is usually possible to have at least some numbers in place. Once the PMs get the data, they can use it to avoid accidentally making the notification experience worse, and to make sure the rest of the organization can see the benefits for larger changes to notifications.

2. Make it easier to change notification templates. While it’s ideal to make all notification channels and notification types configurable by PMs, it’s not always realistic. Instead, at least make it so that PMs can change existing notifications without much involvement from the engineering team. Even if that’s all you allow, you will still need to add functionality to adjust notification designs to fit the updated content, and likely implement internationalization and translation workflows if you’re interested in supporting multiple languages.

3. Build guardrails to prevent notification issues from escaping to production. Ideally, all notification functionality should be covered with automated and, possibly, manual tests so that the organization can be confident in the product’s notification experience at all times. The areas to check include: notification text fitting within the display area; possible internationalization glitches; technical issues like app crashes resulting from changes in notification text size; handling of unexpected characters if notifications include user input.

Courier can help

Instead of building everything yourself, use Courier — and get our recommended steps 1–3 done almost instantly after some brief initial implementation work.

Using Courier frees up your team to focus on other valuable things in their backlog. For PMs, UX designers, and other non-technical stakeholders, Courier helps by:

providing a drag and drop designer, including a staging environment, with the ability to make changes live without deploying the app
offering a UI that allows users to add new notification channels without needing to update code
including an Automation UI that allows users to build out notification workflows visually (no application code)
Implementing the guardrails in point 3 above, so that you can reduce the effort involved in changing notifications without increasing the risk.

How PMs Should Build a Great Product Notification Experience

anwesa-courier — Fri, 16 Sep 2022 15:37:28 +0000

Your product’s notification experience can make or break how your users perceive your application. That’s why getting the notification experience right should be at the forefront of product managers’ minds. But what, exactly, is a great notification experience for a mobile or web app? Here at Courier, we often hear this question from product managers.

In this article, we’ll do a deep dive into what contributes to a great notification experience. We’ll talk about various notification types, which notification channel is best suited for what kind of message, and how to make sure that your users don’t leave your product due to wrongly timed notifications. After reading this article, you’ll have the confidence — and the tools — to set up a notification system that delights and doesn’t annoy.

What is a notification experience?

In this article, we use the term “notification experience” to include everything your users see, hear, do, and feel when they interact with notifications from your app or software service — from emails to push notifications to Slack messages and beyond.

Image: email, push, and Slack notifications for an HR application.

Notification channels are a central component of a notification experience. Each channel is a way to reach the user through a particular technology, platform, or service that is able to deliver notifications. Here are some examples:

Mobile push (including banners, badges, sound alerts)
Email
Chat (like Slack or WhatsApp)
SMS
Phone call
In-app notifications

In many cases, it’s not sufficient to only use one notification channel, so most notification experiences would also include notification logic. In addition to defining which channels to use under which circumstances, the logic would process user preferences, pick the right language based on the user’s profile, and so on.

How different notification types contribute to the overall notification experience

There are two broad types of notifications used by software products and services: transactional notifications and marketing notifications.

Transactional notifications are directly relevant to a specific action, like creating a post or placing an order, that a user takes within your app. Examples can include a delivery app that sends them an immediate confirmation of an order, or a marketplace app that notifies them of a new message about a product they’re looking to sell.

Lifecycle notifications are designed to encourage your users to return to and interact with the product itself. An example is sending a user who hasn’t been in the product for three weeks a reminder email that their work in the app is waiting. Or sending a weekly digest of statistics to a user by email and having them return to analytics within the product for more details.

While the boundary between these notification types can sometimes be blurry, the core concepts are defined quite specifically in law.

A transactional push notification and a marketing push notification. Similar format but different purposes.

In general, you could use any notification channel for both transactional and marketing purposes, but some are more suited to one or the other. We offer some examples in the table below.

Channel	Advantages	Disadvantages	Best suited for	Not suitable for
Email	Wide adoption.	Can take days for the recipient to read an email. Possibility of hitting deliverability issues. Possibility of getting lost in the inbox.	Important information that the user shouldn’t miss, like pricing changes, account updates, security alerts; marketing messages that are not time-sensitive.	Time-sensitive alerts — as email is not designed to be read instantly.
Mobile push	Received quickly by the user; can take the user directly to the app to perform an action.	Alert fatigue; limited settings on the user side.	Timely alerts.	(Arguably) marketing messages.
SMS	Wide adoption.	Doesn’t work without a mobile connection. Length limitations.	Timely alerts about appointments, events, etc.	Most app notifications.
Chat (Slack, Discord)	Reaching chat app users with less interruption; giving users an opportunity to see messages in the app when browsing other activities.	Can get lost in the chat. Possibility of not reaching the recipient if they are not checking the chat often.	Context-specific notifications — for example, work conversations or gaming conversations.	Time-sensitive notifications outside of chat hours. Security alerts.

There is no single channel that is perfect for all uses. A good notification experience should take advantage of each channel's strengths.

A bad notification experience can frustrate users

Based on our experience speaking to Courier customers and prospects, product managers understand that notifications matter, but sometimes they don’t see how much they matter. In reality, lots of bad things can happen if the notification experience for your app or service is not good. For example:

You could lose users due to incorrectly using notification channels, like sending marketing notifications via channels like mobile push which are normally only used for time-sensitive, transactional alerts. Such application behavior can feel unprofessional and spammy, causing users to lose trust in your product or service.
You could upset users due to sending notifications at the wrong time. For example, someone who gets an avalanche of notifications might decide to completely block them for your app. This means that even your important messages can’t reach them. Also, needlessly sending out notifications at night could cause users to literally lose sleep. Who would want to do that to their customers?

What does a good experience look like, in contrast?

Let’s contrast the potentially serious consequences of a bad notification experience with the more positive aspects of a good experience. Based on what we see at Courier, here are the key aspects that contribute to a good notification experience.

Right channels. Choosing suitable channels for your notifications makes it more straightforward to build and improve your notification experience later on. For example, in a banking app, using mobile push for transaction notifications would likely be a good fit due to this format’s timeliness, while email wouldn’t be so suitable. However, if there is a suspicious transaction, it might be better to send an SMS, or even escalate to a phone call to make sure the customer doesn’t miss the notification.

Right timing. It’s better to avoid sending some notifications like mobile push at night, as that might wake your customer up unnecessarily if they don’t have the right alert settings. A local marketplace app, for instance, should thus try to avoid sending mobile push (or other intrusive) notifications at night. Instead, it could send a summary email in the morning. On the other hand, mobile push notifications could be totally right for a security-related alert.

Right customizations and preferences. In addition to allowing notifications to be fully on or fully off, applications should offer ways for users to customize notification settings to their needs. For example, a weather app might offer a separate setting to turn rain notifications on or off independently of low temperature notifications. Some of us dislike rain less than others!

Following platform best practices. A notification experience that seamlessly fits into the platforms you use for notifications, like iOS push, in-app notifications, or Slack, will add delight into your customers’ day. An HR app like the one we showed above, for example, should make use of Slack’s various built-in “blocks” when it makes sense, rather than using the basic text-only format and shoehorning various content types into that format’s limitations.

Common objections to building a good notification experience

At Courier, we frequently talk to product managers as part of our support, solutions, and sales conversations. We’ve noticed over time that there are a few key issues that are blocking PMs from improving their product’s notification experience. Below, we list some of the most common concerns. Have a look if any of those resonate with you!

“I can’t control the notification experience the same way as I can control the app experience.”

Yes, it’s true that you don’t have as much control over how the notifications in your product look and feel, compared to the app itself. This is because the notifications on platforms like iOS and Android need to look like iOS and Android for consistency, rather than your brand colors and font face. Your app can only customize parts of the notification experience on these platforms.

Another way to look at this limitation, however, is to recognize that there is a smaller UX hurdle for users to overcome when relying on an existing notification system, where users already know how notifications look and feel. Moreover, modern notification systems on iOS and Android, as well as other channels like Slack, Discord, and email, are flexible enough for companies with such unique products as Uber, Airbnb, and LinkedIn to offer a good notification experience — so you can do a good job too despite platform limitations.

Our advice is to explore what different notification platforms have to offer: Slack, for example, has multiple message “blocks” that your application can send, and you might find exactly what you need in one of the pre-built blocks. And in iOS 16, the new Live Activities feature for notifications can change how notifications work for time-sensitive events.

“I don’t know what a good experience for my users looks like.”

It can be challenging to identify exactly which notifications need improving for an optimal app experience, or how you can make a notification’s content or format more valuable to your users — and lack of in-depth notification analytics can be a contributing factor. While it’s straightforward to measure engagement on a website with tools like Google Analytics or Matomo, analytics of users’ notification experiences are harder to get.

Our recommendation is twofold:

Try to get quantitative data on notifications — for example, open rates and clicks across channels. On some platforms, like email, this is easier; on platforms like iOS this is more challenging but still possible.
Support the quantitative data with user research. Send surveys to your users and ask them which notifications they find most valuable, and which they find annoying (if any).

For inspiration on good notification experiences, consider apps that you use frequently yourself. Are there any apps where the notification experience feels “just right” — delivering messages at the right time and pace, with relevant and engaging content?

“Designing a good experience is too hard.”

Because there are so many different platforms involved in a notification experience, PMs can feel overwhelmed by the number of decisions they have to make when it comes to designing the notification system.

Our advice is to focus on fixing aspects that are wrong and getting the basics right, rather than trying to implement advanced notification techniques from the start.

For example, the basic steps can include:

Getting basic analytics on notification interactions to better understand how your notifications are used by your users
Making sure notifications don’t crash the app
Allowing users to customize their notification experience using basic preferences
Adding relevant channels — as outlined in our table above — so that users can receive the kinds of notifications they need

Each of these items should be small enough to be able to implement with your team. By focusing on smaller, tangible deliverables you can slice the ambiguous “notification problem” into manageable chunks.

Tips for building a great notification experience

To summarize, the way to build a great notification experience is to consider notifications a core part of your product and treat them accordingly.

Apply user research, design thinking and other product techniques to notifications too, not just your application. Test your notifications the same way as you test the rest of your product, to ensure that they are functional and look good. Measure the impact of notifications on user behavior via analytics.