We bieden in Squeezely verschillende geavanceerde opties aan om permissies te verwerken zodat je dit naar eigen wens kan inrichten. Praktisch gezien maken we het onderscheid tussen:
- Toestemming voor verwerken van eventdata, dit door middel van cookies. (“Custom pixel consent management enabled” setting)
- Toestemming voor emails te versturen, dit door middel van profielattributen.
Op deze pagina lichten we voor beide toestemmingsniveaus alle technische mogelijkheden toe. Let op: wij kunnen niet adviseren over welke optie je het beste neemt en wat wel of niet is toegestaan, alleen over de technische implementatie. Wel hebben we een voorbeeldsituatie met praktische uitwerking voor beide types permissies.
Situatie: Een klant geeft zijn e-mailadres op en je wilt een welkomsmail versturen.
Scenario 1: Merchant gebruikt geen cookie- of emailpermissie
Oplossing: Je verstuurt alleen het emailattribuut zonder meer, in de journey geef je geen required consent op.
Event | Journey | |
---|---|---|
|
Scenario 2: Merchant gebruikt alleen emailpermissie
Oplossing: Je verstuurt naast het emailadres, ook de consent die je zelf aanspreekt in de journey.
Event | Journey | |
---|---|---|
|
Scenario 3: Merchant gebruikt email en cookiepermissie
Oplossing: Je verstuurt hetzelfde event, maar je stuurt op elke pagina een extra consent event wat aangeeft welke data wel / niet verwerkt mag worden. Dit consent event wordt getriggerd door je eigen cookiebar en welke optie de gebruiker daar selecteert. Veel cookiebar systemen, zoals Cookiebot, zijn eenvoudig combineerbaar met ons permissiesysteem.
Event | Journey | ||
---|---|---|---|
|
Verstuur je het eerste event zonder het tweede, wordt het in een queue geplaatst en pas verwerkt zodra we het consent event ontvangen. Let op: de queue verdwijnt bij een nieuwe pageload.
Dit is een lijst van alle cookies die Squeezely first-party bewaart op je website. Voor die cookies die met gemarkeerd zijn, kan het van toegevoegde waarde zijn om deze server-side langs jouw kant te overschrijven. Dit om mogelijk dataverlies door ITP restricties te vermijden. Zie het ITP artikel voor meer informatie.
Cookie naam | Functie | Zet server side? |
---|---|---|
sqzllocal | Het unieke ID van de bezoeker waarmee we hem in Squeezely identificeren. | |
sqzl_vw | Informatie over welke personalisatie wanneer is gezien door de bezoeker. |
|
sqzl_disable_personalization_<id> | Houdt bij wanneer gebruikers expliciet personalisaties wegklikken. |
|
sqzl_session_id | Elke sessie van de gebruiker krijgt een uniek ID voor onderscheid. |
|
sqzl_abs | Of de gebruiker wel of geen ad-block gebruikt. |
|
sqzl_consent | Bij gebruiken van multi level consent: welke consent de user heeft gegeven. |
|
Toestemming voor Analytics en Marketing cookies wordt bij deze instelling afgehandeld door de Squeezely tracker. Dit betekent dat elke keer als een pagina inlaadt je de Squeezely tracker moet meegeven of de bezoeker toestemming heeft gegeven om cookies te bewaren. Bijvoorbeeld: wanneer een bezoeker voor het eerst je site bezoekt, moet hij toestemming geven voor cookies. Zolang hij dit niet doet, zal Squeezely (op diezelfde pagina) de events in een wachtrij zetten tot er toestemming is gegeven. Zodra dat het geval is, stuur je grant door zoals in onderstaande voorbeelden.
Om dit in te stellen ga je naar settings -> consent management en vink je custom pixel consent management aan.
Simpele toestemming is de “alles of niets” optie. Hierbij stuur je slechts “grant” of “revoke” door, dit zorgt ervoor dat je zowel statistieken bijhoudt als third party tracking doet. Als je revoke doet, wordt er voor die bezoeker niets opgeslagen en zullen er vanuit Squeezely ook geen third party events worden verstuurd.
|
of
_sqzl.push({ "consent": "revoke" }); |
Je kan ook ervoor kiezen om een onderscheid te maken tussen analytics en/of marketing cookies. Dit zou je dan in je cookiebanner expliciet vragen en aan de hand van de gekozen opties, stuur je een variant van onderstaande code door.
|
Je kan ook revoke doorsturen bij een wijziging van de bezoeker zijn instellingen:
|
Naast het gedrag in de browser, hebben we standaard ook ondersteuning voor drie verschillende toestemmingsniveaus wat er met een bezoeker zijn emailadres mag gebeuren. Onderstaand leggen we deze uit.
Naam | Functie | Attribuutwaarde |
---|---|---|
Marketing | Toestemming voor delen met derde partijen zoals Google en FB. | marketing |
Nieuwsbrief | Toestemming voor het versturen van een nieuwsbrief. | newsletter |
Service berichten | Toestemming voor het versturen van essentiële service emails. | service |
Voor de meeste koppelingen syncen we de nieuwsbrief waarde met hun equivalent van het nieuwsbrief attribuut, maar bij bepaalde koppelingen kan je via de instellingen de mapping wijzigen. Je bepaalt zelf adhv de regels van de gesyncte audiences welke profielen gesynct worden, dit limiteren we niet standaard vanuit onze kant.
Enige uitzondering is wanneer je de custom consent management setting geactiveerd hebt, in dat geval is de marketing consent vereist voor email exports naar Google en Facebook (dus wanneer de “email export” optie in de audience aangevinkt is). |
Email toestemming bewaren werkt anders dan bovenstaande toestemming: hierbij wordt het op het profiel bewaard. Dit betekent dat je het maar eenmalig moet doorsturen tenzij er een wijziging in toestemming is. Hiervoor kan je het onderstaand EmailOptin event gebruiken. (je kan een “yes” permissie ook met andere events meesturen zoals purchase bv, maar een “no” permissie kan alleen met dit event).
|