Hvis du bruker Universal Analytics, herunder Analytics for mobilapper, vises det neppe mange egenhenvisninger i rapportene.
Bakgrunn
Når en bruker kommer til nettstedet ditt, prøver Analytics å finne ut hvor hen kom fra – altså brukerens trafikkilde. Kilden kan klassifiseres som direkte, organisk (ubetalt), kampanje eller henvisning.
Henvisninger blir vanligvis definert som trafikk til nettstedet ditt fra et annet nettsted. Du kan analysere denne typen trafikk ved å se nærmere på rapporten om henvisninger under rapportkategorien Brukeranskaffelse.
Hvordan vet jeg om jeg har egenhenvisninger?
Hvis du ser ditt eget domene i Brukeranskaffelse > All trafikk > Henvisninger-rapporten, kalles dette en egenhenvisning i Analytics. Tenk deg at nettsetdet ditt er www.example.com. Da er alle forekomster av www.example.com i rapporten egenhenvisninger.
Hvis du har implementert Analytics for å måle økter som går over flere domener og/eller underdomener, er det naturlig at du får noen egenhenvisninger.
Men mange egenhenvisninger kan også være et symptom på et problem med Analytics-implementeringen. De kan føre til upresise beregninger og skjule de faktiske trafikkildene som de viktige hendelsene og annet engasjement på nettstedet skulle ha vært tilskrevet.
Finn ut hvor egenhenvisninger stammer fra
analytics.js-kodebiten
Hvis du har tagget sidene med analytics.js-kodebiten, må du påse at du har lagt til alle domenene dine (også underdomenene) i ekskluderingslisten for henvisninger for området ditt:
- Logg på Analytics-kontoen din.
- Klikk på Administrator, og naviger til det ønskede området.
- Klikk på Sporingsinformasjon.
- Klikk på Ekskluderingsliste for henvisninger.
- Klikk på + LEGG TIL HENVISNINGEKSKLUDERING.
- Skriv inn domenet du vil ekskludere, og klikk deretter på Opprett.
ga.js-kodebiten
Hvis ga.js-kodebiten er plassert på sidene dine, finnes det dessverre ingen enkeltårsak til at egenhenvisninger oppstår. Egenhenvisninger kan oppstå i en rekke scenarioer. I denne veiledningen finner du en liste over de vanligste årsakene vi har sett på kundenes nettsteder. Du kan bruke denne veiledningen som en sjekkliste for å sirkle inn den underliggende årsaken til egenhenvisningene dine.
For å hjelpe deg med å finne delene av innholdet ditt som kan være årsaken til problemet med egenhenvisninger, har vi tatt med følgende datautvalgsfilter og tilpassede rapport som vi selv har hatt nytte av under feilsøking av slike problemer. Du kan finne flere detaljer ved å utvide de enkelte delene:
RapporteringsvisningsfilterDet er enklere å finne de nøyaktige årsakene til egenhenvisninger hvis du ser på Brukeranskaffelse > All trafikk > Henvisninger-rapporten.
Når du ser en oppføring for ett av dine egne domener, kan du se på Henvisningsbane-dimensjonen ved å åpne detaljoversikten. Disse henvisningsbanene kan være sider på nettstedet ditt som det er verdt å undersøke nærmere.Dimensjonen for henvisningsbaner sier noe om den aktuelle siden noen var på før hen navigerte til nettstedet ditt. Som standard inkluderer henvisningsbanen ikke søkeparameterdelen av henvisningsadressen, som kan ha verdifull informasjon. For å se den fullstendige henvisningsadressen, inkludert søkeparametre, må du angi et rapporteringsvisningsfilter.
Ta dette eksempelet på en henvisningsbane:
/bane/underbane/?query=123¶meter=456
Henvisningsbanerapporten viser som standard bare dette:
/bane/underbane/
Bruk dette rapporteringsvisningsfilteret for å gjenopprette hele henvisningsbanen i GA-rapporter:
Advarsel: Før du bruker et filter på et Google Analytics-datautvalg, anbefaler vi på det sterkeste at du lager et nytt testdatautvalg (finn ut hvordan du kopierer et datautvalg). Du bør alltid beholde en ufiltrert rapporteringsvisning. Den kan være en sikkerhetskopi av rådata og brukes som referanse når du vil sjekke at datainnsamlingen fungerer som forventet.
Filteret vi vanligvis bruker, kan konfigureres slik:
Attributter for visningsfilter
- Filternavn: Vis hele henvisningsadressen, inkludert parametere
- Filtertype: Tilpasset filter => Avansert
- Felt A -> trekk ut A: kampanjemedium, ^referral$
- Felt B -> trekk ut B: henvisning, ^https?://[^/]+(/.*)
- Resultat til -> konstruktør: kampanjeinnhold, $B1
- Felt A er obligatorisk: ja
- Felt B er obligatorisk: nei
- Overstyr utdatafelt: ja
- Skill mellom små og store bokstaver: nei
Vanlige årsaker til og løsninger for egenhenvisninger
Det finnes flere vanlige årsaker til egenhenvisninger. Du kan finne flere detaljer ved å utvide de enkelte delene:
Sporingskoden mangler eller fungerer ikke på landingssidenEn vanlig årsak til egenhenvisninger er landingssider eller sider på nettstedet ditt som ikke er tagget med Analytics-sporingskoden. Med programtillegget Google Tag-assistent for Google Chrome kan du få hjelp med å oppdage problemer med sporingskode som mangler eller ikke fungerer.
Du må sørge for at Analytics-sporingskoden er installert på alle sidene på nettstedet ditt.
Hvis du bruker den egendefinerte rapporten og visningsfilteret som er nevnt ovenfor, er det enklere å finne ut nøyaktig hvilke sider som mangler kode eller inneholder ødelagt kode.
En av de vanligste årsakene til egenhenvisninger er inkonsekvent konfigurering av sporingskoden. Metodene nedenfor endrer hvordan Analytics-informasjonskapsler angis og lagres på domener.
Det er svært viktig at du kaller disse metodene på en konsekvent måte på hele nettstedet ditt. Hvis du kaller disse metodene på en inkonsekvent måte på samme side eller forskjellige sider på nettstedet, kan dette føre til at Analytics-systemet tilbakestiller informasjonskapslene eller oppretter et nytt sett av informasjonskapsler. I begge tilfellene forsøker Analytics-systemet å finne kampanjekilden. Det er ofte på dette punktet at en egenhenvisning oppstår.
Her er noen eksempler på hvor dette kan skje:
Eksempel på sporing av underdomener
Sporing av underdomener er en vanlig konfigurasjon. Finn ut mer om dette her. Enkelte nettsteder benytter imidlertid flere malfiler, og Analytics-sporingskoden må settes inn på flere steder (dvs. det brukes ikke en global inkludering for hele nettstedet). I slike tilfeller må du kontrollere alle de inkluderte malene dine for å sikre at de inneholder en konsekvent Analytics-sporingskodebit.
Se for deg eksempelet ovenfor, der startsiden og produktsidene bruker én mal og handlekurvsidene bruker en annen.
Feil
Startside: (www.example.com)_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push(['_setDomainName', 'example.com']); _gaq.push([‘_trackPageview’]);Handlekurvside: (handlekurv.example.com)
_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push([‘_trackPageview’]);
I eksemplet ovenfor blir det opprettet to sett med informasjonskapsler (utma, utmb, utmz) for øktene til brukerne som går fra startsiden til handlekurvsiden – ett sett for hvert domene:
- example.com (start- og produktside)
- handlekurv.example.com (handlekurv)
At du ikke kaller opp _setDomainName, har den samme effekten som å kalle opp _setDomainName(‘auto’). Hvis du bruker document.domain-metoden, oppretter ga.js informasjonskapsler for handlekurv.example.com.
For å hindre egenhenvisninger i denne situasjonen må du påse at Analytics-systemet leser data fra ett sett av informasjonskapsler, uavhengig av om brukeren er på toppdomenet www.example.com eller underdomenet handlekurv.example.com.
Hvis du vil påse at det blir brukt ett sett med informasjonskapsler for det overordnede domenet og de tilhørende underdomenene, tar du med _setDomainName-linjen i Analytics-kodebiten på hele nettstedet ditt.
Løsning: Sørg for at metodene som endrer måten Analytics-informasjonskapsler defineres på, kalles på en konsekvent måte i sporingskoden din.
Riktig
Startside: (www.example.com)_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push(['_setDomainName', 'example.com']); _gaq.push([‘_trackPageview’]);Handlekurvside: (handlekurv.example.com)
_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push(['_setDomainName', 'example.com']); _gaq.push([‘_trackPageview’]);
Eksempel med flere Analytics-sporingskoder
En populær konfigurasjon som mange kunder bruker, men som generelt sett ikke støttes, er et flerkodet oppsett. En slik konfigurasjon brukes til å sende informasjon til flere Analytics-kontoer samtidig.
En vanlig misforståelse om dette oppsettet er å anta at hver sporingsenhet er en separat enhet (eller et separat objekt), men informasjonskapslene blir angitt på domenenivå, ikke på sporingsenhetsnivå. Dermed deles og leses alle sporingsobjektene på den samme siden fra det samme settet med informasjonskapsler.
Dermed er samsvarende sporingskode i de ulike sporingsenhetene like viktig som det å sikre slikt samsvar på alle sidene på nettstedet, slik beskrevet i eksempelet med underdomenet ovenfor.
Feil
_gaq.push( ['firstTracker._setAccount', 'UA-XXXXX-1'], [‘firstTracker._setDomainName’, ‘example.com’], ['firstTracker._trackPageview'], ['secondTracker._setAccount', 'UA-XXXXX-2'], ['secondTracker._trackPageview'] );
Legg merke til at secondTracker ikke har kalt opp _setDomainName-metoden. Dette kan potensielt føre til problemer med egenhenvisninger både i sporingsenhetene og nettområdene UA-XXXXX-1 og UA-XXXXX-2.
Løsning: Påse at alle sporingsobjektene på det samme domenet alltid kaller opp de samme metodene, altså at de er tilsvarende konfigurert, for å unngå at det oppstår konflikt mellom sporingsenhetene. I eksempelet nedenfor blir _setDomainName kalt opp konsekvent av begge sporingsenhetene.
Riktig
_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 av flere domener
En annen vanlig konfigurasjon av Analytics er å spore brukeraktivitet på flere toppdomener. Finn ut mer sporing av flere domener.
Hvis du har to domener, for eksempel www.example.com og www.otherexample.com, og du vil spore brukeraktivitet mens brukerne flytter seg mellom disse domenene, må du bruke en av disse metodene:
Med disse metodene kan data for Analytics-informasjonskapsler sendes mellom domenene. Hvilken metode du bruker, avhenger hovedsakelig av hvordan brukerne navigerer mellom domenene, dvs. om de klikker på en link, sender inn et skjema, åpner en iframe osv.
Et vanlig problem vi ser, er imidlertid at ikke alle linker, skjemaer eller iframes er merket på riktig måte slik at informasjon kan sendes mellom de ulike domenene.
Eksempel på en HTML-side (på www.example.com)
Feil
<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 eksempelet ovenfor er link 1 konfigurert slik at informasjon om Analytics-informasjonskapselen sendes til otherexample.com, mens link 2 ikke inneholder onclick-attributtet.
Brukerne som klikker på link 1, blir sporet helt nøyaktig på flere domener. Brukerne som klikker på link 2, blir registrert som henvisninger fra example.com.
Løsning: Du må sørge for at alle linkene er merket på riktig måte, slik at informasjonskapselsinformasjon kan sendes fra example.com til otherexample.com.
Riktig
<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>
Tips: Hvis du har flere linker som fører til et annet domene, kan du bruke et Javascript-rammeverk (f.eks. JQuery) som lytter etter onclick-hendelser som sender brukerne til de andre domenene dine.
Da slipper du å merke hver link manuelt, og det er en diskret og foretrukket metode for å håndtere linker for flere domener.
Viderekoblinger mellom domener
Vi dekker viderekoblinger i mer detalj senere i artikkelen, men en annen vanlig årsak til egenhenvisninger ved sporing av flere domener er viderekoblinger der dataene om informasjonskapsler for flere domener fjernes før Analytics ga.js har muligheten til å lese denne informasjonen fra nettadressen på mottakerdomenet.
Vi går tilbake til det tidligere eksempelet med HTML for flere domener:
Eksempel på en 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-nettadresse for flere domener som i eksemplet 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 følgende kan skje hvis en viderekobling forekommer på startsiden
http://www.otherexample.com/
og brukerne blir videresendt til:
http://www.otherexample.com/startside
Da kan det hende at Analytics-informasjonen om flere domener ikke tas med i viderekoblinger og dermed heller ikke sendes til viderekoblingsadressen.
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
Viderekobler til:
http://www.otherexample.com/startside
Merk: Analytics-parameterne for flere domener mangler (?__utma=......).
Dette skjer ofte fordi det ikke tashensyn til søkeparameterne som finnes i den tidligere nettadressen, i mange viderekoblinger basert på tjenersiden. Med denne viderekoblingsregelen flyttes ganske enkelt brukerne fra én nettadresse til en annen. Men disse infokapselparametrene blir ikke tatt vare på under viderekoblingen.
Løsninger:
-
Sørg for at Analytics-sporingsparameterne tas med til neste nettadresse i viderekoblingen, 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
-
Du kan eventuelt også fjerne viderekoblingen eller oppdatere linken på de forrige domenene, slik at de peker til den nye plasseringen, så ingen viderekobling blir kalt opp.
Bruker du et underdomene for mobilenheter, eller har du en versjon av nettstedet som er forbeholdt mobilenheter på det samme domenet?
Det er vanlig å lage en mobilversjon av nettstedet som er tilgjengelig fra et underdomene, for eksempel m.example.com.
Hvis du har konfigurert mobilversjonen av nettstedet slik at Analytics-sporingsbiblioteket på tjenersiden (PHP, JSP, ASP.NET, og Perl) blir brukt (dette kalles vanligvis WAP-sporing), og brukerne kan navigere mellom mobilversjonen og den fullstendige versjonen av nettstedet, kan det hende du ser egenhenvisninger fra mobil- eller primærdomenet ditt.
Hvis mobilsidene dine ikke inneholder den vanlige ga.js-sporingskoden, er effekten den samme som om du hadde hatt umerkede sider på nettstedet ditt.
Hovedformålet med WAP-sporingsbiblioteket er å tillate sporing av enkle mobilenheter, dvs. de enhetene som har begrenset støtte for informasjonskapsler eller javascript.
Mange av de nyeste smarttelefonene støtter imidlertid nå JavaScript, informasjonskapsler og bilder, akkurat som vanlige stasjonære datamaskiner. På grunn av økt bruk av smarttelefoner anbefaler vi at du overfører mobilsidene dine til den vanlige ga.js-sporingskodebiten i stedet for WAP-sporingsbiblioteket.
Fører viderekoblinger til egenhenvisninger? Vanligvis skal ikke viderekoblinger føre til egenhenvisninger. Hvis du ønsker å se et unntak, kan du se delen om sporing av flere domener i dette dokumentet. Vi ser på noen eksempler på viderekoblinger og innvirkningen deres på kampanjeinnstillingene i Analytics.
301/302-viderekoblinger
Denne typen viderekobling er en viderekobling som kalles opp på tjenersiden, og som sender HTTP-statuskodene 301 eller 302. Nettredaktøren din har implementert en slik viderekobling, og den vanligste grunnen til at noen gjør dette, er at en side eller gruppe med sider er blitt flyttet.
301/302-viderekoblinger bør bevare den opprinnelige henvisningsinformasjonen.
Eksempel:
I diagrammet ovenfor klikker en bruker på some-other-website.com på en link som peker til startsiden din på example.com, en 301-viderekobling på tjenersiden oppstår og brukeren videresendes til den nye nettadressen for startsiden din.
I dette scenariet bevares henvisningsinformasjonen (registrert via document.referrer for javascript) fra some-other-website.com via 301-viderekoblingen.
Metaoppdatering og JavaScript-baserte viderekoblinger
Det kan hende at henvisningsinformasjon fra Google Analytics kan skjules eller tilsløres av viderekoblinger som ikke er kalt opp på tjenersiden, for eksempel html-taggen for metaoppdateringer eller JavaScripts window.location-metoder. Derfor anbefaler vi at du ikke bruker slike metoder på sider som sannsynligvis er landingssider.
Hvis du vil vite mer om effekten av å bruke iframe-rammer med Analytics og mulighetene for egenhenvisninger, kan du lese denne artikkelen om Analytics og nettsteder med rammer.
Bruker du API-er for Flash-sporing? Når du arbeider med dette sporingsbiblioteket, er det ideelt sett lurt å bruke bromodusen i stedet for AS3-modusen. Finn ut mer her. Når du bruker bromodusen, kan Flash-sporingsbiblioteket kommunisere med de samme informasjonskapslene som den vanlige ga.js-sporingskoden. Det betyr at aktiviteten i et Flash-objekt kan spores tilbake til riktig kampanjekilde, dvs. kilden som blir brukt for å finne nettstedet ditt.
Når du bruker AS3-modus, bruker biblioteket Flash-informasjonskapsler. For å fastslå kampanjekilden sjekker biblioteket henvisningsadressen som ble brukt for å åpne Flash-objektet. Dette er som regel nettstedet ditt (den overordnede siden), for eksempel www.example.com.
