Google Analytics Page Level Custom Variables
13/09/2011 | Written by | Categories: Analytics Set-up

Hand holding colour cards

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.

Picture of coloured balloons

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.

Sample set-up for a custom report for page level custom variables

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?

15 responses to “Google Analytics Page Level Custom Variables”

  1. Definitely agree on request to Google. Different CV type should be in different set of reports. Makes sense.

    • Peter O'Neill says:

      Thanks Paolo, it does seem like one of those changes which is in line with Google trying to make the UI more intuitive for users. Will raise it next time I get to chat with a Google Analytics person.

  2. Kayden Kelly says:

    Great write-up on custom variables, Peter. What are your thoughts on how to use the additional 45 custom variables that are now available to Google Analytics Premium clients? Do you think this adds a lot of value and is a key reason to move to Premium? Interested to hear your take.

    If you have a moment, check out our post discussing the additional CVs. It would be great to hear the thoughts of another Google Analytics consultant.


  3. Kayden Kelly says:


    I forgot to say that I too agree with your proposal. It is a great idea which is definitely needed to help users avoid misinterpreting data.

    Also, I believe the unsupported workaround to bypass the 5 custom variable limit has been eliminated. Google intended to eliminate this workaround before Google Analytics Premium launched since this was one of the key features that justify the cost for Premium.


    • Peter O'Neill says:

      @Kayden Thanks for your comments and apologies for not replying sooner. I see the SLA, extra processing power and support as much greater selling points for Google Premium than the additional custom variables actually. I think it is a nice to have but how many companies not only have all five slots currently implemented but are actively using the data from them?

      I am tending to equate page level CVs to SiteCatalyst s.prop (visitor CVs to eVars) and so I totally expect companies to use all 50 if they upgrade to Google Premium just like so many use 50+ s.props and 50+ eVars. But the issue for companies in optimising their business performance is generally not having enough detailed data, it is not being able to understand/use the data they already have. Hence more support, faster reports and recognition from the C-level due to a SLA and signing a cheque are more important.

      In terms of ways to use the additional CVs, as per the comment comparing them to custom variables in SiteCatalyst, I would expect them to be used to capture similar data.



  4. Kayden Kelly says:

    @Peter Agreed, you are absolutely correct in your prioritization of Premium benefits. The SLA is an absolute requirement for many organizations and the value of the support is tremendous.

    There is definitely an analytics maturity model that should be followed with each client and when they get to the later stages it is a lot of fun to help them take advantage of the power of the extra custom variables. Unfortunately, full utilization of custom variables, much less goals, doesn’t happen enough but it should happen with all Premium clients because the strategy and setup of the extended custom variables is included.

    Anyway, I am glad that I came across your article which led me to learn more about your organization. Keep up the great posts and I look forward to further conversations with you and your team.

    • Peter O'Neill says:

      Thanks Kayden, I look forward to further discussions and transfer of knowledge back & forth as well. And I do agree that if a client has invested in Premium, they will be doing a thorough implementation including using far more than the standard 5 custom variables.

  5. Jenn Kunz says:

    Thanks so much for this post- we needed a confirmation about what the visits metric meant in the CV reports and this post is the only thing we could find that addressed it. Very helpful!

    • Peter O'Neill says:

      You’re welcome Jenn – glad that you found this useful. I get the feeling people just aren’t taking full advantage of the page level custom variables in GA, they are incredibly powerful when combined with custom reports. I need to write a follow up or two and provide some examples on how I am using them.

  6. robbin says:

    Hi Peter,

    Thanks for your post. Now I am using Custom Variables in my site, but there is a wired problem, can you help me?

    I add 2 custom variable,

    _gaq.push([‘_setCustomVar’, 1, ‘UID’, ‘$uid’, 1]);

    _gaq.push([‘_setCustomVar’, 2, ‘Category’, ‘$category’, 3]);

    Then I created 2 segments, the one is ‘include category equal ‘normal’, the other is ‘include category equal undergradschool’.

    The report is like (the 2nd column is PVs)

    cate-undergradschool 249 195 00:01:23 0.00% 10.04%
    All Visits 602 518 00:01:23 57.70% 50.00%
    cate-normal 602 518 00:01:23 57.70% 50.00%
    cate-undergradschool 137 124 00:01:40 82.09% 58.39%
    All Visits 137 124 00:01:40 82.09% 58.39%
    cate-normal 64
    so the problem is ‘harvard-univeristy’ is an undergradschool category, so there should be no cate-normal visitors, and top/university is a normal category, so there should be no cate-undergradschool pvs, do you why?

    Thanks for your time.

    • Peter O'Neill says:

      Hi Robbin,

      Ok, on a side note first – you appear to be capturing a user id in the first custom variable. This is personally identifiable information which you cannot capture in GA under their ToS, I highly recommend removing that custom variable (plus I don’t find individual tracking useful).

      To your question. You have created segments for visits that include a particular custom variable. But within that single visit, the visitor may have viewed both types of pages, hence why they appear in the reports against both segments.

      I believe what you are after is a breakdown of the number of views & visits to all pages within each category. For page level custom variables, I always recommend using Custom Reports. Your metrics should be pageviews and unique events (proxy for visits) and your dimension is customVarValue 2. Set a filter of customVarKey 2 = category and you will only get data for this custom variable. Should give you everything you need.



  7. Alex says:

    Hi Peter,

    Wonderful post.

    Have you ever seen ‘event value’ and ‘ave. value’ metrics being used alongside ‘total events’ for page level custom variables?


  8. Alex says:

    Hi Peter,

    Can’t say that I have either.

    From the limited attempts at usage, the data tends to raise more questions than answers and leads to a retreat to the comfort of event tracking instead.


    • Peter O'Neill says:

      I think it goes back to what you are using it for. I have been fine to use page level custom variables to capture more information on pages being viewed – no need for event value metrics. I only use Unique Events as the best proxy for visits.

Leave a Reply

Your email address will not be published. Required fields are marked *

Looking to improve your digital analytics or conversion rate optimisation?
Contact us today on +44 (0)20 7148 5970

Alternatively, come visit us in London and we’ll buy the coffee!
Get in touch
Leave us a message
Use the form below to leave us a message.

Lindsey Street