De toestemmingsmodus is het mechanisme waarmee uw meet- en advertentietools hun gedrag aanpassen aan wat de bezoeker heeft geaccepteerd. Het opzetten ervan is in Europa een voorwaarde geworden voor toegang tot bepaalde advertentiefuncties, en het wordt vaak half gedaan.
De algemene regels van de cookiebanner zijn elders behandeld. Dit artikel gaat over de technische aansluiting op de meettools.
Het principe
Zonder toestemmingsmodus is uw keuze binair: het meetscript laadt, of het laadt niet.
Met de toestemmingsmodus laadt het script in een beperkte staat zolang de bezoeker niets heeft geaccepteerd. Het schrijft geen cookie, het geeft geen identificator door, en het kan signalen versturen zonder persoonsgegevens.
Twee praktische gevolgen. U houdt een geaggregeerde meting over bezoekers die weigeren. En de overgang van weigering naar acceptatie wordt onmiddellijk verwerkt, zonder herladen.
Niet te verwarren: dit mechanisme ontslaat u niet van toestemming. Het bepaalt wat uw tools doen zolang die er niet is.
De vier signalen
Het geheel rust op vier indicatoren, elk afzonderlijk toegekend of geweigerd.
Twee betreffen de bezoekersmeting: opslag voor analysedoeleinden, en het doorgeven van meetgegevens.
Twee betreffen advertenties: advertentieopslag, en het gebruik van gegevens voor personalisatie of advertentiemeting.
Drie regels bij de uitvoering.
Elk signaal moet overeenkomen met een doel uit uw banner. Biedt uw banner “bezoekersmeting” en “advertenties”, dan is de koppeling eenvoudig. Biedt hij alleen een globale keuze, dan kunt u de signalen niet correct invullen.
Alle signalen moeten worden gedeclareerd, ook die u niet gebruikt. Een ontbrekend signaal geldt als niet ingevuld, en dat is niet hetzelfde als geweigerd.
De standaardstatus is weigering, totdat de bezoeker kiest.
De uitvoeringsvolgorde, het kritieke punt
Dit is de meest voorkomende technische fout en ze stelt het hele mechanisme buiten werking.
De standaardstatus moet worden gedeclareerd vóórdat de meetscripts laden. Laadt het script eerst en komt de status daarna, dan vertrekt de eerste gebeurtenis met de standaardinstellingen van de tool, dus zonder enige beperking.
Concreet is de volgorde: declaratie van de standaardstatus, dan het laden van de tagmanager, dan het bijwerken van de status wanneer de bezoeker kiest.
In PrestaShop betekent dit dat de declaratiecode zeer hoog in de pagina wordt geïnjecteerd, vóór elk ander meetscript. Een toestemmingsmodule die na de tagmanager laadt, kan niet correct werken.
Controle: bekijk de volgorde van de scripts in de broncode van uw homepage. De statusdeclaratie moet aan al het andere voorafgaan.
DataFirefly Cookie Manager: aangedreven door de opensourcemotor tarteaucitron.jsDe cookiebanner die aan de AVG voldoet, zonder de meting op te geven.€220,00
Voorafgaande blokkering blijft nodig
Een veelvoorkomende verwarring die opheldering verdient.
De toestemmingsmodus regelt het gedrag van tools die hem ondersteunen. Hij blokkeert de andere niet.
Uw scripts voor chat, kaarten, ingesloten video, klantbeoordelingen of gedragstests kennen hem niet. Die moeten door uw toestemmingsoplossing worden geblokkeerd, net als voorheen.
De juiste configuratie combineert dus twee mechanismen: voorafgaande blokkering voor alles wat trackers plaatst zonder ondersteuning, en de toestemmingsmodus voor de compatibele tools.
Te vermijden fout: denken dat het opzetten van de toestemmingsmodus de blokkering overbodig maakt. Ze dekt maar een deel van uw pagina.
Bijwerken op het moment van de keuze
Drie implementatiepunten.
Het bijwerken moet onmiddellijk gebeuren, zonder de pagina te herladen. Een bezoeker die accepteert, moet de volledige meting op zijn lopende sessie zien activeren.
Het moet de keuze per doel weergeven, niet één globaal akkoord toepassen. Een bezoeker die meting accepteert en advertenties weigert, moet twee toegekende en twee geweigerde signalen opleveren.
De keuze moet worden onthouden en bij elk bezoek opnieuw worden toegepast, tot ze verloopt.
Aanvullend punt: het intrekken van toestemming moet de signalen eveneens bijwerken, de andere kant op. Een oplossing die alleen acceptatie verwerkt, is onvolledig.
Wat u meet bij weigering
Een terechte vraag, en het antwoord verdient nuance.
In beperkte staat kunnen de tools signalen doorgeven zonder identificator of cookie. Die signalen maken een schatting van het gedrag van weigerende bezoekers mogelijk, via modellering.
Drie eerlijke preciseringen.
Die schatting is een modellering, geen meting. Ze levert ordegroottes op, geen exacte cijfers.
Ze veronderstelt voldoende volume aan waargenomen gegevens om berekend te kunnen worden. Bij een kleine webshop kan ze uitblijven.
Ze herstelt niet wat de weigering heeft weggenomen. Ze verzacht het verlies, ze heft het niet op.
Dit mechanisme voorstellen als een manier om “verloren conversies terug te winnen” is een overtrokken lezing die veel rondgaat.
Controleren of het werkt
Vier controles, alle uitvoerbaar in de browser.
Vóór elke keuze opent u de console en bekijkt u de uitgaande verzoeken. De meetaanroepen mogen vertrekken, maar zonder cookie en met de parameters die de beperkte staat aangeven.
Na een weigering controleert u dat er geen enkele meet- of advertentiecookie is geplaatst.
Na een acceptatie controleert u dat de cookies verschijnen en dat de aanroepen de verwachte identificatoren bevatten.
Bij een herhaald bezoek controleert u dat de vorige keuze opnieuw wordt toegepast zonder opnieuw te vragen.
Voeg daar een controle in de meettool zelf aan toe, die doorgaans een rapport toont over de staat van de ontvangen signalen. Daar worden de inconsistenties zichtbaar die de console niet laat zien.
Veelgemaakte fouten
Slechts één signaal ingevuld. Sommige configuraties declareren alleen de analytische opslag en laten de drie andere oningevuld.
De standaardstatus op toegekend. Een ernstige fout: ze komt neer op verzamelen vóór toestemming.
Een globale koppeling. Eén doel “marketing” uit uw banner dat tegelijk op alle vier de signalen wordt gemapt, waarmee de keuze van de bezoeker niet wordt gerespecteerd.
Het mechanisme ontbreekt op bepaalde pagina’s. Het bestelproces of advertentielandingspagina’s ontsnappen soms aan de banner, door een afwijkend paginasjabloon.
Dat laatste geval is het schadelijkst: de pagina’s die het zwaarst wegen in uw meting zijn juist die waar het mechanisme ontbreekt.
De samenhang met server-side verzending
Een punt om af te handelen als u gebeurtenissen vanaf uw server doorstuurt.
Server-side verzending loopt niet via de browser en negeert dus de staat van de signalen, tenzij u die expliciet meegeeft.
Twee gevolgen. Uw serverimplementatie moet de toestemmingsstatus kennen van de bezoeker, wat betekent dat u die opslaat en aan de sessie koppelt.
En ze moet de verzending navenant beperken of blokkeren. Advertentiegegevens vanaf de server doorsturen voor een bezoeker die ze in de browser heeft geweigerd, is een omzeiling, geen optimalisatie.
De Cookie Manager voor PrestaShop zet deze keten op in PrestaShop 8 en 9: declaratie van de standaardstatus vóór elk meetscript, koppeling tussen de doelen van de banner en de vier signalen, onmiddellijke bijwerking bij de keuze en voorafgaande blokkering van externe scripts die dit mechanisme niet ondersteunen.
