This post sets out to solve a very specific problem: namely, how to balance the competing demands of a platform-agnostic Data Layer and the Enhanced Ecommerce plugin for Google Analytics. This might sound niche, but you’d be surprised how many large ecommerce websites using Google Tag Manager eventually run into this challenge.
The Problem: Platform Agnosticism
Enhanced Ecommerce tracking is infinitely better than the standard Ecommerce plugin (ecommerce.js). It offers deep insight into your website’s customer journey, allowing you to measure product impressions, shopping cart behaviour, checkout abandonments, and so on.
The most efficient way to implement Enhanced Ecommerce is with Google Tag Manager (GTM), and the bulk of the work necessary to do so is in configuring your site’s Data Layer (see Google’s Documentation). Once the relevant attributes and values are present on the page, enabling Enhanced Ecommerce in GTM is as simple as ticking a box.
However, in larger organisations – particularly those valuing data-led decision-making – the Data Layer often has multiple stakeholders and needs to serve multiple analytics platforms. For this reason, a degree of platform agnosticism is always encouraged; it minimizes the number of moving parts in your reporting setup and keeps things lean and DRY (don’t repeat yourself!).
Customisations to Enhanced Ecommerce tracking frequently require us to use proprietary, GA-specific syntax in our Data Layer. To illustrate the problem, I’ve created the following example based on a real problem I encountered with one of our Analytics clients:
window.dataLayer = window.dataLayer || ;
"affiliation": "Outdoor Adventure Park",
"location": "Bristol" // Our custom purchase attribute
"name": "Quad Biking",
"category": "Vehicle Track",
"name": "Clay Pigeons",
"category": "Shooting Range",
Our (fictional) website allows users to make bookings at a number of outdoor activity centres. As you can see, the Data Layer above corresponds to our purchase page, and it shows that our customer has purchased two activities – clay pigeon shooting and quad biking – at the Bristol venue.
Our nice, platform-agnostic Data Layer includes the name of the venue in the
actionField object, where it is available to all analytics platforms under the name
location. Makes sense, right? Because users are asked to select a venue during the first step of the checkout process, location is a purchase-level attribute, rather than product-level: all transactions containing multiple items relate to a single location.
However… let’s say we want to push location to Google Analytics as a product-scoped custom dimension, so we can aggregate revenue by location. Doing so requires an arbitrary modification to each item in the products array:
"name": "Quad Biking",
"category": "Vehicle Track",
"dimension3": "Bristol" // Setting a custom dimension
For various (completely valid) reasons, our development team do not wish to make this change:
- Key name (“dimension3”) is specific to GA and not intuitive
- Hard-coded dimension index number, which is liable to change
- Property must be added to every item in products array, despite other analytics platforms accessing it from its logical position in
So, what do we do?
First, we’ll create a Data Layer variable which fetches the
ecommerce object. We’ll call it ‘dlv – ecommerce – full’. Be sure to select Version 1 of the Data Layer, since this will ensure that GTM only accesses the payload which was most recently pushed into the Data Layer – see this excellent primer on Data Layer versions by Simo Ahava.
What we want to do is copy the value of the
location property in our ecommerce payload and add it to each item in the
The script is quite simple – we access our original ecommerce Data Layer Variable under the name
ecom, and get the value of its
location property from
actionField using dot notation. We then have a simple loop which iterates through each item in the
products array and adds a
dimension3 property to each, with the location as its value. Finally, we return the manipulated data as a new ecommerce object.
The last step is to open your Enhanced Ecommerce enabled GA tag and untick the box for ‘Use Data Layer’. Instead, reference your newly-created ecommerce object:
And that’s all you need to do. Assuming your product-scoped custom dimension in slot 3 is configured in your GA property, valuable data will start accumulating immediately.
However, don’t get carried away. Ideally this technique should be used to avoid proprietary customisations to your Data Layer, rather than as a hack to sidestep any of its fundamental shortcomings. Don’t start screen scraping, or doing anything that will incur loads of development debt further down the line. In the words of esteemed GTM expert Uncle Ben, “with great power comes great responsibility”.
If you need assistance with an Enhanced Ecommerce implementation or would like to discuss your GTM setup with a consultant, you can reach our experts here.
Thanks for reading! Let me know what you think in the comments or on Twitter.