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:

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:

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.

---

David Booth
David is a co-founder and principal consultant at WebShare. You can find out more about David here.

See more posts by David Booth

We get asked very often how to track Facebook “Like” buttons inside Google Analytics, so here’s a post that will show you how to do it.  There are basically three steps – first, you need to get the Like button on your pages using the XFBML / Javascript version of the Like Button.  Next, you’ll need to fire some Google Analytics code in a Facebook event that tells us when a successful “like” action has occurred.  Lastly, you need to find where it all ends up in Google Analytics and take action based on your new data!

1. Get a Facebook Like Button on your page(s)

The first step is to actually get a Facebook Like Button on your page. The quickest way to do this is to go here:

http://developers.facebook.com/docs/reference/plugins/like

Just fill out the form and click the “Get Code” button…you’ll see something like this pop up:

Now, you’ve got two options here. The iFrame version is admittedly the easiest to install, but unfortunately you don’t have any way to track when someone actually clicks and successfully “likes” your page as a result. There’s no onClick event you can use for an <iframe>, or for a <fb:> tag for that matter. And even if you could, the click itself doesn’t tell you if someone actually successfully liked your page or not – remember, they have to log into Facebook first, via a popup that might even be blocked in some browsers, so your click and Like counts may be very different.

So instead, we’re going to use the XFBML version (highlighted).

To implement this, you’re going to need to use the Facebook Javascript SDK – basically it works like this (and you can view the source of this page – you’re looking at a working example):

• Update your <html> tag to include

xmlns:fb='http://developers.facebook.com/schema/' xmlns:og='http://opengraphprotocol.org/schema/'

• Add the proper Open Graph Protocol meta tags – this is not necessarily required but a good thing to do.
• Reference the Facebook Javascript library – we recommend you use the following asynchronous version (make sure to put your own App ID in there):


<div id="fb-root"></div>
<script>
window.fbAsyncInit = function() {
FB.init({appId: 'INSERT YOUR APP ID HERE', status: true, cookie: true,
xfbml: true});
};

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

• Add the XFBML that you generated above (make sure to update it with your own page URL as the source and add any available attributes you might want) where you’d like your button to appear on your page:


<fb:like href="http://www.somesite.com/somepage"></fb:like>


2. Fire a Google Analytics Event when a “Like” action occurs

OK, at this point you’ve got your Like button up and running. Now in order to track these in Google Analytics, we’re going to use Event Tracking to fire an event whenever someone successfully Likes the page. You can choose to set this up in whatever hierarchy you like, but here’s one you might want to use:

Category: “facebook”
Action: “like”
Label: URL of the page that was “liked”

Using the _trackEvent() method of the pageTracker object, the Google Analytics javascript code would look like this:


pageTracker._trackEvent('facebook','like', href);


Note: This is the synchronous version of the Google Analytics code and assumes a javascript variable called href contains the URL of the page that’s being “liked”

So the last step in this process is to actually fire this code only when a successful Facebook like occurs. To do this, we’re going to subscribe to an event that Facebook exposes to us when the successful “like” action occurs. When we detect that event, we’ll fire our _trackEvent code. Here’s the code that will do it:


<script>
FB.Event.subscribe('edge.create', function(href, widget) {
pageTracker._trackEvent('facebook','like', href);
});
</script>


Note: The safest placement of this code is somewhere BELOW your standard Google Analytics tracking code – this will ensure that the pageTracker object has been defined before you try to use it

That’s it!  Feel free to get creative here…want to use a Custom Variable to create a segment of either visitors (scope = 1) or sessions (scope = 2) that “Liked” something?  Then all you would have to do is something like this (make sure your slot 1 is available and you want this at a visitor scope for the exact code below):


<script>
FB.Event.subscribe('edge.create', function(href, widget) {
pageTracker._setCustomVar(1,'facebookLiker','true',1);
pageTracker._trackEvent('facebook','like', href);
});
</script>


Want to stick this data into a database so you can use it for any number of customized reasons? Just fire some AJAX in there. Just about anything you can accomplish with Javascript can be done with each Like event.

3. Find that data in Google Analytics and USE it!

Now, you can log into your Google Analytics account and head over to the Content > Event Tracking reports and take a look at the Categories, Actions and Labels as you’ve defined them:

Note that here we’ve drilled down to the Category of “facebook” and the action of “like” – now we’re looking at a list of the URL’s we passed in – or in our case the actual blog posts that people “liked.” They’re a bit ugly since they’ve been formatted for proper URL encoding, but hovering over the label itself will let you see the URL that was “liked” pretty clearly.

So what do we do with it?

Well, this is one more set of data that can be used to identify what content resonates with your user base.  Which are the popular themes of blogs?  Which are the authors that our visitors like the best?  Which topics do people like to read about?  We can look at the Site Usage tab right here to understand if people who like certain blog posts are any more engaged (think bounce rate, time on site, average pageviews per visit) than others.  We can look at our Ecommerce tab and find out if people who like certain pages are more or less likely to, say, sign up for one of our live Google Analytics or Website Optimizer Seminars for Success trainings.  With this knowledge, we can tailor the content that we write to the things that people like the best and the things that get people to engage with our site and convert on our goals.

And don’t forget about your Advanced Segments! Below you can see a quick Advanced Segment configuration that will quickly let you compare those Facebook Likers to any other segment of traffic you care to define:

Hope this helps a few of you out, and we’d love to hear how you’re using this in the comments!

---

David Booth
David is a co-founder and principal consultant at WebShare. You can find out more about David here.

See more posts by David Booth