Laatst las ik iets van Himanshu Sharma — die ik je aanraad te volgen als analytics en digitale business je interesseren — waarin hij zei dat Google Universal Analytics niet de nek omdraaide omdat er meer servers nodig waren (“gebruikers dwingen” BigQuery te gebruiken).
Dat was het niet.
Het was privacy.
In GA3 konden we namelijk alle gegevens verzamelen die nodig waren om zeer nauwkeurige gebruikersprofielen te maken, iets wat volledig in strijd was met de AVG.
En Google heeft geen zin om opnieuw een boete te krijgen.
Daarom dwingt Google de migratie naar GA4 af, een tool die op dit vlak veel strenger is en die wij, als mensen die ermee werken, juist daardoor een stuk slechter vinden.
Dus proberen we een niveau van datakwaliteit te bereiken dat vergelijkbaar is met wat we vroeger hadden.
Hoewel het moeilijk is om dat opnieuw te halen (vrijwel onmogelijk, zou ik zeggen), zijn er opties zoals GA4 implementeren zonder cookiebanner, wat in Spanje legaal is als je aan bepaalde criteria voldoet.
Die criteria maken het mogelijk de nauwkeurigheid van de verzamelde gegevens te verhogen, al blijft die ver verwijderd van de gouden tijd van digitale analytics — vóór 2.018 en die vermaledijde cookiebanner. Ik leg ze uit in het artikel.
In deze post laat ik je het systeem zien dat ik in mijn ecommerce-bedrijven en die van enkele klanten heb opgezet en waarmee we het beste van twee werelden kunnen krijgen:
- Aan de ene kant zoveel mogelijk gegevens legaal verzamelen in Spanje.
- Gebruikmaken van de geavanceerde functies met de gegevens van gebruikers die ons toestemming geven. In het beste geval zal dat rond de 70% liggen.
Duaal meetsysteem met Google Analytics
De kern van de aanpak die ik je ga uitleggen is het gebruik van twee GA4-properties:
- De eerste wordt zo ingesteld dat we die altijd kunnen activeren, zonder dat de gebruiker de cookiebanner hoeft te accepteren.
- De tweede gebruikt alle mogelijkheden van GA4, maar daarvoor is de toestemming van de gebruiker nodig.
Als je ziet waar ik naartoe wil, begrijp je dat we twee properties met verschillende gegevens zullen hebben om in onze reporting te gebruiken.
In sommige gevallen gebruiken we de eerste, met minder functies maar meer data. Bijvoorbeeld om de performance van kanalen of campagnes te meten.
In andere gevallen gebruiken we de tweede, wanneer we sociodemografische gegevens van gebruikers willen kennen of in Analytics gegevens van andere Google-tools willen bekijken, zoals Google Ads of Search Console.
Tijd en ervaring met beide zullen ons leren wanneer we de ene of de andere moeten gebruiken om een bepaald gegeven op te halen.
Dit is het grote geheel, nu leg ik je uit hoe je ze allebei configureert.
Zoals ik eerder zei, in dit artikel vind je de configuratie van dit type property uitgebreid uitgelegd, met de relevante juridische onderbouwing.
Als je dit soort dubbele implementaties overweegt, ga ik er bovendien vanuit dat je ervaring hebt met Google Analytics en geen begeleide stap-voor-stapuitleg nodig hebt, maar alleen de belangrijkste richtlijnen, en dat is wat ik in deze post vertel.
Bij de meer lastige onderdelen ga ik wel dieper op de details in.
Bijvoorbeeld bij de implementatie.
De tools implementeren
Een manier vinden om twee GTM-containers te laden, één met toestemming voor analytics-cookies op “granted” en één op “denied”, is niet direct vanzelfsprekend.
Ik heb verschillende methoden getest en uiteindelijk werkten er maar twee. Eén makkelijker en één beter.
De makkelijke methode
In dit geval is het proces als volgt:
- Maken en configureren van een GA4-property zonder banner.
- Die rechtstreeks in de code plaatsen. Het kan ook via een GTM-container die correct is ingesteld (ik leg zo uit hoe) en altijd afvuurt.
- Maken en configureren van een tweede GA4-property met alles wat we nodig hebben en waarvoor toestemming vereist is (userId, , Google signals, , koppeling met Google Ads)…).
- Implementeren via een nieuwe GTM-container met de juiste consent mode.
- Deze tweede container laden we alleen wanneer de gebruiker op de accepteerknop van de cookiebanner klikt. Daardoor missen we bepaalde gegevens en wordt de modellering van Google Analytics slechter.
- De rechten van deze tweede container op “granted” zetten wanneer de gebruiker de cookies accepteert.
Kortom:
- Twee GA4-properties en één of twee GTM-containers maken.
- Alles zo configureren dat het in de juiste volgorde afvuurt.
De betere methode
Laten we het ons wat moeilijker maken, in ruil voor betere dataverzameling in de GA4-property waarvoor toestemming nodig is:
- Maken en configureren van een GA4-property zonder banner.
- Maken van een GTM-container die afvuurt wanneer de pagina laadt en die configureren met consent mode, met analytics-cookies op “granted”, ook al heeft de gebruiker de cookies misschien nog niet geaccepteerd. Als GA4 correct is ingesteld, mogen we deze cookies in Spanje wettelijk laden.
- Maken en configureren van een tweede GA4-property met alles wat we nodig hebben en waarvoor toestemming vereist is.
- Maken van een tweede GTM-container die afvuurt met cookies en opslagrechten voor analytics en advertenties op “denied”.
- De rechten van deze tweede container op “granted” zetten wanneer de gebruiker de cookies accepteert.
Samengevat:
- Een GA4-property en een GTM-container configureren zoals je dat tot nu toe deed (met consent mode ingeschakeld, bewust of onbewust, en de GA4-configuratie die je nodig had).
- Een nieuwe GA4-property en een nieuwe GTM-container toevoegen, die vóór de eerdere worden geladen, en ze configureren alsof consent mode niet bestond.
Maar laten we deze tweede methode stap voor stap bekijken.
#1. Configuratie van de eerste GTM-container (zonder banner)
Dit was het onderdeel dat me bij het opzetten van het hele systeem de meeste hoofdpijn bezorgde. Uiteindelijk kreeg ik het met deze configuratie werkend:
Twee tags, die van GA4 en die van consent mode. Ik gebruik die van Simo Ahava (natuurlijk):

De GA4-tag laad ik op alle pagina’s.
De configuratie van de consent-mode-tag is als volgt:

En als trigger de gebruikelijke:

#2. Configuratie van de normale container
Er zijn verschillende manieren om consent mode te configureren, afhankelijk van je CMP.
Hier leg ik er één uit, maar je kunt blijven gebruiken wat je tot nu toe gebruikte, zolang je controleert of dit de configuratie van de GA4-tag zonder banner niet beïnvloedt.
Controleer dus dat de cookies van de tag zonder banner altijd worden geplaatst.
#3. Configuratie van de GA4-tag zonder banner
Het staat goed uitgelegd in het artikel dat ik eerder linkte, maar samengevat:
- Deel op geen enkele manier gegevens met Google.
- Activeer Google signals niet.
- Je kunt de periode voor gegevensverzameling en -bewaring op 14 maanden laten staan
- Maar je mag die niet automatisch verlengen bij elk bezoek van de gebruiker.
- Je mag userId niet gebruiken.
- Je mag de GA4-property niet koppelen aan een andere Google-tool.
- Cross-domainmeting is niet toegestaan tussen verschillende merken, hoewel er in principe geen probleem zou moeten zijn tussen regionale domeinen (.es, .pt, .fr) van hetzelfde merk / bedrijf.
- Ik weet niet zeker of granulaire gegevens wel of niet gebruikt mogen worden. Wil je geen risico lopen, schakel ze dan uit. Is dat verplicht om aan de regels te voldoen? Ik zou zeggen van niet, maaar…
#4. Configuratie van de normale GA4-tag
Hier kun je gewoon de implementatie gebruiken die je al hebt:
- Met of zonder userId.
- Wel of niet gekoppeld aan Google Ads of GSC.
- Met of zonder Google signals.
- Met verlenging van de vervaldatum van de cookie bij elk nieuw bezoek van de gebruiker.
- …
Al die dingen waarvoor expliciete toestemming nodig is.
Controle
Ongeacht de methode die je hebt gekozen, zou het volgende moeten gebeuren wanneer een nieuwe gebruiker je website bezoekt zodra alles draait:
#1. De tag van de GA4-property zonder banner vuurt af.
Heb je voor de betere methode gekozen, dan vuurt ook de tag van de normale GA4-property af, samen met die van de twee GTM-containers waarin ze zitten:

#2. De cookies van de GA4-property zonder banner zijn geplaatst, maar die van de normale niet:

#3. Hetzelfde herhaalt zich bij elke nieuwe paginalaad totdat de gebruiker de cookies accepteert.
Op dat moment worden de cookies van de normale GA4-property geladen:

Als dit is wat er gebeurt, gefeliciteerd: je kunt nu profiteren van de voordelen van dit systeem.
Voordat we die bekijken, nog één opmerking.
Cookiebeleid
Dat je de gebruiker niet om toestemming hoeft te vragen, betekent niet dat je hem niet hoeft te informeren.
Dat doe je via het Privacybeleid of Cookiebeleid van de website.
In dit gedeelte moeten we uitleggen welke cookies worden geplaatst, wat hun vervaldatum is en welk type cookies het zijn.
En dat moet zowel voor de cookies die we altijd plaatsen als voor de cookies die pas in de browser worden geïnstalleerd nadat de gebruiker de banner accepteert:

Nu komen we bij het goede deel.
Voordelen van het systeem
Google Analytics op deze dubbele manier implementeren maakt het mogelijk om je dataverzameling enorm te verbeteren.
Je beseft pas hoeveel verschil dit maakt wanneer je het test, vooral bij middelgrote of kleine projecten.
Met de property zonder banner kun je een zeer hoog percentage van je conversies verzamelen en aan het juiste kanaal toeschrijven, waardoor je veel minder blind vaart.
Voor projecten die niet kunnen profiteren van de voordelen van consentmodellering in GA4 is dit puur goud.
Aan de andere kant blijven de “geavanceerde” functies van de tool in onze normale property behouden, alsof de andere niet bestond.
Met andere woorden: onze gebruikelijke stack en reporting worden helemaal niet benadeeld. Het is simpelweg een extra laag erbovenop.
Maar natuurlijk kon niet alles goed zijn…
Nadelen
Volgens mij zijn het er drie. En ze zijn belangrijk.
Complexere implementatie
Het eerste en meest voor de hand liggende nadeel is de dubbele implementatie.
De configuratie is inderdaad iets complexer, maar als je de stappen volgt die ik heb uitgelegd, zou je het binnen een halfuur moeten kunnen regelen, afhankelijk van je CMP en hoe je huidige consent mode is geïmplementeerd (dit punt kan irritant zijn).
Ook de implementatie in de toekomst wordt ingewikkelder, want je moet repliceren in twee GTM-containers dezelfde tags -ten minste de GA4-gerelateerde-, variabelen en triggers. Dubbel onderhoud.
Als we de DataLayer gebruiken wordt het wat draaglijker, maar het kost je altijd meer tijd dan wanneer je maar één GTM-container zou kunnen gebruiken.
Juridische veranderingen
Het tweede nadeel zijn juridische veranderingen en verschillen tussen landen.
Dit systeem dat ik je uitleg, werkt voor Spanje, maar zou bijvoorbeeld niet werken in Duitsland, omdat het gebruik van gegevens voor het maken van cohorten daar niet is toegestaan. En voorlopig kun je die functie in GA4 niet uitschakelen. Als ik moest gokken, denk ik trouwens dat dat niet lang meer zal duren…
Als je je al met AVG-kwesties hebt moeten bezighouden, heb je bovendien gezien dat sommige punten erg interpretabel zijn, en dat het niet duidelijk is wat wel en niet mag. Daarom is het niet vreemd dat er af en toe veranderingen zijn en toegestane use cases worden verduidelijkt, zoals gebeurde met de mogelijkheid om GA4 voor doelgroepmeting te gebruiken.
Dat betekent dat je, als je iets op je website wilt meten, nooit helemaal ontspannen achterover kunt leunen: je moet elke ontwikkeling blijven volgen.
En ja, dat is vermoeiend, dat ga ik niet ontkennen.
Moeilijkheden door de omgeving
Dat we wettelijk een cookie in de browser van de gebruiker mogen plaatsen zonder toestemming betekent niet dat we dat altijd kunnen.
Browsers worden elke dag strenger op privacy en het gebruik van adblockers neemt toe..
Het lijkt er niet op dat die trend gaat veranderen. Willen we maximale nauwkeurigheid bij het verzamelen en verwerken van onze gegevens, dan moeten we onze implementatie en het gebruik van analytics-tools blijven aanpassen.
Zaken zoals server-side tagging, het exporteren van gegevens naar BigQuery of de noodzaak van een eigen alternatief analytics-systeem zouden ons bezig moeten houden.
Sterker nog, ik zou zeggen dat ze een must zijn, ware het niet dat de benodigde technische capaciteit ervoor zorgt dat alleen grote bedrijven ze goed kunnen implementeren en benutten.
Misschien verschijnen er in de toekomst tools die het proces eenvoudiger maken, maar vandaag liggen de kosten van een server-side + BigQuery-implementatie buiten bereik van 90% van de bedrijven in dit land.
En met dat percentage ben ik nog optimistisch.
Juist daarom denk ik dat het implementeren van het systeem dat ik hier voorstel het minimum is waar je met je bedrijf naar zou moeten streven.
Conclusies
Dit is een van de belangrijkste artikelen van mijn hele blog.
Tenminste als je bedrijf in Spanje zit.
Dat is zo omdat het een lichtpunt biedt in de steeds donkerder wordende wereld van digitale analytics.
(Opnieuw) kunnen toeschrijven aan het juiste kanaal 90-95% van de conversies op onze website is reden voor een feestje, hoe je het ook bekijkt. Zeker bij kleine en middelgrote projecten, die door GA4 aan hun lot leken te zijn overgelaten.
Wanneer alles slechter wordt, smaken kleine overwinningen als deze extra goed.
Lees het systeem dus nog eens door, test het op je website en profiteer ervan.
En als je daarna nog meer wilt, bekijk dan deze pagina met meer tips over Google Analytics.
Elke week een nieuwe. En je kunt hem in je inbox ontvangen door je hier in te schrijven.

Geef een reactie