When Enhanced eCommerce dataLayer is not enough
Enhanced eCommerce & Data Layer
We believe that you came here because you know what Enhanced eCommerce and data layer are. Most of the online marketers have heard of it and all of the marketers in the eCommerce segment should know it for sure. In this article, we will discuss valuable improvements/additions to the Google Analytics Enhanced eCommerce data layer and some of the most common issues with the implementation of the data layer.
We will start with a background on the Enhanced eCommerce data layer, then we'll discuss improvements and follow-up with issues that we often encounter during development.
We, as a company, suggest and have been suggesting for a long time to implement all (almost all) tracking scripts within Google Tag Manager. This approach has such advantages as:
No developer involvement needed
Fast deploy of tracking scripts
All scripts are in one place
Ease of script management
These benefits of Google Tag Manager are widely known, however, we would like to mention separately the benefit of having one data source for all scripts — data layer.
One data source to rule them all
We can all probably agree that most of the tracking scripts are pretty useless without dynamic data to track. Google Tag Manager does provide plenty of built-in variables, however, for eCommerce, these built-in variables are not enough — therefore the data layer should be utilized. For those who do not know what the data layer is:
“A data layer is an object that contains all of the information that you want to pass to Google Tag Manager. Information such as events or variables can be passed to Google Tag Manager via the data layer”
Today we will speak about the data that are handy to have available in the data layer.
Our company specializes in the Magento platform, and we have been working with Google Tag Manager and Google Analytics setups for a pretty long time. There were a lot of problems with the data layer extensions for Google Analytics Enhanced eCommerce available on the market. These problems could be stated as follows:
Compatibility with projects — most of the eCommerce stores have a large number of custom modules, which results in a need to adjust extensions every time we install them, in order to make it compliant with the project structure
Lack of enhancements — we use some variables which are very useful for tracking, however, they are not present in most of the extensions (i.e. page type variable for remarketing)
Furthermore, extensions often had problems with variable types or event names (data layer pushes often just did not have names). Therefore, for Magento 2, we decided to create our own extension.
Our data layer pushes list
As you may know, Google Analytics Enhanced eCommerce tracking is based on 10data layer pushes:
Also, we have introduced an additional data layer push that covers user-related data — “General”.
In terms of Enhanced eCommerce it is pretty straight forward — open Google Analytics Enhanced eCommerce data layer technical documentation and implement it step by step, right? Well, yes, you definitely should start with the basic Enhanced eCommerce as per Google documentation.
Here we will describe variables and data layer pushes in greater details, so you could pick-up some ideas and implement them straight away at your website.
Finished with Enhanced eCommerce data layer — what’s next?
Once you have finished with the Enhanced eCommerce data layer, you would probably think — can we improve it even further?
Yes, you can. How? The answer is — product-scoped custom dimensions and metrics. In our extension we have added a functionality that allows passing any product attribute to the product field as a custom dimension or metric. This allows highly detailed product performance analysis! Websites that have lots of configurable products will get greater benefits from this functionality, i.e. size, color and fit tracking for clothing stores.
Finished with enhancing Enhanced eCommerce data layer — what’s next?
We have introduced an additional data layer push, which is used as a complimentary data source for Google Analytics as well as provides useful data for other tracking scripts. “General” data layer push contains data about a user and a web page. This push is triggered on every page, before all other data layer pushes — in order to have all user-related data in place for coming Enhanced eCommerce tags. Variables:
<customerId>— string — User ID, for cross-device tracking
User ID, as most of you probably know, is required for Google Analytics User ID reports that allows to connect user’s actions across different devices, thus, you get a broad picture of how users’ interact with the website. We did go with Magento user ID, however, hashed user email instead of Magento ID will work great if you are using remarketing scripts that use hashed user email for user identification.
<customerLoginState>— string — “Logged in” or “Not logged in”
Customer login state — we use it for Google Analytics custom dimensions, both hit scope and session scope, which allows us to separate users for behaviour analysis both at the session level and a particular event level.
<customerType>— string — Type is taken from the BE
To know a customers’ type would be beneficial for companies that provide services for B2C and B2B clients, as well as for those who have a focus on long term clients. This variable is not only useful as a custom dimension for customer behaviour analysis — it provides greater possibilities for the remarketing targeting, and, as you may know — precise targeting is key.
<visitorExistingCustomer>— string — “Yes” or “No”
Same as the previous variable — segmentation and remarketing. One of the main advantages of this variable as a custom dimension is content optimisation.
<lifeTimeValue>— integer — Total order values is taken from the BE
And again, segmentation for behavioural analysis and remarketing.
<storeView>— string — Store view name
<language>— string — Store view language
These two variables could be useful only for multiple store view and/or language websites. The main purpose of these variables is ease of tag triggering.
<pageType>— string — Page type homepage/category/product/etc
We use this one for tag triggering, segmentation by the page type, i.e. to see where users do add products to cart from category page or at PDP. Also, could be used for custom content grouping.
- [Cart] — Array — Contains an array of products in cart
We use this array for remarketing as well as for 3d party checkout tracking setup in the Google Tag Manager. Instead of “checkout” dataLayer.push — when a user goes to the 3d party checkout we just restructure [cart] array so it would become a [checkout] array, thus, eliminating additional work for developers.
Things to pay attention to
Product Categories — Product category tracking is one of the biggest issues when dealing with Enhanced eCommerce. This issue comes from product categorisation — pretty often one particular product could belong to multiple subcategories, i.e. “sandals” could simultaneously belong to “summer shoes” and “outdoor shoes”, thus, creating an issue of which category to choose? Moreover, categories could have a different depth, so if you’re thinking of “taking a step up” and retrieving a “higher level” category in order to eliminate the issue of multiple subcategories — you could find out that this logic does not work for all of your categories. There is no unified solution “to rule them all”, therefore, you will need to tailor tracking logic to your project.
Configurable Products — In case if you do have configurable products on your website you should pay attention to the product ID tracking logic. Usually, configurable products exist until add to cart event, then they are converted into simple ones. This creates an issue with product performance analysis since Google Analytics will recognise configurable and simple products as different products, thus, configurable products will not have add to cart data and purchases, and simple products will not have the impression and product detail view data. This problem, usually, is solved via passing configurable product SKU (parent SKU) instead of simple product SKU (child SKU).
Impression tracking — There are two common problems with impression tracking. The first issue with this dataLayer.push is that people do not always check if impressions are working for the infinite scroll feature, so just keep in mind to test it if you do have infinite scroll functionality on your website.
The second issue is with product promotion block impression tracking (“we also recommend products”/”recently viewed” section, not “promo view”) — it is better to QA these “we also recommend” section impressions on the LIVE website. It happens pretty often that the QA of the data layer is done on a staging or development website and 3d party solutions for “we also recommend section” rely on LIVE website data, thus, resulting in “impression” data layer.push not working on staging or development instances, while, in fact, the issue is with the “architecture” of the “we also recommend” section itself.
Add To Cart/Remove From Cart on quantity update — It is pretty common that people forget to set up addToCart and removeFromCart events on quantity update either in the cart or at the cart dropdown, so — do not hesitate to check it :)
promoView/promoClick — these two things we usually tailor to the project since there is no unified solution. Moreover, often it is easier to track promotions via custom events rather than setting data layer pushes.
To sum up, here's a recap of what we have covered:
Start with the basics— no need to enhance stuff if basics are not completed or not working properly
Improvements/additions that we have described here are tailored to eCommerce needs, however, we did include only the most commonly used ones, thus, you can always expand further.
Also, keep in mind that a lot of great improvements of Google Analytics tracking could be achieved by a proper configuration of Google Analytics tags in Google Tag Manager.
For example, for checkout events — you can pass cart total value (can calculate via JS from the checkout products array) as the event value, thus, you will get a very clear understanding of how much money is “dropping off” in the checkout. So keep in mind that there are a lot of ways to get better data!
Learn more about our analytics services and how we can work together to improve your eCommerce site!
Questions? Comments? Need help? Feel free to contact us via email: email@example.com