Enhanced Ecommerce<\/a> is certainly one of the finest reporting user interface features that Google Analytics<\/a> has to offer. Enhanced Ecommerce, as the name implies, is a set of dimensions, metrics, and reports, which combine to provide you with a fairly complete view into how users are interacting with your products in your webstore. The main downside of Enhanced Ecommerce is, as with all good things, that it\u2019s complicated to implement.<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n Luckily, there\u2019s Google Tag Manager<\/a>. Theoretically, you could implement Enhanced Ecommerce through Google Tag Manager without ever adding a single line of functional logic into the codebase of your web site. You could do everything by simply scraping<\/em> the Document Object Model<\/a> (DOM). However, as we have hopefully learned over the years – GTM is a tool with which fastidiousness trumps fast.<\/p>\n Whenever you\u2019re working with There is a lot of information in this article. Much of it is already covered in Google\u2019s excellent Enhanced Ecommerce Developer Guide<\/a>, but there are plenty of gotchas<\/em> that I might have covered in earlier articles (see the Further Reading<\/a> chapter), or which I might not even have written down before.<\/p>\n NOTE!<\/strong> This is an implementation<\/strong> guide. If you want to know how Enhanced Ecommerce works or how to map your site into relevant interactions, you\u2019ll want to look at Google\u2019s support center documentation<\/a>.<\/p>\n<\/blockquote>\n \n \n Subscribe to the Simmer newsletter<\/a> to get the latest news and content from Simo Ahava into your email inbox!\n <\/p>\n <\/span><\/p>\n Obviously, it would make sense if you read the guide from top-to-bottom. However, I fully acquiesce that the loquaciousness of my rhetoric might be tedious to some in all its verbose glory. Also, sometimes I write douchy things like that.<\/p>\n So, depending on what your role is in the implementation project, there might be only some chapters that are relevant for you. However, don\u2019t neglect to consult with all the stakeholders in the project! It doesn\u2019t make sense for a developer to write code without understanding what the code is needed for. Similarly, it doesn\u2019t make sense for the person operating Google Tag Manager to utilize the If you are a developer, tasked with implementing the If you are the person tasked with setting up EEC via the Google Tag Manager User Interface<\/strong>, you\u2019ll want to focus on the following chapters (in order):<\/p>\n<\/blockquote>\n As I said, I still wish you\u2019d spend the time reading the entire guide. I don\u2019t think there\u2019s any irrelevant information to anyone working on the project, and it makes sense to understand the full complexity of the implementation rather than focus only on the things that are directly relevant to your work.<\/p>\n Implementing Enhanced Ecommerce requires an overview of the following components:<\/p>\n All three of these components are necessary, and all three require some understanding of how Google Tag Manager works, how tags and triggers interact with <\/p>\n <\/a><\/p>\n<\/div>\n Needless to say, if you want a robust<\/strong> implementation, interaction and co-operation with your site\u2019s front-end developers is an absolute must<\/strong>. Typically, the front-end developers utilize page templates and server-side variables (using PHP<\/strong> or React.js<\/strong>, for example) to build the HTML structure of any given page. On Enhanced Ecommerce pages, it\u2019s important that they integrate the front-end with whatever ecommerce system you have in use, so that this system produces the necessary values dynamically for the front-end developers to funnel through into the For interactions that take place after the page load, such as cart interactions, the front-end developers might need update the site JavaScript to populate the Or you can just throw caution to the wind and scrape everything off the HTML itself<\/a> through Google Tag Manager. The purpose of this guide isn\u2019t to recommend any specific course of action, but to highlight the different ways in which you can run the Enhanced Ecommerce implementation project.<\/p>\n If you\u2019ve been running Standard Ecommerce<\/a> through Google Tag Manager, there are mainly three<\/strong> major differences between that and Enhanced Ecommerce.<\/p>\n Standard Ecommerce<\/strong> only collects transactions (i.e. \u201cPurchase\u201d hits in EEC) – there are no other components to its funnel (in fact, there is no funnel).<\/p>\n<\/li>\n Standard Ecommerce<\/strong> uses a different Standard Ecommerce<\/strong> doesn\u2019t support Product-scoped Custom Dimensions and Metrics<\/a>.<\/p>\n<\/li>\n<\/ul>\n One thing to pay heed to is that you can collect both Standard Ecommerce and Enhanced Ecommerce hits<\/strong> to an Enhanced Ecommerce -enabled Google Analytics view! This means that if you leave your \u201cold\u201d tracking in place and run an Enhanced Ecommerce implementation in parallel, you might end up double-counting<\/strong> transactions.<\/p>\n Google Analytics does<\/em> deduplicate identical transactions sent in a session, but it\u2019s enough for some component in the two different tracking methods to differ for GA to collect the data twice.<\/p>\n Product Category<\/strong> is collected to a different dimension, depending on which method you are using. So if you populate the <\/p>\n <\/a><\/p>\n<\/div>\n The following chapters will cover certain aspects of an Enhanced Ecommerce implementation. As I stated in the Introduction<\/a>, how the values are populated into However, there are plenty of custom Ecommerce platforms and setups out there which require tinkering for them to produce the values into variables that your front-end developers can then utilize.<\/p>\n The next chapter, for example, simply instructs what the generic The The The key-value pairs are populated by scraping the page HTML using Google Tag Manager.<\/p>\n<\/li>\n<\/ol>\n Enhanced Ecommerce requires a specific syntax<\/strong> for the objects pushed to Do note that Google Tag Manager only reacts to Within the push, all the keys listed under and including Now, you will need to populate the keys in the object with relevant values. For example, the value for Similarly, you\u2019ll need to collect details about the products in the transaction, and send any variant, brand, and category information as metadata, too.<\/p>\n How you do this really depends on what the integration to your Ecommerce system is like. It\u2019s impossible to give generic instructions, because each Ecommerce platform differs in how it provides the values for you to exploit in other on-site code. But if you already have an Ecommerce system in place, I recommend you read through its documentation and try to find out how you can request or access these values and variables from this system.<\/p>\n When you select the Use data layer<\/strong> option in the Enhanced Ecommerce settings of a Google Analytics Page View or Event tag (or a Google Analytics Settings variable<\/a>), you instruct the tag to look into the Data Layer and pull the key-value pairs from the <\/p>\n <\/a><\/p>\n<\/div>\n This sounds pretty straight-forward. All you need to do is make sure the object pushed into However, there are two important things to note here.<\/p>\n The When a tag with \u201cUse data layer\u201d fires, it really only accesses the most recent<\/strong> Point (2) might sound counter-intuitive, but it actually makes sense. If GTM didn\u2019t exhibit this behavior, then all It\u2019s precisely because of this behavior that I again strongly recommend to always include the However, you might want to take a look at the next section, too.<\/p>\n One of my main issues with the This means that it might be a huge effort to get the data into the correct format in the first place. But then you also need to have a process in place so that you can update it with minimal delay, and so that you can audit it to make sure no data is lost.<\/p>\n So, thankfully, Google Tag Manager also lets you send the data using a Custom JavaScript variable<\/a>.<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n Using the variable has a very simple logic. All the variable needs to do is return<\/strong> a valid And how is this useful? Well, you could have the Ecommerce data pushed into Or, if you want to go the DOM scraping route, you can do all the scraping in the Custom JavaScript variable, and have it return a valid You can also modify a valid<\/strong> With this simple example, I\u2019m updating a perfectly valid As you can see, I\u2019m making a copy<\/strong> of the original variable with the One additional important thing to note<\/strong>. Data Layer Variables are, by default, Version 2<\/strong><\/a>. This means that they will merge all the existing Whether you want to use a Page View or Event tag and how you setup your Custom Event triggers is completely up to you.<\/p>\n Personally, I always<\/strong> use Event tags. Why? Because if you use a Page View tag, you lack insight into what Enhanced Ecommerce events have been collected in Google Analytics. This might make debugging a broken implementation difficult. By using events, I can always look at the Top Events report to see all the Enhanced Ecommerce hits sent to GA.<\/p>\n![\"enhanced](\"https:\/\/www.simoahava.com\/images\/2018\/09\/enhanced-ecommerce-guide-for-google-tag-manager.jpg#ZgotmplZ\")
<\/p>\ndataLayer<\/code>, for example, you\u2019re investing into the stability of your data collection process. Thus, even though I will be talking about DOM scraping further on<\/a> in the guide, the focus here will be on a setup where the front-end<\/strong> produces HTML documents and\/or JavaScript that populates the Ecommerce values into the dataLayer<\/code> without using DOM scraping or other client-side hacks to do the job.<\/p>\n\n
\n X<\/span><\/p>\n
\n The Simmer Newsletter<\/strong>\n <\/p>\nHow to read this guide<\/h2>\n
dataLayer<\/code> structures without understanding the limitations of the back-end or front-end systems.<\/p>\n\n
dataLayer<\/code> objects<\/strong>, you\u2019ll want to read the following chapters (in order):<\/p>\n<\/blockquote>\n\n
\n
\n
Introduction<\/h2>\n
dataLayer<\/code>, and how the Enhanced Ecommerce data is sent to Google Analytics. These will all be covered in this guide.<\/p>\n![\"Implementation](\"https:\/\/www.simoahava.com\/images\/2018\/09\/implementation-process.jpg#ZgotmplZ\")
<\/p>\ndataLayer<\/code>.<\/p>\ndataLayer<\/code> object with the necessary values in the client.<\/p>\nDifferences (and similarities) to Standard Ecommerce<\/h2>\n
\n
category<\/code> format.<\/p>\n<\/li>\ncategory<\/code> key for a product using either method, the dimension you\u2019re looking for in GA is going to be different.<\/p>\n![\"Product](\"https:\/\/www.simoahava.com\/images\/2018\/09\/product-category-dimensions.jpg#ZgotmplZ\")
<\/p>\nImplementation guidelines<\/h2>\n
dataLayer<\/code> depend on the integration between your site\u2019s front-end and the Ecommerce platform you use. Some platforms such as WooCommerce for WordPress introduce this integration using a plugin<\/a>, others such as Magento provide it out-of-the-box as a feature<\/a>.<\/p>\ndataLayer<\/code> object needs to look like. How you end up populating the values into the required keys is up to you, but typically it\u2019s done in one of the following ways:<\/p>\n\n
dataLayer.push()<\/code> is written directly into the page template by whatever server-side mechanism you have for producing the templates.<\/p>\n<\/li>\ndataLayer.push()<\/code> is generated dynamically by your web server or the Ecommerce platform using typically a combination of JavaScript and HTTP requests.<\/p>\n<\/li>\nPopulate the Data Layer<\/h3>\n
dataLayer<\/code> or generated with a Custom JavaScript variable. For example, a dataLayer.push()<\/code> with the minimum required Ecommerce object for a Purchase<\/a> looks like this:<\/p>\nwindow<\/span>.dataLayer = window<\/span>.dataLayer ||\u00a0[];\nwindow<\/span>.dataLayer.push({\n event: 'eec.purchase'<\/span>,\n ecommerce: {\n purchase: {\n actionField: {\n id: '1'<\/span>\n },\n products: [{\n id: 'p'<\/span>\n }]\n }\n }\n});\n<\/code><\/pre>\n<\/div>\ndataLayer.push()<\/code> commands<\/strong>. No other array methods will do anything in GTM, so it\u2019s imperative that you do not improvise with this. All the interactions with dataLayer<\/code> must be done with push()<\/code>.<\/p>\necommerce<\/code> are required. The event<\/code> key is something I strongly recommend<\/a> to add to every single dataLayer.push()<\/code> object.<\/p>\necommerce.purchase.actionField.id<\/code> would need to be a unique identifier of the order itself. You could generate one randomly using JavaScript, but typically you\u2019ll want to use the same<\/strong> order ID that was included in the actual transaction. That way you can later augment details about this transaction using Data Import<\/a>, for example.<\/p>\nSend the data to Google Analytics using the Data Layer<\/h3>\n
ecommerce<\/code> object pushed most recently<\/strong> into dataLayer<\/code>.<\/p>\n![\"Use](\"https:\/\/www.simoahava.com\/images\/2018\/09\/use-data-layer.jpg#ZgotmplZ\")
<\/p>\ndataLayer<\/code> follows the exact correct syntax, and that it\u2019s pushed into dataLayer<\/code> before (or in the same push as) the tag that accesses the data via Use data layer<\/strong> fires.<\/p>\n\n
dataLayer.push()<\/code> must<\/strong> be perfectly formed. There\u2019s no way to modify it on-the-go if you activate the \u201cUse data layer\u201d option. So it\u2019s absolutely vital that you specify and audit the object that is being pushed into dataLayer<\/code> for Enhanced Ecommerce data collection.<\/p>\n<\/li>\necommerce<\/code> push. So, if you\u2019ve split Product Impressions into multiple pushes and then fire the tag when the last one is done, if the tag has \u201cUse data layer\u201d checked, only the last impressions object is sent to Google Analytics.<\/p>\n<\/li>\n<\/ol>\necommerce<\/code> pushes done on a single page would tag along with all the subsequent Enhanced Ecommerce payloads. By sending only the most recently pushed object, this behavior can be avoided.<\/p>\nevent<\/code> key in every single Enhanced Ecommerce object<\/strong>. Why? Because then you can use Custom Event triggers<\/strong> to fire your Enhanced Ecommerce tags at precisely the correct time, and the most recent object they access will always be the one that triggered the tag. That way you won\u2019t lose any data because of pushes that didn\u2019t trigger any tags.<\/p>\nSend the data to Google Analytics using a Custom JavaScript variable<\/h3>\n
dataLayer<\/code> object syntax for Enhanced Ecommerce in Google Tag Manager is its rigidity. The \u201cUse data layer\u201d option requires that you follow a very specific, unwieldy syntax.<\/p>\n![\"Custom](\"https:\/\/www.simoahava.com\/images\/2018\/09\/custom-js-variable.jpg#ZgotmplZ\")
<\/p>\necommerce<\/code> object. In other words, the variable needs to return exactly the same thing that the developers would push into dataLayer<\/code> in a perfect world.<\/p>\ndataLayer<\/code> in any<\/em> format, and then use the Custom JavaScript variable to transform it into a valid ecommerce<\/code> object. This way, you don\u2019t need to confuse matters with a rigid dataLayer<\/code> specification, but rather the Ecommerce platform can push the data into dataLayer<\/code> in whatever format suits it best. Then, with some JavaScript magic, you can pull this data through the Custom JavaScript variable into your tag.<\/p>\necommerce<\/code> object with all the key-value pairs in place.<\/p>\necommerce<\/code> object in the dataLayer<\/code> in case you need to add some dynamic updates to it (such as Product-scoped Custom Dimensions). For example, here\u2019s me adding a Product-scoped Custom Dimension<\/a> to all the products in a Purchase object:<\/p>\nfunction<\/span>() {\n \/\/ Create a copy of the variable to avoid\n<\/span> \/\/ modifying the source object by reference\n<\/span> var<\/span> ecom = JSON.parse(JSON.stringify({{Data Layer Variable - ecommerce}}));\n try<\/span> {\n ecom.purchase.products.forEach(function<\/span>(prod) {\n prod.dimension10 = {{get discount}}(prod.id);\n });\n } catch<\/span>(e) {}\n return<\/span> {\n ecommerce: ecom\n };\n}\n<\/code><\/pre>\n<\/div>\necommerce<\/code> object (represented by {{Data Layer Variable – ecommerce}}<\/strong>), by adding a new field to every single product.<\/p>\nJSON.parse(JSON.stringify(obj))<\/code> method. Because JavaScript copies objects by reference, any changes you make to the ecom<\/code> variable would reflect in the original object stored in dataLayer<\/code>. This might have adverse effects if the variable is run more than once, especially if you\u2019re running calculations on any fields (the calculations would be done over and over again).<\/p>\necommerce<\/code> pushes into one big ecommerce<\/code> object. So when you create the variable for ecommerce<\/code>, you might want to use Version 1<\/strong>. Read this article<\/a> for more information.<\/p>\nPage View or Event tag<\/h3>\n
![\"Event](\"https:\/\/www.simoahava.com\/images\/2018\/09\/event-list.jpg#ZgotmplZ\")
<\/p>\n