Validating Data Layer Events Using the JavaScript Debugger

If you have used any tag management solution long enough, you know the importance of a data layer, or perhaps you’ve already implemented one for your organization. But, have you ever encountered a situation where you’re unable to validate the data layer events and variables in the browser console as they happen because of fast page redirects and reloads? If yes, then, fortunately, there is a solution to this problem.

It’s worth mentioning that while data layers can be object-based, like the Customer Experience Digital Data Layer (evangelized mostly by Adobe) or event-driven (like Google Tag Manager’s dataLayer)— our solution applies to both.

To give you a better understanding of the scenario, it’s best to look at a real-life example. Let’s say we have the following website with a data layer implemented. To keep things simple, I’ve created a bare minimum website.

The Problem

Upon performing an interaction that triggers a reload of the page, e.g. submitting a form, the page reloads so fast that we can’t see the data layer event firing in the console.

Now, this doesn’t mean that the 'formSubmit' event did not actually fire. It also doesn’t mean that the event will not be captured by Tag Management Solutions (TMS) like Google Tag Manager, Adobe Launch, etc. Tag Managers, if set up correctly, will still be able to capture these events since, under the hood, they are constantly on the lookout for data layer events.

However, if you don’t see the event captured by your TMS as well, it could be because of multiple reasons:

• Maybe there was a spelling mistake in the string identifier for the event 
• Maybe the string identifier had a trailing space ('formSubmit ' instead of 'formSubmit')

How will we validate this, since we don’t get to see it in the console? There is a solution called JavaScript Debugger.

The Solution: JavaScript Debugger

Every browser has a JavaScript Debugger that allows us to step through the JavaScript code and examine or modify its state. This is exactly what we’ll use to validate our data layer events before they are flushed out.

In our example, we will use Chrome’s developer tools, but other web browsers have similar tools. We won’t get into too many details, but just enough to solve our challenge.

Developer Tools 

There are many ways to open your browser’s developer tools. I personally prefer the shortcut Command+Option+I (Mac) or Control+Shift+I. This shortcut opens the last panel you had opened in the DevTools.

For me, it opened the Source tab but that might not be the case for you so please navigate to the source tab if that isn’t the tab that opened for you by default. As you can see there are a lot of other tools available here, but we’ll be focusing on JavaScript debugging. 

The Source Panel is split into three sections: 

• File Navigator: This lists all the files loaded on the page
• Code Editor: This shows the content of the file currently selected
• Javascript Debugging Panel: This contains various tools for debugging

Let’s go back to our example. In order to validate that our data layer event has been configured correctly and has all of the information required, we need to find the relevant code that handles the logic for that event, and then we need to use our JavaScript debugging tool to pause the code execution at the right moment in time when information is inserted into the data layer (when the user submits the form, and before the browser changes the page)—this is done with a feature of the debugger called a breakpoint. We'll get to that in a minute.

Before we set up our first breakpoint, let's review how to identify when this breakpoint should pause execution. Typically this is in the form of a JavaScript event listener.

In case you are unfamiliar with events and event listeners in Javascript, let me quickly explain it to you in non-technical terms. Think of an event as a signal from the browser that something happened. Event Listeners, on the other hand, “listen” for those events and are a way to execute a specific code or function in response to them. Please keep in mind that these events are different from tag management system data layer events. Usually, a JavaScript event results in a tag management system data layer event being triggered to notify the TMS of the activity.

Common javascript events are onclick, onmouseover, onkeydown, onsubmit, onload, and onunload. While many are self-explanatory, here’s what few of them mean:

• onsubmit event: occurs when a form is submitted 
• onload event: occurs when the page is loaded
• onunload event: occurs when the page has unloaded (or the browser window is closed). The unload event also triggers when the user navigates away from the page or reloads the page. 
• onbeforeunload event: occurs when the page is about to be unloaded.

For most use cases, adding a breakpoint on the beforeunload event will solve our data layer validation problem, but it’s worth mentioning that there are many other breakpoint types as well. The most well-known being line-of-code breakpoint. I would recommend using line-of-code breakpoints when you exactly know which region of the code you need to investigate, or in our case which exact region of the code is responsible for pushing data into the data layer. This could get fairly inefficient if the codebase is very large and you don’t know exactly where to look.

Using a Standard Event Breakpoint

To use an event breakpoint, open the Event Listener Breakpoints section, expand the relevant category, and check the relevant checkbox. In our case, we will use the beforeunload breakpoint found under the Load category.

As an alternative, you could also enter the following in the console. 

window.addEventListener("beforeunload", function() { debugger; }, false)

This code snippet will pretty much do the same thing as using the Event Listener Breakpoints section in developer tools UI.

So, when we submit the form on our example website, the developer tools pause the code execution once it hits the beforeunload function. Because of that, we are now able to validate the formSubmit event in the console as shown below.

Alternatively, we can also utilize the watch section in the Sources panel, to examine the values of javascript variables over time as shown below.

As I mentioned earlier, event listener breakpoints are just one type of breakpoints. Your browser’s developer tools offer many other types as well, so check out your browser’s official documentation to learn more about supported breakpoints.

Validate Data Layer Events

That’s it! You now know how to validate data layer events, using your browser’s developer tools, before they get wiped out by the new page load.

In case the beforeunload event did not solve the problem for you, try out other event listener breakpoints such as submit, click, etc. Depending on your website architecture, one of them will definitely pause the code execution just in time for you to view the data layer event in the console.

Also, do note that depending upon the number of scripts listening to these standard events, you might have to resume the script execution multiple times using the  button shown above until you are paused on the correct line of code and are able to see the data layer event you were looking for.

In case looking through the code this way to get to the correct line gets too inefficient (when there are tons of scripts listening to a standard event), then line-of-code breakpoint would be the right option for you.