How to set up “trackPageview” or “pageview” in Google Analytics

When you implement Google Analytics on your website, the code that you absolutely must put on every page will look as follows:

//ASYNCHRONOUS – GOOGLE ANALYTICS

<script type="text/javascript">
  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-xxxxxxx-x']);
  _gaq.push(['_trackPageview']);
  (function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
  })();
</script>

OR //UNIVERSAL – GOOGLE ANALYTICS

<script>
  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
  })(window,document,'script','//www.google-analytics.com/analytics.js','ga');

  ga('create', 'UA-xxxxxxxx-x', 'siteURL.com');
  ga('send', 'pageview');
</script>

There are two basic ‘calls’ in the above code:

  • the account creation: ‘_setAccount’ in Asynchronous, or ‘‘create’ in Universal – we are NOT going to discuss this specific call
  • the page view: ‘_trackPageview’ in Asynchronous or ‘pageview’ in Universal – we ARE going to talk about this call method

You have two options when it comes to tracking pages when you first set up Google Analytics
a) do nothing: leave above page view code as is
b) customize the code

On the following pages we are going to use Target.com as an example; we are also going to provide examples in the context of Universal Google Analytics – which is directly applicable to the Asynchronous Google Analytics.

What happens when you a) “do nothing”?

On Target.com, assume you go to women -> clothing -> activewear:

Target.com categories

Google Analytics Site Content Menu.

How will Google Analytics capture the name of this page?
If you go to the Content report in Google Analytics, and you view Site Content/All Pages….

…you will see something like this.

Here is the PROBLEM: what you see in Google Analytics under Page, will have nothing to do with the fact that the ‘breadcrumb’, the steps that the visitor took to get to this page, and the navigation itself, follows home -> women -> clothing -> activewear.

Which brings us to what we recommend you should do, i.e.:

b) customize (or over-write) ‘pageview’.

If you go to that same page on target.com, you will see that there is actually a ‘breadcrumb’ visible, that corresponds to women/clothing/activewear:

We recommend that you pass that ‘navigation logic’, into the ‘pageview’ variable.

Tip breadcrumb:
On Target.com that >women>women’s clothing>activewear breadcrumb happens to be visible – that makes your job very easy when communicating to the site dev team what it is that you want them to populate in ‘pageview’.


However, on websites that do not have that visible breadcrumb (it is ‘invisible’), that breadcrumb logic does in fact exist somewhere in the site code; that’s because the website has to ‘know’ what to show you when you click on top nav or sub-nav pages; ask the dev team if they can populate that ‘breadcrumb logic’ into ‘pageview’ – they should understand what you are asking them to do)

b1) How do you customize ‘pageview’ – the “better than doing nothing” way

One way to customize ‘pageview’ is to just ask the front-end developer to pass the actual visible breadcrumb into ‘pageview’. That means that when the Activewear page loads, if you were to right-click on the page to ‘view code’ you would see in the Google Analytics java script area:

ga('send', 'pageview',’/women/womens-clothing/activewear’);

Now, when you go to Google Analytics, you will see:

That’s definitely easier to ‘read’!

b2) How do you customize ‘pageview’ – the Recommended way

In fact, the above b1) “second best” approach is better than doing nothing, but … this method is still not optimal.

The optimal and Recommended method is one where you can easily FILTER your content, using the filter in Content (or, through the Google Analytics API):

What you really want, is a page naming taxonomy for ‘pageview’ where you can easily FILTER by

  • level 1: pages such as Baby or Kids
  • level 2: pages such as activity gear & toys
  • level 3: pages such as bouncers & rockers

(here: level1 = top nav items; level2=major bolded merch areas; level3=not bolded sub-merch categories)

How do you structure ‘pageview’ taxonomy that’s super easy to ‘read’ AND filter by?
Add a L1 etc designation in the pageview taxonomy, such as:

  ga('send', 'pageview',’/L1_women/L2_womens-clothing/L3_activewear’);

Now, in Google Analytics, you can easily FILTER by

  • sum of pageviews to L1
  • sum of pageview to L2

or

  • create an Advanced segment between people who view just L1
  • visitors who get to L1_baby, AND to L1_kids
  • etc etc

What’s next?

In the next post we will talk about page naming taxonomy for:

  • product pages, and
  • cart pages

Greg

Posted under Google Analytics by Greg Sobiech on 9th October, 2013

4 Comments
Send to a friend

4 comments + Add a comment

Aurélien Bouchard
October 11, 2013 at 8:44 am

Interesting post !
Easy to read and to understand.

But I would like to know : what is the add-value of this method if we already have set up event trackings on each “level” ?

    Jeffrey James
    October 12, 2013 at 10:00 am

    Aurélien – good question. There’s a tension between this method and using events. Also, with the new content grouping feature, soon the methodology will become even less important as the analytics tool becomes smarter and the reliance on developer time and manual coding in general, lessens.

    That being said, the biggest advantage is usability for the client – some people don’t want to understand high dimensional events. If your site has 5 levels, the custom event may not even work and you’ll have to concatenate values within the event or split it into 2 events, hence the usability degrades.

    From a goals set-up standpoint, either is fine ever since event based goals came out in GA. The page flow report may also be easier to interpret for some in contrast with the event pathing report. Lower threshold to insights.

    Lastly, in defense of the method, if you have lots of ‘true’ virtual pageviews in the web experience: quick-view, overlays, site-shades, etc…which do require a virtual view or event to track, if the step is truly significant to the visitor and the experience is such that it does seem like a page in the process, at least there’s all grouped together logically in a ‘pages report’.

    In conclusion – do whatever can get done as quickly as possible and maintained over time :) . We are looking for to Google Analytics new content grouping feature so when we’re on-boarding clients with messy URL structures and 1000′s of pages, we may be able to get a clean view on content without touching any javascript.

    Jeff

greg sobiech
October 12, 2013 at 12:39 pm

One trend that neither Content Grouping in Google Analytics, nor events or any other method can universally cover is the increased usage of modal windows/overlays/AJAX, or whatever you decide to call pages that don’t generate an explicit URL.

I think that in creating a view on page taxonomy one should go after several approaches all at once, and see what works best – for you as an Web Analyst, for the Marketing/Merchandising/Content staff, and for your Dev team that will have to execute on your directions.

If you look at eg ZephyrHillsWaters.com (enter a FL ZIP to enter), Dimension Widening, Events, nor any other method will fail because ultimately you need to explicitly define pages that you would normally classify as “virtual” (ie overlays/modals, etc).

Now, the new Google Tag Manager feature around the “listener tags”, that well, listen to clicks and can be translated into events, or really any other ‘hit’ (such as pageview), may be the ULTIMATE cleanest solution – all pages should theoretically, assuming each click on nav or an element creates a change in the jv that GTM can listen to.

I wrote this article a month ago, before, before GTM ‘listener tag’, or Dimension Widening, were announced.

If it were me, I would apply the above (now maybe ‘old school’ method), with L1 etc + events + dimension wideing + GTM and listener tags, to cover all bases. Tagging always gets messed up during execution by Dev, having 2 or 3 ways to track the same interaction is probably the smart way to go.

Andrey
November 11, 2013 at 12:59 pm

What can be done in cases when there is no clear taxonomy on the site. For example a blog with articles in different subjects? but we need to aggregate data similar to L1, L2?
I think custom var can be an option. any other ideas?

Have your say

Thanks for your contribution.

You can use Gravatar to upload an avatar that will appear next to your comment.

Please be polite and respectful to others.

<