The Blog

3 Ways to Deal with Google Preview visits in Google Analytics

So you may have heard that this new Google Preview functionality on the search engine results page is skewing Google Analytics data. Well, as it turns out, the page fetching that Google is doing (and that occurs when the page preview is NOT in cache), actually IS executing Javascript, which includes the Google Analytics tracking code.

This means that Google Preview fetches are showing up as a visits in your Google Analytics account.

Automated (bot) visits like this can inflate your visit counts and artificially reduce all of your per-visit metrics (pageviews per visit, time on site, value per visit, etc…), which, if you didn’t know what was causing this, might leave you wondering if your traffic quality has suddenly dropped.

Now you could always just filter out all the traffic from Google as an ISP, but to really focus in on Google Preview, here are three different ways to deal with this issue until Google addresses this problem, which will hopefully be soon:

We’re working on a solution for this, to prevent Google Instant Preview on-demand fetches from executing Analytics JavaScript. I’m not sure about the timeframe, but I’ll drop a note here when I have more to share. Thanks for your patience. (11-18-2010)

Option 1: Advanced Segment

Once the tainted data has been processed in Google Analytics, there’s nothing we can do to reprocess it or change it.  But we CAN change the way we view the data through Advanced Segments.  All we need to do is take what we know about the traffic we want to single out within our reports and create a segment that matches it.

So, knowing that these sessions originate from a Service Provider called “google inc.” and that these will be short, single page visits, we could do something like this:

Google Analytics Advanced Segment to remove Google Preview visits

This segment (here’s the link to this segment) will allow you to see exactly which components in your reports are originating from a Service Provider of “google inc.” that have the conditions on a bot visit that we would expect.  Is it perfectly, 100% accurate?  Nope.  But it WILL give you a baseline to see how this might be affecting you.  We’ve found this to be a relatively small percentage of visits across accounts thus far…here’s an example:

sample Google Preview segmented visits

Option 2: Server Side with Custom Variable

While approximating this impact with an Advanced Segment may be the only way we can adjust past data, we can label these visits as Google Preview visits with custom variables as the data comes in.  This is much more accurate as it relies on the actual user agent that the Google Preview tool uses when fetching your pages:

Mozilla/5.0 (en-us) AppleWebKit/525.13 (KHTML, like Gecko; Google Web Preview) Version/3.1 Safari/525.13

So all we have to do is apply some simple logic…

if (the user agent is that of Google Preview) {
Set a Custom Variable to identify this visit
}

Easy enough. Here’s an example of what that might look like using PHP, but you can adapt this to any server side technology as needed:


<?php $uAgent=$_SERVER['HTTP_USER_AGENT'];
if(strpos($uAgent,"Google Web Preview")>0){
$googlePrev=true;
}
?>

...

<script type="text/javascript">
var pageTracker = _gat._getTracker("UA-1111111-1");
<?php if($googlePrev){ ?>
pageTracker._setCustomVar(1,"googlePreview","true",2);
<?php } ?>
pageTracker._trackPageview();
</script>

There you have it. Now you’ll be able to see these visits in your Custom Variable reports, as well as create a more accurate Advanced Segment (click here for the link to it) based on this custom variable, and you can even access Custom Variables in your Custom Reports.

Option 3: Server Side Exclusion

You may just not care to see any of the visits generated by Google Preview at all and just filter them completely out of your data.  If that’s the case, we can use the same logic as we did in Option 2, but rather than set a custom variable, we’ll just never render the tracking code for the Google Preview user agent.

Again, you can do this with any server side technology, but here’s what that code might look like in PHP:


<?php $uAgent=$_SERVER['HTTP_USER_AGENT'];
$googlePrev=true;
if(strpos($uAgent,"Google Web Preview")>0){
$googlePrev=false;
}
?>

...

<?php if($googlePrev){ ?>
<script type="text/javascript">
var pageTracker = _gat._getTracker("UA-1111111-1");
pageTracker._trackPageview();
</script>
<?php } ?>

With this option, the tracking code will never fire for the Google Preview user agent, meaning the data will never get sent back to Google and will thus be excluded entirely from your reports.

Hopefully one of these three options will help you adjust for the impact of Google Preview visits showing up in your Google Analytics reports, and please share your ideas, thoughts and other options in the comments!


UPDATE: As of Nov 22, 2010 at about 3:30p PT, this issue has been resolved by Google. Please note that data will NOT be reprocessed, so Option 1 above can help you sort out affected data for past date ranges.

  • kas

    You would think that one place where they would fix it is their own product. Instant preview is screwing everybody over. you waste more resources for ppl that never visit your site. it ignores robots.txt. It’s amazing that they are doing it (and not in a good way).

  • http://www.nabler.com Gunjan

    Is this problem still exists? I applied segment but not getting any data.

  • mdasad

    You would think that one place where they would fix it is their own product. Instant preview is screwing everybody over.So i like this site.

Copyright © 2014, All Rights Reserved. Privacy and Copyright Policies.