Consent Mode & KVKK
Consent Mode is where legal policy meets measurement reality. Your counsel decides what your KVKK and GDPR posture requires; our job is making the tracking obey it precisely, and then telling you what that costs you in measurable data, as a number from your own export rather than a vendor's estimate.
The division of labor
We are not lawyers and we do not write your privacy policy. What we do is the technical half that determines whether the policy is actually enforced: Consent Mode configuration, consent-aware tag firing, data minimization in what gets collected, and verification that a declined user really is declined everywhere, including in the server-side integrations that ad platforms use.
That verification matters because the failure mode is silent in both directions. A banner that blocks tags it should not blocks revenue data you were entitled to. A banner that fires tags it should not creates compliance exposure that nobody notices until someone audits it.
What we implement
Consent Mode v2 with both advertising signals, ad_user_data and ad_personalization, wired as distinct decisions rather than one blanket toggle, and analytics_storage governing measurement separately. Basic versus advanced implementation chosen deliberately: advanced sends cookieless pings that feed Google’s modeling and preserve aggregate signal, basic sends nothing before consent and therefore loses more measurable data. Most clients are better served by advanced, but if your legal position requires zero pre-consent requests, that decision is made with counsel, not by us.
Then the plumbing that consent banners usually get wrong: the CMP integration firing in the right order so no tag races ahead of the consent decision, defaults set correctly per market, consent state propagated to server-side integrations and conversion APIs, and the state persisted so returning users are not asked again or, worse, treated as declined by accident.
Measuring what it costs you
This is the part almost nobody does, and it is the reason teams argue about consent with no data. Your GA4 BigQuery export carries the consent state on every event. Grouping by it gives you the real rate: by day, by platform, by market, and separately on purchase events, because consent behavior differs by intent and the loss that matters is the one on transactions.
With that number you can plan instead of guess. You know how far your consented dataset is from total truth, you can reconcile against backend revenue to size the gap, and you know which reports to read as trends rather than absolute counts. It also explains the divergence that surprises teams after a banner change: GA4’s interface blends modeled data back in, while your BigQuery export stays consented-only, so the two drift apart by exactly the amount modeling is covering.
What modeling does and does not give back
Behavioral modeling estimates the sessions and conversions of non-consenting users and blends them into interface reports once thresholds are met. Three limits worth writing on the wall: it never reaches your BigQuery export, so your warehouse is consented-only truth; modeled users cannot enter audiences or remarketing lists, so your addressable pool shrinks by the real decline rate whatever the reports say; and its quality depends on ping volume, so a basic implementation gets little back.
Where this sits
Consent configuration and estimated data loss are standing checks in our Measurement Health Framework, run on every audit and monitored continuously in Analytics Consultancy engagements. A consent banner update that quietly cuts a third of your events is exactly the kind of change that goes unnoticed for weeks without daily checks.
FAQ
Does Consent Mode make us KVKK compliant?
Should we use basic or advanced Consent Mode?
How much data will we lose?
Our GA4 and BigQuery numbers stopped matching after a banner change. Why?
Can we recover declined users for ad platforms through CAPI?