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. in Facebook's in -app browser 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.

About Mat Bennett

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.

13 thoughts on “The Facebook browser – the biggest browser that you ignore

  1. 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.

    1. 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!

      1. Hi Leandro, and Mark. I’m similarly seeing some strange missing JS analytics for Facebook in-app browser users. Were you able to reproduce these issue reliably? If so could you describe ho you did it?

        1. I think there may be two issues here. One is that facebook does prefetching of the first result of a clickable URL when they think the user might click it. So you’ll see a bunch of extra requests that don’t result in further requests (i.e. missing included css, js, images, etc). You can recognize these by looking at the (X-Purpose:preview) request header they send:

          The second issue might be that the user clicks the link but the browser is very slow in opening the website and the user quits during the process. In this case, you might see multiple related requests (html, included css, js, images) and javascript maybe / maybe not get executed (depending on when the user kills the in-app browser). I’ve got both of these issues going on now – I think the only fix for the latter is to make the site landing as fast to load as possible.

  2. Not the grammar police but it there’s a totally understandable and slightly amusing misuse of “site” vs. “sight” in the 8th paragraph. It’s either a great subtle pun or you type “site” much more often than sight on a blog about (web) sites!

  3. I just noticed our website does not display properly on smartphones from facebooks browser. Is there anyway to fix this? I don’t know what to do. This could be killing our results.

    1. same case is mine. my customers complain that my add to cart button is not working. Now i have realized that my website Add To Cart doesn’t work in facebook browser. And I am losing customers :-/

        1. not fixed so far; perhaps, I ran many campaigns to educate my customers to open website in the specific web browser like chrome, firefox, safari etc.

  4. The facebook browser does not like google analytics. I found this out after wasting money on Facebook advertising. I was promoting a web page on facebook. When i clicked the link on my computer the page opened within 2 seconds. When I clicked the link from my phone the page would take 2-3 minutes to load. But if I clicked open in samsung internet from the facebook menu it would open within 2 seconds

Comments are closed.