Enhanced Ecommerce<\/a> is undoubtedly an excellent feature of Google Analytics<\/a>. It provides us with a set of reports that truly extend the capabilities of funnel-based website analysis. As I\u2019ve shown before, it\u2019s also very useful for tracking other transactional events on your site, such as content engagement<\/a>.<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n However, here\u2019s the thing. It\u2019s not very easy to implement. Even if you get everything right according to the documentation, there are still quite a number of pitfalls, and many of the learnings emerge only through experience. This is where I want to help out, so I composed this post with some of my key findings about Enhanced Ecommerce implementation and use.<\/p>\n It\u2019s well worth learning this stuff, as a fully functional Enhanced Ecommerce implementation might well be the key to finally coming up with a useful report to plaster across your vanity dashboards.<\/p>\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 As a self-proclaimed Google Tag Manager<\/a> fanatic number 1, I do all my implementations with GTM. There are some quirks you need to consider, though, when implementing Enhanced Ecommerce through GTM. Here they are, in no particular order.<\/p>\n If you use the Enable Enhanced Ecommerce<\/strong> \/ Use Data Layer<\/strong> option in your Tags, there\u2019s one very important thing to understand.<\/p>\n Only the most recent In other words, if you do two consecutive <\/p>\n <\/a><\/p>\n<\/div>\n This is because the \u201cUse Data Layer\u201d option uses version 1<\/em> of the Data Layer, which doesn\u2019t have fancy things like recursive merge<\/em> of objects<\/a>. In practice, this means that an \u2018ecommerce\u2019 object will always overwrite the previous \u2018ecommerce\u2019 object in the data layer, if the version 1<\/em> interface is used.<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n If you do<\/strong> want to recursively merge \u2018ecommerce\u2019 objects, you will need to use the \u201cRead data from variable\u201d option which becomes available when you uncheck the \u201cUse Data Layer\u201d option. Read on\u2026<\/p>\n I\u2019ve written about this before<\/a>, and these days I actually only use this option to send the payloads. When you use the Custom JavaScript option (see the developer guide<\/a> for further information), you can create, parse, and delete parts of the \u2018ecommerce\u2019 object until it\u2019s to your liking. This is an incredibly powerful tool, letting you pull in data from multiple sources to compile the object, or allowing you to access the full<\/em> \u2018ecommerce\u2019 object stored in the data model<\/a>, and not just the stunted version 1<\/em> object available if you use the \u201cUse Data Layer\u201d option in your Tags.<\/p>\n The example above pulls together both product impressions<\/em> and product detail view<\/em> in a single object, sending the complete payload to Google Analytics with the Tag.<\/p>\n To access a recursively merged<\/em> This is pretty vaguely covered in the developer guide, but combining data types in a single payload can be very useful if you want to keep the number of requests to Google Analytics down. So, if you want to send multiple \u2018ecommerce\u2019 objects in one single payload, you can, but only if you send one of each object type ( Also, you can\u2019t<\/em> combine a action<\/strong> with one of action<\/strong> with In any case, combining objects into a single payload can truly save a lot of time and make the whole thing more efficient, but don\u2019t forget that Google Analytics has a character limit in the payload!<\/p>\n The analytics.js<\/strong> library refuses to send a hit if the full payload size is larger than 8192 bytes. This does require quite a lot of data to be stuffed within, but it only takes some dozens of product impressions to clog up the channel.<\/p>\n Eivind Savio has written an excellent post<\/a> about how to manage this overflow, so I suggest you head on over to take a look!<\/p>\n Enhanced Ecommerce is comprised almost entirely of hit-level interactions. This means that every Enhanced Ecommerce payload sent to Google Analytics is unique, and does not persists its information across subsequent hits.<\/p>\n This, in turn, basically means that the You\u2019ll want to be very careful when designing and developing the Data Layer for your Enhanced Ecommerce payloads. The developers need to understand how important it is to have the product details be identical throughout the funnel process.<\/p>\n This has implications for queries as well. For example, let\u2019s say you send the following two payloads to Google Analytics:<\/p>\n In this case, querying for product SKU<\/strong> \u2018A12345\u2019 will return a result when queried against product detail views<\/em> and product adds to cart<\/em>. However, product name<\/strong> \u2018My T-Shirt\u2019 will only return a result when queried against product adds to cart<\/em>. Since this product name was missing from the \u2018detail\u2019 payload, you won\u2019t be able to query for this information.<\/p>\n Many times when working with an Enhanced Ecommerce implementation which uses client-side methods to populate some of the data (e.g. scraping from the page), this consistency requirement has become a serious issue. I\u2019ve been forced to persist full product information throughout the funnel using solutions like HTML5 Storage and cookies<\/a>.<\/p>\n This is not the recommended approach.<\/p>\n The best way is to render product details in Note that checkout<\/strong> is a bit exceptional in terms of consistency. It\u2019s enough to send the \u2018products\u2019 Array with just the first step<\/em>. This is because Enhanced Ecommerce only has an aggregate productCheckouts<\/strong> metric, which increases by one when a product is sent with the first checkout step. The checkout option<\/strong> and the rest of the checkout steps need not, and thus perhaps should not include product information.<\/p>\n Product-scoped custom dimensions and metrics are a wonderful way to extend the rather limited set of information you can send with each product.<\/p>\n To send a product-scoped dimension or metric in Google Tag Manager, you need to include the For example, to send a dimension with details about the T-shirt size, and a metric with the tax-free value of the shirt, the Naturally, a payload like this will only let you query for this information with product detail view<\/em> queries, and for this particular product only. These dimensions do not persist across funnel payloads, nor do they cover multiple products. They\u2019re per product, per hit<\/strong>.<\/p>\n![\"Enhanced](\"https:\/\/www.simoahava.com\/images\/2015\/09\/enhanced-ecommerce-tips.jpg#ZgotmplZ\")
<\/p>\n
\n X<\/span><\/p>\n
\n The Simmer Newsletter<\/strong>\n <\/p>\n1. Implementation via Google Tag Manager<\/h2>\n
The fleeting
ecommerce<\/code> object<\/h3>\necommerce<\/code> object is included in the hit!<\/strong><\/p>\ndataLayer.push()<\/code> commands with their own \u2018ecommerce\u2019 objects, any Tag which fires after the latter push will only have access to the latter \u2018ecommerce\u2019 object.<\/p>\n![\"Use](\"https:\/\/www.simoahava.com\/images\/2015\/09\/ecommerce-features.jpg#ZgotmplZ\")
<\/p>\n![\"Custom](\"https:\/\/www.simoahava.com\/images\/2015\/09\/use-js-variable.jpg#ZgotmplZ\")
<\/p>\nCustom JavaScript Variable to the rescue<\/h3>\n
function<\/span>() {\n var<\/span> ecom = {'ecommerce'<\/span> : {\n 'impressions'<\/span> : pageData.productImpressions,\n 'detail'<\/span> : {\n 'actionField'<\/span> : {'list'<\/span> : 'Related Products'<\/span>},\n 'products'<\/span> : pageData.productDetailView\n }\n };\n return<\/span> ecom;\n}\n<\/code><\/pre>\n<\/div>\necommerce<\/code> object, you will need to create a new Data Layer Variable which accesses the \u2018ecommerce\u2019 object pushed within. Instructions for this can be found in this article<\/a>.<\/p>\nYou can combine multiple data types in a single payload<\/h3>\n
promoView<\/code>, promoClick<\/code>, impressions<\/code>, action<\/strong>). An action<\/strong> is any Enhanced Ecommerce data type which has the products<\/code> Array. In other words, these are the available action<\/strong> objects:<\/p>\nclick<\/code>, detail<\/code>, add<\/code>, remove<\/code>, checkout<\/code>, purchase<\/code>, checkout_option<\/code>, refund<\/code><\/p>\npromoClick<\/code> with a promoView<\/code> or an action<\/strong> object. These are, thus, the valid combinations:<\/p>\n\n
impressions<\/code> with one of promoView<\/code>, promoClick<\/code> or action<\/strong><\/p>\n<\/li>\nimpressions<\/code> with promoView<\/code> and action<\/strong><\/p>\n<\/li>\npromoView<\/code> with one of impressions<\/code> or action<\/strong><\/p>\n<\/li>\npromoView<\/code> with impressions<\/code> and action<\/strong><\/p>\n<\/li>\npromoClick<\/code> with impressions<\/code><\/p>\n<\/li>\nimpressions<\/code> or promoView<\/code><\/p>\n<\/li>\nimpressions<\/code> and promoView<\/code><\/p>\n<\/li>\n<\/ul>\nThere is an 8KB limit in the payload<\/h3>\n
2. Consistency is key<\/h2>\n
products<\/code> Array needs to be consistent throughout the funnel. For example, if you have a product which has the category \u2018T-Shirts\u2019, you will need to have this information in all the payloads the product is sent in if you want to query for it across the entire funnel. GTM or GA will not persist this information.<\/p>\ndataLayer.push({\n 'ecommerce'<\/span> : {\n 'detail'<\/span> : {\n 'products'<\/span> : [{\n 'id'<\/span> : 'A12345'<\/span>,\n }]\n }\n },\n 'event'<\/span> : 'ecommerce'<\/span>\n});\ndataLayer.push({\n 'ecommerce'<\/span> : {\n 'add'<\/span> : {\n 'products'<\/span> : [{\n 'id'<\/span> : 'A12345'<\/span>,\n 'name'<\/span> : 'My T-Shirt'<\/span>\n }]\n }\n },\n 'event'<\/span> : 'ecommerce'<\/span>\n});\n<\/code><\/pre>\n<\/div>\ndataLayer<\/code> as the page loads, making sure your developers add them consistently in all steps of the funnel. Once the products are in dataLayer<\/code>, you can use the Custom JavaScript Variable method<\/a> to pull them out and parse them into a valid ecommerce<\/code> object.<\/p>\n3. Product-scoped custom dimensions and metrics<\/h2>\n
dimensionX<\/code> and\/or metricX<\/code> key in the respective product in the payload you want to send the dimension\/metric in. Again, as in the previous chapter, product-scoped dimensions and metrics do not persist, so you will need to include them consistently in the payloads.<\/p>\ndataLayer.push()<\/code> would look like this:<\/p>\ndataLayer.push({\n 'ecommerce'<\/span> : {\n 'detail'<\/span> : {\n 'products'<\/span> : [{\n 'id'<\/span> : 'A12345'<\/span>,\n 'name'<\/span> : 'My T-Shirt'<\/span>,\n 'dimension3'<\/span> : 'Large'<\/span>,\n 'metric2'<\/span> : 11.99<\/span>\n }]\n }\n },\n 'event'<\/span> : 'ecommerce'<\/span>\n});\n<\/code><\/pre>\n<\/div>\n
![\"Product](\"https:\/\/www.simoahava.com\/images\/2015\/09\/product-categories.jpg#ZgotmplZ\")
<\/p>\n