Implementation methods for events and transactions tracking in Google Analytics

Julien Kervizic
Oct 16 · 9 min read

I previously covered the different integration patterns and pitfalls when implementing google analytics. In that article, however, I did not cover the implementation of events for Google Analytics, their setup within a website code base or how to QA them.

Events in Google Analytics

There are different types of events in Google Analytics, the most basic one is a Page view event, but other types of events are available such as enhanced e-commerce events and custom events.

Basic Tracking

The most basic of events within Google Analytics are Page Views events. They are triggered by default on every page load. An event is composed of four different components: Category, Action, Label and value.

The list of default analytics events is available here, and includes event types such as checkout, purchase, login, signup or search.

Enhanced Ecommerce

Enhanced e-commerce provide more granular tracking information by adding additional dimensions to certain events. For instance, with enhanced e-commerce add to cart and purchase events provide information at the product level rather than on a transaction level.

The use of enhanced e-commerce tracking unlocks some of the dashboards within Google Analytics that require this more granular information to be available.

Custom Events

Google Analytics allows for tracking custom events, this allows to track any potential type of event, such as scroll tracking, e-voucher download …One of the main caveat when implementing custom-events, is the impact of interaction events.

Interaction and Non interaction events: Events can be categorized as interaction or non-interaction events. The difference being that interaction events will be considered for the calculation of “Bounce” events.

Implementing Event Tracking

There are different ways to implement event tracking, each with their pros and cons. The first aspect to consider, is how the event triggers will be implemented in the code of the website. Triggers can be implemented, as event listener, by function binding or by leveraging a middleware. There are also different implementation patterns available with respect to the implementation of the tracking function, either leveraging Google Analytics’ SDK, calling the measurement protocol or propagating the events to a dataLayer.

Event Listener

Event listener are pieces of code that tie certain functions to actions being taken on the website. Event listeners rely on the HTML implementation and looks for certain action being performed to then trigger the function that is tied to the event.

Let’s say for instance, we had the following add to cart button set for the SKU 123 on our website.

We can create an event listener, that would activate based on a click on an addToCart button:

The example above uses a jQuery implementation and would activate for any button having the add to cart class.

There are different cases when to use event listener:

  • The first is that you want to decouple the tracking from the rest of the code, this can be the case when you have a different team responsible for the setup of the analytics than from the development of the core of the website or when you want to have a different release schedule from tracking purposes and not having to redeploy customer facing customer on any tracking changes
  • The second is that you have a fairly stable front-end in terms of components and classes.

Function binding

Another way to setup the tracking is to embedded the tracking in the functions that are performing the different actions.

The buy button above would call the javascript function “buy” with the parameter 123, presumably denoting some sort of product id.

The buy button above would call the javascript function “buy” with the parameter 123, presumably denoting some sort of product id. Within the buy function, two different actions would be performed, the actually add to cart action and the tracking component.

One of the advantage of using the function binding approach to tracking is that tracking needs to be owned and maintained by the development team and give them the onus of updating the tracking as they code of the website changes. Biding the tracking within the actions makes it obvious in the codebase.

Implementing it this way, however puts deployment of the analytics code on the same release schedule as the deployment of the rest of the code on the website.


Some javascript framework such as React, a popular front-end javascript framework, can make use of a middleware to propagate different events, in React this is usually done through a library named Redux. Using the middleware layer, different components can subscribe to these events and perform their own set of operations.

The picture above shows how of the interaction using such a middleware would work. A specific event trigger would be sent to the middleware, which in turns would be responsible for dispatching the data of this action to both a google analytics logger and the application itself.

More information as to how to implement Google Analytics tracking using redux is covered in the following article:

The middleware approach has the advantage of separating the different actions within the code base and of getting the developers to own the analytics integration. Unlike the Event Listener approach, using a middleware does however force the analytics code to be released on the same schedule as the ret of the front end code and usually requires the use of Javascript Frameworks such as React or Angular.

Tracking Function

There are different ways to setup the tracking function, either a direct SDK call, a measurement protocol request or a push of data to a dataLayer.

Direct SDK call: The tracking function can leverage the GA’s SDK in the manner of ga(‘send’ ‘pageview’) . This requires the Analytics SDK to be loaded on the website. The disadvantages of this approach is that it requires additional dependencies to implement and doesn’t allow for leveraging this data push in other ways, for instance for providing the data to other tracking scripts.

Measurement protocol: The tracking function can make calls to the measurement protocol, either directly or indirectly by passing through some backend system. Using the measurement protocol allows for no other dependencies to be loaded on the website, this can make it very suitable to implement tracking on lightweight pages. Like using the Analytics SDK, the approach of using direct measurement protocol calls does not allow for leveraging data for other purposes, however using indirect calls give the flexibility to use the data for other means, provided it can be integrated through service side tracking.

DataLayer: Events can be provided to a dataLayer and picked up by a tag manager such as google tag manager. The event push can be implemented in a simple manner like: dataLayer.push({‘event’: ‘myEventName’}); The main advantage of using this method is that you can use a tag manager with it and re-use this integration to set up other tags that will be fed with that data. This does come at the cost of performance issues from having to load the tag manager’s tags and script, as well as having to do round trip calls before sending the data to Google Analytics.

Handling duplicate transactions

Transactions are a very particular type of events and a significant number of implementations of Google Analytics Enhanced E-commerce, would fire a transaction event on page view, irrespective of whether or not the event has been fired before. This can cause some duplication on the number of orders and revenue being provided to GA. There are however a couple of ways to handle this.

  1. Using local, session storage or a cookie
  2. Using the Measurement protocols

Using local, session storage or or a cookie: A custom javascript would need to be implemented to check that a specific transaction id has not already been sent to google analytics. If the transaction is not present, trigger the event and place a record on successful response into local/session or cookie storage.

The above code shows an example as to what implementing this type of control would mean in terms of code.

Using the Measurement protocol: The measurement protocol essentially allows you to push data to google analytics using a server side script, this means that you are in perfect control or what get sent to google analytics and are free to do any type of check on the data before hand.

On the server side, there is two main approach that can be taken to avoid ending up having duplicates in Google Analytics. Either doing events duplicates detection or pushing the transactions server side based on order creation or payment, provided that the google analytics clientId has been sent as part of the transaction metadata.

For the first approach, either performing a database check on transaction id or using a message broker with duplicate detection functionality such as Azure Service Bus, prior to pushing the message would work. The second approach requires that your e-commerce platform is able to generate a webhook on specific event triggers if real-time integration is required.

Quality Assurance

There are a few ways to double check what ends up being sent to Google Analytics from your browser. There are a few methods for this, using a plugin such as the google analytics debugger, inspecting network traffic, looking at real-time reports or going straight for the raw data.

Google Analytics Debugger

The google Analytics debugger is a chrome extension, that outputs every events, warning or errors processed by the Google Analytics SDK to the javascript console. This allows to quickly identify what is being sent and if the code is sending events as intended.

Network traffic

The network traffic tab as part of Google Chrome’s developer tools allow to identify what gets sent from your browser. Requests sent to the collect and batch end points of are the one that needs to be dived into.

Using this network view, we can see which url or HTTTP post parameters have been sent to google analytics. These values are by themselves, hard to interpret but are part of the measurement protocol and can be checked from the Measurement Protocol Parameter Reference guide.


The real-time reports in Google Analytics can help get a sense of how the data that you are pushing is being interpreted by Google Analytics. The options to deep dive into the full actual data sample is somewhat limited, but it allows for some quick validation that you are sending the right information.

The event’s real-time report is of particular interest, as it allows to see how certain events have been interpreted by Google Analytics.

Raw data

For customers of Google Analytics 360, looking at the raw data exported by BigQuery can be a final validation that everything is behaving as expected. Unfortunately the export from BigQuery is not real-time and happens only every 8 hours, making it unsuitable for a large part of the validation process.


There are multiple ways to implement event and transactions tracking for Google Analytics. When implementing the analytics components, it is worth not just looking at the technical context of the implementation, but also how it affects the organization and make sure that ownership of the components lies in the right place and that the implementation and organization enables the right development and leveraging of the data.

Hacking Analytics

All around data & analytics topics

Julien Kervizic

Written by

Living at the interstice of business, data and technology | Solution Architect & Head of Data | Heineken, Facebook and Amazon | linkedin:

Hacking Analytics

All around data & analytics topics

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade