{"id":159783,"date":"2025-03-27T13:47:14","date_gmt":"2025-03-27T13:47:14","guid":{"rendered":"https:\/\/peraltafinancing.com\/analytics\/google-tag-managers-data-model\/"},"modified":"2025-03-27T13:47:14","modified_gmt":"2025-03-27T13:47:14","slug":"google-tag-managers-data-model","status":"publish","type":"post","link":"https:\/\/fivemor.com\/?p=159783","title":{"rendered":"Google Tag Manager’s Data Model"},"content":{"rendered":"


\n<\/p>\n

\n

It\u2019s time for MeasureCamp<\/a> again! As before<\/a>, I want to write an accompanying post for my session, since there\u2019s always so much more to say than the time slot allows for. So, the topic of this article is the data model used by Google Tag Manager<\/a> to process digital data in your data layer.<\/p>\n

This post also picks up where I left in my previous foray into the data layer<\/a>. However, where the first article aimed to be generic (since the data layer should be generic), this post will look at how GTM uses the information in the generic data layer, and how it processes this information to work with the proprietary features of the tool.<\/p>\n

\n

<\/p>\n

\"Data<\/p>\n

<\/a><\/p>\n<\/div>\n

The diagram above should elucidate my point (fear my PowerPoint-to-image skills).<\/p>\n

We have data passing through your backend systems to your website. Some of this data is used to build the website with its visuals and functionalities, and some of this data is stored in the data layer to be used by other tools and applications connected to the website.<\/p>\n

Google Tag Manager doesn\u2019t access the data layer\u2019s structure directly, since that would compromise the data layer\u2019s generic and tool-agnostic purpose. Rather, it pulls data from the data layer, stores it in its internal, abstract data model, and uses that<\/em> to process the digital data.<\/p>\n

Since we live in a multi-vendor world, where web tools and applications are popping up like mushrooms after rain, it\u2019s important to respect the generic data layer. It\u2019s up to the sophistication of the tool itself to use this data, but it must be done in a non-invasive manner – using pull methods rather than push.<\/p>\n\n\n\n\n\n\n\n\n
dataLayer<\/strong><\/th>\nData Model<\/strong><\/th>\n<\/tr>\n<\/thead>\n
Tool-agnostic<\/td>\nTool-specific<\/td>\n<\/tr>\n
Generic<\/td>\nUnique<\/td>\n<\/tr>\n
Accessed directly<\/td>\nAccessed via helper<\/td>\n<\/tr>\n
Structured<\/td>\nAbstract<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

There\u2019s a difference between data layer and data model. To some it might seem very subtle, but in reality it\u2019s what ensures that the data layer remains a free-for-all, standardized container for data. The data model, on the other hand, is built according to each platform\u2019s own specifications, but the way it communicates with the data layer must be clean and perhaps even standardized, since only that way can we ensure that a single tool doesn\u2019t ruin the data layer for all.<\/p>\n


\n X<\/span><\/p>\n

\n
\n The Simmer Newsletter<\/strong>\n <\/p>\n

\n Subscribe to the Simmer newsletter<\/a> to get the latest news and content from Simo Ahava into your email inbox!\n <\/p>\n

<\/span><\/p>\n

Setting up the test<\/h2>\n

The most familiar way of accessing GTM\u2019s data model is through the Data Layer Variable Macro. When you call this macro type, the following happens:<\/p>\n