Original Research

A Three-Layer Verification Model for GA4 Under DPDP, and the Real Cost to Remarketing

Consent-gated GA4 doesn't just lose some data, it loses it unevenly, and every brand ends up guessing how much. Here's a real, proposed framework for closing that gap, plus a direct, honest look at what consent decline actually costs D2C brands: remarketing, custom audiences, and a real, structural rise in acquisition cost.

Key Takeaways

  • The real problem: consent-gated GA4 undercounts, and the undercount is uneven. A brand only sees the users who opted in. The users who declined aren't a random 30%, they may skew toward specific channels, devices, or campaigns, which means GA4's shortfall isn't a clean, flat discount you can just add back.
  • The fix: a second, consent-free measurement layer. A self-hosted or subscription instance of Plausible (or a similar cookieless tool) collects no personal data and, in most current interpretations, needs no consent banner, giving a real, independently-measured traffic baseline to compare GA4 against.
  • The extrapolation quotient turns that gap into a real correction factor, applied to GA4's own numbers, not a guess, and Claude, connected through Google's own official GA4 MCP server, can automate the comparison and reporting.
  • Cloudflare or Azure raw logs give a genuine, independent third check, real per-request records regardless of consent, cookies, or JavaScript, though full log export is typically an Enterprise-tier feature, not something every site has by default.
  • The real cost: remarketing disappears for anyone who says no, and historical customer lists likely can't be reused for it either. D2C brands relying on remarketing and uploaded custom audiences should expect both to shrink under DPDP, a real, structural pressure on marketing costs, not a temporary hurdle.

The Real Problem With a Single, Consent-Gated Source

Once GA4 is correctly consent-gated for DPDP compliance, as it has to be, it only measures users who actively opted in. That's not a flat, uniform discount on the real numbers. A brand's actual consent opt-in rate can vary meaningfully by channel, device, campaign, and even time of day, which means GA4's undercount isn't evenly distributed. A brand that simply assumes “GA4 shows me 60% of real traffic, so I'll multiply everything by 1.67” is applying a single number to a genuinely uneven problem.

The real fix isn't to abandon GA4, its ecosystem integration with Google Ads, Search Console, and Performance Max remains genuinely valuable. It's to pair it with a second, independent, consent-free measurement source, and use the real, measured relationship between the two to build a more honest correction.

Layer One: A Consent-Free Secondary Measurement Source

Plausible, run either as a paid, cloud-hosted subscription or self-hosted (the Community Edition is genuinely open-source, AGPLv3, and can run on a small VPS), collects no cookies and no personally identifiable information. Under most current privacy interpretations, that means it doesn't require a consent banner at all, and it measures real, unconsented traffic that consent-gated GA4 structurally cannot see.

Independent, current benchmarks put the real gap between the two tools in a real, meaningful range, commonly cited between 10% and 40% more measured traffic on Plausible than on a comparable, consent-gated GA4 property, with the exact figure depending on the site's actual audience and real consent opt-out behaviour. That gap is not noise. It's the real, measurable shape of what GA4 alone is missing.

Extrapolation Quotient (EQ) = Plausible Sessions ÷ GA4 Consented Sessions

Calculated per real, meaningful segment (channel, device, campaign, or time period), not as one blended, site-wide number, since the underlying consent gap itself isn't uniform across segments.

Layer Two: Turning the Gap Into a Real Correction Factor

The extrapolation quotient is deliberately simple: for a given segment and time period, divide Plausible's real, consent-free session count by GA4's consented session count for that same segment and period. An EQ of 1.3 for a given channel means GA4 is showing roughly 77% of the real traffic that channel is actually receiving, a real, specific, segment-level correction, not a blanket guess.

This is genuinely proposed here as ibs fulcro's own first version of this framework, not an established, externally validated industry standard. It's built on sound logic, using a real, unconsented data source to quantify a consented one's known shortfall, but it deserves real-world testing across different site types and traffic patterns before being treated as a finished methodology. We're publishing it because the underlying problem is real and current, not because the formula is beyond refinement.

A worked example: a paid search channel shows 4,000 sessions in consent-gated GA4 for a given week. Plausible, measuring the same real traffic without a consent gate, shows 5,600 sessions for that channel over the same period. The extrapolation quotient for that channel is 5,600 ÷ 4,000 = 1.4, suggesting GA4 is capturing roughly 71% of real paid search traffic that week, a specific, segment-level number a brand can actually act on, rather than an assumption applied uniformly across the whole site.

Layer Three: Automating the Comparison Through the Real GA4 MCP

Google publishes an official, real, read-only GA4 MCP server, connecting a GA4 property's real data directly to Claude and other MCP-compatible clients through Google's own Analytics Data API. It's genuinely read-only by design, using the analytics.readonly scope, meaning it can query and report on real GA4 data but cannot alter campaigns, budgets, or account settings.

With GA4 connected through its own real MCP server, and Plausible's data pulled in alongside it, whether through its own API or exported into the same reporting layer, Claude can be prompted to calculate the extrapolation quotient by segment, flag which channels or campaigns show the widest gaps between the two sources, and produce a real, recurring monthly report without a human manually cross-referencing two separate dashboards each time.

For a more permanent, visual version of the same comparison, GA4's real, existing Power BI connectivity, either Microsoft's native (currently beta) connector or a more mature third-party ETL tool, can feed the same consented GA4 numbers into a Power BI report alongside Plausible's real figures, giving a business audience a live, ongoing view of both the raw numbers and the calculated extrapolation quotient by segment, not just a one-off analysis.

Layer Four: Cloudflare and Azure Raw Logs as a Genuine, Independent Ceiling

Even a two-tool comparison has a real limitation: if something is wrong with how both GA4 and Plausible are implemented on a site, comparing them to each other won't catch it. A genuine third, independent verification layer is raw edge and server log analysis, through Cloudflare or Azure, since both see every real request that reaches a site's infrastructure, regardless of consent state, cookies, JavaScript execution, or ad blockers. It's the one measurement layer that structurally cannot itself have a consent-gate blind spot, because it isn't a script running in a visitor's browser at all; it's a record of the request itself.

The same extrapolation-quotient logic applied to Plausible versus GA4 can be applied here too, comparing raw log volume against GA4's consented numbers for the same real period, giving a genuine, second, independent correction factor to check the first one against.

One real, honest caveat worth stating directly: raw, per-request log export, Cloudflare's Logpush, or the equivalent on Azure, is typically an Enterprise-tier capability, not something every site has access to by default on a standard plan. Cloudflare's own free and lower-tier plans provide aggregated analytics dashboards, genuinely useful, but not the full per-request log needed for this kind of precise, independent comparison. A brand considering this third layer should confirm what their actual hosting or CDN plan includes before assuming raw logs are available to pull.

Haven't set up consent-gated GA4 yet? This framework assumes GA4 is already correctly consent-gated for DPDP compliance. If that step isn't done yet, start with our real, step-by-step Consent Mode v2 implementation guide first. Read the implementation guide.

The Real Cost: Remarketing Disappears for Anyone Who Says No

None of the measurement layers above change the single biggest, real impact on marketers: for every user who does not give consent, remarketing stops being available as a conversion lever, on Meta and on Google both. This isn't a modelling gap that better analytics can paper over; it's a structural loss of the actual identifier needed to show that specific person another ad.

This hits D2C brands specifically hard, since D2C performance marketing has leaned unusually heavily on remarketing and lookalike audiences built from site visitors and cart abandoners, exactly the audiences that a consent decline removes from the pool entirely. A brand that's used to remarketing carrying a large share of its performance budget's efficiency needs to plan for that share genuinely shrinking, not assume better tooling will recover it.

A real, unresolved gray area: if a user accepts a cookie consent banner in full, does that constitute valid, DPDP-compliant consent specifically to be remarketed to? The DPDP Act's purpose limitation principle requires consent tied to a specified purpose stated at the time it's given, and “accept cookies” and “consent to be remarketed to across other sites and platforms” are arguably two different, specific purposes, not one. This hasn't been definitively tested or clarified yet, and brands and their agencies should treat a blanket “Accept All” click as a genuinely uncertain basis for remarketing consent specifically, not a settled green light, until real regulatory guidance or enforcement clarifies it.

The Historical Data Problem: Custom Audiences Built Before Compliance

A real, separate and significant issue sits behind current tracking altogether: most brand marketers today run custom-audience campaigns by uploading customer mobile numbers and email addresses collected over years, often long before DPDP-specific, purpose-limited consent was ever captured for that specific use. Under the Act's purpose limitation principle, personal data can only be used for the specific purpose it was originally, genuinely consented for. A customer's email address collected for order confirmations or customer support was not, in almost every real case, consented to for building an advertising custom audience.

That means the practice of uploading historical customer lists to build custom audiences is a genuine, real compliance risk for the vast majority of brands' existing databases, not a theoretical one, since fresh, purpose-specific consent for that exact use very likely does not exist at the individual, granular level for data collected before this became a live compliance concern. Brands relying on this tactic need to audit what consent, if any, was actually captured for each list, and in most cases, should expect to stop the practice for historical data until fresh, purpose-specific consent is obtained.

The Real, Broader Consequence for the Industry

Put together, these constraints represent a genuine, structural shift, not a temporary compliance inconvenience. Brand and performance campaigns that have relied on remarketing and custom-audience targeting to keep acquisition costs efficient will need real, credible alternatives for top-of-funnel marketing, since a meaningful share of the audience-precision tools that kept costs down are becoming unavailable for non-consenting users. The honest, likely outcome is that overall marketing costs rise, for a real, structural reason, not a cyclical one, and the industry, agencies and brands both, needs to be planning for that now, not discovering it once enforcement lands.

References

  • Independent Plausible vs. GA4 benchmark comparisons (multiple sources, 2026), on real, measured traffic-capture differences under consent gating.
  • Google, Google Analytics Data API and the official analytics-mcp GA4 MCP server (GitHub).
  • Microsoft Power Query, Google Analytics connector documentation.
  • Cloudflare, Logpush and Cloudflare Logs documentation; Digital Personal Data Protection Act, 2023, Section 6(1) (purpose limitation).

Need help navigating the marketing impact of the DPDP Act? Reach out to us for a no-obligation chat, or explore our Brand & Digital Strategy practice.

Let's talk about what this could look like for your brand

Start a Project