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:
“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
Localytics 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.
Benedict 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.