# Google Tag Manager implementation: common mistakes and how to fix them Canonical URL: https://www.martechdevs.com/blog/google-tag-manager-implementation-mistakes By [Jafrin Akter Alo](https://www.martechdevs.com/authors/jafrin-akter-alo) Data Engineer and Co-founder, martechdevs Published: 2026-02-02 Last updated: 2026-10-13 A reliable Google Tag Manager implementation sends the right event once, with the right parameters and consent state, to the intended destination. Most failures come from installation order, broad triggers, duplicate senders or missing context between browser and server. Fix those mechanics before adding tags, and verify the full path from customer action to destination record before publishing a container version. Includes Google's 8 October 2026 change to visible `gtag.config` events. GTM can show “tag fired” while the destination receives the wrong transaction amount, a duplicate purchase or no usable event at all. Firing confirms that the tag ran under the container's rules. It does not validate the business result. ## What should you check before changing the container? Map every installation path and sender. Check the website source, platform apps, plugins, hardcoded Google tags, GTM containers, custom pixels, server containers and any Google tag gateway configuration. Choose one test action with a known result. Record its expected event name, destination, consent state, transaction or user identifier and required parameters. Follow that action through the browser request, server processing if present and destination diagnostics. [Martechdevs' analytics and tracking service](https://www.martechdevs.com/analytics-tracking) builds and tests that full path. The [server-side tracking guide](https://www.martechdevs.com/blog/server-side-tracking) explains which responsibilities move to a server and which remain in the browser. ## Mistake 1: setting consent defaults after tags have already run Consent defaults must be established before tags use them. A consent banner appearing on the page does not prove that the initial requests used the intended state. With GTM, use a supported consent template and the Consent Initialization trigger for default state. Google's [consent-template guidance](https://developers.google.com/tag-platform/tag-manager/templates/consent-apis) specifies its consent APIs and explains why queued `gtag` consent commands can be processed too late for a subsequent event. Inspect the actual sequence in preview mode. Test a fresh browser profile, a returning visitor with saved choices, a slow connection and a visitor changing their choice. A cached or delayed CMP script can behave differently from the developer's warm browser session. The consent management platform, or CMP, captures and communicates the visitor's choices. Separate its visual banner from the underlying state update. The fix may involve script order, cache exclusions or template configuration rather than changing the banner text. ## Mistake 2: assuming every tag obeys Google's consent state Google tags have documented consent behaviour, but third-party templates and custom HTML require their own review. A container-wide consent setting does not establish that every vendor receives only permitted data. Use Google's [website consent-mode setup guide](https://developers.google.com/tag-platform/security/guides/consent) to distinguish defaults, updates and implementation methods. Then inspect each tag's built-in checks and any additional consent requirements against the intended behaviour. Choose basic or advanced consent mode deliberately. Under an advanced implementation, some Google requests can be expected with denied storage; the test is whether they follow the configured policy and documented behaviour. Under a basic implementation, relevant tags remain blocked until consent. Our [Consent Mode v2 guide](https://www.martechdevs.com/blog/consent-mode-v2) explains the distinction. Test rejection and withdrawal as carefully as acceptance. Replaying an event after a choice changes can create duplicates or send information collected under a different state. Define the behaviour instead of allowing an automatic replay to decide it. ## Mistake 3: wildcard triggers catching new platform events Google's [8 October 2026 GTM release note](https://support.google.com/tagmanager/answer/4620708?hl=en) says configuration commands now appear as visible `gtag.config` events, while GTM container snippets initialise on load independently of those commands. Wildcard custom-event triggers can therefore match an event they previously did not see. Inspect custom-event triggers that match every name or a broad regular expression. If a business-event tag forwards the current event name automatically, it may start forwarding platform configuration events as though they were customer actions. Prefer explicit business-event names where practical. For example, a purchase tag should respond to the deliberately defined purchase event. A general forwarding tag should have a reviewed allowlist and tests for internal or configuration events. Reproduce the observed behaviour in preview mode before editing. Do not blindly block all events with a particular prefix if other parts of the implementation rely on them. Google also directs sites using `gtag` configuration code to use the correct Google tag installation; verify the snippet and ID type instead of patching an unsupported installation with more triggers. ## Mistake 4: loading tags through several paths A platform app, a theme snippet and GTM can each send the same event. A gateway or CDN deployment can add another installation path that the container owner did not inspect. Create a sender inventory for each destination and event. Name the owner of page views, purchases and advertising conversions. Then perform one action and count outgoing requests, including requests routed through a first-party endpoint. A Google tag gateway changes how supported traffic is served or routed; it should be reviewed alongside the website and consent configuration. Verify its active configuration at the CDN or integration layer. Do not infer the complete setup from the GTM workspace alone. Remove duplicate ownership through a controlled change with a saved prior version. Keep the required event and its parameters intact. Deleting the most visible tag can leave the less reliable sender in charge. ## Mistake 5: reporting the server's location as the customer's A backend request has the backend's network context unless the implementation deliberately supplies appropriate customer context. Server-side processing can therefore produce misleading geography when headers or event fields are missing or overwritten. Google's [common event-data reference](https://developers.google.com/tag-platform/tag-manager/server-side/common-event-data) defines `ip_override` as the user's IP address. Separately, its [region-specific tagging guidance](https://developers.google.com/tag-platform/tag-manager/server-side/enable-region-specific-settings) explains location headers for first-party script serving. These are related configuration concerns, but they are not interchangeable fields for every endpoint. Inspect the request at each hop: browser, proxy or load balancer, server container and outgoing destination call. Confirm the meaning of each field with the destination's current specification. Use only customer context you are permitted to process, and preserve any required redaction. Do not trust an arbitrary client-supplied forwarding header as proof of location. Configure the trusted proxy chain and compare a controlled test from a known region with the resulting event. If context is unavailable, document the limitation rather than manufacturing a country value. ## Mistake 6: promising that server-side tracking removes Safari limits Safari's storage rules depend on how data is stored and how the browser classifies the context. Moving a request to a subdomain does not establish unlimited identifier persistence. WebKit's [2020 storage explanation](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/) describes the seven-day expiry cap for script-set cookies and removal of other script-writable storage after seven days of Safari use without site interaction. Its separate [CNAME-cloaking explanation](https://webkit.org/blog/11338/cname-cloaking-and-bounce-tracking-defense/) documents a seven-day cap for cookies set through the covered third-party CNAME response pattern. Those are scoped mechanisms, not a claim that every first-party cookie disappears exactly seven calendar days after creation. Inspect the current browser version, actual response, cookie attributes and infrastructure path. Test the customer journey rather than repeating a blanket “Safari-proof” claim. Use durable authenticated account identifiers where appropriate and permitted, and report the coverage of anonymous measurement honestly. Server-side tracking can improve control and delivery while still operating within browser and consent constraints. ## Mistake 7: expecting a Shopify browser event to cover every order Shopify's [`checkout_completed` documentation](https://shopify.dev/docs/api/web-pixels-api/standard-events/checkout_completed) explains that the event usually fires on the thank-you page, can fire earlier on a post-purchase upsell page and may not fire if the relevant page never loads. A server container cannot forward a browser event it never receives. First identify whether the missing purchase is absent at Shopify's browser event, the outgoing request, the server client or the destination tag. Each failure point needs a different fix. If you add a backend order signal, define the order state it represents, attach a stable transaction identifier and implement the destination's deduplication requirements. Preserve customer consent and supported attribution context. A backend purchase with no browser context can have different reporting and attribution coverage. Reconcile by order ID and status. Test an ordinary checkout, accelerated checkout, upsell path, delayed payment and cancelled or refunded order as relevant to the store. An initial success count is not a substitute for net revenue reconciliation. ## Mistake 8: losing the event between the server client and tag In a server container, a client claims an incoming request and turns it into event data. Tags then process that event under their triggers. A request reaching the host does not establish that the expected client claimed it or the destination tag received the right fields. Google's [server-side data setup guide](https://developers.google.com/tag-platform/tag-manager/server-side/send-data) describes this path and the browser delivery methods that may need appropriate content-security-policy configuration. Inspect client claim, parsed event, transformations, trigger conditions and the outbound response in order. ![Trace the customer action through browser consent, the outgoing request, server client, transformations and destination tag, then compare diagnostics with business records.](https://www.martechdevs.com/assets/blog/google-tag-manager-implementation-mistakes.svg) Watch for transformations that remove a parameter needed downstream. Apply a field policy intentionally and test both permitted and excluded data. Avoid forwarding entire payloads by default simply because a destination accepts arbitrary parameters. ## Mistake 9: maintaining a container through copied tags Repeatedly cloning tags makes future edits inconsistent and consumes container capacity. Google's [container-efficiency guidance](https://support.google.com/tagmanager/answer/2772488?hl=en) recommends optimisation when the size indicator exceeds 70%, including consolidation and removal of unused configuration. Use shared settings and reviewed variables for repeated values. Give tags, triggers and variables descriptive names, owners and purposes. Move substantial static application code into the application's normal delivery process where it can be versioned and tested appropriately. Do not split a container solely to hide its size warning. Separate containers when sites or operating boundaries justify it, then document which one owns each event. Two poorly coordinated containers can make duplication harder to find. ## How should you verify a repaired implementation? Use a test matrix that covers event behaviour and customer state. At minimum, include fresh and returning browsers, accepted and denied consent, relevant devices, a normal completion, a retry and the major checkout or signup variants. For every case, record the expected event count, required parameters, destination and outcome. Save the container version, test evidence and rollback reference together. After release, monitor the real population for changes in event volume and reconciliation gaps. Consider an illustrative store with 100 confirmed eligible test orders. The original browser path produces 92 unique purchase IDs, while duplicate senders produce 11 additional requests. Request count is 103, yet eight orders remain missing. Comparing only totals could make the setup look healthy. After repair, the acceptance test checks unique IDs, amount and currency for the defined eligible population, plus duplicate handling. Some real-world orders can remain unobservable to a particular analytics destination because of permissions or delivery constraints. Separate those explanations from implementation defects instead of forcing the report to equal all orders. ## A GTM implementation checklist - [ ] Inventory every snippet, app, pixel, container and gateway route. - [ ] Assign one owner for each business event and destination. - [ ] Establish consent defaults before the relevant tags execute. - [ ] Test acceptance, rejection, stored choices and withdrawal. - [ ] Review broad triggers for `gtag.config` and other platform events. - [ ] Validate event names, transaction IDs, currency and amounts. - [ ] Inspect browser requests and server client handling separately. - [ ] Verify permitted location and identity context at each hop. - [ ] Reconcile Shopify or billing records with unique destination events. - [ ] Remove unused configuration and consolidate repeated settings. - [ ] Save test evidence, version notes and a rollback plan. - [ ] Monitor production after release with a named owner. For the architecture and operating costs behind a server container, read the [server-side tracking guide](https://www.martechdevs.com/blog/server-side-tracking). At Martechdevs, we implement tracking from the customer action through the records used in reporting and optimisation. Start with the [free martech AI audit](https://www.martechdevs.com/martech-ai-audit), or explore an [AI assistant built around your approved workflows](https://www.martechdevs.com/custom-martech-ai-agent). ## Frequently asked questions ### How long does a GTM implementation take? The scope depends on the website, checkout paths, consent setup and destinations. A simple site with a clear data layer is different from a store with several pixels, an upsell flow and server-side routing. Estimate after inventorying those paths and defining acceptance tests. ### Can we fix everything inside GTM? Some problems need application, CMP, CDN or commerce-platform changes. GTM cannot reliably infer a business event that the application never exposes. Agree on the event contract with developers and test the resulting data layer. ### Why did tags start firing on `gtag.config`? Google's October 2026 change makes configuration commands visible as those events in the data layer. Broad custom-event triggers may match them. Inspect the trigger and replace unintended wildcard behaviour with the required event conditions. ### Does server-side GTM guarantee better attribution? It can improve control over data processing and delivery, but attribution still depends on available identity, consent, event quality and platform rules. Verify the actual improvement against a defined baseline. Do not equate more requests with more accurately attributed customers. ### When should we use an implementation partner? Use one when the work crosses systems or needs specialist testing your team cannot currently own. Ask for the event specification, consent test matrix, reconciliation evidence and handover documentation. Those deliverables make the implementation maintainable after launch. ## Sources 1. Google, [GTM release notes](https://support.google.com/tagmanager/answer/4620708?hl=en), 8 October 2026. 2. Google, [Consent template APIs](https://developers.google.com/tag-platform/tag-manager/templates/consent-apis), checked October 2026. 3. Google, [Website consent-mode setup](https://developers.google.com/tag-platform/security/guides/consent), checked October 2026. 4. Google, [Common server event data](https://developers.google.com/tag-platform/tag-manager/server-side/common-event-data) and [region-specific settings](https://developers.google.com/tag-platform/tag-manager/server-side/enable-region-specific-settings), checked October 2026. 5. WebKit, [Third-party cookie blocking and storage limits](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/), 2020. 6. WebKit, [CNAME-cloaking and bounce-tracking defence](https://webkit.org/blog/11338/cname-cloaking-and-bounce-tracking-defense/), 2020. 7. Shopify, [Checkout completed event](https://shopify.dev/docs/api/web-pixels-api/standard-events/checkout_completed), checked October 2026. 8. Google, [Send data to server-side Tag Manager](https://developers.google.com/tag-platform/tag-manager/server-side/send-data), checked October 2026. 9. Google, [Manage container size and efficiency](https://support.google.com/tagmanager/answer/2772488?hl=en), checked October 2026.