Een toestemmingsbanner instellen is goed. Maar om echt compliant te zijn, moet u de keuzes (of afwezigheid van keuzes) van uw bezoekers vertalen in concrete technische acties.
Uw website moet dus anders reageren afhankelijk van de toestemmingsstatus van de gebruiker :
✅ Als de gebruiker toestemming geeft voor een service :
→ U kunt de service laden en de bijbehorende scripts uitvoeren.
❌ Als de gebruiker de service expliciet weigert :
→ De service mag niet worden geladen, en geen gegevens mogen naar deze service worden verzonden.
🕓 Als de gebruiker nog niet met de banner heeft gecommuniceerd (toestemming niet gegeven) :
→ De service moet standaard worden geblokkeerd zolang geen keuze is gemaakt.
Dit voorwaardelijke gedrag wordt toestemmingsafhankelijke logica genoemd. Het zorgt ervoor dat services die aan toestemming onderhevig zijn, alleen worden geactiveerd wanneer ze zijn geautoriseerd, en dat ze in alle andere gevallen geblokkeerd blijven.
In praktijk kan deze logica op twee manieren worden geïmplementeerd :
handmatig in de code van uw website, door voorwaarden te schrijven (bijvoorbeeld: "als de gebruiker akkoord is gegaan met deze service, laad dan dit script") ;
of via een visuele interface zoals die van een tag manager, waarmee u deze regels zonder codering kunt definiëren. De tag manager vertaalt deze regels vervolgens in uitvoerbare logica aan de browserzijde.
Hoe worden services op uw website aangeroepen?
Hoe worden services op uw website aangeroepen?
Voor elke service die u heeft opgesomd, is het belangrijk om te verifiëren hoe deze op uw website wordt geladen. Er zijn verschillende manieren om een externe service te integreren, maar in de meeste gevallen zijn er twee belangrijke benaderingen :
Het script is rechtstreeks in de code van uw pagina's geïntegreerd ("hardcoded"), vaak gekopieerd uit de documentatie van de betreffende service.
De service wordt via een Tag Manager geladen (zoals Google Tag Manager), door de code in een aangepaste HTML-tag te plakken of door een taaktemplate van de service te gebruiken.
In sommige gevallen kunt u ook tegen het volgende aanlopen :
CMS-plugins (WordPress, Shopify...) die automatisch externe services integreren,
iframes (bijv.: YouTube, Google Maps),
of dynamische aanroepen ingevoegd via JavaScript-frameworks.
Andere gevallen kunnen voorkomen, zoals services geladen via CMS-plugins, iframes of dynamisch geïnjecteerde scripts, maar deze twee methoden dekken de meeste gevallen.
Onze aanbeveling: centraliseer uw scripts in uw Tag Manager
Onze aanbeveling: centraliseer uw scripts in uw Tag Manager
Als u al Google Tag Manager (of een ander tag manager) gebruikt, raden wij u sterk aan om alle services erin te centraliseren. Hier is waarom :
U hebt een uniform overzicht van alle externe services die u laadt,
U kunt toestemmingsafhankelijke logica gemakkelijk beheren dankzij het triggersysteem van GTM,
En vooral voorkomt u dat u de code van uw website moet wijzigen, wat ingewikkeld kan zijn als u niet vertrouwd bent met ontwikkeling.
👉 In praktijk, voor elk script dat u hardcoded op uw pagina's hebt gevonden, maakt u een tag in GTM om het te vervangen, en verwijdert u vervolgens de hardcoded code van de site. Hierdoor kunt u alles proper beheren vanuit GTM, inclusief de activering op basis van Axeptio-toestemming.
En als u geen Tag Manager gebruikt?
En als u geen Tag Manager gebruikt?
Als u uw services rechtstreeks in de code van uw website hebt geïntegreerd en u geen Tag Manager gebruikt, kunt u de toestemmingsafhankelijke logica nog steeds hardcoded beheren. U vindt code-voorbeelden om u te helpen deze logica te ontwikkelen in ons speciale artikel.
Dit impliceert :
de Axeptio-toesteммingsstatus in de gaten houden,
en de externe scripts alleen uitvoeren zodra toestemming is gegeven.
Dit is een meer technische oplossing, die ontwikkelingsresources vereist, maar die nauwkeurige controle over het gedrag van de website mogelijk maakt.
Onthouden: het enkel weergeven van een toestemmingsbanner is niet voldoende. Als u deze toestemmingsafhankelijke logica niet implementeert, kunnen uw bezoekers een service weigeren... die toch op de achtergrond blijft laden.
Om compliant te zijn, moeten services worden geblokkeerd totdat de gebruiker toestemming heeft gegeven, en mogen ze alleen worden geactiveerd als hij dit heeft gedaan.
🧪 Concreet voorbeeld: de activering van een Facebook Pixel aan toestemming onderhevig maken
Ter illustratie van deze toestemmingsafhankelijke logica nemen we een concreet geval dat u tegen zou kunnen komen.
De service en de status ervan identificeren
U hebt uw website gescand met Shake, en het PDF-rapport geeft aan dat een Facebook Pixel op bepaalde pagina's aanwezig is.
➡️ Deze service is opgesomd als verzamelaar van persoonlijke gegevens. Deze moet dus aan toestemming onderhevig zijn.
Verifieer hoe de service is geïntegreerd
U stelt jezelf nu de volgende vraag :
👉 Hoe wordt de Facebook Pixel op mijn website geladen?
Ter verificatie merkt u op dat :
De Pixel niet rechtstreeks in de code van uw pagina's is geïntegreerd,
De Pixel wordt via Google Tag Manager geladen, in de vorm van een aangepaste HTML-tag of via de Facebook Pixel-taaktemplate die in GTM wordt aangeboden.
Onderhevig maken van de activering aan toestemming in GTM
Omdat u GTM gebruikt, kunt u de activering van de Facebook Pixel-tag onderhevig maken aan de Axeptio-toesteммingsstatus.
Resultaat: de Facebook Pixel wordt alleen geactiveerd als de gebruiker toestemming heeft gegeven voor deze service via de Axeptio-banner.
Als de gebruiker weigert, of als hij niet reageert, wordt de Pixel niet geactiveerd.
💡 En als het script hardcoded was?
In dat geval had u een voorwaarde in uw code moeten toevoegen om de toesteммingsstatus in de gaten te houden en het Facebook-script alleen uit te voeren in geval van uitdrukkelijke toestemming.