Facebook’s in-app browser might not be something you’ve ever given much thought to. It’s easy to ignore: its users tend not to think of it as a browser, it hides in your analytics and once disabled is easily forgotten about. In fact, most popular searches about it are from people looking for how to disable it on their Android and iOS devices. If you haven’t looked at its impact on your site, it might be worth doing. The in-app browser is on the rise and it does raise a few questions for website owners and marketers. With a new version of the browser in testing that looks to encroach further into Chrome/Firefox/Edge/Safari territory, now might be the time to get those questions answered.
If you haven’t looked at its impact on your site, it might be worth doing. The in-app browser is on the rise and it does raise a few questions for website owners and marketers. With a new version of the browser in testing that looks to encroach further into Chrome/Firefox/Edge/Safari territory, now might be the time to get those questions answered.
What is it?
If you haven’t spotted the in-app browser yet, then you either don’t use the mobile Facebook app, or you have probably already disabled it and forgotten about it (For some reason only Android users are offered this option). It’s a stripped-down browser window that opens when open external links from within the Facebook browser.
The “browser” is actually just a webview window that provides limited browsing functionality, as a sub-process of the app that opened it. This allows information to be shared back from the browser window to the parent app.
Why don’t I see this in analytics
“In-app browsers” are not actual browsers, but a webview window running off your device’s core browser. 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.
In-app browsers do give themselves away in the user-agent string (the strings FBAV and FBAN are footprints left by the Facebook browser), but this is not accessible in Google Analytics without passing it in as a custom variable.
Why is this happening?
The PR-friendly answer is “speed”, and in-app browsers can certainly launch pages more quickly than switching to a separate application. More cynical readers (ie, almost everyone) will have probably already come to the conclusion that the real motivation is to increase dwell time. Users opening links in an in-app browser are more likely to return to Facebook when they finish browsing. That gives Facebook more opportunity to show those all-important ads.
The benefits to Facebook go beyond the immediate ad impressions. If a link opens in Chrome Facebook loses site of that user and learns nothing more about them until they return to Zuckerberg’s warm embrace. Links that open in Facebook’s browser are able to keep sharing data, helping build up a thicker, more valuable advertising profile of that user.
Strategically there is even greater value in ensuring that data remains within the Facebook app. Facebook is essentially an online advertising company, which means that their big competitor is Google. Google is utterly dominant as an ad platform in the open web. Once users leave Facebook’s walled garden for the open web they not only stop giving data to Facebook but instead give it to Facebook’s biggest rival.
As online advertising gets ever more sophisticated, and advertisers want every more targeted spend, the money follows the data.
Impact on site owners
Multiple browsers instantly throw up issues around Cookies that will be familiar to anyone who has faced the challenge of cross device targeting. Although on the same device, Cookies placed in a user’s primary browser are not accessible to in-app browsers (or vice versa). It’s not that the in-app browser doesn’t support cookies, but that it has its own set that are separate to those used by the main browser. Sites relying on that Cookie data for personalisation will essentially have to treat users in-app as separate individuals.
For websites reliant on advertising display, the lack of Cookies has a more immediately measurable effect. Display ads rely heavily on Cookies to serve relevant ads to users. With Cookie data ring-fenced to either the in-app browser or the main browser the ad tech can’t access their Cookies. On Safari the in-app browsers also block all 3rd party cookies, increasing the problem further. Without that data ads tend to be perceived as more annoying and command much lower rates from advertisers shy to bid to serve impressions to less targeted audiences. That, of course, will generally add up to a decrease in ad revenues.
In-app webview browsers are also light on functionality. They are tab-less, don’t allow users to bookmark, have no URL bar and are generally stripped back. No tabs also means not opening links in new windows – all issues that can impact user experience if you are not expecting them.
Pages can also render differently (and certainly less reliably), again an issue worth testing in detail if social referrals are a part of your traffic acquisition strategy.
Those who’s sites relying on ad display are probably most likely to already be familiar with the limitations of the Facebook in-app browser. The lack of data available to non-Facebook ad networks can result in far lower bids for each impression, pulling the rug from under CPM rates.
Facebooks recent announcement that the audience network is now available on mobile web might offer some hope in this regards. With Facebook still having access to the full user profile there is the potential for them to maintain high rates. How much they are willing to share that when they control both the supply and the demand remains to be seen.
What happens next?
Facebook seem to be testing an all-new version of their in-app browser. With a little more navigation it seems to be aiming to hang around on screen longer than the current version which is only going to exacerbate the issue
What you can do now
Before doing anything you need to understand how the issue is (or isn’t) impacting your website. That means plugging the gap in Analytics. My preferred approach is to pass the in-app browser details to Google Analytics as a custom dimension. See ‘Tracking Facebook in-app browser in Google Analytics‘ on the OKO blog for a tutorial and code snippet to do this.
Passing the in-app browser to a custom dimension allows you to apply that to other reports without re-writing otherwise useful data. This allows you to easily see the impact of in-app browsers on metrics such as bounce rates, depth of visit, conversion rates, user loyalty and even ad revenue.
With that data to hand you can better understand what the rise of in-app browsers mean for your site and decide on appropriate action.