Google Analytics custom variables have been around for nearly two years now and while I find myself including them in implementations, I have not reviewed the results in detail. But opportunities have arisen over the past few months to perform more detailed GA implementations and to dig into the data for custom variables. This has led to some interesting discoveries, primarily around Page Level CVs.
To cover off the basics first, page CVs have a large variety of uses. Some can be general, (e.g. page type, page depth, site section) while others are specific to the type of the page such as:
- article page – author, category
- product page – brand, availability, price level
- search results – number of search results
The Google Analytics code for custom variables uses two parameters as settings for the variable and two parameters providing it with a name and value. These are:
- Index – the location the data is stored in, can be 1 to 5
- Name – the name of the custom variable
- Value – the value of the custom variable
- Scope – 3 for page level, 2 for visit level, 1 for visitors (defaults to page level if blank)
But enough about that, if you want to know more about the actual code, check out the Google Analytics documentation. And for details on how to implement and what the different settings mean and the basic uses, there are excellent posts from LunaMetrics (parts I to III) and Justin Cutroni. I want to talk about what I found interesting.
Length of Custom Variable Names & Values
A limiting factor with custom variables currently is that the combined length of their name and value cannot exceed 64 bytes. Hopefully Google will ease up on this restriction at some stage but it does mean you need to be careful with your naming convention. It is a lot of characters but easy to go beyond, particularly if you use an article name or a sub directory structure. This could be the reason for your custom variables not appearing in your reports.
Using Custom Variables with Events
Another factor that is reported in all the documentation and blog posts but doesn’t appear focused on is that page level custom variables are actually measurement level, not page level. This means they can also be associated with events, not just pages. You could even trigger multiple measurements on a single page (whether using events or virtual page names) and attach a set of custom variables to each one.
This allows you to get more descriptive around actions on the website as you are not limited to the three label parameters in an event. For example, you might be using an event to capture the details of an outbound link. This can be extended through using one page CVs to identify which section of the page the link was clicked from and a second to identify the position within that page section.
As with so much around the implementation of Google Analytics, the possibilities are limited by your creativity. I haven’t tested it but it wouldn’t surprise me if you could even include custom variables within ecommerce transaction measurements, allowing you more fields to describe customer/purchase behaviour.
More than Five Custom Variables
It is a well know fact that there is a limit of five custom variables in Google Analytics. Apparently there is an unsupported workaround in the code but I haven’t experimented with this. But this limit only applies to the number of custom variables that are in use at any one time. Now visitor & visit CVs apply to all pages on your website as do any page CVs which are implemented on all pages.
But say you are only using two of those (a visitor CV for registered users and a page CV for page type), then you have three slots to be reused for other page level CVs across the rest of the site. This is not three custom variables but three slots for custom variables. And as you are using custom variables for different purposes on different page types, you are not limited to a total of five custom variables. You can have three CVs on your blog pages and a different set of three CVs on your product detail pages. Events can even use four CVs as the page type CV won’t apply. So remember that the limit is five custom variables at any one time, not five custom variables in total.
Including Custom Variables in Segmented Profiles
Segmented profiles can be set up to include only visits that meet certain criteria or to include only data within visits that meets criteria. For the segmented profiles that target pages within visits, events and custom variables need to meet the criteria as well. But, the page name they use to compare against the criteria is the default page name (from the URL), not a virtual page name or a page name renamed by prior profile filters.
Do you need to use a Visitor/Visit CV?
In line with the observation earlier that you have more than five custom variables available if using non global page level custom variables, it make sense to avoid using visitor or visit CVs where possible. So have a think about what you are trying to accomplish. Are you creating a visit based CV for visitors who log in so that you can get the proportion who do and understand their behaviour? If so, can’t you just use an event or page level custom variable and then create an advanced segment around this – it will give you the same result.
Interpreting Metrics for Page Level CVs
The real fun for me started when I started to really look at the numbers for page CVs. The Visits number just didn’t look right, seemed much too low for many of the variables. I was using Next Analytics to extract data into Excel so reached out to Mike Sullivan for his thoughts and he pointed me in the right direction.
A Visit for page custom variable is only counted for the first value recorded – that is the first value per name, not per slot. It is not visits in which that custom variable value was viewed. If the custom variable is on all pages within a website, then Visits should equal Entrances. But basically it is a useless metric and frustrating as it appears within the default custom variable report (which appears designed for visitor/visit custom variables, particularly as described as a Demographics report in the new UI).
There is an alternative. Page views are a type of event and therefore the Total Events and Unique Events metrics can be used with page level CVs. Unique Events equates to Visits, the metric I was after, while Total Events is the total count of occurrences of that value, similar to Pageviews. So if using a page CV in a segment, Visits are fine. But if using it as a dimension or a filter, then use Unique Events instead.
Two more points. The metric Entrances only appears to be recorded if the custom variable is on the landing page for the visit. If the custom variable value is recorded for the first time on the second page, it will be a Visit for that value (and an Event) but not an Entrance.
And everything I have said here also applies to Pages. It is why Unique Page Views is used in content reports instead of Visits and why you can use Unique Events and Total Events metrics with Pages as a dimension. Just keep that in mind when using page names in a filter when creating custom reports, dashboard widgets or extracting data via the API.
Using Page CVs in Custom Reports
Which leads into the next question, how do you access this data. The answer is to set up custom reports for all your page level custom variables and use these instead of the standard reports. You can set filters for only a particular custom variable name so can customise the report to show the exact data you want. Another option is to set up widgets within GA Dashboards to report on similar information.
Request to Google
So it appears that page level custom variables behave quite differently to visitor/visit level custom variables. The output is not Demographic reports but Content reports. In a way, it is similar to the difference between s.Props and Evars in Omniture SiteCatalyst, one is a traffic/content metric while the other is persistent with Goals/Conversion Events as the key metrics.
But I digress. My request to Google is to create a new set of custom reports and include them in the Content section of the new GA menu structure. Leave all visitor/visit custom variables in the existing Demographic reports section (you know which variables they are) but move any page level custom variables to this new set of reports. It will make sense to users and reduce the risk of misinterpreting data. Do people agree/disagree with this proposal?