Cookies er geniale men begrænsede

De seneste år er cookies blevet stærkt begrænset som redskab til at tracke brugere. Både fordi 3. part cookies er blevet begrænset med fx ITP men også fordi brugere nu skal give consent til cookies og dermed tracking.

Cookies er geniale til at genkende en bestemt browser på tværs af sidevisninger og sessioner. Det er helt anonymt og brugeren har fuld kontrol og kan slette cookies efter behov.

Browser fingerprinting

Et alternativ til at sætte en cookie med et anonymt ID kan være at forsøge at genkende og adskille browsere fra hinanden, baseret på alle de indstillinger og informationer man kan se om en given bruger med JavaScript. Dette kaldes browser fingerprinting.

Browser fingerprinting er stærkt kritiseret, fordi det sker uden at brugeren er klar over det og browsere forsøger derfor at blokere for det.

På amiunique.org kan du se om der kan laves et unikt fingerprint af din browsere og se hvilke datapunkter der indgår i et fingerprint.

Hvad indgår i et fingerprint?

Her er en ikke-udtømmende liste over hvad der kan indgå i et fingerprint.

• User Agent
• Sprog
• Operativ system
• Tidszone
• Hvilke fonts der er installeret
• Om der bruges Adblocker
• Browser
• Browser version
• Om Java er aktiveret
• Hvilke plugins der er installeret
• Skærm opløsning
• Om browseren må bruge kamera og mikrofon
• Og mange flere...

Men også ting som batteri status og om ens statuslinje er vist eller skjult.

Se hele listen på amiunique.org.

Men spørgsmålet er om det ovenhovedet gør browseren unik?

Kan fingerprinting erstatte cookies?

Fra et teknisk synspunkt er det interessant at teste om fingerprinting overhovedet kan være en erstatning for cookies i forhold til at identificere brugere i Google Analytics. Jeg lavede en test hvor jeg brugte fingerprintjs til at generere et fingerprint og gemme det com custom dimension i Google Analytics. Selvfølgelig opsat i GTM.

Fingerprintjs laver et Array med alle datapunkterne som derefter hashes så man får en værdi som fx 69a45868bbc98e83a463e2e0730be988.

Herunder ses nogle eksempler på fingerprints, device, browser samt hvor mange GA users der har præcis denne kombination. Hvis et fingerprint skal være unikt, skal det kun matche én bestemt User. Ellers er der dermed flere browsere som har det samme fingerprint og så kan det ikke bruges til at genkende én browser mellem sidevisninger og besøg, som en cookie kan.

Og her kan man allerede se problemet, hvor flere Users har det samme fingerprint.

Hvis vi kigger på hele datasættet opdelt i desktop og mobile er der dog en stor andel af fingerprint værdierne der kun har én GA user, så de er unikke.

Langt størstedelen af desktop har kun én User, men der er stadig 26 fingerprints som er fælles for mere end 5 GA Users. På mobile ser det dog anderledes ud, hvor der stadig er flest som matcher én User, men der er mange som matcher mere end én.

Dette skyldes at fingerprint afhænger af hvor meget man har ændret indstillingerne på sin computer og browser, samt installeret fonts og lignende. Og det gør man bare ikke i nær så høj grad på mobile.

Derudover er der også mange flere forskellige computere, med forskellige skærmopløsninger, osv. På mobile i Danmark er der rigtig mange brugere fordelt på de nyeste modeller af iPhone.

Men det bliver værre endnu.

For som det ses herover er der 200 fingerprints som matcher mere end 5 users og der er faktisk ét fingerprint som er ens for 128 forskellige browsere. Der er altså 128 iPhones som er 100% identiske i forhold til alle de datapunkter som fingerprintet bruger.

Herunder ses antal users i datasættet fordelt på Device Category og Operating System. Der er 6304 users på iPhone og iPad, så når der er 128 brugere med samme fingerprint, så er det 2% af alle iPhones/iPads der har identisk fingerprint. Ikke særlig unikt, må man sige.

For at se den totale udfordring med at bruge fingerprint til at gøre browsere unikke, har jeg vist summen af GA Users i de enkelte buckets herunder.

Her ses det at der fx for mobile er 3655 users som har et unikt fingerprint. Men der findes samtidig 3923 users som har et fingerprint som deles af mere end 5 brugere.

Hvis vi opdeler dem i to grupper: Unikke fingerprints (som kun matcher én GA user) og ikke unikke fingerprints, så ser fordelingen således ud.

På mobile er det altså kun 37% af brugere der har et unikt fingerprint, mens det på desktop er 89%. Totalt set har 58% af brugerne et unikt fingerprint og når andelen af trafik fra mobile tilmed er stigende er det derfor totalt umuligt at bruge fingerprint til at identificere og genkende brugere og dermed være en erstatning for cookies.

Andre alternativer til cookies

Plausible Analytics er en ny analytics platform, som kan lave (simpel) analytics uden brug af cookies.

I stedet for cookies bruger laver de et hash af IP adresse og User Agent samt et daily salt. Derved kan de genkende den samme bruger på den samme dag, men næste dag vil der være et nyt salt og så vil brugere være en ny unik bruger. Teoretisk vil der sagtens kunne være flere forskellige brugere fra den samme IP som har samme User Agent, men i praksis vil det være marginalt, så det er et OK kompromis. Meget bedre end fingerprinting, som faktisk ikke bruger IP adressen.

Under afsnittet How we count unique users without cookies kan du læse mere om hvordan Plausible Analytics tæller unikke brugere uden cookies. Eller du kan læse det her:

Det eneste du skal gøre er at udskifte #formId med ID eller class på formularen og affyre koden i konsollen, inden du submitter formularen.

window.addEventListener('beforeunload', function(e) {
    e.preventDefault();
    e.returnValue = '';
});

document.querySelector("#formId").addEventListener("submit", function(e){    
    e.preventDefault();
    console.log("form submitted");    
});

Mennesker lærer af erfaring. Maskiner lærer af data.

Interessen for Machine Learning er steget markant i løbet af de sidste år, men for mange er det stadig mest et buzz word. Her vil jeg prøve at bringe det lidt ned på et niveau som de fleste kan relatere til, nemlig ved at lave lidt Machine Learning i Excel. Machine Learning behøver ikke være mere kompleks end det.

Antal ord og organisk trafik

Som eksempel på machine learning der kan laves i Excel, vil jeg analysere forholdet mellem længden på blogindlæg og mængden af organisk SEO trafik. Sammenhængen er bevist flere gange tidligere, fx af Backlinko:

Rand Fiskin har dog et helt andet take på det i denne Whiteboard Friday:

Her vil jeg derfor analysere hvor meget længden af indlægget betyder for trafikken på min personlige blog og endnu mere spændende: Om man kan forudsige hvor meget trafik et blogindlæg vil få, baseret på antal ord = prædiktiv analyse.

Først har vi brug for noget data

Vi skal bruge et datasæt som indeholder antal ord i hvert blogindlæg samt antal organiske sessioner der er startet på hvert blogindlæg. Der er flere måder at få antal ord på. Man kan gøre det manuelt, men det gider vi ikke, så vi får Wordpress til at gøre det for os, ved at indsætte denne funktion i functions.php:

function word_count() {
    $content = get_post_field( 'post_content', $post->ID );
    $word_count = str_word_count( strip_tags( $content ) );
    return $word_count;
}

Derefter kan antal ord i hver blogindlæg nemt udstilles i dataLayer sådan her:

window.dataLayer = window.dataLayer || [];
dataLayer.push({
  'words': ''
});

I Google Analytics har jeg så opsat en hit-scoped Custom Dimension, hvor jeg kan opsamle antal ord for blogindlægget, når det bliver besøgt.

Derefter vælger jeg rapporten Acquisition -> All traffic -> Channels og vælger Organic Search. Jeg vælger Landing Page som primær dimension og den nye custom dimension Word Count, som sekundær dimension og får dermed dette udtræk, som eksporteres til Excel.

Okay, så nu har vi styr på datasættet. Så skal vi igang med noget Machine Learning.

Der er tre typer af Machine Learning

Indenfor Machine Learning er der tre primære grupper af analyser du kan lave:

• Unsupervised learning: Kan der findes nogle interessante mønstre i datasættet?
• Supervised learning: Kan man forudsige noget på baggrund af disse data?
• Reinforcement learning: Analyse der automatisk bliver klogere af sig selv på baggrund af en række regler, fx, find den optimale strategi i skak

I dette indlæg kigger vi på de to første. Lad os starte med den første:

Unsupervised learning

Det første skridt er at undersøge om der er en sammenhæng mellem de to variabler. I statistik kaldes de to to variable for den uafhængige variabel (antal ord) og den afhængige variabel (organisk trafik). Vi prøver altså at undersøge om organisk trafik er afhængig af antal ord.

Er der en sammenhæng? (Scatter Plot)

Det kan være svært at se om der er en sammenhæng ud fra en tabel med data, så lad os lave lidt simpelt data visualisering med et Scatter Plot.

Hver prik er et blogindlæg og akserne er hhv. antal ord i artikel og organisk trafik til blogindlægget.

I første omgang er det svært at se om der er en sammenhæng, da de fleste er klumpet sammen nede i hjørnet. Det skyldes outliers, dvs. observationer i datasættet, som ligger markant uden for normalen. Ekstreme tilfælde er svære at arbejde med, da de vil få alt for stor indflydelse på modellen. Vi ønsker primært at arbejde med data indenfor normal-området.

De to outliers er:

1) Mit indlæg om drikkevarer til et bryllup, som får ekstremt meget trafik, sammenlignet med mine normale indlæg om digital marketing, så derfor fjernes den fra modellen.

2) Den anden outlier er mit indlæg om responsivt web design i 3 nemme trin som er på 4253 ord, som er markant længere end mine øvrige indlæg, så derfor fjerner jeg også den.

Nu er det mere tydeligt at se en sammenhæng, hvor blogindlæg med flere ord også har mere organisk trafik.

Vi kan gøre det lidt tydeligere, ved at tilføje en tendenslinje.

En tendenslinje gør for det første sammenhængen tydeligere, men den viser også hvor konsistent sammenhængen er i datasættet. Jo tættere alle prikkerne er på linjen, jo mere konsistent er relationen mellem tekstlængden og trafikken. Jo længere prikkerne er fra linjen, jo mere tilfældigt er det og dermed vil dataene typisk ikke være gode at bygge en model på.

Hvor stærk er sammenhængen? (Korrelation)

Hvis der er perfekt korrelation, kan man forudsige værdien af den ene variabel, kun ved at kende den anden.

Korrelation udtrykkes som et tal mellem -1 og 1. Jo tættere på yderpunkterne, dvs. -1 eller 1, jo stærkere er korrelationen.

Lad os tage et par eksempler.

Her er først et datasæt med en korrelation på 1, dvs. når den ene stiger, så stiger den anden også.

Det kan for eksempel være personers højde og vægt som ofte følges ad. I den virkelige verden vil man dog typisk aldrig opnå en korrelation på 1,0 da der vil altid være outliers.

Den omvendte er et datasæt med en korrelation på -1, dvs. en negativ korrelation. Det vil altså sige når den ene stiger, så falder en anden.

Det kan fx være sammenhængen mellem hvor koldt det er og hvor mange penge man bruger på at opvarme sit hus.

Det sidste eksempel er et datasæt med en korrelation tæt på 0, dvs. der er ingen sammenhæng mellem de to variabler. Dermed er det umuligt at forudsige hvad den ene værdi vil være hvis man kender den anden værdi.

Det kan fx være en persons højde og karakter i skolen, hvor der formentlig ikke er nogen som helst sammenhæng, og det er dermed helt tilfældigt hvor prikkerne er placeret, som det ses herover.

Korrelation mellem antal ord og organisk trafik

I disse data er korrelationen mellem antal ord og organisk trafik på 0,63.

Årsag eller sammenhæng?

Okay, så nu har vi fundet ud af at der er en sammenhæng mellem de to variabler. Årsag er en helt anden ting.

Det vi gerne vil undersøge her er nemlig ikke blot om der er en sammenhæng mellem antal ord og organisk trafik, men også om antallet af ord kan forårsage (eller forklare) trafikken og dermed om man kan konkludere at hvis man skriver flere ord, så får man også mere trafik og omvendt.

Når vi snakker årsag så er der tre muligheder:

1. Antal ord påvirker mængden af organisk trafik. Det er en sandsynlig forklaring.
2. Organisk trafik påvirker antal ord. Det giver ikke nogen mening. Der kommer ikke flere ord i en artikel, hvis den begynder at modtage mere organisk trafik, så væk med den.
3. Både antal ord og organisk trafik bliver påvirket samtidig af en helt 3. faktor. Den kan også være en sandsynlig forklaring. Forklaringen kan være at årsagen bare er gode velskrevne blogindlæg, som både får meget trafik og at velskrevne blogindlæg også ofte er længere. Dvs. man kan ikke bare skrive længere blogindlæg. Man skal skrive bedre blogindlæg, for at få mere trafik.

Ingen kan forklare korrelation bedre end hende her, så lad os give hende 5 minutter og så fortsætter vi derefter.

Giver det mening?

Det bedste du kan gøre for at afgøre om den ene variabel forårsager den anden variabel eller der blot er en sammenhæng er at spørge dig selv om det giver mening?

• Lange tekster indeholder meget information om et givent emne og er derfor gode at henvise til.
• Lange tekster kommer i bund med et emne.
• Lange tekster dækker mange aspekter af et emne og brugeren skal dermed kun søge information ét sted.

Alle sammen er faktorer som gør at Google gerne vil ranke indholdet højt.

Tidligere undersøgelser har vist en sammenhæng mellem lange tekster og deres placering i Google.

Supervised learning

For at lave en model som kan forudsige organisk trafik baseret på antal ord kan vi lave en regressionsanalyse.

Regression

En regressionsanalyse kan laves direkte i Excel og giver følgende resultat for vores data.

Den blå kasse hedder R squared på engelsk, også kaldet forklaringsgraden. Den viser at 17,5% af variationen i den afhængige variabel (organisk trafik) kan forklares af modellen. Og eftersom der kun er én uafhængig variabel i modellen (antal ord), så kan vi altså sige at antal ord forklarer 17,5% af variationen i organisk trafik. Eller sagt på lidt mere dansk: Antal ord forklarer 17,5% af den organiske trafik et blogindlæg har. Resten af variationen (82,5%) kan ikke forklares af modellen, og skyldes dermed andre faktorer, som er alle de andre ting Google kigger på, når de ranker indhold.

Hov hov, nu ikke så hurtigt!

Men husk at vi ikke kan konkludere at antal ord alene forklarer 17,5% af trafikken. Som tidligere nævnt kan det sagtens være en andre ting, som dog korrelerer stærkt med antal ord, fx en velskrevet artikel, som får mange sociale delinger, links, høj CTR, etc.

Forudsige organisk trafik

Okay, nu skal vi lige et smut ned af memory lane. Vi skal tilbage til linoleumsgulve og folkeskolens matematiktimer. Kan du huske linjens ligning?

Altså den her: Y = A * X + B

Hvor A er hældningen på linjen og B er skæringen med Y-aksen. Det er de to tal regressionsanalysen kan udregne for os.

Når vi kander A og B kan vi indsætte antal ord som X og udregne den forventede organisk trafik. Vi skal derfor have linjens ligning for tendenslinjen herunder.

De to tal vi skal bruge til at indsætte istedet for A og B i ligningen får vi altså som en del af resultatet af den linære regression. Det er de to tal i den orange boks.

Det første tal er skæringen med Y-aksen som er -13,95.

Det næste tal er hældningen på linjen som er 0,067.

Dermed bliver linjens ligning: Y = 0,067 * X - 13,95

Hvis vi fx indsætter X = 5000, får vi følgende: 321,05 = 0,067 * 5000 - 13,95.

Det vil altså sige at den forventede organiske trafik til et blogindlæg på 5000 ord er 321 besøg i samme periode som de øvrige tal er udtrukket for. I dette tilfælde har jeg trukket 1 års besøg ud, så perioden er 1 år.

Hældningen på linjen fortæller desuden at hver gang X stiger med 1, så stiger Y med 0,067.

Sagt på dansk: Hver gang vi skriver et ord mere, så kan vi forvente 0,067 flere besøg om året.

Dermed kan jeg se hvor lang tid der går fra brugeren lander på siden til et Event udføres.

Det tilføjer også en spændende dimension til dine data, som ikke er tilgængelig i en standard Google Analytics opsætning, nemlig tid mellem forskellige events indenfor en session.

Google Analytics er god til at vise hvor mange sessioner, transaktioner, etc. du har haft på en given dag eller time, samt den gennemsnitlige varighed for de sessioner. Men der er ikke noget data på rækkefølgen af events eller tiden mellem de enkelte events. Det tilføjer vi noget af i dag.

Her viser jeg hvordan du sætter det op og eksempler på hvordan det kan forbedre dine analyser.

Opsætning i Google Tag Manager

I Google Tag Manager skal der laves to ting:

• En Custom JS variabel som udregner tiden
• Et Event Tag hvor resultatet af variablen indsætter som Værdi.

Udregn hvor hurtigt et event udføres

For at udregne hvor hurtigt et Event udføres, skal der bruges to tal.

1. Et præcist tidspunkt når Event'et udføres.
2. Et præcist tidspunkt når siden indlæses.

Når man skal regne i tid er Unix timestamps geniale. Unix timestamp er den tid der er gået siden 1. januar 1970 - typisk i antal sekunder eller millisekunder.

Og det er super nemt at få det timestamp i millisekunder med JavaScript.

new Date().getTime()

Men det har jeg det præcise tidspunkt for hvornår et Event sker.

Så skal jeg bare have tidspunktet hvor siden blev indlæst.

window.performance.timing.navigationStart

Ved at trække de to tal fra hinanden, ved du præcist (i millisekuder) hvor lang tid der er gået fra brugeren begyndte at loade siden, til et givent Event bliver udført.

Du laver derfor en Custom JavaScript Variable i GTM, hvor du trækker de to tal fra hinanden. Husk at en Custom JavaScript Variable altid skal være en function som returnerer en værdi.

Funktionen gør følgende pr. linje:

1. Gemmer tiden lige nu i millisekunder
2. Trækker tiden da siden blev indlæst fra tiden nu i millisekunder. Dividerer med 1000 for at omregne til sekunder
3. Returnerer tiden hvis den er under 1800 sekunder. Hvis den er over returneres `undefined`

Jeg tjekker om der er gået mere end 1800 sekunder (30 minutter) siden dengang siden blev indlæst, for at undgå at tracke nogle meget høje antal sekunder, som vil skævvride data markant. Hvis der er gået mere end 30 minutter er der stor sandsynlighed for at sessionen er udløbet, så det er en god grænse at sætte.

Det smarte ved at returnere undefined som værdi er at undefined værdier automatisk bliver udeladt af dit request til Google Analytics.

function() {
  var currentTime = new Date().getTime();
  var timeToEvent = (currentTime - window.performance.timing.navigationStart)/1000;
  return timeToEvent < 1800 ? timeToEvent : undefined;
}

Jeg bruger altid den samme navngivning når jeg opretter Tags, Variabler eller Triggers i GTM. Fx starter jeg altid en Custom JavaScript Variable med “JS - [navn]” så jeg har dem samlet i oversigten og de er nemme at finde.

Den her kalder jeg “JS - Time to event”.

Event Tag med tiden som værdi

Du kan derefter indsætte den nye variabel som Værdi i dine Event tracking Tags.

Det fede ved at tracke tiden som værdien for et Event er at Google Analytics udregner et gennemsnit ud-af-boksen. Dermed får du et hurtigt overblik over hvor hurtigt et Event sker i gennemsnit.

Use case #1: JavaScript fejl

En af de ting jeg altid sætter op i GTM er tracking af JavaScript fejl. Det er mega nemt og værdifuldt, fordi det er indbygget i GTM, så der skal ikke kodes noget.

Ved at tracke tiden indtil der sker en JavaScript fejl, er det meget nemt at se hvilke fejl der sker ved pageload og hvilke der først sker efter brugeren er begyndt at bruge siden. Dét gør det tit meget nemmere at debugge en JavaScript fejl og forstå hvad der gik galt.

Use case #2: Læsning af indhold

Jeg tracker min blog med Enhanced Ecommerce, som du kan læse meget mere om her. Jeg tracker en række events når brugeren har læst hhv. 33%, 66% samt 100% af et blogindlæg. Her bruger jeg også tiden, til at se hvor hurtigt brugerne læser indholdet og hvor lang tid det tager dem at nå til bunden af siden.

Jeg tracker et “add to cart” event, når brugeren begynder at scrolle ned af indlægget. Det er overraskende at det igennemsnit tager 26,52 sekunder før brugerne begynder at scrolle, men det tager 51,97 sekunder at nå 33% ned gennem indlægget (checkout step 1).

Use case #3: Klik i menuen

Mange websites tracker hvad brugeren klikker på i menuen. Særligt i en mega-menu kan det være nyttigt at vide hvor brugerne klikker og hvilke områder der ikke modtager nogen kliks. Her kan tiden også bidrage med ekstra viden, til at se hvor hurtigt brugeren kan danne sig et overblik over menuen og foretage et valg.

Her på bloggen har jeg en hamburger menu, hvor jeg tracker når den åbnes og lukkes.

Jeg tracker også når brugeren klikker i menuen. Her er det interessant at se hvor stor forskel der er på hvor hurtigt brugerne klikker på de forskellige kategorier af indlæg. Bemærk at dette er tiden efter siden blev indlæst og ikke tiden efter menuen blev åbnet.

Jeg har efterfølgende lavet et stort redesign af min blog og alle beslutningerne var baseret på data, fx at fjerne menuen. Det kan du læse mere om her.

Use case #4: Brug af drikkevare beregner

Tilbage i 2015 lavede jeg en infografik over hvor meget der blev drukket til vores bryllup. Det er i øvrigt suverænt det mest blogindlæg jeg har. Jeg skal have skrevet noget mere/bedre om Google Analytics.

Jeg lavede også en beregner hvor man kan indtaste antal gæster og få at vide hvor meget man skal købe.

Der er lavet 18.555 beregninger til dato og der er i gennemsnit gået 110 sekunder fra siden blev indlæst, til der er udført en beregning.

Bounteous har også skrevet en fin artikel om at tracke tiden op til et event hvis du vil læse mere om emnet.

Kan vi se hvad brugerne gør efter de ser forsiden?

Det er et godt spørgsmål!

Men umiddelbart ikke så nemt at svare på…

Problemet med Next Page Path

Problemet er at der findes ikke en next path dimension.

Eller joh, det gør der. Den hedder Next Page Path. Men du får ikke det der står udenpå æsken.

Den giver bare det samme som Page dimensionen.

Det skyldes at et givent hit eller pageview i Google Analytics, isoleret set, ikke har informationer om hvad der sker efterfølgende. Man kan derfor ikke vælge forsiden i “All pages”-rapporten og derefter se hvad brugerne gør derefter med Next Page Path dimensionen. Den indeholder nemlig præcis det samme som Page dimensionen.

Next Page Path er misvisende, hvilket også er grunden til at Google Analytics har gjort den deprecated og fjerner den på et tidspunkt.

Du får også en advarsel hvis du bruger den i en custom report.

Previous Page er løsningen

Til gengæld kan man altid se den forrige side, via document.referrer som bliver tracket i dimensionen Previous Page Path.

Tricket til at se den næste side efter forsiden er derfor at lave en rapport som kigger på alle sider og filtrere så du kun ser de sider hvor den forrige side er forsiden. Det kan nemt laves i en custom report sådan her:

Og dermed får du den ønskede oversigt:

De er geniale til at indsamle e-mail permission på et website. Og de er ikke så irriterende som pop-ups.

Eller er de?

Kan de være så irriterende at brugerne ikke konverterer og måske forlader sitet?

Det har jeg testet!

Indhold

• Byg en simpel slide-in
• HTML
• CSS
• JavaScript
• Hvornår skal den så vises?
• Vis på et tilfældigt tidspunkt
• Effekt på tilmelding til nyhedsbrev
• Effekt på læsning af blogindlæg
• Læst 33%
• Læst 66%
• Læst 100%
• Læst 100% + 1 minut
• Opsummering

Byg en simpel slide-in

Jeg lavede en simpel slide-in her på min blog.

HTML

Selve slide-in boxen er blot noget simpel HTML.

<div class="slide-in-box">
    <a href="#" class="slide-in-box-close"></a>
    <h3>Få gratis tips og tricks i din indbakke!</h3>
    <form action="" method="post">
    ... input felter ...
    </form>
</div>

CSS

Den kan styles på mange måder, men det vigtigste er at den har position: fixed så den er låst i bunden af skærmen og z-index: 99999 så den er “ovenpå” websitet. Derudover har den bottom: -100% som gør at den som standard er skjult “under” skærmen.

Når slide-in boxen skal vises, sætter jeg en .open class på den med JavaScript, som sætter bottom: 5px som gør at den bliver synlig 5px over bunden af skærmen.

transition: .5s bottom ease-in-out tilføjer en animation når værdien af bottom ændres, som gør at den “slider” op nedefra.

.slide-in-box  
  z-index: 99999  
  position: fixed 
  bottom: -100% 
  transition: .5s bottom ease-in-out

  &.open
    bottom: 5px

Dermed har jeg en simpel slide-in box.

JavaScript

Det sidste er et stykke JavaScript til at vise boxen.

Slide-in boxen skal kunne åbne på forskellige tidspunkter, så jeg har lavet en funktion, som jeg kan kalde til at åbne den, som gør følgende.

1. Funktionen tager en parameter randomPageState som er tidspunktet hvor den skal åbne. Det kommer vi tilbage til lige om lidt.
2. Hvis personen tidligere har set og lukket en slide-in box, bliver det gemt i localStorage. Jeg tjekker om det er sket, så jeg ikke viser boxen igen til samme bruger.
3. Jeg sætter en .open class på boxen så den åbner.
4. Til sidst tracker jeg et event med at boxen er åbnet og tidspunktet den åbnede på.

showSlideUpBox: function(randomPageState) {    
    var slideInOptOut = localStorage.getItem("slideInOptOut");
    var slideUpBox = document.querySelector(".slide-in-box");
    if (!slideInOptOut) {
      slideUpBox.classList.add("open");
      Tracking.trackSlideUpBox("open", randomPageState);
    }
}

Sådan ser det ud når slide-in boxen bliver synlig.

Hvornår skal den så vises?

Jeg tracker detaljeret hvor meget der bliver læst af mine blogindlæg ved at sende et event på følgende tidspunkter.

1. Når brugeren lander på et blogindlæg (detail view)
2. Når brugeren begynder at scrolle (add to cart).
3. Når brugeren har scrollet 33% af indlæggets længde (checkout step 1).
4. Når brugeren har scrollet 66% af indlæggets længde (checkout step 2).
5. Når brugeren har scrollet 100% af indlæggets længde (checkout step 3).
6. Når brugeren har scrollet 100% af indlæggets længde og været på siden mindst et minut (purchase).

Jeg tracker de events med Enhanced Ecommerce hvis du vil læse mere om det.

Jeg vil gerne tracke det optimale tidspunkt at vise en slide-in på af de 6 ovenstående tidspunkter. Både for at øge konverteringen og få flest mulige tilmeldinger til mit nyhedsbrev. Men også for at undgå at irritere brugeren, så de forlader siden uden at læse indlægget færdigt.

Vis på et tilfældigt tidspunkt

Ud af de 6 ovenstående tidspunkter jeg kan vise en slide-in på, vil jeg dog ikke vise den med det samme når brugeren lander på siden, så jeg vil teste de andre 5 tidspunkter.

Jeg har lavet et array med de 5 tidspunkter:

var randomPageStates = ["scroller","oneThird","twoThirds","endContent","purchase"];

Når brugeren lander på et blogindlæg bruger jeg JavaScript til at generere et tilfældigt tal mellem 0-4.

var randomPageState = Math.floor(Math.random() * 5);

Dette tal bruger jeg så til at vælge et af de 5 tidspunkter. Arrays i JavaScript er 0-indexeret, så den første plads er index 0, op til index 4.

Jeg bruger det tilfældige tal til at vælge et tilfældigt index i array’et, som styrer hvornår min slide-in vises på siden. Jeg tracker også værdien i en Hit-scoped custom dimension, så jeg kan sammenholde det med konvertering og frafald.

Lad os starte med konverteringer.

Effekt på tilmelding til nyhedsbrev

Okay, vi kan lige så godt tage den med det samme. Min slide-in konverterer ikke. Slet ikke.

Slide-in boxen er i alt blevet vist 22.161 gange og den er blevet lukket 15.490 gange. Men den har kun fået 29 tilmeldinger.

29!

Det er en konverteringsrate på 0,13%.

Men det er også min egen skyld. Jeg sælger slet ikke den tilmelding godt nok. Det er ikke nok bare at give mulighed for at få en mail ved nye blogindlæg.

Det virker meget bedre med en Content Upgrade.

Nåh, men det var heller ikke det vi skulle snakke om!

Effekt på læsning af blogindlæg

Jeg vil gerne undersøge om brugerne er mere tilbøjelige til at forlade sitet når min slide-in bliver vist.

I det efterfølgende kigger jeg på konverteringsraten for de enkelte events ned gennem et blogindlæg sammenlignet med detail views som er det samme som sidevisninger på blogindlægget.

Det første jeg kigger på er Add to Cart konverteringsraten, dvs. hvor mange der begynder at scrolle.

Denne er lidt ligeyldig fordi min slide-in tidligst bliver vist på det tidspunkt hvor de rammer Add to Cart. Så den kan faktisk ikke nå at påvirke, men den er god at have med som kontrol.

De fem søjler er de fem tidspunkter slide-in boxen bliver vist på. Ikke overraskende er konverteringsraten næsten den samme for alle grupper.

Læst 33%

Det næste event er dem som har scrollet 33% af indlægget og her vil den første gruppe altså have set slide-in boxen, mens de andre ikke har set den endnu.

Add to Cart har en anelse lavere konverteringsrate end Læst 33% men forskellen er meget lille og med en p-værdi på 0,1572 er den ikke signifikant.

Man kan også se at Læst 100% har en konverteringsrate der er endnu lavere end Add to Cart og Læst 100% har altså ikke set slide-in boxen endnu, så det er bare naturlig varians.

Indtil videre påvirker det altså ikke konverteringsraten.

Læst 66%

Ved 66% læst er der heller ingen markant forskel og faktisk er det de to øverste grupper (som på dette tidspunkt har set slide-in boxen) der har den højeste konvertering.

Så stadig ingen påvirkning.

Læst 100%

Ved 100% læst er det dermed de øverste 3 grupper der har fået vist slide-in boxen - men det har stadig ingen betydning.

Videre til sidste event.

Læst 100% + 1 minut

Det sidste event er dem som har scrollet 100% og været på siden mindst 1 minut - det er dem hvor jeg antager at de faktisk har læst hele blogindlægget (og dem jeg tracker som et transaktion i Enhanced Ecommerce).

Men heller ikke her er der nogen entydig forskel som skulle indikere at brugerne bliver irriteret af en slide-in og dermed er mere tilbøjelige til at forlade sitet eller mindre tilbøjelige til at læse blogindlægget færdig.

Konklusionen er derfor at min slide-in ikke er irriterende for brugerne - i hvert fald ikke så meget at de ikke gider læse blogindlægget færdigt.

Opsummering

I dette blogindlæg har jeg brugt Google Analytics og Google Tag Manager til at indsamle det nødvendige data til at teste hypotesen om at slide-ins ødelægger konverteringsraten. Min konklusion gælder ikke for alle sites og alle brancher - sådan noget skal altid testes på det enkelte site. Men jeg håber at ovenstående kan give noget inspiration til hvordan man kan opstille en hypotese, indsamle den nødvendige data og analysere det, så der kan træffes en beslutning på baggrund af data.

Tilbage er der blot at få lavet en ordentlig content upgrade, så jeg kan lave en slide-in der faktisk kan give nogle tilmeldinger til mit nyhedsbrev.

I 2013 flyttede jeg bloggen over på WordPress hvor alt HTML blev konverteret til WordPress templates, men designet forblev nogenlunde uændret.

I 2014 lavede jeg designet responsivt så siden blev mobilvenlig.

I 2019 var det så tid til et redesign hvor jeg har brugt data fra Google Analytics, både til at tage beslutninger for at få sitet til at loade så hurtigt som muligt, men også til at forbedre KPI’erne for sitet. Jeg har også testet et råd fra Steve Krug’s Dont Make Me Think, for at få brugerne til at læse flere af mine blogindlæg.

Jeg har delt blogindlægget op i to dele, hvor den første del fokuserer på hvordan jeg har kodet sitet (der er brugt GA data to steder, som er markeret med fed herunder).

Den anden del fokuserer på optimering med Google Analytics og opfølgning på effekten af de ændringer jeg har lavet.

Indhold

Part 1: Det tekniske med fokus på hvordan designet er kodet.

• Mål med det nye design
• Workflow
  • GruntJS
  • Kun én JavaScript fil
  • Browser caching og cache busting
  • Gruntfile.js
• JavaScript
  • Tracking logik fra GTM til dataLayer
  • Væk med jQuery
  • JavaScript reduceret fra 184 KB til 31 KB
• CSS
  • CSS skrevet i Sass
  • Inline CSS eller ekstern fil? (Baseret på adfærdsdata fra Google Analytics)
  • Inline kun den nødvendige CSS kode
  • CSS reduceret med 45%
  • Væk med !important
• Billeder
• WordPress
  • Væk med unødvendige plugins
  • Tabeller
  • Syntax highlighting
  • Relaterede indlæg (Baseret på adfærdsdata fra Google Analytics)

Part 2: Optimering af adfærden på sitet med Google Analytics data.

• Loadtid og konvertering
  • Google Pagespeed Score hævet fra 86 til 99
  • Er sitet så blevet hurtigere?
  • Hvad med konvertering?
  • Øge sidevisninger pr. besøg (test af råd fra Steve Krug)
• Lykkedes målene?

Mål med det nye design

1. Mere moderne workflow til udvikling af websitet
2. Oprydning i kode og sletning af unødvendige ting
3. Hurtigere loadtid
4. Højere konvertering
5. Øge sidevisninger pr. besøg

Workflow

GruntJS

Der er mange (kedelige) opgaver involveret i at optimere front-end kode og jeg bruger GruntJS som task runner, til at udføre alle de opgaver automatisk.

GruntJS gør følgende ved mine filer:

1. Samler JavaScript filer til én samlet, minificeret fil. Både de forskellige libraries jeg bruger og mine egne JavaScript filer.
2. Compiler alle Sass filerne til en minificeret CSS fil.
3. Kopiere alle de færdige optimerede filer over i en mappe, som indeholder de filer der skal uploades til webserveren.
4. JavaScript filen bliver cachet 1 år i browseren og derfor får den et unikt nyt navn, hvis filen ændres, så browseren downloader den nye fil.
5. Grunt overvåger mine filer og kører de ovenstående opgaver, når jeg gemmer en ny ændring, fx i en Sass eller JavaScript fil.

Kun én JavaScript fil

Det er ikke så vigtigt efter HTTP2 blev lanceret, men det er stadig best practise at lave så få requests som muligt, fx ved at samle alt JavaScript i én fil. Takket være GruntJS bliver dette gjort helt automatisk og derefter bliver filen minificeret.

Browser caching og cache busting

JS filen caches i browseren i 1 år ved at sætte expire-headers til 1 år i .htaccess. Jeg har brugt de anbefalede settings fra html5boilerplate.

ExpiresByType application/javascript                "access plus 1 year"
ExpiresByType application/x-javascript              "access plus 1 year"
ExpiresByType text/javascript                       "access plus 1 year"

GruntJS laver et hash baseret på indholdet i filen og det hash bliver tilføjet til filnavnet.

Dvs. denne fil:

bundle.min.js

Kommer til at hedde:

bundle.min.e3d609e4.js

Hvis filen ændrer sig bliver der lavet en ny hash, så filnavnet ændrer sig. Dermed vil browseren se det som en ny fil, så den ikke bruger den fil den allerede har i cache, men downloade den nye fil.

Dermed kan jeg have filen cachet nærmest uendeligt, men stadig sikre at alle browsere får den nyeste fil, hvis jeg ændrer noget.

Gruntfile.js

For de interesserede, så er her min Gruntfile.js som indeholder hele den opsætning af GruntJS som er beskrevet herover. Derudover har den også compile af Sass til CSS som jeg beskriver om lidt.

module.exports = function(grunt) {
    require("load-grunt-tasks")(grunt);

    // 1. All configuration goes here
    grunt.initConfig({
        pkg: grunt.file.readJSON("package.json"),

        // grunt-contrib-concat
        concat: {
            dist: {
                src: [
                    "js/libs/prism.js",
                    "js/SlideUpBox.js",
                    "js/content-as-ecommerce.js",
                    "js/tracking.js",
                    "js/hamburgerNav.js",
                    "js/jacobworsoe.js",
                    "js/drinksberegner.js"
                ],
                dest: "js/build/bundle.js"
            }
        },

        // grunt-contrib-uglify
        uglify: {
            build: {
                files: [
                    {
                        src: "js/build/bundle.js",
                        dest: "js/build/bundle.min.js"
                    }
                ]
            }
        },

        // grunt-contrib-sass
        sass: {
            dist: {
                options: {
                    style: "compressed",
                    sourcemap: "none"
                },
                files: {
                    "css/homepage.css": "scss/homepage-bundle.sass",
                    "css/single.css": "scss/single-bundle.sass"
                }
            }
        },

        // grunt-contrib-copy
        copy: {
            main: {
                files: [
                    {
                        expand: true,
                        src: ["*.php"],
                        dest: "dist/",
                        filter: "isFile"
                    },
                    {
                        expand: true,
                        src: ["*.css"],
                        dest: "dist/",
                        filter: "isFile"
                    },
                    {
                        expand: true,
                        src: ["*.png"],
                        dest: "dist/",
                        filter: "isFile"
                    },
                    {
                        expand: true,
                        src: ["css/*.css"],
                        dest: "dist/",
                        filter: "isFile"
                    },
                    {
                        expand: true,
                        src: ["js/build/*.min.js"],
                        dest: "dist/",
                        filter: "isFile"
                    },
                    {
                        expand: true,
                        src: ["svg/*.svg"],
                        dest: "dist/",
                        filter: "isFile"
                    }
                ]
            }
        },

        // grunt-hashres
        hashres: {
            options: {
                fileNameFormat: "${name}.${hash}.${ext}",
                renameFiles: true
            },
            prod: {
                options: {},
                src: ["dist/js/**/*.min.js"],
                dest: ["dist/footer.php"]
            }
        },

        // grunt-contrib-watch
        watch: {
            options: {
                livereload: true
            },
            scripts: {
                files: ["js/*.js"],
                tasks: ["concat", "uglify"],
                options: {
                    spawn: false
                }
            },
            css: {
                files: ["scss/*.sass", "scss/*.scss"],
                tasks: ["sass"],
                options: {
                    spawn: false
                }
            }
        }

    }); // grunt.initConfig

    // 4. Where we tell Grunt what to do when we type "grunt" into the terminal.
    // Development tasks
    grunt.registerTask("default", ["sass", "watch"]);
    grunt.registerTask("stage", ["sass", "concat", "uglify", "copy"]);
    grunt.registerTask("deploy", [
        "sass",
        "concat",
        "uglify",
        "copy",
        "hashres"        
    ]);
};

JavaScript

Tracking logik fra GTM til dataLayer

Jeg afprøver og tester en masse forskellig tracking på mit website. Noget af det er tilføjet til sitets JavaScript fil og udstillet i dataLayer som det bør, men noget bliver også hurtigt tilføjet direkte i GTM for at afprøve det.

Jeg gik alt GTM kode igennem og fik det flyttet til sitet, så GTM indeholder så lidt kode og logik som muligt. Det er fint at teste noget hurtigt i GTM, men det skal tilføjes til dataLayer hvis det skal være permanent.

Væk med jQuery

Jeg har omskrevet alt jQuery til ren JavaScript for at slippe for at loade de 87 KB som jQuery fylder når det er minified (274 KB unminified). Her var youmightnotneedjquery.com en stor hjælp.

JavaScript reduceret fra 184 KB til 31 KB

JavaScript koden til websitet er reduceret kraftigt med i alt 153 KB hvoraf de 87 KB er jQuery. Men der er også en masse andre ting jeg har skåret væk og skrevet smartere. Fx FitVids.JS som jeg brugte da jeg lavede sitet responsivt til at gøre YouTube videoer responsive. Det er meget smart, men med lidt simpel HTML og CSS kan man undvære det jQuery plugin.

Jeg indsætter en div rundt om videoen.

<div class="videoWrapper">
    <iframe src="//www.youtube.com/embed/usyYXNNBRjc" frameborder="0" allowfullscreen></iframe>
</div>

Og tilføjer lidt styling af den div samt iframen som indeholder videoen, og så er videoen responsiv.

.videoWrapper
    position: relative
    padding-bottom: 56.25%
    padding-top: 25px
    height: 0
    margin: 20px 0 20px 0
    border: 5px solid $lightGrey

.videoWrapper iframe
    position: absolute
    top: 0
    left: 0
    width: 100%
    height: 100%

Jeg brugte også LunaMetrics’ script til tracking af visninger af YouTube videoer, men jeg brugte ikke den tracking til noget, så det blev også fjernet.

CSS

CSS skrevet i Sass

I det nye redesign skrev jeg alt CSS fra bunden igen og jeg valgte at skrive det i Sass.

Sass er et sprog som giver nogle ekstra muligheder og Sass filerne skal compiles til almindelige CSS filer inden de ryger ud på websitet.

Her er mine top 3 fedeste ting ved Sass.

1) Variabler. Jeg kan definere variabler, fx til farvekoder som er brugt mange steder i koden. Dermed kan du nemt skifte farven overalt i din kode, blot ved at ændre én variabel. Da facebook valgte at rydde op i deres CSS, fandt de 800 næsten ens blå farver i koden. Det sker ikke med Sass.

2) Imports. Jeg kan splitte Sass koden op i mindre filer som tilhører en bestemt side eller sektion af sitet. Det hele kan samles til én fil, så browseren stadig kun skal lave et request.

// Base
@import "normalize"
@import "_vars"
@import "_base"
@import "_jetpack"

// Critical
@import "_header"
@import "_videoEmbeds"
@import "_pre"
@import "_button"
@import "_blockquote"

// Below-the-fold
@import "_post-share-follow"
@import "_comments"
@import "_footer"
@import "_slide-up-box"

// Pages
@import "_single"
@import "_highlight"
@import "_tables"

3) Nesting. Med Nesting kan man tilføje underliggende selectors blot ved at indent’e linjen, så man slipper for at gentage selectors mange gange.

Her er et eksempel på Nesting i Sass.

.comment-gravatar
    float: left
    width: 15%
    max-width: 120px
    padding-right: 20px
    margin-top: 10px

    @media(max-width: 500px)
        padding-right: 8px

    img
        border-radius: 5px

Og her den CSS kode det compiles til.

.comment-gravatar {
  float: left;
  width: 15%;
  max-width: 120px;
  padding-right: 20px;
  margin-top: 10px;
}

@media(max-width: 500px) {
  .comment-gravatar {
    padding-right: 8px;
  }
}

.comment-gravatar img {
  border-radius: 5px;
}

Inline CSS eller ekstern fil?

Normalt er det best practice at have CSS i en ekstern fil, så den kan caches i browseren. Men det kræver et ekstra request at have den i en ekstern fil. Så om det kan betale sig at lave et ekstra request kommer an på hvor stor filen er samt hvor mange sider brugeren ser på sitet.

På første sidevisning vil det nemlig være en ulempe at have CSS i en ekstern fil, da der skal laves et request mere. Men på efterfølgende sider vil filen være cachet og skal ikke hentes igen.

I løbet af det sidste år har der været en bounce rate på 85% på sitet, dvs. langt de fleste læser kun et enkelt blogindlæg. Der bliver også kun set 1,17 sider pr. session. Det betyder altså at 85% af de besøgende ikke ser en efterfølgende side og dermed ikke får gevinsten af en cachet CSS fil.

I hvert fald ikke i det samme besøg. Men det kan jo være de kommer tilbage på sitet igen og dermed stadig har CSS filen i deres cache.

Det er kun 25% af de besøgende der har været på sitet før, så langt de fleste vil ikke have CSS filen cachet.

Min konklusion på de ovenstående data bliver at det er bedst at optimere efter at give en hurtig oplevelse på den første sidevisning og derfor lægger jeg CSS’en inline, for at spare det ekstra request.

Inline kun den nødvendige CSS kode

Når man har CSS i en ekstern fil som bliver cachet giver det typisk bedst mening at samle det hele i én fil. Men når jeg inliner min CSS kode, giver det bedre mening kun at inline den CSS kode der skal bruges på den specifikke side.

Min forside er rimelig simpel. I mit tilfælde er det bare en liste af mine blogindlæg med titel, dato og antal kommentarer.

Et blogindlæg har både billeder og video i indlægget, den har en anderledes header med titlen på indlægget. I bunden er der links til sociale medier, tilmelding til nyhedsbrev og så er der hele kommentar sektionen, som kræver en masse CSS kode.

Der er altså en masse CSS kode som er helt overflødig at loade på forsiden og vice versa.

Når jeg bruger Sass til at samle de enkelte .sass filer til en færdig CSS fil laver jeg derfor to filer:

1. En til forsiden og kategorisider, hvor der blot vises en liste af indlæg.
2. En til single.php som viser hele indlægget.

De to filer har alt den generelle styling til fælles, som jeg har brudt ud i logiske moduler.

// Base
@import "normalize" // https://necolas.github.io/normalize.css/
@import "_vars" // Sass variabler med alle de farver jeg bruger
@import "_base" // Site-wide styling, fx box-sizing: border-box og H1, H2, H3 og overordnet font-family
@import "_jetpack" // Jetpack tilføjer en lille statistik box, som jeg sjuler med CSS

// Critical - Above-the-fold
@import "_header" // SVG logo, sidens titel, hamburger menuen og selve menuen som åbnes

// Below-the-fold
@import "_footer" // Footer med sociale links, mit billede og en række links

Ovenstående CSS kode inkluderes i begge filer og derudover inkluderer jeg så den kode som er relevant for hhv. forsiden og blogindlægget.

Jeg har i alt 19 KB CSS kode.

• 41% er Normalize, som jeg måske skal overveje om jeg kan undvære.
• 38% er specifikt til blogindlæg som jeg derved ikke behøver at loade på forsiden.
• 18% er den globale CSS til header og footer.
• 3% er til forsiden, der som sagt er meget simpel.

I WordPress inkluderer jeg de to CSS filer så de ligger inline, baseret på et check for om siden er single.php eller andre sider.

<style>
<?php if ( is_single() || is_page() ) {
    include("css/single.css");
} else {
    include("css/homepage.css");
}
?>
</style>

CSS reduceret med 45%

CSS kode har det med at vokse over tid og man får sjældent ryddet op løbende. Her skrev jeg alt fra bunden og jeg er nok også blevet bedre til at skrive CSS så det fylder mindre. Resultatet er en 45% reduktion af CSS fra 34,5 KB på i det gamle design til 19 KB i det nye design.

Væk med !important

Når jeg skriver !important i min CSS kode er det et tegn på at jeg har malet mig op i et hjørne.

Det er en sidste udvej. Og det kommer til at bide mig i røven senere hen.

Det gamle design brugte !important 35 gange.

Derfor har jeg fokuseret på at få gennemtænkt mine CSS selectors så jeg undgår at bruge !important i det nye design.

Jeg har også tænkt over at min styling skal cascade så meget som muligt, så jeg definerer mest muligt CSS kode på de øverste selectors (dem med lavest specificity) og derefter nedarves de bare til alt det øvrige. Det betyder også at jeg ikke overskriver min egen kode eller laver den samme styling flere gange på forskellige selectors.

Et eksempel er at jeg styler min font på html elementet og derefter nedarves det bare til resten af sitet, så jeg ikke skal style min font igen - lige bortset fra input elementer som ikke nedarver styling og derfor skal styling skrives specifikt på dem.

html
    background: $grey-dark
    color: $lightGrey
    font-family: -system-ui,-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol"
    -webkit-font-smoothing: antialiased
    -moz-osx-font-smoothing: grayscale
    letter-spacing: 0.02em
    font-size: 20px
    line-height: 1.75

Tit bruges !important også for at overskrive noget andet styling, fx noget CSS der kommer med et plugin. Det betyder dermed overflødig kode, som blot overskrives.

Det giver også browseren mere arbejde med at finde ud af hvad der skal overskrive noget andet.

Jeg har, så vidt det er muligt, deaktiveret den medfølgende CSS fra de enkelte plugins, så jeg blot får den rå HTML og selv skrevet alt styling. Dermed er jeg sikker på at der ikke kommer noget overflødig CSS kode med.

SVG til grafik

SVG er super fedt til grafiske elementer fordi det er kode og ikke et billede. Dermed kan det skalere uendeligt uden at blive grimt og det fylder meget lidt.

Jeg bruger det fx til den lille graf i mit logo.

Der er forskellige måder at indsætte et SVG billede på og jeg lytter til Chris Coyiers enorme erfaring om SVG (han har skrevet en bog om det: Practical SVG). Hans anbefaling er blot at inline SVG koden direkte i HTML’en. Det har han skrevet om her: A Pretty Good SVG Icon System

Jeg har alle mine SVG filer liggende i koden og selve koden til grafen i logoet kan ses herunder. Den fylder kun 848 bytes som SVG fil.

Indholdet af SVG filen indsætter jeg i header.php med følgende kode. Når SVG filen ligger i koden, skal der ikke laves et ekstra request for at hente den og færre requests er med til at gøre sitet hurtigt.

<a href="/" title="jacobworsoe.dk" rel="home" class="blog-title">
   <span class="logo"><?php include("svg/logo.svg"); ?></span>
   <span class="title"><?php bloginfo( 'name' ); ?></span>
</a>

WordPress

Væk med unødvendige plugins

Jeg har fået fjernet en del plugins, så det bliver mere simpelt, fjerner mulige sikkerhedshuller og gør sitet hurtigere.

Tabeller

TablePress er et fedt plugin, men de få simple tabeller jeg har i mine indlæg, kan jeg sagtens skrive i hånden, så væk med det.

Syntax highlighting

Jeg brugte Code Prettify til syntax highlighting af kode. Jeg er skiftet til at bruge Prism.js hvor jeg vælger præcis de kodesprog jeg skal bruge og så får jeg en CSS fil og en JavaScript fil. CSS filen inkluderer jeg i min SCSS fil og JavaScript filen bliver bundlet sammen med min øvrige JS kode i én samlet fil. Og så er dét plugin overflødigt :)

Jeg kan i øvrigt anbefale denne artikel med alle de forskellige muligheder for at skrive og vise kode i WordPress.

Relaterede indlæg

Jeg har brugt Yet Another Related Posts Plugin til at vise relaterede indlæg i bunden af hvert blogindlæg.

Jeg brugte Enhanced Ecommerce til at tracke impressions og clicks på dem og fandt ud af at de links havde en CTR på 0,42% så for 99,58% var de bare ligegyldigt støj på siden. Så jeg fjernede dem inklusiv det plugin.

Jeg fjernede i øvrigt også links til de seneste blogindlæg, da de havde en endnu lavere CTR på 0,05% - disse blev ikke lavet med et plugin, men det er altid godt at få fjernet unødvendigt støj.

Loadtid og konvertering

Okay, det var en lang teknisk snak. Nu skal vi se om det har givet de ønskede resultater.

Google Pagespeed Score hævet fra 86 til 99

Det gamle design havde en pagespeed score på 86 for desktop. Den er nu 99.

Den vigtige metric er dog mobile nu og den er 96.

Er sitet så blevet hurtigere?

Ja, det er det. I gennemsnit er loadtiden blevet forbedret 29%.

Men gennemsnit kan snyde meget og skjule sandheden.

Ikke alle sider loader lige hurtigt.

Jeg har blogindlæg på mere end 6000 ord med masser af billeder. Jeg har meget populære blogindlæg som står for 70% af sidevisningerne som kun har få, men til gengæld meget store billeder. Og så er der forsiden som stort set kun er tekst.

Især det faktum at de har meget forskellige antal sidevisninger gør at de fylder meget forskelligt i gennemsnittet.

Lad os derfor kigge på top 10 mest populære sider hver for sig, samt et vægtet gennemsnit for de sider. Alle top 10 sider er blevet hurtigere, men der er stor forskel på hvor meget de er forbedret.

22% er et mere retvisende gennemsnit for udviklingen i loadtid.

Hvad med konvertering?

Jeg har tidligere skrevet om hvordan jeg bruger Enhanced Ecommerce til at tracke om brugerne læser mine blogindlæg.

Kort fortalt tracker jeg hvor mange der scroller helt til bunden af et blogindlæg og har været mindst 1 minut på siden. Det er den vigtigste KPI for min blog. Hvor mange læser hele blogindlægget?

For hvert blogindlæg har jeg en Buy-to-detail Rate, som er forholdet mellem antal sidevisninger og antal læsninger.

På trods af at loadtiden er markant forbedret for alle blogindlæg, så er konverteringen desværre ikke steget - tværtimod.

Jeg tror den store årsag til den lavere konvertering skyldes designet. Jeg har skruet op for font-size fra 17px til 20px i det nye design og gjort overskrifter markant større og givet det hele lidt mere “luft”. Det gør det nemmere at læse, men siden bliver også markant længere. Måske føles det som et længere blogindlæg at tygge sig igennem?

Bounce Rate er ligeledes uændret, på trods af den hurtigere loadtid.

Så det nye design har ikke haft den ønskede effekt på konverteringen. Det må jeg gøre bedre i næste design.

Øge sidevisninger pr. besøg

Jeg har læst Don’t Make Me Think mange gange og den kan anbefales til alle der arbejder med noget digitalt.

Her er en god pointe fra bogen omkring navigation.

Som tidligere vist, så har sitet en Bounce Rate på 85% og der bliver kun set 1,17 sider pr. session.

Jeg vil gerne at brugerne fortsætter rundt på sitet og ser nogle flere blogindlæg.

Det gamle design havde ikke en menu, så jeg tilføjede en burger menu som viser sitets kategorier, som Steve Krug anbefaler i Don’t Make Me Think.

Jeg tracker både hvor mange der åbner burger menuen og hvor mange der klikker i den.

• 1,6% af alle besøg åbner menuen.
• 0,4% af alle besøg klikker på noget i menuen.

Her er de kategorier der bliver klikket på.

Umiddelbart en ret lav konverteringsrate og sider pr. besøg er dog også uændret.

Så selvom Steve Krug har ret i mange ting, så virker en burger menu altså ikke på dette site. Jeg må i tænkeboks.

Til sammenligning er der 0,47% der klikker på et internt link når jeg i et blogindlæg, linker til et andet af mine blogindlæg.

Lykkedes målene?

Lad os se.

1. Mere moderne workflow til udvikling af websitet - Tjek!
2. Oprydning i kode og sletning af unødvendige ting - Tjek!
3. Hurtigere loadtid - Tjek!
4. Højere konvertering - Nope!
5. Øge sidevisninger pr. besøg - Nope!

Antal månedlige besøg er vigtig.

Trafik fordelt på kanaler er også vigtig at vide. Og måske også om de besøgende tilmelder sig nyhedsbrevet.

Men hvordan måles konvertering?

Man kan tracke når nogen skriver en kommentar. Men da diskussionen i høj grad er flyttet over til de sociale medier hvor indlægget deles, så er det ikke et godt mål for konvertering på en blog. Siden jeg startede min blog i 2009 har jeg til dato haft 118.121 besøg og 482 kommentarer, hvilket giver en konverteringsrate på 0,4%.

Det kan også være tilmelding til RSS feed, men selvom det er min foretrukne måde at holde mig opdateret med en lang række blogs, så har jeg på fornemmelsen, at det er meget få der bruger det. Det samme med nyhedsbreve for blogs.

Endelig er der metrics som bounce rate og time on page. Men de er svære at konkludere noget ud fra isoleret set. Jeg har en bounce rate på 85% på dette site. Det er højt, men det betyder ikke nødvendigvis at mine blogindlæg ikke bliver læst grundigt. Det kan sagtens være brugerne er på sitet mange minutter og stadig bouncer. Det betyder bare at de kun læser ét blogindlæg.

Time on page bliver ikke målt på den sidste side i et besøg, så med en bounce rate på 85% er det sjældent den bliver målt. Den metric er også farlig at konkludere noget ud fra, da brugeren ikke nødvendigvis forlader siden, men fx blot loader en ny side i en anden tab.

Bliver indholdet rent faktisk læst?

Selvom det er fedt med mange besøg og sidevisninger, så siger det ikke i sig selv noget om kvaliteten af indholdet. Det er vigtigt at vide om brugerne rent faktisk læser indlægget.

Og det er lige præcis den form for konvertering der er vigtig for en blog, så i dette indlæg viser jeg hvordan jeg bruger Google Analytics Enhanced Ecommerce til at tracke mit indhold og den verden af nye indsigter det åbner op for.

Inspireret af Simo Ahava

Jeg elsker at finde nye kreative måder at bruge Google Analytics og Enhanced Ecommerce til at indsamle data og få et nyt indblik i alt fra websites til den fysiske verden.

Det gør Simo Ahava også og mit tracking setup er også kraftigt inspireret af det setup han har lavet på sin egen blog og skrevet om her: Track Content With Enhanced Ecommerce

Selve logikken i koden er kopieret fra Simo’s Github som er baseret på Justin Cutroni’s scroll script.

Jeg har derefter omskrevet det til ren JavaScript, så det ikke er afhængigt af jQuery, for at slippe for at skulle loade jQuery på sitet. Jeg brugte den her rigtig meget for at konvertere koden: youmightnotneedjquery.com

Derudover har jeg lavet tre udvidelser af koden:

• Jeg tracker kun impressions af blogindlæg på forsiden og andre lister, hvis de har været synlige på skærmen
• Jeg tracker brugere der kun skimmer artiklen, uden at læse den
• Alle data er udstillet i dataLayer og jeg scraper derfor ikke noget indhold med JavaScript

Mere om det senere.

Tracking af læsning af indhold med Enhanced Ecommerce

Okay, lad os lige starte med at se på hvordan man overhovedet kan bruge Enhanced Ecommerce til at tracke når brugerne læser indholdet på en blog. Det kræver nemlig at man er lidt kreativ med fortolkningerne af Ecommerce og checkout.

Her er definitionerne af Enhanced Ecommerce, som jeg bruger på min blog:

• Produkt: Et blogindlæg.
• Produkt navn: Titlen på blogindlægget.
• Produkt pris: Antal ord i blogindlægget.
• Produkt kategori: WordPress kategori, fx "Webanalyse" eller "SEO".
• Produkt brand: Blogindlæggets udgivelsesår.
• Produkt impression: Når et blogindlæg bliver vist på en liste, fx forsiden, kategorisider, tagsider, relateret blogindlæg eller lignende.
• Produkt lister: Alle ovenstående lister.
• Produkt click: Når en bruger klikker på et blogindlæg på en af ovenstående lister.
• Produkt detail view: Når et blogindlæg vises (dvs. sidevisning af et blogindlæg).
• Produkt add to cart: Når brugeren begynder at scrolle og dermed om de er begyndt at læse indlægget.
• Produkt checkout: Der er 3 steps i checkout, som er afhængige af hvor langt brugeren scroller. Step 1 er 33%, step 2 er 66% og step 3 er 100% af indlægget. Her måler jeg kun højden på selve indlægget, dvs. kommentarer er ikke med.
• Gennemført købt: Når brugeren har scrollet 100% af indlægget og været mindst 1 minut på siden. Dermed kan jeg antage at indlægget rent faktisk er læst og ikke bare skimmet.

Lad os få styr på produktdata

På alle sider hvor der vises et eller flere indlæg, skal der trackes en række produktdata for hvert indlæg.

ID og navnet (titlen) på indlægget kan fanges i Wordpress i The Loop med de indbyggede funktioner the_title() og the_ID() og gemmes i en JavaScript variabel, så de kan sendes til Google Analytics. Årstallet som gemmes i brand hentes med the_time('Y').

Et indlæg kan tilhøre flere kategorier og hvis du bruger Yoast SEO er der mulighed for at angive en primær kategori. Hvis et indlæg tilhører flere kategorier, bruges kun den primære. Den logik kan kodes således:

// SHOW YOAST PRIMARY CATEGORY, OR FIRST CATEGORY
$category = get_the_category();
$useCatLink = true;

// If post has a category assigned.
if ($category){
    $category_display = '';
    $category_link = '';
    if ( class_exists('WPSEO_Primary_Term') )
    {
        // Show the post's 'Primary' category, if this Yoast feature is available, & one is set
        $wpseo_primary_term = new WPSEO_Primary_Term( 'category', get_the_id() );
        $wpseo_primary_term = $wpseo_primary_term->get_primary_term();
        $term = get_term( $wpseo_primary_term );
        if (is_wp_error($term)) { 
            // Default to first category (not Yoast) if an error is returned
            $category_display = $category[0]->name;
            $category_link = get_category_link( $category[0]->term_id );
        } else { 
            // Yoast Primary category
            $category_display = $term->name;
            $category_link = get_category_link( $term->term_id );
        }
    } 
    else {
        // Default, display the first category in WP's list of assigned categories
        $category_display = $category[0]->name;
        $category_link = get_category_link( $category[0]->term_id );
    }

    // Display category
    if ( empty($category_display) ) {
        $category_display = "Ingen kategori";
    }   
}

Derefter udskrives kategorien med <?php echo $category_display; ?>.

Prisen er antal ord og der har PHP en indbygget funktion str_word_count som tæller antal ord i en streng - i dette tilfælde den aktuelle artikel. Jeg har lagt det i en funktion i functions.php så jeg nemt kan kalde den med word_count() i single.php.

function word_count() {
    $content = get_post_field( 'post_content', $post->ID );
    $word_count = str_word_count( strip_tags( $content ) );
    return $word_count;
}

I Enhanced Ecommerce er det vigtigt at produktdata er formateret med præcis den rigtige syntaks - ellers vil der ikke blive sendt nogen produktdata til Google Analytics for dét request. Det færdige Product object med den korrekte syntaks ser således ud:

var product = [{
    name: '',
    id: '',
    price: '',
    brand: '',
    category: '',
    variant: '',
    quantity: 1
  }];

Product impressions efter 2 sekunder

Det første trin i kunderejsen er product impressions på en produktliste.

Der vises lister af blogindlæg på forsiden, kategorisider, som relaterede indlæg, etc. Der er primært to ting der er vigtige når der trackes impressions.

1. Der skal kun trackes impressions af blogindlæg som brugeren rent faktisk har set. Det er ikke nok at linket til blogindlægget har været længere nede på siden (below the fold), eller at brugeren har scrollet lynhurtigt forbi det. Brugeren skal have set blogindlægget og jeg skal være rimelig sikker på at brugeren har set og forholdt sig til det.

2. Trackingen må ikke sløve brugerens computer og gøre sitet langsomt. Når jeg skal holde øje med hvor langt brugeren scroller ned af siden og dermed om et givent blogindlæg er blevet synligt på skærmen, kan jeg nemt risikere at der skal køres noget JavaScript kode meget ofte, især hvis brugeren scroller hurtigt ned over siden. Dette kan påvirke hvor gnidningsfrit scrollet opleves for brugeren.

I værste fald kan det gøre sitet ubrugeligt, som det skete for Twitter tilbage i 2011.

Depending upon the browser the scroll event can fire a lot and putting code in the scroll callback will slow down any attempts to scroll the page (not a good idea). Instead it’s much better to use some form of a timer to check every X milliseconds OR to attach a scroll event and only run your code after a delay.John Resig, skaberen af jQuery

Begge ting kan løses med en debounce funktion.

En debounce funktion siger: “Udfør denne kode når noget ikke er sket i X antal millisekunder”.

Denne artikel fra CSS-Tricks.com har nogle gode visualiseringer og demoer som viser hvordan debounce virker. David Walsh har også skrevet om det her.

I dette tilfælde køres koden når brugeren stopper med at scrolle i 2 sekunder. Hvis brugeren scroller igen inden de 2 sekunder er gået, nulstilles timeren og når brugeren stopper med at scrolle, starter timeren igen fra 0 og hvis der går 2 sekunder uden scroll, udføres koden.

Og sidst men ikke mindst skal der kun trackes impressions for et produkt én gang på hver side.

Lad os kigge på koden.

Først er der lavet tre funktioner. Den første tjekker om et element er synligt på skærmen.

function checkVisible(elm) {
  var rect = elm.getBoundingClientRect();
  var viewHeight = Math.max(document.documentElement.clientHeight, window.innerHeight);
  return !(rect.bottom < 0 || rect.top - viewHeight >= 0);
}   

Bemærk! Jeg lavede dette tilbage i 2016. Hvis det skal laves i dag, kan du med fordel bruge Intersection Observer som er et asynkront API til netop at holde øje med hvornår elementer bliver synlige i viewport og den kan også holde styr på hvilke der har været synlige, så man ikke selv skal sørge for at de ikke tracker flere gange. Browser support er rigtig god i dag, så den bør bruges fremover.

Den næste laver et Enhanced Ecommerce product object med de relevante produktdata for et blogindlæg som er synligt på skærmen.

function pushProducts(productElement, i) {
  ga_products.push({
    name: productElement[i].dataset.title,
    id: productElement[i].dataset.id,
    price: productElement[i].dataset.price,
    brand: productElement[i].dataset.year,
    category: productElement[i].dataset.category,
    variant: productElement[i].dataset.author,
    list: pageType,
    position: productElement[i].dataset.position
  });
}

Produktdataene er placeret i data attributter i HTML koden.

<h1 class="home-post-headline">
    <a href="/returvarer-google-analytics/" 
        data-title="Tracking af returvarer i Google Analytics (den ultimative guide)" 
        data-id="1597" 
        data-category="Webanalyse" 
        data-year="2019" 
        data-author="2" 
        data-price="3668" 
        data-position="2"
        class="home-post-link">
        Tracking af returvarer i Google Analytics (den ultimative guide)            
    </a>
</h1>

Den tredje funktion sender impressions til Google Analytics.

function sendProducts(trigger) {
  window.dataLayer = window.dataLayer || [];
  dataLayer.push({
    event: trigger,
    ecommerce: {
      impressions: window.ga_products
    }
  });
  window.ga_products = [];
}

Ved pageload bygges et JavaScript object med sidens blogindlæg og der checkes om nogle af sidens blogindlæg er synlige, dvs. dem som er above-the-fold. De synlige blogindlæg pushes til products objectet med pushProducts().

Hvis der er blogindlæg som ikke er synlige, tilføjes de til ga_products_not_visible objectet som vi derefter kan holde øje med om de bliver synlige i 2 sekunder og tracke en impression for dem.

// Cache product element
var articles = document.querySelectorAll(".home-post-headline a");

// See if products are in view
if (articles && articles.length > 0) {
  for (var i = 0; i < articles.length; i++) {
    if (checkVisible(articles[i])) {
      pushProducts(articles, i);
    } else {
      ga_products_not_visible.push(articles[i]);
    }
  }
}

Hvis der var nogle synlige blogindlæg, pushes de til dataLayer, så de bliver sendt med, sammen med pageview requestet for siden.

// If any products was in view on pageload, send those products
if (ga_products.length > 0) {
  window.dataLayer = window.dataLayer || [];
  dataLayer.push({
    ecommerce: {
      impressions: window.ga_products
    }
  });
  window.ga_products = [];
}

Okay, nu har vi styr på blogindlæg som er above-the-fold. Nu skal vi tracke impressions for dem som er below-the-fold.

Fordi det kan være lidt tungt at tracke på scroll, så skal det kun gøres hvis der rent faktisk er nogle produkter below-the-fold, så det starter vi med at tjekke med ga_products_not_visible.length.

Derefter defineres en funktion som køres hver gang der scrolles.

Det første funktionen gør, når der scrolles er clearTimeout som nulstiller timeren.

Derefter startes en ny setTimeout som indeholder den kode som køres efter 2000 millisekunder.

Når de 2000 millisekunder er gået udføres koden, som tjekker om nogle af de blogindlæg der endnu ikke er tracket en impression af, er synlige på skærmen. Hvis det er tilfældet bliver de tilføjet til products objectet og fjernet fra listen over blogindlæg der ikke er tracker en impression for, så de ikke kan trackes igen. Til sidst sendes de til Google Analytics med et event.

Men! Hvis der scrolles inden de 2000 millisekunder er gået, så køres hele koden igen og det første i koden er at nulstille timeren og starte den på ny som beskrevet herover.

Dette er “magien” bag en debounce funktion. Den sørger for at koden ikke afvikles med det samme der scrolles, men først efter en pause på 2000 millisekunder, hvilket både gør sitet mere flydende, men også sikrer at brugeren skal stoppe med at scrolle i 2000 millisekunder (og dermed formentlig har vurderet om de vil klikke på linket) før vi tracker en impression.

// If page contained products not in view, start the scroll tracker
if (ga_products_not_visible.length > 0) {
  var scrollTimeout;

  function checkProductsInViewOnScroll() {
    clearTimeout(scrollTimeout);

    scrollTimeout = setTimeout(function() {
      for (var i = ga_products_not_visible.length - 1; i >= 0; i--) {
        if (checkVisible(ga_products_not_visible[i])) {
          pushProducts(ga_products_not_visible, i);

          // Remove the product in view from ga_products_not_visible
          ga_products_not_visible.splice(i, 1);
        }
      }

      if (ga_products.length > 0) {
        sendProducts("moreImpressionsSent");
      }
    }, 2000);
  }

  // Start scroll listener
  window.addEventListener("scroll", checkProductsInViewOnScroll);
}

Her er den samlede kode til at tracke impressions på lister.

// Set objects to store posts
window.ga_products = window.ga_products || [];
window.ga_products_not_visible = window.ga_products_not_visible || [];

function checkVisible(elm) {
  var rect = elm.getBoundingClientRect();
  var viewHeight = Math.max(
    document.documentElement.clientHeight,
    window.innerHeight
  );
  return !(rect.bottom < 0 || rect.top - viewHeight >= 0);
}

function pushProducts(productElement, i) {
  ga_products.push({
    name: productElement[i].dataset.title,
    id: productElement[i].dataset.id,
    price: productElement[i].dataset.price,
    brand: productElement[i].dataset.year,
    category: productElement[i].dataset.category,
    variant: productElement[i].dataset.author,
    list: pageType,
    position: productElement[i].dataset.position
  });
}

function sendProducts(trigger) {
  window.dataLayer = window.dataLayer || [];
  dataLayer.push({
    event: trigger,
    ecommerce: {
      impressions: window.ga_products
    }
  });
  window.ga_products = [];
}

// Cache product element
var articles = document.querySelectorAll(".home-post-headline a");

// See if products are in view
if (articles && articles.length > 0) {
  for (var i = 0; i < articles.length; i++) {
    if (checkVisible(articles[i])) {
      pushProducts(articles, i);
    } else {
      ga_products_not_visible.push(articles[i]);
    }
  }
}

// If any products was in view on pageload, send those products
if (ga_products.length > 0) {
  window.dataLayer = window.dataLayer || [];
  dataLayer.push({
    ecommerce: {
      impressions: window.ga_products
    }
  });
  window.ga_products = [];
}

// If page contained products not in view, start the scroll tracker
if (ga_products_not_visible.length > 0) {
  var scrollTimeout;

  function checkProductsInViewOnScroll() {
    clearTimeout(scrollTimeout);

    scrollTimeout = setTimeout(function() {
      for (var i = ga_products_not_visible.length - 1; i >= 0; i--) {
        if (checkVisible(ga_products_not_visible[i])) {
          pushProducts(ga_products_not_visible, i);

          // Remove the product in view from ga_products_not_visible
          ga_products_not_visible.splice(i, 1);
        }
      }

      if (ga_products.length > 0) {
        sendProducts("moreImpressionsSent");
      }
    }, 2000);
  }

  // Start scroll listener
  window.addEventListener("scroll", checkProductsInViewOnScroll);
}

Antal impressions falder dermed jo længere ned på forsiden man kommer og de første to positioner har stort set samme antal impressions, da de er above-the-fold, både på mobile og desktop.

Produkt click med et callback

Når brugeren klikker på et blogindlæg, skal klikket trackes. Udfordringen er at siden skifter når man klikker og derfor er der risiko for at requestet ikke når at blive sendt til Google Analytics, før siden er skiftet og dermed bliver det aldrig sendt.

Løsningen er at annullere sideskiftet med JavaScript og istedet få GTM til at lave sideskiftet i et callback efter requestet er succesfuldt sendt til Google Analytics.

Der er særligt to ting der er vigtige at tage højde for når man annullerer et sideskift.

1. Hvis requestet til Google Analytics fejler eller GTM ikke bliver loaded korrekt på siden, kan det betyde at sideskiftet aldrig bliver lavet.

2. Hvis brugeren holder CTRL (eller CMD på Mac) nede mens der klikkes på linket for at åbne det i en ny tab, skal der ikke laves et sideskift, da brugeren jo netop gerne vil blive på siden.

Den første kan løses ved at lave et timeout på fx 2 sekunder, så sideskiftet bliver lavet uanset hvad, hvis requestet til Google Analytics ikke er gennemført efter 2 sekunder.

Den anden kan løses ved at tjekke om click eventet har enten event.ctrlKey (Windows) eller event.metaKey (Mac) for at tjekke om brugeren holder CTRL/CMD nede mens der klikkes.

Alt logikken tilføjes til det dataLayer.push som udføres når brugeren klikker på et blogindlæg på en liste, fx forsiden.

dataLayer.push({
  event: "productClick",
  ecommerce: {
    click: {
      actionField: { list: pageType },
      products: [
        {
          name: title,
          id: id,
          price: price,
          brand: author,
          category: category,
          variant: year,
          position: position
        }
      ]
    }
  },
  eventCallback: function() {
    if (!e.ctrlKey && !e.metaKey) {
      window.location = href;
    }
  },
  eventTimeout: 2000
});

Brugbar CTR på produktlister

Når der er styr på tracking af blogindlæg som har været på brugerens skærm i 2 sekunder, samt kliks, fås en meget mere brugbar CTR for de enkelte blogindlæg på de forskellige lister.

Brugbar fordi jeg ved at brugeren har haft tid til at læse overskriften og vurdere om blogindlægget er spændende og relevant. Det er helt afgørende for at man faktisk kan konkludere noget på baggrund af CTR.

Brugerne klikker ikke på relaterede og nyeste indlæg

Jeg har brugt Enhanced Ecommerce til at tracke min blog siden 2016. Da jeg gav bloggen et redesign i starten af 2019 undersøgte jeg hvor mange der klikker, når der vises relaterede indlæg i bunden af et indlæg eller klikker på listen af nyeste blogindlæg.

Det gør de ikke.

Slet ikke.

Bemærk de meget forskellige antal impressions. Som beskrevet ovenfor tracker jeg kun impressions når links er synlige på skærmen og brugeren ikke har scrollet i 2 sekunder.

Nyeste indlæg vises i højre side højt oppe på siden, mens relaterede indlæg vises i bunden af blogindlæg, så der er langt færre der scroller helt ned til dem.

Fordi der er meget få kliks er det svært at optimere ud fra. Men hvis der havde været nogle flere kliks, ville det være oplagt at kigge på hvilke blogindlæg der fungerer godt når de vises som relaterede indlæg:

CTR på de links var dermed så lav, at de for langt de fleste brugere ikke er brugbare links, og dermed blot støj. Jeg valgte derfor at fjerne dem i det nye design og dermed få et mere clean design.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.Antoine de Saint-Exupery

Til sammenligning har links på forsiden en CTR på 4,92%.

Screenshottet viser i øvrigt en kritisk vigtig ting i Enhanced Ecommerce og analytics generelt: Konsistent data.

Da jeg redesignede bloggen omskrev jeg alt JavaScript fra bunden, så det var skrevet i ren JavaScript (dvs. uden jQuery) og samtidig fulgte den samme gode kodestruktur.

Det betød desværre at jeg kom til at omdøbe Forsidens product list name fra Forsiden til homepage og dermed er data nu splittet.

Doh!

Lesson learned.

Produkt detaljevisning, add to cart og checkout

Okay, nu skal vi videre ned gennem tragten. Næste skridt fra product click er detail view. Nu gennemgår jeg alt det der sker på et blogindlæg.

Når et blogindlæg vises starter jeg med at sætte en række variabler, som bruges til at styre scroll trackingen. Der sættes det samme scrollTimeout på 2000 millisekunder som ved impressions og jeg sætter at brugeren mindst skal scrolle 150 pixels før de er begyndt at læse indlægget.

Derefter sættes en variabel til false for hvert event/state ned gennem siden. Når brugeren scroller til et punkt affyres et event og det sættes derefter til true så det samme event ikke trackes igen, hvis brugeren scrolle op igen.

Derefter vælges den div som indeholder blogindlægget, så jeg kan måle højden på den div og holde øje med hvor langt brugeren scroller. Bemærk at kommentarerne under indlægget ikke er med i denne div, så det er kun selve indlægget jeg kigger på.

Til sidst gemmes det aktuelle tidspunkt, som bruges til at afgøre hvor længe brugeren har været aktiv på siden.

// Default time delay before checking location
var scrollTimeout = 2000;

// # px before tracking a reader
var readerLocation = 150;

// Set some flags for tracking & execution
var timer = 0;
var scroller = false;
var oneThird = false;
var twoThirds = false;
var endContent = false;
var didComplete = false;
var purchase = false;

// Content area DIV class
var contentArea = document.querySelector(".post-content");

// Set some time variables to calculate reading time
var startTime = new Date();
var beginning = startTime.getTime();
var totalTime = 0;

Derefter pushes en Enhanced Ecommerce action sat til detail som sendes med sidevisningen når brugeren lander på blogindlægget. Konsistens er vigtig i Enhanced Ecommerce, så de produktdata der sendes med her, skal være identiske med dem som bruges ved impressions og click.

// Track the article load as a Product Detail View
dataLayer.push({
   ecommerce: {
     detail: {
       products: product
     }
   }
});

Derefter defineres den funktion som affyres når brugeren ikke har scrollet i 2000 millisekunder.

// Check the location and track user
function trackLocation() {
  clearTimeout(scrollTimeout);

  scrollTimeout = setTimeout(function() {
// Herinde placeres alt koden som affyres efter 2000 millisekunder

    }
  }, 2000);
}

// Track the scrolling and track location
window.addEventListener("scroll", trackLocation);
},

Når brugeren begynder at scrolle på siden og dermed begynder at læse indholdet, trackes dette med et add to cart event. Her bruger jeg samme debounce funktion som tidligere, sat til 2 sekunder.

scrollTimeout = setTimeout(function() {
    bottom = window.innerHeight + window.pageYOffset;

    // If user starts to scroll send an event
    if (bottom > readerLocation && !scroller) {
      dataLayer.push({
        event: "addToCart",
        ecommerce: {
          add: {
            products: product
          }
        }
      });
      scroller = true;          
    }

Når brugeren lander på siden måles højden på artiklen i pixels, som bruges til at tracke hvor meget af artiklen der læses. Hvis brugeren scroller 33% af artiklen, trackes checkout step 1.

Ved 66% trackes step 2 og ved 100% af artiklen trackes step 3.

// If one third is reached
if (
  bottom >= contentArea.offsetTop + contentArea.clientHeight / 3 &&
  !oneThird
) {
  dataLayer.push({
    event: "checkout",
    ecommerce: {
      checkout: {
        actionField: { step: 1, option: product[0].variant },
        products: product
      }
    }
  });
  oneThird = true;
}

// If two thirds is reached
if (
  bottom >= contentArea.offsetTop + contentArea.clientHeight / 3 * 2 &&
  !twoThirds
) {
  dataLayer.push({
    event: "checkout",
    ecommerce: {
      checkout: {
        actionField: { step: 2, option: product[0].variant },
        products: product
      }
    }
  });
  twoThirds = true;          
}

// If user has hit the bottom of the content send an event
if (
  bottom >= contentArea.offsetTop + contentArea.clientHeight &&
  (!endContent || !purchase)
) {
  if (!endContent) {
    dataLayer.push({
      event: "checkout",
      ecommerce: {
        checkout: {
          actionField: { step: 3, option: product[0].variant },
          products: product
        }
      }
    });
    endContent = true;
  }
}

Tracking af læste blogindlæg som køb

Hvis brugeren har været på siden mere end 1 minut, når der er scrollet 100% af artiklen, antages det at brugeren har læst artiklen og ikke bare skimmet den og den handling trackes som et køb. Prisen på ordren er antal ord i blogindlægget og dermed kan man se hvor mange artikler og ord der bliver læst på bloggen.

// If user has reached end of funnel, check if 60 seconds is passed
if (endContent && !purchase) {
  currentTime = new Date();
  contentScrollEnd = currentTime.getTime();
  timeToContentEnd = Math.round((contentScrollEnd - beginning) / 1000);
  if (timeToContentEnd > 60 && !purchase) {
    // Track purchase
    dataLayer.push({
      event: "purchase",
      ecommerce: {
        purchase: {
          actionField: {
            id:
              new Date().getTime() +
              "_" +
              Math.random()
                .toString(36)
                .substring(5),
            revenue: product[0].price
          },
          products: product
        }
      }
    });

    // Only do this once!
    purchase = true;
  } else {
    dataLayer.push({
      event: "scrollToEndBeforeOneMinute",
      product: product[0].name
    });
  }
}

Den samlede kode for tracking af læsning af et blogindlæg ser dermed således ud:

// Track single post as product
trackSinglePostAsProduct: function(product) {
  // Default time delay before checking location
  var scrollTimeout = 2000;

  // # px before tracking a reader
  var readerLocation = 150;

  // Set some flags for tracking & execution
  var timer = 0;
  var scroller = false;
  var oneThird = false;
  var twoThirds = false;
  var endContent = false;
  var didComplete = false;
  var purchase = false;

  // Content area DIV class
  var contentArea = document.querySelector(".post-content");

  // Set some time variables to calculate reading time
  var startTime = new Date();
  var beginning = startTime.getTime();
  var totalTime = 0;

  // Track the article load as a Product Detail View
  dataLayer.push({
    ecommerce: {
      detail: {
        products: product
      }
    }
  });

  // Check the location and track user
  function trackLocation() {
    clearTimeout(scrollTimeout);

    scrollTimeout = setTimeout(function() {
      bottom = window.innerHeight + window.pageYOffset;

      // If user starts to scroll send an event
      if (bottom > readerLocation && !scroller) {
        dataLayer.push({
          event: "addToCart",
          ecommerce: {
            add: {
              products: product
            }
          }
        });
        scroller = true;          
      }

      // If one third is reached
      if (
        bottom >= contentArea.offsetTop + contentArea.clientHeight / 3 &&
        !oneThird
      ) {
        dataLayer.push({
          event: "checkout",
          ecommerce: {
            checkout: {
              actionField: { step: 1, option: product[0].variant },
              products: product
            }
          }
        });
        oneThird = true;
      }

      // If two thirds is reached
      if (
        bottom >= contentArea.offsetTop + contentArea.clientHeight / 3 * 2 &&
        !twoThirds
      ) {
        dataLayer.push({
          event: "checkout",
          ecommerce: {
            checkout: {
              actionField: { step: 2, option: product[0].variant },
              products: product
            }
          }
        });
        twoThirds = true;          
      }

      // If user has hit the bottom of the content send an event
      if (
        bottom >= contentArea.offsetTop + contentArea.clientHeight &&
        (!endContent || !purchase)
      ) {
        if (!endContent) {
          dataLayer.push({
            event: "checkout",
            ecommerce: {
              checkout: {
                actionField: { step: 3, option: product[0].variant },
                products: product
              }
            }
          });
          endContent = true;
        }
      }

      // If user has reached end of funnel, check if 60 seconds is passed
      if (endContent && !purchase) {
        currentTime = new Date();
        contentScrollEnd = currentTime.getTime();
        timeToContentEnd = Math.round((contentScrollEnd - beginning) / 1000);
        if (timeToContentEnd > 60 && !purchase) {
          // Track purchase
          dataLayer.push({
            event: "purchase",
            ecommerce: {
              purchase: {
                actionField: {
                  id:
                    new Date().getTime() +
                    "_" +
                    Math.random()
                      .toString(36)
                      .substring(5),
                  revenue: product[0].price
                },
                products: product
              }
            }
          });

          // Only do this once!
          purchase = true;
        } else {
          dataLayer.push({
            event: "scrollToEndBeforeOneMinute",
            product: product[0].name
          });
        }
      }
    }, 2000);
  }

  // Track the scrolling and track location
  window.addEventListener("scroll", trackLocation);
},

Dataene kan blandt andet ses i Product Performance rapporten.

Analyse af Ecommerce data for min blog

Okay, lad os kigge på det data jeg kan få ud af alt det her.

Shopping behaviour

En af de fedeste rapporter i Enhanced Ecommerce er Shopping Behaviour, som viser en komplet funnel over hele websitet fra total antal sessioner til antal køb.

Her ses frafaldet i hvert step mod læste blogindlæg.

Jeg kan se at en stor del af de besøgende ser blogindlæg (faktisk hele 96%) og rigtige mange begynder at scrolle (add to cart). 85% af dem der scroller når også ned til den første 1/3 af indlægget (checkout) men kun 20% af dem læser et blogindlæg. Der er et stort frafald på det sidste step.

Det kigger vi lige nærmere på med Checkout behaviour.

Antal sessioner bliver cirka halveret i hvert step, men dog er 78% af dem som scroller helt til bunden også på siden længe nok, til at de læser blogindlægget og tracket som et køb.

Ekskludering af irrelevante blogindlæg

Mit mest besøgte blogindlæg er uden sammenligning min infografik over hvor meget der blev drukket til vores bryllup.

Jeg har brugt Enhanced Ecommerce til at tracke min blog siden december 2016 og siden da har den infografik stået for 77% af alle sidevisninger.

Målgruppen og adfærden på det blogindlæg er markant anderledes end de andre blogindlæg jeg skriver om digital marketing, så derfor udelukker jeg den med et segment, i alle de nedenstående analyser.

Top 10 blogindlæg

Herunder ses top 10 blogindlæg baseret på sidevisninger (detail views) samt deres Buy-to-Detail Rate.

Eller sagt på en anden måde: En vanity metric mod en engagement metric.

Bemærk de kæmpe forskelle i engagement!

Konverteringsrate pr. trafikkilder

Med infografikken fjernet, kan jeg se om besøg fra forskellige kilder egentlig læser mine blogindlæg.

Gennemsnittet for sitet er en konverteringsrate på 26,58% hvilket vil sige at 27% af trafikken læser mindst ét blogindlæg. Det er jeg egentlig godt tilfreds med.

• Organisk trafik har en konvertering på 24,33% dvs. tæt på gennemsnittet.
• Social er høj hvor 34% læser blogindlægget når det bliver delt.
• E-mail er ekstremt høj hvor 43% læser blogindlægget. Næsten dobbelt så højt som gennemsnittet. Jeg sender kun e-mails ud, når jeg skriver nye blogindlæg, så det giver god mening at folk kun klikker på links i de e-mails, hvis de synes blogindlægget ser spændende ud. Men alligevel :)

Lad os først lige kigge nærmere på social og de posts jeg selv laver, når jeg har skrevet et nyt blogindlæg.

Konverteringen her er markant højere end gennemsnittet på 27% men det er interessant at facebook konvertere lavere end de andre. Jeg poster typisk kun i Analytics-nørder - den hårde kerne hvor alle er interesseret i Analytics. På LinkedIn og Twitter ryger den bredt ud til mit netværk, som nok er en lidt mere blandet skare, men til trods for det, så er der flere der læser hele indlægget.

Bliver blogindlæg læst eller bare skimmet?

Hvis brugeren scroller helt til bunden af et blogindlæg inden der er gået 60 sekunder, har brugeren kun skimmet blogindlægget. Der er ikke noget godt Enhanced Ecommerce event der passer til det, så det derfor tracker jeg det blot som et normalt Event.

Jeg laver 3 segmenter, som allesammen har en detaljevisning i deres session:

1. Sessioner som kun skimmer
2. Sessioner som kun læser
3. Sessioner som både skimmer og læser

De tre segmenter kan brydes ned på device og dermed se adfærden.

• Der er altså 26% der kun skimmer et blogindlæg, mens hele 63% læser blogindlægget uden at skimme det først. Det er overraskende. Jeg havde egentlig forventet at langt flere startede med at skimme og derefter læse, hvis det så spændende ud - fx. masser af billede og ikke bare wall of text. Men det er faktisk kun 11% der først skimmer og derefter læser indlægget.
• Det er dem som scroller helt til bunden inden der er gået et minut, og derefter bliver på siden og stadig er aktive (dvs. scroller) når der er gået et minut.
• Det er derimod ikke overraskende at der er næsten dobbelt så mange der skimmer på desktop i forhold til mobile devices, da det er meget nemmere at scrolle ned i bunden på en desktop, fx med scroll-hjulet på musen eller "page down"-tasten. Det er lidt tungere at scrolle et langt indlæg igennem med swipe på en telefon.

Bliver lange blogindlæg læst mere end korte blogindlæg?

I Product Performance rapporten kan du se Average price og But-to-detail rate. Med de to tal kan du se sammenhængen mellem blogindlæggets længde (prisen) og sandsynligheden for at det bliver læst.

Du plotter tallene på et Scatter Plot i Excel og tilføjer en trendlinje, som viser sammenhængen.

Trendlinjen viser en tydelig nedadgående sammenhæng mellem pris og konvertering, så jo længere blogindlægget er, jo mindre sandsynlighed er der for at det bliver læst til ende.

Antal ord i buckets

Du kan også inddele blogindlæggene i buckets af antal ord, fx 0-500, 501-1000, etc. og finde den optimale længde på et blogindlæg hvor brugerne oftest læser det hele.

Overraskende nok er det de helt korte indlæg på mindre end 500 ord hvor færrest læser det hele. Der er et sweetspot omkring 500-1500 ord og ligesom det ses i ovenstående Scatter Plot, så falder fastholdelsen i de lange indlæg.

Der er STOR forskel på blogindlæg

Okay, lad os kigge på mine to seneste blogindlæg som eksempler.

Baseret på antal pageviews er de cirka lige populære.

Men pageviews er bare en vanity metric. Den fortæller intet om kvaliteten eller evnen til at fastholde brugeren.

Og de to blogindlæg er meget forskellige.

• Tracking af returvarer i Google Analytics (den ultimative guide 2019) er en inspiration, men også noget som er en reference til senere brug og den er på 3668 ord.
• Tracking af kaffeforbrug med AWS IoT Button og Google Analytics er en sjov use-case for Google Analytics, den er rimelig letlæst og man skal læse (eller skimme) det hele for at den er sjov. Den er kun på 1571 ord.

Buy-to-Detail Rate

Den store forskel på de to blogindlæg ses tydeligt i Buy-to-Detail rate som er 11,69% for returvarer-indlægget mens den er hele 46,26% på AWS IoT-indlægget!

Dvs. næsten halvdelen af alle dem som ser indlægget om AWS scroller helt til bunden og er mindst 1 minut på siden.

Men hvornår falder folk fra på returvarer-indlægget?

Men hey! Tabeller med rå data er måske fede for data scientists, men de dur ikke til at gøre data nemme at forstå. Så lad os lige lave en graf inden vi går videre.

Meget bedre.

Herover ses en tydelig forskel hvor mange brugere på returvarer-indlægget starter med at scrolle (Add to cart) men meget få læser ned til 33% af indlægget (Checkout). Så de fleste har lige skimmet toppen og (forhåbentlig) bogmærket siden og så videre til andre ting.

På kaffe-indlægget er der slet ikke samme frafald, så det indlæg fastholder brugerne meget bedre. Det er godt at vide til fremtiden.

Blog kategorier

Der er også kæmpe forskel i fastholdelse af brugerne fordelt på kategorier. Indlæg om Nethandel bliver læst meget.

Heldigvis bliver mine indlæg om Webanalyse, som jeg lægger meget arbejde i, også læst meget, hvor 24% læser hele indlægget.

Til gengæld skal jeg vidst tage mig lidt sammen, når jeg skriver om SEO, som umiddelbart ikke er så interessante indlæg. Her har jeg også lige taget Hverdagsstatisk med, som er mit indlæg om drikkevarer til et bryllup.

Udgivelsesår

Jeg skrev mit første blogindlæg på denne blog i 2009 og jeg har skrevet 35 indlæg i alt. Lad os se om jeg er blevet bedre til at skrive spændende indlæg igennem årene.

Jeg startede ret godt ud i 2009 og 2010 og havde derefter nogle knap så gode år, særligt 2014-2017. Men 2018 og 2019 har begge været rigtig gode år, så jeg skal vidst bare fortsætte med den type indlæg.

Opsummering

I det ovenstående har jeg gennemgået step-by-step hvordan jeg bruger Enhanced Ecommerce til at få et langt mere detaljeret billede af hvordan mit indhold performer.

Ikke bare vanity metrics, som pageviews, bounce rate og time on page.

Men metrics som viser præcist hvad brugerne gør på sitet, hvor lang tid de (korrekte) er på siden, samt hvor meget af indholdet de læser.

Hvor mange procent tror du læser dette indlæg?

Smid dit svar herunder og deltag i lodtrækning om en… ej pjat, du kan ikke vinde noget, men giv gerne et bud alligevel :)

Overordnet set kan workarounds deles op i to metoder:

1. Der gemmes et ID i localStorage (lukket af ITP 2.3)
2. Der gemmes et ID i en server-side cookie

Cookies der er sat server-side med Set-Cookie er pt. ikke berørt af ITP.

Server-side cookies (HTTP cookies)

Lad os lige se på forskellen mellem client-side og server-side cookies.

• Client-side cookies sættes med JavaScript
• Server-side cookies kommer direkte fra serveren og bliver sat med Set-Cookie i HTTP headeren i det HTTP response der kommer retur fra serveren

Her er hvad der sker når du skriver jacobworsoe.dk i din browser.

1. Browseren sender et HTTP request på en URL til serveren, fx. jacobworsoe.dk
2. Web serveren sender et HTTP response tilbage med HTML koden for dén URL. Et HTTP response indeholder nogle Headers som fx status koden (200, 301, 404, etc.), om siden skal caches i browseren og hvor længe, osv. Headeren kan også indeholde en Set-Cookie kommando som sætter en cookie i browseren.

Accutics Cookie Saver

Måske har du hørt om Cookie Saver fra danske Accutics. De kan sætte server-side cookies for dig.

Du opretter en CNAME record i din DNS hvor man peger et subdomæne på dit website på Cookie Saver’s server. I praksis fungerer det som en redirect.

Derefter indsætter du et stykke JavaScript i din Tag Manager, som sørger for at lave et request til det CNAME med en liste af de cookies du gerne vil have sat server-side. Cookie Saver sørger så for sætte sende et HTTP Response tilbage med de ønskede server-side cookies.

Det har nogle store fordele.

1. Adblockere har ikke så nemt ved at blokere dette request, fordi subdomænet er unikt og kan hedde hvad som helst. Det er derimod meget nemt at blokere Google Analytics, fordi den altid sender til collect.google-analytics.com.

2. Når man laver et request til ens eget subdomæne for at sende data, er der mulighed for at serveren sætter en cookie via Set-Cookie som en del af det HTTP response der kommer retur fra serveren. Fordi requestet er lavet til ens eget domæne, kan serveren sætte en første parts server-side cookie, hvilket pt. ikke bliver blokeret af ITP.

Google kommer ikke med en "nem" løsning

I hvert fald ikke hvis løsningen er server-side cookies. Det er simpelthen ikke teknisk muligt for Google at lave en simpel løsning på dette. For at sætte en server-side cookie kræver det at der laves et subdomæne på det website. Det kan Google ikke bare gøre for dig. Det skal du aktivt selv oprette.

Det betyder at du ikke skal sidde og vente på at Google løser det for dig. Det kan de ikke. Rent teknisk kan det ikke lade sig gøre.

Men samtidig betyder det også at Safari måske ikke begynder at blokere server-side cookies i de næste ITP versioner. Netop fordi det kræver en bevidst handling af dig.

En del af problemet som ITP prøver at løse er nemlig at der ofte bliver lavet en masse cross-site tracking af dine brugere - på det eget website - uden at du er klar over det. Bare fordi du har indsat en harmløst script på dit website.

Men med server-side cookies, sker der ikke noget uden du er klar over det, så det er ikke noget en 3. part bare kan gøre, hvilket formentlig er grunden til at ITP ikke blokerer det.

Er workarounds spild af penge?

Måske. Facebook forsøgte med et workaround og det blev stoppet af ITP 2.1.

Det kan derfor sagtens være at det er spild af penge at implementere workarounds til ITP, som måske bliver blokeret i næste ITP version.

Du er nødt til at overveje hvor meget det koster dig at ITP ødelægger dine data.

Men som beskrevet ovenfor, så kommer Google ikke og løser det hele for dig, så det er værd at have med i overvejelserne i forhold til om det kan betale sig at lave en workaround.

Apple, som startede det hele med Safari browseren. Apple har ikke en annonceplatform og deres omsætning stammer ikke fra reklamer. De har ikke nogen Analytics platform. Apple kan sagtens prioritere brugernes privatliv, uden at skade deres egen forretning.

Adobe har kun en analytics platform. Ingen browser eller annoncer. Adobe skal kun tænke på at lave den bedst mulige Analytics platform, og kan sagtens lave workarounds til ITP.

Facebook har en annonceplatform hvor deres omsætning kommer fra og de har en analytics platform. Facebook skal lave den bedst mulige annonceringsplatform for deres annoncører som dermed bruger flere penge hos dem, og de laver derfor workarounds til ITP.

Google har både den mest brugte browser, den mest brugte web analytics platform og 95+% af deres omsætning kommer fra deres annonceplatform. De har en fod i alle lejre og skal træde meget varsomt.

Google vil gerne beskytte brugernes privatliv, fx ved at skjule organiske søgeord (not provided) eller muligheden for at Google automatisk løbende sletter ens aktivitetsdata.

Det er godt for deres image og godt for udbredelsen af Chrome, når de tager brugernes privatliv seriøst. Det er derfor ikke utænkeligt at Google vil introducere noget der minder om ITP i Chrome.

Firefox har introduceret Enhanced Tracking Prevention (ETP), som også blokerer 3. parts cookies, samt en række af kendte tracking scripts, så der er ingen tvivl om at browserne bliver mere strikse med cookies og giver mere kontrol til brugeren.

Tidligere i år annoncerede Chrome at de arbejder på en browser extension til at vise hvilke data der er brugt til at personalisere de reklamer du ser, samt hvilke firmaer der har været involveret i databehandlingen. Google arbejder også på at brugeren får bedre kontrol over 3. parts cookies i Chrome.

Googles primære indtægtskilde er Google Ads og det er vigtigt at annoncørerne har nogle gode muligheder for at analysere deres data og optimere ad spend. Hvis de ikke kan se hvad der virker, er de ikke så tilbøjelige til at bruge penge på annoncering. Hvis ITP begrænser mulighederne for at analysere effekten af annonceringen, så er det et problem for Google.

Og til sidst har de Google Analytics, som selvfølgelig skal vise så korrekte data som muligt. Men er det sandsynligt at Google vil lancere en workaround til ITP, samtidig med at de skal beskytte brugernes privatliv? Og måske enda lancere noget lignende i Chrome? Det er muligt at Google blot er nødt til at acceptere at udviklingen går mod mindre tracking og bedre kontrol over brugernes data, og dermed ikke selv kommer med en løsning til ITP.