Deze gids is voor Shopify-winkels die kiezen tussen de basic- en advanced-modus van Consent Mode v2 — en voor de situatie waarin een banner tags tegenhoudt maar geen signaal verstuurt. Hij vergelijkt de drie op mechanismeniveau: wat de browser verlaat vóór een keuze, hoe de Customer Privacy API van Shopify de beslissing doorgeeft, en wat GA4 en Google Ads later laten zien.
Er komt geen rangorde in modi of tools uit, en hij doet geen uitspraak over je juridische verplichtingen; dat is aan een privacyjurist. Dit behandelt de technische implementatie, geen juridisch advies. Er staan geen leveranciersprijzen in; voor CMP-prijzen zie je de prijspagina van elke leverancier.
Wat stuurt de basic-modus van Consent Mode v2 eigenlijk vóór een keuze?
In de basic-modus laadt de Google-tag pas nadat de bezoeker de banner beantwoordt, dus Google ontvangt daarvoor niets — zelfs de standaard consentstatus niet — en helemaal niets als de bezoeker weigert. Na een toekenning laadt de tag en stuurt hij de standaard- en bijgewerkte consentstatussen.
In Shopify moeten twee mechanismen op één lijn zitten: de banner of CMP schrijft de beslissing via de Customer Privacy API, en jouw tagloader leest die voordat hij de Google-tag injecteert. Die twee staan los van elkaar, en het gaat mis wanneer ze het oneens zijn: de CMP legt een keuze vast terwijl een themesnippet, app-tag of webpixel de tag injecteert.
De prijs is structureel: Google stelt dat in de basic-modus conversiemodellering in Google Ads terugvalt op een algemeen model.
Wat stuurt de advanced-modus van Consent Mode v2 vóór een keuze?
De advanced-modus laadt de Google-tag bij het openen van de pagina met de consentstandaard op denied; zolang consent denied is, stuurt de tag cookieloze pings en geen volledige meting, en pas bij een toekenning schakelt hij over op volledige meting en cookies.
Google beschrijft drie cookieloze pings zolang consent denied is: consentstatus-pings vanaf elke pagina waarop Consent Mode actief is, pings voor key events, en Google Analytics-pings.
Die pings zijn mager, maar cookieloos betekent niet zonder identificatoren. Google noemt hun inhoud functionele informatie (tijdstempel, user agent, referrer) en geaggregeerde of niet-identificerende informatie: of de huidige of een eerdere pagina parameters van advertentiekliks zoals GCLID of DCLID droeg, een booleaanse consentstatus, en een willekeurig nummer dat bij elke paginalading wordt gegenereerd. Met ad_storage denied stelt Google dat er geen nieuwe advertentiecookies of apparaat-identificatoren worden geschreven en geen bestaande worden gelezen, en dat Ads-producten IP-adressen inkorten bij de verzameling — toch wordt de volledige pagina-URL, inclusief parameters van advertentiekliks, nog steeds verzameld. ads_data_redaction redigeert die identificatoren in consent- en key event-pings en in pagina-URL’s die ze bevatten.
De consentstatus reist mee in de requestparameters. Google documenteert dat gcs ad_storage en analytics_storage doorgeeft, en dat gcd altijd wordt verstuurd, of Consent Mode nu actief is of niet.
Advanced maakt ook het adverteerderspecifieke conversiemodel van Google Ads mogelijk. Gedragsmodellering in GA4 is een apart product met eigen vereisten: Consent Mode op elke pagina, tags die in alle gevallen laden vóór de consentdialoog, minstens 1.000 events per dag met analytics_storage denied gedurende minstens 7 dagen, en minstens 1.000 dagelijkse gebruikers die events met toekenning sturen gedurende minstens 7 van de voorgaande 28 dagen. Als je daaraan voldoet, is dat geen garantie op geschiktheid; het model past zijn eigen kwaliteitscontroles toe. De conversiediagnose van Google Ads maakt onderscheid tussen “Consent mode is implemented” en “Consent mode is implemented and modeling is active”, en Google documenteert een klikdrempel voor Ads van 700 kliks over 7 dagen.
In Shopify is diezelfde Customer Privacy API een JavaScript-API van de storefront, maar anders gemapt: de CMP vertaalt zijn doeleinden naar de consenttypes van Google en stuurt de update bij een keuze. Webpixels zijn een aparte uitvoeringscontext — strikt voor app-pixels, lak voor custom pixels — waarin de pixel init.customerPrivacy leest en zich abonneert op visitorConsentCollected. De pixelmanager van Shopify geeft een pixel pas vrij wanneer de toestemming van de bezoeker elk gedeclareerd doel dekt, dus een pixel die wordt tegengehouden tot die toestemming er is, kan geen Google-pings vóór consent uitsturen; die komen van de Google-tag in het storefront-document. Google stelt dat Google-tags binnen een custom pixel van Shopify geen ondersteunde implementatie zijn.
Wat gebeurt er als je helemaal geen Consent Mode gebruikt?
Een banner die je Google-tags tegenhoudt zonder een consent-API aan te roepen, laat Google niet in staat de keuze van de bezoeker te verifiëren; de EER-richtlijnen van Google zeggen dat dit tot dataverlies kan leiden. De basic- en advanced-modus bestaan er juist om dat te corrigeren.
Diezelfde documentatie stelt dat adverteerders consent moeten verzamelen voor eindgebruikers in de EER en signalen met Google moeten delen om de betreffende tags te blijven gebruiken voor meting, personalisatie en remarketing; zonder geldige signalen worden die functies beperkt voor EER-verkeer. De consentinstellingen van GA4 tonen per datastream of de signalen voor advertenties en gedragsanalyse aankomen.
Geen Consent Mode is dus niet neutraal: het is de situatie die de twee andere opties juist verbeteren.
Naast elkaar
De tabel vergelijkt de drie situaties op de criteria die de meeste Shopify-implementaties bepalen. Hij beschrijft afwegingen en brengt geen rangorde aan; geen enkele optie repareert een purchase-event dat om andere redenen stuk is.
Vergelijkingstabel — scrol horizontaal om alle kolommen te bekijken
| Criterium | Basic Consent Mode v2 | Advanced Consent Mode v2 | Geen Consent Mode (alleen CMP-poort) |
|---|---|---|---|
| Bron van events | Tag wordt pas geïnjecteerd nadat de bezoeker kiest | Tag laadt bij het openen van de pagina, standaard op denied | De loader of CMP beslist; geen consent-API aangeroepen |
| Dekking van purchase en refund | Geen van beide modi instrumenteert purchases of refunds; je thema, app of pixel moet de purchase versturen, en refunds hebben hun eigen orderdatapad nodig | Dezelfde instrumentatie; Consent Mode bepaalt alleen wanneer het signaal volledige meting mag dragen | Dezelfde instrumentatie, maar de events bereiken Google zonder enige consentstatus |
| Deduplicatie | Geërfd van je Shopify-purchasepad; verandert niet per modus | Hetzelfde | Hetzelfde |
| Omgaan met consent | Tags tegengehouden tot een toekenning; statussen verstuurd na de toekenning | Standaard op denied, update bij een keuze, pings zolang denied | Vastgelegd door de CMP, maar niet aan Google gesignaleerd |
| Controle en databestemming | De winkelier bestuurt het laden van tags; niets bereikt Google vóór een toekenning | De winkelier bestuurt de standaardwaarden en de updates; cookieloze requests bereiken Google zolang denied | De CMP bestuurt de poort; Google ontvangt requests zonder consentstatus |
| Afhankelijkheid en lock-in | Afhankelijk van de CMP-loader en je eigen poort | Afhankelijk van de mapping van de CMP naar de consenttypes van Google | Volledig afhankelijk van de CMP |
| Onderhoudslast | Controleer de poort opnieuw wanneer de loader of CMP verandert | Controleer standaardwaarden, updates en regio-logica opnieuw | Alleen de CMP-poort te bouwen; EER-functies blijven beperkt |
| Voor wie het past | Winkels die geen Google-tag vroeg willen laden | Winkels die in aanmerking willen komen voor modellering en EER-dekking | Winkels die bereid zijn Google-meting in de EER te verliezen |
Beslistabel
Koppel je situatie aan een startpunt. Dit zijn standaardkeuzes voor gangbare gevallen, geen regels.
Vergelijkingstabel — scrol horizontaal om alle kolommen te bekijken
| Als je situatie … is | Kies … |
|---|---|
| EER-bezoekers zijn een betekenisvol deel van je verkeer en je hebt adverteerderspecifieke conversiemodellering in Google Ads nodig | Advanced: basic stuurt geen signaal vóór consent en modelleert vanuit het algemene model van Google |
| Je wilt dat gedragsmodellering in GA4 in aanmerking komt | Advanced: Google vereist dat tags in alle gevallen laden vóór de banner |
| Er mag geen enkel request naar Google gaan vóór een keuze | Basic Consent Mode v2 |
| Je draait basic-modus en wilt weten welke modellering overblijft | Het algemene conversiemodel van Google Ads; advanced alleen als je het adverteerderspecifieke nodig hebt |
| Je CMP legt consent vast, maar Google ontvangt geen signaal | Implementeer Consent Mode; basic is een geldige eerste stap |
| Je purchase-event is al stuk of wordt dubbel geteld | Geen van beide: repareer eerst het purchasepad |
| Je weet niet wat Google op dit moment ontvangt | Controleer de standaardstatus en de update voordat je een modus kiest |
Wanneer je elke optie niet gebruikt
Basic levert modelleerdiepte in, advanced stuurt cookieloze pings vóór een keuze, en zonder Consent Mode breng je je EER-functies in gevaar.
Kies de basic-modus niet als je gedragsmodellering in GA4 nodig hebt — de voorwaarden daarvoor vragen dat tags in alle gevallen laden vóór de dialoog — of als het algemene Ads-model niet genoeg is voor je biedingen in de EER. Basic ondersteunt het algemene conversiemodel van Google Ads wel.
Kies de advanced-modus niet wanneer je juridische positie elk request naar Google vóór een keuze verbiedt; wanneer je CMP de doeleinden niet naar alle vier consenttypes van Google kan mappen; of wanneer niemand de standaardstatus en de update kan verifiëren, want de advanced-modus faalt geruisloos als de update nooit afgaat.
Draai de opzet zonder Consent Mode niet wanneer je adverteert op gebruikers in de EER, daar doelgroepen of remarketing nodig hebt, of “de banner houdt tags tegen” als gelijkwaardig aan Consent Mode ziet.
Hoe ik dit verifieer in echte implementaties
Verificatie dekt wat de pagina instelt voordat er een tag draait, wat er verandert bij consent, wat elk platform rapporteert, en of purchases aansluiten op de bestellingen.
- Lees de standaardstatus in Tag Assistant. Bevestig dat alle vier parameters —
ad_storage,ad_user_data,ad_personalization,analytics_storage— op denied staan voordat er tags draaien. - Ken consent toe en lees de update. Bevestig dat de vier op granted staan en controleer daarna welke tags afgingen of geblokkeerd werden. Een ontbrekende update wijst op de bedrading van de CMP.
- Inspecteer de requests. Bevestig dat de consentstatus in de requestparameters staat, dat de advanced-modus vóór een keuze een request met denied-status stuurt en dat basic er geen stuurt. Herhaal dit met een gesimuleerde EER-locatie.
- Lees wat de platforms rapporteren. Maak in de conversiediagnose van Google Ads onderscheid tussen “Consent mode is implemented” en “Consent mode is implemented and modeling is active”, met inachtneming van een gedocumenteerde vertraging van maximaal twee weken. GA4 DebugView toont events live binnenkomen.
- Controleer de Shopify-kant. Bevestig in welke uitvoeringscontext elke tag draait: de Customer Privacy API en de Google-tag horen bij het storefront-document, terwijl een webpixel in zijn eigen sandbox zit,
init.customerPrivacyleest en zich abonneert opvisitorConsentCollected. Een pixel die Shopify nog niet heeft vrijgegeven kan niet de bron van een ping vóór consent zijn. Waar ook Meta-events draaien, hoort Test Events in Events Manager te laten zien dat de pixel dezelfde poort volgt. - Reconcileer tegen de bestellingen. Vergelijk GA4-purchases met een Shopify-orderexport van een afgesloten periode volgens de standaardmethode op orderniveau. Consent Mode verandert de signaalkwaliteit, niet hoe je reconciliëert — orderreconciliatie is waar een echt verschil zichtbaar wordt.
Veelvoorkomende faalpatronen
Consent Mode kan in de bedrading mislukken ook als het model gezond is: een standaardstatus die te laat wordt gezet, een update die nooit afgaat, een standaard per regio die de banner tegenspreekt, of een CMP die een keuze vastlegt die geen enkele tag ooit leest.
- Standaardstatus gezet nadat een tag al draaide, waardoor Consent Mode het al verzonden request niet meer beïnvloedt.
- Update aangeroepen terwijl de pagina wordt gesloten, waardoor de browser het request afbreekt en de granted-status Google nooit bereikt.
- De keuze wordt niet bewaard, waardoor een bezoeker met een toekenning bij de volgende pagina terugvalt op de denied-standaard.
- Helemaal geen update — de banner legt een beslissing vast terwijl de tag in zijn standaardstatus blijft staan, in beide richtingen.
- Regio-logica ontbreekt of spreekt zichzelf tegen, waardoor EER-standaarden doorlekken naar ander verkeer of de banner tegenspreken.
- Onvolledige mapping van doeleinden, of twee Google-tagpaden die tegelijk actief zijn en tags met verschillende standaarden laden.
Beperkingen
Consent Mode verandert wat Google ontvangt en wat het kan modelleren. Het maakt een niet-gerelconciliëerd cijfer niet waar, haalt verkeer dat een bezoeker weigerde niet terug en vervangt geen juridisch advies; elke modus blijft begrensd door de keuze van de bezoeker en de beschermingen van de browser.
Gemodelleerde data is geschat, niet waargenomen. Google stelt dat gedragsmodellering alleen wordt meegenomen wanneer het vertrouwen in de modelkwaliteit hoog is, en dat wanneer er te weinig verkeer met consent is om het model te voeden, events van gebruikers die consent weigeren helemaal niet worden gerapporteerd. Verschillende GA4-functies nemen het nooit mee, waaronder doelgroepen, gebruikersexplorer, retentierapporten, voorspellende statistieken en BigQuery-export. In rapporten geldt modellering voor de statistieken gebruikers, sessies en nieuwe gebruikers, maar niet voor eventaantallen zoals page_view.
De pixelsandbox van Shopify en het storefront-document zijn aparte uitvoeringscontexten: de pixel die consent waarneemt is niet de Google-tag die erop handelt, dus ze kunnen het oneens zijn als gedeclareerde doeleinden, CMP-mapping en tagstandaarden uit elkaar lopen. Geen enkele Consent Mode lost attributieverschillen tussen GA4, Google Ads en Shopify-bestellingen op — ze tellen verschillende dingen op verschillende klokken.
Alternatieven
Als je probleem niet is welke modus je draait, kan een andere laag helpen: server-side levering voor transportverlies, reconciliatie wanneer platforms het oneens zijn, en een audit wanneer je niet weet wat er verstuurd wordt.
Voor het consentwerk zelf dekt de dienst Consent Mode v2 de CMP-integratie, regio-bewuste poorten en server-side propagatie, en de kennisbankpagina over Consent Mode v2 definieert de signalen en consenttypes. Gaan requests verloren ná consent in plaats van ervoor, dan is dat transport, en is server-side tracking de laag om te onderzoeken.
Zijn de platforms het simpelweg oneens, begin dan bij waarom de omzet van GA4 niet overeenkomt met Shopify. Als consent-poorten legitieme sessies in de verkeerde groep duwen, zie Unassigned-verkeer en de GA4-check op Unassigned-verkeer. Kun je helemaal niet zien wat er verstuurd wordt, dan is dat een trackingaudit.
