DEV Community: Nick Gottlieb

The Importance of a Future-Proofed Multichannel Notification System

Nick Gottlieb — Thu, 01 Sep 2022 17:08:13 +0000

Product notifications are a mission-critical component of your product that can’t be left to chance. However, notification channels are ever-evolving, and you need to keep up in order to reach users when, where, and how they prefer to be reached.

A future-proof multichannel notifications strategy helps you stay in touch with your users without coming off as intrusive, non-responsive, or antiquated.

What Is a Multichannel Notifications System?

A multichannel notifications system is designed to seamlessly route and deliver messages about product-related events to users across multiple channels and providers.

For companies that require a detailed and wide-ranging strategy to reach customers and potential users, a multichannel notifications system can help your company reach out to users in the way they prefer to be contacted. One of our clients, Bluecrew, a W-2 staffing platform that connects hourly workers with employers, recorded a 55% improvement in job application rates after scaling their notifications infrastructure with Courier.

With multiple communication options, businesses need to think about how they’ll communicate different events to their users, including:

Transactions: notifications that provide a summary of transactional updates
Alerts: notifications that require high assurances of deliverability and visibility
User activities: notifications that update users about key activities within their accounts or profiles
Required actions: notifications that proactively let users know when action is needed
Digests: notifications that deliver a dynamic summary of events To do notifications well, a company/product requires a multichannel notifications strategy that can adjust with the times.

Traditional Approaches to Multichannel Notifications Systems Fall Short

There are two traditional approaches to managing the notifications strategy for your apps: limited channel notifications and custom channel support.

1. Static and uncustomizable approach

This is a notifications strategy that supports a handful of channels that are the only means of communicating with users, irrespective of the user’s needs or preferences. A strategy that supports a limited number of channels is common in legacy solutions with ancient codebases that are best left undisturbed.

However, many newer products and services might unwittingly end up with a limited number of channels after a few years. Sometimes, product managers don’t consider how they’ll support notifications until the last minute. Then you are forced to choose whatever notification channel seems to work best at that time. The challenge with this approach is that you may never quite get around to introducing new channels, and it becomes impractical to make changes as your codebase grows.

In contrast, a multichannel product notifications strategy that begins during product development allows you to bake agility into your plans to add new channels over time.

2. Customizable, yet unscalable Approach

This is a notifications strategy in which the company actively works to support new channels as needs arise. This custom-channel notifications strategy is especially common with startups because they tend to move fast. Many startups, for instance, adopt the blitzscaling product development approach that prioritizes speed over efficiency. In this case, you’d probably lean toward writing code to support new channels as the need arises instead of thinking strategically about how to manage notifications in the future.

In the early days, the development team might power through the night or weekend to update your code so it can support a new notification channel, and it’s common to do this every time there’s an additional notification channel that needs support.

While this ad-hoc approach might work in the short term, it eventually becomes unsustainable as your business grows. As your product development process matures, decision-making requires input across cross-functional teams. It’s not as easy to adapt on a whim.

A Future-Proof Notifications System Adapts to Changing Communication Preferences

A notifications strategy that takes into consideration that we live in a multichannel world is future-proof. It is designed to adapt to the dynamic needs of modern communication without being slow, expensive, or outdated for your stakeholders.

A future-proof multichannel notifications strategy should let you notify users across channels, integrate with your existing tech, and reroute messages to different channels, all while being easy to use and scaling with your company.

Enable Notifications Across Multiple Channels Today

A multichannel notifications strategy lets you switch across channels to meet the needs of your users.

For instance, SMS is a popular notification channel in the United States, but there’s a strong preference for WhatsApp in emerging markets. For example, 96.4% of Brazil’s digital population, 95.4% of South Africa’s digital population, and 95.2% of the digital population in Argentina actively use WhatsApp monthly.

Similarly, WeChat is the leading communication channel in Asia with 1.26 billion monthly active users, and emails seem to be the preferred communication channel in Europe with 72% of respondents preferring emails over WhatsApp, SMS, or other communication channels. Your product notifications system must be robust enough to deliver notifications across all these channels.

Deliver Notifications Across Multiple Providers on the Same Channels

You also need to be able to pivot the delivery of notifications through different providers within a channel as providers compete on features, pricing, and other metrics.

The benefits of being able to integrate with multiple providers accross a notifications channel include having a fallback option to ensure delivery of one provider has a downtime. Another benefit is that you might be able to shop around fo the best price per message based on the price offering of different providers in different countries.

Therefore, you may want to be able to integrate with the following providers (and potentially more) across all the communication channels.

For emails: SendGrid, Mailgun, Amazon SES, SparkPost
For SMS: Twilio, MessageBird, Plivo, Telnyx
For chat: WhatsApp, Microsoft Teams, Slack, FB Messenger
For push: Firebase, OneSignal, Airship, Expo

Route Notifications Across Channels and Providers

The preferences and needs of users are dynamic; therefore, users who only want email notifications today might later decide they want push notifications.

The challenge with changing user preferences is that notification formats differ across channels. For instance, a notification requiring a user action sent by email needs a button, whereas the same notification sent as an SMS needs a hyperlink.

Make It Easier to Expand to Future Channels

Your product notifications strategy should enable forward compatibility to integrate with new channels and providers as they emerge.
Right now, Zoom and Microsoft Teams are the leading business communication tools, but that could change in five years; after all, Skype used to be the standard some 10 years ago. When developing your product notifications strategy, you should insist on simple, elegant, and potentially modular code that can be easily updated to support new channels.

Scale Effortlessly for More Users and Messages

As your business grows, your notifications strategy should accommodate your company’s size, from startup to enterprise and beyond. For instance, Gojek, a transport and logistics company in Southeast Asia, says it delivers more than 1 million push notifications per hour.

While your products may not need to send 1 million notifications per hour, you need to think about how the architecture of your product notifications system is designed to initiate, send, and deliver (and, where necessary, store) thousands of notifications as easily as it handles hundreds of notifications per day.

Enhance the Agility of Your Product Notifications Strategy with Courier

Building a custom multichannel strategy that adapts to a multichannel and fast-changing communication infrastructure is slow, expensive, and frustrating. Courier is on a mission to improve software-to-human communications with APIs. Courier helps you handle the notifications experience in your products, so you can focus on building your business.
Courier empowers you to future-proof your multichannel product notifications strategy with shortened development time, dynamic templates, and analytics.

APIs Shorten the Development Time and Costs

Courier shortens the time it takes to build a multichannel notifications strategy by providing you with APIs and SDKs, so you don’t have to start writing code from scratch. Our APIs can be integrated into all communication channels, from push to emails, and you can get support for more than 60 providers in a single API. Courier’s APIs also handle user data, templates, preferences, and message orchestration for a seamless product notification experience.

Additionally, we provide SDKs for all major languages to enable you to implement geographical-based localization in the delivery of your notifications.

Templates Make It Easier to Add More Channels

If you develop your templates manually, it might be difficult to manage the different variations of the templates as you add new channels and providers. Courier’s templating system has an omnichannel architecture. Courier Studio supports drag-and-drop designs, and you can use JSON-based templates to produce templates efficiently. Courier automatically generates notification templates that fit the format of each delivery channel before routing the messages through the right provider(s).

Analytics Improves the Notification Experience for Your Users

Courier is also outfitted with analytics that helps you understand the notification experience of your users. Visibility into the quality of their experience also provides you with insights on how to optimize the notification experience across all the channels and providers you support.

Scale Your Notifications System Across Channels Effortlessly

Courier’s modular model enables you to add new channels, replace providers, and route messages across channels in a unified system. Courier also functions as a low-code solution. So anybody on your team with minimal technical skills can add channels in minutes without a developer or knowing how to write code.

Are you a PM who needs to establish or improve their app’s notification system? Check out our ebook about what it takes to build a great notification system or just learn more about Courier by scheduling a demo.

Announcing Courier Automations: Application Logic for Notifications

Nick Gottlieb — Fri, 03 Jun 2022 21:35:42 +0000

We’re excited to announce a powerful new feature for the Courier platform: Courier Automations. Courier Automations is a toolset that includes both an API and a visual builder that allows anyone to easily configure logic for notification workflows. Need to send a reminder to class attendees 10 minutes before the class starts? Need to page an on-call engineer on multiple channels until they respond? These use cases and more can be achieved quickly and easily with Automations.

Why we built Automations

As developers, notifications are the primary way that the applications we build communicate with our end-users and the use cases vary widely. Some use cases are very straightforward and simply require that a single message goes to a single user once. Many notifications however require more sophisticated orchestration in order to deliver the desired user experience. Most developers today end up building a separate service to manage this logic. This results in additional infrastructure and development overhead and often in a less than ideal end-user experience.

We built Automations so that developers can deliver the ideal notification experience without needing to build and maintain yet another service.

What are product and engineering teams doing with Courier Automations today?

While today marks the official release of Automations, many of our customers are already using Automation to power key parts of their product experience.

The engineering team at LaunchDarkly, a feature management platform, uses Automations to define the logic for notifications associated with approvals for their customers' feature releases. Any time approval is requested or granted, an Automation is triggered to ensure all the relevant stakeholders are alerted. You can read more about their use case here.

Officevibe, which is an employee experience platform, regularly sends out Slack notifications on behalf of their customers asking employees to complete a brief survey. Their engineering team utilizes the Automations API to create lists of users for whom the Slack survey could not be delivered and send them an email survey instead.

For Yoga International, an online Yoga platform, it's essential that they deliver a seamless experience to their customers from the time they register for a live class through to the start of class. Their engineering team utilizes the Automations API to send timely reminders to class attendees for each live class that happens on their platform.

“Meetings Reminder”

Let's build a meetings reminder that sends an email reminder 10 minutes before the meeting and a link to the meeting notes two hours after the meeting.

Design the Messages:

Log into Courier and navigate to the Notifications Designer
Design an email reminder that will be sent 10 minutes before the meeting with the Gmail provider (or any email provider of your choice)
Access the template ID in the settings of that notification and save it for future reference
Design an SMS reminder that will be sent two hours after the meeting with the Twilio provider (or any email provider of your choice)
Access the template ID in the settings of that notification and save it for future reference

How To Create an Automation Using the API (Node.js Example)

Within your Node.js app, install node-fetch npm install node-fetch
Navigate to the Automations API Reference and copy the starter code
Add an automations object with an array of objects called steps

"automation": {
      "steps": [
        {
          "action": "send",
          "template": "template_id",
        }
      ]
    },

Automations API Reference

Automations Docs

For this example, we will need three steps: send, delay, and another send. The first send step will send the 10 minute reminder. The delay step will wait for two hours after the meeting. The third step will send an SMS with a link to the meeting notes.

"automation": {
    "steps": [
      {
        "action": "send",
        "template": "template_id_1"
      },
      {
        "action": "delay",
        "duration": "130 minutes"
      },
      {
        "action": "send",
        "template": "template_id_2"
      }
    ]
  },

Update template_id_1 with the notification template from Step 3 of “Design the Message” and update template_id_2 with the notification template from Step 5 of “Design the Message”
Update the brand and recipient attributes with your preferred brand and recipient IDs
If your steps reference any Notification Templates, update the ID template attribute
Run your code to trigger the Automation

// Dependencies to install:
// $ npm install node-fetch --save

const fetch = require('node-fetch');

const options = {
  method: 'POST',
  headers: {
    Accept: 'application/json',
    'Content-Type': 'application/json',
    Authorization: 'Bearer replace-token'
  },
  body: JSON.stringify({
    "automation": {
      "steps": [
        {
          "action": "send",
          "template": "template_id_1"
        },
        {
          "action": "delay",
          "duration": "130 minutes"
        },
        {
          "action": "send",
          "template": "template_id_2"
        }
      ]
    },
    "brand": "W50NC77P524K14M5300PGPEK4JMJ",
    "template": "EXAMPLE_NOTIFICATION",
    "recipient": "8ec8c99a-c5f7-455b-9f60-8222b8a27056",
    "data": {
      "name": "Jane Doe",
      "age": 27
    },
    "profile": {
      "phone_number": "2025550125",
      "email": "hello@example.com"
    }
  })
};

fetch('https://api.courier.com/automations/invoke', options)
  .then(response => response.json())
  .then(response => console.log(response))
  .catch(err => console.error(err));

Check the Datalog for delivery status and error messages

How To Create An Automation Using the Studio

This example demonstrates integrating an API V2 notification send call (Step 5 of "Design the Message").

Navigate to the Automations page
Create an Automation Template from scratch
Add a send step and select the “10 minute reminder” for the Notification
Add a delay step and update the length to 130 minutes
Switch over to code mode (top right, under the the “Publish Changes” button) and add an API V2 notification send call for the SMS with a link to the meeting notes

{
      "action": "send",
      "message": {
        "to": {
            "email": "example@email.com"
        },
        "content": {
            "title": "Meeting Notes",
            "body": "Link to meeting notes: ..."
        }
      }
    }

This step can be done within the designer by following Step 3

Select a trigger for the Automation (if no trigger is selected, the Automation can be triggered manually with a curl command)
Publish changes to save your Automation
Create a Test Event to test your Automation

{
  "data": {},
  "profile": {
    "email": "example@email.com",
    “name”: “Your Name”
  }
}

Invoke your Automation in the Designer or copy the starter code and run it in a terminal

Getting Started

Sign up for a free Courier account to get started with Automations. Courier’s Free Tier includes Automations and up to 10,000 notifications per month.

Building Product Notifications That Users Love

Nick Gottlieb — Mon, 11 Apr 2022 21:30:14 +0000

Product notifications should never spoil a user’s experience—they should contribute to it. Otherwise, users are prone to turn off the notifications. According to Statista, 39% of smartphone users who receive too many notifications turn them off in response.

So how do you create product notifications that delight a user no matter how harried? Consider your users and their many different experiences as you design and build your product, not after.

In other words, your product should define the notification experience.

Notify Intelligently

Simply put, notifying your users intelligently means serving them the right content, in the right channel, at the right time.

Let’s say you work for a large airline and are currently building a mobile app to serve your travelers. Some information, like gate or flight time changes, must be served in real time to a user. Considering this scenario in the design and build phase allows developers to understand the right content, in the right channel, at the right time.

Let’s say the real-time information our user needs is a gate change. Our user is hurrying through security and stressed to the max. A real-time push notification and or text message is probably the best way to send their gate details without adding more stress to an already stressed traveler.

In our scenario, a push notification or an SMS at the right moment is the difference between a missed flight and a user who’s bound to churn and a happy traveler who will probably be a long-term user.

However, there’s a fine line between delighting and spoiling a user experience. Push notifications and SMS are best for urgent updates like delays, cancellations, or gate/terminal changes. Travelers trying to get through security with their sanity intact do not need real-time push notifications or SMSs about promotions or travel deals—that would be an example of the wrong content, in the wrong channel, and at the wrong time.

Offer Notification Granularity

Let’s be real—today’s users expect to maintain control, so offering notification preferences isn’t really an option anymore; it’s a must-do. Offering users control over how an app notifies them pays off exponentially in a user's lifecycle with the app.

Granular permissions allow users to opt-in and opt-out of notifications that aren't time-sensitive or essential to the users' end experience. For example, when a user installs our fictional mobile travel app, they will be delighted to see that they have the option to curate their preferences around flight reminders. You might not let them opt out of gate or terminal changes, but you do let users choose whether they want seat upgrade or flight deal notifications.

Once our user is safely through security and relaxing at their terminal—browsing options for seat upgrades or a deal on their next trip is delightful. Whereas notifying our users as they struggle to get to their terminal with dings and buzzes reminding them to UPGRADE!—spoils an already stressful airport experience.

When developers don’t consider notification as an extension of the product and don’t offer preference controls to their users, they risk spoiling their users' experiences and losing them. In fact, research shows that 40% of users will abandon an app for a competitor after a bad experience.

Know When to Batch

To put it simply, don’t spam your users! Whether they're running late on a Monday morning or sweating their way through airport security, people rarely appreciate a stream of notifications.

Have you ever collaborated with someone via Google Docs? The tool is pretty smart about notifications. Instead of sending a separate email for every comment someone leaves, Google Docs bundles these notifications into a single email.

Be like Google Docs. Instead of overwhelming your web users with notifications, group them into batches that you send just a few times per day.

Think of our first user taking a moment in the car to silence their notifications indefinitely and probably forever, and instead, give users a reason to stay. Android 7.0 shows developers when and how to create and send group notifications so that you're not inadvertently spamming your users away.

Be Helpful

Serving your users’ information at the right time is only half the battle. Knowing what details your user needs is another.

Let’s return to our fictional user relaxing in the terminal, waiting patiently for their flight (and looking forward to their upgraded and better seat). Suddenly, they receive a text message alerting them that the flight is canceled. A total bummer.

But what if the text message also said: “click here for rebooking options”? Less of a bummer and actually kind of delightful.

When notifying users, provide all of the information they need to help them achieve their end goal.

Use Notification Analytics

To constantly provide and optimize a better user experience, engineers and developers need to build their products with visibility. Visibility means being able to see and understand how users receive and/or react to your notifications.

If a product engineering team can’t see how notifications are performing, they can't optimize their user experience. Once the product is built, engineers and developers should have a means of analyzing notification metrics, from deliverability open rates to engagement rates. Without this information, how will our fictional travel app know when it is the wrong time to send a push notification?

Moving Forward with Notifications That Delight and Enhance UX

Understanding that your product will ultimately define its users’ notification experiences means your engineering team can implement these ideals as they build. This is the best way to ensure your notifications enhance and don’t spoil your users’ experiences. In a nutshell:

TL;DR

One universal rule that will never fail your app or your users: consider your users and their many experiences while you design and build your product—not after.
There are five ways to leverage notifications and make them core to your UX. Notify intelligently, offer notification granularity, know when to batch, be helpful, and use analytic visibility.
Read more about real-life start-ups leveraging notifications successfully and how they are doing it.
Or, try delivering in the right place and at the right time for yourself!

Organizing In-app Communication With Inbox Feed

Nick Gottlieb — Sat, 26 Mar 2022 22:51:44 +0000

Notifications—such as emails, SMS, or push notifications from an app—are a big part of daily life. Whether for work, fun, banking, or just to chat, mobile notifications tell us what we need to attend to and when. While some users like getting notifications so that they don’t miss out, others turn off most notification channels for the sake of peace. But if it’s your application, what can you do to make sure that you’re communicating effectively with your users?

Last year, Courier introduced the Inbox Feed, an in-app repository of the notification history so that users don’t miss out on any important information. In a notifications inbox, users can view all their notifications in one place. Having such a centralized repository for notifications makes it easier for users to tackle all relevant action items at once, reduces notification fatigue, and increases focus. Courier’s Inbox Feed implementation provides ready-made components that you can use and a scalable back-end API to power those components.

Read on to learn how exactly embedding an Inbox Feed into your application can benefit your users.

Why you need an Inbox feed

In this section, we’re going to talk about how an Inbox Feed can be a viable solution for users who have difficulties staying connected.

Dealing with notification overload

Most applications have more than one way of communicating with their users. Notification channels such as push, SMS, and e-mail are all point-in-time notifications. When they are sent out, a user might not be directly using the app or even available to attend to the notification. When the user does choose to review the missed notifications, they might have to check more than one channel, such as an email about a planned outage or push notifications about changes in status in the application. In that case, the user will have to pick the pieces up separately, by checking different channels, to stay informed. In the example of an email about a planned outage, they might forget about it completely and get frustrated when they can’t access your application. Separately, their email client might be filtering out certain messages so they might never have seen the email about an outage. Some users disable all notifications to avoid being overwhelmed by them, even if they specified contact preferences in your application. These users risk missing out on important information, and your product risks losing engagement with them.

This is why a central feed for notifications, inside your app, will be a huge improvement to users' experience with your application. With a notification inbox, users can control what they attend to and when. A historical notification feed takes the pressure off users to feel like they need to respond immediately. It can improve user engagement by giving them a sense of control over how they interact with your application.

Popular examples of historical notification feeds include Facebook’s News Feed and the notification history in Reddit or GitHub. In the widely-known Facebook News Feed, when a user enters the application, they can click on the notification bell icon to see a historical list of all events since they last logged in. These can include messages and comments to relevant pages and what their friends were up to. Reddit’s notification repository is similar: when a user enters the application, the notification bell icon is lit with a red circle and links to new messages, comments, and other relevant popular subreddits for the user to check out. In applications like these, when there is a lot of activity, a notification feed allows a user to see everything that has happened since they last used the application.

In GitHub’s case, the notification repository also includes notifications that depend on other user activity, such as assignments and review requests. Below is an example of the notification inbox on GitHub, which is accessed by clicking on the bell icon in the top right corner.

Effective distribution of information for collaboration

Effective distribution of information is important, especially in the case of B2B SaaS applications, where teams from different companies or different departments are often collaborating to work together on more than one project. Users need to understand the scope of each project’s status and who is doing what and when. In a business application like Asana or Trello, users can get notified of any activity on their projects by email and push notifications. However, it is still essential that they can see all such updates when they log into the application, such as mentions, conversations, deadline changes, and project changes. Without the Inbox page in Asana or Trello, it would be difficult for someone working on more than one project to keep track of these updates. Scattered notifications via email or push are not as efficient in distributing that information—especially for collaboration—as a notification inbox embedded in the app. Weekly digest emails are another option, but they are inadequate for teams working within strict deadlines.

Google Docs, for example, allows all users sharing a document to view all comments and suggestions via the Comments drop down menu, in addition to sending comments to the document’s collaborators via email. In the Google Docs interface, users can view current and past comments, and sort comments by status.

Smoothing workflow automation with notification inbox

For many B2B SaaS applications, automating a workflow is the core value the software delivers. Examples include team members receiving access requests, review requests, or other notifications requiring the action of another user. These teams need to function efficiently, within deadlines, and it is up to the design of the application to ensure that all relevant information is available as clear as possible and easy to visualize. A notification feed empowers a user to get an understanding of what’s happening overall in the scope of their projects and administrative requests and attend to them as necessary.

In early 2022, LaunchDarkly, a software feature development platform and one of Courier’s clients, decided to include the Inbox feature in its product. LaunchDarkly’s reasoning was similar to what we have outlined here: some notifications, especially those that require an action from another user, are too important to be overlooked. To avoid the uncertainty of a user missing an email or Slack notification and potentially delaying the development or approval process, the Inbox Feed makes all notifications ever-present and accounted for, every time a user logs in.

Below is an example of LaunchDarkly’s Inbox feed, accessed by the bell icon in the top right corner.

Implementing an Inbox Feed is faster with Courier

If you’ve decided to implement an inbox feed feature in your app, there are two main components that you need to consider: the front-end element responsible for displaying the notifications in the user interface, and the back-end system that handles the sending of the notifications and their read/unread status.

For the front-end, there are several open-source React libraries to choose from. At Courier, we recommend react-toastify. Alternatively, you could use a framework like react-hot-toast or notistack.

On the back-end, you can integrate your own notifications provider with the front-end components, or you can use Courier Push to power your inbox feed—and get additional features. For example, Courier Push takes care of read status: if a user already opened an email that was sent through Courier, the Inbox will show the respective notification as read. Courier’s API gives you the power to make a single function call that can notify a specific user via any already configured channel. A user can also delete notifications to keep their feed organized and uncluttered.

If you decide to build the back-end yourself, consider how you will integrate various channels and how you will scale the back-end for growth. This is ultimately a build-or-buy decision: are you ready to spend resources on building this feature, or do you prefer to use an already reliable and easily integrated service with Courier? If doing it yourself, you’ll need a developer dedicated to fixing issues, for example, if an error or delay occurs and the feeds do not update by the time a user logs in. As with all notifications, it’s vital that an inbox feed is reliable and stays relevant for its users or it risks its actual usefulness as a feature. Check out our other articles on building a routing engine and scalable and reliable systems for what you need to know if you’re thinking of making the build yourself.

With Courier Push, you would use the configuration studio to customize the Inbox feature for your application, pictured below. Or, if you prefer, you could customize the Inbox feed with code.

To get a feel for setting up an Inbox feed for your application, try it out on this Courier-powered playground. You can see our example below. The first image shows the notification alert as we had entered it. The second image illustrates the actual Inbox view.

Ready to give the Inbox a try?

Notifications are integral for connecting with your users and alerting them to an event, or another piece of relevant information. But without a repository of the notification history, your application might be losing out on valuable engagement with your users or hindering timely collaboration between them. Our Inbox feature strives to improve user engagement and social collaboration within applications. We see it as a valuable tool that empowers users to take control.

Read more about how to integrate Inbox here. If you’re looking to learn more about the feature, check out our documentation.

3 Types Of User Communication APIs and when to use them.

Nick Gottlieb — Thu, 06 Jan 2022 21:12:21 +0000

As modern applications have become increasingly feature-rich and performant, user expectations are at an all-time high. Failure to communicate key information or displaying out-of-date information frustrates users and causes a loss of trust. Think about the last time you ordered something online: if you didn’t receive your order confirmation within seconds, you probably began to worry that something went wrong. Users require product transparency for consistent use.

Luckily for developers, a proliferation of new APIs have been developed to help provide features such as real-time order update emails, push notifications based on in-app activity, or live chat with sales and support. Communications APIs are becoming increasingly specialized, with each type being more or less suited to certain tasks.

If you’re an engineer who’s been tasked with planning out your application’s communication strategy, this post will help you map out the landscape. You’ll come away understanding the three core types of user communication APIs and in which circumstances you should use them to create the best possible end-user experience. We’ll also show you how using the right APIs in the right places will streamline your own day-to-day work.

Let’s get into it!

Planning Your Communications API Strategy

The best outcome any engineer can hope for is that your communications strategy is so smooth, it isn’t even noticed. For the end user, it just works exactly when it’s supposed to work, the way it’s supposed to work. For your own internal teams, everyone has the ability to craft the messaging they need and send it when they need, without unnecessary bottlenecks that can often impact your own engineering time.

In a marketplace application, for instance, users need to get an automated push notification or email every time someone comments on an item they’re selling. The marketing department also wants to send email campaigns to everyone who has purchased an item in the past six months to let them know there’s a sale coming up. When a buyer’s checkout fails, they might need to message your sales or support team to get help and complete the transaction.

All of these are very different examples that will need to use a different type of communications API to get the job done.

Exploring The Three Types

Communications APIs are segmented not only by the functionality they provide and how immediately they need to respond to user actions but also often by which teams at the company will need to use them to send messaging.

App-to-user APIs are highly customizable, instant communications sent by engineering as integral parts of the application experience, such as push notifications about likes or comments. Brand-to-user APIs collect data and give the company, particularly marketing and product teams, the ability to send users targeted messages individually or en masse. User-to-user APIs facilitate live chat either among app users or with someone at your company, such as sales or support.

Let’s discuss the strengths and weaknesses of the three types of APIs, and see some commonly-used third-party providers for each.

App-to-user APIs

App-to-user APIs are transactional messages that are embedded into the application code. These APIs are often the most mission-critical of the three, as they form a core part of the application experience. For instance: your rideshare has arrived, your order was received, you have just been added to this chat room, here is your one-time password for login. These types of communications tend to be time-sensitive and are designed to send immediately when the trigger events occur.

A robust App-to-user API will provide multi-channel communication (email, SMS, and push notification), complex routing, and easy opt-in and opt-out for users. Most can be heavily automated as well. For instance, when a new user is created via Auth0, a welcome push notification can be automatically sent.

App-to-user APIs are typically instrumented and used by engineering teams. Companies who have the resources may choose to build their own App-to-user API infrastructure, which we have a guide on how to do here. Courier also provides a ready-to-use App-to-user API infrastructure.

Brand-to-user APIs

Brand-to-user communication happens any time your company has a message for a specific group of users. Maybe the product team noticed that a user got partway through the sign-up flow but didn’t hit the “complete” button. Maybe marketing wants to tell everyone in New York about an upcoming in-person event.

Braze and Customer.io are two examples of out-of-the-box Brand-to-user APIs. Engineering implements API calls in the application code that log information about user behavior, which then gets sent to a separate dashboard other teams at the company can access. Anyone on those teams can then use that data to craft and send messages to specific subsets of users. For instance, users who didn’t complete the sign-up flow, or who live in New York. Brand-to-user APIs save engineering time because, once the initial API calls are instrumented, any team who needs to send campaigns or needs to access that data can do so easily and independently.

While Brand-to-user APIs make it easy for anyone at the company to send messaging to users, they typically aren’t configurable enough to power core parts of the application experience. Messages can go out minutes to hours after user criteria for the message have been met. There can also be implementation delays any time you want to send messages based on a different set of criteria than you were using before—new API calls in the app mean the data needs time to populate before they can be used.

While this trade-off is often worthwhile for marketing and product communications, App-to-user APIs (discussed above) are a much better fit when you need fine control over messaging content or timing within engineering.

User-to-user APIs

User-to-user communication APIs facilitate active conversations among two or more individuals—either between a user and someone on your own internal staff or from one app user to another.

Support tickets, for instance, are a type of User-to-user API, as are live chat boxes that let customers have direct conversations with your support or sales teams. Likewise, two users in a marketplace might need to message each other to offer bids or send along shipping information. While these are possible services to build out in-house, most companies opt to save time by going with a ready-to-use SaaS solution, such as Intercom, Zendesk, or Sendgrid.

Conclusion

Most applications will use more than one type of user communications API for different parts of the user experience. Your application may very well use all three!

App-to-user APIs provide part of the application’s core functionality. These APIs are highly customizable and provide instant user communication that is tightly coupled with your application code. Marketing and product teams will often want a Brand-to-user API implementation that makes it easier to see user data and send updates to users. User-to-user APIs give customers access to back-and-forth communication either among each other, or with company support or sales teams.

When you’re thoughtful about your communications strategy, you can create a seamless experience for users while also enabling everyone on your team to save time and do their best work.

Read on for more information on building user communication API infrastructure:

Illustration by Rebekka Dunlap

APIs: The Prefabrication Of Software

Nick Gottlieb — Tue, 12 Oct 2021 17:31:13 +0000

Whether it’s for building a company, monitoring the news, or even making a grocery list, software penetrates every part of the modern western lifestyle. The demand for software far exceeds what developers (and the tech industry as a whole) are capable of supplying from scratch. In order to keep pace with demand, our industry has been increasingly shifting towards a ‘prefabrication’ model of software development via the utilization of third party APIs. While this trend has been in the making for 10 to 15 years already, the market is poised for continuous aggressive change in the coming years as well.

We can say this with confidence because history tells us so. At the turn of the century, when large-scale construction was beginning to become common, constructing an office building or factory required bringing together a large group of expert craftsmen at a jobsite. Expert carpenters were needed to build the doors and framing, expert glass blowers for the windows, expert masons to cut and lay the stone, blacksmiths to create the steel structure, and so on. As the 20th century progressed, and demand for construction skyrocketed, various forms of prefabrication were developed in order to make construction faster, cheaper, and more accessible. For high-end, custom buildings, the prefabricated parts components could be limited to the windows, doors, and HVAC system while at the other end of the spectrum entire buildings can be erected in days out of completely prefabricated components. In fact, McDonalds has been known to complete a building in mere weeks this way.

The evolution of software development has followed a similar trajectory, with APIs serving as the prefabricated software that companies are leaning on to build software faster and more cheaply than ever before.

How APIs Came To Be

In many ways, Amazon pioneered this ‘prefabrication’ mode for software developers when they released Amazon Web Services in 2006. By making Amazon’s excess compute resources available to other software companies to use in the form of APIs, the capital and expertise needed to build a software company was reduced dramatically. Do you want to spend your technical resources trying to scale and manage infrastructure better than Amazon? For the vast majority of companies the answer is no, they’d rather spend those resources focusing on the more specialized parts of their software, and that’s why AWS generated $46 billion in revenue last year.

Since AWS, hundreds of other API-as-a-service companies have emerged to help other software companies build faster and cheaper. Twilio came up for digital communication. Stripe was used for payments. Shopify was available for e-commerce. Okta became important for user authentication. Just these four companies represent over $350 billion in enterprise value and have laid a lot of the groundwork for this industry, but it’s still very early in this movement. There are still many parts of the software stack that have yet to be ‘prefabricated’ and millions of hours of development are still spent on building the same functionality over and over again when it would be far more efficient and lead to more innovation if those hours were spent on building unique value.

Build Vs. Buy Has Become An Important Decision For Developers

The rise of APIs-as-a-service is increasing both the prevalence and importance of the ‘build vs buy’ decision within engineering teams. Should we roll our own user authentication service or buy Auth0? Should we roll our own payments platform or buy Stripe? As my colleague Tejas controversially argued in his post, user authentication, payments, and notifications are three things that you should never build yourself. While many people did not agree with that particular thesis, the trend of engineering orgs evaluating API solutions in order to get their product to market faster is certainly growing.

What this means for engineers is that having the ability to effectively evaluate APIs and run a cost benefit analysis as opposed to creating a custom solution is becoming increasingly important. As a company that builds and sells an API, we see it all the time here at Courier. A software company, typically a medium to large startup, begins to run into some pain points around sending and managing product notifications. A decision is made to find a new notification service that meets their needs and tap a senior engineer to decide how this problem should be solved. He or she typically evaluates using Courier rather than rolling out a custom solution and then makes a case for which solution they think is a better fit to their team.

Having a good understanding of the currently available products and functionality offer, being able to effectively estimate the total cost of ownership for both an API solution as well as a homegrowth solution, and being able to effectively map out the integration strategy for API products are all skill sets that are becoming ever more valuable in both developers and engineering leaders.

The Developer As Artist

As APIs handle more and more of the monotonous and undifferentiated parts of the software stack, developers' time is being freed to be spent creating new, unique, and highly valuable product experiences. In the past several years we’ve seen brand new software startups take on challenges as diverse and complex as automating and streamlining the mortgage application process, building marketplaces for pretty much any good or service imaginable, democratizing the ownership of publicly traded stock, and much more.

As the proliferation of APIs continues, software development will be able to focus less on solving low level systems and infrastructure challenges and more on the creative side of product and customer experience. Of course, there will always be a place for the engineers who truly want to dig into systems challenges (someone does have to build these APIs, after all), but the engineer who is adept at leveraging APIs in order to deliver a more differentiated product more quickly will become increasingly valuable and sought after.

This Is Only The Beginning

The prefabrication of software via APIs is the next big wave of disruption in the software industry, and while it has already arrived, we’re only in the beginning phases. There are still hundreds, maybe thousands, of technical challenges that are repeatedly solved across nearly every software company or vertical that could be successfully prefabricated via an API. As slower moving industries such as insurance, healthcare, education, and finance become increasingly digital, additional API services will emerge to serve those industries. As digital regulations around privacy and security continue to mature, we’ll see more APIs focused at helping with compliance. The startup engineers of the future will either be building APIs to help other companies move faster or leveraging those APIs to take their own product to market.

How to Add a Notification System to your MVP

Nick Gottlieb — Fri, 09 Jul 2021 23:19:02 +0000

As a product engineer, you likely understand the value of incorporating notifications functionality into your Minimum Viable Product (MVP).

Here's what you can accomplish by building notifications:

Drive engagement. Notifications inform customers that there’s something going on in your application that’s worthy of their attention. Timely notifying your audience about valuable content or interactions with other users is great for building trust and engagement.

Enable user journeys based on asynchronous actions. If you don’t expect your users to always be connected to your app or service, notifications enable your users to stay plugged in without having to constantly check for updates in-app.

Support time-sensitive operations. Perhaps you’re planning on requiring two-factor authentication at login, or maybe you simply want to let account admins know each time somebody new first signs into their workspace. In both cases, adding real-time notifications can help call attention to time-sensitive details where needed.

At the MVP stage, developers focus on finding product-market fit for their venture. On the one hand, this means experimenting with functionality that’s capable of creating value. On the other hand, teams at this phase start requiring less and less time on every new experiment, before finding something that works.

In this article, we show you how to build a notification system for your MVP, in a way that both enables experimentation and helps you get results quickly.

Let’s dive in!

The main components of a notification system

We’ll start by reviewing a very simple notification system for an application:

mvp-stage notification system
Architecture diagram for a simple notification system.

This simple system, though functionally limited, still has certain key components that enable its extensibility to future use cases: a set of notification triggers, a central place for all notification-related decision logic, a simple templating system, and connections to various messaging providers.

Let’s walk through the components and show what a simple implementation for each part would look like in JavaScript. We’ll begin on the diagram’s right, where the elements are more specific, and will work towards the left, where components become more abstract.

Email dispatch via an email API

Sending an email through an email API is straightforward: we connect to an email provider using its JavaScript SDK, form the message with the parameters required, and then send the message.

In this example, we’ll work with AWS SES as the email provider—but you would get a similar result if you're working with another provider.

First, we’ll need to install the AWS SDK:

$ npm install aws-sdk

We can then use the SDK to send an email through SES:

// notify.js

var AWS = require('aws-sdk');
AWS.config.update({region: 'us-east-2'});
var ses = new AWS.SES();

function notify_email(subject, message, email_address) {
  var params = {
        Destination: { ToAddresses: [ email_address] }, 
        Message: {
            Body: { Text: { Charset: "UTF-8", Data: message } }, 
            Subject: { Charset: "UTF-8", Data: subject }
        }, 
        Source: "patrician@disc.world", 
  };
  ses.sendEmail(params, function(err, data) {
    if (err) console.log(err, err.stack);
    else     console.log(data);
  });
}

In this example, we send a text-only email and skip the HTML version. We hard-code the source address as we assume that all emails will come from the same sender on our side. All of these assumptions can be changed in the future as our product expands.

Message templates

We can now send emails, but it’s going to be unviable to handcraft every email at the various codebase locations from which notifications can originate.

Message templates are a pattern that lets you easily parameterize your notifications with user data. Here’s our simple templating “system”:

// notify.js

function template_activity(channel, props) {
    switch (channel) {
        case 'email':
            return `Hello ${props['first_name']}, there is an interesting post that you can check out here:

                            https://disc.world/activity`
    }
}

Instead of going with string literals, we can use more functional solutions like mustache.js once we need to send more complex notifications.

In the above example, however, we’ve generated just one template. Templates for HTML emails, push notifications, or chat notifications could follow in the same function.

Notification decision logic

With email sending and templates out of the way, we now need to make decisions on whether we should notify users about a given event. The simplest approach to this task is a function that switches between notification types based on the parameters being passed in:

// notify.js
function maybe_notify(event, props) {
    switch (event) {
        case 'activity':
            // todo: check notification preferences
            // todo: check unsubscribe list
            console.log('Sending activity notification to user:', props['id']);
            notify_email(
                'Something interesting on the Discworld!',
                template_activity('email', props),
                props['email_address']
            );
    }
}

Our function selects the right template and messaging medium based on notification type, and also creates a log message so that we can debug any issues.

You might not always want to notify someone of new activity, so we’ve added a few TODOs to check for preferences and monitor our unsubscribe list.

Notification trigger

Finally, we need to wire everything together and send an activity notification:

// notify.js

maybe_notify('activity', {
    'id': 123,
    'email_address': 'rincewind@disc.world',
    'first_name': 'Rincewind'
});

In our example, the function is accessible directly in our JavaScript file, but if you’re accessing notifications through various services, this might happen over an HTTP or RPC API.

Running the example

To run the example, we ensure that our AWS account is configured and then run node notify.js:

$ node notify.js
Sending activity notification to user: 123
{
  ResponseMetadata: { RequestId: '751ecac5-d140-4717-a06a-94b3b42d01ef' },
  MessageId: '010f017a15621a86-ac305fa4-919a-4178-8362-7faf64e10cc8-000000'
}

And we can see the resulting email in our email client:

The resulting email in our email client.

While this is a very simple notification system that’s quick to set up, it still includes key components that you'll be able to build on top of when your MVP moves forward to the next stage.

What should you leave out of an MVP-stage notification system?

With an MVP-stage system, the goal is to make your notifications sufficiently functional for all sides without over-allocating time to make that happen.

This doesn’t mean that you should save on error handling and unit tests, however. Our recommended approach for an MVP-stage notification system is to keep the initial amount of functionality that the system offers limited while keeping its quality high, following best practices, and thoroughly testing all code paths.

Let’s expand on that.

Features to exclude from an MVP

To help you decide which features should go into an MVP-stage notification system, think about what you’re trying to achieve with your MVP.

You’ve likely already defined one or more metrics for the MVP’s success (if you haven’t, you should consider doing so!). For a new product, let’s assume that you’re measuring the number of daily active users.

How do notifications tie into the daily usage metrics? If you build a good-enough notifications system, how will that help you achieve your goal?

In our example, a notification will likely be the mechanism by which your product’s users can learn about something that needs their attention. If they haven’t signed in on a particular day, a notification is the only way to alert them to the activity they missed. In such a scenario, we could very well attribute the sending of a notification to a direct increase in daily active users (DAUs).

Now, how you build your notifications will affect your system’s impact on DAUs. Going from zero notification channels (no notifications at all) to one channel (e.g., email) can significantly boost your MVP metrics.

But would adding a second channel (e.g., mobile push) make enough of a difference?

That depends. Your app’s functionality may rely on real-time interactions, in which case a push notification on the user’s phone will make a difference compared to an email notification that might get read later on.

But if you’re building a B2B application where synchronous action has less importance, then having email notification only will probably suffice.

Here are a few examples of features to potentially exclude from an MVP if they don’t directly drive the MVP’s metrics:

Additional notification channels.
Aditional types of notifications.
Non-essential efficiency and performance improvements.

What you shouldn’t skip even in an MVP system

Even if you’ve decided on the specific functionality that’s critical to your MVP’s success, there are still a few things that you should keep in mind for any MVP-stage system. Regardless of the MVP notification system you're building, here are some guidelines to keep in mind:

Item 1: Polished experience for a limited set of notifications. Typos in your notification templates; incorrectly functioning call-to-action buttons; email designs that don’t work on mobile—these are all issues that will affect the sentiment of your early users. Although you'll be working with a limited number of notification channels, the ones that you do select for your MVP should contribute to a positive user experience. Spend a bit of time on testing and validating (manually and/or automatedly) the look and feel of your MVP notifications.

Item 2: Right notification, at the right time. The reason why you’re building notifications in the first place is to alert your users to an event that merits their attention. It’s important to get the mechanics of your notifications right, especially when you’re only using one or a few notification channels in your MVP. Document the overall logic for when a notification should and shouldn’t be sent, and make sure that you keep this logic consistent throughout your application.

Item 3: Reliability and consistency. Few things are more frustrating than notifications getting sent inconsistently. If your MVP system accidentally skips so much as 10% of the notifications that should have been sent, your users might miss out on app interactions and eventually decide that your notifications “don’t work” and simply disable or ignore them. Building trust with your early users is critical, so consider implementing monitoring for your notifications system. You need to be able to identify issues before they can cause any negative impact.

Common gotchas when building MVP notification systems

By this point, you’ve hopefully settled on the functionality that you’ll include in your MVP notification system. Here are a few common pitfalls that startup engineers should avoid when building basic notification systems.

Shortcuts taken now can be painful in the future

While we encourage taking certain shortcuts in the MVP phase—like having an initially reduced number of supported notification channels, it’s important to consider how the choices you make today can impact what’s possible for your product down the line.

For example, modeling all of your messages around a particular email API can make it more difficult to change email providers or add SMS support in the future.

We recommend that you come up with your own schema for what a notification object should look like. Implementing this level of abstraction will make it easier to add other notification types in the future.

Remember that you’re serving multiple categories of users

Notification systems aren’t only used by your customers. You, as a developer, are also a user of the system. And if the system constantly breaks, your team will suffer setbacks.

Your content editors and marketing team will most likely want to change individual notifications and tweak the text. These colleagues might not have the technical know-how to edit the code base and submit pull requests.

When building an MVP system, reflect on how the notifications experience will look for all customer groups, both internal and external. The experience for each group doesn’t need to be perfect (and probably can’t be perfect in an MVP), but if you’re prioritizing one group’s experience over another, make this choice explicit and discuss it with your team.

You won’t go far without deliverability

Notifications that aren’t delivered do not fulfill their purpose and do not move your metrics in the right direction. Any operational issues with your notifications system can affect deliverability, but there are other factors to consider.

For email notifications, having the right DKIM and SPF records set up for message authentication can improve the likelihood of emails getting to your users’ inboxes.

For mobile push notifications, delivery may be prevented due to connectivity issues or the user’s device being off. Retrying a push message a few times if delivery fails can increase the rate of successfully delivered notifications.

Quickly build an MVP-stage notification system with Courier

Building an MVP notification system from scratch need not be overly complicated. We encourage you to think through the MVP metrics you're looking to drive with a notification system, and to understand which notification channels will be most relevant for your internal and external customers.

While you’re at it, why not check out Courier?

Courier provides a comprehensive, easy-to-integrate API that takes care of all notification types. Start with an MVP, and add more functionality later without locking yourself into a particular provider.