Intelligent Tracking Prevention (ITP) gaat de komende tijd de markt van analytics net zo beheersen als eerder de cookiewall en de GDPR hebben gedaan. Managers kloppen bij analisten aan omdat ze zich druk maken over hun metingen, terwijl CRO experts zich afvragen hoe ze in hemelsnaam nog attributie rapportages kunnen maken of A/B-testen goed kunnen uitvoeren.
Inmiddels worden we na versie 1.0 en 2.1 nu alweer geconfronteerd met ITP versie 2.2, en daar zal het volgens ons niet bij blijven. De hoogste tijd dus om eens goed stil te staan bij deze ontwikkeling, de gevolgen ervan en de slimste manier om met deze gevolgen om te gaan.
Waar komt ITP vandaan?
De aankomende veranderingen zijn allemaal afkomstig van de WebKit developers community (de motor achter de Safari browser), maar ook Google heeft recent aangekondigd grote stappen te gaan maken. De reden dat ze dit doen: het tegengaan van cross domain tracking.
Cross domain tracking is een methode die partijen zoals Facebook en advertising networks (bv. Google Doubleclick) in staat stelt om de stappen die jij online zet eenvoudig overal te volgen om vervolgens je gedragsdata te verkopen aan de hoogste bieder. Hierdoor is het o.a. mogelijk om voor jou ‘relevante’ advertenties te tonen op basis van je online gedrag.
Al deze systemen maken gebruik van cookies om jou als gebruiker op verschillende plekken en op verschillende momenten te kunnen identificeren. In de meeste gevallen worden deze cookies door een extern script (Javascript library) via document.cookie geplaatst in jouw browser. Zo kun je aan de hand van deze cookie herkend worden wanneer je bijvoorbeeld binnen een bepaalde periode terugkeert naar een website.
Met de nieuwe updates die er aankomen wordt cross domain tracking (en vergelijkbare praktijken) steeds meer tegengegaan. Met als gevolg dat ook analytics en A/B-test systemen bezoekers steeds minder goed kunnen herkennen zolang ze nog steeds van document.cookie gebruik maken.
ITP historie, werking en gevolgen
ITP is niet nieuw. Versie 1.0 is ingegaan in juni 2017 waarbij de focus voornamelijk lag op het tegengaan van 3rd party cookies (de meeste analytics en A/B-test software werken met 1st party cookies). Maar sinds Versie 2.1 zijn er nieuwe regels rondom 1st party cookies, met name wanneer het client side cookies zijn.
Zo heeft versie 2.1 ervoor gezorgd dat wanneer een extern script een cookie als 1st party cookie plaatst (en dat is altijd het geval bij client side cookies), dan wordt de cookie na zeven dagen inactiviteit (in de browser) van de gebruiker op de website verwijderd.
Sinds één tot twee maanden kan je dus in elk analytics en A/B-test software pakket Safari gebruikers niet meer herkennen als terugkerende bezoeker zodra ze meer dan 7 dagen niet actief zijn geweest in de browser.
Gelukkig heeft deze versie niet veel problemen veroorzaakt voor A/B-testen en ook binnen onze analytics werkzaamheden waren de gevolgen te overzien.
Wat is ITP 2.2?
Maar met de komst van ITP 2.2 (nu nog in bèta) wordt de tijd dat je een client-side cookie kunt herkennen op maximaal 24 uur gezet! Dit limiet geldt overigens niet voor iedereen, er zijn een aantal voorwaarden waar het domein aan moet voldoen:
“As of ITP 2.2, persistent cookies set through document.cookie are capped to one day of storage when both of the following conditions are met:
- A domain classified with cross-site tracking capabilities was responsible for navigating the user to the current webpage.
- The final URL of the navigation mentioned above has a query string and/or a fragment identifier.”
Dus, wanneer je domein door de machine learning engine van Webkit geclassificeerd is als een domein met cross domain tracking mogelijkheden en je daarnaast gebruik maakt van query parameters, dan worden client side cookies niet langer dan 24 uur opgeslagen.
De gevolgen van ITP 2.2 voor A/B-testen
Voor A/B-testen heeft dit als gevolg dat Safari gebruikers relatief vaker zowel variant A als B te zien kunnen krijgen (wat weer negatieve gevolgen heeft voor de betrouwbaarheid van je A/B-test resultaten). Je bent namelijk niet meer in staat om bij te houden welke variant de gebruiker te zien kreeg bij een eerder bezoek.
Een probleem dat overigens niet onbekend is in de conversie optimalisatie wereld, want ook zonder ITP 2.2 maken mensen gebruik van meerdere apparaten en kunnen cookies verwijderd worden. Maar met de komst van ITP 2.2 zal deze vervuiling van je testresultaten voor Safari gebruikers enorm toenemen. Daarnaast zal het niet lang meer duren voordat ook andere browsers hierin meegaan.
Wat kunnen we verwachten in de toekomst?
Waarschijnlijk zal niet iedereen onder de voorwaarden van ITP 2.2 de 24 uurs grens opgelegd krijgen, maar de koers lijkt duidelijk. De enige manier om nu en in de toekomst je bezoekers goed te herkennen is door het plaatsen van cookies vanaf je eigen webserver en niet via een extern (java)script.
Er zijn natuurlijk tijdelijke oplossingen (bv. local storage) om cross domain tracking toch mogelijk te maken, maar ook die mogelijkheden zullen in de nabije toekomst afgesloten worden. Het zal niet lang meer duren voordat ze ITP 2.3, 2.4, 3.0 etc introduceren.
Om nu al rekening te houden met toekomstige ITP versies moeten Analytics en A/B-test software de optie inbouwen om via de webserver cookies te plaatsen en te lezen. Helaas zijn veel A/B test software ontwikkelaars nog niet zo ver, dus is er een workaround nodig.
De oplossing
Organisaties die gebruik maken van analytics en A/B-test resultaten om inzicht te krijgen in het gedrag van hun klant zullen (net zoals als ons) aan de slag moeten om oplossingen te verzinnen voor tools als Adobe Analytics, Google Analytics, testen in GTM, Optimizely, VWO enz.
Wij zijn in ieder geval al hard aan het werk om verschillende oplossingen uit te werken. Hoe we met dit soort veranderingen om moeten gaan leren we alleen door er meters in te maken en het zo snel mogelijk op te pakken. Net als eerdere ontwikkelingen (SSL en GDPR) in het digitale werkveld zullen we ook deze tackelen.