Photo credit: Post Memes via Flickr
Talking with founders is one of my favorite parts of being an early stage investor. Recently a founder casually mentioned there were three types of push notifications. I pounced on the comment as I had thought the same thing independently and was I excited to hear someone else’s definitions. Turns out we were in completely different places: the founder was thinking about notification technology while I was thinking notification use cases.
The three technical types she outlined were push, local, and in-app. In reviewing the iOS dev docs, one could also frame three as badge, message, and sound. The reality is that on either dominant mobile platform, notifications have a lot of unexplored potential in terms of tech and UX. And as the sophistication of notifications design grows in support of user engagement (not new user growth as is commonly discussed) the need for specific language to analyze the different types of notifications grows since not all of them are made equal!
With that in mind I’m going to enumerate the key notification use cases given their importance to mobile application design, engagement, and growth. Personally, I’ve come to believe there are three common types of use cases for notifications*: (1) user-generated, (2) context generated, and (3) system generated. Diving into each a bit more:
- User-generated notifications: These notifications contain content created by a human using the app to other humans. Generally, these are the most engaging but especially so when the content they contain is private and directed to specific people. Mobile messaging is the highest volume example of this type of notification but other examples include comments / likes / favorites on posted content or @ mentions. My current favorite example of this notification is getting a new photo of my son from my wife.
- Context-generated notifications. These notifications are generated by an application based on the permission of its users. This is the fast growing category of notifications because the amount of machine readable data mobile devices create: location, contacts, calendars, and much much more. The norms around context-generated notifications are still be worked out between developers and users. Location-based notifications currently dominate this category but other examples include information about your next meeting (time relevance) or updates about your favorite sports teams (interest relevance). My current favorite example of this notification is when I get notified there is a designer nearby via Highlight (disclosure: I’m an investor there).
- System-generated notifications. These notifications are generated by an app based on the needs of the app. This type of notification can usually be called re-engagement at best or spam at worst. Sometimes these can create value for the end user like letting you know a friend has started using the app or that there is a sale on in app purchases. Actually I can’t say that with a straight face as I don’t think they’ve ever created any value for me. Wait, I got one: security alert that someone has requested to reset my password. Well, until those started coming every few days anyhow. 😦
I’d like to pause here to solicit feedback on this classification and specifically to find examples that break it. After digesting feedback I’ll follow up with some more ideas on notification design.
*While I’m framing this in the context of mobile push notifications I think these categories work fine to classify notifications delivered via other channels including SMS, email and soon to arrive widely web browsers notifications.
bubba.vc 
Hey, how would you classify notifications from ‘things of your interest’ – for example a alert about a ‘flash sale for ski lift tickets’ – do you see that as an hybrid of context+system or an example of interest relevance? Also, an interesting pivot to this categorization would also be notifications that are real-time vs notifications that are more informational – do you think that would have a barring on your design for notifications.
Good question. If a user provided their interests (explicitly in app or by downloading the app with knowledge that push notifications based on interest X were primary value prop) than these would be in the context bucket for me. If the app just slung these out, like many FTP games do, I think they are system type.
Any notification that does not take into account current context risks being qualified as spam. The only exception would be notifications with the highest immediacy requirements e.g. password reset request submitted or credit card being used outside the home country (you want these notifications immediately even if you are standing with an umbrella in your hand at a street corner, context might not matter as much).
Rules of engagement (or rules of notification) that do not combine immediacy requirements and end-user context (derived from sensor data, ambient data and historical look ups) completely miss the point.
We could categorize notifications in various ways:
1. Based on notification trigger:
– User action
– Ambient data change (derived from both smartphone and external sensors)
– System event (includes pre-set time triggers)
– A combination of all of the above (sophisticated rule of engagement)
Historical data looks ups could also play a part when defining the above rules of engagement.
2. Based on immediacy requirements / delivery mode:
– Push alert (Local or Remote)
– In-app notification box
– SMS (works even if 4G LTE / data connection fails)
3. Based on call to action:
This becomes super relevant with iOS8 interactive notifications.
– Info only, no response required
– Response required via notification box
– Tap thru to app for response / action
4. Based on decay rules:
This is something that future versions of iOS and Android would have to implement for sure. Today, all notifications decay at the same rate which does not make sense.
There is a gigantic opportunity to create the next generation user experience via interactive notifications but it does require sophisticated tech for understanding context, respecting immediacy needs and implementing decay rules. This system of engagement would ultimately scale beyond smartphones and tablets into cars, airplane seat-backs, tvs and various other screens we interact with today.
This is one of the key problems that our centralized system of engagement software at MobileROI (mobileroi.com) solves for.
Thanks for thoughtful comment. I agree interactive and decay rules are going to be interesting to see play out. My current thinking is interactive just remove friction (less clicks to act on notification) while decay rules change the expectations of notifications given they are opt in but I can’t always act on them in real time.
Great post. Super useful for framing up some of the work we are doing on developing our own notification strategy.
Any thoughts on best practices for context-generated notifications for mcommerce?
Thx! I’d focus on generating context based notifications (we think you are shoping for new jeans so sending you this push) vs system notifications (we are having a sale for 24 hours so open our app!). Ideally, a user would be able to sign up to get notifications about things they care about.
The are four classes of push notification:
1) Broadcast
2) Personal
3) Contextual
4) Transactional
1) Broadcast: One notification for everybody. Broadcast notifications have a 2% engagement rate. Or put another way, 98% of them are ignored. Newsstand apps are the standout offenders. Repeat offence leads to deletion. It’s akin to bulk mailing.
___
2) Personal: The notification is only for you, and human initiated. They range from @whatsapp/snapchat/… messages, to @mentions, to @follows, to @likes, to [____]. They have a very high read rate…though not necessarily an equally high open rate. The notification alone can suffice.
___
3) Contextual: Notifications that are contextual to app use; contextual to the many senses available to the app – location, beacons, health, ’things’; or contextual to the many services that connect through the app (weather, sports scores).
Additional notes on contextual notifications:
Contextual to app use: These are automated notifications triggered by what users have (or haven’t done) in-app to help nurture, activate and grow a profitable relationship. Executed artfully in the context of use, they can be incredibly effective. Most sadly, are blunt, limited to the desperate “come back” hue, and most likely triggered locally by the app.
Contextual to senses: These notifications ought to be effective, but often turn out to be the opposite. Hell for me is walking down a high-street, and having every store shout at me. Beacons have the potential to put push on steroids. The real challenge, and opportunity, is deciding the if and when and notification should be sent.
Contextual to services: Notifications sent from services we’ve signed up for. To stand out from the choir, apps deploy custom sounds – Castro telling you a new podcast is available, Dark Sky informing you of a storm, The Football App informing you of a score from your favourite team.
____
4) Transactional: Machine generated messages intended just for you, and (hopefully) valuable you. Increasing apps and notifications will take over the jobs email, sms and call centers do today. “Your flight is delayed. Your card has just been used online, Your account has just been accessed. Your free trial is ending.”
Additional notes on transactional notifications:
Apple and Google prohibit sensitive content in the notification. So developers may need to add secure in-app messaging channels.
____
Know thy limits.
When all you have is a hammer, every problem looks like a nail. All most developers have to connect with their mobile customers is the notification. Hence, lots of jobs – onboarding, engagement, re-engagement, monetisation, customer development – are shoehorned into 150 characters.
In examining all these jobs, the definition of a notification is worth exploring – “the action of notifying someone or something”. It’s not what most developers need which is a communication “the imparting or exchanging of information by speaking, writing, or using some other medium.” The latter is where developers need to get to. They will be greatly helped by Apple’s new interactive notifications and custom in-app messaging channels.
Great comments! I think we see the world largely the same way with differences on margin (I combine transactional with contextual in my mental model but see your point). Love your last paragraph and point it makes!
We have a type called “Operational” messages. This falls somewhere between your “system” and “context” notifications. For example, if a package has been delivered, or is ready to be picked up, many people find these notifications helpful.
Barry calls these transactional which seems reasonable as a form of contextual or standalone classification.
Weekly Round Up: 09/06/2014: Cross-device Design, Deep-links, Push Notifications, Apple + Android, App Rejections - Lattice Labs Blog
How to Create User-friendly Mobile Notifications - Jon Izquierdo