A powerful feature of Google Tag Manager is the platforms ability to create event listeners that collects data on user interactions without the need for code. Never has something sounded so sweet to developers than the idea that data tracking is possible without ever touching the codebase. In the following two part guide, I will dive into detail about creating and testing event listeners for the purpose of reducing development hours and code bloat.
Brief Note on Changes in Google Tag Manager (Version 2)
A lot has changed with creating event listeners since version one of Google Tag Manager. In version one, the only way to create an event listener was to create a tag specifically for searching DOM interactions, which would then be referenced by each tag looking to use the listener. This is not the ideal setup to have to rely on when scaling tag use, as well as scenarios where additional admin’s are working on the container without understanding the listener logic and how it works.
Thankfully, all of this can be avoided in version two, with the creation of a predefined method at the trigger level. Instead of having to create event listener tags, you can create a trigger with a “Click” method to mimic the functionality found in creating an event listener tag.
Let’s Start the Show
Now that we have an understanding of how event listeners have evolved from version one to version two, let’s jump into creating a tag that utilizes an event listener!
Creating our Tag
Start by creating a tag based on the data that you are trying to collect. For the purpose of this guide, we will be creating a Google Analytics event tag that will give us information about the outbound links that users are clicking on.
When coming up with event naming conventions, I like to pull out keywords from the reporting question that drove us to start tracking specific data points.
In our example, it is “Information (event label) on the outbound links (event category) that users are clicking (event action) on.
Since we want to group together all of the outbound link that are clicked, it is best if we use a descriptive word or phrase for the group like “Outbound Links” for the event category.
For the event action, it has always been a best practice to use a verb interpreting the action a user has taken like click or submit. However, if there is a case where you need to pass a lot of information about an interaction, then I typically use this slot to pass additional information. For our example, we won’t have to worry about using the scenario explained as we have very simple reporting criteria. The value that should be used for our event action is “Click”.
Finally, our event label will capture the URL for the link that is being clicked. Since this value will be change from case to case, we will use a variable that will pass the URL from the click event to our event hit. In the next section, I will cover the definition of a variable and how to use a variable to track the dynamic URL value.
Summary:
Category: Outbound Links
Action: Click
Label: Element URL (Dynamically passed based on href)
Making Life Easier with Variables
This part of the setup involves variables, which are key value pairs that pass static or dynamic information at runtime. I will not be going into the wide range of variable uses in this guide, but I suggest that you read up on variables and learn about common use cases. To keep this simple for the purpose of teaching novice users about using event listeners, we will be using the predefined {{element url}} variable. This variable scans the page for the element that is being interacted with and passes back the href property of the anchor text.
Keeping Data Clean with Triggers
With our tag and variable setup finished, it is time to create the conditions that will trigger our tag and send data to the Google Analytics server. This is what I consider the most important part of our creation process as leaving the trigger conditions too broad will open you up to sending incorrectly labeled data and dirty your reporting.
Since we are only looking to track outbound links from our domain, the only condition that is required is, {{element url}} "not containing” our domain or associated sub-domains. This might be the easiest trigger setup you will ever conduct, but think of it as a stepping stone for future triggers where you will need to conceptualize all of the possible reasons why the trigger you will create might fail. As I mentioned before, if we don’t make this consideration, than it is likely that we could have done something like leave our trigger with an exact match condition, which would only capture our domain homepage. This is the mindset that you will need to have whenever you create triggers, so it is best if you wrap your head around a simple setup before taking on more complex setups.
For this example we will use the "does not contain" condition and add in our domain without a www so that any sub-domains that are present or possibly added in the future will be caught by our trigger.
Ready For Staging
Now that we have our tag, trigger and variable setup, it is time to conduct tests and publish the tag. In part two of this guide, I will review multiple ways to test this setup so that you will feel 100% confident that the data being sent will not be compromised by unforeseen scenarios.
Click here for Part 2: Debugging Google Tag Manager Event Listeners