Over the past dozen or so years, I have been involved in 100+ web analytics implementations. These have primarily been of Google Analytics (GA) but also using various incarnations of Adobe Analytics and of course my days at Nedstat. Some have been from scratch, others have been re-implementations, fixes to existing tracking or enhancing what was in place. This work has been across all sectors, ecommerce, publishing, listings websites, finance, etc.
As any good Digital Analytics consultant will tell you, before any tracking code can be implemented, the consultant needs to know what you need to know. The business needs to define its information needs so the tracking can be designed against these future needs.
While that is correct, highly experienced Digital Analytics consultants might say that if the business wants to move fast, “just let me get on with it, I know what you need”. The solution won’t be perfect but it will contain 80%+ of your needs and will be delivered much faster.
A sector where this applies is Ecommerce. Fundamentally all retail websites are the same, they have the same purpose, page types and functionality. This post details out the web analytics set-up I recommend for any retail website. I use GA (Universal Analytics) specifics through-out but the same principles would work with any web analytics tool.
*** Updates ***
- This blog post was used as the basis of a workshop. The recording of that workshop can be viewed at this new blog post.
- While this blog post focuses on Universal Analytics, a new blog post covers the equivalent set-up for GA4.
- An audit checklist is now available for anyone to use. Get in touch if you would like me to perform this light audit for your organisation.
Defining what to track
When I first started working for myself (the first time, back in 2010), I had plans to create the most perfect web analytics implementations. I learnt quickly that this led to failure. The implementation instructions for developers were too big and would take too long to implement. Most information would not even be looked at unless specific use cases arose and/or the company matured in the use of data so it could consume more of it.
The result was projects being paused for many months during this set-up phase waiting for developer resources, for information that stakeholders would not use. I learnt from these experiences, capture less information focusing on what will be used immediately. These requests can be implemented fast which means delivering value sooner.
This diagram shows different levels of tracking that could be added for a website. The Basic level is adding the pageview tag (or the new GA4 tag) plus, for Ecommerce websites, capturing transactions as well. This level is depressingly common for small and big websites. It appears many times that web analytics is ticked off by the web development agency by simply adding a tag to all pages. It should go without saying but if this is the level of analytics tracking you have, you cannot do analytics properly.
Instead, you need a Core level of tracking as a minimum. This tracking is defined based on the information you must have to make fundamental decisions. Keep that list short to minimise the amount of work & time required to perform the implementation work. Additional information is then captured based on requirements, building up to a Silver, Gold and Platinum level of web analytics set-up over time.
This web analytics set-up is my recommended Core level for Ecommerce websites. It is the minimum required to:
- Create your Ecommerce funnel
- Create a basic Ecommerce Performance Diagnostic
- Create a Merchandise Report
- Identify pages uniquely on the website
- Evaluate performance by marketing campaign
Core Tracking for Ecommerce Websites
Page Naming Convention
The page naming convention is the starting point for any implementation. In GA, page names default to the Page Path + URL query parameters. Luckily, I started my career with Nedstat and then using HBX (which led to Adobe Analytics) which required defined page names. This is a habit I have retained ever since.
I think you can tell if a Digital Analyst has only used GA based on whether they define page names or just accept the default option.
Rather than going into more details, here are my thoughts on page naming conventions. I define page names as critical tracking, whichever web analytics tool you use. With GA, you need to populate the “page_path” variable with a user friendly page name.
The basic page naming convention for an ecommerce website is quite straight forward. There may be additional page types on your website, in which case this list will need to be extended. But to get you started:
Additional Page Information
The first element of each page names is the Page Type. It is critical to also capture this within a variable, whether that is a Content Grouping in GA or similar in other tools.
For websites with multiple languages, the language each page is viewed in should also be captured. Ensure that the language is captured with a user-friendly name, not an abbreviation e.g. english and not EN.
While it is not critical, I always like to capture the complete Page URL in a variable. It is easy to do and incredibly useful in various ways.
Transactions
It is an Ecommerce website; transactions must be recorded. But with the idea of focusing on critical data, only some information about the transaction is required:
- Transaction ID
- Total amount paid (split by amount for shipping and amount for products)
- For each product purchased
- The product name (matching the granularity level shown on product pages)
- Quantity of the product purchased
- Price per item
- If multiple currencies are in use, recording the currency for this transaction
- Or recording all transactions converted to your central currency
There are other data points I would like to capture about transactions and the items purchased. This minimum level allows you to build critical Ecommerce reporting.
Note that to rely on your web analytics data, reported transactions (without duplications) must be within 10% and ideally 5% of actual transactions. If not, work is required to understand why and to improve data collection to hit this level.
Product Page Views
For the Merchandising report, we need to record when products are viewed. The critical level of tracking here is just the product name recorded in a variable (e.g. hit scoped Custom Dimension) on each product page view. The product name needs to reflect the granularity for the page that is being viewed e.g. include colour if there is a different product page per colour variant.
The name must be the exact same naming convention as that used to record the product name in transactions.
Add to Basket
Whenever a product is added to basket and from any location, this needs to be captured. Besides the fact that a product was added to basket, it is critical to know the location from which the product was added to basket (product details page, product list page, basket, wishlist, etc) and the name of the product.
With GA, the easiest way to capture this is with an Event. The location and the product name can be recorded in the Event Action and Event Label variables or, if the Event Action is already populated, in the Event Label and a hit scoped Custom Dimension.
Once again, the product name must be consistent with that used elsewhere – no adding in the size variant here to identify the exact SKU. This tracking could be enhanced in a lot of ways, capturing information such as:
- Any size or colour variants
- Product categorisation
- Quantity of items added to the basket
- Value of products added to the basket
All great to have information but not critical.
Campaign Tracking
It is (or should be) a simple requirement to add campaign tracking to all marketing links to your website. These are the UTM codes for GA with equivalent for other tools. They need to be used across all channels where you control the URL used including Paid Search, Social Media, Email (both promotional and operational), Affiliates and Display.
The integration for some Channels is very easy, it can be added via ticking a box or making a request to the vendor. Google AdWords needs to be integrated with GA with all URLs auto tagged from that point. All good email, display & affiliate tools/vendors can add campaign tracking for you. You might need to have a discussion to achieve useful campaign naming conventions, rather than basic defaults.
For any other channels you need to define the naming convention to use and then ensure these are followed consistently by everyone in your business. It helps to use a guide and tool that creates the URLs by selecting/entering the campaign parameters.
Enhanced Ecommerce
I have written about capturing transactions, product page views and add to basket without mentioning Enhanced Ecommerce. This feature should do most of what I define as critical but unfortunately it contains some flaws:
- The funnel doesn’t include the Ecommerce Visit stage
- The SHOPPING_STAGE dimension didn’t provide a good funnel extract
- reviewing now, it should work but there is/was an issue there
- The Product Performance data is not useful as reported as instances, not sessions
I recommend using the Enhanced Ecommerce code when recording transactions and, as it should be minimal extra work beyond what we are already doing, to do the same to record product details when products are viewed and added to basket. Getting this code right across all possible stages & recording more product details would be a Silver or Gold level of web analytics tool set-up – it is not Core.
Google Analytics Configuration
While this is very specific to GA, the related configuration changes for this tracking are:
- The obvious of:
- ensure at least two Views, one for raw data and one for primary use
- get the time zone right
- exclude known bots and spiders
- exclude internal traffic using IP filters
- integrate with Search Console and AdWords
- Enable site search based on the search term parameter from your user-friendly page names and strip out the query parameter from this page name
- Choose the correct default currency
- Create a Goal for each stage of the Ecommerce funnel (excluding the first stage which is just Sessions)
- Ecommerce Session: destination goal with regex match for all ecommerce pages e.g. ^/(department|product-list|search-results|product-details|basket|checkout)
- View Product: destination goal that begins with /product-details
- Create Basket: event goal with something like Event Action = add to basket
- Commence Checkout: either a destination goal that begins with /checkout OR an event goal with something like Event Action = commence checkout
- Place Order: destination goal for page = /checkout/confirmation
- Create Content Groupings with Tracking Code enabled for:
- Page Type
- Page URL
- Page Language (if relevant)
- Modify Channel Grouping as needed based on your campaign naming conventions
- There should be zero to minimal traffic classified as Other
- Enable Enhanced Ecommerce (no need to name Checkout stages)
- For a nice bonus, create Calculated Metrics for each funnel stage completion
- g. Goal 2 Completions / Goal 1 Completions
- Create Custom Dimensions for:
- Product View: Product Name – hit scoped
- Add to Basket: Location – hit scoped (if captured)
Data needed for each Report
Ecommerce Funnel
You only need six numbers to create the Ecommerce funnel and these are now very easy to access. Stage 1 is Sessions while stages 2 to 6 are Goal Completions.
Performance Diagnostic
The basic version of the Performance Diagnostic report for an Ecommerce website contains standard metrics, transaction data and the Ecommerce funnel. All of that will be available with this Core set-up. Dimensions are standard too with a couple of exceptions.
If all channels are tracked with campaign parameters and Channel Groupings are configured accordingly, then the traffic source breakdown will work correctly. The Entry Point dimensions uses the Page Type Content Grouping (the landing page dimension).
With pre-defined dimensions and metrics in use (either canned data or Goals, Content Groupings, etc), sampling should not be a limitation in accessing the data, even with free GA.
Merchandise Report
This report relies on product information captured when
- Product pages are viewed
- Products are added to basket
- Products are purchased
That means three different data extracts with the dimension of product name and the relevant metrics. They will be joined using the product name as the unique identifier. That is why it is so important to use the product name consistently with the same spelling, capitalisation and granularity.
The data extracts are:
- View Product
- Page views
- Unique Dimension Combinations (equivalent to Sessions)
- Add to Basket
- Unique Dimension Combinations (total added to basket)
- Unique Dimension Combinations (filtered so only when added to basket via product page)
- Transactions
- Unique Purchases
- Quantity
- Product Revenue
Extending the Tracking
That is my recommended Core tracking for any Ecommerce website. What then is Silver or even Gold/Platinum levels of tracking?
The answer will vary from business to business, depending on priorities and other ongoing work. For example, if the navigation menu is being worked on to optimise performance, then track everything about the navigation menu. But some common useful tracking elements are mentioned below.
Visitor Tracking
The visitor type, identifying if a visitor is a prospect or a known customer, can provide the most valuable segmentation possible to a retailer. Discovering that while your website conversion rate feels pretty good at 4% but it is only so high due to loyal customers with prospects converting at 0.3%, could lead to an entire change in strategy. The solution used for this is not ideal as based on cookies but still yields useful information.
If you want to capture the behaviour of individual customers, you can capture their customer ID but only while the visitor is logged in, therefore identifying themselves. One use case for this customer ID is to extract details of behaviour outside of transactions to personalise website experience/marketing messaging e.g. language, size preferences, products interested in.
Site Search
Capturing a search term is relatively easy and included at the Core standard. A useful variable to capture, especially if high abandonment from search results pages, is the number of results displayed. Creating solutions for common searches with zero search results can be very valuable.
Site search only records by default if visitors click through to the search results page. Commonly websites allow visitors to select products directly from the search bar or take visitors to a product list page. In either case, recording that a search occurred and the action taken from this can change your strategy around site search e.g. if the use of reported search increased from 5% to 20%.
Form Tracking
If initial analysis suggests issues through the checkout process, it is useful to know if the checkout process forms are causing issues. A good level of form tracking is to record:
- The form name and field name for any form field completed
- The form name of any form successfully submitted
- The form name, field name and error message for form validation errors
This allows you to see the abandonment stage in forms and the most common form validation errors.
Product Page View
There are several reasons why a product can be underperforming as reported within the Ecommerce Merchandise report. Additional tracking can quickly provide insights into these reasons. Data points to capture on product page views include:
- % product SKUs that are in stock
- If a full price or discounted product
- If a (relatively) expensive or cheap product
- How long the product has been available for
Summary
I could continue for several more pages with lists of variables and visitor actions that could be captured on any ecommerce website – let’s save that for another day. The Core tracking for any retail website is standard and it is not extensive. Frustratingly even this level is not always in place.
Let me know in the comments your thoughts on this tracking. Is there anything here that you would not consider Core or any tracking that is missing which is critical?
Please get in touch if you want this tracking and these reports for your business. I can provide a free audit of your current tracking against this list of Core tracking so you know what is missing. Working with your developers, the missing tracking can be added, the reports created and your team trained in their use.
This is not advanced Data solutions. There is no Big Data, AI, ML or Data Scientists involved. This is getting the basics right first, learning the impact that working smarter using data can have on your business and developing the business culture to allow you to take advantage of Big Data, AI and ML solutions. A small first step but needed to start that journey.
