Missing Google Tag Manager settings in Complianz can be intentional when another analytics integration owns the setup. Check the active integration before reinstalling the plugin or adding a second GTM snippet. The important question is which component installs the container, not how to make one field appear.
Make an ownership inventory
List the components involved in measurement: Complianz, Site Kit, GTM4WP, an analytics plugin, theme snippets and any CDN-injected tag. Record their roles separately. One plugin can supply ecommerce data while another installs GTM; disabling the entire plugin may remove useful events even if it eliminates a duplicate script.
| Responsibility |
Record one deliberate owner |
| Install the GTM container |
Plugin or approved theme integration |
| Establish consent defaults |
CMP integration and trigger |
| Send consent updates |
Visitor-choice integration |
| Populate ecommerce events |
Store integration, distinct from container installation |
Use the page's public source and Tag Assistant to compare configured container IDs with the actual installation. A field in an admin screen is not evidence that the corresponding script is active on the storefront.
Choose a supported setup before changing switches
Complianz's Consent Mode configuration guide explains that integrations such as GTM4WP or MonsterInsights can hide wizard options. Its current GTM setup guide describes a Complianz-managed approach in which GTM4WP's container installation is off while Complianz installs GTM.
Those are configuration-specific instructions, not a reason to turn off every integration on a working site. First decide whether you are retaining the existing supported integration or deliberately migrating ownership. Export the relevant settings and GTM workspace before altering the setup on staging.
For a migration, document the old installer, new installer and the exact point at which the old snippet stops loading. Keep the ecommerce data producer if the chosen architecture still requires it. Avoid editing production snippets while simultaneously replacing consent triggers, because that makes missing and duplicate events hard to explain.
Before change: Export current settings. Migration: Retire the previous installer. Store events: Keep the needed data producer. Visitor choice: Test all approved scenarios. Explanatory checklist, not a customer test result.
Verify the visitor experience, not just the restored field
Open a fresh browser profile and test no choice, rejection, acceptance and later withdrawal. Observe consent state before the relevant tags evaluate. Repeat a synthetic form submission and, for a store, one sandbox purchase. Confirm the intended event count and destination under each approved consent scenario.
Do not change a site's approved privacy behavior just to make an analytics request appear. Basic and advanced consent implementations have different expected network behavior. Document which model the business has approved rather than treating every blocked request as a defect.
If the field appears but Google tags run twice, revisit the ownership inventory. If the container loads once but a form event never reaches it, the WordPress Consent Mode and form tracking guide covers the next diagnostic layer.
Keep a small handoff record
Save the final installer, container ID, CMP version, data producer and test outcomes without visitor identifiers. A future developer should be able to see why GTM4WP is active but not injecting its container, if that is the chosen setup. HandL WP can untangle conflicting tracking integrations without treating the banner, container and ecommerce payload as one interchangeable component.
References reviewed October 11, 2026. Examples are explanatory, not customer test results.