GA Flash Audit – Snow and Rock
04/07/2013 | Written by | Categories: GA Flash Audit

This is a Google Analytics Flash Audit performed on the Snow and Rock website.  It evaluates their implementation of Google Analytics and makes some suggestions as to what can be done to improve the usefulness of the data via the configuration or an improved implementation.

Note that L3 Analytics does not have access to the Snow and Rock Google Analytics account so all comments made are based on observed implementation of their website.  It is entirely possible that some of the recommendations are already in place or being achieved through other means.

Basic Details

Company Name: Snow and Rock


Code on Website

Snow and Rock is using the old synchronous version of Google Analytics (outdated since 2010) on most of the website. The blog has the asynchronous tracking code through Yoast’s WordPress plugin.

They still have the tracking code for the A/B testing tool Google Website Optimizer which has been replaced since June 2012 by Google Analytics Content Experiment.

Snow and Rock has several tracking codes on their website:

  • SLI systems (merchandising)
  • myThings (retargeting)
  • SaleCycle (retargeting)
  • AppNexus (advertising)
  • RightMedia (advertising)
  • Facebook Exchange (advertising)
  • Bazaarvoice (review platform)
  • AddThis (sharing platform)

They don’t use any Tag Management Systems (TMS).

Google Analytics code

Standard code

There were no pages encountered that did not contain Google Analytics code.

The GA account number was consistent across all pages on the main website (UA-3618498-1). The blog and the mobile websites are tracked through different web properties (UA-3618498-4 and UA-3618498-5). This separation makes sense because they are independent websites with different behaviours.  However it does mean top products across the mobile and desktop websites cannot be easily identified.

Internal search pages are hosted on the subdomain The subdomain tracking code is correctly implemented on those pages but it needs to be added to the main domain.

Virtual page views are used to add search query parameters at the end of page names instead of anchors (/search#w=running shoes becomes /search?w=running). This is the correct approach to allow Google Analytics internal site search reporting to be set up.

All pages in the checkout process including the Basket page use virtual page names.  This greatly improves the usability of all page name related reports in GA around this section of the website.

Additional Variables

No custom variables were encountered during the exploration of the Snow and Rock website.

Events were encountered during the exploration of the website on list pages filters but the information sent to GA is wrong (utmac=UA-XXXXX-X). The tracking code placed in file listing.js contains the asynchronous version of event tracking. Updating GA standard code should fix the issue.

Marketing Campaign Parameters

Snow and Rock has been identified as using a number of marketing channels including Twitter, Facebook, Google+, and email.  None of the Social Media links are tagged with GA campaign parameters that will enable this marketing to be identified within Google Analytics.  Emails are tagged following a strong campaign name convention.

Potential Configuration of Google Analytics

Internal (Site) Search

Snow and Rock is able to set-up Internal Search reporting.  They need to set the parameter “w” as the query parameter within the Profile Settings.

Page Names

To maximise the usefulness of web analytics reporting and analysis, page names should be recognisable as relating to a particular page on the website and follow a hierarchical structure.  If they do not naturally follow a strong naming convention, pages can be renamed as part of the configuration of Google Analytics.  For an ecommerce website, pages are grouped into three sections: ecommerce pages, checkout process (Basket page through to Order Confirmation page) and non-ecommerce pages.

Ecommerce pages

There are some pages in this section which do not follow a strong page naming convention.  Pages that should be renamed in the configuration are:

  • Department pages
    • Apply a profile filter that renames the specific department pages as /department/<department name> e.g.
      • Field A -> ^/all/([a-z0-9-]+)/fcp-category/
      • Output -> /department/$A1

  • Product List pages
    • Apply a profile filter that renames all product list pages as /product-list/<department name>/<sub category name> e.g.
      • Field A -> ^/([a-z0-9-]+)/([a-z0-9-]+)/fcp-category/list
      • Output -> /product-list/$A2/$A1
  • Product Detail pages
    • Apply a profile filter that renames product pages as /product/<department name>/<sub category>/<product name>/<sku code> e.g.
      • Field A -> ^/([a-z0-9-]+)/([a-z0-9-]+)/([a-z0-9-]+)/fcp-product/([0-9]+)
      • Output -> /product/$A3/$A2/$A1/$A4

Checkout Process pages

Pages in this section naturally follow a strong page naming convention with most pages using virtual page views.

Non ecommerce pages

Pages in this section naturally follow a strong page naming convention.  It could be enhanced slightly for many of the standard website pages by using a profile filter that renames some of these pages as /information/<page name> e.g.

  • Field A -> ^/[a-z0-9-]+/content/fcp-content
  • Output -> /information/$A1


It is recommended that if not already set-up, Goals are created for the following website actions based on the existing implementation and previously suggested configuration:

Macro Conversion Events

  • Place Order
    • One goal includes a funnel for the stages of the ecommerce funnel
    • The same goal but the funnel reflects the pages within the checkout process

Stages of the Ecommerce Funnel

  • View Ecommerce page
    • Any of Department, Product List, Product Details or Search pages
  • View Product List page
  • View Basket Page (as a proxy for create basket which cannot be tracked)

Micro Conversion Events

  • Contact Snow and Rock
    • The thank you page for submitting the contact form
  • Sign up to Newsletter
    • The thank you page for signing up
  • View Gift Voucher page
  • View Store Locator

Recommendations for an Enhanced Implementation

Page Tracking Code

Snow and Rock is currently using the old traditional tracking code. This version of the tracking code still works so they could leave it as is. However, we have noted that they need to enable subdomain tracking on the main website so could use this opportunity to switch to Google Analytics asynchronous code.  If so, their standard page tag should be placed just before the </head> tag and would be:

<script type=”text/javascript”>

var _gaq = _gaq || [];
_gaq.push([‘_setAccount’, ‘ UA-3618498-1’]);
_gaq.push([‘_setDomainName’, ‘’]);

(function() {
var ga = document.createElement(‘script’); ga.type = ‘text/javascript’; ga.async = true;
ga.src = (‘https:’ == document.location.protocol ? ‘https://ssl’ : ‘http://www’) + ‘’;
var s = document.getElementsByTagName(‘script’)[0]; s.parentNode.insertBefore(ga, s);


Tag Management System

Snow and Rock has several tracking codes for different purposes: analytics, merchandising, display, SEM, retargeting etc.

To manage rules and obtain more flexibility, they could implement a tag management system like Google Tag Manager.


Custom Variables

It is recommended that the following custom variables are tracked:

  • Visitor
    • Customer ID
      • set when a purchase is made or when a visitor logs in to the website and is recognised as having previously made a purchase
    • Visitor Type
      • Identifies the visitor as a guest, existing customer or registered user (who hasn’t yet purchased)
  • Page View
    • On the Product Details page
      • Availability
      • On Sale flag
      • Method used to access product details page
    • On the Search Results page
      • Number of search results returned
    • On form validation errors
      • Include name of the form, first field that triggered the error and the error message
    • On 404 Page Not found errors
      • Include URL of the page and referrer to the page


It is recommended that the following actions on the Snow and Rock website are tracked as events:

  • Visitor login
    • Include method of logging in, number of previous orders and their value
  • View Product Info & Care and Delivery & Returns tabs on Product Details pages
  • Clicks on product images on Product Details pages
  • Clicks on internal promotional boxes/links
  • Clicks out to Social Media networks
    • Using Social Events as appropriate
  • Clicks on add to my shopping bag
    • Include category, brand and product names to measure a product level success rate
    • Capture the value of products added to basket to enable Snow & Rock to calculate the value of abandoned baskets

Key Ecommerce Investigations

Analyse the Ecommerce Funnel

Not all stages of the ecommerce funnel can currently be identified and reported on.  The stage which cannot be measured is:

  • Create Basket
    • No measurement is recorded when a product is added to the basket

Create a Merchandising Report

It is not possible to create a Merchandising report for Snow and Rock due to no measurements being captured when visitors add a product to their basket.

Analyse Performance by Entry Point

With the recommended configuration in place for department, product list and product pages, it will be possible to create a report comparing % Entries, Bounce Rate and Conversion Rate for different website entry points and different traffic sources.


Snow and Rock currently has a basic GA implementation.  The page naming convention don’t follow a hierarchical structure and could be easily improved using Google Analytics profile filters in the configuration.

The biggest issue is they don’t record the number of baskets created.  As a results, they have no visibility of performance through the ecommerce funnel and no method of evaluating performance at a product page level. If they used events on the add-to-cart button, they could then set up merchandising reports.

The subdomain tracking code needs to be updated. They are still using the traditional Google Analytics code and could use this opportunity to switch to asynchronous one.

There is a seriously large level of additional information they could easily capture. For example, there is no visibility on 404 error pages. They could also start tracking the customer ID to perform cohort and multichannel analysis.

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