Intelligent Tracking Prevention 2.1 og Google Analytics
Apple har annonceret version 2.1 af Intelligent Tracking Prevention (ITP). ITP er indbygget i Safari-browseren og er kort sagt et værktøj, der beskytter brugerens privatliv. Det gør ITP ved at sætte restriktioner på cookies - især tredjeparts-cookies.
Tredjeparts-cookies er generelt meget udskældte - og med rette. Det er fx dem, som Facebook bl.a. anvender til at tracke en person på tværs af nettet. Men generelt har stort set alle annoncenetværk brugt dem til tracking og traditionelt og generelt har de gjort det uden samtykke.
Facebook - for eksempel, for de er langt fra de eneste - har dog skiftet over til at bruge førsteparts-cookies. Men det har ikke afholdt dem fra at fortsætte deres praksis med den såkaldte cross site tracking.
Det er bl.a. den praksis, som ITP 2.1 adresserer nu ved at lægge nogle skrappe restriktioner på førsteparts-cookies. Og det har betydning for dine Google Analytics-data!
Din trafik kommer nok til at stige
Det er første gang, at en ITP-opdatering påvirker indsamling af data i Google Analytics i et så alvorligt omfang.
Sagen er nemlig, at ITP 2.1 nu sætter en begrænsning på alle førsteparts-cookies, der betyder, at de slettes automatisk efter blot 7 dage.
Oversat til Analytics-sprog betyder det, at en ny bruger ikke vil blive genkendt som en returnerende bruger, hvis den returnerende session sker mere end 7 dage efter første besøg.
Det lyder måske umiddelbart til at leve med. Men for mange vil det betyde en markant stigning i antallet af brugere, en stigning i antallet af nye brugere og fremfor alt en kraftig forringelse af attribution-modeller og tilskrivning af konverteringer til de rigtige kilder (selv ved en last-click attribuering).
Derudover er der mange andre metrics, der vil blive beregnet ud fra et forkert grundlag. Jeg lister dem ikke her (det er ikke formålet med denne post). Men på mange sites vil det altså have relativt store implikationer.
Ændringen gælder i øvrigt kun såkaldte client side cookies (som Analytics fx bruger). De gælder altså ikke HTTP cookies, der sættes af serveren.
A/B testing bliver kompliceret
Hvis du eksekverer A/B-testing på dit website, så er du også i farezonen. Mange værktøjer (fx Visual Website Optimizer og Google Optimize, som er blandt de mest populære) bruger også client side cookies.
De bruger disse cookies til bl.a. at sørge for, at en bruger ser den samme testversion ved returnerende besøg. Forestil dig lige implikationerne for dine testresultater, hvis den samme bruger kan komme til at se forskellige versioner af en test?
Løsningen på den korte bane er måske helt at udelukke Safari-brugere fra A/B-testing. Men det vil i mange tilfælde betyde, at man (i Danmark) udelukker en signifikant mængde af mobiltrafikken.
En bedre løsning kan potentielt være at gå over til server side testing. Dvs., hvor udviklere står for at implementere testversioner samt at identificere og huske de brugere, der skal identificeres overfor en version frem for en anden.
Det er desværre ikke understøttet af Visual Website Optimizer, men kan godt sættes op i fx Google Optimize eller fx Conductrics.
Hvad kan jeg gøre?
For det første skal du finde ud, om det er et problem for dig. Undersøg derfor, hvor mange af dine brugere, der overhovedet anvender Safari. Det gør du i Google Analytics i rapporten Audience → Technology → Browser.
Derefter kan du åbne rapporten Audience → Active Users, hvor du tilføjer/aktiverer et segment, der kun inkluderer brugere med Safari-browseren. Hvis du i denne rapport har langt de fleste (+90%) af dine Safari-brugere i kategorierne 1 Day Active Users eller 7 Day Active Users, så kan du nok trække vejret roligere - dine brugere er nemlig frekvente nok til, at deres cookies bliver fornyet jævnligt.
Hvis du derimod har en del brugere i kategorierne 14 Day Active Users og 28 Day Active Users, så er du på spanden ift. at kunne tracke dine Safari-brugere.
Hvilket i øvrigt er mit gæt, for Apple nævner faktisk ikke noget om, hvorvidt en fornyelse af cookien kan ske. Det går jeg dog ud fra, da det har været tilfældet i tidligere ITP-versioner.
Men nej, du kan reelt ikke gøre noget ved det. Jo, du kan konfiguere Analytics til at bruge localStorage i stedet for cookies. Men localStorage har en masse andre begrænsninger. Det understøttes fx ikke af alle browsere (men dog de fleste). Og du er ikke garanteret, at der er plads (for ja, der er kun et begrænset antal kilobytes tilgængelig i localStorage). Og mere.
Du kan også skifte din implementering fuldstændig over til Measurement Protocol, selv finde på Client IDs og selv sætte HTTP cookies. Det er nok en operation, der er for omkostningstung og praktisk talt umulig for de fleste.
Så reelt er der intet at gøre lige nu. Andet end at være opmærksom.
Hvad skal jeg ikke gøre?
Du skal for alt i verden ikke begynde at juble over din stigende trafik og din pludseligt høje andel af mobile-besøgende, når ITP 2.1 gradvist indfinder sig på markedet. Det vil være fake news.
Du skal ej heller gå ud og købe en anden Analytics-platform. Med mindre den er server side-baseret. Langt de fleste Analytics-platforme (fx Google Analytics, Adobe Analytics, Matomo osv.) bruger nemlig den samme teknologi.
Adobe Analytics bruger dog kun client side cookies som fallback, hvis de ikke kan sætte en server side cookie, som er standard. Matomo kan faktisk også relativt nemt konfigureres til at bruge server side cookies.
Min holdning (lige nu, for den skifter ofte) er, at vi egentlig bare må afvente. Måske finder (Google) Analytics på en anden tracking-metode, måske finder de på at lave et server side SDK eller andet.
Så nu er du advaret :)