Data layer implementation

The data layer is currently the most talked about topic of recent times. If you’ve started working on a new technology solution for your e-commerce business in 2021 (and beyond), you’ve probably been advised by an analyst, enlightened marketer or developer to consider implementing a data layer right from the start.

If not, we recommend ideally integrating this technology and philosophy into the project right away. Otherwise, after the new solution is launched, you may be in for some unpleasant extra work when marketing agencies need data for marketing and analytics tools.

What is a data layer?

The principle of a data layer (whether specifically a dataLayer object or the overall philosophy of a data object containing user, page, and product information) is not exactly groundbreaking technologically. 

It is a JavaScript object over which a queue is created using the Google Tag Manager library, thanks to which individual data (so-called push or event) are processed into analytical and marketing systems.

Often, the default data layer is created before Google Tag Manager is initialized and contains data about the current page (its type, category, etc.), the user (their ID, group, number of purchases, etc.) or products (the products displayed on the page, their IDs and prices, etc.). During the user’s browsing through the page (the data layer is cleared when the page is refreshed or the user moves to the next page), it is supplemented either automatically or by means of the so-called pushes with additional information (e.g. form submission, successful login, clicking something, etc.). 

Why is the data layer important when developing a solution?

If your technology supplier properly integrates the data layer during the development of the solution, you will save yourself a lot of trouble and modifications to the existing version of the website. Many marketing tags and data for them are obtained and set up based on events in the data layer. Especially if the data layer is generalized (some analysts use the word semantic – that means it makes it easier to navigate through it and provides appropriate context), you can create the final form of data for individual pixels using JavaScript directly in Google Tag Manager.

So developers don’t have to hard-code 6 variations of the same information in a different structure directly into the website, which in turn makes it easier for them.

How to imagine all this?

Imagine that a user comes to the web. The data layer will record information about the type of page (category, product detail, etc.) and whether or not the user is logged in. The data is supplemented with information about the products that are visible on the page. Before loading Google Tag Manager, the developer executes the following JavaScript code:

After the user has given their consent (see the article “Tips on cookies from the analyst’s practice”), this information can go to the systems using relevant marketing and analytics tags.

The data layer (or Google Tag Manager) then waits for the next event.

This may be, for example, adding a product to the cart. This can look very simplistically like this:

Again, this information then goes out to the systems and the whole process is repeated.

What is the ideal status?

Until 2020 (and of course now), the data layer structure that was used for Enhanced E-commerce for Google Analytics 3 (Universal Analytics) is very much the default. For a long time, this was more or less the only form of the data layer, along with the google_tag_params object, that you saw on websites (especially e-shops).

With the development of marketing and analytical technologies, the data layer was becoming more and more desirable and so were the superstructures above the GA3 e-commerce object. User, page and other objects started to appear, adding the necessary context to the data layer without having to scrape data from the DOM object. This brought significant ease in implementation.

With the opening of GA4 to the public, the situation became more complicated. GA4 by default requires a different data structure than GA3 EEC measurements. The more experienced know that there are templates of variables in GTM that convert the EEC GA3 model to the new data required by GA4 e-commerce measurement. But the question still remains – how to approach the data layer and its structure.

For developers offering their solutions to clients and for newly emerging e-shops, a generalized (so-called semantic) data layer structure is definitely the ideal way. In it, you do not solve the structure of objects according to GA3, GA4 or any other system, but you name the elements in such a way that you can best understand them and reflect the data model used in the e-shop. The conversion to the final form is done afterwards. So from one layer, you can easily prepare objects for GA3, GA4, Criteo, Glami or any other widely used system. 

Of course, it all depends on the life cycle of your current solution. A generalized data layer can be a big leap even for already established e-shops, where a complete redesign of the entire layer brings the need to redo the entire measurement mostly built on the GA3 model. A more appropriate situation seems to be to build the generalized layer next to the currently existing objects and pushes and gradually migrate to it.

If you need help with data layer design, documentation or long-term maintenance, please contact our professionals.

For agencies and developers

Especially for e-commerce solutions that you distribute to your clients, a robust and perfectly documented GA4-ready data layer is a huge competitive advantage. Contact us if you need help with its design as well as creating templates and business cases that you can then distribute to your clients.