Using Persistent Notifications

There’s a new post on the Android developer blog on Engaging users during major events: How The Guardian used innovative notifications. The Guardian newspaper used the new notifications functionality in Android 7.0 Nougat to create a continuously updating notification which was persistent on their lock screen:

Google says:

“Promoting live updates (via the notification) resulted in 103% increase in daily installs during election week. “

I am currently involved in apps using iBeacon and Eddystone Bluetooth beacons. It occurred to me that an interesting partner for persistent notifications is use with beacons. Detection of beacons could drive changes in a notification based on a user’s indoor location. This might be used in visitors spaces such as galleries and museums. It might even be used to direct users along an indoor route.

Learn more about notifications in Android Nougat
Learn more about beacons

Using Notifications to Drive Engagement

localyticsLocalytics have new research that shows that in-app messages drive 3.5X higher user retention. But, as Localytics say…

“Many app owners wonder how to create content that isn’t viewed as spam and doesn’t detract from the user experience.”


The problem is that unless the message is event/content triggered and is useful to the user then the notification is likely to be seen as an annoyance. For example, as some developers do, reminding the user about some feature of the app that isn’t pertinent to specific new content in the app is likely to be viewed unfavourably. If your app isn’t event/content driven then in most cases I’d avoid notifications as it’s harder to justify their use.

Localytics also have some recommendations for you to consider to help drive use of notifications…

  • Get the user to opt in (rather than have to opt out)
  • Provide personalised recommendations (rather than serving them with everything)
  • Provide notifications for upgrade or achievement notifications
  • Get users to share app content (I am less sure this is a good idea)
  • Provide app quick tips (I personally think this will annoy all but the most ardent fans of your app who will probably already know about the feature anyway)

You might also consider filtering notifications based on what content the user has previously viewed or what they have favorited/saved. Whatever you do, provide the option in the app for the user to turn off notifications otherwise some people might uninstall the app instead.

Pre-App Strategy

benedictevansBenedict Evans has two new excellent posts on Mobile First and App vs Web. However, what he writes about is very different to the usual mobile first and app vs web arguments.

In Mobile First, Benedict suggests that we think about the desktop as the more limited cut-down version of the Internet. The smartphone allows interaction with more things (e.g. iBeacons, notifications, Touch ID) and knows a lot more, via sensors and APIs, than the desktop ever did. He argues that while the screen might be smaller, the smartphone is more of the ‘whole internet’.

In Apps vs Web, Benedict asks the usual question whether publishers should do an app or a web site. However, instead of the discovery or functionality arguments he distils the answer down to:

“Do people want to put your icon on their home screen”.

He goes on to argue that even if you have an app, you should also have a web site that functions well on mobile. You should also shape your proposition so that it works for people who have chosen to interact only via mobile and might not even be mobile (e.g. using on WiFi at home).

In both these posts Benedict is thinking about the business decisions made pre-app. I believe this pre-phase of mobile strategy is one that publishers don’t spend long enough analysing. People often leave issues such as usage, discovery, the channel, PR, marketing and analytics until too late on when solutions are often more difficult and costly to retro-fit. You also need to think about feasibility, platforms, business models, OS and form factor variants and cost. See my Mobile Development Primer for more insights.

Notifications vs Apps

intercom.pngThere’s a thought-provoking article and discussion at Intercom on "The End of Apps As We Know Them". The premise is that we will use apps directly less and less and instead interact with rich notifications or cards.

While I can see some notification-rich apps might work this way, I am less convinced that the majority of apps will end up working that way. Most apps do too much to be shoehorned into a notification style app. Also, people are more used to invoking apps via icons and I can’t see that going away. I think cards/notifications are great for end user consumption but not end user content creation. If the majority of apps were to use this paradigm then the user would become overwhelmed with notification overload.

Check-in Services, Geo-Fencing and Push Notifications

retailtouchpoints.pngCheck-in services and apps aren’t something I am that interested in due to the fact I don’t use them and I don’t even know anyone who does. However, there’s an interesting article at retail touch points that has made me think again.

The article explains how check-in services have evolved to provide for smart (context sensitive) deals and how, in the future, they will evolve into better customer loyalty tools. The article also shows how check-in users are an appealing demographic…

More interesting for mobile developers is using push notifications rather than SMS for scenarios such as geo-fencing around physical stores and trigger based marketing. Push notifications allow for larger messages, more easily integrate into apps and don’t have a per message cost. While the article goes on to promote a proprietary push solution, there’s no reason why Google’s CD2M and Apple’s push notifications can’t be used in solutions.