Jeśli korzystasz z Universal Analytics, w tym Analytics dla aplikacji mobilnych, prawdopodobnie nie zobaczysz w swoich raportach zbyt wielu odesłań wewnętrznych.
Tło
Gdy użytkownik przechodzi do Twojej witryny, Analytics próbuje określić, skąd przybył, czyli jakie jest źródło jego odwiedzin. Możliwości są następujące: odwiedziny bezpośrednie, odwiedziny z wyszukiwarki (bezpłatne), odwiedziny z kampanii lub odesłanie.
Odesłania są ogólnie definiowane jako ruch w witrynie pochodzący z innej witryny. Do jego analizowania służy raport Odesłania w kategorii Pozyskiwanie.
Jak mogę się dowiedzieć, czy mam odesłania wewnętrzne?
W Analytics samodzielne odesłanie to sytuacja, w której w raporcie Pozyskiwanie > Cały ruch > Odesłania znajdują się Twoje własne domeny. Jeśli np. Twoja witryna to www.example.com, każda pozycja w raporcie zawierająca www.example.com jest odesłaniem wewnętrznym.
Jeśli Twoja usługa Analytics została wdrożona i skonfigurowane tak, aby liczyć sesje w wielu domenach lub subdomenach, marginalny poziom odesłań wewnętrznych może być zjawiskiem naturalnym.
Odesłania wewnętrzne mogą jednak wskazywać na problem z wdrożeniem Analytics, przekłamywać dane i przesłaniać rzeczywiste źródła odwiedzin, do których należy przypisywać kluczowe zdarzenia i inne formy interakcji w Twojej witrynie.
Określanie pochodzenia odesłań wewnętrznych
Biblioteka analytics.js
Jeśli masz strony oznaczone fragmentem kodu analytics.js, musisz upewnić się, że wszystkie Twoje domeny (i subdomeny) są na liście wykluczeń odesłań dla Twojej usługi:
- Zaloguj się na konto Analytics.
- Kliknij Administracja i przejdź do odpowiedniej usługi.
- Kliknij Informacje o śledzeniu.
- Kliknij Lista wykluczeń stron odsyłających.
- Kliknij + DODAJ WYKLUCZENIE STRONY ODSYŁAJĄCEJ.
- Podaj domenę, którą chcesz wykluczyć, i kliknij Utwórz.
Biblioteka ga.js
W przypadku stron otagowanych fragmentem kodu ga.js nie można określić jednej najczęstszej przyczyny odesłań wewnętrznych. Mogą one być wynikiem wielu różnych scenariuszy. W tym przewodniku znajdziesz listę najczęstszych przyczyn, jakie występują w witrynach naszych klientów. Możesz użyć go jako listy kontrolnej umożliwiającej eliminowanie kolejnych przyczyn, aż znajdzie się ta, która leży u podstaw Twoich samodzielnych odesłań.
W zlokalizowaniu potencjalnie problematycznych sekcji Twojej witryny może pomóc Ci poniższy filtr widoku oraz raport niestandardowy, które przydają się podczas rozwiązywania problemów z samodzielnymi odesłaniami. Rozwiń wybraną sekcję, by uzyskać szczegółowe informacje:
Wyświetl filtrAby spróbować określić przyczynę występowania samodzielnych odesłań, przejdź do raportu Pozyskiwanie > Cały ruch > Odesłania.
Jeśli zobaczysz wpis dla jednej z Twoich domen, przejdź do jej wiersza, by wyświetlić zakres ścieżki odesłania. Te ścieżki odesłania mogą wskazywać na strony Twojej witryny, którym warto przyjrzeć się bliżej.Zakres ścieżki odesłania powie Ci coś więcej o stronie, na której przebywał użytkownik przed przejściem do Twojej witryny. Domyślnie ścieżka odesłania nie zawiera jednak części adresu URL zawierającej parametry zapytania, które mogą być cennym źródłem informacji. Aby zobaczyć pełny URL odesłania razem z parametrami zapytania, musisz utworzyć filtr widoku.
Przeanalizujmy tę przykładową ścieżkę odesłania:
/path/sub-path/?query=123¶meter=456
Domyślnie raport o ścieżce odesłania będzie zawierać tylko tę jej część:
/path/sub-path/
Aby przywrócić w raportach Analytics pełną ścieżkę odesłania, użyj następującego filtru widoku:
Uwaga: zdecydowanie zalecamy utworzenie nowego widoku testowego (duplikatu) przed zastosowaniem jakiegokolwiek filtru w widoku Analytics (dowiedz się, jak skopiować widok). Należy zawsze zachować widok niefiltrowany jako punkt odniesienia. Może on stanowić kopię zapasową nieprzetworzonych danych oraz służyć do zweryfikowania, czy dane są zbierane prawidłowo.
Najczęściej używany filtr można utworzyć w następujący sposób:
Atrybuty widoku filtru
- Nazwa filtru: pełny adres URL witryny odsyłającej razem z parametrami
- Typ filtru: Filtr niestandardowy > Zaawansowany
- Pole A -> Wyodrębnij A: Medium kampanii, ^referral$
- Pole B -> Wyodrębnij B: Odesłanie, ^https?://[^/]+(/.*)
- Dane wyjściowe -> Konstruktor: Treść kampanii, $B1
- Wymagane pole A: Tak
- Wymagane pole B: Nie
- Zastąp pole danych wyjściowych: Tak
- Z uwzględnieniem wielkości liter: Nie
Najczęstsze przyczyny występowania samodzielnych odesłań i sposoby rozwiązania problemu
Samodzielne odesłania mogą występować z kilku przyczyn. Rozwiń wybraną sekcję, by uzyskać szczegółowe informacje:
Brakujący lub niedziałający kod śledzenia na stronie docelowejTypową przyczyną odesłań wewnętrznych jest brak otagowania stron docelowych lub stron witryny kodem śledzenia Analytics. Wtyczka Google Tag Assistant do przeglądarki Google Chrome pomoże Ci rozwiązać problemy z brakującym lub niedziałającym kodem śledzenia.
Upewnij się, że wszystkie strony Twojej witryny mają zainstalowany kod śledzenia Analytics.
Za pomocą raportu niestandardowego i filtru widoku wymienionych powyżej możesz wyodrębnić strony z brakującym lub niedziałającym kodem.
Jedną z najczęstszych przyczyn samodzielnych odesłań jest niespójność konfiguracji kodu śledzenia. Poniższe metody zmieniają sposób ustawiania i zapisywania plików cookie Analytics dla Twoich domen.
Jest niezwykle ważne, by wywoływać te metody w konsekwentny sposób w obrębie całej witryny. Jeśli metody te będą wywoływane niekonsekwentnie na tej samej stronie albo nawet na różnych stronach witryny, może to spowodować zresetowanie lub utworzenie nowego zestawu plików cookie przez Analytics. W obu sytuacjach Analytics próbuje ustalić źródło kampanii i w tym właśnie momencie występuje samodzielne odesłanie.
Przyjrzyjmy się kilku przykładom miejsc, w których może to nastąpić:
Przykład związany ze śledzeniem subdomen:
Śledzenie subdomen to często spotykana konfiguracja. Więcej informacji na jej temat można znaleźć tutaj. Jednak w niektórych witrynach wykorzystuje się wiele plików szablonów, co wymaga wstawienia kodu Analytics w wielu miejscach (tzn. wstawienie w całej witrynie nie jest obsługiwane). W takich przypadkach należy sprawdzić zawartość każdego szablonu, by upewnić się, że znajduje się w nich taki sam fragment kodu śledzenia Analytics.
Przeanalizujmy przykład, w którym strona główna i strony produktu mają jeden szablon, a koszyk na zakupy ma drugi szablon.
Źle
Strona główna: (www.example.com)_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push(['_setDomainName', 'example.com']); _gaq.push([‘_trackPageview’]);Strona koszyka: (koszyk.example.com)
_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push([‘_trackPageview’]);
W powyższym przykładzie użytkownicy, którzy przechodzą ze strony głównej na stronę koszyka, będą mieli dwa zestawy plików cookie (utma, utmb, utmz) utworzone dla swoich odwiedzin, po jednym zestawie w każdej domenie:
- example.com (strona główna i strona produktu)
- koszyk.example.com (koszyk na zakupy)
Niewywołanie _setDomainNamema taki sam skutek jak wywołanie _setDomainName('auto'). Użycie metody document.domain spowoduje utworzenie przez ga.js plików cookie dla witryny koszyk.example.com.
Aby zapobiec odesłaniom wewnętrznym w tej sytuacji, Analytics musi odczytywać 1 zestaw plików cookie niezależnie od tego, czy użytkownik znajduje się w domenie najwyższego poziomu www.example.com czy w subdomenie koszyk.example.com.
Aby upewnić się, że jeden zestaw plików cookie jest używany dla domeny nadrzędnej i jej subdomen, dołącz wiersz _setDomainName we fragmencie kodu Analytics w całej witrynie.
Rozwiązanie: upewnij się, że Twój kod śledzenia w jednolity sposób wywołuje metody, które zmieniają sposób definiowania plików cookie Analytics.
Dobrze
Strona główna: (www.example.com)_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push(['_setDomainName', 'example.com']); _gaq.push([‘_trackPageview’]);Strona koszyka: (koszyk.example.com)
_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push(['_setDomainName', 'example.com']); _gaq.push([‘_trackPageview’]);
Przykład kodu śledzenia wielokrotnego Analytics
Częstą, chociaż zasadniczo nieobsługiwaną konfiguracją, którą stosuje wielu klientów, jest konfiguracja modułu śledzenia wielokrotnego. Służy ona do wysyłania informacji na wiele kont Analytics naraz.
W przypadku tej konfiguracji klienci często błędnie zakładają, że każdy moduł śledzący to oddzielna jednostka (lub obiekt), podczas gdy w rzeczywistości pliki cookie są ustawiane na poziomie domeny, a nie modułu śledzącego, więc wszystkie obiekty tego modułu na tej samej stronie mają wspólny zestaw plików cookie, z którego odczytują dane.
Spójność kodu śledzenia w wielu obiektach skryptu śledzenia jest tak samo ważna jak spójność na wszystkich stronach witryny. Pokazuje to omówiony wcześniej przykład sub-domain.
Nieprawidłowo
_gaq.push( ['firstTracker._setAccount', 'UA-XXXXX-1'], [‘firstTracker._setDomainName’, ‘example.com’], ['firstTracker._trackPageview'], ['secondTracker._setAccount', 'UA-XXXXX-2'], ['secondTracker._trackPageview'] );
Zauważ, że moduł secondTracker nie wywołał metody _setDomainName. To może spowodować problemy z odesłaniami wewnętrznymi zarówno dla obu modułów śledzących, jak i usług sieciowych UA-XXXXX-1 i UA-XXXXX-2.
Rozwiązanie: zawsze sprawdzaj, czy wszystkie obiekty skryptu śledzenia w danej domenie wywołują te same metody, a więc są tak samo skonfigurowane. Pozwoli to uniknąć konfliktu między obiektami. W poniższym przykładzie metoda_setDomainName jest wywoływana konsekwentnie przez oba moduły śledzące.
Prawidłowo
_gaq.push( ['firstTracker._setAccount', 'UA-XXXXX-1'], [‘firstTracker._setDomainName’, ‘example.com’], ['firstTracker._trackPageview'], ['secondTracker._setAccount', 'UA-XXXXX-2'], [‘secondTracker._setDomainName’, ‘example.com’], ['secondTracker._trackPageview'] );
Przykład śledzenia w wielu domenach
Kolejna często używana konfiguracja Analytics to śledzenie aktywności użytkownika w wielu domenach najwyższego poziomu. Więcej informacji o śledzeniu w wielu domenach.
Jeśli masz 2 domeny, np. www.example.com i www.otherexample.com, i chcesz śledzić aktywność związaną z przechodzeniem użytkowników między tymi domenami, musisz użyć jednej z następujących metod:
Metody te umożliwiają przekazywanie danych plików cookie Analytics między domenami. Stosowana metoda zależy głównie od sposobu poruszania się użytkowników między domenami: przez kliknięcie linku, przesłanie formularza, otwarcie elementu iframe itp.
Często występującym problemem jest brak poprawnego otagowania linków, formularzy lub elementów iframe, co umożliwia przekazywanie informacji między różnymi domenami.
Przykład dla strony HTML (w witrynie www.example.com)
Źle
<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>
W powyższym przykładzie link 1 jest tak skonfigurowany, by przekazywać informacje z plików cookie Analytics do witryny otherexample.com. Z kolei link 2 nie zawiera atrybutu onclick.
Użytkownicy, którzy kliknęli link 1, będą prawidłowo śledzeni w wielu domenach. Użytkownicy, którzy kliknęli link 2, zostaną zarejestrowani jako odesłania z witryny example.com.
Rozwiązanie: upewnij się, że wszystkie linki są odpowiednio otagowane pod kątem przekazywania informacji z plików cookie z witryny example.com do otherexample.com.
Dobrze
<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>
Wskazówka: jeśli masz wiele linków prowadzących do innej domeny, możesz wykorzystać bibliotekę JavaScript (np. JQuery), aby rejestrować zdarzenia onclick, które przekierowują użytkowników do innych Twoich domen.
To jest zalecana, dyskretna metoda obsługi linków w wielu domenach, dzięki której nie trzeba tagować każdego linku samodzielnie.
Przekierowania między domenami
Przekierowania zostaną omówione dokładniej w dalszej części artykułu, ale inną częstą przyczyną samodzielnych odwołań w przypadku śledzenia wielu domen jest usunięcie przez przekierowanie informacji z plików cookie wielu domen przed odczytaniem przez kod Analytics ga.js tych informacji z adresu URL w domenie odbierającej dane.
Jeszcze raz spójrzmy na poprzedni przykład związany z wieloma domenami:
Przykład dla strony HTML (w witrynie 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>
Metoda _link wygeneruje adres URL Analytics dla wielu domen, taki jak:
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
Jeśli jednak przekierowanie ma miejsce na stronie głównej:
http://www.otherexample.com/
i przekierowuje użytkowników do:
http://www.otherexample.com/home
może nie uwzględnić informacji Analytics dla wielu domen i przekazać je do przekierowanego adresu 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
Przekierowanie nastąpi do:
http://www.otherexample.com/home
Uwaga: brakuje parametrów Analytics dla wielu domen (?__utma=......).
Często tak się dzieje, ponieważ wiele przekierowań po stronie serwera nie uwzględnia parametrów zapytania obecnych w poprzednim adresie URL. Reguła przekierowania po prostu przenosi użytkowników z jednego adresu URL do następnego, ale nie zachowuje parametrów plików cookie podczas przekierowania.
Rozwiązania:
-
Upewnij się, że przekierowanie przenosi parametry śledzenia Analytics do następnego adresu URL, np.:
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
-
Ewentualnie możesz usunąć przekierowanie lub zaktualizować link w poprzednich domenach tak, by wskazywał nową lokalizację, dzięki czemu nie zostanie wywołane żadne przekierowanie.
Używasz subdomeny mobilnej lub masz wersję swojej witryny na komórki w tej samej domenie?
Zwykle w takiej sytuacji tworzy się mobilną wersję witryny dostępną z poziomu subdomeny, np. m.example.com.
Jeśli mobilna wersja Twojej witryny została tak skonfigurowana, sby używać biblioteki śledzenia Analytics (PHP, JSP, ASP.NET i Perl), zwanej również śledzeniem WAP, a użytkownicy mogą przełączać się między mobilną a pełną wersją witryny, możesz zauważyć odesłania wewnętrzne z domen mobilnej i głównej.
Jeśli Twoje strony mobilne nie używają zwykłego kodu śledzenia ga.js, efekt jest taki sam jak w przypadku nieotagowanych stron w witrynie.
Głównym celem biblioteki śledzenia WAP jest umożliwienie śledzenia mniej zaawansowanych urządzeń mobilnych, czyli urządzeń z ograniczonymi możliwościami obsługi plików cookie lub języka JavaScript
Wiele najnowszych smartfonów obsługuje już język JavaScript, pliki cookie i grafikę tak samo jak zwykłe komputery stacjonarne. Ze względu na coraz większą popularność smartfonów zalecamy stosowanie na stronach mobilnych zwykłego fragmentu kodu śledzenia ga.js zamiast biblioteki śledzenia WAP.
Czy przekierowania powodują odesłania wewnętrzne? Na ogół przekierowania nie powinny powodować samodzielnych odesłań. Wyjątek został opisany w sekcji tego dokumentu poświęconej wielu domenom. Przyjrzyjmy się kilku przykładom przekierowań oraz ich wpływowi na ustawienia kampanii w Analytics.
Przekierowania 301/302
Ten typ przekierowania jest wywoływany po stronie serwera i wysyła kod stanu HTTP 301 lub 302. Takie przekierowanie jest wdrażane przez webmastera, a najczęstszym jego powodem jest zmiana lokalizacji przez stronę lub grupę stron.
Przekierowania 301/302 powinny zachowywać informacje oryginalnych witryn odsyłających.
Przykład
Na powyższym schemacie użytkownik innej witryny klika link prowadzący do Twojej strony głównej w witrynie example.com. Następuje przekierowanie 301 po stronie serwera, które kieruje użytkownika do nowego adresu URL strony głównej /home.
W tym scenariuszu przekierowanie 301 powinno zachować informacje o witrynie odsyłającej (zarejestrowane za pomocą metody JavaScript document.referrer) z tej innej witryny.
Przekierowania typu „meta refresh” i przekierowania oparte na języku JavaScript
Przekierowania po stronie innej niż strona serwera, takie jak tag HTML meta refresh czy metody JavaScript window.location, mogą ukryć lub przesłonić informacje o witrynie odsyłającej z Analytics, dlatego nie zalecamy stosowania tych metod na żadnej stronie, która może być stroną docelową dla użytkowników.
Więcej informacji o wpływie stosowania elementów iframe na Analytics i o możliwości występowania odesłań wewnętrznych można znaleźć w artykule o witrynach z ramkami i Analytics.
Stosujesz interfejsy API śledzenia elementów Flash? Pracując z tą biblioteką śledzenia, najlepiej jest używać trybu Bridge zamiast trybu AS3 (więcej informacji). Tryb Bridge umożliwia bibliotece śledzenia elementów Flash komunikowanie się za pomocą tych samych plików cookie co zwykły kod śledzenia ga.js. To oznacza, że aktywność w obrębie obiektu Flash można wyśledzić aż do prawidłowego źródła kampanii, tj. źródła, które posłużyło do znalezienia Twojej witryny.
W trybie AS3 biblioteka korzysta z plików cookie Flash. Aby określić źródła kampanii, biblioteka będzie szukać adresu URL odesłania użytego do otwarcia obiektu Flash. Jest to zazwyczaj Twoja witryna (strona nadrzędna), np. www.example.com.
