Hvis du bruger Universal Analytics, herunder Analytics til mobilapps, ser du efter al sandsynlighed ikke ret mange selvhenvisninger i dine rapporter.
Baggrund
Når en bruger kommer til dit website, afgør Analytics, hvor vedkommende er kommet fra – trafikkilden. Kilden kan klassificeres som direkte, organisk (ikke-betalt), kampagne eller henvisning.
Henvisninger defineres generelt som trafik til dit website fra et andet website. Med rapporten Henvisninger i kategorien Anskaffelse af rapporter, kan du analysere denne type trafik.
Hvordan kan jeg vide, om jeg har selvhenvisninger?
En selvhenvisning i Analytics er en tilstand, hvor du ser dine egne domæner i rapporten Anskaffelse>Al trafik>Henvisninger. Hvis dit website f.eks. er www.eksempel.dk, er enhver post i rapporten, der angiver kilden som www.eksempel.dk, en selvhenvisning.
Hvis din implementering af Analytics er konfigureret til at måle sessioner på tværs af flere domæner og/eller underdomæner, er det naturligt med et marginalt niveau af selvhenvisninger.
Men selvhenvisninger kan dog også være et symptom på et problem med din implementering af Analytics, og de kan muligvis forvrænge dine metrics samt skjule de faktiske trafikkilder, som vigtige hændelser og andre former for engagement på dit website skulle tilskrives.
Bestemmelse af oprindelsen af selvhenvisninger
analytics.js
Hvis dine sider er tagget med analytics.js-kodestykket, skal du sørge for, at du har føjet alle dine egne domæner (også underdomæner) til listen over henvisningsekskluderinger for din ejendom:
- Log ind på din Analytics-konto.
- Klik på Administrator, og gå til den relevante ejendom.
- Klik på Sporingsoplysninger.
- Klik på Liste over henvisningsekskluderinger.
- Klik på + TILFØJ EKSKLUDERING AF HENVISNINGSWEBADRESSE.
- Angiv det domæne, du vil ekskludere, og klik derefter på Opret.
ga.js
Hvis dine sider er tagget med ga.js-kodestykket, er der desværre ikke en enkelt fælles årsag til selvhenvisninger – faktisk er der mange scenarier, der kan føre til en selvhenvisning. I denne vejledning vil vi forsøge at give dig en liste over de mest almindelige årsager, som vi har oplevet på kundernes websites. Brug denne vejledning som en tjekliste, så du kan spore dig ind på årsagen til dine egne selvhenvisninger.
For at hjælpe dig med at finde de potentielt problematiske sektioner i dit eget indhold har vi medtaget følgende visningsfilter og tilpassede rapport, som efter vores erfaring er nyttig ved fejlfinding af problemer med selvhenvisninger. Udvid hvert enkelt afsnit for at se detaljer:
Få vist filterDu kan indsnævre årsagerne til selvhenvisninger ved at gå til Anskaffelse>Al trafik>Henvisninger.
Når du ser en post med et af dine egne domæner, kan du vise detaljerede oplysninger i rækken for at se dimensionen henvisningssti. Disse henvisningsstier kan være sider på dit website, som du bør undersøge yderligere.Dimensionen henvisningssti fortæller en smule om den side, som nogen var på, før vedkommende gik til dit website. Men henvisningsstien indeholder som standard ikke forespørgselsparameterdelen af den henvisende webadresse, som kan være en værdifuld oplysning. For at se den komplette henvisende webadresse, inklusive forespørgselsparametre, må vi oprette et visningsfilter.
Eksempel på en henvisningssti:
/path/sub-path/?query=123¶meter=456
Som standard viser rapporten for henvisningssti kun:
/path/sub-path/
Brug følgende visningsfilter til at gendanne den komplette henvisningssti i GA-rapporterne:
Advarsel: Inden du anvender et filter på et visningsfilter i Analytics, anbefaler vi, at du opretter en nyt testvisning (lær, hvordan du kopierer en visning). Du bør altid beholde en ikke-filtreret visning som reference, så den kan fungere som sikkerhedskopi af dine rådata og bruges som en kilde, du kan bruge til at sikre, at din dataindsamling fungerer korrekt.
Det filter, vi sædvanligvis bruger, kan oprettes således:
Egenskaber for visningsfilteret
- Filternavn: Vis komplet henvisende webadresse inklusive parametre
- Filtertype: Tilpasset filter => Avanceret
- Felt A -> Uddrag A: Kampagnemedium, ^referral$
- Felt B -> Uddrag B: Henvisning, ^https?://[^/]+(/.*)
- Output til -> Constructor: Kampagneindhold, $B1
- Felt A er krævet: Ja
- Felt B er krævet: Nej
- Tilsidesæt Output-felt: Ja
- Forskel på store og små bogstaver: Nej
Almindelige årsager til og løsninger selvhenvisninger
Der er flere almindelige årsager til selvhenvisninger. Udvid hvert enkelt afsnit for at se detaljer:
Sporingskoden mangler eller fungerer ikke på landingssidenEn almindelig årsag til selvhenvisninger er landingsider eller sider på websitet, som der ikke er tagget med Analytics-sporingskoden. Google Tag Assistant-pluginnet til Google Chrome kan hjælpe dig med at opdage problemer med manglende eller ikke-fungerende sporingskode.
Du skal sikre, at alle siderne på dit website har Analytics-sporingskode installeret.
Brug den tilpassede rapport og visningsfilteret, som er nævnt ovenfor, til at hjælpe med at finde frem til siden/siderne med manglende eller ødelagt kode.
En af de mest almindelige årsager til selvhenvisninger er inkonsekvent konfiguration af sporingskode. Følgende metoder ændrer måden, som Analytics-cookies indstilles og gemmes på for dine domæner.
Det er meget vigtigt, at disse metoder kaldes konsekvent på tværs af hele websitet. Hvis disse metoder ikke kaldes konsekvent på de samme eller sågar på forskellige sider på dit website, kan det medføre, at Analytics enten nulstilles eller opretter et nyt cookiesæt. I begge situationer forsøger Analytics at bestemme kampagnekilden, og her opstår der ofte selvhenvisninger.
Lad os se på et par eksempler, hvor dette kan forekomme:
Eksempel på sporing af underdomæne:
Sporing af underdomæne er en almindelig konfiguration, som du kan få flere oplysninger om her. Nogle websites bruger imidlertid flere skabelonfiler og kræver, at Analytics-sporingskoden indsættes på flere placeringer (dvs. en global inkludering bruges ikke på hele websitet). I tilfælde som dette skal du kontrollere hver enkelt af skabeloninkluderingerne for at sikre, at de indeholder et konsistent Analytics-sporingskodestykke.
Forestil dig ovenstående eksempel, hvor startsiden og produktsiderne bruger én skabelon, og indkøbsvognsiderne bruger en anden.
Ikke korrekt
Startside: (www.eksempel.dk)_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push(['_setDomainName', 'example.com']); _gaq.push([‘_trackPageview’]);Indkøbsvognside: (indkøbsvogn.eksempel.dk)
_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push([‘_trackPageview’]);
I eksemplet ovenfor vil brugere, som går fra startsiden til indkøbsvognssiden, få oprettet to sæt cookies (utma, utmb, utmz) for deres sessioner. Ét sæt under hvert domæne:
- example.com (start- og produktside)
- basket.example.com (kurv)
Hvis _setDomainName ikke kaldes, har det samme effekt som at kalde _setDomainName('auto'). Brug af document.domain-metoden vil medføre, at ga.js opretter cookies for basket.example.com.
For at forhindre selvhenvisninger i denne situation vil du gerne have Analytics til at læse fra 1 sæt cookies, uanset om brugeren er på topdomænet www.eksempel.dk eller på underdomænet indkøbsvogn.eksempel.dk.
Sådan sikrer du, at der bruges ét sæt cookies for det overordnede domæne og dets underdomæner: Medtag linjen _setDomainName i Analytics-kodestykket på hele websitet.
Løsning: Sørg for, at din sporingskode konsekvent kalder metoder, der ændrer den måde, som Analytics-cookies defineres på.
Korrekt
Startside: (www.eksempel.dk)_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push(['_setDomainName', 'example.com']); _gaq.push([‘_trackPageview’]);Indkøbsvognside: (indkøbsvogn.eksempel.dk)
_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push(['_setDomainName', 'example.com']); _gaq.push([‘_trackPageview’]);
Eksempel på multi-Analytics-sporingskode
En populær, men generelt ikke-understøttet konfiguration, som mange kunder bruger, er multisporingskonfiguration. Den bruges til at sende oplysninger til flere Google Analytics-konti på samme tid.
En almindelig misforståelse i forbindelse med denne konfiguration er den formodning, at hver sporer er en separat enhed (eller objekt), men faktisk indstilles cookies på domæneniveau og ikke på sporerniveau, så alle sporerobjekter på den samme side deler og læser fra det samme sæt af cookies.
Derfor er konsistens med sporingskoden på tværs af flere sporingsobjekter lige så vigtig som konsistens på tværs af alle sider på websitet, ligesom i eksemplet med underdomæner ovenfor.
Ikke korrekt
_gaq.push( ['firstTracker._setAccount', 'UA-XXXXX-1'], [‘firstTracker._setDomainName’, ‘example.com’], ['firstTracker._trackPageview'], ['secondTracker._setAccount', 'UA-XXXXX-2'], ['secondTracker._trackPageview'] );
Har du lagt mærke til, hvordan den anden sporer ikke har kaldt _setDomainName-metoden? Dette kan potentielt føre til selvhenvisningsproblemer for både sporere og webejendommene UA-XXXXX-1 og UA-XXXXX-2
Løsning: Sørg altid for, at alle sporingsobjekter på det samme domæne kalder de samme metoder, dvs.er konfigureret på samme måde for at forhindre risikoen for at forårsage en konflikt mellem trackere. I følgende eksempel kaldes _setDomainName konsistent for begge sporere.
Korrekt
_gaq.push( ['firstTracker._setAccount', 'UA-XXXXX-1'], [‘firstTracker._setDomainName’, ‘example.com’], ['firstTracker._trackPageview'], ['secondTracker._setAccount', 'UA-XXXXX-2'], [‘secondTracker._setDomainName’, ‘example.com’], ['secondTracker._trackPageview'] );
Eksempel på sporing på tværs af domæner
En anden almindelig konfiguration af Analytics er sporing af brugeraktivitet på tværs af flere topdomæner. Få flere oplysninger om sporing på tværs af domæner
Når du har 2 domæner, f.eks.: www.example.com og www.otherexample.com, og du vil spore aktiviteten, når brugerne bevæger sig mellem disse domæner, skal du bruge 1 af følgende metoder:
Disse metoder giver mulighed for at Analytics-cookiedata kan videresendes mellem domæner. Den valgte metode afhænger primært af den måde, besøgende bevæger sig mellem domæner på, dvs. klikker på et link, indsender en formular, åbner en iframe etc.
Vi oplever imidlertid et almindeligt problem, nemlig at ikke alle links, formularer eller iframes tagges korrekt til at kunne overføre oplysninger mellem de forskellige domæner.
Eksempel på HTML-side (på www.example.com)
Ikke korrekt
<html> <head></head> <body> <a href="http://www.otherexample.com/" onclick="_gaq.push([‘_link’, this.href]); return false;">link 1</a> <a href="http://www.otherexample.com/page2">link 2</a> </body> </html>
I eksemplet ovenfor er link 1 konfigureret til at videresende Analytics-cookieoplysninger til otherexample.com, men link 2 indeholder ikke onclick-attributten.
Brugere, som klikker på link 1, vil blive sporet præcist på tværs af domæner. Brugere, som klikker på link 2, registreres som en henvisning fra example.com
Løsning: Du skal sikre, at alle links er korrekt tagget til at videresende cookieoplysninger fra example.com til otherexample.com
Korrekt
<html> <head></head> <body> <a href=”http://www.otherexample.com/” onclick=”_gaq.push([‘_link’, this.href]); return false;”>link 1</a> <a href=”http://www.otherexample.com/page2” onclick=”_gaq.push([‘_link’, this.href]); return false;”>link 2</a> </body> </html>
Tip! Hvis du har flere links, der fører til et andet domæne, kan du udnytte en JavaScript-struktur (f.eks. JQuery) til at lytte efter onclick-hændelser, der sender brugere til dine andre domæner.
Derved behøver du ikke tagge hvert enkelt link manuelt, og det er den foretrukne og mindst generende metode til håndtering af links på tværs af domæner.
Omdirigeringer mellem domæner
Vi kommer ind på flere detaljer om omdirigeringer senere i denne artikel, men en anden almindelig årsag til selvhenvisninger ved sporing på tværs af domæner er, at en omdirigering fjerner cookieoplysninger på tværs af domæner, før ga.js i Analytics får mulighed for at læse disse oplysninger fra webadressen på det modtagende domæne.
Igen med henvisning til det forrige eksempel på HTML på tværs af domæner:
Eksempel på HTML-side (på www.example.com)
<html> <head></head> <body> <a href=”http://www.otherexample.com/” onclick=”_gaq.push([‘_link’, this.href]); return false;”>link 1</a> </body> </html>
_link-metoden genererer en Analytics-webadresse på tværs af domæner som nedenfor:
http://www.otherexample.com/?__utma=117945243.497169939.1345210711.1359390130.1360067715.18&__utmb=117945243.3.10.1360067715&__utmc=117945243&__utmx=-&__utmz=117945243.1358253212.11.5.utmgclid=TeSt1234|utmcsr=(not set)|utmccn=(not set)|utmcmd=(not set)|utmcct=(not set)&__utmv=-&__utmk=258513226
Men hvis der forekommer en omdirigering på startsiden:
http://www.otherexample.com/
og den videresender brugerne til:
http://www.otherexample.com/home
Omdirigeringerne underlader muligvis at inkludere Analytics-oplysningerne på tværs af domæner samt at videresende dem til den omdirigerede webadresse.
http://www.otherexample.com/?__utma=117945243.497169939.1345210711.1359390130.1360067715.18&__utmb=117945243.3.10.1360067715&__utmc=117945243&__utmx=-&__utmz=117945243.1358253212.11.5.utmgclid=TeSt1234|utmcsr=(not set)|utmccn=(not set)|utmcmd=(not set)|utmcct=(not set)&__utmv=-&__utmk=258513226
Omdirigerer til:
http://www.otherexample.com/home
Bemærk! Fraværet af Analytics-parametre på tværs af domæner (?__utma=......).
Dette sker ofte, fordi mange serversidebaserede omdirigeringer ikke tager højde for de forespørgselsparametre, som findes på den forrige webadresse. Omdirigeringsreglen sender ganske enkelt brugerne fra 1 webadresse til den næste, men bevarer ikke disse cookieparametre under omdirigeringen.
Løsninger:
-
Sørg for, at omdirigeringen fører Analytics-sporingsparametre til den næste webadresse, f.eks.:
http://www.otherexample.com/home?__utma=117945243.497169939.1345210711.1359390130.1360067715.18&__utmb=117945243.3.10.1360067715&__utmc=117945243&__utmx=-&__utmz=117945243.1358253212.11.5.utmgclid=TeSt1234|utmcsr=(not set)|utmccn=(not set)|utmcmd=(not set)|utmcct=(not set)&__utmv=-&__utmk=258513226
-
Alternativt kan du også fjerne omdirigeringen eller opdatere linket på de forrige domæner, så det peger på den nye adresse, og omdirigering ikke indledes.
Bruger du et mobilt underdomæne, eller har du en dedikeret mobilversion af dit website på det samme domæne?
Det er en almindelig fremgangsmåde at oprette en mobilversion af websitet, som er tilgængeilg via et underdomæne, f.eks.: m.example.com
Hvis du har konfigureret mobilversionen af websitet til at bruge Analytics-sporingsbiblioteket på serversiden (PHP, JSP, ASP.NET og Perl) – omtales almindeligvis som WAP-sporing – og brugerne har mulighed for at navigere mellem mobilversionen og den fulde version af websitet, oplever du muligvis selvhenvisninger fra mobildomænerne og de primære domæner.
Hvis mobilsiderne ikke bruger den almindelige sporingskode ga.js, er effekten den samme som ved ikke-taggede sider på websitet.
WAP-sporingsbibliotekets primære formål er at tillade sporing af mindre avancerede mobilenheder, dvs. enheder med begrænset understøttelse af cookies og/eller JavaScript.
Mange af de nyeste smartphones understøtter imidlertid JavaScript, cookies og billeder ligesom almindelige computere. Pga. stigende udbredelse af smartphones anbefaler vi, at du migrerer dine mobilsider til at bruge det regulære ga.js-sporingskodestykke i stedet for at bruge WAP-sporingsbiblioteket.
Skyldes selvhenvisninger omdirigeringer? I de fleste tilfælde medfører omdirigeringer ikke selvhenvisninger – se afsnittet om på tværs af domæner i dette dokument vedr. en undtagelse. Lad os se på nogle eksempler på omdirigeringer og deres påvirkning af kampagneindstilling i Analytics.
301/302-omdirigeringer
Denne type omdirigering indledes på serversiden, og den sender HTTP-statuskoden 301 eller 302. Det vil være webmasteren, der har implementeret en sådan omdirigering, og den mest almindelige grund til at gøre det er, at en side eller en gruppe sider er flyttet til en ny placering.
301/302-omdirigeringer bør bevare de oprindelige henvisningsoplysninger.
Eksempel
I diagrammet ovenfor klikker en bruger fra some-other-website.com på et link, som peger på din startside på example.com, hvorefter en 301-omdirigering på serversiden sender brugeren til den nye webadresse for din startside /home.
I dette scenarie bør 301-omdirigeringen bevare henvisningsoplysningerne (registreret via document.referrer-JavaScriptet) fra some-other-website.com.
Meta refresh- og JavaScript-baserede omdirigeringer
Omdirigeringer, der ikke er indledt fra serversiden, f.eks. metoderne meta refresh-html-tag eller window.location-JavaScript, kan skjule eller tilsløre henvisningsoplysninger fra Analytics. Vi anbefaler derfor ikke at bruge sådanne metoder på sider, der med en vis sandsynlighed kan blive en landingsside.
Læs følgende artikel om indrammede websites og Analytics for at få flere oplysninger om effekten af at bruge iframes sammen med Analytics og potentialet for selvhenvisninger.
Udnytter du Flash Tracking API'er? Når du arbejder med dette sporingsbibliotek, er det en god idé at bruge Bridge-tilstand i stedet for AS3-tilstand. Få flere oplysninger her. Ved brug af Bridge-tilstand kan Flash-sporingsbiblioteket kommunikere med de samme cookies som den almindelige ga.js-sporingskode. Det betyder, at aktivitet i et flash-objekt kan spores tilbage til den korrekte kampagnekilde, dvs. den kilde, som blev brugt til at finde dit website.
Når du bruger AS3-tilstand, bruger biblioteket Flash-cookies. For at bestemme kampagnekilde vil biblioteket søge efter henvisningswebadressen, der blev brugt til at åbne Flash-objektet. Det er normalt dit eget website (overordnet side), f.eks. www.example.com.
