Site Speed reports in Google Analytics

A small refresher course in how you deal with site speed reports and page timings in particular. As Google announced site speed to be one of the ranking factors the issue got more ‘real’ – a wast number of articles show the importance of site speed and its effect on the business outcome (a recent one by Stéphane Hamel shows some numbers – link) yet the most important thing is the end user which may or may not like slow loading pages.

This article will present 2 simple things:

  1. Technical manipulation of the site speed measurement
  2. Averages suck – drill down

How to set the site speed feature for Google Analytics (Page timings)

Some basic facts:

  1. Site speed info is sent without any additional GA code needed
  2. Site speed info is sent with pageview hits
  3. Site speed sample can be increased reduced with additional code
  4. Default site speed sample size is described here

The implementation part if you want to manipulate the sample size is quite easy as you only need to slightly adapt the basic GA tracking code (info on the siteSpeedSampleRate field):

ga('create', 'UA-XXXX-Y', 'auto', {'siteSpeedSampleRate': 50});

Note that the values expected are 0-100. The default value, without any code adaptation, is 1%.

With GTM it is even easier to do this. It also allows you to be flexible if you want to determine for which part(s) of the site you actually want to see a larger sample – more important parts of the site.

For instance if you by any chance use dynamic remarketing there already is a variable present which you can freely use such as ecomm_pagetype which provides info on the page type viewed (conversionintent, searchresults, category, product etc.).

A simple example of how to set siteSpeedSampleRate in GTM

This example is based on the assumption you already have dynamic remarketing variable present on the site (if not you can always create a customJS variable and set the siteSpeedSampleRate based on Page URL or similar).

Variable 1 – fetch the ecom_pagetype value (example based on dataLayer)

Screen Shot 2016-02-12 at 09.29.34

Variable 2 – set the siteSpeedSampleRate based on value from ecomm_pagetype variable

Screen Shot 2016-02-12 at 09.31.07

Just to explain a bit we set the input values as expected strings from the ecomm_pagetype variable and set the output as values used for the siteSpeedSampleRate field – a lookup table variable is used in this case. And one additional thing if the variable does match any of the explicitly defined strings we set the default value to 1 (you can freely change this to any number you prefer (0-100)). By doing this you effectively increase the chance the timing hit will indeed be sent.

The Google Analytics Pageview Tag – one and only in this case 

Screen Shot 2016-02-12 at 09.32.30

The only thing you need to set inside your main Pageview tag is the Fields to set part – Field Name: siteSpeedSampleRate and Value: {{util – siteSpeedSampleRate}} (or any other variable name you set). Publish.

The results

Nicely described here –  https://support.google.com/analytics/answer/2383341?hl=en&ref_topic=1282106.

The averages suck part

With page timings be very very careful when analysing data as for some pages the sample can be so small it can easily lead you to wrong conclusions.

A small example on data collected from this blog. When looking at Behavior > Site Speed > Page Timings report there will probably be pages which are above or below average for a metric such as avg. page load time.

Screen Shot 2016-02-12 at 09.49.28

Issue detected? Of course you would need to check if that page has an obvious reason as it can be resource heavy so try not to compare to average but with similar pages (page types – use Content Grouping!). A very simple approach to continue detecting the reason if nothing obvious is found – secondary dimension. Just click on the page in question inside the table report and add a secondary dimension which will reveal the context – as an initial idea try Country, Device Category, Browser or similar. For example:

Screen Shot 2016-02-12 at 10.00.03

Yes, our site on mobile sucks. But do not be hasty in making such decisions – always use an additional segmentation to prove this hypothesis. So lets see the issue with an another Secondary dimension:

Screen Shot 2016-02-12 at 10.05.49

Now you can definitely see  there are some outliers (in a sucky small sample of data) which affect the average heavily which can defeat any initial hypothesis we created.

Standard reports will only get you so far. For more in depth look at the issue create a Custom report which will allow for a more granular look at the data and some more metrics (more appropriate). Create something like this – custom report link where it is much easier to find the ‘real’ culprit and act on it.

 

 

 

Leave a Reply

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