Tracking vóór toestemming: wat het is en waarom toezichthouders het als overtreding behandelen
Netwerkverzoeken die identificatoren meedragen en worden afgevuurd voordat een gebruiker toestemming heeft gegeven. Het meest voorkomende AVG/ePrivacy-gebrek op het Europese web — en het gebrek waar toezichthouders het vaakst boetes voor hebben opgelegd.
Lukas Kontur · · 5 min leestijd
Tracking vóór toestemming is een categorie bevindingen in onze scanner. Hij wordt geactiveerd wanneer de browser tussen het begin van een verse paginalading en het moment waarop een gebruiker een actie op de toestemmingsbanner uitvoert, een of meer netwerkverzoeken verzendt die identificatoren bevatten, niet-essentiële analytics-payloads vervoeren of niet-essentiële cookies plaatsen.
Dit is het meest voorkomende gebrek dat we vaststellen. In onze scan van 97.000 EU-websites werd het merendeel van de hoog-risico-classificaties veroorzaakt door tracking vóór toestemming, niet door ontbrekende banners of defecte weiger-knoppen.
Waar de scanner naar zoekt
De detector observeert het netwerk vanaf het moment dat de browser het documentverzoek doet tot een van drie gebeurtenissen plaatsvindt:
- De gebruiker klikt op een knop op de toestemmingsbanner (accepteren, weigeren, instellingen).
- Een meetbaar cookie of
localStorage-vermelding voor de toestemmingsstatus wordt geschreven. - Een time-out verstrijkt (standaard 8 seconden) zonder enig toestemmingssignaal.
Elk verzoek dat in dat venster wordt afgevuurd, wordt onderzocht op drie signalen:
- Bekende tracker-vingerafdruk. Het bestemmingsdomein, het verzoekpad of het payload-patroon komt overeen met een vermelding in onze tracker-database. Dit omvat Google Analytics, Meta Pixel, Hotjar, LinkedIn Insight, TikTok Pixel, X-conversiepixels en vele andere.
- Identificator-dragende payload. Het verzoek bevat een stabiele client-identificator (cookie, vingerafdruk-hash of query-parameter die over meerdere pagina's voortbestaat).
- Niet-essentieel cookie geschreven. Het antwoord plaatst een cookie dat volgens classificatie niet strikt noodzakelijk is voor de functionaliteit van de site.
Eén van deze signalen volstaat om de bevinding te activeren. Alle drie samen vormen het typische patroon voor een Google Tag Manager-container die afvuurt vóór de toestemmingspoort.
Het juridische kader, kort
Wij zijn niet uw advocaat. De kale feiten:
- GDPR Art. 6(1)(a) vereist een geldige rechtsgrond voor de verwerking van persoonsgegevens. Voor niet-essentiële trackers is dat toestemming.
- GDPR Art. 7 stelt de maatstaf voor wat geldige toestemming is: vrij gegeven, specifiek, geïnformeerd, ondubbelzinnig en herroepbaar.
- ePrivacy Directive Art. 5(3) vereist uitdrukkelijk toestemming voordat informatie op het eindapparaat van een gebruiker wordt opgeslagen of geraadpleegd — dus voordat cookies en vergelijkbare identificatoren worden gelezen of geschreven. Of een specifiek netwerkverzoek vóór toestemming overgaat in een overtreding hangt af van de vraag of het informatie van het apparaat leest of erop schrijft, of het identificatoren meedraagt en of het als "strikt noodzakelijk" kan worden gerechtvaardigd — dat zijn de vragen die toezichthouders afwegen.
Nationale implementaties verschillen in detail. Het Duitse TTDSG (nu TDDDG) en de Franse omzetting via de Loi Informatique et Libertés zoals gehandhaafd door de CNIL hebben de meest zichtbare handhaving opgeleverd. DPAs in de hele EU hebben gewaarschuwd voor patronen van tracking vóór toestemming; specifieke handhavingsdrempels variëren per rechtsgebied. Het onderliggende beginsel is overal hetzelfde: eerst toestemming, dan tracker.
Wat toezichthouders daadwerkelijk hebben gedaan
Een korte, gedeeltelijke tijdlijn van besluiten waarin tracking vóór toestemming de centrale bevinding was:
- CNIL v. Google (december 2020): EUR 100 miljoen voor het plaatsen van advertentiecookies op
google.frzonder voorafgaande toestemming. - CNIL v. Amazon Europe Core (december 2020): EUR 35 miljoen voor hetzelfde patroon op
amazon.fr.
Dit zijn niet de enige zaken — het zijn de dragende. Het patroon erdoorheen is consistent: de toezichthouder mat het netwerkgedrag en behandelde de technische werkelijkheid als doorslaggevend, ongeacht de tekst van het beleid.
De scripts die het meestal veroorzaken
Grofweg in de volgorde waarin we ze als hoofdoorzaak bij een hoog-risico-scan tegenkomen:
- Google Tag Manager-containers die zonder consent-mode-gating zijn geconfigureerd, of waarbij consent mode zo verkeerd is geconfigureerd dat de standaardstatus "granted" is.
- Meta Pixel dat rechtstreeks via
<script src>wordt geladen in plaats van achter een toestemmings-callback te wachten. - Hotjar-sessieopname die wordt gestart voordat de banner is weggeklikt.
- LinkedIn Insight voor B2B-retargeting, met name op bureau- en SaaS-sites.
- TikTok Pixel in consumenten-e-commerce.
- First-party-analytics-implementaties die
navigator-eigenschappen lezen of fingerprinting-cookies plaatsen voordat enige gebruikersactie heeft plaatsgevonden.
De gemeenschappelijke factor is bijna nooit het script zelf — het is de inrichting. Elk van deze leveranciers publiceert een gedocumenteerde manier om het afvuren te koppelen aan een toestemmingssignaal; de standaardinstallatie-instructies vermelden dat echter vaak niet.
Hoe een schone scan eruitziet
Een site die onze pre-consent-controle doorstaat, doet een van het volgende:
- Laadt helemaal geen third-party tracking totdat toestemming is gegeven. Functionele cookies (sessie, taalvoorkeur, CSRF) zijn prima.
- Laadt de tag manager in "denied"-status, met alle niet-essentiële tags achter expliciete toestemmingssignalen, en werkt de status na de gebruikersactie bij via Google Consent Mode v2 of een gelijkwaardig mechanisme.
- Laadt tracker-stubs die geen identificatoren overdragen totdat de toestemmings-flag is gezet.
In ons corpus uit het eerste kwartaal van 2026 met 97.000 EU-sites had 68% een trackingdienst actief voordat enige toestemmingsbeslissing was genomen. De minderheid van sites die de pre-consent-controle doorstaat, deelt een profiel: het netwerk in het pre-consent-venster wordt gedomineerd door het document zelf, CSS- en lettertypebestanden en een favicon — niets dat een identificator van het apparaat af draagt.
Hoe je het oplost
De eerlijke versie: er is geen kortere weg. Elke tag moet worden gecontroleerd op de vraag of hij afvuurt voordat het toestemmingssignaal is gezet. Stappen die in de praktijk werken:
- Open de site in een schoon browserprofiel met de devtools open.
- Filter het netwerk op "third-party" en herlaad.
- Alles wat afvuurt voordat je op een banner-knop klikt, is een kandidaat.
- Vind voor elke kandidaat de loader (meestal een script-tag, een tag-manager-trigger of een inline snippet) en koppel deze aan het toestemmingssignaal.
- Hertest. Herhaal totdat het pre-consent-venster leeg is van trackers.
Als u een toestemmingsmanagementplatform gebruikt, is de "blokkeren tot toestemming"-modus van het platform noodzakelijk, maar niet voldoende — veel CMP's blokkeren alleen het cookie-schrijven, niet het verzoek. Article 5(3) van de ePrivacy Directive vereist toestemming voordat informatie op het apparaat van een gebruiker (cookies, local storage, vergelijkbare identificatoren) wordt opgeslagen of geraadpleegd. Of een specifiek netwerkverzoek vóór toestemming die verplichting in werking stelt, hangt af van wat het verzoek van het apparaat leest of erop schrijft — een feitelijke vraag.
Voor een uitgewerkt voorbeeld op uw eigen domein, start een scan en bekijk het paneel "pre-consent network" van het rapport. Elk overtredend verzoek wordt vermeld met zijn initiator-stack, zodat u het tot de bronbestand in uw codebase kunt herleiden.
Laatst bijgewerkt: