The widespread release of Android Instant Apps brings us a shift in traditional ideas of user engagement with mobile apps and mobile app UX. Mobile app users will be able to test out segments of your app and may never download the full version. The shift has implications for your mobile app analytics strategy, bringing forth new data sources, goals, and experiments. As one of the top mobile app developer companies, and a Google certified developer agency, we’ve dedicated special attention to Android Instant Apps, and would like to share our thoughts on what we see as the top 5 analytics and UX impacts of this new approach to mobile engagement.
Concurrent with the announcement of Instant Apps at Google I/O, Google also updated and rebranded Firebase Analytics to Google Analytics for Firebase. You can currently still access the Google Analytics Android and iOS SDKs when you create a new Google Analytics (GA) account. However, the change to Google Analytics for Firebase gradually attempts to minimize confusion over which analytics platform to set up for native mobile apps by limiting your choice to Google Analytics for Firebase when you attempt to create a new mobile GA property. The data can then be displayed in the familiar GA UI or in your new Firebase console.
Now that you have a fancy new analytics SDK in addition to a new mobile touchpoint for users, here’s what do you need to know to actually build an analytics strategy around measuring the success of Instant Apps.
#1 How do I distinguish data from my installed app and Instant App?
Your installed app and Instant App have the same package name and there is no way to tell them apart in your Google Analytics for Firebase account. Therefore, Google suggests adding a user property such as app_type and setting “installed” for the installed app and “instant” for the Instant App. Adding the user property will enable you to filter reported events by each value so that you can distinguish usage from each.
#2 How will Instant Apps change my thinking around UX and user flows?
Your Instant App should have a very clear purpose and enable users to easily complete a task they sought out to do. The primary flow of Instant Apps should not be gated by a prompt to install the full version. The experience should be the same as if they had the installed app but the Instant Apps will have new flows that immediately engage users, users won’t likely sign up immediately or at all, and users may only interact with a subset of the app’s features.
#3 How do I evaluate the performance of my instant app?
As you could imply from point #2, good Instant App performance should NOT be based on the number of installations of your full app. Instead you should optimize a key performance indicator (KPI) that is directly linked to the completed action at end of the flow that users initiate when they clicked to download your Instant App.
A few example KPIs from Google’s initial partner’s Instant Apps could include number of people successfully signing a document, completing a crossword puzzle, or viewing a video. Take note of how each Instant App is centered around a very specific action that a user can complete. This action should align with your primary goal.
#4 What if a user wants to install the full version of the app?
There are going to be users who want to install the full version of your app upon using your Instant App. Examples include users who were impressed of your app’s value with your Instant App experience and users who are convinced to install to access specific features only available in the installed app.
For these cases, you should incorporate explicit and implicit installation prompts throughout your app. For explicit prompts, Google suggests creating an installation button using the Material Design “get app” icon that is clearly labeled with “install.” The buttons can be strategically integrated in your app’s UI as a clear reminder that the full app is available without taking away from the value that the Instant App already provides. Examples of explicit install button placement. Source
Google’s best practices state a maximum of 2-3 implicit install prompts. These prompts are triggered by a user navigating to features outside of the main Instant App flow and should describe the clicked feature to help convince users to install the full app. Example of implict button with feature description. Source
Be sure to add a Google Analytics for Firebase event for clicks on the install buttons (install_prompt) and include a parameter (install_prompt_type) that will differentiate explicit and implicit prompt clicks. An additional parameter (install_prompt_location) can also used to tell which explicit or implicit prompt was clicked if you have more than one. Tracking the clicks as an event will let you know if users are converting from your Instant App and the parameters will help you attribute the conversion to the correct CTA.
#5 Can I run any experiments with Instant Apps?
Google added a new type of experiment to the Play Console called mobile holdback. Mobile holdback lets you to funnel a percentage of your traffic away from your Instant App and routes the users to mobile web. This feature allows you to compare conversion performance across the two platforms.
Since it is difficult to run tests without a large volume of traffic, we suggest initially sending 100% of your mobile traffic to your instant app. You can use the data to evaluate the UX of the new platform and compare it to existing data from the full version of your app or to historical mobile web conversion data.
If you do not have large traffic numbers, you could try running a mobile holdback experiment coupled with an ad campaign to drive more traffic to the URL. Ads could give you the boost that you need to get your experimental results to reach statistical significance.
For more information, see Google’s documentation: Add Google Analytics for Firebase to your instant app and Best practices for user experience in an instant app. And contact us for help creating your Instant Apps.