The surprising tradeoff at the center of the question whether to build a Native or Web App
The choice to build a native app over a website is often made because apps “feel” so much nicer than web sites and that “they’re the future”, but here’s a secret I want to share with you:
Great UX isn’t worth anything if you can’t acquire users
And it is way harder to get users to try your native app than your web site.
Acquiring users is much easier on the web
On average, just 26.4% of users that visit your app store page will install your app. The other 73.6% of users are now lost to you and didn’t even get to try your app.
According to a study by ComScore, the top 1000 mobile websites receive 270% more monthly visitors than the top 1000 native apps. This data makes it clear that native apps are leaving users on the table.
At this point things aren’t looking too good for native apps, but that’s nowhere near the full story.
You can’t acquire as many app users, but they engage heavily
According to the same ComScore data, the average user spends ~18.5X more time than in the average top 1000 native app than in the equivalent mobile web app (Pinterest found this number to be ~3X and Yelp found it to be ~10X). There are are couple reasons for this difference:
- Apps are easily launched from the user’s home screen
- Apps can send engaging push notifications
- Apps generally have better UX
- Companies generally invest more in their apps than their web property
- These metrics only consider the time spent by the 26.4% of potential users that chose to install the app. 76.3% of potential users spent exactly zero time in the app. Hence these engagement numbers are heavily inflated by a selection bias
Regardless of the selection bias, there seems to be a very real tradeoff between reaching users are engaging them when thinking about platform strategy.
Conventional web sites let you reach users, while apps let you deeply engage users. This is the heart of the tradeoff between mobile web vs apps.
The most important question is therefore: for your product specifically, what is the optimal way to trade off reach and engagement?
Making the tradeoff for your product
The key to answering this trade off is to ask yourself:
What interactions within your product ultimately create value for your company?
Do users “create value” on their first visit (e.g. by viewing ads)? And is the session value of a returning user very similar to that of a new user (e.g. e-commerce, publishing)? If so, then reaching as many users as possible is the most important factor.
Alternatively, do users only become valuable to you after they have used your product for a while (e.g. messaging, social networks)? If so then you’ll want to focus on engaging a smaller group of potential customers.
(I have another post in mind that digs into this question from a more mathematical perspective, leave a highlight if you’d like to read that and I’ll work on it!)
What if we could get the best of both?
In an ideal world you’d get the reach of a web app and the full engagement of a native app, but unfortunately that maximal point is never obtainable.
This is because app engagement numbers have selection bias built in and because your target customers aren’t all equally interested in your product.
Some of your target customers will want to use your product infrequently, or even only once while some users will want to use your product every day.
Additionally, almost all of your users won’t know if they will want to use your product every day until they have tried it.
To make progress from here it’s helpful to think about interaction with a product as going through two distinct phases:
- New or low engagement users that don’t know much about your product, but are hopefully willing to try it and engage a little
- Engaged and convinced users that have decided they like your product and are willing to commit to using it more often
Conventional web-only or app-only strategies
A conventional web-only or app-only strategy would each only address one of the above phases, which is almost always suboptimal.
The only case in which a web-only strategy could make sense are in certain verticals (e.g. publishing and e-commerce) where there are so many potential new or low engagement users that it is optimal to focus all resources towards those users, rather than focusing on the ‘whales’, a much smaller group of users that each consume very heavily. This is changing though, as we’ll see in the section below ‘Innovative strategies to address users in both phases’.
An app-only strategy approximately never makes sense
By observing the strategy of almost every successful mobile product is should be clear that approximately none of them use an app-only strategy, and those that do are increasingly realizing that it isn’t working which should surprise nobody once you make the realization that the users in phase two start out as new or low engagement users.
Some companies have made a desktop web + native app strategy work by first engaging users on desktop as a way to transition them from phase one to phase two and then convert them into installing an app. In that case it is possible that on mobile a hard sell for a native app can be optimal, as was found by Pinterest, although this strategy almost certainly depends on having a pre-established brand and a well known value proposition.
While app-only may be a reasonable way to first demonstrate product value, very quickly it will be necessary to expand to the web in order to increase growth. (At this point I’d predict the engineering team will realize how much easier it is to ship new code and experiment on the web and regrets not doing this earlier)
The conventional web and app strategy
The most conventional strategy is to build both web and app versions. This allows you to reach large groups of users with your product and then once some users are convinced upsell them to your app, where they will be engaged and retained. This is the strategy used by companies such as GrubHub, Twitter, LinkedIn and others.
Innovative strategies to address users in both phases
The main problem with the conventional web + app strategy is that it requires you to build your product three times: iOS, Android and web
In the past year a new option has emerged. The major web browsers (with the notable exception of Safari) have centralized around a new set of web technologies which collectively enable developers to build Progressive Web Apps.
Progressive Web Apps are fast-loading web apps that can be accessed with low friction just like any other web app, but on Android can also be added to the user’s home screen, work offline, and use push messaging.
With a Progressive Web App strategy, the product can reach the large number of new or low engagement users with their Progressive Web App, and then offer engaged or convinced users to install it or enable push notifications, driving the engagement benefit of a native app but with the same single platform.
Unfortunately Safari doesn’t currently support the installation, push notifications or offline features of Progressive Web Apps, so upselling to an iOS native app is still important to address the segment of engaged or convinced iOS users.
Benefits of the Progressive Web App strategy
This strategy has a number of benefits:
- You can address users in both phases across all three platforms (Desktop, iOS and Android) with one fewer implementation of your product rather (as the Progressive Web App can take the place of the Android native app)
- Investments in the Progressive Web App now pay off across all three platforms. For example, when AliExpress built a Progressive Web App they saw an 82% increase in conversion rates on iOS compared to their old mobile web site
- Progressive Web Apps consume 92% less data compared to a native app, allowing them to better address users with slower phones or limited storage
- Progressive Web Apps allow engineering teams to maintain a high development velocity thanks to fast deploys and easy experimentation on the web compared to app stores
Drawbacks of the Progressive Web App strategy
- Today, browsers tightly control your ability to prompt users to install the Progressive Web App. While there have been hints that this may be getting easier, Chrome users must have already spent 5 minutes in the Progressive Web App before you can prompt them to install it
- While you can buy ads on Facebook to direct users to try your Progressive Web App, the Facebook WebView doesn’t support the installation or push notification opt in flow, and you can’t take advantage of the app-install ad format
Measuring your platform strategy
With this understanding of the reach and engagement benefits of different platforms in mind, the final question is how to measure how your platform strategy is working.
Rather than fallacious approaches like simply comparing average engagement between platforms, the key is actually fairly simple: run A/B tests!
Use A/B tests to measure the expected lifetime value (in engagement, dollars, etc) of your users in different experimental groups such as:
- Letting users experience the web version uninterrupted
- Showing a small banner encouraging users to install the native app or Progressive Web App
- Letting users interact with the Progressive Web App but require they install it (or the native app) at key conversion points in the flow
When you go out into the world to build your product, remember that while your native app experience may be very appealing that…
Great UX isn’t worth anything if you can’t acquire users
Remember that when it comes to reach and engagement:
- In most cases a hybrid web/app strategy works best to reach a large group of phase one users and then upsell those interested to phase two, where the average engagement per user will go up dramatically
- The exact balance of web and app that works best for you will depend on your business model and whether you can derive value from users that visit infrequently (such as advertising-supported products that don’t have high sign-up/set-up friction)
- Progressive Web Apps are an innovative new way to achieve this strategy with lower costs
Don’t forget to give a ♥, and for more, follow me on Twitter (@owencm) and Medium.
This post is shared under Creative Commons Attribution-ShareAlike 4.0