Explanation: iubenda's own troubleshooting documentation identifies this as a critical configuration error: when the iubenda Privacy Controls and Cookie Solution script is embedded after Google Analytics or Google Tag Manager in the HTML, Google's scripts initialize first. This means GTM receives a "granted" default consent state before iubenda has had the opportunity to set it correctly — a direct GDPR violation for EU visitors, who must not be tracked by default. The iubenda WordPress plugin handles this automatically, but for manual or custom integrations, the placement order is entirely the developer's responsibility and is frequently wrong.
Business/analytics impact: EU visitor data collected during this pre-consent window is legally invalid and analytically unreliable. Google Ads conversion modeling becomes skewed, GA4 audience segments include users who never consented, and the business carries regulatory exposure it may not discover until a supervisory authority investigation or a third-party compliance audit.
Explanation: iubenda's Google Consent Mode troubleshooting guide explicitly warns about a scenario common on Shopify stores and WordPress sites with multiple plugins: when more than one CMP or consent-related plugin is active simultaneously, multiple default consent signals are sent to GTM, creating incompatibility. This happens when Google Analytics or Google Ads plugins independently configure Consent Mode signals alongside iubenda, or when a developer installs a Simo Ahava-style Consent Mode GTM template on top of iubenda's own template. The result is a race condition where GTM receives contradictory instructions about what consent state to apply.
Business/analytics impact: Conflicting consent signals produce unreliable analytics and advertising data. GA4 events may be attributed to the wrong consent state, remarketing audiences are built on incorrect data signals, and Google Ads Consent Mode modeling produces misleading conversion estimates. Resolving the conflict requires identifying all sources of consent signals — a task that is extremely difficult to do manually on complex tag stacks.
Explanation: A documented iubenda bug pattern occurs when the Privacy Controls and Cookie Solution is configured with enableGdpr: false — typically done unintentionally when a developer wants to support US privacy laws but inadvertently disables GDPR enforcement. In this state, iubenda applies US-law defaults to all visitors, meaning Consent Mode parameters are set to "granted" before the user makes any choice. EU visitors are then tracked as if they were US visitors operating under an opt-out model, rather than the opt-in model required by GDPR. The iubenda Site Scanner can detect this, but only if it's actively monitored.
Business/analytics impact: This is a high-severity compliance failure. EU visitors are tracked without valid consent, exposing the business to enforcement action under GDPR Article 5 (data minimization) and Article 7 (conditions for consent). At the same time, analytics teams are working with data that over-represents EU user behavior, invalidating cohort analyses, funnel metrics, and marketing attribution reports.
Explanation: This is a real-world issue documented in iubenda's GitHub repository: when a custom GTM event fires before iubenda has finished evaluating and publishing the user's consent state — even with the iubenda tag triggered on "Consent Initialization - All Pages" — consent-dependent tags may execute prematurely. This happens because iubenda sets its final consent state at a later stage of the GTM lifecycle than some custom event triggers expect, particularly in complex containers with many firing rules. The result is a timing gap that allows tags to fire without a confirmed consent decision.
Business/analytics impact: Timing-related consent failures are particularly difficult to detect because they appear in normal analytics data — events fire, conversions are recorded, and nothing looks broken until you inspect the GTM debug timeline carefully. This means weeks or months of analytics data may contain events that were collected before consent was properly established.
Explanation: iubenda's auto-blocking feature requires an accurate and up-to-date list of cookies and scripts categorized by purpose (necessary, analytics, marketing, etc.). When new third-party tools are added to a website — a new chat widget, a performance monitoring script, an A/B testing tool — and the iubenda cookie declaration is not updated to include them, those scripts fall outside the auto-blocking logic and fire freely regardless of user consent choices. iubenda's Site Scanner runs periodic checks, but the interval between scans means new scripts can operate unchecked for days or weeks.
Business/analytics impact: Unblocked, uncategorized scripts represent both a compliance gap and a data governance problem. They inject unconsented tracking data into analytics pipelines, create discrepancies between what your privacy policy discloses and what your site actually does, and increase the risk of enforcement action if a supervisory authority or privacy researcher audits your implementation.
Trackingplan observes your actual, live traffic and validates the entire consent chain — from iubenda signal to downstream tag execution. It detects when tracking events precede a valid iubenda consent confirmation, identifies conflicting signals from multiple sources in your GTM container, and flags events that fire for EU visitors before the correct regional defaults have been applied. You get real-world evidence of what's happening in production, not a report of what your configuration says should be happening.
Trackingplan detects any anomaly by analyzing the actual consent parameters sent for real user sessions, broken down by region. If EU visitors are receiving "granted" defaults before making a choice, or if the iubenda_gtm_consent_event trigger isn't firing in the correct GTM lifecycle sequence, Trackingplan surfaces the specific session data and timing information your development team needs to diagnose and fix the issue — without reproducing a timing-dependent failure in a test environment.
iubenda's Site Scanner runs periodic checks, and only on the pages explicitly configured to crawl. Trackingplan observes all network requests made by real users across your entire site and immediately flags any tracking-related request that doesn't correspond to a known, consented script in your iubenda cookie declaration. When a developer, vendor, or CMS plugin update introduces a new pixel or widget, you know about it the same day — not the next time the scanner runs.
For teams managing iubenda across multiple websites or client properties, Trackingplan's centralized dashboard provides a unified view of consent compliance health across every implementation. Real-time alerts surface consent failures, conflicting signals, and unconsented script activity as they happen — so your team can prioritize and remediate issues across a portfolio without manually auditing each site.
The most likely cause is script load order: if Google Analytics 4 or GTM initializes before iubenda's Privacy Controls and Cookie Solution script has set the correct consent defaults, GA4 will fire during the pre-consent window with a "granted" state. This is iubenda's most documented implementation error and occurs most often in manually configured setups where developers place the iubenda script later in the <head> than GA4 or GTM. A secondary cause is the enableGdpr: false misconfiguration, which causes iubenda to apply US opt-out defaults globally — meaning EU visitors are treated as if they've consented by default. Trackingplan identifies both issues by analyzing the actual sequence of consent signals and GA4 events in your real user sessions, giving you a precise, evidence-based diagnosis rather than requiring you to reproduce the issue manually in a debug session.
Google's Consent Mode warning appears when the four required parameters (analytics_storage, ad_storage, ad_user_data, ad_personalization) aren't being sent in the correct order or aren't covering the right regional scope. Common iubenda-specific causes include: using the legacy iubenda Custom HTML GTM tag instead of the newer iubenda GTM template (which handles Consent Mode v2 natively); having another plugin — such as Google's own Site Kit for WordPress or Shopify's Google & YouTube app — independently setting Consent Mode defaults that conflict with iubenda's signals; or the iubenda tag loading after GTM has already processed its first event. Trackingplan validates which consent parameters your real sessions are actually sending, broken down by region, so you can identify exactly which configuration gap is triggering Google's warning — without having to replay every possible edge case in a test environment.
This is a known iubenda issue on Shopify: Google's or Shopify's native app ecosystem often installs its own Consent Mode configuration alongside iubenda's. When both are active, GTM receives two sets of default consent signals at initialization — one from iubenda and one from the conflicting plugin — causing unpredictable consent state assignment. The fix requires identifying all sources of Consent Mode signals in your GTM container and disabling any that aren't iubenda's own template. Trackingplan detects the presence of multiple, conflicting consent signals in your live sessions and surfaces the conflict immediately, allowing your development team to isolate the source without spending hours in GTM's debug mode trying to reproduce a timing-dependent issue.
iubenda's Site Scanner is a periodic check — not a real-time monitor. New scripts added to your site between scans can fire without consent for days before the scanner catches them, and the scanner only checks pages it's configured to crawl. When a developer or third-party vendor injects a new tracking pixel, analytics tag, or personalization script, it may remain outside your iubenda cookie declaration indefinitely. Trackingplan observes all network requests made by real users on your site and automatically identifies new tracking-related requests that don't correspond to a known, consented script in your stack. You get an immediate alert when something new appears — whether it was added by your team, a vendor, or a CMS plugin update — so you can categorize it in iubenda before it becomes a compliance gap.
iubenda records consent revocations with a timestamp and sends an updated consent signal to GTM via the iubenda_gtm_consent_event DataLayer event. But whether your downstream tools — GA4, Google Ads, Meta Pixel, or CRM webhooks — actually stop firing after receiving that updated signal depends entirely on how your GTM triggers are configured to respond to consent changes. Many GTM setups are built to respond to consent initialization but not to subsequent consent updates, meaning revocations are recorded in iubenda but not honored in the tag stack. Trackingplan monitors event activity in your sessions following consent revocation signals and flags any tracking event that fires after a user has withdrawn consent. This gives you concrete evidence of whether your full analytics and advertising stack is correctly honoring iubenda's revocation signals — and a specific, actionable remediation path when it isn't.
Because life’s too short for tedious data work
Achieve more by getting rid of manual processes and validations
Reduction of measurement error resolution time
Hours saved per month per FTE
Reduction in data errors in reports
Improvement in campaign performance
Efficiency increase in marketing automation
