I previously covered the different integration patterns and pitfalls when implementing google analytics. In that article, however, I did not include 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 is 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 provides 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 us to track any potential type of event, such as scroll tracking, e-voucher download …One of the main caveats, 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 an event listener, by function binding or by leveraging a middleware. There are also different implementation patterns available for 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 listeners 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, that 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 an 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 set up the tracking is to embed 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 actual add to cart action and the tracking component.

One of the advantages 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.

Middleware

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.

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 codebase 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 rest 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 set up 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 disadvantage 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 gives the flexibility to use the data for other means, provided it can be integrated through service sidetracking.

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 make round trip calls before sending the data to Google Analytics.

Handling duplicate transactions

Transactions are a very particular type of event, 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.

• Using local, session storage or a cookie
• Using the Measurement protocols

Using local, session storage, 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 beforehand.

On the server-side, two main approaches 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, before pushing the message would work. The second approach requires that your e-commerce platform can 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 event, warning, or errors processed by the Google Analytics SDK to the javascript console. This allows us 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 you to identify what gets sent from your browser. Requests sent to the collect and batch endpoints of google-analytics.com 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.

Livestream

The real-time reports in Google Analytics can help get a sense of how Google Analytics is interpreting the data that you are pushing. 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 us to see how Google Analytics has interpreted certain events.

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.

Summary

There are multiple ways to implement event and transaction 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.

‍