Over a million developers have joined DZone.

What's the Deal With In-App Browsers and Push Notifications?

DZone 's Guide to

What's the Deal With In-App Browsers and Push Notifications?

Progressive web apps are changing the way people interact with their apps, particularly with push notifications. But as some move toward Chrome, others go it alone.

· Mobile Zone ·
Free Resource

At iZooto, we deal with a varied range of publishers – including the likes of Network18, Bhaskar, Zee India, IndianExpress, and many more. A question that pops up every now and then is whether or not the in-app browsers support web push notifications. For publishers, especially the large ones, this is an extremely critical question, because Facebook as a source contributes over 40% of their total traffic. Here is an overview of which in-app browsers support web push and which one does not.

Understanding In-App Browsers

“In-app browser” is nothing but a web view that provides limited browsing functionality as a subprocess of the app that triggers the web view. This also facilitates the flow of information from the browser view to the parent app.

Android iOS
Twitter Chrome Chrome
Facebook Facebook’s Own Native Browser
LinkedIn Chrome Chrome

So LinkedIn and Twitter's In-App Browsers Support Web Push Notifications?

Twitter and LinkedIn both use Chrome as their in-app browser/webview, ensuring that the experience is same as that of Chrome. Now given that the webview is in Chrome itself, as long as the version of Chrome on the device is above 42, web push notifications are supported. What that means is that the subscription prompt for push notifications will function as expected. You can trigger the prompt, allowing them to subscribe. Note – this is only applicable for Android and not iOS

What About Facebook?

app browsers

No. Facebook does not use Chrome for in-app browser notifications. It is important to understand a bit more about Facebook’s in-app browser, which has received multiple updates in 2016. If you haven’t looked at the impact of Facebook’s in-app browser on your overall site traffic, it might be worth doing. The in-app browser’s contribution to web traffic is on the rise, and it does raise a few questions on the current market share of browsers. It’s about time that website owners and marketers take notice of this.

What is more important to notice is that the Facebook app browser's traffic share for publishers now varies from 2% (for sites like MSN.com Rank #22 ) to 90% (for littlethings.com Rank #2 ). Refer to this post from Similar Web to understand the contribution of Facebook to publisher traffic.

These stats are staggering. And it's important to note is this – users tend to not to think of Facebook’s in-app browser as a browser — it also hides in Google Analytics and, once disabled, you can easily forget about it. "How to disable Facebook’s in-app browser" remains a popular search term.

app browsers

Here is what a quick analysis tells us:

  • 17% out the top 300 English language publications depend on Facebook for 50% (and more) of their traffic.
  • Facebook’s in-app browser contributes over 70% of traffic for 11% of these leading publications
  • 4% of these publishers depend on Facebook for 85% of their web traffic.

This article by Oko talks about how to ensure proper tracking of Facebook in-app traffic in Google Analytics. “In-app browsers,” like that of Facebook especially, are not actual browsers, but a mere webview window running off your device’s core browser. For instance, Safari passes the “(in-app)” string into the browser name, but others don’t. As far as Google Analytics is concerned, a webview window based on Chrome is simply Chrome (as in the case of traffic coming in via LinkedIn and Twitter).

It's important to note that in-app browsers do give themselves away in the user-agent string (the strings FBAV and FBAN are footprints left by the Facebook browser). However, this is not accessible in Google Analytics without passing it in as a custom variable. Read the guide by Oko to configure this correctly.

Does This Adversely Impact Your Website?

app browsers

On multiple grounds, yes. To start with, you need to understand the underlying objective here — Facebook’s goal is to ensure that the user does not move away from the app itself. Both instant articles and in-app traffic are steps toward ensuring that users consume content within the Facebook container. The impacts of both these practices are widespread, ranging from an impact on CPM bids to less engaged traffic. While Google has been pushing for creating a more powerful web browser, Facebook’s intent here seems counterintuitive. The key challenges revolve around:

  1. Limiting personalization: Given that an in-app browser can’t access the parent browser's cookies, these users are treated as unique new users, limiting your ability to personalize. Not only does the tracking go out the window, but it also leads to duplicates in the system.
  2. Far from a native experience: The experience on the original browser (Chrome at least) is now becoming near native. With progressive web apps and push notifications, marketers and website owners have the ability to create powerful experiences. Facebook’s in-app browser limits that drastically, where users can’t open new tabs and permission boxes can’t be triggered. The experience is sluggish and 1998ish.
  3. Ad revenues: Because of inappropriate tracking, CPM and bid rates go down the drain. The fact that the impression and view data is not accessible to ad networks and ad exchanges, impacts the CPM rates negatively.

It will be interesting to see how Facebook positions the in-app browser. As a standalone full-fledged browser, it could be a great boon for publishers, but at the moment, publishers are between a rock and hard place. Also, when you apply this viewpoint to your regular browser usage data, the statistics now appear convoluted.

browser compatibility ,push notification ,in-app browsers ,mobile

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}