Een toestemmingsbanner configureren is goed. Maar om echt compliant te zijn, moet u de keuzes (of het gebrek aan keuzes) van uw bezoekers vertalen in concrete technische acties.
Uw site moet dus anders reageren afhankelijk van de toesteemmingsstatus 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 interactief gewerkt (toestemming niet gegeven) :
→ Standaard moet de service worden geblokkeerd totdat een keuze is gemaakt.
Dit voorwaardelijke gedrag wordt toestemmingslogica genoemd. Het zorgt ervoor dat services die aan toestemming zijn onderworpen alleen worden geactiveerd wanneer zij zijn geautoriseerd, en in alle andere gevallen geblokkeerd blijven.
Concreet kan deze logica op twee manieren worden geïmplementeerd :
handmatig in de code van uw site, door voorwaarden in te stellen (bijvoorbeeld: "als de gebruiker aan deze service heeft ingestemd, laad dit script dan") ;
of via een visuele interface zoals die van een tag manager, waarmee u deze regels kunt definiëren zonder te coderen. De tag manager zet deze regels vervolgens om in uitvoerbare logica aan de browserkant.
Hoe worden services op uw site aangeroepen?
Hoe worden services op uw site aangeroepen?
Voor elke service die u heeft opgesomd, is het belangrijk om te controleren hoe deze op uw site wordt geladen. Er zijn verschillende manieren om een service van derden te integreren, maar in de meeste gevallen zijn er twee grote benaderingen:
Het script is rechtstreeks in de code van uw pagina's geïntegreerd ("hardcoded"), vaak gekopieerd uit de documentatie van de betrokken service.
De service wordt via een Tag Manager geladen (zoals Google Tag Manager), ofwel door de code in een aangepaste HTML-tag te plakken, ofwel door het tagsjabloon te gebruiken dat de service in GTM biedt.
In bepaalde gevallen kunt u ook tegenkomen:
CMS-plugins (WordPress, Shopify…) die automatisch services van derden integreren,
iframes (bijv. YouTube, Google Maps),
of dynamische aanroepen ingevoegd via JavaScript-frameworks.
Er kunnen andere gevallen bestaan, zoals services die via CMS-plugins, iframes of dynamisch ingevoegde scripts worden geladen, 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, adviseren wij u stellig om al uw services daarin te centraliseren. Hier is waarom:
U hebt een geïntegreerd overzicht van alle services van derden die u laadt,
U kunt de toestemmingslogica eenvoudig beheren dankzij het trigger-systeem van GTM,
En het allerbelangrijkste is dat u de code van uw site niet hoeft aan te passen, wat lastig kan zijn als u niet comfortabel bent met webontwikkeling.
👉 Concreet, maak voor elk script dat u hardcoded op uw pagina's hebt gevonden een tag in GTM om het te vervangen, en verwijder vervolgens de hardcoded code van de site. Hierdoor kunt u alles netjes vanuit GTM beheren, inclusief 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 site hebt geïntegreerd en geen Tag Manager gebruikt, kunt u de toestemmingslogica toch beheren. U vindt codefragmenten om u te helpen deze logica te ontwikkelen in ons speciale artikel.
Dit omvat:
luisteren naar de Axeptio-toestemmingsstatus,
en scripts van derden alleen uitvoeren nadat toestemming is gegeven.
Dit is een meer technische oplossing die webontwikkelingsbronnen vereist, maar die verfijnd beheer van het sitegedrag mogelijk maakt.
Onthoud: het simpelweg weergeven van een toestemmingsbanner is niet voldoende. Als u deze toestemmingslogica niet implementeert, kunnen uw bezoekers een service weigeren… die echter toch op de achtergrond wordt geladen.
Om compliant te zijn, moeten services worden geblokkeerd totdat de gebruiker zijn toestemming heeft gegeven, en moeten zij alleen worden geactiveerd als hij dit heeft gedaan.
🧪 Concreet voorbeeld: het activeren van een Facebook Pixel voorwaardelijk maken
Om deze toestemmingslogica te illustreren, nemen we een concreet geval dat u zou kunnen tegenkomen.
De service en de status ervan identificeren
U hebt uw site gescand met Shake, en het PDF-rapport geeft aan dat een Facebook Pixel aanwezig is op bepaalde pagina's.
➡️ Deze service is vermeld als het verzamelen van persoonlijke gegevens. Het moet dus aan toestemming zijn onderworpen.
Controleren hoe de service is geïntegreerd
U stelt jezelf nu de volgende vraag:
👉 Hoe wordt de Facebook Pixel op mijn site geladen?
Bij controle ziet u dat:
De Pixel niet rechtstreeks in de code van uw pagina's is geïntegreerd,
Deze wordt via Google Tag Manager geladen, in de vorm van een aangepaste HTML-tag of via het tagsjabloon van Facebook dat in GTM wordt aangeboden.
De activering in GTM voorwaardelijk maken
Omdat u GTM gebruikt, kunt u de activering van de Facebook Pixel-tag voorwaardelijk maken op basis van de Axeptio-toestemmingsstatus.
Resultaat: de Facebook Pixel wordt alleen geactiveerd als de gebruiker via de Axeptio-banner toestemming aan deze service heeft gegeven.
Als de gebruiker weigert of niet reageert, wordt de Pixel niet geactiveerd.
💡 En als het script hardcoded was?
In dat geval zou u een voorwaarde in uw code moeten toevoegen om de toestemmingsstatus te volgen en het Facebook-script alleen uit te voeren in geval van expliciete instemming.