Notification management - Don’t underestimate its importance and complexity

With the rise of digital platforms and marketplaces and the gig-economy as a whole, applications send more and more notifications to their users. These notifications can be a very helpful tool for calling users to action and driving engagement on the platform but can also lead to notification fatigue (especially as all digital platforms send dozens of notifications). A good notification strategy is therefore essential.

At the same time, setting up the tooling to support this notification strategy is also of upmost importance. Such tooling should be able to implement the different features of a good notification manager at a low cost.
Unfortunately most firms still build such a notification manager from scratch, resulting in a poor result (in terms of configurability, intelligence and usability) and hundreds of mandays spent on it.

It is therefore better to work with a tool which manages all aspects of such a notification manager. Unfortunately, in the world of operational messaging (contrary to the world of marketing related messaging, i.e. campaigns) there are very few players offering such a tool (even though every application and digital platform needs to handle this). Although there are many SaaS platforms (like SendGrid, Twilio, Amazon SNS…​) offering part of the required features, it is hard to find a tool that provides all required functionalities (one example is Courier - https://www.trycourier.com/, but this is quite unique in its segment).

But before diving into the features of such a tool, it is important to define what we mean with a notification. A notification is any message to a user (independent of the type of message), which informs the user about a specific event and ideally calls him to action (to do something on the digital platform).

In order to determine the required features of a good notification manager, it is best to describe the lifecycle of a smart notification in a notification manager:

• Step 1: called the notification manager with a user identifier, event type and potentially variables (content) to be included in the notification messages
• Step 2: try to map the event type to a notification template
• Step 3: retrieve the user details for the provided user identifier. This consists of the user’s language, email address, phone number…​, but also of the specific notification configuration of the user (i.e. user might have disabled specific notifications or enabled/disabled certain notification output types).
• Step 4: determine based on a set of rules if a notification should be sent out or not
• Step 5: determine based on a set of rules which output channel(s) should be used to send the notification to the user. This step is very important to avoid notification fatigue and maximize user engagement.
• Step 6: retrieve for each output channel the required API tokens to call the output channel
• Step 7: select the right template based on the language and output channel and replace the variables in the template (with the provided data in step 1).
• Step 8: call the output channel with the enriched template, API tokens and user address. Different output channels should be supported, like SMS, mail, internal notifications, mobile push notifications (i.e. notification showed on mobile dashboard even if application is not open) and a chat-messenger tool (such as Slack, Microsoft Teams, Mattermost and Facebook Messenger),
• Step 9: check the reply of the output generation. If the output failed, execute a failure-process (e.g. retry or divert to another output channel)
• Step 10: track the response to the call to action in the output message sent to the user (in order to monitor the effectiveness of the notification).

All those steps should be supported in an easy, flexible and intelligent way by the notification manager tool. This results in following functional features:

• Expose an easy and well-documented API to trigger the notification manager. Note that in above flow the selection of which user(s) should be triggered is done outside the notification manager, but we could consider this also part of the notification manager tool.
• Manage a look-up table between event types and notification templates.
• Keep track of event types, which cannot be mapped to notification templates, so that missing notification templates can be easily added and associated events can still be recovered when notification template is created.
• Integration with different user management tools, in order to query all important user data. A good notification manager should also be able to cope with different output addresses per user (e.g. different mail addresses), the possibility to work with back-ups and work with group boxes (e.g. group email address).
• Management of notification preferences, i.e. enable/disable notification types, manage allowed output types per notification type, manage specific restrictions and filters per notification type…​ This feature should also manage the default values for these preferences in case of a new user.
• Management of inter-dependencies between notification types, e.g. only send out notification type as soon as other notification type has been sent out (guarantee order), don’t send out a notification type if other notification type already sent out to user, allow to filter out a notification if time to previous notification too short…​
• Determine notification output types via available output types, user’s notification preferences, user’s current state (e.g. when user logged in, better to send notification only via internal messaging box in the platform and not via email, SMS…​), user’s engagement history for different output types…​
• Selection of right notification template and replacing variables in it. This can be a simple textual find/replace, but also more complex rule-based substitutions can be envisaged.
• Standard integrations with different output generation applications and SaaS platforms (such as SendGrid, Twilio, MailGun, MailChimp, CM Telecom, Slack, Microsoft Teams, Facebook Messenger, Firebase…​)
• Tracking and monitoring of engagement for different output types (read/unread, call to action executed or not…​)
• Reverting unread notifications, which are no longer relevant, e.g. when read via other channel, when already notification generated which makes the previous one obsolete (e.g. because further in workflow process) or when expired (it should be possible to set an expiration time per notification).
• Tool for managing notification templates, with possibility to manage different languages, different output types, include variables, possibility to define certain rules (e.g. certain blocks of text to appear or not or change, depending on variable value) and add call to action buttons/links.
• Tool for managing all rules for accepting/rejecting notification and selecting output type(s)
• Tool for managing notifications, e.g. bulk updates to mark as read or remove
• Tool for sending out ad-hoc notifications, allowing to send a custom message to a specific audience.
• Tool for searching historical notifications (i.e. per user and per output type) and tool for searching ad-hoc notifications (overview independent of user and output type).
• Tool for managing API keys for integration with different platform to generating outputs. These APIs keys will be environment specific and also tenant specific (if multi-tenant platform).

Apart from these functional features, a good notification management tool should also support multiple non-functional features, such as

• Security: as the notification manager handles important communication with users, it should be very well protected as when hacked, it can expose confidential information, but also allow hackers to send all kind of messages to users (as if the platform would send them).
• Scalability: a notification manager should be extremely scalable, i.e. not only to support fluctuations and growth in the business and new platform features (resulting in new notifications), but even on a stable platform with a stable business, the notification manager will be confronted with very spiky loads (e.g. a batch processing resulting in the creation of thousands of notifications in parallel).
• Performance: a notification manager should have a very low latency, especially the handling of the API call to generate a notification (as the calling process will probably make a synchronous call for this). To keep the latency low, the notification manager will typically work asynchronous internally, i.e. queue the API call for asynchronous further processing and immediately reply to the API call.
  Furthermore for internal notifications, a mechanism of web-sockets and/or web-hooks will need to be foreseen to rapidly inform the platform that a new notification is available for an active user. This avoids the platform message box to poll on regular intervals, which results in higher latencies and lots of unnecessary calls.
• Auditability: every notification and even every step in the notification manager (see above) should be audited, so that easy debugging and auditing of issues with notifications can be done. Note that the notification messages will typically contain personal information, meaning that special measures should be taken not to expose this logging and audit information without proper security.
• Environment management: as DevOps results more and more in large sets of automated tests executed continuously, it is important to avoid sending out automatically emails/sms’es from test environments. The notification manager tool should therefore support options like disabled/enabling specific output types per environment, managing white and blacklisting for specific output types per environment, automatically adding an indication of environment in output messages, when not generated in production environment…​
• Resilience: the notification manager should be highly resilient. This means it should be able to queue notification requests in case of unavailability, support retries for output generation and support switching to other output types, when a specific output type is not available.

The above shows that managing notifications smartly is a considerable effort and should therefore not be underestimated. It is therefore recommended to make a maximum use of different tooling available in the market (both open-source and proprietary), rather than reinventing the wheel again in your organization.

Good notification management will however become crucial, when static overviews on different websites (e.g. financial overviews in banks and insurance companies or invoice overviews on telecom-websites) are gradually replaced by feeds (cfr. social media feeds), which provide you with an actionable insights on a continuous basis and are driven by notifications.