[Digital Analytics](/categories/digital-analytics) October 14, 2026 # GTM debugging: manual methods vs continuous monitoring How to debug Google Tag Manager with Preview Mode, extensions, the Network tab and server-side preview, and when continuous monitoring takes over. ![](/images/65d75b0ae8d69ef95785a5d6_david-pombar.webp) **[David Pombar](/author/david-pombar)** Swiss army knife at Trackingplan 16 min read · 3539 words GTM Preview Mode tells you what a tag would do in your browser, right now. Continuous monitoring tells you what it did for every visitor since the last release. Those are two different questions, and most GTM debugging goes wrong when one tool is asked to answer the other. This guide covers the whole spectrum: Preview Mode, browser extensions, the Network tab, server-side containers, and continuous monitoring. It builds on the work of people who have documented GTM debugging better than anyone, above all Julius Fedorovicius at [Analytics Mania](https://www.analyticsmania.com/post/google-tag-manager-debug-mode/) and [Simo Ahava](https://www.simoahava.com/analytics/new-preview-mode-google-tag-manager/). Where they go deep on one tool, this guide puts the tools side by side and says when to reach for each. ## The short answer Manual debugging is for building and changing an implementation. Continuous monitoring is for keeping it working in production. You need both, at different moments. For the wider picture beyond GTM, from manual audits to scheduled crawlers, see [5 approaches to tracking audits and monitoring, compared](/blog/5-approaches-to-tracking-audits-and-monitoring-compared). | | Point-in-time debugging (Preview Mode, extensions, Network tab) | Continuous monitoring (Trackingplan) | | --- | --- | --- | | Question it answers | Does this tag fire correctly, here, now? | Did anything break, for anyone, since the last release? | | Setup time | None: it’s built into GTM and the browser | One tag, SDK or server-side hook, then it learns from traffic | | Coverage | Your session, your browser, your consent choice | Real traffic across web, apps and server-side | | Unpublished changes | Yes: Preview runs the draft workspace | No: it sees what is live | | Team expertise | GTM, the dataLayer and each vendor’s parameters | Reading an issue and its evidence | | When it runs | When someone opens it | Every hour, without anyone asking | | Best for | Implementation, QA before publishing, reproducing a bug | Production issues, regressions after releases, issues that hit some users only | ## GTM Preview Mode: where every debug session starts Click **Preview** in a workspace and GTM opens Tag Assistant at tagassistant.google.com. You enter the URL, connect, and the site loads the draft container instead of the published one. A badge on the page confirms the connection ([Google’s help page](https://support.google.com/tagmanager/answer/6107056?hl=en) has the steps). As Simo Ahava explains, Preview switches on from any of three signals: the `gtm_debug=x` parameter in the URL, a referrer from Tag Assistant, or the first-party `__TAG_ASSISTANT` cookie. It also keeps its history across reloads and page navigations, so you can follow a checkout from cart to confirmation. What you get, per event in the left-hand stream: - **Tags:** which fired, which didn’t, and the trigger conditions that blocked them. - **Variables:** the value of every GTM variable at that event. - **Data Layer:** the state of the dataLayer after that push. - **Errors:** exceptions thrown by tag templates, with the tag that failed. Analytics Mania’s first rule for the interface saves a lot of confusion: “Always select the event in the event stream first.” A variable read on `Container Loaded` and the same variable read on `purchase` are two different values. Preview also handles collaboration and staging. Share a session from the three-dot menu and someone else can watch it. For staging sites, GTM Environments give you a snippet that always loads a given version, so QA doesn’t depend on someone keeping a Preview tab open. ### Where Preview Mode stops - **It tests one browser.** Yours, with your extensions, your consent choice, and your device. - **“Fired” isn’t “received”.** Analytics Mania’s [debugging tips](https://www.analyticsmania.com/post/google-tag-manager-debugging-tips/) put it plainly: a tag marked as fired doesn’t mean the vendor got the data. An ad blocker, a CSP rule or a wrong measurement ID can stop the request after GTM is done with it. - **It doesn’t cover everything.** Google’s help page says mobile app containers have no debug interface and AMP containers are preview-only. Tags inside iframes need the Tag Assistant extension. - **It only runs while someone is looking.** Close the tab and nothing is checked. ### When Preview Mode won’t connect This is the most asked GTM debugging question there is, and Analytics Mania lists [26 ways to fix it](https://www.analyticsmania.com/post/google-tag-manager-preview-mode-not-working/). The causes that come up most: - The GTM snippet is missing, wrong, or belongs to another container. - An ad blocker, Ghostery, or AdGuard blocks Tag Assistant, or automatic cookie blocking removes `_TAG_ASSISTANT`. - The consent banner blocks GTM itself until someone accepts. - Cloudflare Rocket Loader or another script loader changes how `gtm.js` loads. - A Content Security Policy doesn’t allow Google’s debug scripts. - Safari or Brave block what Preview needs. Simo Ahava has a short tip on [Preview in Safari](https://simoahava.com/gtm-tips/enable-preview-mode-safari-browser). - The site runs an environment snippet while you preview a workspace. Before anything else, try an incognito window with no extensions, in its own window, and in the foreground. That rules out half the list in a minute. ## Browser extensions: Tag Assistant, Omnibug, and Analytics Debugger Extensions fill the gaps Preview leaves. They split into three jobs: helping Preview, decoding hits, and reading the dataLayer. **Tag Assistant (Companion).** Google’s extension isn’t a debugger on its own; it makes Preview better. The debugged site opens in a tab instead of a window, and you can debug iframes and several windows in one session. If Preview misbehaves on a site with embedded forms or a cross-domain checkout, install it first. Our [guide to the Tag Assistant extension](/blog/tag-assistant-chrome-extension) covers it step by step, and [GA4 and Google Tag Assistant](/guides/ga4-google-tag-assistant-optimization-guide) covers its use with GA4. **Omnibug.** An open-source extension (MIT licence) for Chrome, Firefox, and Edge that decodes outgoing hits from dozens of marketing tags: GA4, Adobe Analytics, Meta Pixel, and more, in one panel. You can filter by account, add notes, and export to CSV. It shows requests, not GTM logic: it won’t tell you why a trigger didn’t fire. Trackingplan maintains a [fork of Omnibug](/docs/trackingplan-omnibug-extension) that validates each request against your tracking plan, with full credit to the original project. For installing it, the panel and its filters, see our [guide to the Omnibug Chrome extension](/blog/omnibug-chrome-extension). **Analytics Debugger.** David Vallejo’s free extension runs as a DevTools panel and puts dataLayer pushes and hits in one ordered timeline: GA4 (including hits sent to a server container), Google Ads, Floodlight, Adobe, and others. It’s the closest thing to reading the dataLayer and the network at the same time. **dataLayer extensions.** Adswerve’s [dataLayer Inspector+](https://adswerve.com/resources/adswerve-data-layer-inspector-2) prints every push and hit to the console and separates GA4 hits from server-side ones. Datalayer Checker shows pushes as a table or JSON and lets you save snapshots to compare. **Vendor helpers.** Meta’s Pixel Helper is now Meta Ads Data Advisor. It shows Pixel events and their parameters per page, but Meta itself points to Test Events in Events Manager for a thorough check. [Meta Pixel and CAPI debugging tools compared](/blog/meta-pixel-capi-debugging-tools) goes through Meta's side in detail. ## Inspecting the dataLayer from the console Most GTM bugs are dataLayer bugs: a key renamed, a value pushed after the event that needs it, an `ecommerce` object left over from the previous push. The console answers those faster than any interface. To prevent them in the first place, see [data layer best practices](/guides/data-layer-best-practices). See every push so far, in order: ```js window.dataLayer.forEach((entry, i) => console.log(i, entry.event || '(no event)', entry)); ``` Find the last push of one event: ```js window.dataLayer.filter((e) => e.event === 'purchase').at(-1); ``` Read a value the way GTM sees it, with the merged dataLayer model (replace the container ID with yours): ```js google_tag_manager['GTM-XXXXXX'].dataLayer.get('ecommerce.transaction_id'); ``` Log every new push as it happens. Run it after the page has loaded, then click through the flow: ```js (() => { const dl = window.dataLayer; const push = dl.push.bind(dl); dl.push = (...args) => { console.log('[dataLayer]', ...args); return push(...args); }; })(); ``` If `transaction_id` is in the dataLayer but empty in the tag, the tag almost certainly fires on an event that comes before the push. That one pattern explains a large share of “the tag fired but the value is missing” questions. ## Inspecting network requests The Network tab is where you stop trusting GTM’s word and read what actually left the browser. It’s vendor-agnostic, built into every browser, and the only place where “fired” turns into “sent”. In Chrome DevTools: 1. Open the **Network** tab and tick ** Preserve log**, so requests survive page navigations. 2. Filter by `collect` for GA4, `facebook.com/tr` for Meta, or your server container’s domain. 3. Open a request and read the **Payload** tab: the query string and the body, decoded. 4. Check the **Status**. A request that never appears, or comes back blocked, is your answer. ![The Payload tab in Chrome DevTools, with a request’s query string parameters decoded.](/images/gtm-debugging-guide-devtools-payload.webp) The Payload tab in Chrome DevTools, with a request’s query string parameters decoded. *Screenshot: [Chrome for Developers](https://developer.chrome.com/docs/devtools/network/reference), [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).* A GA4 hit packs the event and its parameters into short keys: `en` is the event name, `ep.` prefixes a text parameter, `epn.` a numeric one, `tid` is the measurement ID, and `gcs` carries the Consent Mode state. To read one quickly, copy the request URL and decode it in the console: ```js const hit = new URL('https://region1.google-analytics.com/g/collect?v=2&tid=G-XXXXXXX&en=purchase&ep.transaction_id=T-1043&epn.value=89.90&cu=EUR'); console.table(Object.fromEntries(hit.searchParams)); ``` GA4 often batches several events in one request: the first sits in the URL and the rest in the body, one per line. If an event seems missing from the URL, read the body before you conclude it wasn’t sent. ![Anatomy of one hit: a GA4 purchase and everything Trackingplan captures around it.](/images/same-models-different-answers-02-anatomy-of-a-hit.webp) Anatomy of one hit: a GA4 purchase and everything Trackingplan captures around it. For native apps there is no Network tab. Proxies like Charles Proxy, Proxyman, or HTTP Toolkit sit between the device and the internet and show the Firebase and SDK requests an app sends. They need a certificate on the device and some patience, and they still show only the session in front of you. ## Debugging server-side containers A server container changes where the bugs hide. The browser sends one request to your tagging server; the server decides what reaches GA4, Meta CAPI, or anyone else. Debugging it means looking at both ends. If you're still setting one up, start with [server-side tagging with GTM and GA4](/guides/google-tag-manager-server-side-setup). Stape’s documentation describes the order that works: open the **server container’s Preview first**, then the web container’s Preview in another tab, and load the site ([Stape: debugging with Preview Mode](https://stape.io/helpdesk/documentation/preview-debugging-web-server-gtm-containers)). In the server Preview, each incoming request shows: - **Request:** the client that claimed it, the incoming request, and the outgoing HTTP requests to vendors with their responses. - **Tags, Variables, Event Data, and Console:** what the server built from the request, and the errors from fired tags ([Google’s server-side debug docs](https://developers.google.com/tag-platform/tag-manager/server-side/debug)). ![Server-side GTM Preview: incoming requests on the left, and the Request tab showing the client that claimed a GA4 hit.](/images/gtm-debugging-guide-sgtm-preview.webp) Server-side GTM Preview: incoming requests on the left, and the Request tab showing the client that claimed a GA4 hit. *Screenshot: [Google for Developers](https://developers.google.com/tag-platform/tag-manager/server-side/debug), [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).* Three things trip people up, and Stape’s checks catch them: - **No client claimed the request.** Check the request path for a typo or a mismatch with the client’s settings. - **Event Data is empty.** The wrong client claimed the hit. - **The outgoing response isn’t 2xx.** Read the response body: the vendor usually says what’s wrong. Simo Ahava points out a limit worth remembering: “the Preview tab only shows hits that originate from your browser” ([server-side tagging guide](https://www.simoahava.com/analytics/server-side-tagging-google-tag-manager/)). Webhooks, CRMs, and backends don’t come from your browser. To see them in Preview, they need the `X-Gtm-Server-Preview` header, whose value you copy from **Send requests manually** in the Preview menu ([Simo’s tip](https://www.simoahava.com/gtmtips/preview-server-side-google-tag-manager/)). The value changes with every new Preview session, so it can’t live in your app: ```bash curl -X POST "https://sgtm.example.com/data" \ -H "Content-Type: application/json" \ -H "X-Gtm-Server-Preview: " \ -d '{"event_name":"purchase","transaction_id":"T-1043","value":89.90}' ``` If you host on Stape, two features fill the gap. Its [Preview Header](https://stape.io/solutions/sgtm-preview-header) stores the current header value and routes test requests into your open Preview session. [Stape Logs](https://stape.io/blog/guide-to-debugging-and-monitoring-server-side-tracking-configuration) record incoming and, when enabled, outgoing requests: 3 days on Pro, 10 days on Business and up, with alert rules on the higher plans. One more detail from Analytics Mania’s [DebugView guide](https://www.analyticsmania.com/post/debugview-in-google-analytics-4/): GA4 events sent from a server container need `debug_mode` set by hand to appear in DebugView. ## Where point-in-time debugging stops Every tool above shares one property: it checks the session in front of you. That is exactly what you need while building. It is also why tracking breaks in production without anyone noticing. A developer ships a release on Tuesday and renames a CSS class a trigger relied on. A CMP update changes the default consent state in one market. A GTM release moves a tag to the page view, before the dataLayer push it reads. None of these shows up in a Preview session you ran last week, and none of them sends an error to anyone. That’s the gap teams describe before they monitor. “Before Trackingplan, issues could easily go unnoticed for two or three weeks,” says Rasmus Frølund of [Fact](/customer-stories/how-fact-keeps-analytics-accurate-for-a-growing-client-portfolio). Manual checks don’t scale either: Pablo Urueña of Semmántica, working on an e-commerce site, puts it as “With e-commerce clients that have thousands of product-category URLs, going through them one by one is impossible.” ## Continuous monitoring: debugging that runs without you [Continuous monitoring](/landings/monitoring) flips the model. Instead of opening a debugger to test a hypothesis, you get told when something changes, with the evidence attached. Trackingplan installs with one tag, SDK, or server-side hook and starts observing real traffic. It learns a baseline per hour of day and day of week, then compares every hour against it, per event, per property, and per platform. What it catches is the list every GTM debugger knows by heart: missing properties, dead tags, duplicate fires, broken triggers, naming inconsistencies, and vendors firing before consent. Two things make it a debugging tool, not only an alert system: - **It reads your GTM releases.** Trackingplan finds your GTM containers in your own traffic and captures every published release. It decodes each one into tags, triggers, variables, consent settings, and the dataLayer paths they read, with their change history. When an event breaks, the first question, “what changed?”, already has an answer. - **It checks live when it needs to.** Click ** Analyze** on an issue and the agent narrows it down in the hits, finds the tag, trigger, and variable that send the event, and checks what changed in the container. When a live check could settle it, it reproduces the flow in a real browser, with the same consent state the affected traffic had. ![An issue traced back to the GTM release that caused it, confirmed live, with the fix.](/images/same-models-different-answers-06-issue-debugged.webp) An issue traced back to the GTM release that caused it, confirmed live, with the fix. Teams that monitor describe the difference in hours. Rethink’s team hears about errors “Sometimes even just a couple of hours after a release.” MicroAnalytics gets a notice “within 24 hours at most.” Semmántica reports a [50% reduction in debugging time](/customer-stories/how-semmantica-simplified-analytics-management-with-trackingplan). Trackingplan isn’t the only way to monitor, and the others are worth knowing. [ObservePoint](/alternative-to-observepoint), DataTrue, and QA2L run scheduled audits and scripted journeys in a real browser. Synthetic tests have one advantage: they can check a page before any visitor reaches it, which real-traffic monitoring can’t. Their limit is that they only check what you defined, and journeys built on selectors break when the site changes. Stape’s alert rules watch the server container, but only the server container. Real-traffic monitoring sees what actual users, devices, and consent states produce, including the paths nobody scripted. ## GTM debugging tools comparison table Prices and features as published by each vendor in October 2026: [Charles Proxy](https://www.charlesproxy.com/buy/), [Stape](https://stape.io/pricing), [DataTrue](https://datatrue.com/pricing/), and [Trackingplan](/pricing). ObservePoint quotes on request; the other tools are free. | Tool | Type | What it inspects | Coverage | Mode | Price | Strongest at | | --- | --- | --- | --- | --- | --- | --- | | GTM Preview Mode | Built into GTM | Tags, triggers, variables, dataLayer of the draft container | Web | Point-in-time | Free | Testing unpublished changes and why a trigger didn’t fire | | Tag Assistant (Companion) | Chrome extension | Extends Preview | Web | Point-in-time | Free | Iframes and multi-window sessions | | GA4 DebugView | Built into GA4 | GA4 events as GA4 receives them | Web, apps | Point-in-time | Free | Proving the hit arrived | | Chrome DevTools Network | Built into the browser | Every request, raw | Web | Point-in-time | Free | The raw truth, any vendor | | Omnibug | Extension, open source | Decoded hits from many vendors | Web | Point-in-time | Free | Reading hits from several vendors in one panel | | Analytics Debugger | DevTools extension | dataLayer pushes and hits in one timeline | Web | Point-in-time | Free | dataLayer and network side by side | | dataLayer Inspector+ | Chrome extension | dataLayer pushes and hits in the console | Web | Point-in-time | Free | Console-first debugging, sGTM hits apart | | Datalayer Checker | Chrome extension | dataLayer pushes, snapshots | Web | Point-in-time | Free | Comparing dataLayer states | | Meta Ads Data Advisor | Chrome extension | Meta Pixel events | Web | Point-in-time | Free | Quick Pixel checks | | Charles Proxy / Proxyman | Desktop proxy | Every request from a device | Web, apps | Point-in-time | From $50 per user (Charles) | Native app hits | | sGTM Preview | Built into GTM | Incoming request, client, outgoing vendor requests | Server-side | Point-in-time | Free | Why a server tag failed | | Stape Logs | sGTM hosting feature | Server container requests and responses | Server-side | Retained 3–10 days | From Stape Pro ($17/month billed annually) | Looking back at server traffic | | ObservePoint | SaaS | Scheduled audits and scripted journeys | Web | Scheduled, synthetic | Quote | Auditing many pages, privacy checks | | DataTrue | SaaS | Scheduled audits, journeys, consent tests | Web (apps on top plans) | Scheduled, synthetic | From $16k/year | Consent-state tests in a real browser | | Trackingplan | Agent with monitoring | Every hit, the dataLayer, consent state and GTM releases on real traffic | Web, apps, server-side | Continuous | From $99/month (Starter), with a free trial | Production issues traced to their cause | ## Which debugging approach for your situation? Start at the top and stop at the first yes. ```text Are you building or changing the container, before publishing? ├─ Yes → GTM Preview Mode + Tag Assistant extension; read hits in the Network tab └─ No ↓ Is the problem in a server container, a webhook or a backend request? ├─ Yes → sGTM Preview (server first, then web) + X-Gtm-Server-Preview header; Stape Logs to look back └─ No ↓ Is it a native app? ├─ Yes → Proxy (Charles, Proxyman, HTTP Toolkit) + GA4 DebugView └─ No ↓ Does a tag show as fired, but the vendor shows nothing? ├─ Yes → Network tab, then GA4 DebugView or the vendor’s test events └─ No ↓ Is it already in production, for some users, devices or markets only? ├─ Yes → Continuous monitoring on real traffic └─ No ↓ Do you need to know it broke before someone tells you? └─ Yes → Continuous monitoring, with alerts in the channel that owns the fix ``` Most teams end up using both halves of the tree. They use Preview and extensions every time someone touches the container, and monitoring for the long stretch in between, when nobody is looking. ## Common GTM debugging questions These are the questions that come back again and again in GTM community forums. ### Why is GTM Preview Mode stuck on “connecting”? Usually something blocks Tag Assistant: an ad blocker, a privacy extension, a consent banner holding GTM back, or a CSP. Try an incognito window with no extensions, keep the debugged tab in its own window in the foreground, and check the URL matches the site exactly, `https` and `www` included. Remove the old Tag Assistant Legacy extension if it’s still installed. ### Why do my tags fire in Preview but not on the live site? Most often the container was never published: Preview runs the draft. After that, check consent (you accepted, your visitors may not have), ad blockers stopping the request after GTM fires it, a wrong measurement ID, or a hard-coded gtag.js running next to GTM. The Network tab tells you which one. ### Why don’t I see events in GA4 after testing? Use DebugView, not the standard reports, which take time to process. If DebugView is empty too, check the request in the Network tab and the `debug_mode` parameter. Events from a server container need it set by hand. For the GA4 side, see [troubleshooting common issues in GA4](/guides/troubleshooting-common-issues-ga4). ### Can I use Preview Mode on a Shopify checkout? Not inside custom pixels. They run in a sandboxed iframe, so Preview can’t attach to them. Log events from inside the pixel with `console.log`, read the requests in the Network tab, and confirm in GA4 DebugView or a server container’s Preview. ### How do I test GTM before publishing? Preview a workspace on staging, or create a GTM Environment so staging always loads a given version. Keep test hits out of production data with a separate GA4 property or a debug filter, and write version notes when you publish so you can roll back. ### What’s the best way to debug GTM? Work from the inside out. Check the dataLayer first, then the trigger and the tag in Preview, then the request in the Network tab, then what the vendor received. Once it works, monitor it, because the next release will change something. Manual debugging is how an implementation gets built. Continuous monitoring is how it stays true after the people who built it have moved on to the next release. ## References - Analytics Mania, [A Guide to Google Tag Manager Preview Mode](https://www.analyticsmania.com/post/google-tag-manager-debug-mode/) - Analytics Mania, [Google Tag Manager Preview Mode Not Working? 26 Ways To Fix It](https://www.analyticsmania.com/post/google-tag-manager-preview-mode-not-working/) - Analytics Mania, [28 Google Tag Manager Debugging and Testing Tips](https://www.analyticsmania.com/post/google-tag-manager-debugging-tips/) - Analytics Mania, [A Guide to DebugView in Google Analytics 4](https://www.analyticsmania.com/post/debugview-in-google-analytics-4/) - Simo Ahava, [Tag Assistant Preview Mode In Google Tag Manager](https://www.simoahava.com/analytics/new-preview-mode-google-tag-manager/) - Simo Ahava, [Server-side Tagging In Google Tag Manager](https://www.simoahava.com/analytics/server-side-tagging-google-tag-manager/) - Simo Ahava, [Preview Requests In Server-side Google Tag Manager](https://www.simoahava.com/gtmtips/preview-server-side-google-tag-manager/) - Stape, [How to debug sGTM configuration using Preview Mode](https://stape.io/helpdesk/documentation/preview-debugging-web-server-gtm-containers) - Stape, [Guide to debugging and monitoring server-side tracking configuration](https://stape.io/blog/guide-to-debugging-and-monitoring-server-side-tracking-configuration) - Google, [Preview and debug containers](https://support.google.com/tagmanager/answer/6107056?hl=en) - Google, [Preview and debug server containers](https://developers.google.com/tag-platform/tag-manager/server-side/debug) - Google, [Troubleshoot with Tag Assistant](https://support.google.com/tagassistant/answer/10039345?hl=en) On this page 1. [*01*The short answer](#the-short-answer) 2. [*02*GTM Preview Mode: where every debug session starts](#gtm-preview-mode-where-every-debug-session-starts) 3. [*03*Browser extensions: Tag Assistant, Omnibug, and Analytics Debugger](#browser-extensions-tag-assistant-omnibug-and-analytics-debugger) 4. [*04*Inspecting the dataLayer from the console](#inspecting-the-datalayer-from-the-console) 5. [*05*Inspecting network requests](#inspecting-network-requests) 6. [*06*Debugging server-side containers](#debugging-server-side-containers) 7. [*07*Where point-in-time debugging stops](#where-point-in-time-debugging-stops) 8. [*08*Continuous monitoring: debugging that runs without you](#continuous-monitoring-debugging-that-runs-without-you) 9. [*09*GTM debugging tools comparison table](#gtm-debugging-tools-comparison-table) 10. [*10*Which debugging approach for your situation?](#which-debugging-approach-for-your-situation) 11. [*11*Common GTM debugging questions](#common-gtm-debugging-questions) 12. [*12*References](#references) **Stop babysitting tags** Trackingplan audits your real user data around the clock and flags issues before they cost you. [Start free trial →](https://app.trackingplan.com/signup) ![](/images/65d75b0ae8d69ef95785a5d6_david-pombar.webp) **David Pombar** Swiss army knife at Trackingplan Read more from David, a Senior Product Strategist with 18+ years in digital product development and an atypical error detection knack. Share Copy link [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.trackingplan.com%2Fblog%2Fgtm-debugging-guide) [X](https://twitter.com/intent/tweet?url=https%3A%2F%2Fwww.trackingplan.com%2Fblog%2Fgtm-debugging-guide&text=GTM%20debugging%3A%20manual%20methods%20vs%20continuous%20monitoring) Read next [All Blog →](/blog) - [ 11 minDigital AnalyticsOctober 9, 2026 ### Meta Pixel and CAPI debugging tools compared Data Advisor, GTM Preview, DevTools, Test Events, Diagnostics, server logs, and Trackingplan: what each one proves when you debug Meta Pixel and CAPI. by **Mariona Martí**](/blog/meta-pixel-capi-debugging-tools) - [ 13 minDigital AnalyticsAugust 23, 2026 ### Rate of Sale Explained: Formulas, Benchmarks, and Analytics Master rate of sale calculations, benchmarks, and reporting. Learn how to use ROS for smarter inventory decisions and track it reliably in your analytics stack. by **David Pombar**](/blog/rate-of-sale) - [ 13 minDigital AnalyticsAugust 22, 2026 ### Event Taxonomy Design: A Practical Framework Build a scalable event taxonomy with proven naming conventions, property schemas, and governance workflows that keep analytics data clean across teams. by **David Pombar**](/blog/event-taxonomy) Trackingplan ## See everything. Miss nothing. Your implementations audited around the clock with real-time, real-user data. Real-time alerts about errors or changes in your data, campaigns, pixels, privacy and consent. Let AI flag issues before they cost you. [Start free trial →](https://app.trackingplan.com/signup) [Book a demo](/demo)