One of the key skills for anyone<\/em> working with web analytics<\/strong> and tag management<\/strong> is understanding how to identify where things went wrong, why they went wrong, and ideally how to fix them.<\/p>\n There are plenty of excellent browser extensions for helping you debug, and we\u2019ll discuss these in the guide, too. But most of all we\u2019re going to use browsers\u2019 own developer tools<\/strong>, as they are always the best source of truth for anything that happens within the browser window.<\/p>\n In the guide, we\u2019ll use Google Analytics 4<\/a> and Google Tag Manager<\/a> as examples. However, the guide\u2019s topics can be extended to any<\/em> web analytics tools and tag management solutions out there, because the use cases are universal.<\/p>\n \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 Your best friend in debugging issues with your web analytics and tag management systems in the web browser are the browsers\u2019 own developer tools<\/strong>.<\/p>\n Developer tools are a suite of utilities that you can use to investigate various different aspects of the dynamic web page the user is inspecting.<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n The image above lists the keyboard shortcuts<\/strong> for opening the developer tools in various browsers and operating systems.<\/p>\n Note that on Safari<\/strong>, you\u2019ll want to open Safari<\/strong> -> Preferences<\/strong> -> Advanced<\/strong> and check the button next to Show Develop menu in menu bar<\/strong>.<\/p>\n<\/blockquote>\n All of the browsers above utilize a similar set of developer tools with just small differences in the UI and the chosen semantics. The most useful tools we\u2019ll focus on are:<\/p>\n The element inspector<\/strong>, which lets you look at the dynamic representation of the web page (D<\/strong>ocument O<\/strong>bject M<\/strong>odel). This is particularly useful for inspecting injected tracking scripts and custom HTML elements added by tag management solutions.<\/p>\n<\/li>\n The network debugger<\/strong>, which lets you inspect and analyze outgoing HTTP requests<\/strong> sent from the page (or embedded frames). This is one of the most important tools for you, as it will tell you the truth<\/strong> about what is actually sent from the user\u2019s browser.<\/p>\n<\/li>\n The JavaScript console<\/strong>, which lets you run JavaScript code in the context of the current page (or embedded frame). Vital for recognizing issues with the JavaScript implementations of your analytics scripts.<\/p>\n<\/li>\n The sources browser<\/strong>, which lets you browse through the JavaScript resources loaded on the current page (or embedded frames). Great for identifying mismatches between what you expected the JavaScript file to contain vs. what\u2019s actually<\/em> contained within.<\/p>\n<\/li>\n The application storage<\/strong>, which lets you investigate the browser storage (cookies, In this section, we\u2019ll walk through these different tools with more detail, so that you\u2019ll have a better understanding of how to use them to unravel some of the more complicated debugging cases you run into.<\/p>\n Note! This section uses mainly Chrome\u2019s developer tools in examples. It\u2019s possible the actual actions are (slightly) different in other browsers.<\/p>\n<\/blockquote>\n The element inspector<\/strong> lets you analyze the DOM (Document Object Model) of the page.<\/p>\n When the browser loads the HTML source it retrieves from the site\u2019s web server, it renders it into a dynamic tree model, accessible via JavaScript. This dynamic representation is the DOM.<\/p>\n Whenever an analytics snippet or a tag manager interacts with the page, such as by loading a third-party JavaScript library or adding a click listener somewhere, they modify the DOM.<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n Thus, if you have problems with your implementation, it\u2019s useful to search through the element inspector to find what the issue could be.<\/p>\n The element inspector is also extremely useful when you\u2019re building triggers<\/strong> or variables<\/strong> in your tag management system with the purpose of scraping some information from the page or adding listeners to and injecting elements into the document.<\/p>\n Here are a couple of cool tricks you can try in the element inspector.<\/p>\n Hit CMD + F<\/strong> \/ CTRL + F<\/strong> to open a search bar. You can then search for a string<\/strong> (e.g. text content) or a CSS selector<\/a> to have the inspector locate a specific element.<\/p>\n For example, to search for all elements with the class name If you\u2019re unsure whether Google Tag Manager actually added the Google Analytics 4 script on the page, for exampled, you could search for You can also do the reverse. If you click the little element selector icon (this differs from browser to browser) in the developer tools panel, you can actually select an element on the page to reveal it in the element inspector.<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n In addition to pinpointing it in the element inspector, the tool also displays some useful information about the element in question.<\/p>\n When you select an element in the inspector with the right mouse button, you\u2019ll see a context menu.<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n You can do a lot<\/strong> of cool stuff with this, such as:<\/p>\n Add \/ edit<\/strong> the element\u2019s attributes. I use this a lot to change link URLs to something else, when I want to test a specific outgoing link, for example.<\/p>\n<\/li>\n Edit \/ delete<\/strong> the element itself. Sometimes it\u2019s useful to just delete an element entirely (e.g. an overlay that hides the page underneath). And sometimes you\u2019ll want to edit the entire HTML structure of an element when you want to add new contents to it for testing a click listener, for example.<\/p>\n<\/li>\n Copy selector<\/strong>, as this lets you copy a CSS selector<\/strong> path to the element itself. Extremely useful when configuring triggers in Google Tag Manager, for example. Just note that the CSS selector path is usually needlessly complex, and you can trim it down to be more generic in order to avoid subtle changes in the DOM from breaking your triggers.<\/p>\n<\/li>\n Break on\u2026<\/strong> lets you pause the page whenever the element or its subtree (nested elements) changes<\/em>. This is pretty useful when you want to inspect what happens when an element becomes visible or when an element\u2019s content is dynamically changed (think form validation error messages, for example).<\/p>\n<\/li>\n<\/ul>\n When you\u2019ve selected the element, you can change the associated styles<\/strong> with the developer tools.<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n This might have marginal use for analytics debugging, but occasionally you might use it to make an element visible or move it around when you can\u2019t find it in the actual page.<\/p>\n Often you\u2019ll find that your tag management system and\/or your analytics debugger extension claims that your hit has fired<\/strong>, but no data is collected into the vendor endpoint.<\/p>\n At this point, you need to open the Network<\/strong> tab in the developer tools, as this lists all the HTTP requests<\/strong> sent from the browser.<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n The network debugger is the ultimate truth<\/strong>. If a request doesn\u2019t appear here, then the browser has not sent it. So if your tag management system says that a GA4 hit has fired<\/strong> but you see no evidence of a It might be useful to check the Preserve log<\/strong> option, as this doesn\u2019t clear the log of requests between page loads. This is very useful when you want to debug what happened on a previous page.<\/p>\n For a more detailed walkthrough of the network debugger, check out this excellent resource<\/a>.<\/p>\n Here are some of the things you can do with the network debugger.<\/p>\n By typing something into the filter field, you can show only the HTTP requests that match the filter.<\/p>\n The filter searches through the request URL and the request body.<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n When you select a request in the debugger, a small overlay opens with various tabs.<\/p>\n Headers<\/strong> includes all the HTTP headers of the request<\/em> and the response<\/em>. This is useful for debugging things like cookies, referrer values, and where the request was actually sent.<\/p>\n<\/li>\n Payload<\/strong> contains the query parameters<\/strong> and the request body<\/strong>. Extremely important when analyzing what was actually sent to the analytics platform.<\/p>\n<\/li>\n Response<\/strong> shows what the web server actually responded with. This is often empty or nonsensical with pixel requests, but it\u2019s useful when analyzing API responses<\/strong> or JavaScript files.<\/p>\n<\/li>\n Cookies<\/strong> lists all the cookies that were sent with the request<\/strong> and set in the response<\/strong>.<\/p>\n<\/li>\n<\/ul>\n You can right-click any request in the list and choose Block request URL<\/strong> or Block request domain<\/strong> to prevent the page from being able to send the request until the block is removed.<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n When the resource URL (or domain) is blocked, then any requests that match the URL (or domain) will be blocked in future requests.<\/p>\n This is extremely<\/strong> useful when you want to figure out which JavaScript resource is causing conflicts on the page. By blocking each one-by-one and then reloading the page, you\u2019ll be able to pinpoint the file that causes issues.<\/p>\n To unblock<\/strong> a resource, press the ESC<\/strong> key to toggle the Drawer<\/strong>, select the Network request blocking<\/strong> tab and uncheck the box next to the request (or delete it from the respective buttons). If you don\u2019t see the tab, you can select it by clicking the Drawer menu (the three vertical dots) in the top-left corner of the Drawer.<\/p>\n You can also right-click the blocked resource in the network debugger and choose Unblock\u2026<\/strong>.<\/p>\n<\/blockquote>\n If you want to test how the page loads like on a slower connection (might be useful every now and then), you can choose a throttling speed<\/strong> from the network tools.<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n Remember to switch back to No throttling<\/strong> when done, though, or you\u2019ll have to continue suffering with slowly loading pages.<\/p>\n In the Initiator<\/strong> column, you can see the resource or process that caused the redirect to fire.<\/p>\n By clicking the resource in the column, it will jump to the relevant part of the developer tools to show what process initiated the request.<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n If the initiator is If the initiator is a JavaScript file or a CSS file, for example, then developer tools will open the Sources<\/strong> tab with the relevant part of the source file code selected. This might not be very useful in itself, but you can use the Sources panel to add a breakpoint to the injection moment in order to replay through the stack after a page reload (more on this below in the Sources section<\/a>).<\/p>\n The JavaScript console lets you execute any<\/strong> JavaScript commands in the context of the current page<\/strong>.<\/p>\n The context of the page is the DOM, and you can use DOM methods<\/a> to interact with page elements.<\/p>\n Here are some use cases for the JavaScript console.<\/p>\n Many tools output debug messages to the JavaScript console, so the first course of action<\/strong> whenever you run into trouble is to open the JavaScript console to see if there are any relevant errors shown.<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n It\u2019s a good idea to add some In browser JavaScript, global variables are stored in the If you want to check whether a global <\/p>\n <\/a><\/p>\n<\/div>\n You can also set<\/em> new global variables simply by initializing them in the This is a cool trick. Whenever any JavaScript that runs on the page uses the If you want to try this out, you can add a click listener on the page with The JavaScript console is initially bound to the context of the top frame (the URL the user is currently navigating).<\/p>\n If the page embeds other content in iframes, you can use the frame selector in the console to change context to the iframe.<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n This is, of course, particularly useful when debugging embedded content such as third-party shopping carts or widgets.<\/p>\n Note that the frame selector is confusingly in different parts of the developer tools across different browsers. The screenshot above is from Chrome<\/strong> (and it\u2019s the same on Edge<\/strong>). With Firefox<\/a> the context picker is in the top-right corner of the developer tools, and with Safari it\u2019s in the bottom-right corner of the developer console.<\/p>\n<\/blockquote>\n The sources<\/strong> panel can be game-changing but it can also be very overwhelming to use.<\/p>\n The panel lists all of the subresources<\/strong> (images, scripts, frames, etc.) loaded on the current page.<\/p>\n The list is sorted by URL, starting with the origin<\/em> and then drilling own to paths and files.<\/p>\n
\n X<\/span><\/p>\n
\n The Simmer Newsletter<\/strong>\n <\/p>\n![\"Shortcuts](\"https:\/\/www.simoahava.com\/images\/2022\/01\/developer-tools-keyboard-shortcuts.jpg#ZgotmplZ\")
<\/p>\n\n
\n
localStorage<\/code>, etc.) utilized on the current page (or embedded frames). Instrumental for understanding why some trackers might not be able to persist data consistently.<\/p>\n<\/li>\n<\/ul>\n\n
Element inspector<\/h3>\n
![\"Element](\"https:\/\/www.simoahava.com\/images\/2022\/01\/element-inspector.jpg#ZgotmplZ\")
<\/p>\nSearch for a specific element in the inspector<\/h4>\n
simmer<\/code>, you can type .simmer<\/code> into the search bar and the inspector will return all the matches.<\/p>\ngtag\/js<\/code> to find all elements that have that particular string somewhere<\/em> in them. Since GA4 is loaded from the \/gtag\/js?id=G-...<\/code> URL, the inspector should find the GA4 script element, unless it\u2019s actually missing.<\/p>\nSelect a specific element on the page itself<\/h4>\n
![\"Element](\"https:\/\/www.simoahava.com\/images\/2022\/01\/element-selector.jpg#ZgotmplZ\")
<\/p>\n![\"Element](\"https:\/\/www.simoahava.com\/images\/2022\/01\/element-context-menu.jpg#ZgotmplZ\")
<\/p>\n\n
Change element styles<\/h4>\n
![\"Change](\"https:\/\/www.simoahava.com\/images\/2022\/01\/change-element-style.jpg#ZgotmplZ\")
<\/p>\nNetwork debugger<\/h3>\n
![\"Network](\"https:\/\/www.simoahava.com\/images\/2022\/01\/network-debugger.jpg#ZgotmplZ\")
<\/p>\ncollect?v=2<\/code> request in the network debugger, then the hit has not<\/strong> been sent.<\/p>\nFilter for specific requests<\/h4>\n
![\"Network](\"https:\/\/www.simoahava.com\/images\/2022\/01\/network-filter.jpg#ZgotmplZ\")
<\/p>\n\n
Block a request from future loads<\/h4>\n
![\"Block](\"https:\/\/www.simoahava.com\/images\/2022\/01\/block-url.jpg#ZgotmplZ\")
<\/p>\n\n
Manually throttle the page speed<\/h4>\n
![\"Throttling](\"https:\/\/www.simoahava.com\/images\/2022\/01\/throttling.jpg#ZgotmplZ\")
<\/p>\nPinpoint the initiator of the request<\/h4>\n
![\"Network](\"https:\/\/www.simoahava.com\/images\/2022\/01\/network-initiator.jpg#ZgotmplZ\")
<\/p>\n(index)<\/code>, it means the request originated from a resource injected into the DOM, which means clicking it will open the element inspector<\/strong> with the element selected.<\/p>\nJavaScript console<\/h3>\n
Inspect logs<\/h4>\n
![\"Console](\"https:\/\/www.simoahava.com\/images\/2022\/01\/console-log.jpg#ZgotmplZ\")
<\/p>\nconsole.log(msg)<\/code> calls in whatever code you add yourself via a tag management system, for example. That way you can debug the log output in the JavaScript console \u2013 often this is the easiest way to debug code execution.<\/p>\nCheck the value of global variables<\/h4>\n
window<\/code> object.<\/p>\ndataLayer<\/code> array exists, you can simply type window.dataLayer<\/code> and press enter. If the console shows undefined<\/code>, it means that dataLayer<\/code> does not exist in global scope.<\/p>\n![\"Undefined](\"https:\/\/www.simoahava.com\/images\/2022\/01\/undefined-datalayer.jpg#ZgotmplZ\")
<\/p>\nwindow<\/code> object:<\/p>\nwindow<\/span>.myGlobalVariable = \"Hello, I am a global variable.\"<\/span>;\n<\/code><\/pre>\n<\/div>\nAdd an event listener with a breakpoint<\/h4>\n
debugger;<\/code> keyword, the page will pause and you will be diverted to the Sources<\/strong> tab where you can then walk through the stack (more on this below).<\/p>\ndebugger;<\/code> in the callback. Then, when you click anywhere on the page, the execution will pause and you\u2019ll be taken to the Sources tab.<\/p>\nwindow<\/span>.addEventListener('click'<\/span>, () => { debugger<\/span>; })\n<\/code><\/pre>\n<\/div>\nChange the context to an iframe<\/h4>\n
![\"Iframe](\"https:\/\/www.simoahava.com\/images\/2022\/01\/iframe-selector-chrome.jpg#ZgotmplZ\")
<\/p>\n\n
Sources<\/h3>\n
![\"Sources\"\/](\"https:\/\/www.simoahava.com\/images\/2022\/01\/sources.jpg#ZgotmplZ\")
<\/p>\n![\"Pretty-print\"\/](\"https:\/\/www.simoahava.com\/images\/2022\/01\/pretty-print.jpg#ZgotmplZ\")
<\/p>\n![\"Add](\"https:\/\/www.simoahava.com\/images\/2022\/01\/add-breakpoint.jpg#ZgotmplZ\")
<\/p>\n![<\/p>\n](\"https:\/\/www.simoahava.com\/images\/2022\/01\/paused-on-breakpoint.jpg\"){kind=link}