The following blog post was created thanks to the invaluable collaborative efforts by Risa Pesavento, Ravi Mandliya, and Imran Akbar — thanks so much for all your work!
Notifications: when done right, they help you stay connected to the communities and friends they feel close to. Notifications are delightful when sent at the right time, at the right place, and tell you about the right stuff. Doing it “right” can be extremely difficult and learning from user feedback offers a glimmer of hope to tackle the challenge. That’s why machine learning is crucial to building a delightful notification experience.
We’ll start with a conceptual outline of a notification system and then keep adding layers to reach the industrial state of the art. We’ll follow the start-simple-deliver-value approach of how to build ml-first products in the following blog post.
Inputs:
1. Direct messages to individuals or groups: There is an implicit expectation from the user to be getting a notification for content in this channel, for example, direct messages to a user on a messaging platform like Discord. From the recipient’s perspective, these could be:
a. time sensitive / urgent
b. important but not urgent, at least not urgent enough to notify them.
c. promotional / spam / scam direct messages
2. Mentions / tags in content: Depending on the volume and frequency for the recipient (think a million people tagging Tom Cruise in tweets after Top Gun), we might want to optimize the channel for how much we believe a particular notification interrupts the user.
3. Posts of followed users / topics (connected content)
4. All posts (unconnected content): For example, all messages in a Discord server.
5. Creator / Platform driven: For example, promotions by creators/community hosts or recommendations by the platform for Groups to join, Users to add-friend, follow, and so on.
Channels:
These are surfaces where the user could be notified such as their email inbox, a push notification to their mobile device, or their notifications hub within an app. We have chosen not to include channels such as newsfeeds or homefeeds because those are surfaces a user visits to see content, i.e. action initiated by the user. The channels are avenues by which the platform reaches out to the user.
1. New email notification - typically shows up in email and usually filtered out into the “promotions” tab by Gmail’s smartness.
2. New push notification - typically shows up on the user’s phone if they have notifications enabled for this app.
3. New in-app notification for logged in users - For example, an in-game notification in Roblox, or an in-app notification that a “friend” has started live streaming on a social network.
4. New notification in the app’s notif-tab / inbox - This might or might not be accompanied by badging of the app icon. Usually this is a strict superset of (2) push notifs.
5. Update an existing notification in the app’s notif-tab - For example if you post something on Instagram and you get 250 likes on it, you probably don’t want to see 250 different items in your notification tab about it. You probably want to see a single item there showing a few users who have liked and the total number of likes.
Basic Framework
At a high level we have inputs, i.e. sources of notifications, channels, and ways of getting in touch with users. To optimize the experience, we need to add a decision maker in the middle that decides for each notification whether it should be dropped or sent ahead and if sending, to which channel.
There is some nuance missing in the above schematic.
- To learn and optimize, we need to log the user’s interaction with the notification which is typically delayed.
However, to keep the images clean, we will extend Fig 1 going forward, just bearing in mind the implicit detail of Fig 2.
Need for Smart Channels
Channels may be synchronous or asynchronous. Asynchronous channels operate at their own cadence. For example, emails might be batched and sent once a day to the user. As mentioned in “Update an existing notification”, i.e. Channel # 5 above, not all channels are idempotent. Some, like the notification tab, might want to optimize their own product experience.
Some Notifications May Have a Longer Life?
Some items might be relevant for notifications like email and push notifications somewhat asynchronously and later than when the content was created. Hence even if items are not sent immediately, they should be reconsidered.
Problem: Too many items to reconsider!
This process is having to independently optimize for each user. Let’s say there are millions of users and messages on the platform. Each message can potentially be sent as a notification. For example, on other social platforms, these could be posts from users who follow high volume hashtags. In such cases it seems the “reconsider in some time” might become a huge list of messages to consider for each user.
Proposed solution: Smart Inputs
To make the SNS lighter, what if we made “Smart Inputs” that are capable of looking at older content to determine what to send, whom to send and when to send? This way we can remove the reconsider loop in SNS.
Real Example - Notif Stack of a Social Network
We will put together what we have talked about so far into an actual example, say the notification stack of a consumer internet company like Discord.
Examples of “simple inputs”: Creator went live and Direct message
Examples of “smart inputs”: Email digest, Push notification of notable posts (a.k.a. Inorganic push notifs)
Example of “smart channel”: Notification Inbox / Tab on the app.
Design Choices
Separating ML service from a platform service
Conclusion
Together, we saw how the notification system design needs to change to incorporate machine learning. We also learned how to componentize machine learning into smart inputs and smart channels in addition to the main Smart Notification System, so each of them can be developed in parallel by different ML teams.
Does this sound interesting to you? We’re always hiring, so check out our jobs page!