Why Enhanced E-commerce and how to implement it

When working with E-commerce, one of the main concerns is how users interact with our website and our products. Which are the most common entry pages? What’s the conversion and bounce rate for each page? Which are the most visited products? There are many tools on the market that help us answer those questions. One of the most complete ones is Google Analytics (GA), a web analytics monitoring tool from Google, and we’ve been using it to answer most of our questions in the last six years.

Part of the process of maturing as an E-commerce is to scale the complexity of the questions we want answers to. For example, not only do we want to know which are the entry and exit pages, but also which are the pages with the most significant conversion rates. We want to know how our conversion funnel looks like and which of our users’ funnels are segmented by product type, traffic source, or users’ location. Also, we aim to understand which are the terms searched, which is the CTR of our search page, which are the positions on the page of the most clicked products, etc.

To obtain these answers, we’ve decided to implement Enhanced Ecommerce (EEC). This GA resource allows the generation of reports related to pages visualizations, clicks, conversions, and reports where the funnel steps talk to each other, generating more enriched information.

The EEC allows these event types to be sent to GA:

After studying the possibilities of EEC and adapting it to our business model, we’ve decided to implement the following events:

• Checkout Success → The confirmation of a purchase. This step is essential because we need to know how many purchases were made by our clients. We want to know how many products were sold, the type of the items sold, the currency of the purchase, the payment method, among other metrics and dimensions.
• Checkout → The step of filling out information to buy a product. The Checkout is crucial because it is where the clients will see the total value of the products, and we want to know how many clients enter this page and how many have abandoned at this step. Our site doesn’t have an “Add to Cart” process, so the Checkout step is the first step of buying.
• Detail → The visit to a product page. We have three types of products: hotel nights, packages (hotel nights plus plane tickets), and activities. We want to know which types are the most popular, and within each type, which are more accessed. The Detail step helps us with this analysis, and we can get the searched dates, for example.
• Impression/Click Search → The events of visualizing and clicking on a listed product on the search page. These events are essential to understand our products’ CTR and measure how our clients interact with a search result. We can get information about the results total number, which dates were searched, which terms are more searched, among much more information.
• Impression/Click Home and Product Listing Pages→ The events of visualizing and clicking in a listed product on the Home and in the Product Listing Pages (PLPs). This step is fundamental for a feature we’re going to discuss later: the Product List Performance. Besides having the products’ CTR, we can see which pages lead our clients to convert and the performance of which page.
• Impression/Click Packages → The events of visualizing and clicking in a listed product option on the packages’ pages. This step was made exclusively for our package products because we want to know which option the users are seeing and which options are being clicked. I’ll explain better about these options to you later.
• Impression/Click Promotions → The events of visualizing and clicking in a listed campaign banner on the Home and the PLPs. These events are essential for us to know how a marketing promotion card is performing. We want to know if the banners are attractive if our clients are clicking on them and converting.

After deciding which steps we would implement, we started defining which metrics and dimensions would be captured in each stage and which of them would be present in all phases. The events related to Promotions are very specific, so we’ll first talk about the Product Events.

Implementation design

One essential requirement for the efficient running of EEC is maintaining consistency across all domain pages. For example, the unique identifier of a product must be the same on all pages. EEC allows the unique identifier to be an SKU or the product’s name, so we’ve decided to use the SKU because it’s a better candidate for a unique key. This dimension appears on all pages, and we’re able to capture the paths of a product through this dimension.

Another critical requirement is the dimension List Name included on impressions and click events. The List Name is a resource of EEC that allows identifying which page was responsible for the conversion, since we have the same product on many pages. For example, a travel package for a trip to Salvador is listed in our Home, on a page related to Brazilian Northeast, and on a page containing packages with discounts. Using the List Name enables it to identify which was the last page containing a specific SKU visualized by a client before converting, and it assigns the conversion to that page. Since we sell to clients from all over Brazil, we need to adapt our offers to reach everyone’s needs. That’s why our company’s travel packages have different travel departure cities specified on multiple offer options.

The exception is the impression/click events on the package page. In this case, we don’t want to see all the paths until the conversion, we want to know which package options are visualized and clicked by our clients. So we used a different type of SKU as a unique key, an SKU that identifies a product’s offer option. This event was built to be analyzed independently, and the procedures made to get consistency through the funnel don’t apply in this case.

Some dimensions and metrics are native to ECC. Some of them are available in all funnel steps, like the SKU and Product Name. Some others are important to only part of the funnel, in our case. Examples are the Product Revenue and Currency, which are only important to us in the Check-out and Purchase events.

A particular case is the List Name. The purpose of this dimension is to be sent in a page containing a list of products. But a considerable part of our traffic lands directly on the product details page, where we send the Detail event. So we came with rules to assign the List Names based on different scenarios:

• User lands at our Home or some PLPs → The page’s identifier is sent as List Name (example: Home, Packages, Disney, Etc.) on the Impressions and Clicks events.
• User lands at a package Detail page → The identifier offer_detail is sent as List Name.

If the native dimensions and metrics don’t cover all data you want to grab, you can use Custom Metrics and Custom Dimensions. This possibility is terrific and helped us to get so much important data!

It’s required to have the same dimension in all funnel steps to segment the EEC funnel. For this purpose, we capture the type of product and the point of sale code in all funnel steps using Custom Dimensions. As we went global in 2019, we have three stores already, and the store code identifies which store the user was navigating. And segment by product type is essential because a different team handles each product on our business model.

Custom Metrics and Dimensions we capture include the total results of a search, which check-in date and check-out date the users are looking for, the destination of each hotel or package, among many others.

So, we know which events, metrics, and dimensions are necessary, including native and custom ones. The next step is to determine how to implement it and start capturing our precious data!

The Implementation

It’s possible to implement the EEC directly into the website’s script, but this has a particular syntax that will need many changes in the source code and mobilize many different teams. A more flexible option is to use the Google Tag Manager (GTM), Google’s tag management system, to manage, configure, test, and deploy snippets of code on a website.

Before talking about the implementation itself, it’s crucial to punctuate two requirements. First of all, to use the EEC, it’s necessary to activate the reports of the Enhanced E-commerce in the GA platform. And for the implementation using GTM, it’s required to populate the webpage’s dataLayer with the information you want to grab from it. The dataLayer is a layer of a website that allows access by external tools to the data stored on it, and this layer is populated during a page load or user interaction, according to what was programmed in the source code.

There are three types of elements in GTM:

• Variables → Elements that can be associated with one specific data in the dataLayer, or in the URL, or it can be built with JavaScript, among other options. We can say that it’s the primary element.
• Tags → Elements that are fired as events or pageviews. These elements are the ones that hold the information we want to send to GA, and we usually attach the variables we want to monitor to them. They are the main elements.
• Triggers → Elements that trigger the Tags. It can be associated with previously existing events, page loading, Etc.

To organize our implementation description according to objectives, we’ll segment this part into two types of implementation. For convenience, we’ll call Direct Implementation the events triggered when the page finishes loading and Interactive Implementation the events triggered depending on the user interaction with the website. The EEC format objects basic information can be consulted in the official developer documentation.

Direct Implementation

As a reference for this part of the project, we used Simo Ahava’s Enhanced Ecommerce Guide for Google Tag Manager. (I take this opportunity to thank him for all knowledge he shares with us; his blog was an extensive reference.) In this category, the events included are Checkout Success, Checkout, and Details.

First Step: DataLayer Variables

As mentioned before, it was crucial to have all the information we need to grab on the dataLayer for our implementation. So, having all data available, it was needed to create the Variables on GTM. Our variables are DataLayer Variables because they fetch the data from the dataLayer, and they’re from DataLayer Version 1. Although version 1 does not support nested arrays, when working with version 1, the variable will reference the newest push on the dataLayer. A little confused? For example, I have a product on the checkout page that costs $100 in our inventory system from where I fetch the products’ information during the page loading, but I want to put a different discount on it. So I’ll do a new push on the dataLayer with the new Price’s value of $80, then using Version 1 will overwrite the Price preceding value.

Example of GTM’s dataLayer variable.

Second step: Custom JavaScript Variables

As described before, there’re plenty of variables we can create. The JavaScript Variable is used to create the object of the EEC. The function that delivers the purchase object is shown below. Note that this structure is very particular from EEC. For the Checkout Success (purchase object), you must have this specific object format, calling the purchase object inside the e-commerce main object and the actionField apart from the product object. In our case, we sent one product per purchase, but you can send multiple products inside the products array as well. One point of attention is that there are limitations about the payload size limitations.

Purchase event’s object.

On the action field, you’ll insert data about the order itself. If your website allows users to buy more than one product per time, you’ll insert revenue as the sum of each product’s revenue, and in the products fields, you can insert each products’ values. Important: if you only insert the quantity and the price in the products field and do not insert the revenue on the action field, GA will multiply the quantity by price to get the total revenue.

In the object, you can note native dimensions and metrics, like revenue, id, name, and custom ones. Custom metrics and dimensions must be declared on the EEC object with `metricX` and `dimensionY`. Otherwise, the ECC will not process them. You need to configure these custom metrics and dimensions on the GA platform, and you can see how to do it here.

Third Step: The Tag

The Tag is our central entity, but it’s the easiest part to configure. The Tag Type must be Google Analytics: Universal Analytics if you’re using GAUA. The Track Type must be `event` because the pageview type doesn’t allow us to set the Category and the Action. For Category, Action, and Label, you can set up names that make sense to you. For all the steps we classified as Direct Implementation, set up the Non-interaction Hit as True because these Tags will be fired in the page loading. Enable the overriding settings to be able to access the EEC option and set up your Tracking Id.

Example of GTM’s tag configuration for purchase event.

In the More Settings menu, we’ll configure all the custom metrics and dimensions used on the object we built before. In Custom Dimensions and Custom Metrics, we put the indexes of the elements we configured on the GA platform and the variable associated with each of them.

Example of dimensions and metrics attribution.

In the Ecommerce menu, you’ll enable the Enhanced Ecommerce Features and associate the object of the step you’re configuring at Read Data from Variable. Set up the Tag firing options to Once per event and then connect the trigger. And the Tag is read to go!

Referencing variable and connecting trigger.

I used the Checkout Success (Purchase) event to exemplify the Direct Implementation, but the steps are the same for all the events triggered on the page loading. You may find all the native metrics and dimensions available for each step In the EEC documentation.

Interactive Implementation

This implementation was different because of its objectives. With the Direct Implementation, we want to see if a client achieves that step of the funnel, so the events are triggered when the page finishes loading. On the other hand, in the Interactive Implementation, multiple events are triggered on the same page; these are events related to each product visualization and click by a client, obtaining the CTR of each product.

We also used multiple events as reference content from Simo’s blog, the True View Ecommerce Impressions With Google Tag Manager. We’ve made some modifications to avoid conflicts in our implementation.

First Step: DataLayer Variables

In this step, we don’t collect the data individually on the dataLayer like in the previous implementation, we’ve created a dataLayer variable associated with a data array that contains information about all the products listed on a page.

Example of the array of content on dataLayer.

Second Step: HTML Tag

The EEC object construction took place by creating a Custom HTML Tag in which the array collected is organized in the proper format. Then the tag makes a dataLayer push of the final object.

Custom HTML tag which pushes the object to the dataLayer.

And the trigger for this Tag is the event that inserts the data array on the dataLayer.

Third Step: Element Visibility Trigger, the true view impression handler, and the true view object

This part is very similar to Simo’s article for our products, but we needed to make some changes to get the CTR for the promotion cards, so I’ll focus on it. First of all, our Home and PLPs have cards listed among the products, like the image below.

Our website and its cards disposition!

Reason why we implemented the impressions and clicks for these two elements separately. We change variable names, the unique identifiers for cards and products are different, besides they are in the same array. We need the unique identifier of the EEC object to be in the HTML Layer of the website as well, identifying each element in this implementation, with different names for products and cards.

The Element Visibility Trigger is the principal feature of this implementation. It is a native trigger activated when the desired element is visible in the user’s screen.

The True View Impression Handler is a Custom JavaScript Variable developed by Simo that basically builds the batch of elements that will be fired and creates the beforeunload handler (a trigger that I’ll explain later). Simo’s implementation considers the events for products, but as we have products and cards on the same page, we needed to consider some changes to avoid conflict, mostly on click events. Our True View Impression Handler for promotions is featured below.

The True View Impression Handler custom JS variable.

The True View Object builds the EEC object and in this element, besides changing variables names, rename variables, change the event we get from the dataLayer, the main difference was the ECC object that you can see on the function’s end.

The True View Object custom JS variable.

A full explanation of how each part of these codes works is also available in the original article, which could not have been explained in a better way.

Fourth Step: Get Impression Label and Get Impression Interactions

These elements are variables that determine if the fired event will be an impression event or a click event. Their implementation is exactly like the one in the original article.

Fifth Step: Triggers

In this case, we have four possible triggers:

• beforeunload_final_batch →An event created and watched on the True View Impression Handler that triggers the Impression event if the user leaves the page and the batch of products/promotions contain elements.
• click_trigger→Native GTM trigger that fires the event in case of a click. This trigger also influences the changes of Label and Interaction Mode on the main Tag.
• element_visibility_trigger → The trigger that always fires when the desired element is visible in the user’s screen and this process the element will be inserted inside the batch built by the impression handler, and the main tag will be fired when the batch has the maximum number of elements inside of it.
• timer_trigger → A trigger that fires after 60 seconds of user downtime if the batch has elements.

In short, the primary tag can be fired in four distinct ways and each time the batch is reset. This section was totally based on Simo’s work, feel free to check out the original article for more details.

Results

We achieved good results from this work and many projects derived from the insights we extracted from GA after that. One of the exceptional results is that our product and marketing teams can now identify the main bottlenecks in the general funnel or segmentation per product type, per point of sale, per user’s location, among others possibilities.

GA’s Shopping Behavior report.

Another key feature is the Product List Performance which allows our Marketing Team to analyze each page’s performance. In addition, our Commercial and Operations teams can see each product’s performance through the funnel.

GA’s Product List Performance report.

We also have improved the quality and the accuracy of our data. For example, before this project, we had a four-digit error in our Revenue data and now have reduced it to inexpressive values.

In the beginning, it can be challenging to collect all the required information, mobilize many teams to make the dataLayer changes, and implement it. Still, with a vast community always available to help, we can get the maximum value that GA can offer and increase the level of our analysis!

Join the crew if you like what we are doing at Hurb! We are continually seeking sharp analytical people for our Data & Analytics Tribe. We have offices in Rio de Janeiro, Porto, and soon in Montreal.