Subscribe to our newsletter

Get the State of Digital Newsletter
Join an elite group of marketers receiving the best content in their mailbox
Help us understand what topics we should be writing about!
We would like to help you get the best content for your role
* = required field
I want the...

What alerts do you want to receive?

What topics do you most like to read about?

The Facebook browser – the biggest browser that you ignore

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.

StateOfDigital.com in Facebook's in -app browser

StateOfDigital.com in Facebook’s in -app browser

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.

In-app Safari webview windows are tracked in Analytics, but other browsers do not report it

In-app Safari webview windows are tracked in Analytics, but other browsers do not report it

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.

Missing functionality

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.

Page rendering

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.

Ad revenues

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

The next version of Facebook's browser? Spotted by @henryWilmer

The next version of Facebook’s browser? Spotted by @henryWilmer

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.



Mat has been building, managing and marketing websites since 1996 and now heads up the team at OKO Digital. Mat has solid experience across a range of digital skills, but is increasingly focused on his specialist area of website monetisation.
  • Leandro Chaves

    Thanks for the article! I’m having a big issue with Facebook in-app browser:

    Everything started when i realized most of my visits are not being counted in neither Google Analytics nor Adsense page view counter. In order to debug the problem, i created a server side page view log (when user requests a url (yes, it filters bots)), and another on the load of the page (which is called via ajax).

    So, I can see I have a lot of visits, but the most of them are using Facebook’s in-app browser. However, most of these visits aren’t getting logged on the second page view log. Then, I putted a noscript tag, and, inside it, an image with src pointing to a server side action that outputs an image and registers another log, but it have logged just myself, when i disabled javascript. So, I think javascript disabled is not the problem. I’m algo using TrackJs for debugging any eventual javascript error, but i’m not seeing anything relevant. Maybe the website is just not being loaded in these cases.

    Some versions of Facebook’s in-app browser page views is working fine and getting logged, but most are not. Right now, I have a list with hundreds of Facebook’s in-app browser versions that seems like not working to my website (It uses Foundation 5 in frontend).

    If you have some tip, please, let me know.

    • Mark

      I’m having the exact same problem as you. I’ve also logged regular images outside of noscript tags and images within an attached CSS file and both aren’t getting registered, only the actual page request.

      This is happening to 80% of requests hitting our web app are from the FB browser and they don’t seem to be bots either. Really frustrating if this Facebook in app browser is causing such a drop in conversions. I’ve tested on several phones and our site seems to work fine in the FB browser though so I’m really stumped as to what’s happening. Perhaps its some kind of ping to the site happening from user’s phones when our site link is impressed on their FB APP. If anyone has any ideas please let me know!

  • Bas

    Thank you for this article it really helped me.