Het configureren van een consentmentbanner is goed. Maar om werkelijk compliant te zijn, moet u de keuzes (of afwezigheid van keuzes) van uw bezoekers vertalen in concrete technische acties.
Uw site 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 interactie gehad (toestemming niet gegeven) :
→ De service moet standaard worden geblokkeerd totdat er een keuze is gemaakt.
Dit voorwaardelijke gedrag wordt toestemmingsafhankelijke logica genoemd. Dit garandeert dat services die aan toestemming onderhevig zijn alleen worden geactiveerd wanneer ze zijn geautoriseerd, en dat ze in alle andere gevallen geblokkeerd blijven.
Concreet kan deze logica op twee manieren worden geïmplementeerd :
hetzij handmatig in de code van uw site, door voorwaarden te schrijven (bijvoorbeeld: "als de gebruiker aan deze service heeft ingestemd, laad dan dit script") ;
hetzij via een visuele interface zoals die van een tag manager, waarmee u deze regels kunt definiëren zonder te coderen. De tag manager vertaalt deze regels vervolgens in uitvoerbare logica aan de browserzijde.
Hoe worden services op uw site aangeroepen?
Hoe worden services op uw site aangeroepen?
Voor elke service die u hebt opgesomd, is het belangrijk om te controleren hoe deze op uw site wordt geladen. Er zijn verschillende manieren om een externe service te integreren, maar in de meeste gevallen komen we twee grote benaderingen tegen :
Het script is rechtstreeks in de code van uw pagina's ingebed ("hardgecodeerd"), meestal gekopieerd uit de documentatie van de betreffende service.
De service wordt geladen via een Tag Manager (zoals Google Tag Manager), ofwel door de code in een aangepaste HTML-tag te plakken, ofwel door een tagsjabloon van de service te gebruiken.
In sommige gevallen kunt u ook tegenkomen :
CMS-plugins (WordPress, Shopify…) die automatisch externe services integreren,
iframes (bijv.: YouTube, Google Maps),
of dynamische aanroepen via JavaScript-frameworks.
Andere gevallen kunnen voorkomen, zoals services die via CMS-plugins, iframes of dynamisch geïnjecteerde scripts worden geladen, maar deze twee methoden dekken het merendeel van de gevallen.
Onze aanbeveling: centraliseer uw scripts in uw Tag Manager
Onze aanbeveling: centraliseer uw scripts in uw Tag Manager
Als u reeds Google Tag Manager (of een ander tag manager) gebruikt, raden wij u sterk aan om al uw services daarin te centraliseren. Hier is waarom :
U hebt een geïntegreerd overzicht van alle externe services die u laadt,
U kunt toestemmingsafhankelijke verwerking eenvoudig beheren dankzij het triggersysteem van GTM,
En vooral: u vermijdt het wijzigen van de code van uw site, wat complex kan zijn als u niet vertrouwd bent met ontwikkeling.
👉 Concreet, maak voor elk script dat u hardgecodeerd op uw pagina's hebt gevonden een tag in GTM aan om dit te vervangen, en verwijder vervolgens de hardgecodeerde code van de site. Dit stelt u in staat om alles netjes van GTM uit te beheren, 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 site hebt geïntegreerd en geen Tag Manager gebruikt, kunt u de voorwaardelijke logica nog steeds hardcoderen. U vindt codefragmenten om u te helpen deze logica te ontwikkelen in ons speciale artikel.
Dit omvat :
luisteren naar de status van Axeptio-toestemming,
en externe scripts alleen uitvoeren nadat toestemming is gegeven.
Dit is een meer technische oplossing die ontwikkelingsbronnen vereist, maar die gedetailleerde controle over het gedrag van de site mogelijk maakt.
Onthoud: het eenvoudig weergeven van een consentmentbanner is niet voldoende. Als u deze voorwaardelijke logica niet implementeert, kunnen uw bezoekers een service weigeren… die toch onder de motorkap blijft laden. Om compliant te zijn, moeten services worden geblokkeerd totdat de gebruiker toestemming heeft gegeven, en mogen ze alleen worden geactiveerd als dat het geval is.
🧪 Concreet voorbeeld: het activeren van een Facebook-pixel aan toestemming koppelen
Om deze voorwaardelijke logica te illustreren, nemen we een concreet geval dat u kunt 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 op bepaalde pagina's aanwezig is.
➡️ Deze service is niet strikt noodzakelijk voor de werking van de site en slaat informatie op op het apparaat van de bezoeker. Het moet daarom aan toestemming onderhevig zijn.
Controleer hoe de service is geïntegreerd
U stelt zich nu de volgende vraag :
👉 Hoe wordt de Facebook-pixel op mijn site geladen?
Na controle stelt u vast dat :
De pixel niet rechtstreeks in de code van uw pagina's is ingebed,
Het via Google Tag Manager wordt geladen, als een aangepaste HTML-tag of via het Facebook-tagsjabloon dat in GTM wordt aangeboden.
Maak de activering voorwaardelijk in GTM
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 toestemming voor deze service heeft gegeven via de Axeptio-banner.
Als de gebruiker weigert, of niet reageert, wordt de pixel niet geactiveerd.
💡 En als het script hardgecodeerd was?
In dat geval zou u hebben moeten een voorwaarde in uw code toevoegen om naar de toestemmingsstatus te luisteren en het Facebook-script alleen in geval van expliciete toestemming te activeren.