10 Most Common Enhanced Ecommerce Mistakes (Implemented via GTM)

Updated: June 7th, 2020.

Enhanced Ecommerce (EE) is probably the most powerful web tracking feature in the Google Analytics toolset (I intentionally added the word “probably” so that I would more or less right #thanksCarlsberg). It allows you to track not only the final goal (purchase or something similar) but also the entire funnel (starting from the product impression).

However, with great power comes great responsibility (read: in order to properly implement EE you will face many challenges, issues, nuances, quite lengthy documentation (for an inexperienced eye), and some not-so-intuitive requirements). It isn’t always like that. The more EE implementations you do, the better you will become at it. However, the initial steps are full of traps and you will probably learn lessons the hard way.

Even though there are some very useful EE-related resources online (e.g. a bunch of Simo Ahava’s blog posts), people still tend to do same mistakes over and over again (at least that’s what if feels like when I’m seeing yet another post in the GTM community about the Enhanced Ecommerce problem that was discussed a week or two ago).

But I fully understand that. The topic is complex, there are many things you need to understand and keep in mind, some guides might look too complicated, and, in the end, the best teachers happen to be our own mistakes. However, those mistakes might cost a lot of time and money. That’s why I decided to also add my two cents to the ecosystem of blog posts/guides about EE. In this article, I will share Enhanced Ecommerce mistakes that I notice most often in others’ Google Tag Manager implementations (or questions in Google Tag Manager communities).

 

Before we continue: EE implementation (via GTM) is thoroughly explained in my Intermediate course

In May 2019, I have released an Intermediate Google Tag Manager course that takes a deep dive into various web tracking topics where GTM is one of the most important ingredients. I will uncover and explain many underutilized Tag Manager features but, most importantly, I tackle some biggest pains that digital marketers and analysts face in web tracking:

• iFrames and Cross-domain tracking
• Cooperation with developers
• Proper testing and debugging
• Enhanced Ecommerce, etc.

Enhanced E-commerce takes a special place in the course by getting a 2-hour-long module where I explain the entire implementation process, starting from planning and ending with the actual configuration and testing.

Many of my early-adopter students have named Enhanced Ecommerce implementation as one of their top pains at work and, after taking that intermediate course, they learned A LOT about it and now can own the process with confidence.

 

Most common Enhanced Ecommerce mistakes

Alright, enough of the introduction, let’s get down the business. Not all of these list items are considered critical mistakes. Some belong to the “it would be better if you did this” zone.

If you see that some very common mistakes are missing from this list (which is totally possible), let me know in the comments and I’ll add them here.

 

Mistake #0. Not studying EE-related resources well enough and trying to bet on your intuition

The majority of the mistakes mentioned below are caused (I think) because people don’t read the available resources online (the official docs, Simo’s blog posts, other resources).

My guess is that they just quickly skim some parts and try to figure out the rest along the way. The result? Well, this blog post is considered to be one of them.

 

Mistake #1. Using the Universal Analytics Transaction tag

If you’re familiar with the implementation of GA Standard Ecommerce, you already know that the purchase must be tracked with a Transaction Tag.

However, this type of Universal Analytics tag works only with the Standard Ecommerce. In the case of Enhanced Ecommerce, information about all funnel steps (including purchase) must be sent either with a page view or with an event tag (with Enhanced Ecommerce features enabled). The transaction tag will not work.

 

Mistake #2. Not following the structure (and naming convention) of dataLayer.push snippets

So here is the main principle of how the Enhanced Ecommerce implementation via GTM works. A developer pushes ecommerce data to the Data Layer (e.g. product impression, product click, add to cart, purchase, etc.), then you fire the Universal Analytics tag (with enabled Enhanced Ecommerce features) that sends the EE data (from the Data Layer) to Google Analytics.

But here’s the catch: a developer cannot just push some random ecommerce data to the Data Layer. The data must be formatted (and use the same naming convention) as it is strictly described in the official GTM documentation (for Enhanced Ecommerce).

In the dataLayer.push there always must be an ecommerce object that contains certain data related to a particular funnel step. Then there must be the name of the action (e.g. add, remove, purchase, checkout, etc.) and then some data related to that particular action.

<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'purchase',
  ecommerce: {
    purchase: {
      actionField: {
        id: '123456abc'
        revenue: '12.00',
        tax: '3.00',
        shipping: '1.00'
      },
      products: [{
        id: 'product123',
        name: 'MY PRODUCT'
        brand: 'Analytics Mania',
        quantity: 1,
        price: '12'
      }]
    }
  }
});
</script>

dataLayer.push does not have to include all the purchase-related fields that are displayed in the documentation (because some are optional), however, if you decide to include a particular parameter, then make sure that a developer uses the key of the attribute as it is displayed in the official docs.

Also, data types of those attributes must be as Google requires. If products is displayed in the documentation be an array then it must be an array.

P.S. if you’re not familiar with arrays, objects, and other data types in JavaScript, I explain that in my Intermediate Google Tag Manager course.

Mistake #3. Not being consistent

As Simo Ahava mentions this multiple times in his blog posts (e.g. this one), there is almost no attribution in Enhanced Ecommerce. This means: if you are tracking products and, for example, send the product name to GA (in the “add to cart” funnel step), that data will not be automatically available in the GA reports of subsequent funnel steps (e.g. checkout or purchase). Forget session or user scopes here. The only way to make sure that data (e.g. product name) persists in all the funnel steps is to ask a developer to push such product information (dimensions and metrics) to the Data Layer in every step of the EE funnel. Read this guide for more info.

Consistency is key here and you have to ask a developer to push the dimensions not just once (in a single funnel step) but to do that in every funnel step. That way you will be able to see, say, the stats of that particular product throughout the entire funnel.

P.S. Checkout steps are an exclusion to the rule here (it’s sufficient to pass the product data only with the first checkout step).

Tip: read this guide on attribution in Enhanced Ecommerce. There is almost none of it, however, you need to be aware of some exceptions.

 

Mistake #4. Entering the entire Ecommerce funnel in the GA View’s Ecommerce settings (or including the ‘purchase’ there)

Enhanced Ecommerce features must be enabled on the level of the Google Analytics view (by going to Admin > View > Ecommerce settings > Toggle Enable Ecommerce > Toggle Enabled Enhanced Ecommerce Reporting.

Once you do that, optionally, you can label the checkout funnel steps. But here is a part that, apparently, is tricky for those who just quickly skim Enhanced Ecommerce guides. Checkout funnel includes only those steps that happen after the product(s) is added to a cart (e.g. the customer clicks Start Checkout button) and before the actual purchase.

Checkout funnel is NOT the full Ecommerce funnel. You do not have to enter all the funnel steps here (starting from product impressions and ending with the purchase). That’s not how it works.

In this section, you only need to enter steps like “Enter billing information”, “Enter shipping information”, “Order review”, or something similar. A customer completes these steps only when he/she is ready to pay for what is added to a cart. However, the purchase (as a step) should not be entered here as well, because there is a separate ecommerce action called purchase that tracks it.

If we open the Enhanced Ecommerce reports of the official Google Analytics demo account, you will see that there are two funnel visualization reports:

• Shopping behavior
• Checkout behavior

Shopping Behavior includes all the Ecommerce funnel steps (starting from product views (if you track such data) and ending with a purchase). One of the columns in that funnel is Sessions with Check-out.

However, if you go to another report called Checkout Behavior, you will see that it consists of multiple steps (like Billing and Shipping, Payment (a.k.a. “enter payment information”), Review, and Sessions with Transactions). This funnel is a more detailed view at the Sessions with Check-out column of the previous screenshot.

These columns (except the last one) are the ones that are configured in the Ecommerce settings of the GA View.

 

Mistake #5. Trying to pass product-scoped custom dimensions on the level of the tag (or GA settings Variable)

If you are familiar with how to set the GA custom dimensions via GTM, you already know that they can be set either on the level of a Universal Analytics tag, or on the level of the GA Settings Variable.

But this applies only to the user, session or hit-scoped dimensions (not product-scoped). Imagine a situation: you’re tracking products that have a custom dimension called size (possible values: S, M, L, XL, XXL, etc.). Now you want to pass such dimension with every product to Google Analytics.

There are many cases where a single Enhanced Ecommerce hit might include multiple products (for example, a purchase). Each product in that payload might have different sizes. If you set the custom dimension size on the level of a Universal Analytics tag, how is GTM supposed to know which products should get what size? Well, GTM will simply not know that.

Therefore, product-scoped custom dimension (and the same applies to custom metrics) must be included in the ecommerce object that is pushed to the data layer and that dimension/metric must be placed right next to other product dimensions/metrics.

Based on the index (e.g. dimension2, metric1) GTM will know which custom definition is being used here.

 

Mistake #6. Not passing the Product ID or Product Name

If you take a look at the official Enhanced Ecommerce docs for GTM, you will see that only one of these two parameters are required when the product information is passed to GA.

However, I strongly advise on using both.

If you don’t include the Product name, you will see (not set) in the Product column of your GA reports.

If you don’t include the Product ID, then product list attribution will not work (of course, if you are tracking the performance of the product list in the first place). Simo Ahava has explained this part in his blog post (so if you’re interested, go ahead and check it out).

Mistake #7. Trying to send multiple actions with a single dataLayer.push

While Enhanced Ecommerce in Google Tag Manager allows you to send more than one data type in a single Enhanced Ecommerce hit, there are some limitations. But first of all, here’s an example of a totally acceptable dataLayer.push() that includes multiple Ecommerce data types (product impressions and promotion impressions).

For example, a single dataLayer.push (containing the ecommerce object) cannot contain both Product Click and Product Detail (when the detailed information about the product is viewed) at the same time.

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'ecommerce',
  ecommerce: {
    click: {
      actionField: {
        list: 'Related products'
      },
      products: [{
        id: '123456abc',
        name: 'Some product',
		brand: 'Analytics Mania'
      }]
    },
    detail: {
      products: [{
        id: '123456abc',
        name: 'Some product',
        brand: 'Analytics Mania'
      }]
    }
  }
});

A solution for this? Ask a developer to do two separate dataLayer.push (one for the Product Click and another one for Product Detail) and then send this information as two separate hits to Google Analytics. Like this:

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'eec.productClick',
  ecommerce: {
    click: {
      actionField: {
        list: 'Related products'
      },
      products: [{
        id: '123456abc',
        name: 'Some product',
		brand: 'Analytics Mania'
      }]
    },
  }
});

window.dataLayer.push({
	event: 'eec.productDetail',
	ecommerce: {
	detail: {
		  products: [{
			id: '123456abc',
			name: 'Some product',
			brand: 'Analytics Mania'
		  }]
		}
	  }
});

Read this chapter to learn more about combining different types of data in a single EEC hit.

 

Mistake #8. Misunderstanding with the Checkout and the Checkout Option

When you are measuring the performance of your checkout process, there are two types of data that you can send to GA: checkout and checkout_option.

What is the difference, you ask?

checkout should be pushed to the Data Layer when a visitor/user/customer enters a certain checkout step (for example opened the “Enter billing information” page).

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'eec.checkout',
  ecommerce: {
    checkout: {
      actionField: {
        step: 1
      },
      products: [{
        id: '123456abc',
        name: 'Some product',
        brand: 'Analytics Mania',
        quantity: 1
      }]
    }
  }
});

If you already know what payment method was chosen (because maybe that is not the first purchase of a customer), you can also send the option key that contains some additional information about that checkout step, for example, payment method.

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'eec.checkout',
  ecommerce: {
    checkout: {
      actionField: {
        step: 1,
		option: 'Paypal'
      },
      products: [{
        id: '123456abc',
        name: 'Some product',
        brand: 'Analytics Mania',
        quantity: 1
      }]
    }
  }
});

Alternatively, a developer can first push just the checkout object with the step number (to the Data Layer) and after that, a developer can activate an additional .push that contains the checkout_option (with the chosen payment method).

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'eec.checkoutOption',
  ecommerce: {
    checkout_option: {
      actionField: {
        step: 1,
        option: 'Paypal'
      }
    }
  }
});

If you choose to implement both checkout and checkout_step, remember this: a Checkout option hit is always sent after the corresponding Checkout Step has already been sent. So you can’t send a Checkout option hit for step 2 if you haven’t first sent a regular Checkout hit for step 2. This is where some people get stuck.

Once again:

• Checkout step one must be pushed first
• Then Checkout option for step 1 can be pushed

(the same applies to the rest steps of the checkout funnel)

On the other hand, you’re not required to send Checkout option hit at all (because some checkout steps might have no options at all).

Mistake #9. Sending EE-carrying hits before the pageview (as non-interaction hit: false)

This mistake will not affect your Enhanced Ecommerce data, however, some other parts of GA reports will suffer. Bounce rate, in particular. It will make it real low (which is not a good thing (learn why)).

First, let’s get a quick refresher on what is a bounce in GA. In short, a bounce rate is the percentage of single-interaction sessions on your web page. In other words, a visitor landed on your site, did nothing (i.e. did not interact with the content), and then left. To sum up:

• 1 interaction (e.g. page view) = bounce.
• 2+ interactions = no bounce.

Now, let’s go back to Enhanced Ecommerce. It’s perfectly fine to send the EE data not via Pageview tag (but with a GA Event tag). In fact, this is the way I always implement. However, there is one issue. What happens if:

1. I first send the product impression EE data with an event tag (meaning that a product is displayed)
2. And then separately track a regular pageview (with a Page view tag and without anything related to EE)?

The result: two hits are sent to Google Analytics. Two hits = two interactions = no bounce.

What if a visitor just landed on a product list, did nothing, and left? In this case, we would have sent two hits (a pageview and an event that transports the product impression data), therefore, such a session would not be counted as a bounce (even though this is a clear bounce). Not good.

What’s the solution?

Pick Google Analytics events that are sending EE data and that are being fired together, before or right after the GA pageview tag. Set those events to “non-interaction hit: true”. Such events will not affect the bounce rate (because they are sent as non-interactions). You still be able to see their data in the GA reports.

For example, if Add to cart EE data is sent right after the cart page loads, you should set the event to non-interaction hit: true.

 

Mistake #10. Exceeding the limit of 8kb per request to GA

Universal analytics has a certain limitation that might become very annoying for those who have implemented the Enhanced Ecommerce and are sending a lot of data with every request to Google Analytics.

That limitation is 8kb. A single request sent to Google Analytics cannot exceed the limit of 8 kilobytes. If it does, the request will not be sent to GA.

How is it possible to reach that limit?

If you’re tracking things like the product detail, add to cart, checkout, purchase AND usually, visitors are not buying many products at the same time, you’re (most likely) safe. However, if you are actively tracking product list impressions, if people usually buy, say, 50 products (or maybe you’re sending a lot of parameters with each product, chances are that you are already reaching that limit.

What can you do about it? First of all, you should check whether you have this problem in the first place. This guide explains the idea of how you can log requests that exceeded the request size limit. It might get quite challenging but it’s definitely worth a try.

Another option could be to follow this guide. It will send the request size to GA as a custom dimension. Unfortunately, if the request is too large, then the dimension will be sent at all. However, you will be able to see those requests that were quite close to reaching the limit. So, if you’re already quite close, that’s a warning that you should do something about it.

What is that something? What can you do about the requests that are too large? You can:

• Split the request into smaller ones (but this applies to transactions only)
• Or you can implement a solution that will automatically drop some of the parameters until the request size is acceptable

 

Most common Enhanced Ecommerce mistakes (via GTM): Final words

I’ll repeat myself once again. Enhanced Ecommerce in Google Analytics is an amazing feature that gives you a lot of great insight into how visitors/customers are behaving on your website/online store and where are they getting stuck in the journey to the final conversion.

However, not everything is so easy. In order to gain such rich reports, you need to work your ass off while implementing it together with a developer. Just by looking at this list of Enhanced Ecommerce mistakes you can realize that there are many nuances where digital marketers and analysts struggle.

That’s why I, by seeing repetitive posts in Google Tag Manager communities, decided to put a lot of focus on Enhanced Ecommerce in my latest Intermediate Google Tag Manager course. It includes over 2 hours of video material on how to properly own the process of EE implementation (from planning to the final testing).

So if this is one of your major work-related pain points, I have a solution for that.