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:

  1. De gebruiker klikt op een knop op de toestemmingsbanner (accepteren, weigeren, instellingen).
  2. Een meetbaar cookie of localStorage-vermelding voor de toestemmingsstatus wordt geschreven.
  3. Een time-out verstrijkt (standaard 8 seconden) zonder enig toestemmingssignaal.

Elk verzoek dat in dat venster wordt afgevuurd, wordt onderzocht op drie signalen:

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:

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:

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:

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:

  1. Laadt helemaal geen third-party tracking totdat toestemming is gegeven. Functionele cookies (sessie, taalvoorkeur, CSRF) zijn prima.
  2. 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.
  3. 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.

Sample scan

78 / 100

High Risk · 23 trackers · pre-consent tracking: yes

See sample report →

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:

  1. Open de site in een schoon browserprofiel met de devtools open.
  2. Filter het netwerk op "third-party" en herlaad.
  3. Alles wat afvuurt voordat je op een banner-knop klikt, is een kandidaat.
  4. Vind voor elke kandidaat de loader (meestal een script-tag, een tag-manager-trigger of een inline snippet) en koppel deze aan het toestemmingssignaal.
  5. 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: