Kung gumagamit ka ng Universal Analytics, kasama na ang Analytics ng Mobile App, malabong makakita ka ng maraming self-referral sa iyong mga ulat.
Background
Kapag may dumating na user sa iyong website, nagsusumikap ang Analytics na matukoy kung saan siya nanggaling - ang kanyang source ng trapiko. Ang source ay puwedeng ituring na direkta, organic (hindi bayad), campaign, o referral.
Ang mga referral ay karaniwang tinutukoy bilang trapiko papunta sa iyong site mula sa ibang website. Sa pamamagitan ng ulat sa Mga Referral sa kategoryang Pagkuha ng mga ulat, masusuri mo ang ganitong uri ng trapiko.
Paano ko malalaman kung mayroon akong mga self-referral?
Ang self-referral sa Analytics ay isang kundisyon kung saan nakikita mo ang paglabas ng iyong (mga) sariling domain sa ulat sa Pagkuha>Lahat ng Trapiko>Mga Referral. Halimbawa, kung www.example.com ang iyong website, ang anumang entry na makikita mo sa ulat na ito na may nakalistang www.example.com ay self-referral.
Kung naka-configure ang iyong pagpapatupad ng Analytics na sukatin ang mga session sa maraming domain at/o subdomain, posibleng natural ang mababang level ng mga self-referral.
Gayunpaman, ang maraming self-referral ay posibleng sintomas ng isang isyu sa iyong pagpapatupad ng Analytics, at posibleng nakakaimpluwensya ito sa mga sukatan mo at nagpapalabo sa mga aktwal na source ng trapiko kung saan dapat i-attribute ang mga pangunahing event at iba pang engagement sa iyong site.
Pagtukoy sa pinagmulan ng mga self-referral
analytics.js
Kung naka-tag ang iyong mga page gamit ang snippet na analytics.js, kailangan mong siguraduhin na naidagdag mo ang lahat ng iyong domain (kasama ang mga subdomain) sa Listahan ng Pagbubukod sa Referral para sa property mo:
- Mag-sign in sa iyong Analytics account.
- I-click ang Admin at mag-navigate papunta sa property na gusto mo.
- I-click ang Impormasyon ng pagsubaybay.
- I-click ang Listahan ng Pagbubukod sa Referral.
- I-click ang + MAGDAGDAG NG PAGBUBUKOD SA REFERRAL.
- Ilagay ang domain na gusto mong ibukod, pagkatapos ay i-click ang Gawin.
ga.js
Kung naka-tag sa iyong mga page ang snippet na ga.js, sa kasamang-palad ay walang iisang karaniwang dahilan ng mga self-referral; sa katunayan, maraming iba't ibang sitwasyon na maaaring humantong sa isang self-referral. Ang susubukang gawin ng gabay na ito ay ang bigyan ka ng isang listahan ng mga pinakakaraniwang dahilan na nakita namin sa mga website ng kliyente. Sundin ang gabay na ito bilang isang checklist upang matukoy ang dahilan ng iyong mga self-referral.
Upang matulungan ka sa paghahanap sa mga seksyon ng sarili mong content na maaaring magdulot ng problema, isinama namin ang sumusunod na filter ng view at custom na ulat na napakinabangan namin noong nagto-troubleshoot kami ng mga isyu sa self-referral. I-expand ang bawat seksyon para sa mga detalye:
Tingnan ang FilterUpang tumulong na limitahan ang dahilan ng mga self-referral, mag-navigate patungo sa ulat sa Pagkuha>Lahat ng Trapiko>Mga Referral.
Kapag nakakita ka ng entry para sa 1 sa iyong mga sariling domain, mag-drill down sa row para tingnan ang dimensyong path ng referral. Ang mga path ng referral na ito ay maaaring mga page sa iyong site na karapat-dapat na higit na siyasatin.Magbibigay sa iyo ang dimensyon na path ng referral ng kaunting impormasyon tungkol sa page na napuntahan ng isang tao bago mag-navigate papunta sa iyong site. Gayunpaman, bilang default, hindi kasama sa path ng referral ang bahaging parameter ng query ng nag-refer na URL, na posibleng maging mahalagang impormasyon. Para makita ang buong nag-refer na URL kasama ang mga parameter ng query, kailangan nating gumawa ng filter ng view.
Tingnan ang sumusunod na halimbawang path ng referral:
/path/sub-path/?query=123¶meter=456
Bilang default, ang ipapakita lang ng ulat sa path ng referral ay:
/path/sub-path/
Gamitin ang sumusunod na filter ng view para i-restore ang buong path ng referral sa mga ulat sa GA:
Babala: Bago maglapat ng anumang filter sa isang view ng Analytics, lubos naming inirerekomenda ang paggawa ng isang bagong pansubok na view (matutunan kung paano kumopya ng view). Lagi ka dapat magtabi ng hindi na-filter na view bilang sanggunian, na puwedeng magsilbing backup ng raw data at bilang source para matiyak mo na gumagana nang maayos ang iyong pangongolekta ng data.
Ang filter na karaniwan naming ginagamit ay puwedeng buuin ayon sa sumusunod:
Tingnan ang Mga Attribute ng Filter
- Pangalan ng Filter: Ipakita ang Buong Nag-refer na URL kasama ang mga parameter
- Uri ng Filter: Custom na Filter => Advanced
- Field A -> I-extract ang A: Medium ng Campaign, ^referral$
- Field B -> I-extract ang B: Referral, ^https?://[^/]+(/.*)
- I-output Sa -> Constructor: Content ng Campaign, $B1
- Kailangan ang Field A: Oo
- Kailangan ang Field B: Hindi
- I-override ang Field na Output: Oo
- Case Sensitive: Hindi
Mga karaniwang dahilan at solusyon para sa mga self-referral
May ilang karaniwang dahilan para sa mga self-referral. I-expand ang bawat seksyon para sa mga detalye:
Wala o Hindi Gumagana ang Tracking Code sa Landing PageIsang karaniwang dahilan ng mga self-referral ang mga landing page o page sa iyong website na hindi na-tag gamit ang tracking code ng Analytics. Ang plugin na Google Tag Assistant para sa Google Chrome ay makakatulong sa iyo na matuklasan ang mga problema sa nawawala at/o hindi gumaganang tracking code.
Dapat mong tiyaking may naka-install na tracking code ng Analytics ang lahat ng page sa iyong site.
Gamitin ang custom na ulat at filter ng view na binanggit sa itaas upang makatulong sa iyo na unti-unting matukoy ang (mga) page na may nawawala o sirang code.
Ang isa sa mga pinakakaraniwang dahilan ng mga self-referral ay dulot ng mga hindi pagkakapare-pareho sa configuration ng tracking code. Iniiba ng mga sumusunod na pamamaraan kung paano itinatakda at sino-store ang iyong cookies ng Analytics para sa (mga) domain mo.
Talagang napakahalaga na gawin ang mga pamamaraang ito nang magkakatugma sa iyong buong website. Kung iko-call mo ang mga pamamaraang ito sa paraang hindi magkakatugma sa magkakapareho o kahit sa magkakaibang page ng iyong website, maaaring maging dahilan ito na ma-reset o gumawa ng bagong hanay ng cookie ang Analytics. Sa alinmang sitwasyon, sinusubukan ng Analytics na tukuyin ang pinagmulan ng campaign, sa puntong ito madalas na nagkakaroon ng self-referral.
Tingnan natin ang ilang halimbawa kung saan maaari itong maganap:
Halimbawa ng Pagsubaybay sa Sub Domain:
Isang pangkaraniwang configuration ang pagsubaybay sa sub domain. Puwede kang matuto pa tungkol sa pagsubaybay sa sub domain dito. Gayunpaman, gumagamit ang ilang website ng maraming file ng template at nangangailangan ang mga ito na mailagay ang tracking code ng Analytics sa maraming lugar (hal. hindi gumamit ng panlahatang pagsasama sa kabuuan ng website). Sa mga sitwasyong tulad nito, tingnan kung nagsasama ang bawat isa sa iyong mga template upang matiyak na naglalaman ang mga ito ng pare-parehong tracking snippet ng Analytics.
Pag-isipan ang halimbawa sa itaas kung saan ang homepage at ang mga page ng produkto ay gumagamit ng 1 template at iba ang ginagamit ng mga page ng shopping cart.
Mali
Homepage: (www.example.com)_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push(['_setDomainName', 'example.com']); _gaq.push([‘_trackPageview’]);Page ng Shopping Cart: (basket.example.com)
_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push([‘_trackPageview’]);
Sa halimbawa sa itaas, ang mga user na lumilipat mula sa homepage papunta sa page ng shopping cart ay magkakaroon ng 2 hanay ng cookie (utma, utmb, utmz) na gagawin para sa (mga) session ng mga ito. 1 hanay sa ilalim ng bawat domain:
- example.com (homepage at page ng produkto)
- basket.example.com (shopping cart)
Ang hindi pagtawag sa _setDomainName ay kapareho ng epekto ng pagtawag sa _setDomainName(‘auto’). Kapag ginamit ang paraang document.domain, gagawa ang ga.js ng cookies para sa basket.example.com.
Para maiwasan ang mga self-referral sa sitwasyong ito, gusto mong magbasa ang Analytics mula sa 1 hanay ng cookies, ang user man ay nasa top-level na domain na www.example.com o nasa sub-domain na basket.example.com.
Upang matiyak na gumagamit ng 1 hanay ng cookies para sa iyong pangunahing domain at mga sub-domain nito. Isama ang _setDomainName na linya sa iyong snippet ng Analytics sa iyong buong website.
Solusyon: Tiyaking magkakatugma ang kino-call ng tracking code na mga pamamaraan na nagbabago sa paraan kung paano tinutukoy ang cookies ng Analytics.
Tama
Homepage: (www.example.com)_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push(['_setDomainName', 'example.com']); _gaq.push([‘_trackPageview’]);Page ng Shopping Cart: (basket.example.com)
_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push(['_setDomainName', 'example.com']); _gaq.push([‘_trackPageview’]);
Halimbawa ng Maraming Tracking Code ng Analytics
Isang sikat na configuration na ginagamit ng maraming kliyente pero karaniwang hindi sinusuportahan ang configuration na may maraming tracker. Ginagamit ito para magpadala ng impormasyon sa maraming Analytics account nang sabay-sabay.
Isang karaniwang maling pag-unawa sa configuration na ito ang pagpapalagay na isang hiwalay na entity (o object) ang bawat tracker. Pero ang totoo, itinatakda ang cookies sa level ng domain at hindi sa level ng tracker, kaya ang lahat ng tracker object sa parehong page ay nagbabahagi at nagbabasa mula sa parehong hanay ng cookie.
Samakatuwid, ang pagpapanatiling pare-pareho sa iyong tracking code sa maraming object ng tracker ay kasinghalaga ng pagiging pare-pareho sa lahat ng page sa iyong website tulad ng sa ibinigay naming halimbawa ng sub-domain sa itaas.
Mali
_gaq.push( ['firstTracker._setAccount', 'UA-XXXXX-1'], [‘firstTracker._setDomainName’, ‘example.com’], ['firstTracker._trackPageview'], ['secondTracker._setAccount', 'UA-XXXXX-2'], ['secondTracker._trackPageview'] );
Napansin mo ba kung paano hindi na-call ng secondTracker ang paraan na _setDomainName? Malamang na hahantong ito sa mga isyu sa self-referral para sa parehong mga tracker at mga web-property na UA-XXXXX-1 at UA-XXXXX-2
Solusyon: Palaging tiyakin na kino-call ng lahat ng object ng tracker sa parehong domain ang mga parehong pamamaraan, ibig sabihin, naka-configure nang pareho upang mapigilan ang mga posibilidad na magresulta ito sa pagkakasalungatan sa pagitan ng mga tracker. Sa susunod na halimbawa, parehong na-call ang _setDomainName para sa parehong tracker.
Tama
_gaq.push( ['firstTracker._setAccount', 'UA-XXXXX-1'], [‘firstTracker._setDomainName’, ‘example.com’], ['firstTracker._trackPageview'], ['secondTracker._setAccount', 'UA-XXXXX-2'], [‘secondTracker._setDomainName’, ‘example.com’], ['secondTracker._trackPageview'] );
Halimbawa ng Pagsubaybay na Cross-Domain
Isa pang karaniwang configuration ng Analytics ang pagsubaybay sa aktibidad ng user sa maraming top-level na domain. Matuto pa tungkol sa pagsubaybay na cross-domain
Kapag mayroon kang 2 domain, hal: www.example.com at www.otherexample.com at gusto mong subaybayan ang mga aktibidad habang nagpapalipat-lipat sa mga domain na ito ang mga user, kinakailangan mong gamitin ang 1 sa mga sumusunod na paraan:
Nagbibigay-daan ang mga pamamaraang ito na maipasa ang data ng cookie ng Analytics sa pagitan ng mga domain. Lubos na magdedepende ang gagamitin mong pamamaraan sa kung paano lumilipat ang mga user sa pagitan ng mga domain, hal., nag-click sila ng isang link o nagsumite ng form, nagbukas ng iframe atbp.
Gayunpaman, isang karaniwang problema na nakikita namin ay hindi lahat ng link, form o iframe ay naka-tag nang tama upang makapagpasa ng impormasyon sa pagitan ng magkaibang domain.
Halimbawang HTML page (sa www.example.com)
Mali
<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>
Sa halimbawa sa itaas, naka-configure ang link 1 upang magpasa ng impormasyon ng cookie ng Analytics sa otherexample.com, gayunpaman hindi naglalaman ang link 2 ng onclick na attribute.
Ang mga user na magki-click sa link 1 ay susubaybayan nang tumpak sa lahat ng domain. Ang mga user na magki-click sa link 2 ay mairerehistro bilang referral mula sa example.com
Solusyon: Dapat mong tiyakin na naka-tag nang naaangkop ang lahat ng link upang makapagpasa ng impormasyon ng cookie mula sa example.com papunta sa otherexample.com
Tama
<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: Kung marami kang link na humahantong sa isa pang domain, puwede kang gumamit ng framework ng Javascript (hal: JQuery) para makinig ng mga event na onclick na nagpapasa ng mga user sa iba mo pang (mga) domain.
Sa paggawa nito, hindi mo na kailangan manual na i-tag ang bawat link at isa itong hindi halata at mas pinipiling pamamaraan sa pangangasiwa ng mga link na cross domain.
Mga pag-redirect sa pagitan ng mga domain
Sasaklawan natin ang mga pag-redirect nang mas detalyado sa mga susunod na bahagi ng artikulo, ngunit ang isa pang karaniwang dahilan ng mga self-referral sa pagsubaybay na cross-domain ay kapag inaalis ng isang pag-redirect ang impormasyon ng cookie na cross domain bago magkaroon ang Google Analytics ga.js ng pagkakataon na mabasa ang impormasyong ito mula sa URL sa tatanggap na domain.
Gamit muli ang nakaraan nating halimbawang cross domain na HTML:
Halimbawang HTML page (sa 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>
Bubuo ang pamamaraang _link ng isang URL ng cross domain ng Analytics tulad ng nasa ibaba:
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
Gayunpaman, kung may nagaganap na pag-redirect sa home page:
http://www.otherexample.com/
at dinadala nito ang mga user sa:
http://www.otherexample.com/home
Posibleng hindi maisama ng mga pag-redirect ang cross-domain na impormasyon ng Analytics at posibleng ipasa ito sa na-redirect na 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
Nagre-redirect sa:
http://www.otherexample.com/home
Tandaan: Ang kawalan ng mga cross domain na parameter ng Analytics na (?__utma=......).
Madalas itong nangyayari dahil hindi naisasaalang-alang ng marami sa mga server-side based na pag-redirect ang mga parameter ng query na nasa nakaraang URL. Ang panuntunan sa pag-redirect ay naglilipat lang ng mga user mula sa 1 URL papunta sa susunod, pero hindi nito pinapanatili ang mga parameter ng cookie na ito habang nagre-redirect.
Mga Solusyon:
-
Tiyaking ang pag-redirect ay may mga parameter sa pagsubaybay ng Analytics sa kasunod na URL, hal:
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
-
Gayundin, puwede mo ring alisin ang pag-redirect o i-update ang link sa (mga) nakaraang domain para tumuro sa bagong lokasyon para walang masisimulang pag-redirect.
Gumagamit ka ba ng sub-domain sa mobile o mayroon ka bang pang-mobile na bersyon ng iyong site na nasa parehong domain?
Isang pangkaraniwang kagawian ang paggawa ng pang-mobile na bersyon ng iyong website na maa-access mula sa isang sub-domain, hal: m.example.com
Kung na-configure mo ang pang-mobile na bersyon ng iyong website para gamitin ang server-side na library sa pagsubaybay ng Analytics (PHP, JSP, ASP.NET, at Perl) - na karaniwang tinatawag na pagsubaybay sa WAP, at may kakayahan ang mga user na mag-navigate sa pagitan ng pang-mobile na bersyon at kumpletong bersyon ng iyong website, puwede kang makakita ng mga self-referral mula sa mga pang-mobile at pangunahing domain mo.
Kung hindi ginagamit ng iyong mga page sa mobile ang karaniwang tracking code ng ga.js, pareho din ang epekto tulad ng pagkakaroon ng mga hindi naka-tag na page sa iyong website.
Ang pangunahing layunin ng library ng pagsubaybay sa WAP ay mabigyang-daan ang pagsubaybay sa mga low end na mobile device, ibig sabihin, ang mga device na may limitadong suporta para sa cookies at / o javascript.
Gayunpaman, marami sa mga pinakabagong smart phone ang sumusuporta na rin ngayon ng javascript, cookies, at mga larawan tulad ng mga regular na desktop machine. Dahil sa dumaraming paggamit ng mga smart phone, inirerekomenda naming ilipat ang iyong mga page sa mobile upang magamit ang regular na tracking snippet ng ga.js sa halip na gamitin ang library sa pagsubaybay sa WAP.
Nagreresulta ba ang mga self-referral sa mga pag-redirect? Kadalasan, ang mga pag-redirect ay hindi dapat magresulta sa mga self-referral - para sa isang pagbubukod, tingnan ang seksyong cross domain ng dokumentong ito. Tingnan natin ang ilang halimbawa ng mga pag-redirect at ang kanilang epekto sa setting ng campaign sa Analytics.
Mga pag-redirect na 301/302
Ang uri ng pag-redirect na ito ay isang pag-redirect na sinisimulan sa panig ng server at ipinapadala ang status code ng HTTP na 301 o 302. Ang webmaster mo ang magpapatupad ng ganoong pag-redirect at ang pinakakaraniwang dahilan sa paggawa niyon ay dahil mayroong page o pangkat ng mga page na lumipat ng lokasyon.
Dapat na mapanatili ng pag-redirect na 301/302 ang orihinal na impormasyon ng referral.
Halimbawa:
Sa diagram sa itaas, ang isang user sa some-other-website.com ay nag-click sa isang link na nagdidirekta sa iyong homepage sa example.com, magaganap ang isang pag-redirect na 301 sa panig ng server at dadalhin ang mga user sa bagong URL para sa iyong homepage /home.
Sa sitwasyong ito, dapat mapanatili ng pag-redirect na 301 ang impormasyon ng referral (na nakuha sa pamamagitan ng javascript document.referrer) mula sa some-other-website.com.
Mga pag-redirect na batay sa meta refresh at javascript
Ang mga pag-redirect na na-invoke na wala sa panig ng server gaya ng mga pamamaraan ng meta refresh html tag o javascript window.location ay maaaring maitago o gawing hindi halata ang impormasyon ng referrer mula sa Analytics, kaya naman hindi namin inirerekomenda ang mga ganoong pamamaraan sa anumang page na malamang na isang landing page.
Para matuto pa tungkol sa epekto ng paggamit ng mga iframe sa Analytics at sa potensyal para sa mga self-referral, sumangguni sa sumusunod na artikulo sa mga naka-frame na site at Analytics.
Ginagamit mo ba ang mga Flash Tracking API? Kapag ginagamit mo ang library sa pagsubaybay na ito, mas gugustuhin mong gamitin ang Bridge mode kaysa sa AS3 mode. Matuto pa rito. Binibigyang-daan ng paggamit sa Bridge mode ang library sa pagsubaybay sa Flash na makipag-ugnayan gamit ang parehong cookies bilang ang regular na tracking code ng ga.js. Nangangahulugan ito na ang aktibidad sa loob ng isang flash object ay maaaring masundan hanggang sa tamang pinagmulan ng campaign hal. ang ginamit na pinagmulan upang mahanap ang iyong website.
Kapag gumagamit ng AS3 mode gagamit ang library ng cookies na Flash. Para matukoy ang source ng campaign, hahanapin ng library ang nag-refer na URL na ginamit para buksan ang flash object, kadalasan, ito ang sarili mong website (parent page) hal: www.example.com
