Exploring the Click Element Variable in Google Tag Manager

Updated: May 25th, 2021

Google Tag Manager offers a whole bunch of variables that are at your disposal, built-in and user-defined ones. While I have posted many blog posts about user-defined variables (and I mean many, many, many, many…), this time, I’d like to put a spotlight on the unsung hero of built-in variables, Click Element.

To keep you intrigued, I can say that this variable has a twin-variable in GTM with the same abilities, also Click Element lets us use one of the most powerful (but also quite risky) features in GTM.  So stay tuned and continue reading.

Table of Contents

• What is Click Element Variable in Google Tag Manager?
• Where does the Click Element data come from?
• Click Element variable is not the only one of this kind
  • You can also create custom variables that access the same values
• Why would you need to use the Click Element variable at all?
• Example: Click Element + Matches CSS Selector
• Another case where Click Element variable is useful
• Exploring the gtm.element object
  • Expand the gtm.element object
• Final words

 

Video tutorial

There were some changes in GTM (in late 2020) that also affected how the Click Element variable is displayed in the GTM preview and debug mode.

To see those updates, watch this video:

Everything else (that is explained in this blog post) is still valid.

 

What is Click Element Variable in Google Tag Manager?

It is a variable that returns the element, that was clicked. By default, it is disabled in all new GTM containers and needs to be enabled by going to Variables > Configure (in the Built-in variables section). Then click the checkbox next to a Click Element.

But just enabling the variable won’t do anything in the Preview and Debug mode. You also need to have enabled at least one “Just links” or “All element clicks” trigger. If you’re not familiar with this process, I urge you to read the guide about Click Tracking with Google Tag Manager.

In GTM Preview and Debug mode, this variable looks really misleading and sometimes even similar to the Click URL but this is far from the truth.

Click Element returns a clicked object. If you click a link, this variable returns the actual element that was clicked. Not only its address (if it has one) but also attributes and other data that it contains (and is not necessarily visible for a non-technical eye).

But Google Tag Manager preview and debug console does not display those additional attributes. Therefore, sometimes, the only proof that these two variables are different is their type:

 

Where does the Click Element data come from?

It comes from some of Google Tag Manager’s default auto-event listeners. If you have at least one Just links, All Elements Clicks, Form Submission or Element Visibility trigger, it also enables (somewhere in the background) its respective auto-event listener that starts listening to certain interactions happening on a page.

Just links listener listens to link clicks. All Element Clicks listener is listening to clicks of any element on a page (that is not in the iFrame). Form submission listens to form submissions. And, as you probably guessed it, Element Visibility is listening to when a particular element appears on the screen.

When those listeners spot an interaction, they push certain data to the Data Layer. That data is related to the element, with which a user has just interacted. That dataLayer.push includes the following keys:

• gtm.element
• gtm.elementClasses
• gtm.elementTarget
• gtm.elementUrl
• gtm.elementId

If you go to GTM Preview and Debug mode > Data Layer, you might see something like this (of course, the values will be different).

Each one of those keys in the Data Layer variables can be accessed by the built-in variables in GTM (Click Element, Click Classes, Click Target, Click URL, Click ID). gtm.elementClasses, gtm.elementTarget, gtm.elementUrl and gtm.elementId are strings (read “text content”) but the gtm.element is an object that contains more information. Unfortunately, that is hiding deep and we’ll need to take a deeper dive. But that will happen a bit later.

By now, you should know/remember the following things:

• When an auto-event listener (this applies to clicks, form submissions, or element visibility) pushes data to the Data Layer, one of the pushed keys is gtm.element
• This value in the Data Layer can be accessed by the Click Element variable in GTM (but not limited to. More on that — a bit later)
• In preview and debug mode, Click Element might look similar to the Click URL variable but they are totally different. Click URL just simply returns a string that is a web address (URL). Click Element is actually a clicked element, an object and contains much more information about the element with which a user interacted.

In the upcoming chapters, we’ll take a look at Click Element alternatives, why is Click Element a very useful variable and also what other data is hiding in that gtm.element object.

Click Element variable is not the only one of its kind

So as you have already learned, Click Element returns the value that is stored in the Data Layer as a gtm.element key. If no such key exists, the variable will return undefined.

What some of my readers will definitely not know is that there is another built-in variable in GTM, which accesses the very same key in the Data Layer. And that is… drumroll, please … Form Element.

Yes, both of these variables access the same gtm.element key in the Data Layer (or, more precisely, Data Model). In fact, all Form and Click variable pairs are identical. They access the same keys:

• gtm.elementTarget is accessed by Click Target and Form Target variables
• gtm.elementUrl is accessed by Click URL and Form URL variables
• gtm.elementClasses is accessed by Click Classes and Form Classes variables
• gtm.elementId is accessed by Click ID and Form ID variables
• and finally, gtm.element is accessed by Click Element and Form Element variables.

Why is it like that? I cannot talk on behalf of GTM developers but I can guess. I think that this makes things a bit easier to understand for GTM beginners. In order to track clicks, a GTM user has to enable a click trigger and then activate click variables. The same process is with form tracking. If you want to use the built-in GTM form submission trigger, you need to enable it and then enable the form variables.

Such workflow sounds easier to understand for those who are just starting with Google Tag Manager. (but maybe my guess is wrong).

 

You can also create custom variables that access the same values

Alternatively, you can also create user-defined variables that will work the same as the aforementioned click and form variables. If you wanted to create, say, your own alternative to the Click Element variable, go to Variables > New > Data Layer Variable and enter gtm.element. It’s the name of the key that is stored in the Data Layer.

Both Click Element and Form Element variables access that very same key as well. So there you have it, 3 different variables return the same thing. Why would you want to create your own user-defined variable to access gtm.element? No particular reason. I just wanted to show you how things are connected here.

 

Why would you need to use the Click Element variable at all?

Since you already know that Click Element variable returns an object, with which a user interacted (e.g. clicked element, displayed element or submitted form), it’s time to take the next step. So where is this variable useful? When you need to work with an actual element.

The most popular use case is “together with CSS Selectors”. If you want to track, say, clicks of particular website elements but none of them have unique IDs, CSS Selectors might be a solution.

“CSS ….what?”, you might ask. CSS Selectors are patterns that allow you to select any elements on a page. For example, if you wanted to track clicks only of those elements that have the class “white-button” but also belong to the red sidebar widget of your website, the regular Click Classes variable would not work.

However, if you combine Click Element variable together with a Matches CSS Selector operator, that would be possible.

If you are just starting with Google Tag Manager and you have never heard of CSS Selectors before, I think that this topic might be a bit too difficult for you right now. There are many other things for you to learn first like:

• GTM Click Tracking
• GTM Form Tracking
• A general Google Tag Manager tutorial

 

Example: Click Element + Matches CSS Selector

Anyway, back to the main topic. I hope I won’t intimidate you too much with the following example. In my other (broader) guide on Click Tracking in GTM, I showed a case where CSS Selectors are really useful. Here it goes.

Imagine that you’re working on an e-commerce website and you want to track clicks of the Add To Cart button. The button does not have any link (hence our Just Links trigger will not work). All we are left with is the All Element Clicks trigger.

Unfortunately, not everything is that easy. Turns out that one button actually consists of two elements: button text and button background/rectangle.

If those two elements have similar IDs or Classes, using Click ID or Click Classes variables might still work. Take a look at the screenshot below.

Text of the button has a ID AddToCartText while the background (box) of the button has an ID AddToCart.

This situation is still very convenient and you would be able to create a trigger with a single condition (Click ID starts with “AddToCart”). However, sometimes, things might get more complicated when no IDs or useful Click Classes (read: CSS Classes) are available. What if an element actually consisted of 5 or more elements?

You could create multiple triggers for every element, assign it to a single tag but that’s not the way you should do. Your container must be as optimal as possible that’s why we should cope with that by creating a single click trigger and using CSS Selectors (if possible).

Let’s see how this works in action. We’ll apply CSS selectors to track Add To Cart button clicks. Take a look at the code of that button (in the screenshot below).

The button is created with an HTML element called button (with the ID AddToCart) and its direct child is a <span> element that contains the button text. With a single CSS Selector, we could instruct Google Tag Manager that we want to track clicks of an element of which ID is AddToCart and also all we want to track clicks of all its children (descendants).

In GTM, go to Triggers > New > Clicks > All Elements and enter the following settings:

Take note that we’re using Click Element as a variable because we are checking the entire clicked HTML element against our CSS Selector. Matches CSS Selector works only with the Click Element variable.

#AddToCart CSS selector means that we are interested in clicks of ALL elements that have AddToCart ID (exact match).

A comma means “OR”.

#AddToCart * CSS selector means that we are interested in clicks of ALL the descendants of elements that have AddToCart ID (exact match). In our case, the button text is a direct descendant of the button that has an ID AddToCart. Simo Ahava has published a guide explaining the technique of Wildcard CSS Selectors.

It will not be very easy to grasp on the concept of CSS Selectors if you have no previous knowledge or even idea what they are. However, knowing at least the basics will really help you in GTM. Here are additional guides for you to dig into:

• CSS Selectors
• “Matches CSS Selector” Operator In GTM Triggers
• 10 Useful CSS Selectors
• CSS Selector Guide for Google Tag Manager

But, on the other hand, keep in mind that CSS Selectors should be used with caution otherwise, your tracking implementation will be very unstable and easy to break.

 

Another case where Click Element variable is useful

All in all, Click Element as a variable should be used when you want to work with an actual element (not its attribute). An example of this could be Simo Ahava’s blog post where he shares a technique on how to capture a correct element in Google Tag Manager.

In that solution, he uses {{Click Element}} variable in this custom JavaScript.

By using the actually clicked element, Simo’s Custom JS code finds the closest element that matches a certain CSS Selector. This is an advanced technique but one day you will most likely need to use it.

 

Exploring the gtm.element object

Let’s enter the final chapter of this blog post. So what is that other data that is stored in the gtm.element object? How can we see it if the GTM Preview and Debug mode does not allow us?

Well, you have you use the console in your browser’s developer tools.

Prerequisites for this to work:

• Have enabled at least one All Element Clicks trigger on a page (any settings will work). Just Links, Form Submission, or Element Visibility will work too.
• (optional) Enable the Preview and Debug mode. This is not necessary but will make things a bit easier.

If you have enabled a click trigger, click any element on a page so that Click event appeared in the GTM debug console. Did it appear? No? Then refresh the preview mode and make sure that you have actually enabled at least one click trigger.

If the Click event actually appeared, that’s great. Now go to the Browser’s Developer tools and open the Console. On Chrome (Windows), press F12 and then go to Console. Here are also some tips for other browsers.

Enter dataLayer. Case-sensitive. And hit Enter.

Click the black triangle to expand. This is the list of all the dataLayer.push that occurred on a page. Choose the one that says gtm.click (if you are working now with the All Element Clicks trigger). If you’re working with the Just Links trigger, the event’s name is gtm.linkClick. Form Submission event name is gtm.formSubmit. Element Visibility event’s name is gtm.elementVisibility.

Seeing many gtm.click events? That’s because you clicked many elements on a page. If you want to check a particular event that you also see in the GTM debug mode, take a closer look at the number. In the GTM preview and debug mode that number will be larger by 1. At least that’s how usually things work if developers are not doing some nasty modifications to the dataLayer.

Anyway, when you spot the correct event, expand it by clicking the black triangle next to it.

 

Expand the gtm.element object

This is what was pushed by the listener to the Data Layer when you clicked the element.

See anything familiar? gtm.elementClasses, gtm.elementId, etc. Only the gtm.element has a black triangle next to it because it contains some additional data. And that’s where we’re going.

Click the black triangle (next to gtm.element) and you’ll see A LOT of keys that you can access. While the majority of them will look unusable to you, there are several things worth mentioning.

If you go deeper within that gtm.element key and expand parentElement and then className, you will be able to access the parent element’s class (if, for example, that element was clicked).

The same could apply to parentElement and then choosing the id.

So how can you use that information in Google Tag Manager? You just need to create a Data Layer Variable and define the full path to the key you want to access (starting with gtm.element).

In the case of the aforementioned example, you should enter gtm.element.parentElement.className.

This will return the class of the clicked element’s parent element. This also can apply to the element of which appearance was tracked by the Element Visibility trigger or the form, which was tracked by the GTM Form Submission trigger.

Other honorable mentions:

• gtm.element.parentElement.innerText – returns the plain text of the parent element
• gtm.element.firstChild.id – returns the id of the first child element

Also, this technique was used in the guide created by the Bounteous team, capture submitted form values with Google Tag Manager.

 

Final words

I initially planned to write a much shorter guide on Click Element. But the more I wrote, the more I realized that there are other things worth mentioning as well. At first sight, this variable looks boring and almost never used. But this is just a false perception.

Here are the key takeaways you should remember.

• Click Element accesses the gtm.element key in the Data Layer
• Unlike other built-in GTM Click Variables, Click Element returns an object (meaning that it contains a lot more data than just a regular text)
• Form Element and Click Element are basically the same variables. In fact, all Click variables and their Form Variable counterparts are the same.
• You can also create your own Element variable by having the Data Layer variable, which accesses the gtm.element key
• Click Element or Form Element are the only built-in GTM variables that support the Matches CSS Selector operator in triggers
• You can explore what other data is stored in the gtm.element key by using browser’s developer tools (console) and drilling down. Then you can access those keys by creating Data Layer Variables.

That’s it for this time! Have any related questions? The comments section is at your service.