Category Archives: Google Analytics

Ways to deal with (not provided) in Google Analytics

There is a growing problem for many businesses looking for insights from Google Analytics. Logged in users of Google products (and search bars), have the keyword referral data stripped and this is replaced with the keyword (not provided) instead.
There are several ways to gain insights from the data that is reported instead. At the simplest level, you can segment the organic data by landing page. For a more complex approach, register for the new (not provided) tool currently in Beta testing.

This tool relies on neural networks and machine learning techniques to discover the hidden keywords within the the (not provided) organic referrals.

fb_xd_fragment added to URLs with IE 7.0

Seeing URLs with fb_xd_fragment= reported in Google Analytics may not mean that your SEO is suffering, so don’t panic!

Your alarm might rise further when you see that the presence of the fb_xd_fragment= parameter causes the entire page content to become hidden whilst the page is loading. Still, don’t panic – investigate!

There are three main situations when panic is justifiable:

1. If you see that Google has indexed pages from your site with the additional &fb_xd_fragment= parameter, (Hint: use the site: and inurl: operators to check)

2. Users are reporting that they are seeing ‘blank’ pages on your site e.g. http://www.letsrun.com/forum/flat_read.php?thread=4349142 If you have come to this page looking for a solution as a user of a site, try to delete the ‘&fb_xd_fragment=‘ from the end of the URL and reload the page. if that does let you see the page then contact the webmaster and direct them to this post so they can implement a fix.

3. Since the confirmation that Google is indexing facebook comments (cf. Matt Cutts http://www.searchenginejournal.com/google-indexing-facebook-comments/35594/), the indexation of bad URLs from your site may grow as a consequence. Google may read the javascript on your site and generating these URLs to find additional pages to crawl.

Why are URL including &fb_xd_fragment= being visited in the first place?

The standard implementation of Facebook Javascript SDK for ‘Like’ buttons has been cited as the cause of fb_xd_fragment being appended to URLs for users of “certain browsers”.

It appears that Facebook Javascript SDK causes these ‘phantom’ visits when real visitor clicks on a ‘Like’ button (and overwhelmingly, the visits come from visitors using IE 7.0). It is a combination of the XFBML version of facebook plugins and IE 7 that gives rise to these URLs being generated by javascript and then reported in GA.

Now for a run through of the solutions to the fb_xd_fragment bug…

Here’s a recipe for various solutions depending upon the scale of your problem:

fb_xd_fragment solution A:

Use a custom channelURL file (channel.html) stored at root level. This is used to overload the FB.init() constructor by setting the channelUrl parameter value when FB initialises.The contents of channel.html are simply:

<script src="//connect.facebook.net/en_GB/all.js"></script>

The file above must be cached for as long as possible to provide a smooth user experience and avoid time delays.

This file can fix cross-site scripting issues (see http://developers.facebook.com/docs/reference/javascript/) – Facebook dev resources refer to this issue with tongue in cheek: “The channel file addresses some issues with cross domain communication in certain browsers.”

Finally, add the following code to your pages (on detection of IE 7.0):

<div id="fb-root"></div>
<script>
window.fbAsyncInit = function() {
   FB.init({appId  : 'MY APP ID',  status : true,  cookie : true, xfbml  : true, 
            channelUrl  : 'http://www.yourdomain.com/channel.html'});
};

(function() {
var e = document.createElement('script');
e.src = document.location.protocol + '//connect.facebook.net/en_GB/all.js';
e.async = true;
document.getElementById('fb-root').appendChild(e);
}());
</script>

 

fb_xd_fragment solution B:

Use javascript to undo the nasty side effects of the fb_xd_fragment= in order to make the hidden html visible once again. Use onLoad() to run the following script. NB. As with all scripts, this solution may not work every time, as is essentially a sticking plaster to undo what has already been done.

<!-- Correct fb_xd_fragment Bug Start -->
<script>
document.getElementsByTagName('html')[0].style.display='block';
</script>
<!-- Correct fb_xd_fragment Bug End -->

 

fb_xd_fragment solution C:

For those of you that would rather not use a custom FB.init and channelUrl, or add script to undo this ‘blanking’ effect, then the cheaper option is to use a redirect. Use 301 redirection to ensure that any URL requested with the fb_xd_fragment is redirected to the same URL only without this fragment.

 

fb_xd_fragment solution D:

Taking another step back from addressing the cause, you could try to prevent indexing of these pages by using the rel canonical link. Ensure that rel canonical is defined without the fb_xd_fragment on all pages that have Like buttons (use Browser/User Agent detection to set the canonical to keep page weight down, if preferred).

fb_xd_fragment solution E:

Use WebmasterTools Site Configuration / URL Parameter settings to set to ‘ignore’ the fb_xd_fragment parameter. This informs Google that URLs with this parameter are not important, and should not be indexed.

fb_xd_fragment solution F:

Fix (or more accurately, ‘hide’) the reporting. To keep these ‘phantom’ additional page views out of GA, add a filter in Google Analytics to strip all pages that include the fb_xd_fragment. Ensure that you have identified and fixed (if necessary) the cause before filtering these pages from GA! If you have implemented Solution A, then you don’t need to use a filter. The problem of reporting the ‘phantom’ pages should go away with Solution A!

 

As with most SEO work, pick the solution appropriate to your needs.

Footnote:

If you see visitors appearing to come from a Google cache with this parameter, it is likely that these visitors use iGoogle and they are following a cached link from their dashboard. Look at the rlz parameter in the cache string for G1 to identify the source as iGoogle:

iGoogle cache with Internet Explorer 7 rlz parameter

 

Enhanced by Zemanta

Browser page prefetching causing high bounce rates

Monitoring the pages with high bounce and taking decisions should be a standard part of a professional SEO day to day activity. Bounce rates in themselves don’t give the entire story however, it is nearly always necessary to dig a little deeper before a full understanding can be reached and action taken.

Here’s an example of where investigation sheds light on unusually high bounce rates:

On analysis, one page showed unusually high bounce rates – searchresults.aspx

Over time since 20th July 2011, the number of direct visits to this particular page has been steadily increasing – see screenshot from Google Analytics below.

The danger is that analysis of visits to searchresults pages alone could show a fake growth, as well as distorting bounce rate statistics… further analysis of the cause of this increase in bounce rate and action to remove these pages from any future reporting is essential.

 

 

As you can see, Safari is the the browser at the root of this particular evil.

The table above shows the majority of visits to the searchresults.aspx page are coming directly from Safari.

On analysis of the browser version, it turns out that there was a release of Safari 534 on 20th July 2011 so what we see here, is a steady take up of the new browser over time. This issue is likely to continue to get worse and already accounts for 2,000+ daily visits…

 

The Safari 534.50, 534.48.3 and 534.51.22 versions are all calling the searchresults.aspx page directly – as part of a prefetch cycle – and skewing the statistics in Google Analytics as a consequence.

Tip: Make sure you understand what is causing bounce statistics before taking decisions.

Prefetch can be useful in some situations, to direct the browser to perform a prefetch on ‘prev’ and ‘next’ tags, preparing the browser for the anticipated future interaction by the visitor.

The browser will also obey the the link rel=”prefetch” instruction in order to pull the next page. When the browser is idle, it will download the page behind the scenes into local cache, however if the visitor doesn’t continue their journey, then a 100% bounce is guaranteed.

Further reading on link prefetch can be found here:

https://developer.mozilla.org/en-US/docs/Link_prefetching_FAQ

 

Enhanced by Zemanta