Sådan bevarer du nemt dine marketing-cookies i Safari efter ITP 2.1

Del på facebook
Del på twitter
Del på linkedin
sådan bevarer du cookies i safari itp 2

Den 21. februar offentliggjorde Webkit frigivelsen ITP 2.1 (Intelligent Tracking Prevention), også kendt som Apple Intelligent Tracking Prevention (ITP 2.1). Denne frigivelse udrullede i foråret til samtlige Safari-browsere og betyder, at dine cookies kun lever 7 dage i Safari-browseren, men levetiden kan forlænges til det oprindelige.

ITP 2.1 påvirker din analyse og retargeting

ITP 2.1 påvirker din analyse og retargeting kampagner, da bl.a. Google Analytics ikke kan genkende tilbagevendende besøgende efter kun 7 dage. Derefter bliver én tilbagevendende besøgende i stedet betragtet som én ny besøgende, hvilket bl.a. resulterer i, at dit unikke besøgstal stiger i analysen (selvom det ikke er sandheden), og dine retargeting kampagner ikke virker efter perioden – og det koster dig spildte markedsføringskroner.

I vores tilfælde på lindebjergmedier.dk kommer rundt regnet 25% af trafikken via en Safari-browser herunder Mac-computere, iPhones, iPads m.m. Det betyder, at 1/4 af vores data i Google Analytics muligvis ikke taler sandt, og 1/4 af vores retargeting budget ikke præsterer efter hensigten, hvis vi IKKE benytter en løsning til at undgå ITP 2.1. Dine tal stemmer sandsynligvis overens med vores, hvorfor det er uhyr vigtigt, at du får styr på dine cookies hurtigst muligt.

Før ITP 2.1 havde Google Analytics-cookies en standardperiode på 2 år og Facebook-cookies 90 dage, og her er de gode nyheder – du kan genskabe dem ganske enkelt.

Vi er alle sammen selvfølgelig glade for at få flere nye besøgende på vores hjemmeside. Det giver os en indikation af, at vi gør noget rigtigt. Men når stigningen i nye besøgende ikke afspejler den reelle stigning i nye besøgende, giver den en falsk følelse af sikkerhed. Kortlægning af kunderejsen er et vigtigt skridt til forbedring af salg og marketing. Hvis Google Analytics ikke kan genkende en tilbagevendende besøgende, vil kortlægning af hver interaktion med kunden være umulig, og dermed vil kunderejsen blive ødelagt af dårlige data. 

Svar på spørgsmål som

  • Hvilke kampagner så kunden?
  • Hvor længe er den gennemsnitlige kunderejse?
  • Hvor mange og hvilke berøringspunkter har kunderejsen?

vil have ringe værdi og kun afspejle de begrænsede tilgængelige data. Endnu vigtigere er det, hvis dit fremtidige markedsføringsbudget tildeles baseret på disse svar. Du risikerer at tage nogle dårlige beslutninger, som betyder, at du taber penge. Og hvis du desuden ved, at du ikke kan stole på dine data i Google Analytics, vil du begynde at tage beslutninger baseret på mavefornemmelse, hvilket kan være dårligt for virksomheden.

Hvilke Google Analytics ITP-løsninger findes for at eliminere virkningen af ITP 2.1 på dine cookies?

Der findes forskellige metoder til at omgå ITP 2.1, så du igen får nøjagtig indsigt i Google Analytics, og dine retargeting-kampagner præsterer optimalt. Nogle løsninger kræver imidlertid en vis mængde tekniske ændringer og har forskellige fordele og ulemper.

Generelt er der to kategorier af løsninger: lokal-opbevaringsløsninger (local-storage-based) og server-side-løsninger (server-side-solutions). I modsætning til den udbredte løsning på klientsiden påvirkes disse to tilgange ikke af ITP 2.1.

Vi anbefaler

Cookiesaver.io

Kort fortalt konverterer cookiesaver.io relevante cookies fra klient-side til server-side – altså fra om de er sat af browseren selv, eller om de er sat af en server. Sidstnævnte er ikke berørt af ITP og kan derfor have den ønskede levetid, som tidligere. Hvis en cookie bliver fjernet af Safari, pga. den forkortede udløbstid, genskabes cookien indtil den har haft den ønskede levetid.

I praksis oprettes der to CNAMES i din DNS, der tilknyttes Cookiesaver. Dette er for at få et subdomæne til websitets domæne, hvilket er en forudsætning for, at kunne konvertere til server-side cookies, som nævnt ovenfor (for eksempel er cookiesaver.lindebjergmedier.dk et subdomæne til lindebjergmedier.dk).

Desuden tilføjes der et tag på din hjemmeside fx i den tag manager, der anvendes. Det er forholdsvis simpelt og Cookiesaver leverer den JavaScript kode, der skal til. I tagget kan der tilpasses hvilke cookies, der skal omfattes af servicen, hvor lang expiration de skal have osv. Cookiesaver.io leverer eksempler på de mest anvendte cookies og instruktioner i, hvordan man kan opsætte de særlige cookies man måtte have. Det er denne JavaScript kode, der afgør, hvornår der skal gemmes, eller genskabes cookies, så den ønskede adfærd genskabes.

Løsningen er hostet på Amazon Web Services, som sikrer høj stabilitet og skalerbarhed.

Andre løsninger

Lokal-opbevaring til browsing på tværs af underdomæner

Løsningen er baseret på en lokal-opbevaring, der skal oprettes på et af underdomænerne. Lokal weblagring er en mere sikker måde at gemme applikationsdata, der også muliggør lagring af større mængder data lokalt end i en cookie. Denne opbevaring skal indlæses i en iframe, som er et simpelt HTML-element. Ved at bruge postMessage API og cookie-værdier kan du få og indstille cookies på webstedet. Websteder, der er relateret til det samme domæne, anmoder om klient-id’et fra iframe. Hvis der findes et klient-id, sendes ID’et til det anmodende sted og gemmes i den lokale opbevaring for det pågældende underdomæne. Hvis der endnu ikke findes noget klient-id, får anmodningen en anmeldelse og opretter et klient-id, der derefter sendes til iframe og gemmes der. Den store fordel ved denne metode er, at den muliggør tracking på tværs af domæner for sider, der deler det samme overordnede domæne. Ulempen er, at det kræver en masse programmeringsevner. Desuden vil dette “hul” sandsynligvis blive lukket af Apple snart.

Set-cookie-headers i et script på serversiden

Denne løsning er afhængig af opsætning af cookies-serversiden i stedet for klientsiden. Når en klient anmoder om et websted fra en server, sendes cookien fra serveren med HTTP-svaret. Cookien gemmes derefter i en lokal variabel. Hvis HTTP-anmodningen fra klienten også inkluderer parameteren for tværgående domæne-link, fx hvis det er vigtigt at spore på tværs af domæner til Google Analytics, overskrives den lokale variabel, set-cookien, med det unikke klient-id. Hvis der ikke findes nogen cookie, eller linkeren ikke fungerer, genereres et nyt klient-id.

På denne måde kan cookie-udløbsdatoen indstilles til 2 år og omgå begrænsningen på 7 dage. Ved at implementere en levedygtig softwareløsning kan du smertefrit forlænge dine cookies levetid.

Set-cookie-header i en edge cache

I tilfælde af at du ikke har adgang til webservere, fx når IaaS bruges fra Amazon Web Services, er det stadig muligt at håndtere HTTP-anmodninger mellem browseren og den eksterne serverudbyder.  Dette kan opnås ved at køre et JavaScript, der omskriver alle cookies i HTTP headers, så cookies bliver leveret som server-side. Hvis der ikke findes løsninger fra serverudbyderen, skal dette script skrives af dig selv, hvilket kræver teknisk ekspertise.

Delt webservice refereret til med en CNAME record

Denne løsning er baseret på at opbevare dit indhold på et tredjepartsdomæne og ikke dit eget. For at dette skal fungere, skal der etableres et slutpunkt i en virtuel maskine. Derudover opretter du CNAME-post i din DNS og peger tracker.mydomain.com til den respektive virtuelle maskine. Når siden anmodes om fra en klient, kaldes slutpunktet i den virtuelle maskine. Dette slutpunkt henter cookies fra HTTP headers og indstiller cookies på serversiden på mydomain.com. Problemet er, at denne løsning øger belastningen af webtjenesten, der sender HTTP-svaret.

Reverse proxy til tredjeparts service

Denne løsning fungerer på samme måde som CNAME-omdirigering, da en omvendt proxy skjuler originalserveren for et HTTP-svar. Selvom logikken for, hvordan cookies indstilles, forbliver den samme, indebærer implementeringen af denne løsning mere indsats sammenlignet med CNAME-omdirigering. I stedet for blot at ændre DNS-posten og lade eksterne udbydere gøre alt det hårde arbejde, skal webstedsejere oprette en kompleks logik på serversiden for proxy.

Generelt er der flere måder at eliminere virkningen af Safari’s ITP 2.1 på dine Google Analytics-data. De eksisterende løsninger er forskellige i kompleksitet og bringer både fordele og ulemper forbundet med omkostninger og implementering afhængigt af din nuværende installation.

Opsummering

ITP 2.1 påvirker de cookies, som sættes i Safari-browseren, så du går fra en levetid på 2 år for Google Analytics-cookies og 90 dage for Facebook-cookies til blot 7 dage. I vores tilfælde kommer 25% af trafikken fra en Safari-browser, så det har en enorm betydning for os, at vi har løst udfordringen – og det samme vil gælde for din virksomhed.

Grundlæggende betyder ITP 2.1, at du ikke får et retvisende billede af dine besøgende, da tidligere besøgende vil fremstå som nye besøgende efter 7 dage. Det er misvisende for din kunderejse, dine kampagner (hvor kom dine kunder oprindeligt fra), din trafik og ikke mindst din retargeting kampagner, som ikke længere vil fungere efter perioden. Det betyder, at du ikke længere tager beslutninger baseret på reel analyse/data.

Derfor er det vigtigt, at du håndterer ITP 2.1. Der findes forskellige løsninger – nogle mere avancerede og krævende end andre, men for løse problemet nemmest, anbefaler vi Cookiesaver.io, hvilket vi selv benytter.

Har du brug for hjælp til at implementere løsningen på dit websted, så kontakt os endelig.

Henrik Lindebjerg Møller

Henrik Lindebjerg Møller

Specielle i WordPress Udvikling og Messenger Marketing.

Skriv en kommentar

Om Lindebjerg Medier

Vi har samlet alt det vigtigste online for din virksomhed under ét tag fra hjemmesideudvikling, email, server og online markedsføring, så du får én stærk samarbejdspartner, der kender din virksomhed og dine behov.

Seneste indlæg

Synes godt om os

Bestil uforpligtende tilbud på Standard-pakken

Bestil uforpligtende tilbud på Basis-pakken

Bestil uforpligtende tilbud på Pro-pakken

Bestil uforpligtende et special tilbud på hjemmeside