Guide

Tutorial

Product News

Courier Updates

User Experience

Product Management

Integrations

Engineering

Live Streaming

Notifications Landscape

Courier

Thomas Schiavone

Search is evolving—and fast. At Courier, we’ve started to see a shift in how users are finding us.

Google still dominates product discovery. It remains the primary starting point for most users—and for most products, the largest source of referral traffic.

But something new is happening.

Over the past six months, ChatGPT has become a meaningful source of inbound traffic. It has already overtaken DuckDuckGo in our referral data and, at its current pace, will surpass Bing this year.

Perplexity showed early promise and gained traction among technical users, but its growth has since plateaued. We’ll come back to that.

Other tools, like Anthropic’s Claude, have recently introduced web search capabilities, but they barely register in our data. This shift isn’t about AI in general—it’s about a very specific change in behavior: people are using ChatGPT to find and access products directly.

And that’s starting to show up in the numbers. Here’s a breakdown of referral traffic from AI chat tools compared to DuckDuckGo, our lowest-performing search engine.

![AI Assistant Traffic Referral Sources](//images.ctfassets.net/z7iqk1q8njt4/7mYKFgX13UVN9lrCkWYbZX/d420fc706619aff362725ecd0286ec7e/AI_Assistant_Traffic_Source_1.png)

---

## ChatGPT Is Becoming a Discovery Surface

When traffic from ChatGPT first appeared, it was a novelty. But since late 2024, that trickle has turned into a steady, measurable trend.

Month over month, ChatGPT has grown faster than any other non-Google source.

Today, it’s not just outpacing DuckDuckGo—it’s catching up to Bing. And this isn’t the result of a one-time spike. It reflects a real shift in how users are finding products.

This isn’t something to watch passively. It’s time to treat ChatGPT the way you treat search engines. The mechanics are different, but the effect is the same: visibility matters. The more clearly and authoritatively your product shows up in AI-generated answers, the more likely it is users will click through and engage.

---

## ChatGPT vs. Bing: The Gap Is Closing

Bing has been a steady, if modest, source of referral traffic for years. But ChatGPT is closing in—fast. If trends hold, it will overtake Bing within the next six months.

That said, our data may reflect the nature of our product. Courier is built for developers and product teams—audiences who are often ahead of the curve in adopting new tools like ChatGPT. Our content also aligns well with the kinds of queries AI tools can answer today: implementation questions, comparisons, integration how-tos.

That might not be true yet for other products... yet. As search models improve and user behavior shifts, we expect this pattern to extend well beyond technical categories.

---

## Perplexity: Early Traction, Then a Plateau

Perplexity was one of the first AI tools we saw show up in our referral data. It gained traction quickly and briefly looked like it could become a meaningful channel.

But since then, growth has stalled. Traffic from Perplexity has remained flat, even as ChatGPT continues to climb.

The most likely reason comes down to brand and distribution. ChatGPT benefits from massive exposure and widely regarded as the default AI interface. Perplexity, while respected in certain circles, doesn’t have the same reach or default presence.

It still appears in our data—but it’s not growing. That’s not a good sign for Perplexity’s long-term relevance as a discovery surface.

---

## Claude: Present in the Market, Absent in the Data

Anthropic’s Claude has been in the market a while but it’s the lowest by far among the AI assistants we track (we're giving Grok a pass for now). 

This isn’t surprising. The dominant way Claude is used today is through its API, not its user interface. That may change over time. But today, Claude simply isn't showing up as part of the product discovery journey—not in any meaningful volume.

---

## Google Still Dominates—But It’s No Longer Alone

Google continues to drive the majority of our discovery traffic. That hasn’t changed.

But the landscape around it is shifting. ChatGPT is now a serious alternative. And even Google is adapting. Gemini—Google’s own AI assistant—has started to appear in our referral data. It’s still small, but it’s growing. AI-assisted search is clearly becoming a core part of Google’s future.

For now, Google remains dominant. However, AI assistants are no longer a novelty—they’re becoming the new front door to the internet.


AI Is Changing How Users Discover Products Header

ChatGPT is becoming a real source of traffic. It’s already passed DuckDuckGo—and it’s on track to overtake Bing. Here’s what we’re seeing.

AI Is Changing How Users Discover Products

AI Is Changing How Users Discover Products Thumb

Anwesa Chatterjee

- [Part 1: Product Notification Experience](https://www.courier.com/blog/pm-product-notification-experience/)
- [Part 2: Decoupling Templates From Code](https://www.courier.com/blog/how-decoupling-notifications-from-your-applications-code-empowers-product/)
- [Part 3: User Preferences Management](https://www.courier.com/blog/pm-guide-to-preference-management/)
- [Part 4: Omni-Channel Analytics](https://www.courier.com/blog/pm-guide-omnichannel-analytics/)

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](https://www.courier.com/blog/pm-product-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](https://www.courier.com/blog/pm-guide-omnichannel-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.

![pm-guide-automations-1](//images.ctfassets.net/z7iqk1q8njt4/73USDva4STQ0TQE6ywG9ug/c2fe456c7449be4b02a889a67ef1702c/image1.png)

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](https://www.courier.com/docs/reference/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.

![pm-guide-automations-2](//images.ctfassets.net/z7iqk1q8njt4/1s1Tk6e0hlH6q5VpqsJFtA/60a044a826f14ea5de9ba86b2966fbc5/image3.png)

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](https://www.courier.com/blog/gdpr-communications/), 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](https://www.courier.com/blog/pm-guide-to-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](https://www.courier.com/docs/guides/tutorials/how-to-configure-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](https://www.courier.com/blog/perfect-mobile-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.

![pm-guide-automations-3](//images.ctfassets.net/z7iqk1q8njt4/3bqnv3dUpR30ttUbAPXJSs/5778fbeaa848dec09ec754bf714c71ba/image2.png)

Thanks to [triggers](https://www.courier.com/blog/automations-notification-workflow-designer/#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.


Courier is a notification service that centralizes all of your templates and messaging channels in one place which increases visibility and reduces engineering time. 

Start Routing Notifications Today!

pm-guide-automations-header

Tailored notifications are essential for a positive user experience. Learn how automation tools make it easy to customize user notifications.

pm-guide-automations-thumbnail

The Product Manager's Guide To Building Notification Systems: Optimized Automation Logic

- [Part 1: Product Notification Experience](https://www.courier.com/blog/pm-product-notification-experience/)
- [Part 2: Decoupling Templates From Code](https://www.courier.com/blog/how-decoupling-notifications-from-your-applications-code-empowers-product/)
- [Part 3: User Preferences Management](https://www.courier.com/blog/pm-guide-to-preference-management/)
- [Part 5: Optimized Automation Logic](https://www.courier.com/blog/pm-guide-notification-automations/)

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 omni-channel 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 omni-channel 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. 

![single-channel-vs-omnichannel](//images.ctfassets.net/z7iqk1q8njt4/2mRenvWGbkuJRYHdnXqUTL/857b5011db4a2bfb924164145d6722f4/image2.png)

## 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](https://www.courier.com/blog/pm-guide-to-preference-management/) 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.

![pm-guide-omnichannel-analytics-2](//images.ctfassets.net/z7iqk1q8njt4/3NjBPbLLPiweXq496G9Tse/d4e6094413b211492430dbd0e92b7a02/image1.png)

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](https://en.wikipedia.org/wiki/Extract,_transform,_load).

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](https://www.courier.com/docs/platform/logging/analytics/) which helps you see traction across notification channels out of the box. Need something more custom? With the [Logging](https://www.courier.com/docs/platform/logging/intro) 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.

pm-guide-omnichannel-analytics-header

In this article, we talk about omnichannel analytics, why analytics are hard for notifications, and what we believe is needed to empower PMs.

How to Use Omnichannel Analytics to Improve Notifications

pm-guide-omnichannel-analytics-thumbnail

The Product Manager's Guide To Building Notification Systems: Omni-channel Analytics

- [Part 1: Product Notification Experience](https://www.courier.com/blog/pm-product-notification-experience/)
- [Part 2: Decoupling Notification Templates From Code](https://www.courier.com/blog/how-decoupling-notifications-from-your-applications-code-empowers-product/)
- [Part 4: Omni-Channel Analytics](https://www.courier.com/blog/pm-guide-omnichannel-analytics/)
- [Part 5: Optimized Automation Logic](https://www.courier.com/blog/pm-guide-notification-automations)

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.

![what-are-notification-preferences](//images.ctfassets.net/z7iqk1q8njt4/26esUMLdsmqcKzPyI0kGln/f4a04759341a692f8821da6c2f17f1b5/image2.png)

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.

![how-notifications](//images.ctfassets.net/z7iqk1q8njt4/5rZXRJUysU9umN1h7SfsSw/194989bff3fe44c20f0194f80bc24473/image1.png)

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.

![likelihood-of-getting-annoyed](//images.ctfassets.net/z7iqk1q8njt4/2Px3YfYW63MSa7gatOL82u/d28b0f71a92556c7455f4af6e251b079/image3.png)

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](https://law.stackexchange.com/a/29191) 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](https://www.courier.com/blog/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](https://www.reddit.com/r/UberEATS/comments/lq71yi/how_do_i_disable_promo_notifications/) where users complain about this behavior in the Uber Eats app, or [this thread](https://www.reddit.com/r/Instagram/comments/q6ijfq/how_to_turn_off_notification_account_3_others/) 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](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/adding-an-email-address-to-your-github-account) 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](https://slack.com/help/articles/214908388-Pause-notifications-with-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](https://www.courier.com/features/preferences/) 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


pm-preferences-header

In this article, we’ll cover what notification preferences are and which ones you should include in your app. Read tips for advanced options you could build.

The PM’s Guide to Preference Management for Notifications

pm-preferences-thumbnail

The Product Manager's Guide To Building Notification Systems: Preferences Management

- [Part 1: Product Notification Experience](https://www.courier.com/blog/pm-product-notification-experience/)
- [Part 3: User Preferences Management](https://www.courier.com/blog/pm-guide-to-preference-management/)
- [Part 4: Omni-Channel Analytics](https://www.courier.com/blog/pm-guide-omnichannel-analytics/)
- [Part 5: Optimized Automation Logic](https://www.courier.com/docs/tutorials/how-to-automate-message-sequences)

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

![image1](//images.ctfassets.net/z7iqk1q8njt4/6kGqayxYctQyy0qkn5MolS/74f523a316788e845e22186ca06c979e/image1.png)

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](https://www.courier.com/blog/pm-product-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](https://guides.rubyonrails.org/action_mailer_basics.html), 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](https://www.courier.com/blog/courier-bluecrew-multi-channel-notifications/) 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](https://expel.com), 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.


pm-guide-2-header

In this article, we explain how decoupling notifications from your application’s codebase can help make notification projects less complex for product teams.

Why PMs Avoid Notification Projects — And How to Fix It

pm-guide-2-thumbnail

The Product Manager's Guide To Building Notification Systems: Decoupling Templates From Code

- [Part 2: Decoupling Notification Templates From Code](https://www.courier.com/blog/how-decoupling-notifications-from-your-applications-code-empowers-product/)
- [Part 3: User Preferences Management](https://www.courier.com/blog/pm-guide-to-preference-management/)
- [Part 4: Omni-Channel Analytics](https://www.courier.com/blog/pm-guide-omnichannel-analytics/)
- [Part 5: Optimized Automation Logic](https://www.courier.com/blog/pm-guide-automations/)

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.

![pm-1-1](//images.ctfassets.net/z7iqk1q8njt4/7EK4zCoBASw1pcFUTJcCfc/eeaa0911f8533e864f0642d7b76d34ee/pm-1-2.png)
*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](https://www.law.cornell.edu/uscode/text/15/7702).

![pm-1-2](//images.ctfassets.net/z7iqk1q8njt4/5MDpTUst0073rooipedWJy/68594b245d11bace5ce954bca397ab42/pm-1-1.png)
*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.

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

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”](https://api.slack.com/reference/block-kit/blocks#section) 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](https://9to5mac.com/2022/07/27/ios-16-live-activities-api-available-beta-4-developers/) 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](https://productschool.com/blog/product-management-2/product-management-skills-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.

pm-guide-1-header

After reading this article, you’ll have the confidence and the tools to set up a notification system that delights and doesn’t annoy.

pm-guide-1-thumbnail

The Product Manager's Guide To Building Notification Systems: Product Notification Experience

denis-tatar-headshot

Denis Tatar


*Preference management is an integral part of a great notification infrastructure, which makes it a very important piece of the puzzle here at Courier. This also means that there was a lot of learning and experience-building opportunity for the intern on the project, Denis Tatar. Denis’ internship was only a few months long, but he was able to make an enormous impact as the product manager for Courier’s Preferences feature.* 

*We wanted to learn more about Denis’ experience, so we asked if he’d be willing to work on a writeup for us. Then what he came up with was so good, we thought it would be a good idea to share with all of you! This post will cover Denis’ workflow from planning to execution around the Preferences project as well as his experience working with the Courier team specifically. We’ll let Denis take it from here!*

## What was the problem?
The problem we experienced at Courier was that we’d offer Preferences (V3) to our customers, but the entire product feature’s strategy wasn’t fully fleshed out. I believe that V3 was a great stepping stone for V4, but fundamentally had flaws in certain parts of its strategy. Allowing only global opt-in/out is an example of this. Another problem was that V3 didn’t gain much traction, which I believe points back to the lack of a fully thought out strategy. In May, Preferences (V3) would only allow users to opt-in and out of their preferences of choice globally. V3 of Preferences only allowed our customers (and their customers) to opt-in/out of notifications, and customers globally could also decide if certain notifications were required or not. V3 helped give our customers the ability to start playing around with the idea of having preferences. However, globally opt/in out is a problem because it constrains end users’ notifications options. It was either all or nothing, no in-between. Similar in theory to the Pokemon saying, “Catch one, catch them all.” A problem with this, though, is inbox flooding. Global opt-in would allow for the concept of the end users’ inboxes becoming flooded with every product notification which is problematic because it can easily drive users away from your product. 

Global opt-in/out was quickly resolved by allowing users to select what content they wanted to be notified of and the channels they’d prefer. This overall trend in the market is used by thousands of companies (B2B and B2C products), especially in the technology space.

![Product Preferences Screenshot](//images.ctfassets.net/z7iqk1q8njt4/4wL7Y4vOcZxXWQHf40diKM/95442b858fa2c6def0f2d46add560a54/image_for_internship_blog_post.png)

Visibility became a serious issue with V3. End users never had the option to select what type of content and channel they wanted. Users would be asked if they were interested in receiving notifications in general. Not offering options is problematic as it constrains visibility on what you’ll receive through notifications. End users also don’t like surprises when it comes to product notifications. Having clarity is key because it enables end users to have control over their notifications.

With V4, we solved the visibility problem, which was the main “fail” from V3. Our customers and their end users now had the ability to control the content they received and the channels they would prefer.

V4 was a good way to strategically notify end users. 

## Plan
There were three phases we followed as a team when building Preferences. 

**1. Research**
In phase one, I spent a decent amount of time looking at what is currently available in the market in terms of preference centers. I would constantly ask myself the following two questions:

“How does [insert company name] manage notifications? What does their preference center look like?”

These questions were key. They helped me dive into necessary research which helped me pick up on many important market trends. Out of all the trends found though, there was one that stood out the most. 

**2. Trend**: Channel & content selection through a toggle/grid style layout for preference centers is a must have.

This trend became the backbone to our summer project. It was important to offer users preferences options. 

During this phase, I read many case studies. I was surprised to see how many existed on this topic. Each one helped enlighten me with solutions for the problem we were tackling. I learned through other people’s mistakes, absorbing the valuable lessons. 

Talking to customers was extremely helpful in this phase. I was able to hop on numerous calls with our customers and hear their perspectives on this problem. I would ask questions and show examples of what we had in mind for a solution. This helped tailor a POC. The better we understand our customers’ perspective, the easier it is to start designing something that they would use. 

**3. Designing a POC**
I really enjoyed this phase. Watching research become an actual POC was incredible, and so fun. We took all the feedback I had gathered, then created several iterations of designs.

Once we created a POC, it was essential to go back to our customers and ensure that it was something they envisioned for Preferences. Our customers were also lovely people to work with, always there to provide their much-needed feedback.

Often, I would have a decent amount of brainstorming sessions with Ian. We’d look at our research and what our customers had to say, and combine these sources into a POC. It was an insightful process to be a part of.

This phase lasted several weeks until we finally landed on a POC that satisfied all of the customers we had spoken to since May 2022.

**4. Building an MVP**
Once we had a POC and fully completed designs, we began building our product feature. This phase taught me two vital lessons…

*Being organized is extremely important.*

and...

*As a product manager, you need to stay one week ahead of your team.*

While working at Courier and delegating tasks, I noticed that the more organized you were, the easier it was to work with others. My organizational skills would impact how clearly our designers and engineers understood our goals and individually delegated tasks. The more organized we were, the faster and more efficient we worked. Outlining the tasks our team needed to complete, and vocalizing why these tasks were necessary helped a lot. It brought clarity to everyone, including myself. 

The second lesson here was given to me by our CEO,Troy. He taught me how important it was to think about the current and following week. Troy brought this up because, as a product manager, you want to keep your team informed on what projects and tasks are in the pipeline.. A product manager that isn’t in this mindset can quickly become a hindrance to their team. Taking on this mindset brought clarity and made me less stressed about our project. I would spend time planning each week,and estimating where the team should be at the end of each week (cycle). 

These two lessons helped when we were building an MVP. We progressed through each week as a team, with each week’s tasks outlined, along with the weekly goals we’d needed to achieve. Working with the team at Courier was amazing, everyone was  understanding and absolutely brilliant. What I loved the most was that everyone had an opinion. Engineers and designers would ask if specific tasks were priorities before building them, which allowed us to build the MVP and get it up and running quickly. These questions helped guide priorities and decision-making. 

## Execution: What I did exactly
Throughout this internship, every day was different. My week would involve speaking to customers, delegating tasks to our engineers and designers, and taking time to think ahead, two to three weeks ahead of the current week. I also worked closely with both engineers and designers, ensuring great synergy between both teams. 

There were four core responsibilities that I embodied throughout my product manager internship at Courier:

Being the internal expert on what the market (customers & prospects) want within my realm of focus.

Being the internal expert on what my product feature already provides (and thus the delta to the above core responsibility).
The ability to prioritize the path that gets Courier from our current state to our desired state.

The ability to educate the rest of the company on the current product, the product being built, and our ultimate product vision so that everyone can be on the same page without being experts. 
As the **glue** that ensures the team is working together on the right thing for the right reasons, their success is ultimately limited by my effectiveness in one and two. I cannot accurately educate teammates on what I don’t profoundly understand myself. 

Troy was a fantastic mentor throughout my entire time at Courier. He brought these four core responsibilities to my attention, which became an integral part of my internship. What resonated with me the most was being the glue between all teams. At first, I looked at this concept and was intimidated by it. But, I had a blast easing myself into becoming this glue-like figure between teams. It definitely wasn’t something easy to pull off, but I enjoyed the challenge. I managed to make a lot of great friends along the way too!

## What trade offs did I experience? 
There were many trade-offs throughout my entire internship. The main ones I experienced were related to the following concept “make it work -> make it good -> make it fast,” which I often heard throughout my internship. There were many times when small features that could make our UI/UX stand out would actually slow down the team. 

Trade-offs like these were necessary. They had me questioning whether we focus on the nitty gritty details, or do we put the feature aside and focus on making a product that functions  and gets the job done? The latter part of that question was often chosen as our strategy. It’s tough to make these calls because you know the team can develop an outstanding product build with phenomenal UI/UX components, but our build must accomplish what it’s meant to do in the first place. 

The main goal was to release our MVP, ensure we have customer feedback, improve any core features, and then focus on minor priorities that affect the UI/UX of this product. 

## What was it like working with the team?
I had a blast working with the Lifecycle team on Preferences. Everyone was so kind, and offered fantastic feedback. I’ve mentioned this numerous times around the office, and on calls with coworkers. Working at Courier didn’t feel like work; it felt like I was working on a side project with close friends. I genuinely think this is why I was able to produce the work I did at Courier, because of the environment. Courier is easy-going, extremely friendly, and results-driven.

Another thing I really loved about the team was that they always thought of me. If there were tasks that engineers or designers would do that was considered a ‘norm’ for them, they’d ask me if I’d like to give it a shot to see what it’s like. I have three examples of this. 

When designing a specific tool tip for a part of the Preferences project, Ian (Senior Designer) during one of our calls, asked if I wanted a shot at designing a tool tip. This involved working with Frames in Figma, a concept I never worked with. I really enjoyed creating that tool tip. It made me feel included.

Every week the team would have our team Lifecycle planning meetings. We’d speak about tickets, and write them up. It was early on in my internship when Suhas (Senior Engineer) asked me if I wanted to try writing up several tickets on Linear. I was aware that this was something most PMs would normally do, but I had a lot of respect for Suhas for bringing this up, and was willing to teach me how to properly create tickets in Linear. 
Once the team had something solidified for Preferences, I began to ask around internally to learn if there were any companies that would be interested in hearing about my project. Nathan (Account Executive), reached out to me to let me know about a customer interested in this product feature. Nathan encouraged me a TON when it came to communicating with this customer. I was able to step outside of my comfort zone because of Nathan’s encouragement. I’ve never gotten to speak to a customer before at any of my previous internship experiences, and I learned a lot about customers and the way they perceive Courier. 

Note that these are just three examples from the many opportunities like this throughout my internship. I do want to give a big shoutout to Ian, Suhas, and Nathan. I appreciate you guys giving me opportunities to learn and grow, it means the world to me. 

## How did I work with designers?
I enjoyed working with Ian (Senior Designer). We’d have impromptu meetings through Slack’s ‘Huddle’ feature, (which was internally renamed to **‘Huggle’** because of a typo I once made that stuck). These meetings were really great for brainstorming and product design. Sometimes, Ian and I would have calls later at night because it was easier to come up with more creative ideas.. We’d have one to two hour sessions, and we’d come up with some really awesome UI/UX for Preferences. This is something I’ll never forget. 

When working with Ian, I would try to make it as easy as possible. I would create a to-do list through Google docs or Slack, so both Ian and I would be aware of what needed to be completed every week. 

During our calls, Ian and I would also talk about a lot of different topics not always directly related to work, which was great. This really helped build our friendship, making it so much easier to collaborate and come up with a clean UI/UX for Preferences. I often do a decent amount of product design outside of work hours, and Ian would always give me phenomenal advice on product design and on Figma!

## How did I work with engineers?
I briefly touched on this, but when working with engineers, I would help create tickets, and organize what each week would look like. I helped our engineers whenever they were confused about anything related to Preferences, and would explain how I came up with specific names, why Ian and I would design certain parts of our product, and the goals behind these designs. Many of these answers came from my extensive research process with customers that were interested in Preferences. 

While working with engineers, I learned a lot on how to properly break down tickets (eipcs) within Linear. I thought I had a firm grasp before working at Courier, but I learned a lot more after working with the Lifecycle team. The key to breaking down tickets is to be able to think about every single detail alongside engineers. Being in a small group while doing this was super important, because each individual helped bring up a very important perspective on how to break down tickets. 

During my internship, Seth (Chief Technology Officer), Suhas (Senior Software Engineer), Christian (Software Engineer) encouraged me to speak to the Developer Experience team at Courier and show them our project. The main goal behind this was to test to see if the UI/UX of Preferences was intuitive, if the design made sense, and if the Developer Experience team understood the goal behind this product feature. I prepared a slide deck explaining our project in its entirety. This was a great experience because it helped me prepare on how to **sell Preferences to our customers**. Giving insightful presentations about products and **“selling” your product to customers is such an important and overlooked skill for product managers**. Speaking to folks internally helped me practice and refine this skill, as well.. 

## How did I solve the problem? 
Before V4 Preferences, customers weren’t given the option of choosing what content they’d like to hear about, and how they’d like to hear about it. With V4 Preferences, users now can voice their opinions on both of these matters. This new product feature makes it possible for customers to choose what they like, and want to hear about. Specifically through their channels preference.

Gone are the days of inbox cluttering and customers becoming aggravated with the amount of notifications they receive. Preferences minimizes the frustration that end users experience with their notifications. 

*Want to apply for a role at Courier? Check out our [careers page](https://www.courier.com/careers/). To check out what Denis helped build in action, request a demo [here](https://www.courier.com/request-demo/) and ask to see the Preferences feature.*


Female manager and male intern standing in front of a machine

PM internship with Courier

This post will cover Denis’ workflow from planning to execution around the Preferences project as well as his experience working with the Courier team. 

Female managers and male intern standing in front of a machine where intern is learning how to use it

Build your first notification in minutes

Build your first notification in minutes

Platform

Use Cases

Explore

Company