The functions utag.view and utag.link are used to track page views and events. This article will show how to debug these functions to see how and when they are being called and what data is being passed.
To enable, open the debugging tools in your favorite browser and type the following command:
This cookie turns on debug mode within utag.js, which generates useful output to the console.
Once debug mode is enabled, when you trigger actions on the page that are tracked you will see debug logs in the console. Inspect the console output for: trigger: view or trigger: link
Here is an example of how this will look in the console after an event is tracked:
Click the line under “trigger:view” or “trigger:link” to expand and collapse the event data object.
For more in-depth debugging, it can be useful to set breakpoints in utag.js to pause the code when calls tracking calls are made. This allows you to review the data being passed as well as examine the stack trace to see where the call originated. Follow these steps to use Chrome developer tools to set a breakpoint:
In Chrome Developer Tools, go to Sources and open utag.js.
Unminify (pretty print) the code by clicking the curly braces at the bottom left of the window.
Find the line with return this.track( and click the line number to set a breakpoint:
Return to the main window and perform an action to invoke one of the tracking calls. When a tracking call is made one of the breakpoints will stop the action and you can inspect the code.
In the right-hand side of the developer tool there is a section called Watch Expressions. Click the plus sign + to add a watch expression. Type a and hit Enter to add a watch exppression for this variable.
Expand the object that is contained in parameter a to show the data was passed to the tracking call. This is the data that you have to work with in extensions, load rules and mappings.
One of the advantages of this method is that you can use the Call Stack, reported through the Developer Tools in the Sources tab, to inspect the origin of the tracking call.
Here is an example when looking for the location of a utag.link call:
Item (1) in the image above shows the breakpoint in utag.js that was placed to trap the utag.link call. Item (2), when clicked, shows the utag.link call that is made within the source code (to the left).
You have now successfully been able to debug three things:
Did the breakpoint get hit. If yes, then the function is set up to be triggered correctly.
Since the breakpoint was hit, you were able to see what data was sent when utag.view or utag.link was called.
You were able to view the actual configuration of the utag.view or utag.link call.
This is helpful when you are not seeing the correct data passed when certain events are triggered. Chances are the data being sent in the function is incorrect.
Below is a breakdown of the different output results you see. This is not a comprehensive list as the output will be specific to your implementation. The log output may change at any time due to updates and enhancements.
Pre Loader scoped extensions are now running.
The library begins to read data such as the UDO, Meta Data, DOM data and more.
The standard utag.js file logic is initiated.
All Tags EXTENSIONS
All Tags scoped extensions are now running.
utag.loader.INIT: waiting 1
Tags waiting for DOM Ready.
The library is ready for DOM Ready to occur.
Indicates how many tags are set to wait, e.g. the services-dang/tiq-as profile has 4 tags enabled and all 4 are set to wait.
Attach to head
Tag script is added into the source code.
The specified tag is loaded into the browser but to wait until DOM Ready to fire the Tags.
The tag’s u.send function runs, sending data to the tag.
The tag is triggering the call to the vendor.
Tags are about fire due do DOM Ready.