Jei naudojate „Universal Analytics“, įskaitant mobiliesiems skirtą programą „Analytics“, mažai tikėtina, kad ataskaitose matysite daug persiuntimų sau.
Fonas
Naudotojams atėjus į jūsų svetainę „Analytics“ stengiasi nustatyti, iš kur jie atėjo, t. y. koks srauto šaltinis. Šaltinius galima klasifikuoti į tiesioginius, natūraliuosius (nemokamus), kampanijų arba persiuntimo.
Persiuntimai bendrai apibrėžiami kaip srautas į jūsų svetainę iš kitos svetainės. Naudodamiesi ataskaita Persiuntimai, esančia ataskaitų kategorijoje Įgijimas, galite analizuoti šio tipo srautą.
Kaip žinoti, ar pateikiami persiuntimai sau?
Programoje „Analytics“ persiuntimai sau – tai būsena, kai jūsų domenas (-ai) rodomas (-i) ataskaitoje Įgijimas > Visas srautas > Persiuntimai. Pavyzdžiui, jei svetainė yra www.example.com, bet kuris ataskaitos įrašas, kuriame nurodyta www.example.com, yra persiuntimas sau.
Jei jūsų „Analytics“ diegimas sukonfigūruotas vertinti kelių domenų ir (arba) padomenių seansus, nežymus persiuntimo sau kiekis gali būti natūralus.
Tačiau persiuntimai sau gali rodyti, kad yra „Analytics“ diegimo problema, iškreipti metriką ir neleisti aiškiai suprasti faktinių srauto šaltinių, prie kurių turėtų būti pridėtos konversijos ir kiti svetainės įtraukimai.
Persiuntimų sau kilmės nustatymas
analytics.js
Jei jūsų puslapiai pažymėti analytics.js fragmentu, turite įsitikinti, kad persiuntimų išskyrimo sąraše pridėjote visus savo nuosavybės domenus (įskaitant padomenius):
- Prisijunkite prie „Analytics“ paskyros.
- Spustelėkite Administratorius ir eikite į norimą nuosavybę.
- Spustelėkite Stebėjimo informacija.
- Spustelėkite Persiuntimų išskyrimo sąrašas.
- Spustelėkite + PRIDĖTI PERSIUNTIMO IŠSKYRIMĄ.
- Įveskite norimą išskirti domeną ir spustelėkite Sukurti.
ga.js
Jei jūsų puslapiai pažymėti ga.js fragmentu, deja, nėra vienos bendros persiuntimo sau priežasties; iš tiesų yra daug skirtingų scenarijų, dėl kurių gali būti persiunčiama sau. Šiame vadove bus pateikiamas dažniausiai pasitaikančių priežasčių, kurios buvo pastebėtos klientų svetainėse, sąrašas. Naudodamiesi šio vadovu kaip kontroliniu sąrašu nustatykite persiuntimų sau priežastį.
Siekdami padėti nustatyti potencialiai problemiškas jūsų turinio skiltis, įtraukėme šį rodinio filtrą ir tinkintą ataskaitą, kurie mums pasirodė naudingi šalinant persiuntimo sau triktis. Išskleiskite kiekvieną skiltį ir matysite išsamesnę informaciją.
Peržiūrėti filtrąNorėdami susiaurinti persiuntimo sau priežasčių sąrašą, eikite į ataskaitą Įgijimas > Visas srautas > Persiuntimai.
Kai matote vieno iš savo domenų įrašą, išsamiai išnagrinėkite eilutę ir peržiūrėkite persiuntimo kelio aspektą. Šie persiuntimo keliai gali būti jūsų svetainės puslapiai, kuriuos verta panagrinėti išsamiau.Persiuntimo kelio aspektas pateiks jums šiek tiek informacijos apie puslapį, kuriame kas nors lankėsi, prieš pradėdamas naršyti jūsų svetainę. Tačiau pagal numatytuosius nustatymus persiuntimo kelias neapima persiuntimo URL, kuriame gali būti vertingos informacijos, užklausos parametro dalies. Jei norite matyti visą persiuntimo URL, įskaitant užklausos parametrus, turime sukurti rodinio filtrą.
Naudokite šį pavyzdinį persiuntimo kelią:
/path/sub-path/?query=123¶meter=456
Pagal numatytuosius nustatymus persiuntimo kelio ataskaitoje bus rodoma tik:
/path/sub-path/
Jei GA ataskaitose norite atkurti visą persiuntimo kelią, naudokite toliau nurodytą rodinio filtrą.
Įspėjimas: primygtinai rekomenduojame prieš taikant „Analytics“ rodiniui bet kokį filtrą sukurti naują bandomąjį rodinį (sužinokite, kaip nukopijuoti rodinį). Visada turėtumėte ateičiai išsaugoti nefiltruotą rodinį. Vėliau jį būtų galima naudoti kaip neapdorotų duomenų atsarginę kopiją ir šaltinį, kad duomenys būtų renkami tinkamai.
Toliau matysite, kaip gali būti sudarytas filtras, kurį dažniausiai naudojame.
Rodinio filtro atributai
- Filtro pavadinimas: rodomas visas persiuntimo URL, įskaitant parametrus;
- filtro tipas: tinkintas filtras => išplėstinis;
- A laukas -> A ištrauka: kampanijos terpė, ^referr
- B laukas -> B ištrauka: persiuntimas, ^https?://[^/]+(/.*);
- Išvestis į -> konstravimo priemonė: kampanijos turinys, $B1;
- A laukas privalomas: taip;
- B laukas privalomas: ne;
- nepaisyti išvesties lauko: taip;
- skirti didžiąsias ir mažąsias raides: ne.
Dažnos persiuntimų sau priežastys ir sprendimai
Yra kelios dažnos persiuntimų sau priežastys. Išskleiskite kiekvieną skiltį ir matysite išsamesnę informaciją.
Nukreipimo puslapyje nėra stebėjimo kodo arba jis neveikiaBendroji persiuntimo sau priežastis yra nukreipimo puslapiai arba jūsų svetainės puslapiai, nepažymėti „Analytics“ stebėjimo kodu. „Google“ pagalbinės žymų priemonės papildinys, skirtas „Google Chrome“, gali padėti aptikti trūkstamo ar neveikiančio stebėjimo kodo problemas.
Turite įsitikinti, kad svetainės visuose puslapiuose yra įdiegtas „Analytics“ stebėjimo kodas.
Naudokite anksčiau minėtą tinkintos ataskaitos ir rodinio filtrą ir sumažinkite puslapių, kuriuose nėra kodo ar kodas yra sugadintas, skaičių.
Viena iš dažniausiai pasitaikančių persiuntimo sau priežasčių yra nenuosekli stebėjimo kodo konfigūracija. Toliau nurodytais metodais pakeičiamas „Analytics“ slapukų nustatymo ir saugojimų jūsų domene (-uose) būdas.
Labai svarbu šiuos metodus taikyti nuosekliai visoje svetainėje. Jei šiuos metodus taikysite nenuosekliai tame pačiame ar netgi skirtinguose svetainės puslapiuose, „Analytics“ gali būti nustatyta iš naujo arba sukurtas naujas slapukų rinkinys. Bet kuriuo atveju „Analytics“ bandys nustatyti kampanijos šaltinį – tašką, kuriame dažnai įvyksta persiuntimai sau.
Peržiūrėkite kelis pavyzdžius, kodėl šie persiuntimai sau gali įvykti.
Padomenio stebėjimo pavyzdys
Padomenio stebėjimas yra bendrai palaikoma konfigūracija. Daugiau apie tai sužinosite čia. Tačiau kai kuriose svetainėse naudojami keli šablono failai, o „Analytics“ stebėjimo kodą reikia įtraukti keliose vietose (pvz., visuotinis įtraukimas nenaudojamas visoje svetainėje). Į šį panašiais atvejais patikrinkite, ką apima kiekvienas jūsų šablonas, kad užtikrintumėte, jog juose yra nuoseklus „Analytics“ stebėjimo fragmentas.
Tarkime, kad turime anksčiau pateiktą pavyzdį, kai pagrindinis ir produkto puslapiai naudoja 1 šabloną, o pirkinių krepšelio puslapiai – kitą.
Neteisinga
Pagrindinis puslapis: www.example.com_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push(['_setDomainName', 'example.com']); _gaq.push([‘_trackPageview’]);Pirkinių krepšelio puslapis: basket.example.com
_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push([‘_trackPageview’]);
Pirmiau pateiktame pavyzdyje naudotojai, iš pagrindinio puslapio perėję į pirkinių krepšelio puslapį, turi 2 slapukų rinkinius („utma“, „utmb“, „utmz“), sukurtus jų seansui (-ams). Po vieną rinkinį kiekviename domene:
- example.com (pagrindinis ir produkto puslapis);
- basket.example.com (pirkinių krepšelis).
Neiškvietus „_setDomainName“ poveikis bus toks pat, kaip iškvietus _setDomainName(‘auto’). Naudojant „document.domain“ metodą, „ga.js“ kurs slapukus, skirtus basket.example.com.
Siekiant šioje situacijoje išvengti persiuntimų sau, „Analytics“ turėtų nuskaityti duomenis iš 1 slapukų rinkinio, neatsižvelgiant į tai, ar naudotojas yra aukščiausio lygio domene www.example.com, ar antriniame domene basket.example.com.
Jei norite užtikrinti, kad jūsų pagrindiniam domenui ir jo padomeniams būtų naudojamas 1 slapukų rinkinys, į „Analytics“ fragmento eilutę įtraukite „_setDomainName“ visoje savo svetainėje.
Sprendimas: užtikrinkite, kad jūsų stebėjimo kodas nuosekliai iškviestų „Analytics“ slapukų apibrėžimo pakeitimo būdus.
Teisinga
Pagrindinis puslapis: www.example.com_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push(['_setDomainName', 'example.com']); _gaq.push([‘_trackPageview’]);Pirkinių krepšelio puslapis: basket.example.com
_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push(['_setDomainName', 'example.com']); _gaq.push([‘_trackPageview’]);
Kelių „Analytics“ stebėjimo kodų pavyzdys
Populiari, bet bendrai nepalaikoma konfigūracija, kurią naudoja daugelis klientų, yra kelių stebėjimo priemonių konfigūracija. Ji naudojama informacijai į kelias „Analytics“ paskyras siųsti vienu metu.
Dažnai pasitaiko, kad ši konfigūracija suprantama klaidingai ir manoma, jog kiekviena stebėjimo priemonė yra atskiras subjektas (arba objektas). Iš tikrųjų slapukai nustatomi domeno, o ne stebėjimo priemonės lygiu, todėl visi tame pačiame puslapyje esantys stebėjimo priemonės objektai naudojami bendrai ir skaito iš to paties slapukų rinkinio.
Todėl nuoseklus stebėjimo kodo taikymas keliems stebėjimo priemonės objektams yra tiek pat svarbus, kaip visų jūsų svetainės puslapių nuoseklumas, kaip tai parodyta ankstesniame pavyzdyje pateiktame padomenyje.
Neteisinga
_gaq.push( ['firstTracker._setAccount', 'UA-XXXXX-1'], [‘firstTracker._setDomainName’, ‘example.com’], ['firstTracker._trackPageview'], ['secondTracker._setAccount', 'UA-XXXXX-2'], ['secondTracker._trackPageview'] );
Ar atkreipėte dėmesį, kaip „secondTracker“ gali neiškviesti „the _setDomainName“ metodo? Tai potencialiai sukels persiuntimo sau problemų ir stebėjimo priemonėms, ir žiniatinklio nuosavybėms UA-XXXXX-1 bei UA-XXXXX-2
Sprendimas: visada užtikrinkite, kad visi stebėjimo priemonės objektai, esantys tame pačiame domene, iškviestų tuos pačius metodus, t. y. būtų taip pat sukonfigūruoti, kad būtų išvengta stebėjimo priemonių konflikto. Toliau nurodytame pavyzdyje „_setDomainName“ nuosekliai iškviečiamas abiejose stebėjimo priemonėse.
Teisinga
_gaq.push( ['firstTracker._setAccount', 'UA-XXXXX-1'], [‘firstTracker._setDomainName’, ‘example.com’], ['firstTracker._trackPageview'], ['secondTracker._setAccount', 'UA-XXXXX-2'], [‘secondTracker._setDomainName’, ‘example.com’], ['secondTracker._trackPageview'] );
Kryžminio domenų stebėjimo pavyzdys
Kita dažnai naudojama „Analytics“ konfigūracija yra naudotojų veiklos stebėjimas keliuose aukščiausio lygio domenuose. Sužinokite daugiau apie kryžminį domenų stebėjimą
Jei turite 2 domenus, pvz., www.example.com ir www.otherexample.com, ir norite stebėti veiklą naudotojams perėjus iš vieno domeno į kitą, turėsite naudoti vieną iš toliau nurodytų metodų.
Naudojant šiuos metodus „Analytics“ slapukų duomenys perduodami iš vieno domeno į kitą. Kokį metodą naudoti, labiausiai priklausys nuo būdo, kuriuo naudotojai pereina iš vieno domeno į kitą, t. y. spustelėja nuorodą, pateikia formą, atidaro „iframe“ ar kt.
Tačiau dažniausiai pasitaikanti problema, kad ne visos nuorodos, formos ar „iframe“ tinkamai pažymėtos, kad būtų galima perduoti informaciją iš vieno domeno į kitą.
HTML puslapio pavyzdys (www.example.com)
Neteisinga
<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>
Pirmiau pateiktame pavyzdyje 1 nuoroda sukonfigūruota perduoti „Analytics“ slapuko informaciją į otherexample.com, tačiau 2 nuorodoje nėra „onclick“ atributo.
Naudotojai, spustelėję 1 nuorodą, bus atidžiai stebimi keliuose domenuose. Naudotojai, spustelėję 2 nuorodą, bus užregistruoti kaip persiuntimas iš example.com
Sprendimas: turėtumėte užtikrinti, kad visos nuorodos būtų atitinkamai pažymėtos ir perduotų slapuko informaciją iš example.com į otherexample.com
Teisinga
<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>
Patarimas: jei kelios nuorodos nukreipia į kitą domeną, galite padaryti taip, kad „JavaScript“ struktūra (pvz., „JQuery“) klausytų „onclick“ įvykių, kuriais naudotojai nukreipiami į kitą (-us) jūsų domeną (-us).
Taip nereikės neautomatiškai žymėti kiekvienos nuorodos ir naudosite netrukdantį ir patogų kryžminį domeno nuorodų apdorojimo metodą.
Peradresavimai iš vieno domeno į kitą
Toliau šiame straipsnyje išsamiau aptarsime peradresavimus, tačiau kita dažnai pasitaikanti persiuntimų sau atliekant kryžminį domenų stebėjimą priežastis – peradresuojant pašalinama kryžminio domenų stebėjimo slapuko informacija prieš „Analytics“ „ga.js“ suteikiant galimybę nuskaityti šią informaciją iš URL priimančiajame domene.
Vėl grįžtame prie ankstesnio kryžminio domenų stebėjimo HTML pavyzdžio:
HTML puslapio pavyzdys (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>
Metodas „_link“ sugeneruos tokį „Analytics“ kryžminio domenų stebėjimo URL, kaip nurodyta toliau.
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
Tačiau jei peradresavimas vykdomas pagrindiniame puslapyje:
http://www.otherexample.com/
ir persiunčia naudotojus į:
http://www.otherexample.com/home
Peradresuojant gali būti neįtraukta „Analytics“ kryžminio domenų stebėjimo informacija ir ji gali būti neperduota peradresuojamam URL.
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
Peradresavimai į:
http://www.otherexample.com/home
Pastaba: nėra „Analytics“ kryžminio domenų stebėjimo parametrų (?__utma=......).
Taip dažnai nutinka todėl, kad daugeliui serveriais pagrįstų peradresavimų nepavyksta atsižvelgti į užklausos parametrus, pateiktus ankstesniame URL. Peradresavimo taisyklė tiesiog perkelia naudotojus iš 1 URL į kitą, bet peradresuojant neišsaugo šių slapukų parametrų.
Sprendimai
-
Užtikrinkite, kad peradresuojant būtų perduodami „Analytics“ stebėjimo parametrai kitam URL, pvz.,:
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
-
Be to, galite ankstesniame (-uose) domene (-uose) pašalinti peradresavimo arba atnaujinimo nuorodą, kad būtų nurodoma į naują vietą ir nebūtų inicijuojamas joks peradresavimas.
Ar naudojate padomenį mobiliesiems ar turite mobiliesiems skirtą svetainės versiją tame pačiame domene?
Paprastai kuriama svetainės versija mobiliesiems, pasiekiama iš padomenio, pvz., m.example.com
Jei sukonfigūravote savo svetainės mobiliąją versiją taip, kad būtų naudojama serverio „Analytics“ stebėjimo biblioteka (PHP, JSP, ASP.NET ir „Perl“) – tai dažnai vad. WAP stebėjimu, – ir naudotojai turi galimybę pereiti iš mobiliosios svetainės versijos į visas funkcijas palaikančią versiją (ir atvirkščiai), galite matyti persiuntimus sau iš mobiliosios versijos ir pirminio domenų.
Jei jūsų puslapiuose mobiliesiems nenaudojamas įprastinis „ga.js“ stebėjimo kodas, poveikis yra toks pat, kaip naudojant nepažymėtus svetainės puslapius.
Pagrindinė WAP stebėjimo bibliotekos paskirtis yra leisti stebėti nepažangius mobiliuosius įrenginius, t. y. įrenginius su ribotu slapukų ir (arba) „JavaScript“ palaikymu.
Tačiau daugelis naujausių išmaniųjų telefonų dabar palaiko „JavaScript“, slapukus ir vaizdus, kaip ir įprasti staliniai kompiuteriai. Dėl didesnio išmaniųjų telefonų perėmimo, rekomenduojame perkelti puslapius mobiliesiems ir naudoti įprastinį ga.js stebėjimo fragmentą, o ne WAP stebėjimo biblioteką.
Ar peradresuojant persiunčiama sau? Daugeliu atveju peradresuojant neturėtų būti persiunčiama sau – išimčių ieškokite šio dokumento kryžminio domenų stebėjimo skiltyje. Peržiūrėkite kelis peradresavimo URL pavyzdžius ir jų poveikį kampanijos nustatymui „Analytics“.
301 / 302 peradresavimo URL
Šio tipo peradresavimo URL yra serverio inicijuojamas peradresavimo URL, siunčiantis HTTP būsenos kodą 301 arba 302. Labiausiai tikėtina, kad jūsų žiniatinklio valdytojas įdiegė tokį peradresavimo URL todėl, kad puslapis arba puslapių grupė buvo perkelta į kitą vietą.
301 / 302 peradresavimo URL turėtų būti išsaugota pradinė persiuntimo informacija.
Pavyzdys
Anksčiau pateiktoje diagramoje some-other-website.com naudotojas spustelėja nuorodą, nukreipiančią į jūsų example.com pagrindinį puslapį, pradeda veikti serverio 301 peradresavimo URL ir naudotojai persiunčiami į jūsų naują pagrindinio puslapio URL.
Esant šiam scenarijui 301 peradresavimo URL turėtų išsaugoti persiuntimo iš some-other-website.com informaciją (užfiksuotą naudojant „JavaScript“ „document.referrer“).
Metaduomenų atnaujinimo ir „JavaScript“ pagrįsti peradresavimai
Ne serverio inicijuojami peradresavimai, pvz., metaduomenų atnaujinimo HTML žyma arba „JavaScript“ „window.location“ metodai, gali paslėpti ar padaryti nesuprantamą persiuntimo URL informaciją iš „Analytics“, todėl jokiame puslapyje, kuris naudotojams gali būti nukreipimo puslapis, šių metodų naudoti nerekomenduojame.
Norėdami sužinoti daugiau apie „iframes“ naudojimo su „Analytics“ poveikį ir persiuntimų sau galimybes, žr. toliau pateiktą straipsnį apie įrėmintas svetaines ir „Analytics“.
Ar jums turi įtakos „flash“ stebėjimo API? Dirbant su šia stebėjimo biblioteka geriausia būtų naudoti tilto režimą, o ne AS3 režimą. Sužinokite daugiau čia. Naudojant tilto režimą „flash“ stebėjimo biblioteka gali užmegzti ryšį su tokiais pat slapukais kaip įprastinis ga.js stebėjimo kodas. Tai reiškia, kad „flash“ objekto veikla gali būti stebima ir atrandamas teisingas kampanijos šaltinis, t. y. šaltinis, naudotas jūsų svetainei rasti.
Naudojant AS3 režimą biblioteka naudos „flash“ slapukus. Siekdama nustatyti kampanijos šaltinį, biblioteka ieškos persiuntimo URL, naudoto „flash“ objektui atidaryti. Paprastai tai yra jūsų svetainė (pirminis puslapis), pvz., www.example.com
