{"id":75192,"date":"2025-02-08T06:10:33","date_gmt":"2025-02-08T06:10:33","guid":{"rendered":"https:\/\/peraltafinancing.com\/analytics\/create-a-css-path-variable-for-click-element\/"},"modified":"2025-02-08T06:10:33","modified_gmt":"2025-02-08T06:10:33","slug":"create-a-css-path-variable-for-click-element","status":"publish","type":"post","link":"https:\/\/fivemor.com\/?p=75192","title":{"rendered":"Create A CSS Path Variable For Click Element"},"content":{"rendered":"


\n<\/p>\n

\n

At one point in the turbulent year of 2020, you might have gasped in surprise when looking at the preview interface of Google Tag Manager<\/a>. No, I\u2019m not talking about the new preview mode interface<\/a>.<\/p>\n

Instead, I\u2019m referring to how the Click Element<\/strong> and Form Element<\/strong> built-in variables would now display a CSS path<\/strong> string<\/em> rather than the expected [object HTMLDivElement]<\/code> (or equivalent).<\/p>\n

\n

<\/p>\n

\"Click<\/p>\n

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

There was good and<\/em> bad in this update.<\/p>\n

The good<\/strong> thing was that the Click Element variable was now much more informative in Preview mode. Honestly, there\u2019s not much you can do with the object element string in terms of debugging. Being able to see the CSS path gives us more clues on how the clicked element was reached.<\/p>\n

The bad<\/strong> thing was that the preview mode output is very misleading. It claims now that Click Element returns<\/em> a string<\/strong> and a CSS path. It does neither. It still returns<\/em> an HTML element which you can use with your CSS selector predicates<\/a> and your custom DOM traversal scripts.<\/p>\n

\n

Just to reiterate: The behavior<\/strong> of Click Element has not<\/strong> changed. The only thing that\u2019s changed is how the Click Element variable is displayed<\/strong> in the Preview interface.<\/p>\n<\/blockquote>\n

I would have expected Google to keep the Click Element as it was and instead introduce a new built-in variable called Click CSS Path<\/code> or something. This would have avoided the ambiguity while still adding value to the variables in the container.<\/p>\n

Well, I want to show you how you<\/strong> can create your own CSS path variable. The variable uses the exact same method that GTM uses for determining the CSS path, so it should always match what you see in the Preview interface.<\/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

The CSS Path variable<\/h2>\n

In Google Tag Manager, go to Variables<\/strong> and click the New<\/strong> button to create a new user-defined variable<\/strong>.<\/p>\n

\n

<\/p>\n

\"New<\/p>\n

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

Next, choose Custom JavaScript variable<\/strong> as the type.<\/p>\n

\n

Unfortunately, custom templates<\/a> do not (yet) support DOM traversal or handling HTML elements, so you need to use a Custom JavaScript variable for this.<\/p>\n<\/blockquote>\n

Copy-paste the following into the code editor:<\/p>\n

\n
function<\/span>() {\n  \/\/ Build a CSS path for the clicked element\n<\/span>  var<\/span> originalEl = {{Click Element}};\n  var<\/span> el = originalEl;\n  if<\/span> (el instanceof<\/span> Node) {\n    \/\/ Build the list of elements along the path\n<\/span>    var<\/span> elList = [];\n    do<\/span> {\n      if<\/span> (el instanceof<\/span> Element) {\n        var<\/span> classString = el.classList ? [].slice.call(el.classList).join('.'<\/span>) : ''<\/span>;\n        var<\/span> elementName = (el.tagName ? el.tagName.toLowerCase() : ''<\/span>) + \n            (classString ? '.'<\/span> + classString : ''<\/span>) + \n            (el.id ? '#'<\/span> + el.id : ''<\/span>);\n        if<\/span> (elementName) elList.unshift(elementName);\n      }\n      el = el.parentNode\n    } while<\/span> (el != null<\/span>);\n    \/\/ Get the stringified element object name\n<\/span>    var<\/span> objString = originalEl.toString().match(\/\\[object (\\w+)\\]\/<\/span>);\n    var<\/span> elementType = objString ? objString[1<\/span>] : originalEl.toString();\n    var<\/span> cssString = elList.join(' > '<\/span>);\n    \/\/ Return the CSS path as a string, prefixed with the element object name\n<\/span>    return<\/span> cssString ? elementType + ': '<\/span> + cssString : elementType;\n  }\n}\n<\/code><\/pre>\n<\/div>\n
Save it and you\u2019re good to go!<\/p>\n
The script first builds the list of elements on the click path, all the way to the highest node in the document (html<\/code>).<\/p>\n
It does this by checking what the tagName<\/code> of the element is, and then adding class and\/or ID modifiers to it. Then, it moves to the next element up the DOM tree.<\/p>\n
Once the list is built, the script finally takes the stringified element object name itself (e.g. HTMLDivElement<\/code>) and adds that as the prefix to the CSS path string.<\/p>\n
A sample return value of the script could be something like this:<\/p>\n
'HTMLDivElement: html > body > div#blog > div.hasCoverMetaIn#main'<\/code><\/p>\n
This means that the clicked element is an HTMLDivElement<\/code> (<\/p>\n
), with a single class of hasCoverMetaIn<\/code> and the ID main<\/code>. The element has three ancestors: a <\/p>\n
, the  tag, and finally the  node itself.<\/p>\n
Summary<\/h2>\n
What is this script useful for? Good question!<\/p>\n
It\u2019s not very useful in a trigger, as you can use the matches CSS selector<\/strong> predicate for a more robust approach to identifying elements in the DOM tree.<\/p>\n
However, it might be interesting metadata to send to your analytics tool of choice with the click event. Sometimes sending the click path will help uncover missing bits of information that you might not have considered sending in the first place.<\/p>\n
For example, you might find out that your Click trigger has been too lax<\/strong>, collecting clicks from elements you never intended it to do. You can check the CSS path to see which \u201crogue elements\u201d are receiving clicks, after which you can calibrate the Click trigger itself to be more precise.<\/p>\n
Also, I miss writing articles like this, where I look at some nifty customization that is achievable with JavaScript.<\/p>\n
I hope you enjoyed the article! If you can think of a use case for the CSS path variable, please let us know in the comments!<\/p>\n<\/p><\/div>\n
          <\/code><\/div>\n