Met de release van iOS 13 en Safari 13 voor MacOS heeft Apple ook Intelligent Tracking Prevention 2.3 uitgerold. Hiermee speelt Apple in op de meest voorkomende workarounds om de gevolgen van ITP 2.2 op te vangen en wordt ook het gebruik van Local Storage beperkt.
Intelligent Tracking Prevention
ITP, oftewel Intelligent Tracking Prevention, is een functie van Webkit, de browser engine die o.a. Apple's Safari aanstuurt. ITP streeft gebruikers te beschermen door de houdbaarheid van cookies te beperken. De eerste versie van ITP kwam uit in 2017 en was in eerste instantie gericht op het beperken van tracking door platformen die gebruikers over meerdere sites konden volgen, zoals bijvoorbeeld Facebook. Om gebruikers over meerdere sites te kunnen volgen werden third-party cookies geplaatst. Het gebruik van deze cookies werd beperkt door de houdbaarheid hiervan in te korten. Het doel hiervan was om cross site tracking te beperken, maar de werking van analytische en functionele cookies in stand te houden.
Om dit te omzeilen gingen advertentieplatformen steeds meer gebruik maken van first-party cookies, in navolging hiervan evolueerde ITP mee en werd ook het gebruik van first-party cookies beperkt. Waar de eerdere versies van ITP met name gevolgen hadden voor ad tracking, worden de gevolgen van ITP op tracking voor analytische doeleinden steeds groter.
ITP 2.2
In ITP 2.2 worden first-party cookies die in de browser geplaatst worden met de document.cookie methode beperkt tot een houdbaarheid van 1 dag wanneer er sprake was van een cross domain tracking mogelijkheden, zoals bijvoorbeeld een query parameter. Hiervoor waren een aantal workarounds beschikbaar, dit zijn de meest gebruikte:
- Gebruik van local storage
- CNAME verwijzing naar advertentieplatform
- HTTP cookie set
- Gebruik van url parameter in refererende url
Wat verandert er in ITP 2.3?
In ITP 2.3 wordt ook het gebruik van alle andere browser opslagmethoden beperkt tot 7 dagen. Denk hierbij aan local storage, wat sinds ITP 2.2 veel gebruikt werd als workaround. Veel tools en partijen vertrouwden op deze oplossing en dit heeft een grote impact op verschillende soorten tooling:
Tracking:
Als er een workaround gebaseerd op local storage gebruikt wordt, kunnen gebruikers nog maximaal 7 dagen herkend worden. Analyse op basis van gebruikers wordt hierdoor minder betrouwbaar. Dit heeft effect op analyses die focussen op meer dan 1 sessie zoals attributie of cross-device analyses. Waar de focus de afgelopen jaren verschoven is van rapporteren op sessie naar rapporteren op gebruiker zal dit stagneren omdat gebruikers simpelweg lastiger te herkennen zijn.
A/B Testing:
Meerdere A/B testing tools maakten al gebruik van local storage, dit gebruik wordt nu beperkt tot 7 dagen. Dit kan leiden tot gebruikers die meerdere varianten te zien krijgen afhankelijk van hoe snel ze terug keren op de pagina en dus wordt analyse en rapportage minder zuiver naarmate een test langer loopt.
Remarketing:
Niet alle conversies zullen meer aan de juiste kanalen gekoppeld kunnen worden indien er meer dan 7 dagen tussen verwijzing en aankoop zitten. Dit zal ertoe leiden dat platformen de ‘missende’ conversies proberen te berekenen om hun aandeel in de journey aan te tonen. Dit leidt ertoe dat de data waarop gerapporteerd zal worden minder compleet en nauwkeurig is en dat er meer met een schatting gewerkt zal worden. Het is niet ondenkbaar dat deze schattingen in het voordeel zullen zijn van het platform.
Houdbaarheid van cookie verlengen met een workaround
Vanuit klanten krijgen we regelmatig de vraag hoe we dit op kunnen lossen. Bij ITP 2.2 kon dit nog relatief eenvoudig met local storage via Javascript in de browser, maar dit wordt nu iets lastiger. ITP heeft nu nog alleen gevolgen voor cookies die geplaatst worden vanuit de browser, cookies die geplaatst worden met de HTTP-set methode worden nog niet beïnvloed. Om de cookie beperking door ITP te omzeilen kan je gebruik maken van deze methode. Hierbij wordt de opdracht om de cookie te plaatsen meegegeven in de header, dan kan je de originele cookie overschrijven en zo de houdbaarheid verlengen. De workaround die we gebruiken maakt simpel gezegd een request naar een cloud webservice en krijgt als respons de gewenste cookie met een verlengde houdbaarheid terug. Om dit artikel enigszins leesbaar te houden zal ik niet ingaan op de technische details, maar mocht je hierin geïnteresseerd zijn, leggen we het je graag uit.
Wat kunnen we verwachten in de verdere ontwikkeling van ITP?
Zoals bij de voorgaande versies van ITP zullen ook hier de advertentieplatformen met workarounds komen. De vraag is hoe lang dit kat- en muisspel door zal blijven gaan en wat er in de toekomst zal gebeuren. Is het nodig dat alle gebruikers koste wat kost gevolgd worden over verschillende platforms en websites, of krijgen we een verschuiving in gebruikers? Waarbij aan de ene kant gebruikers zullen kiezen voor gemak en openheid waarbij ze makkelijk gevolgd kunnen worden. En aan de andere kant gebruikers die kiezen voor meer gesloten platformen waar ze ook minder gevolgd kunnen worden.
De tendens is dat de gebruiker steeds beter begrijpt welke data er van hem verzameld wordt en ook steeds meer beheer krijgt over het verzamelen en gebruik van deze data.
Een vraag die je jezelf en je gebruikers hierbij zou kunnen voorleggen is: waarom willen we deze data opslaan en wat is het gevolg (voordeel) voor de gebruiker hiervan. Als er geen voordeel voor de gebruiker in zit, waarom zouden wij dit dan wél op willen slaan? Naast het gebruik van cookies om gebruikers te kunnen herkennen, kunnen websites ook andere manieren gebruiken om terugkerende bezoekers te herkennen. Voorbeelden hiervan zijn het synchroniseren van gegevens wanneer een gebruiker inlogt. Veel partijen bereiden zich al voor op deze zogenoemde cookieless future waarbij gebruikers veel beter kunnen bepalen wanneer en aan wie ze hun data beschikbaar stellen en waarbij websites duidelijke voordelen moeten bieden aan gebruikers die bereid zijn hun data te delen. Hierbij is het belangrijk om je datastructuur op orde te hebben en worden naast webdata ook andere databronnen zoals app en CRM belangrijker dan ooit.
De toekomst
Uiteindelijk zal het volgen en herkennen van gebruikers waarbij dit niet direct in hun voordeel is, steeds moeilijker worden en zullen er meer beperkingen komen voor traditionele tracking. Stel jezelf hierbij de vraag welke kant je nu al op wilt gaan. Wil je zo lang mogelijk proberen om gebruikers op dezelfde manier te blijven volgen of wil je voorsorteren op andere mogelijkheden en een band met je gebruiker en zijn data opbouwen? Als je de data van je klant of gebruiker nu al relevant weet in te zetten voor zijn eigen voordelen en hiermee waarde kan creëren, hoef je je in de toekomst geen zorgen te maken over de mogelijkheden.
Geschreven door:
Op: November 12, 2019
Ook interessant voor jou:
Met de release van iOS 13 en Safari 13 voor MacOS heeft Apple ook Intelligent Tracking Prevention 2.3 uitgerold. Hiermee speelt Apple in op de meest voorkomende workarounds om de gevolgen van ITP 2.2 op te vangen en wordt ook het gebruik van Local Storage beperkt.
Intelligent Tracking Prevention
ITP, oftewel Intelligent Tracking Prevention, is een functie van Webkit, de browser engine die o.a. Apple's Safari aanstuurt. ITP streeft gebruikers te beschermen door de houdbaarheid van cookies te beperken. De eerste versie van ITP kwam uit in 2017 en was in eerste instantie gericht op het beperken van tracking door platformen die gebruikers over meerdere sites konden volgen, zoals bijvoorbeeld Facebook. Om gebruikers over meerdere sites te kunnen volgen werden third-party cookies geplaatst. Het gebruik van deze cookies werd beperkt door de houdbaarheid hiervan in te korten. Het doel hiervan was om cross site tracking te beperken, maar de werking van analytische en functionele cookies in stand te houden.
Om dit te omzeilen gingen advertentieplatformen steeds meer gebruik maken van first-party cookies, in navolging hiervan evolueerde ITP mee en werd ook het gebruik van first-party cookies beperkt. Waar de eerdere versies van ITP met name gevolgen hadden voor ad tracking, worden de gevolgen van ITP op tracking voor analytische doeleinden steeds groter.
ITP 2.2
In ITP 2.2 worden first-party cookies die in de browser geplaatst worden met de document.cookie methode beperkt tot een houdbaarheid van 1 dag wanneer er sprake was van een cross domain tracking mogelijkheden, zoals bijvoorbeeld een query parameter. Hiervoor waren een aantal workarounds beschikbaar, dit zijn de meest gebruikte:
- Gebruik van local storage
- CNAME verwijzing naar advertentieplatform
- HTTP cookie set
- Gebruik van url parameter in refererende url
Wat verandert er in ITP 2.3?
In ITP 2.3 wordt ook het gebruik van alle andere browser opslagmethoden beperkt tot 7 dagen. Denk hierbij aan local storage, wat sinds ITP 2.2 veel gebruikt werd als workaround. Veel tools en partijen vertrouwden op deze oplossing en dit heeft een grote impact op verschillende soorten tooling:
Tracking:
Als er een workaround gebaseerd op local storage gebruikt wordt, kunnen gebruikers nog maximaal 7 dagen herkend worden. Analyse op basis van gebruikers wordt hierdoor minder betrouwbaar. Dit heeft effect op analyses die focussen op meer dan 1 sessie zoals attributie of cross-device analyses. Waar de focus de afgelopen jaren verschoven is van rapporteren op sessie naar rapporteren op gebruiker zal dit stagneren omdat gebruikers simpelweg lastiger te herkennen zijn.
A/B Testing:
Meerdere A/B testing tools maakten al gebruik van local storage, dit gebruik wordt nu beperkt tot 7 dagen. Dit kan leiden tot gebruikers die meerdere varianten te zien krijgen afhankelijk van hoe snel ze terug keren op de pagina en dus wordt analyse en rapportage minder zuiver naarmate een test langer loopt.
Remarketing:
Niet alle conversies zullen meer aan de juiste kanalen gekoppeld kunnen worden indien er meer dan 7 dagen tussen verwijzing en aankoop zitten. Dit zal ertoe leiden dat platformen de ‘missende’ conversies proberen te berekenen om hun aandeel in de journey aan te tonen. Dit leidt ertoe dat de data waarop gerapporteerd zal worden minder compleet en nauwkeurig is en dat er meer met een schatting gewerkt zal worden. Het is niet ondenkbaar dat deze schattingen in het voordeel zullen zijn van het platform.
Houdbaarheid van cookie verlengen met een workaround
Vanuit klanten krijgen we regelmatig de vraag hoe we dit op kunnen lossen. Bij ITP 2.2 kon dit nog relatief eenvoudig met local storage via Javascript in de browser, maar dit wordt nu iets lastiger. ITP heeft nu nog alleen gevolgen voor cookies die geplaatst worden vanuit de browser, cookies die geplaatst worden met de HTTP-set methode worden nog niet beïnvloed. Om de cookie beperking door ITP te omzeilen kan je gebruik maken van deze methode. Hierbij wordt de opdracht om de cookie te plaatsen meegegeven in de header, dan kan je de originele cookie overschrijven en zo de houdbaarheid verlengen. De workaround die we gebruiken maakt simpel gezegd een request naar een cloud webservice en krijgt als respons de gewenste cookie met een verlengde houdbaarheid terug. Om dit artikel enigszins leesbaar te houden zal ik niet ingaan op de technische details, maar mocht je hierin geïnteresseerd zijn, leggen we het je graag uit.
Wat kunnen we verwachten in de verdere ontwikkeling van ITP?
Zoals bij de voorgaande versies van ITP zullen ook hier de advertentieplatformen met workarounds komen. De vraag is hoe lang dit kat- en muisspel door zal blijven gaan en wat er in de toekomst zal gebeuren. Is het nodig dat alle gebruikers koste wat kost gevolgd worden over verschillende platforms en websites, of krijgen we een verschuiving in gebruikers? Waarbij aan de ene kant gebruikers zullen kiezen voor gemak en openheid waarbij ze makkelijk gevolgd kunnen worden. En aan de andere kant gebruikers die kiezen voor meer gesloten platformen waar ze ook minder gevolgd kunnen worden.
De tendens is dat de gebruiker steeds beter begrijpt welke data er van hem verzameld wordt en ook steeds meer beheer krijgt over het verzamelen en gebruik van deze data.
Een vraag die je jezelf en je gebruikers hierbij zou kunnen voorleggen is: waarom willen we deze data opslaan en wat is het gevolg (voordeel) voor de gebruiker hiervan. Als er geen voordeel voor de gebruiker in zit, waarom zouden wij dit dan wél op willen slaan? Naast het gebruik van cookies om gebruikers te kunnen herkennen, kunnen websites ook andere manieren gebruiken om terugkerende bezoekers te herkennen. Voorbeelden hiervan zijn het synchroniseren van gegevens wanneer een gebruiker inlogt. Veel partijen bereiden zich al voor op deze zogenoemde cookieless future waarbij gebruikers veel beter kunnen bepalen wanneer en aan wie ze hun data beschikbaar stellen en waarbij websites duidelijke voordelen moeten bieden aan gebruikers die bereid zijn hun data te delen. Hierbij is het belangrijk om je datastructuur op orde te hebben en worden naast webdata ook andere databronnen zoals app en CRM belangrijker dan ooit.
De toekomst
Uiteindelijk zal het volgen en herkennen van gebruikers waarbij dit niet direct in hun voordeel is, steeds moeilijker worden en zullen er meer beperkingen komen voor traditionele tracking. Stel jezelf hierbij de vraag welke kant je nu al op wilt gaan. Wil je zo lang mogelijk proberen om gebruikers op dezelfde manier te blijven volgen of wil je voorsorteren op andere mogelijkheden en een band met je gebruiker en zijn data opbouwen? Als je de data van je klant of gebruiker nu al relevant weet in te zetten voor zijn eigen voordelen en hiermee waarde kan creëren, hoef je je in de toekomst geen zorgen te maken over de mogelijkheden.
