Defining Page Names for Google Analytics

Note: This post has moved from Leapthree.com to Ayima as part of the 2018 acquisition.

One of the more frequent questions we receive from clients is “Why are you wanting to rewrite all the page names, what is wrong with just using the URLs?”. It is something we feel is critical in the set-up of Google Analytics and this blog post is intended to provide the reasons why.

By default, page names in Google Analytics are taken from URLs, just losing the domain name.  What appears to not be widely known is that you can override the default page names, replacing with your own page naming convention. It is an early task for every Google Analytics implementation that LeapThree performs.  Note that no URLs are changed in this process, we override the page name variable in Google Analytics plus record the URL in an alternative variable.

Benefits of rewriting page names

The work to rewrite all the page names on a website is an investment though and I have no issues with clients questioning this use of developers’ time.  I was once asked, by doing this work, what new information the client would get in their analytics.  My response was that, actually, no new information would be captured.

BUT

Reports which currently take me, as a Google Analytics specialist, half a day to produce, would take anyone in the organisation (with a minimum of Google Analytics knowledge) minutes to produce after the new page naming convention was implemented. Given these time savings, the other benefit of the work is that since Google Analytics is easier & faster to use, the use of it increases throughout the organisation.

Create a page naming convention

There are two tasks involved in rewriting page names, the first being to create the new page naming convention.  This generally takes LeapThree half a day to a full day to complete, depending on the complexity of the website.  I will write a follow up blog post with details of the process we go through to produce a page naming convention, but an example of the logic for a retailer is as follows.

As is fairly clear, I retain the URL structure with elements separated by a / and using a ? to identify the start of URL query parameters (so search terms can be recorded using default Google Analytics functionality).

Implement the page naming convention

The second task is for a developer to implement the new page naming convention.  The time required to do this varies widely between businesses depending on the complexity of the website, the number of page templates in use, how well structured the website currently is and how quickly the developer learns the skills required to do this work (there appears to be a steep learning curve).  This seems to average around two days but can easily be five.

The actual coding part with Google Analytics or Google Tag Manager is quite easy. For hard coded Google Analytics, you simply need to adjust the line

ga('send', 'pageview');

to

ga('send', 'pageview', <new page name>);

If you are a sensible person and have shifted to using a Data Layer and Google Tag Manager, you need to add a Data Layer variable that contains the new page name.  Then within the Google Analytics page tag, or better still the Google Analytics settings variable, simply set the field “page” to the value of that Data Layer variable.

Not just a Google Analytics task

The title of this blog post and previous paragraphs all refer to Google Analytics.  However, all the logic within the post is actually tool agnostic.  The difference is people naturally rewrite page names for other tools like Adobe Analytics.  The Adobe Analytics page name can default to the URL but all the instructions for Adobe Analytics include the need to create a useful page naming convention.  This work should, in my opinion, be replicated for every business using Google Analytics that wants to use the tool properly.

My introduction to Web Analytics tools was initially with Nedstat and then being exposed to HBX (which has evolved to Adobe Analytics).  In both cases, rewriting page names was a default part of every implementation and so that has not changed with my shift to using Google Analytics.  For people who start off with Google Analytics, this needs to be part of their Digital Analytics education.

And this is not a new issue.  Two old blog posts that are still relevant on this topic can be found from Adam Greco and Alec Cochrane.  Given the importance of page naming conventions, there is a depressing lack of writings about it.  Hopefully this will inspire others to share their techniques.

What makes a good Page Naming Convention

There are three key characteristics of a good page naming convention.  Good in this case, is defined as a solution which saves users time and increases their usage of the data.

1. Each page is recorded against only a single page name

Multiple versions of a page name can cause users to misinterpret the data, thinking a single instance represents the entirety of the views of the page.  Then, if the issue is discovered, they need to filter on that exact page to get totals, not realistic when there are hundreds or thousands of pages that you need total metrics for.  Another issue arises when trying to use pathing reports such as the Google Analytics Navigation Summary, the scale doesn’t exist to get a clear pattern of previous/next pages.

The issue is generally caused by URL query parameters being recorded within a page name, generating multiple copies of the page.  It is also caused when URLs contain an ID that is meaningful to ensure the visitor looks at the exact right page but not meaningful when trying to understand page performance, e.g. a user id for an Account History page.

2. A logical and hierarchical structure is defined for page names

For most Google Analytics users, the All Pages report is the method used to review content performance.  They need to be able to apply a simple filter to review different types of pages.  Otherwise it requires an Excel export and manual sorting/identification of a group of pages – something that is likely to be too hard and therefore simply not happen.

URLs are typically either designed for SEO purposes or are default for a CMS.  In either case, they rarely contain the structure required for easy filtering, sorting and analysis; this requires common elements to be shared by similar pages.

3. The page name is intuitive so everyone in the organisation can identify a page based on the page name

The key factor for the usability of a pages report is that users should not need to think in order to identify pages based on their page name.  If people are able to immediately make use of the report, they are more likely to do so.  As per the previous point, URLs are not designed for analytics reporting and therefore don’t produce the pages names required to satisfy this point.

Quick test for your current page naming convention

So after all that, you may still not yet be convinced.  So as a quick test for your current page naming convention in Google Analytics, are you able to easily and confidently answer these questions using the All Pages report:

• How many page views were there last week for your homepage?
  • You immediately fail if you are not sure which one is your homepage in the report
  • Try filtering on ^/($|?) to confirm there are not multiple versions of the homepage
• Are there any pages that contain a user ID?
• What were your top 10 product or article (or equivalent) pages?
• Can you show all the pages within a process flow (e.g. checkout process) for your website with a single filter?
• Look down at the 9^th, 17^th and 33^rd pages, can you immediately identify these pages on the website without clicking through to them?

Compare your answers above to what would be possible if your homepage was called /homepage and if all your product pages started with /product/.

Caveats

Yes, there are always caveats.

First there are two pieces of Google Analytics functionality that break when you implement your own page naming convention.  These are the In-Page Analytics feature and the ability to click through to a page on your website using the links within the All Pages report.

I have always considered this a good trade-off given the power provided by a useful page naming convention.  I have never trusted the In-Page Analytics report entirely, if you want this data, either tag the links directly or purchase a customer analytics tool.  The ability to click through to the page on the website is useful but I always capture the URL in a content grouping so retain the ability to access these pages within a couple of clicks.

The other caveat is due to a quirk in the behaviour of Googlebot.  For some reason, as page names retain a URL structure Googlebot tries to crawl them, with the domain name defaulting to that of the page they are on.

The recommended workaround (assuming you have no more luck complaining to Google than we do) is to add /ga-virtual to the start of all pages.  Within Google Tag Manager, remove this element from the page names before sending to Google.  The task can also be performed using a Google Analytics View Filter.  Within your robots.txt file, exclude the sub directory of /ga-virtual (thanks to Phil Pearce for this workaround).

A request to Google

Finally, just a request to Google.  Life would become so much better/easier if you enabled a feature for separating page names and URLs.  This would be a signal that you are using a manual page naming convention, not defaulting to the use of URLs.  URLs would then be captured separately, easily accessed as a custom variable and used as the link for In-Page Analytics and for clicking through to website pages.

Most importantly, it would highlight this critical piece of the Google Analytics implementation so that it is used and benefited from more widely.