How Android M made Sensy Remote re-think user onboarding
Android M is probably one of the most important Android update for Android product managers. Yes, Lollipop forced many designers to re-think their UI and go towards material design. But Android M overhauled the permissions semantics — and forced Product Managers world wide to rethink user on boarding.
Pre-amble:
From in-secure to extra-secure
Android has been the subject of many security jokes, especially among iOS circles. People accused Android of allowing apps to misuse permissions and hence compromise user privacy without their knowledge. During an app install, a long set of permissions are just “Ok-ayed” by gullible users that want to try the app. Apps (and a sly SDK business) misused this — often by taking extra un-necessary permissions, and sending out data that can aid ad-targeting. Why would games need the microphone permission? Why would Torch apps need your location?
From a model of so-called insecurity, Android M moved to the extreme opposite, where every permission is an on-demand service, and granted by the user just before the app needs it. Apps can/should “prime” users when need this permission. Users have the right to deny a permission. App developers have to take extra precautions to keep the app running and provide functionality even if the requested permissions have been denied.
People behind the Android Play Store have started contacting several popular app developers asking them to incorporate best practices for app permissions.
Why does Sensy Remote needs its permissions?
Sensy strives to make Broadcast TV Viewing the most personalized, friction-free experience. Sensy serves as a Smart TV/STB Remote, a Personalized TV Guide, and a TV Companion. At times, the app needs to present the best choices in front of a user, and some permissions help go a long way.
1) Record Audio:
Voice Search: Sensy supports a Voice Remote. You can just say, “Star Plus”, and the app changes TV channels for you. For this, we need the ability to record voice — so we can send the recorded command to the Voice Search engine.
Auto-Discover TV: How nice would it be to discover stuff related to what you are watching on TV? Sensy has an automated content recognition technology that can sample TV Sound, recognize what is playing on TV, and then suggest interesting videos, gossip and songs for you. An opt-in feature, this again needs the microphone to sample audio and identify TV.
2) Location:
Recommend Set-top Boxes: Set-top boxes and TV providers change by region. Infact, the same Cable operator has different channel number mappings in different regions. Star Plus on Hathway in Bangalore and Delhi will have different channel numbers. By knowing the location of consumers, we can automatically recommend the appropriate TV providers. Further, once a user sets a TV Provider for a location, we “store” it with a geotag, and then crowd source the appropriate TV Provider for others. Did you know there are over 200 cable providers in Karnataka alone!
3) Android Identity:
Personalize TV Recommendations: We stored user preferences and search history to decide the right set of programs to recommend on TV. Making people go through a login process was always a friction. The Identity permission allows apps to re-use the standard auth mechanism of the Android device for its own authentication.
Life was a bit easier as a developer in pre-Android M. The user reviews the permissions, says, Ok, and the app does its best to offer a good experience.
But the problem was not with “good apps”. Many apps took more permissions than they needed, and traded user data with ad networks. Again, why would a Torch App need a Location permission? Most likely the Ad-SDK integrated requested location data to serve geo-specific ads and even more likely to track the location patterns this user visited, and sell it to retailers.
Android M took a stern stance that everything an app does should be known or communicated to the user. Each permission had to be primed for, and granted by the user. So, no more, “Ok” button, but a series of Grant/Deny dialogs.
On demand permissions made us re-think user onboarding.
Here are some thumb-rules.
A) Build context for a permission:
For every permission:
a) Build a case for why the permission is needed.
b) Show users the value of providing the permission even before they grant it.
c) Ask for the permission just when it is needed.
B) Prioritize permissions:
a) Ask the most important ones right upfront.
b) Delay the others to the point of consumption.
With these thumb-rules, we had to revisit when and how we’d ask for permissions. They were most likely bundled with the introduction of important features of the app. At times, we had to introduce new screen flows — to convince the user that a permission is important. We used the following framework.
1) Record Audio
Which features that depend on this? a) Voice Search b) Auto-Discover TV
Is this absolutely necessary for the app to work? No. Perhaps asking for it can be delayed until later.
When should the permission be primed? a) First time a user tries Voice Search.
b) Auto-Discover TV is something that happens in the background. So, there’s no first time. Hence we designed an interactive and on-demand “Discover TV” feature. Users can check how the app can listen to TV and detect what they are watching accurately. When satisfied, they can choose to enable the Auto-Discover TV option.
2) Location
Which features depend on this? Recommendation of TV Operators.
Is this absolutely necessary for the app to work? Yes, Sort of. (If location is not provided, the burden on the user to select his operator is higher). We still make it easier by a search option.
When should the permission be primed? During first few minutes of app usage. And every time he tries to set a TV Operator.
3) Android Identity
Which features depend on this? Personalization of the product.
Is this absolutely necessary for the app to work? Yes, Sort of. (If a Login is unavailable, we cannot predictably store and retrieve preferences). We could store user preferences using a UUID or MacID but if users change phones this data is lost and Users would then have to re-start learning. Its a matter is convenience
When should the permission be primed? During the first few minutes of app usage. However, just asking people to provide a Login often results is drop-offs. People often want to know the benefits of a Login before giving away their details. For this we built an interactive “Interest Builder”, that solicits a few things the user likes on TV, and iteratively builds a cloud of his interests. When he has spent about 3–4 minutes building his profile, it’s easy for us to ask for a permission — so we can save all of his work.
What happens if you don’t prime users in the right context?
Will we be in the old Windows world of Pop-Ups soon after an app install?
How does Permission Priming affect product metrics?
Android M is better for users. Product managers will be forced to improve their on-boarding and be more communicative of what they do with user data. For everything a user gives away, he should get back more. Apps that rush through the permissions priming will risk losing user engagement through uninstalls.
In about a week after moving to Android M, we had some interesting observations on acceptance and denial rates.
- The Location Permission had a 16% denial rate.
- When we asked for the Record Audio permission, the denial rate with Voice Search was a whopping 46%. [This totally beat our thinking. We expected people to grant us this permission after they click on the Voice Search button! Why else were the users expecting?]
- In contrast, when we asked for the Record Audio permission for Discover TV, we saw only a 27% denial. The better messaging probably did the trick.
So, right now, we are back at the drawing board to improve acceptance rates for the Audio permission with Voice Search. Maybe, we should show more messaging and explain the benefits of voice search?
In terms of product metrics, in just about two weeks after moving to this permission model, we noticed:
- DAUs fell by 10%. A large bulk of users on Android M will jump to a new permission model. This means when the app upgrades from an Android L library to Android M, its users will not have these permissions granted by default. They need to discover and grant them. Expect a delay for DAUs to ramp up. They may never get to the full past glory. With fewer permissions than before you have fewer avenues to engage users.
- Average Session Duration jumped up by 20%. Many of the short sessions were gone, and every engaging user spent more time on the app.
Where is all this heading?
Every permission is now a challenge for the developer. He needs to convince the user of the benefits he will derive — for every permission he gives away. We’ll evolve towards products that explain themselves better to users. Android M just made users win!
