Segments are one of the most powerful features of Google Analytics, and they are often useful for zeroing in on the sets of users who are most valuable to us.
One way of looking at potentially valuable users is to look at the frequency with which they visit the website. Let’s look at a couple of ways to do that in GA.
You’ve heard the term “statistical significance”. But what does it really mean? I’m going to try to explain it as clearly and plainly as possible.
Suppose you run two different versions of an ad, and you want to know if the click-through rate was different (or you are comparing two different landing pages on bounce rate, or two campaigns on conversion rate). Ad A has a click-through rate of 1.1%, Ad B is 1.3%. Which one is better?
Seems like an easy answer: 1.3% > 1.1%, so Ad B is better, right? Well, not necessarily.
Consider a quarter
Suppose you have a quarter (and it’s a fair quarter, no tricks). The rate of getting heads when you flip should be 50%, right? If you flipped the coin an infinite number of times, you could expect it to come out heads half the time. Unfortunately in web analytics, we don’t have time to flip the quarter an infinite number of times. So maybe we only flip it 1000 times, and we get 505 heads and 495 tails. Do we conclude that heads are more likely than tails? What if we only flip it 100 times, or 10?
You can see that sometimes, the difference we measure is merely due to chance, not to a real difference.
You already know about event tracking in Google Analytics and using it for everything from downloads to video plays. Maybe you’re using jQuery or Google Tag Manager to capture events.
One thing to note about events is that, by default, events affect the bounce rate. That is, if a user lands on a page and an event is triggered, they are not a bounce (even if they don’t view any subsequent pages). In many cases, that’s what you want: after all, if someone engages with the page in some way, you probably don’t want to count them as a bounce any more.
However, you have control over whether those events affect bounce rate. There’s a parameter you can send with the event data to decide this called the “non-interaction” parameter. In a case where a video auto-plays when someone lands on the page, for example, we might want to set the non-interaction parameter so that the bounce rate of that page isn’t zero.
URLs are often one of the most problematic labels for data in web analytics: they’re messy, full of inconsistency, gunked up with a bunch of query parameters that may or may not be useful to you. It tends to make analyzing your content a mess.
Here, sort this stack of needles.
There are a number of suggestions for cleaning up those URLs (more…)
Back in May, Google announced that GA Premium customers would be able to export analytics data to BigQuery. It’s now rolling out to all Premium customers. What does this really mean? What’s it let you do beyond what you could before?
How do you access the data?
BigQuery stores your GA data in what is basically a giant table. It gives you a SQL-like interface to query that data, either through a web interface or programmatically.
If you use Google Tag Manager or another tag management tool, you’re probably already familiar with the idea of a data layer. It’s basically a centralized place for information about the page to be passed to analytics and other measurement tools.
Up to now, there have been some informal conventions in tools like GTM. But it would help us all to have some standard guidelines, for interoperability between tools. So, if you need to switch from one tool to another, you can easily do that without rearranging the data. Or, if you build a plugin for a content management system, you can build to the standard and not worry about which tool it will be used with.
So a W3C Community Group was assembled to tackle this problem, including 56+ organizations (including Google Tag Manager) providing input on a specification that is standardized enough to provide interoperability, without being too rigid to represent many different industries and websites. (LunaMetrics also participated in the development of the specification.)
After much deliberation, version 1.0 of this specification has been published. Let’s take a look at what it says and does.
If you pay attention to developments in Google Analytics, you were probably glued to the live stream of the Google Analytics Summit opening presentations. GA made a number of announcements about forthcoming features. One of the most exciting is about automatically tracking events in Google Tag Manager. It’s a feature that’s been highly requested ever since Tag Manager was released, and it’s especially exciting because it’s available NOW (unlike a number of the other announcements, which are only “coming soon” — such as a forthcoming SLA for Tag Manager for Google Analytics Premium customers).
But, if you go and take a look at Tag Manager trying to figure these out, you might find yourself scratching your head over documentation that is mostly “coming soon”. Not to worry: I’ve banged on the pipes, and here’s a guide to how it all works. (more…)
Implementing Google Analytics can be pretty easy: copy and paste the code, hopefully into some sort of template file that’s used on every page on your website. Done!
But you know it’s not always that easy. First, there’s not just one template, of course, there’s that special one for the landing pages, oh, and this application on our subdomain uses a whole different server. Oh, and you wanted to put some AdWords tracking code or another tool on all those, too?
Then, of course, you’re not allowed to just copy and paste code into the website. It has to go into the update and testing queue, and three months later, if you’re lucky, it will go into production.
A tag management tool can help you with some of these issues. It’s not a cure-all, and it’s not necessarily any better for you if you don’t face these kind of issues, but if you do, it can pave the way for an easier experience. (more…)
Colliding galaxies, because the universe
Google Analytics has great site search tracking features, but they rely on the URLs of your search results pages having a query parameter (the part of the URL after a question mark, with something like “?searchterm=testing” when you search for “testing”). There are ways around this to track site search without a query parameter (that’s an oldie but still a goodie from 2010), but all those workarounds involved adding or altering the code on your site in some way. But now there’s actually a new way to go about this for some URL structures that involves no code at all. (more…)