Beyond the App Store: How Mobile Web Push Notifications Are Reshaping Brand Engagement

Native app installs were meant to be the best for mobile engagement. You download the app, retain the user, generate revenue. That was true for some time, but the stats supporting it have not been so encouraging. Many companies that pay a lot for app installs lose 77% of their daily active users only three days after the download. The funnel costs a fortune to get in at the top and loses a lot at every step. Mobile web push notifications solve this problem without requiring anything more from users than clicking one browser dialog. No downloading, no App Store, no waiting. This changes the game for the mobile advertising industry.

Why app install friction matters more than most brands admit

Convincing someone to download and install an app is a tall order. They must see an ad, think the description sounds compelling, click through to the app store, probably read reviews or check the release date to ensure it’s not abandonware, consider the price, watch some videos if available, and then finally download it. Next they must engage with your frequent push notifications, or simply forget about it until they remember to delete it a few months later after never having opened it.

The alternative is opening a web browser and typing your URL. If it’s a new user, about three-quarters of web traffic is going to come through Google or similar anyway. They can bookmark (or add to home screen) your site, subscribe to notifications, and even use your site while offline if you’re clever with caching. Oh, and by the way, your site has a search box which likely performs much better than the search function in your app.

The argument used to be that native apps had a capability advantage – they could reach users even when the browser was closed. That’s no longer true.

How service workers make background delivery possible

The foundation of mobile web push is the Web Push API, a W3C standard that gives web apps the ability to receive messages on a device through a push service, even if the web app is not active on the user’s browser at the time. The secret sauce that makes this possible on mobile is the service worker, a JavaScript file designed to run in the background of a mobile browser.

Once push notifications are accepted by a user, their browser subscribes to their service worker for your domain. The service worker then holds an active WebSocket connection opened to a push service, waiting for a message from your server to sync with the subscription. When a message is sent, the user’s service worker wakes up and receives the push payload, then pushes a native notification to the user’s device. The experience is identical to receiving a push from a native app.

This feature has been supported in Chrome for Android for a few years. As the highest volume mobile browser for Android, many Android users were already reachable through web push. The missing link in the chain was iOS.

What Safari 16.4 changed for mobile marketers

Apple’s lack of Web Push API support on iOS made iPhone users unable to receive web push notifications. With Safari 16.4, web push became supported for Progressive Web Apps on iOS when added to the Home Screen. However, iOS push permissions won’t be available until the PWA is added to the Home Screen, which does add an extra step not present in Android. But the door is still open, and this takes a lot of important things into account. Companies running mobile web push campaigns can now target cross-platform users without dual app native codebases for iOS and Android. The game hasn’t completely changed, but it has changed enough to level the field. It shows the importance of web push as a mobile channel rather than just on Android.

Turning passive web visitors into a recurring revenue stream

For publishers, the push monetization angle is particularly exciting. Mobile web banner ads have some problems: declining fill rates, increased use of ad blockers, and issues with reporting viewability. Push ads sidestep all of that. They plug into an entirely different part of the users’ attention stack and provide value at the point of delivery. Publishers who build a push subscriber base can monetize that audience directly through ad network partnerships, and push notification mobile ads served through dedicated networks deliver sponsored content straight to subscribers’ notification trays on a cost-per-click basis.

As a publisher, the first step is building that subscriber list. Install a push JavaScript snippet in your mobile website, and users who opt-in will receive notifications, either on desktop or mobile. Most push ad networks will provide their own JavaScript for this.

This is the only step that requires a little bit of moderation. No one wants to be the site that drives users away with constant nagging to opt-in. Just find a balance that works for your audience and trust good content to keep subscribers around. If you see a rapid drop-off in subscribers shortly after the first visit you may be engaging your users too often.

With a list up and running you can get a feel for how much these readers are worth. Any revenue you generate from their impressions and clicks can be divided by the number of people who received the notification. This will give you a rough idea of the value of an individual subscriber.

Anatomy of a high-converting mobile push ad

Many underperforming push campaigns are victims of their own format. They weren’t built for a platform where the thumbnail image and headline are the primary focus above the fold. Landing page templates made for desktop pop-ups assume the user will see that page, presumably designed somewhere between the headline text and the CTA button. On mobile, built for thumb-stopping moments in people’s lives, it’ll never happen.

In practice, the actual push notice doesn’t even look the way you designed it. Most services default to a notification text preview that includes none of your carefully crafted branding. Your campaign looks identical to competitors’ campaigns. The default setting is: no identity.

Opt-in strategy and churn prevention

Everything starts with the opt-in rate. If we have a list of 10,000 true subscribers (ie users who want to receive and engage with your push notifications) they are going to outperform a list of 100,000 who accidentally ended up subscribing or who did so under annoying pre-check geolocation GDPR-non-compliant cookie-warning pressure – and then immediately ignore or unsubscribe from everything you send them.

The worst way to convert the browsers into subscribers is to trigger the native browser permission prompt and ask if they want to receive notifications – the instant the user arrives on the page. No matter whether they’ve ever seen your site before or how long they plan on sticking around. That’s a cold ask and, as we alluded to already, it trains users to hit “block” more quickly than intended.

The best way to improve opt-in rate is to employ a double opt-in. First, provide an in-page soft prompt that kindly requests them to subscribe. If they agree (because they are interested), then and only then show the native browser dialog. On Android, the opt-in rate using this pop-up-in-page-native-browser approach can hit 10-12% (Business of Apps) compared to the sub-2% (and falling) install rate of native apps.

Getting the opt-in is just the start – keeping the subscriber is the hardest part. Churn generally comes from oversending. There’s no set-in-stone catch-all-push-notifications-should-be-capped-at-this-figure number but one or two per day should be the max for the vast majority of commercial cases. Especially, if you are using them for promotional content. Configure your Time-to-live settings also – an overly generous time to live on an alert and the user is alerted to 12-hour old news and left with a poor impression. Be smart with how TTL is set. If it’s a flash sale and the product is going in the next 4 hours then the TTL should be 4 hours – not 48.

Testing frameworks for real performance improvement

Marketing campaigns that are not tested cannot be improved. The aspects that should be tested are not superficial; they have a real impact on Click-Through Rate (CTR) and how long a subscriber will remain subscribed to your service.

Testing out the delivery time based on the local time zone of the user produces the best results when working with an audience that is spread geographically. For such audiences, testing an advertisement’s performance across different time zones can produce surprising results. Delivering the notification to arrive at 11 am in a user’s local time zone will outperform the 11 am delivery in the app owner’s local time zone.

The use of emojis in the notification should be directly tested against plain text for each app’s unique audience. For some types of products and users, emojis can improve the performance of a notification. For other cases, it makes no difference or even has a negative effect.

Similarly, discount framing can produce different CTR results. The “Save $15” versus “Save 20%” phrasing can increase the number of clicks on an ad, especially when a graphical element can represent the discount offer. The winning option here sometimes comes down to the vertical or the price point on particular goods. Run the same ad with the variants pushed to random subsets of your subscriber list and go forward with the better-performing option.

Privacy compliance as a channel advantage

Web push notifications are naturally originating from the first party. User opt-in on your subscription, your domain’s service worker takes care of the subscription, and no cross-site tracking is even used in the whole process. All in all, no third-party cookies, no fingerprinting, and no identity mapping out from cross-site data.

With privacy rules becoming stricter around the globe, and third-party cookies slowly vanishing from the advertising world, this should be a major competitive advantage. Advertisers who seek a durable, consent dependent channel of marketing, without being required to make changes every other year, have a good cause to start investing right now in web push notification subscribers.

It’s a self-opt-in channel that requires users to check the box and participate. It is also a self-sustaining channel that owes nothing to luck and is not governed by constant changes of terms of service.

The window to build a meaningful mobile web push presence at relatively low subscriber acquisition costs won’t stay open indefinitely. As more brands recognize that the technical gap between native apps and mobile web has closed, competition for subscriber attention will increase. The brands that build this infrastructure now – invest in proper opt-in flows, test creative systematically, and monetize their subscriber bases thoughtfully – will have a durable asset that outlasts the next platform policy change or app store fee revision.