If you use LinkedIn, you've likely noticed that it sends notifications within in-app about various activities, such as connection requests or new messages, while also delivering these notifications over emails.
These email notifications might not be instant and can be delayed by 2-24 hours, customized based on user preferences, potential volume and the priority of the notification.
It also solves a crucial pain point for social media companies, where there are a ton of notification triggers happening through each interaction. This notification fatigue impacts the user experience, and hence is something to be solved sooner.
What is it, and how does LinkedIn and other SaaS tools achieve similar functionality to ensure users are appropriately notified, maintaining engagement with the product without overwhelming with too many alerts?
What is Channel Routing?
Channel routing involves directing notifications through various channels to ensure user engagement isn't hampered if a user is unavailable on a single channel.For example, Instagram provides an almost instant in-app notification when someone likes your post. However, if you remain offline for a certain period, say 6 hours, Instagram sends you an email notification with the same message. This is basic channel routing.On SuprSend, we have enhanced channel routing capabilities. Here’s how:
- Setting Order of Channels (Optimize On): In a multi-channel notification setup, you can specify the order of channels based on custom use cases. For instance, some SaaS platforms might prioritize cost-saving, so their order could be in-app inbox → email → SMS. Others may prioritize read receipts for notifications like OTPs/ verifications, with SMS/ email at the top of the list.
SuprSend can optimize this further by calculating the end-use cases. For example, if the business wants to optimize costs, our platform checks the costs associated with each channel and sets the priority order accordingly. - Time-to-Live (TTL): TTL is the total time a notification is live and attempted for delivery. If TTL is set to 6 hours and there are 3 channels configured, our platform divides the TTL by the number of channels, sending notifications at equal intervals. For example, the first notification at 0 hours, the second in 2 hours, and the third in 4 hours.
- This way, you only need to mention what is the time window in which you want an action on notification, and the workflow engine optimizes for that.
- Must Send To: This parameter instructs the workflow engine to send notifications to specified channels instantly, regardless of the channel order. some text
- For critical notifications like OTPs, sending them simultaneously via email and SMS ensures reliability, a practice common in Fin-tech companies to prevent failures in execution due to single-channel issues.
- Another crucial importance of this feature would be for notifications required to be stored for further bookkeeping. For ex, invoice or billing related businesses might need to store their notifications for longer period and hence channel which can support this, like email or in-app notification should always be set in the 'Must Send To' parameter.
- Success Metric: This defines the target user activity you want to drive with your notifications. Channel routing stops further delivery when the success metric is achieved. There are two types:
- Notification Status: Metrics like delivery, seen, or interaction/click status of sent notifications. For example, if the target is for the user to open the notification, set the success metric to Notification Status - Seen.
- Custom Event: Any custom business event in response to the notification. For instance, for approval, the success metric could be when approval / rejection action is taken.
- Override Channels: Users may have individual channel preferences, necessitating the need to pass these preferences in the event call itself. The Override Channels property allows including a channels array in the event property, ensuring personalized routing.
Implementing Channel Routing in a Social Media Application
We'll be demonstrating channel routing in one of our sample applications where we have installed SuprSend Javascript SDK for triggering events.
You can access the demo application and code here:
Github: https://github.com/SuprSend-NotificationAPI/social-app-react-app-inbox
Deployed Application: https://suprsend-notificationapi.github.io/social-app-react-app-inbox/
To illustrate, let’s define the code for a Comments event where the user inputs a comment, which is sent to SuprSend as an event using suprsend.track.
Once the event is set properly, the next step is to configure the Smart Channel node in the application. Adding the Channel Routing node is a one-click process.Without it, it would be creating individual branches to check whether channel info exists, whether user is subscribed or action is taken.
Then you can set the properties that we discussed above. For this example, use-case we would be using:
Once set, we can do a test trigger, and go to logs to see how the node is working. In the given screenshots at different intervals, you can see that the Inbox is triggered first, while the email channel waits. After the 1 min time window, when the Seen confirmation doesn’t come, the email is triggered.
Incase the Seen confirmation had come from Inbox, the email node would have stopped, and the workflow would be complete, saving unnecessary costs and notification fatigue for the user.
By leveraging SuprSend's advanced channel routing capabilities, social and collaborative applications can enhance user engagement, ensuring critical notifications are delivered through the most effective channels based on user preferences and contextual priorities.
Though there is one more way which collaborative SAAS tools like LinkedIn and Meta uses to reduce notification fatigue. They bundle multiple notifications into 1, and then send it to the user, also known as batching. You can checkout this guide to implement a batching mechanism to your notification infrastructure.
