Getting rid of fb_xd_fragment in Google Analytics

Sometimes some strange URLs may appear on your content reports with the query parameter fb_xd_fragment. It’s caused by Facebook social widgets.

In this post you’ll find out if you have this problem, how it happens and how to get rid of it.

Do you have this problem?

Do you have any Facebook widgets on your page? Like buttons, share buttons… doesn’t matter. If you use a Facebook widget and Google Analytics you are probably affected by this issue.

Just go to you content report and do a quick search for fb_xd_fragment.

OMG, what is all that trash in my content report?

This is a side effect caused by a workaround used by Facebook to support old browsers.

Every time you insert a Facebook widget you’re opening an iframe inside your website and inside that iframe there’s a page on the facebook.com domain. This page inside the iframe needs to communicate with the parent page in order to show you those nice Facebook ‘likes’ counters.

So when you have a ‘like’ button, Facebook has to do some cross-domain communication through the iframe. For security reasons, it’s not an easy job. You can’t give an iframed page access to all of the pages on your website or else you’d be opening a huge security hole in your website. New browsers support the postMessage interface to securely communicate with iframes.

Older browsers (most notably MSIE 6 and 7 and Firefox 2) don’t support postMessage and just block all that frames try to send to the parent page. The workaround used by Facebook and many others that attempted the same, is kind of oldschool but works. Instead of trying to talk to the parent page, they open up a new iframe, inside the iframe, pointing to the parent page. This allows them to send commands to the parent page via query parameters.

Ok enough with the I.T. talk. What do I do?

Ignoring that parameter on Google Analytics Profile configuration won’t solve the problem. Since that just removes the parameter, while you should be removing those pageviews altogether.

The right fix for this is to implement a channel URL. This is a workaround
provided by the Facebook API to work around issues like this. You must provide
a URL that has the code bellow. So instead of duplicating your page inside a
hidden iframe, Facebook will open that page inside a hidden iframe. This is
much faster, since this page is very small, and doesn’t count pageviews twice
because you haven’t put a GATC on that page.

It doesn’t just fix the issue but also speeds up the page loading on your
website for the browsers that don’t support postMessage.

To implement it just create a page somewhere on your domain with the following content:

<script type="text/javascript" src="//connect.facebook.net/en_US/all.js"></script>

Then you should add the channel URL option to your FB.init function, the example bellow assumes you created the page channel.html with the content above:

</pre>
<div id="fb-root"></div>
<pre>
<script type="text/javascript" src="//connect.facebook.net/en_US/all.js"></script>
<script type="text/javascript">
 FB.init({
 appId : 'YOUR APP ID',
 channelUrl: 'http://www.yourdomain.com/channel.html' //custom channel
 });

</script>

This will allow Facebook to open an iframe pointing to this url instead of opening the iframe to the same page it’s in, when it needs to do so.

This fix should solve the issue for you. But in the meantime you should start excluding the pages that have that fb_xd_fragment since they are actually duplicated pageviews from your original pages.

You also should add the fb_xd_fragment as an ignored parameter on Webmaster Tools. There are some cases where these bad URLs can get indexed by Search Engines.

Related Content

• http://www.cakemail.com/the-iframe-cross-domain-policy-problem/
• https://developers.facebook.com/docs/reference/javascript/FB.init/
• http://www.viget.com/engage/fb-xd-fragment-how-can-i-make-it-go-away/