Scripts blokkeren tot toestemming is gegeven: drie methoden vergeleken

Het probleem: tags die te vroeg afgaan

Een toestemmingsbanner werkt alleen als de tags erachter de keuze van de bezoeker respecteren. De meest voorkomende fout is eenvoudig: de banner verschijnt, maar analytics- en advertentiescripts zijn al geladen en hebben identifiers geplaatst voordat iemand ergens op klikte. Dat verhelpen betekent scripts blokkeren tot toestemming is gegeven. Daarvoor zijn drie praktische manieren.

Methode 1: het scripttype herschrijven

Browsers voeren een script-element alleen uit als het type een JavaScript-type is. Als je het type wijzigt in text/plain, negeert de browser het script. Daarna voeg je een data-attribuut toe dat vastlegt bij welke toestemmingscategorie het script hoort:

Goed voor: een handvol bekende inline of externe scripts in je templates. Let op: scripts die door andere scripts worden ingevoegd, komen nooit door je templates en worden dus nooit herschreven.

Methode 2: tags afschermen in een tag manager

Als je tags in Google Tag Manager of een vergelijkbaar hulpmiddel staan, kun je de container op de pagina laten staan en het afgaan sturen met toestemmingsbewuste triggers. Elke tag krijgt een toestemmingsvereiste, en de tag manager laat hem alleen afgaan wanneer de bijbehorende toestemmingsstatus is verleend. Het grote voordeel is centrale controle: marketing kan tags toevoegen zonder templates aan te raken, en de regel reist mee met de tag.

Goed voor: sites met veel marketingtags. Let op: hardgecodeerde scripts buiten de container en aangepaste HTML-tags die zelf weer extra scripts laden.

Methode 3: scripts dynamisch laden bij toestemming

Hier haal je de script-tags helemaal van de pagina en schrijf je een functie die ze pas na een toestemmingsgebeurtenis invoegt. Dit is de schoonste optie voor single-page-applicaties en voor ontwikkelaars die volledige controle willen:

  1. Luister naar de toestemmingscallback van je CMP.
  2. Controleer welke categorieën zijn verleend.
  3. Maak een script-element, stel de bron in en voeg het toe aan het document.
  4. Voer eventuele initialisatiecode uit in de load-handler van het script.

Goed voor: moderne applicaties met een buildstap. Let op: het vergeten van de terugkerende bezoeker, wiens opgeslagen keuze het laden bij het openen van de pagina moet starten zonder nieuwe klik.

Intrekking afhandelen

Blokkeren vóór toestemming is maar het halve werk. Als een bezoeker later toestemming intrekt, stop dan met het aanroepen van de tools en zorg dat ze geen identifiers blijven lezen of schrijven. Een script van de pagina halen verwijdert geen code die al in het geheugen zit, dus een herlaadbeurt na intrekking is vaak de eenvoudigste betrouwbare aanpak.

Welke moet je kiezen?

Zo test je het

  1. Open een privévenster met gewiste cache.
  2. Open de ontwikkelaarstools van de browser op de tabs Network en Application voordat je de pagina laadt.
  3. Laad de pagina en blijf van de banner af. Controleer dat er geen analytics- of advertentieverzoeken worden verstuurd en dat er geen bijbehorende cookies of opslagitems verschijnen.
  4. Accepteer slechts één categorie en controleer dat alleen de bijbehorende scripts laden.
  5. Weiger alles, herlaad en herhaal de eerste controle.
  6. Trek de toestemming in en controleer het hierboven beschreven gedrag.

Waar FlexyConsent past

FlexyConsent ondersteunt IAB TCF 2.4 en Google Consent Mode v2 en is een door Google gecertificeerde CMP (CMP ID 317). Welke blokkeermethode je ook kiest, de taak van de banner is je code een duidelijk signaal te geven van wat de bezoeker heeft gekozen. Jouw taak is ervoor te zorgen dat elk script dat opvolgt.

Belangrijkste punten

← Blog Alles lezen →