Google Consent Mode v2: de signalen, de modi, en hoe je de jouwe controleert.
Consent Mode is makkelijk te installeren en makkelijk subtiel verkeerd te krijgen, omdat vrijwel elke fout geruisloos is. Hier staat wat de vier signalen werkelijk sturen, hoe je de consent-status rechtstreeks van het netwerkrequest afleest, en welke drempel je account moet halen voordat modellering iets teruggeeft.
Consent Mode v2 is een API die de consent-keuzes van een bezoeker doorgeeft aan Google-tags. Het voegt ad_user_data en ad_personalization toe aan de bestaande ad_storage en analytics_storage. De eerste twee zijn poorten — ze bepalen of cookies gelezen of geschreven mogen worden. De laatste twee zijn geen poorten: ze reizen mee met het request en instrueren Google over wat het met de data mag doen zodra die binnen is. Sinds maart 2024 heb je alle vier nodig om conversietracking en remarketing werkend te houden voor EER- en VK-verkeer.
Twee signalen sturen de verzameling. Twee niet.
Dit is het onderscheid dat de meeste implementaties missen. ad_storage en analytics_storage zitten stroomopwaarts: zij bepalen of een tag überhaupt cookieopslag mag gebruiken. ad_user_data en ad_personalization zijn stroomafwaartse instructies — ze houden de tag niet tegen, ze vertellen Google of de zojuist ontvangen data gebruikt mag worden voor advertenties en voor personalisatie. Een setup die het opslagpaar goed zet en het v2-paar ongezet laat ziet er gezond uit in Tag Assistant en laat je remarketing-audiences ondertussen stilletjes leeglopen, want het signaal dat Google nodig heeft om ze te vullen komt nooit aan.
Consent van de lijn aflezen: gcs en gcd
Elk Google-request draagt ze. gcs is de v1-parameter in de vorm G1xy, waarbij x staat voor ad_storage en y voor analytics_storage, 1 voor toegestaan en 0 voor geweigerd — G111 is dus allebei toegestaan en G100 geen van beide. gcd is de v2-parameter en codeert alle vier de signalen met letters voor de overgang, niet alleen voor de eindstand: l betekent nooit gezet, p geweigerd als default en nooit bijgewerkt, t toegestaan als default en nooit bijgewerkt, r geweigerd als default en daarna toegestaan door de gebruiker, en u toegestaan als default en daarna geweigerd. Dat onderscheid is het bruikbare deel. Een r of een u bewijst dat je update-call is afgegaan. Een p of een t bij een bezoeker die op de banner klikte bewijst dat hij dat niet is.
Basic versus advanced is een datakeuze, geen compliancekeuze
Beide zijn compliant. In basic worden tags volledig geblokkeerd totdat er consent is, dus een bezoeker die weigert draagt helemaal niets bij. In advanced laden de tags wél en sturen ze cookieloze pings met willekeurige, kortstondige identifiers in plaats van cookiegebaseerde, en Google gebruikt die om de conversies te modelleren die het niet kan waarnemen. Advanced levert merkbaar meer gerapporteerde conversies op. Het betekent ook dat er requests vertrekken voor mensen die weigerden, en dat is het eerste waar een DPO over wil praten. Kies bewust en leg de redenering vast, want er wordt naar gevraagd.
Modellering kent een drempel, en de meeste accounts halen die niet
Conversiemodellering gaat niet vanzelf. Google hanteert ongeveer 700 advertentieklikken over zeven dagen per land- en domeingroep voordat de modellen aanslaan, en daarna volgt nog een trainingsperiode voordat gemodelleerde conversies in de rapportage verschijnen. Onder die drempel stuurt advanced nog steeds de pings, maar krijg je geen gemodelleerde conversies terug — je hebt het privacygesprek op je hals gehaald zonder de opbrengst te innen. Tel je klikvolume per land voordat je advanced kiest op basis van het modelleringsargument.
Volgorde, defaults en wat iedereen vergeet
Het default-commando moet vóór elke meettag draaien, wat in GTM betekent dat je het op de Consent Initialization-trigger afvuurt en niet op All Pages. wait_for_update geeft een asynchrone banner een opgegeven aantal milliseconden om te antwoorden voordat tags doorgaan. Defaults kun je per regio zetten met ISO 3166-2-codes, waarbij de specifiekere regio wint, dus US-CA overruled US. Twee instellingen worden vrijwel altijd overgeslagen: ads_data_redaction, dat advertentieklik-identifiers uit requests haalt zolang ad_storage geweigerd is, en url_passthrough, dat gclid en dclid via de URL meeneemt zodat attributie een navigatie overleeft wanneer cookies niet beschikbaar zijn.
Waar server-side de vorm van het probleem verandert
Client-side is consent adviserend. De browser vraagt elke tag zich te gedragen en elke leveranciers-tag beslist zelf, wat betekent dat je compliancepositie niet beter is dan de minst zorgvuldige template in je container. In een server container komt de consent-status mee met het event en wordt hij één keer getoetst aan beleid per bestemming, zodat een geweigerd signaal betekent dat het uitgaande request nooit wordt opgebouwd in plaats van opgebouwd en gemarkeerd. Dat is aanzienlijk makkelijker aan te tonen, en in de praktijk levert het ook schonere data op, omdat de events die je wél mag sturen niet langer sneuvelen samen met de events die je niet mag sturen.
- 01 Open het Netwerk-tabblad, filter op gcd, en controleer of de parameter überhaupt op je Google-requests staat
- 02 Accepteer de banner en kijk of de gcd-letters veranderen in r of u — dat bewijst dat de update-call is afgegaan, niet alleen de default
- 03 Controleer of het default-commando op Consent Initialization draait en niet op All Pages
- 04 Weiger, en verifieer dat ad_user_data en ad_personalization allebei op denied staan en niet ongezet zijn
- 05 Kijk of ads_data_redaction en url_passthrough zijn ingesteld; meestal niet
- 06 Tel advertentieklikken per land over zeven dagen af tegen de drempel van ~700 voordat je op modellering leunt
- 07 Open in Google Ads de conversiediagnostiek en kijk naar waarschuwingen over consent mode
Is Google Consent Mode v2 verplicht? +
Niet overal. Het is nodig om conversietracking, remarketing en audience-functies werkend te houden in Google Ads voor verkeer uit de EER en het VK. Daarbuiten breekt er niets zonder, al blijven de signalen nuttig.
Wat is het verschil tussen Consent Mode v1 en v2? +
v1 had ad_storage en analytics_storage, die allebei cookietoegang afschermen. v2 voegt ad_user_data en ad_personalization toe, die niets afschermen — ze instrueren Google of de data na ontvangst gebruikt mag worden voor advertenties en personalisatie.
Hoe controleer ik of Consent Mode echt werkt? +
Kijk naar de gcd-parameter op een willekeurig uitgaand Google-request. Ontbreekt hij, dan draait Consent Mode niet. Blijven de letters op p of t staan nadat een bezoeker met je banner heeft geïnteracteerd, dan is de default wel afgegaan maar de update niet — de meest voorkomende fout die er is.
Heb ik nog steeds een cookiebanner nodig? +
Ja. Consent Mode is het transport, niet de toestemming zelf. Een CMP haalt de keuze op en bewaart hem; Consent Mode is hoe die keuze bij de tags van Google terechtkomt.
Kan ik met server-side tagging consent overslaan? +
Nee, en wie dat beweert verkoopt je een risico. Server-side verzamelen verandert waar de verwerking plaatsvindt, niet of je er een grondslag voor nodig hebt.
Liever dat iemand dit gewoon goed doet?
Consent-handhaving in de container, gekoppeld aan je CMP, met audit trail — onderdeel van elke bouw die we opleveren.