{"id":135314,"date":"2025-03-15T14:00:52","date_gmt":"2025-03-15T14:00:52","guid":{"rendered":"https:\/\/peraltafinancing.com\/analytics\/gtmtips-data-layer-variable-versions-explained\/"},"modified":"2025-03-15T14:00:52","modified_gmt":"2025-03-15T14:00:52","slug":"gtmtips-data-layer-variable-versions-explained","status":"publish","type":"post","link":"https:\/\/fivemor.com\/?p=135314","title":{"rendered":"#GTMTips: Data Layer Variable Versions Explained"},"content":{"rendered":"


\n<\/p>\n

\n

Google Tag Manager<\/a>\u2019s Data Layer<\/a> is something I\u2019ve touched upon in pretty much all of my articles. It\u2019s such an integral part of what makes a tag management solution great and applicable to a host of business scenarios. I\u2019ve also talked at length about the internal data model of Google Tag Manager, and this #GTMTips<\/a> post is very much related to this rather murky concept.<\/p>\n

In this post, we\u2019ll go over the Data Layer Variable Version<\/strong> selection, and I\u2019ll try to explain just what this selector does.<\/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

Tip 40: The two faces of the Data Layer Variable<\/h2>\n
\n

<\/p>\n

\"Data<\/p>\n

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

Let\u2019s start by taking a step back. As a technical construct, the \u201cData Layer\u201d in GTM is a JavaScript Array<\/strong>, which usually comprises a number of plain objects<\/strong> that have been pushed into its innards on a web page.<\/p>\n

\n

<\/p>\n

\"dataLayer\"\/<\/p>\n

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

As you\u2019ve learned from my data model article<\/a>, GTM doesn\u2019t actually access this Array when you create your Data Layer Variables. Instead, when an object is pushed into dataLayer<\/code>, it\u2019s made available to the data model of Google Tag Manager, and any Data Layer Variables you create will refer to these instances in the data model rather than directly accessing the Array itself.<\/p>\n

Why? To decouple the Array from the internal mechanisms of the connected platform (GTM in this case). This is quite important, as the less GTM needs to rely on the abstract structure of dataLayer<\/code>, which could be manipulated at any time by either sloppy code or another connected platform, the better.<\/p>\n

Now, when you select the Version<\/strong> of the Data Layer Variable, you\u2019re instructing GTM to treat the values in the data model in two different ways.<\/p>\n

Version 1<\/h3>\n

Version 1 of the Data Layer Variable has a very limited reach. Basically, the key-value pair that is pushed into dataLayer<\/code> needs to be in the root of the object, as Version 1 doesn\u2019t let you access nested keys.<\/p>\n

Here\u2019s an example of what would happen with a Version 1 Data Layer Variable that points to key name 'product.price'<\/code>:<\/p>\n

\n
\/\/ Works because the dots are in the key name, and the key is in the root:\n<\/span>window<\/span>.dataLayer.push({\n  'product.price'<\/span> : '11.99'<\/span>\n});\n\/\/ Won't work because 'price' is nested in the 'product' object:\n<\/span>window<\/span>.dataLayer.push({\n  'product'<\/span> : {\n    'price'<\/span> : '11.99'<\/span>\n  }\n});\n<\/code><\/pre>\n<\/div>\n
You could, though, access the nested object indirectly with a Version 1 Data Layer Variable by creating the variable for the key 'product'<\/code>, and then manipulating the returned object in a Custom HTML Tag or a Custom JavaScript Variable.<\/p>\n
And\u2026yeah. That\u2019s all that Version 1 does. There\u2019s no merging, no special data model functions, no nothing that you can use to further manipulate the retrieved object. So let\u2019s take a look at what happens when I push two different values for the same key ('product'<\/code>):<\/p>\n
\n
window<\/span>.dataLayer.push({\n  'product'<\/span> : {\n    'price'<\/span> : '11.99'<\/span>\n  }\n});\nwindow<\/span>.dataLayer.push({\n  'product'<\/span> : {\n    'name'<\/span> : 'Tim Duncan Fan Club Membership'<\/span>\n  }\n});\n<\/code><\/pre>\n<\/div>\n
In the example above, if I had my Version 1 Data Layer Variable pointing to 'product'<\/code>, it would return a plain object with {'price' : '11.99'}<\/code> after the first push, and a plain object with {'name' : 'Tim Duncan Fan Club Membership'}<\/code> after the second.<\/p>\n
In essence, any information in the first push is completely overwritten<\/strong> (for this particular Data Layer Variable) by the second push with the same key name ('product'<\/code>).<\/p>\n
Version 2<\/h3>\n
If you want more flexibility, use Version 2 of the Data Layer Variable. This treats objects more like you\u2019d expect if you\u2019re familiar with how JavaScript works.<\/p>\n
Instead of bulldozing over existing keys, Version 2 first checks whether a key with that name already exists in the data model. If it does, it recursively merges<\/strong> information in the new push with information in the existing object.<\/p>\n
Let\u2019s see an example:<\/p>\n
\n
window<\/span>.dataLayer.push({\n  'product'<\/span> : {\n    'price'<\/span> : '119.99'<\/span>,\n    'category'<\/span> : 'Membership'<\/span>\n  }\n});\nwindow<\/span>.dataLayer.push({\n  'product'<\/span> : {\n    'price'<\/span> : '1199.99'<\/span>,\n    'name'<\/span> : 'Tim Duncan Fan Club Membership'<\/span>\n  }\n});\n<\/code><\/pre>\n<\/div>\n
So, let\u2019s say you\u2019re using Version 2 of the Data Layer Variable, and you\u2019re yet again pointing to the key with name 'product'<\/code>.<\/p>\n
After the first dataLayer.push()<\/code>, the variable would return a plain object with:<\/p>\n
\n
{ \n  'price'<\/span> : '119.99'<\/span>, \n  'category'<\/span> : 'Membership'<\/span>\n}\n<\/code><\/pre>\n<\/div>\n
After the second push, the contents would be:<\/p>\n
\n
{\n  'price'<\/span> : '1199.99'<\/span>, \n  'category'<\/span> : 'Membership'<\/span>, \n  'name'<\/span> : 'Tim Duncan Fan Club Membership'<\/span>\n}\n<\/code><\/pre>\n<\/div>\n
Can you see what happened here? Another object with the same key name ('product'<\/code>) is pushed. Version 2 of the Data Layer Variable finds an instance of this key within the data model. Then, it recursively checks each key within this object to see if there are conflicts.<\/p>\n
First, it finds that 'price'<\/code> is in both objects, so there\u2019s a clash. Next, it checks if 'price'<\/code> is also a plain object or an Array to see if it should perform yet another merge deeper in the structure. However, the value of 'price'<\/code> is a String, which means that no recursive merge is performed, and the new value overwrites the old one.<\/p>\n
Next, it sees that 'category'<\/code> does not have any conflicts, so it leaves it be in the object. Finally, it finds a completely new key in the second push, 'name'<\/code>, and it merges this key into the existing object in the data model.<\/p>\n
So using Version 2 of the Data Layer Variable, resolution of conflicts in object key names is first attempted via a merge of the two objects, but if there are new \u201cprimitive\u201d values for any pre-existing keys, their values are overwritten just as they would be with Version 1 of the Data Layer Variable.<\/p>\n
So what?<\/h2>\n
This information could lead to a number of conclusions, but I\u2019m guessing many have the following two questions pop into their minds:<\/p>\n
    \n
  1. \n
    Why does the Version 1 still exist? Its numbering alone would mean that it\u2019s inferior.<\/p>\n<\/li>\n
  2. \n
    What on earth do I need recursive merge for?<\/p>\n<\/li>\n<\/ol>\n
    One of the best use cases for Version 1 is with Enhanced Ecommerce<\/a>. If you\u2019re using the Custom JavaScript Variable<\/strong> method, which I seem to use almost exclusively, you probably want to use Version 1 of the Data Layer when interacting with the 'ecommerce'<\/code> key. This way, GTM will only access the most recent push<\/em> into dataLayer<\/code>. And why is this significant? Take a look at the example below:<\/p>\n
    \n
    window<\/span>.dataLayer.push({\n  'ecommerce'<\/span> : {\n    'impressions'<\/span> : [{ ... impressions ... }]\n  }\n});\n\/\/ Later on the same page\n<\/span>window<\/span>.dataLayer.push({\n  'ecommerce'<\/span> : {\n    'detail'<\/span> : { ... product detail view ... }\n  }\n});\n\/\/ And yet later on the same page\n<\/span>window<\/span>.dataLayer.push({\n  'ecommerce'<\/span> : {\n    'add'<\/span> : { ... add to cart action ... }\n  }\n});\n<\/code><\/pre>\n<\/div>\n
    If you used Version 2<\/strong> of the Data Layer Variable to send the Enhanced Ecommerce payload using the Custom JavaScript Variable method, you\u2019ll end up with three<\/strong> Impression payloads, two<\/strong> Product Detail Views, and one<\/strong> Add to Cart action. This is because of the recursive merge<\/em> of the 'ecommerce'<\/code> object! I\u2019m guessing your intent is to only send each payload once.<\/p>\n
    So, if you instead use Version 1<\/strong> of the Data Layer Variable to access the 'ecommerce'<\/code> object, GTM will only access the payload that was most recently pushed into dataLayer<\/code>. This way you\u2019ll end up avoiding the payload multiplication problem.<\/p>\n
    As for the second point of what recursive merge is good for, there\u2019s a whole universe of possibilities when it comes to merging of objects instead of overwriting previous instances. Examples include:<\/p>\n