For a while I wanted to write this post about the Google Analytics sampling. You know, the dreaded message that appears on top of your reports:
This message shows up when you work with a dataset that contains more than 500.000 visits or more than 1.000.000 items (keywords/url's/etc). Above that Google takes a sample of all those visits to calculate the numbers for your reports. But what is acceptable? In this example Google uses 30.62% of all visits to guess what the other 70% did on my site...
Last months I had quite some clients that started a content experiment but didn't see data comming in:
In almost all those cases the solution was pretty easy: they had a custom Google Analytics code for multiple domain tracking. And that means you need to make some changes to the Content Experiments script also. This is an example of a changed Google Analytics tracking code:
In this case an image says it all:
Looks familiar? No? I certainly hope this wouldn't happen to you. What happened in all these 3 examples is the start of a well implemented Google Analytics account. Before that the site's owner thought he had a lot of visitors that did a lot of small visits. While the real situation showed him there where a lot less visits, that lasted longer and had more pageviews. But he sold his advertising based on the skewed numbers...
I'm pretty sure a lot of you have dealt with this issue in the past. Someone puts a link on a specific page and after a while they ask you how many clicks it got. But in the main menu and footer are links to the same page also... Google Analytics can only report on how many people went from page A to B, but not which specific link they used.
Take a look at this blogpost:
A quick post about a new feature Google released quietly: it's possible to raise your site speed sample rate from 10% to 100% if you want. Especially small sites can take advantage of this. How often have you seen this:
A very low sample of pageviews where a page load time calculation is done. This leads to a very bumpy graph in actual page load times. And that is very annoying if you want to analyze your "bring my page load time down" efforts, You can only significantly say something about it if you have at least a week of data. And we all want to see results right away 😉
Last October Google added a cool feature to their Analytics suite called Goal Flows. That feature is really amazing and helped my find a lot of 'problems' in several sites. Back in the old days we had the old funnel that looked like this:
It was a very helpful funnel that provided some insights in the way people went through an ordering process. But there were also some huge problems with this funnel:
A lot of site owners want to track outbound links so they can see how often they are clicked. It's also useful to see when and where people left your site. Google Analytics knows the exit time of your last page, where in normal cases the last visited page is not counted in the spend time on site/page.
But, there is a big but. A lot of outbound link tracking is done like this:
<a href="http://andrescholten.nl" onclick="trackClick(this)">Nice site</a>
And this is what happens when you click on this outbound link:
- The onclick is executed first
- The trackClick function generates an IMG element with a URL that points to the Web Analytics vendor
- The onclick function is handled and the browser starts with the href part
And then the race starts:
Since the start of the new Google Analytics version (V5) we're unable to export more than 500 rows to for instance Excel. I figured there must be a solution to raise that number to 10.000 or more, so I started coding.
In the old Google Analytics there was the "&limit=10000" parameter that you could add to the export URL. In the new interface you can select the amount of rows below the table:
And after everything is loaded you can export those 500 with the usual export button.
With the new release of ga.js this is possible. In the old days a fired event immediately after a trackPageview would cause Google Analytics to report a 0% bouncerate for that visit. But sometimes you don't want that behavior because the event is not always triggered by the visitor.
For instance: I track page load times the same way Google Analytics does, but in an unsampled way (Google only meausures 10%). To do that I fire an event immediately after the trackPageview, but I do that in another profile with a different UA-XXXX-Y number so it won't affect my bouncerates. But now we have an extra parameter:
_trackEvent(category, action, opt_label, opt_value, opt_noninteraction)
If you set this opt_noninteraction (boolean) to true it wil not affect bouncerates!!! That makes it possible to:
A small blogpost about a new version of the ga.js file that was launched a week ago. As you can see they changed the way customvars are being reported:
"Fixed a bug in Custom Variables that caused some values to be encoded in reports."
Spaces (and other characters) were reported as "%20". So if my name was in a customvar it would look like this: