Why Are App Install Banners Still A Thing?

A tweetstorm digestion by Alex & Owen.

“Why would someone add this banner to their website?!” asks Ada Rose Edwards:

That question spawned a ~40 tweet conversation that some folks asked to see written up here.

Before we get to that, and by way of disclaimer, we don’t have any insight into the specific thinking of the Tumblr team. For all we know they’ve done all the experiments and found the native app a better investment. It’s possible! Regardless, the past few years of working with teams that are at various points on a journey towards Progressive Web Apps has uncovered some patterns and it seems as likely as not that Tumblr is on a similar journey (whether or not they know it).

So why do sites add banners like these? The short answer is growth. The desired form of growth might be increased loyalty, engagement, or use. Sometimes it’s user-base growth, although that instinct has waned among savvy product managers now that the App Store gold rush has definitively ended. This sort of desired deeper engagement gets phrased in many ways: “a better experience”, “faster”, “keeps you up to date” (code for push notifications), etc.

Engagement and recall are valuable commodities in an attention economy. The platform wars that have followed are a result. Product owners and managers often view their websites (if they have them) as the “top of the funnel”; a way to build awareness of the final product or provide a try-before-you-buy version of the “real” experience.

This makes sense, historically speaking. Until Progressive Web Apps arrived, it wasn’t possible to engage users who wanted more of a service in all the ways that native apps could. The lack of push notifications and a presence on the homescreen stunted engagement. Lack of meaningful offline behavior meant it was natural for services and users to choose the native app route once they decided a service was worthwhile.

The trajectory of many businesses adapting to mobile looked like this:

1. Pretend their desktop website is fine because pinch/zoom
2. Invest in “responsive” without slimming down JS, ad, image, or third-party content — or worse, adopt services that “adapt” existing sites using blocking script tags.
3. When that (inevitably) doesn’t work, experiment with native apps
4. Early numbers from native apps look good, particularly regarding engagement vs. bad mobile web experience
5. ALL IN ON NATIVE!!!!
6. Discover the distribution wall: it’s blindingly expensive to drive native app installs if you aren’t #1 in your market
7. Investigate modern mobile web options

We tend to work with teams who are at steps 6 or 7; any earlier than that and the conventional wisdom makes it nearly impossible to get traction. The conventional wisdom is strong for a few reasons:

• “Market leaders have native apps and it’s working for them, so why not us?”
• Early engagement numbers from native apps are strong
• Structural challenges to learning that native apps aren’t working
• Android blindness

Ignoring the false equivalence between not-Facebook (everyone, basically) and Facebook (who can afford to develop infinite versions of a service to reach a marginally larger audiences and leverage existing installed base to drive cheap installs), services that experiment with native apps do tend to see increased engagement vs. “responsive web” sites. This follows from the historical feature gap but also from a more subtle effect: users who are willing to sit through a native app download, install, and ongoing update tax are likely to already be heavily engaged with a service.

Unless product managers are unusually scrupulous in segmenting and tracking which users adopt native apps, the prompts and overlays (like the one Ada Rose Edwards flagged) can simply be zero-sum transfers of engaged users from one version of a service to another. Even rarer are true A/B comparisons: funding both PWA and native app development and comparing engagement between them.

Teams we’ve worked with have reported similar engagement between those who install PWAs and those who install native apps, but the friction of PWA installation is much lower. Our internal metrics at Google show that for similar volume of prompting for PWA banners and native app banners — the closest thing to an apples-to-apples comparison we can find — PWA banners convert 5–6x more often. More than half of users who chose to install a native app from these banners fail to complete installing the app whereas PWA installation is near-instant.

Sadly, few sites are willing to go on the record about native vs. PWA engagement. If you’d discovered a more effective way to engage with users at lower cost would you be telling your competitors about it? There are also organisational pressures not to embarrass colleagues who may have pitched and developed native apps.

This leads us to structural challenges, which are perhaps the least talked about effect. Organisations that have legacy web sites frequently developed native apps in separate teams, out of separate budgets, often with separate goals. It isn’t uncommon for native app development to have been outsourced and funded out of speculative funds, e.g. marketing or R&D, with the reasonable understanding that it takes time to grow anything. Unfortunately, this siloing often leads to long learning cycles. Native app teams may learn how to grow their user base, but businesses too often are blind to the overall picture. Is growing your native app actually growing the business? It takes a real dedication to honest business metrics to even begin to tease this out and look at long term value vs. short-term metric growth. As with website bounce rates, many who visit will not stay, and unlike websites, and native apps are vastly more expensive to distribute. Some businesses are so far in denial about this that when you ask them if they pay for native app distribution, they’ll (unironically) say things like “no, we don’t pay for app installs, but we do provide discounts and offers that are only available in the app.”

Everybody “knows” that native apps work, after all, and some persist well after they hit the wall in terms of cost/benefit to native app distribution. It’s easy to get promoted by pointing to big numbers, and it is possible to grow your install base. Expensive, perhaps ruinously, but possible. Businesses can go years without learning the true cost/benefit of native app strategies — sometimes learning only in a darwinian sense.

Those that can learn on shorter time scales face a final hurdle: Android blindness.

Nearly all product owners, decision makers, and influencers (board members, VCs, etc.) in wealthy western countries carry iOS devices. Most have never seriously used an Android device. Because Apple hasn’t implemented PWA technologies in Safari and functionally prevents others from doing so, the expectations of iOS users regarding the web are set low.

The future is here, the rich just don’t have access to it. Those with the fastest hardware on the best networks simply cannot envision what a more capable web could do for their products because they’ve never experienced it. It’s unsurprising, then, that PWAs are getting built and succeeding in geographies where developers and decisions makers carry the same phones as the majority of users in almost every country on the planet. For more, see Bruce Lawson’s series on the World Wide Web, Not Wealthy Western Web.

Some businesses make it to steps 6 and 7 on the timeline above and are receptive to (or seek out) better strategies for getting users access to their services. The set of folks doing this and collecting truly comparable data is small. The set willing to share the data is even smaller. But let’s say your team wants to try, how do you actually conduct a real comparison?

It may take time and effort. To get a real comparison point, you need experience equivalence. A site that’s drowning in JavaScript won’t attract or retain users:

To really get comparable data, you’ll need to build a high-quality PWA using mobile-first tools like Polymer App Toolbox, Preact, Vue.js, Skatejs, or Svelte. If you’re a developer, your favorite tool probably isn’t in that list. There’s a reason: the constraints of mobile are much, much harder than we have collectively come to terms with. Most JavaScript libraries are suffering the lingering effects of desktop-era assumptions and have not made the radical shifts necessary to deliver great experiences on mobile. Folks using these tools must go to extraordinary lengths to make them perform in this environment.

So let’s say you’ve built a modern PWA that works brilliantly offline, gets a great Lighthouse score, loads the first time in less than 5s on webpagetest.org/easy on the Emerging Markets profile and less than 3s for repeat views. Let’s also assume you’ve implemented web push. Congrats! You’re setup to run a real-world A/B test with your native Android app. From this starting point you can actually compare the engagement of users who opt in to adding to the homescreen or agree to receive push notifications. You’ll also be able to compare the costs of acquiring and retaining these users.

What can you expect? As mentioned earlier, few firms have been willing to share their data on this. Those that have report astonishing comps: Selio reported a 10X lower cost to acquire an activated user (someone that has sent a message or made an offer) via their PWA than their Android app. Housing.com reported it was 50x cheaper to get a user experiencing their service when clicking an ad for the PWA vs. a native app. The “progressive” in PWAs matters: you don’t have any up-front hurdle to using your app with the web; a single link is enough.

Are these outliers? We don’t yet know for certain, but we do know that users are much more likely to accept a PWA request to “Add to Homescreen” than they are to install native apps.

None of this may be relevant to your site or business. Some sites don’t want or need users to return. Some apps aren’t possible on the web today due to technical limitations (though we’re chewing through that list quickly). Some markets have unusually high iOS penetration (e.g., Japan), making PWA ROI a smaller opportunity. Or perhaps you work for Facebook and already have high app penetration which you can use to drive low-cost installs of sibling apps. Or perhaps the early data is all a fluke!

But there’s reason to believe it’s not. PWAs are improving business outcomes for Flipkart, AliExpress, Konga, Suumo, Alibaba, Housing.com, and, yes, even Facebook. Last month’s launch of Twitter Lite is another vote of confidence that these experiences can compete on their own terms. It’s an exciting time to be working on the web platform, and like our colleagues on native app teams before us, PWA teams are springing up as side-projects and insurgencies inside organisations that are primed for change. The largest brands that have launched PWAs have done so with surprisingly small and scrappy teams. Not only is it not impossible to build them, it’s frequently cheaper than the alternative. Wego built their truly excellent PWA in 3 months with Polymer App Toolbox and one Android engineer who had never built for the web before.

Thanks to great tools like Polymer App Toolbox and improving documentation, teams today are only being held back by a lack of willpower. Luckily, the case is getting easier to make every day as more and more examples pour in. Seriously, check out these stats!

It’s our hope that as we show business and decision makers how much better the web is for their bottom lines, we can improve the experience of computing for everyone.