Napisane przez :
dnia: środa, 22 kwi, 2009
8

Instalacja kodu Google Analytics na Twojej witrynie to więcej niż kopiuj-wklej (2/3)

Zasada działania Google Analytics polega na wykonywaniu kodu JavaScript na każdej przeglądanej przez odwiedzającego stronie. Naturalnie aby kod został wykonany musi być poprawnie zainstalowany. Proces instalacji określa się także mianem tagowania stron kodem. Na czym on polega?

Po założeniu konta i określeniu nazwy profilu dostajemy mniej więcej taki kod:

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA-123456-1");
pageTracker._trackPageview();
} catch(err) {}</script>

Pierwsza część kodu bada w jakim protokole dana strona jest oglądana: http czy https. Zależnie od tego zmieniana jest lokalizacja pliku ga.js, który zawiera w sobie cały mechanizm śledzenia zachowania użytkowników.

Druga część deklaruje obiekt trackera na podstawie unikalnego identyfikatora naszego konta i profilu (UA-123456-1). Zaraz po tym następuje wywołanie metody _trackPageview() – to właśnie ta linijka odpowiada za przesłanie danych do Google. Sam proces przesłania danych polega na wywołaniu przez przeglądarkę odwiedzającego pliku __utm.gif. Wywołanie to wzbogacone jest o cały szereg parametrów, dodawanych do pliku (__utm.gif?parametr1=wartosc1&parametr2=wartosc2 itd.).

Do poprawnego działania Analytics wymaga, by fragment kodu podobny do powyższego znalazł się na każdej stronie w obrębie witryny. Niby proste, ale po drodze zdarzyć może się wiele rzeczy :).

Umieszczanie kodu Analytics w kodzie źródłowym witryny

Manual Analytics zaleca umieszczanie kodu śledzącego jako ostatniego elementu przed zamykającym tagiem </body>. Zaletą takiego rozwiązania jest minimalny wpływ ewentualnego niepowodzenia z ładowaniem się Analytics na całość działania witryny. Wadą z kolei jest to, że jako ładowany ostatniej kolejności, kod śledzący jest również w ostatni w wykonywaniu przez przeglądarkę. Jeśli więc wcześniej w kodzie danej strony pojawi się jakiś fragment dokonujący np. przekierowania – jest duża szansa, iż odsłona tej strony nie zostanie przez Analytics zarejestrowana. Podobny scenariusz jest możliwy w momencie, kiedy sama strona ładuje się relatywnie długo i przed ukończeniem tego procesu użytkownik dokona jakiejś akcji (klik w link). Kod Analyticsa po prostu nie zdąży się wykonać.

Umieszczanie kodu Analytics przy korzystaniu z modułu e-commerce

Korzystanie z możliwości oferowanych przez moduł e-commerce wymaga trochę innej instalacji kodu Analytics. Kod e-commerce wygląda mniej więcej tak:

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
 
<script type="text/javascript">
  var pageTracker = _gat._getTracker("UA-XXXXX-1");
 
  pageTracker._trackPageview();
 
  pageTracker._addTrans(
    "1234",                                     // Order ID
    "Mountain View",                            // Affiliation
    "11.99",                                    // Total
    "1.29",                                     // Tax
    "5",                                        // Shipping
    "San Jose",                                 // City
    "California",                               // State
    "USA"                                       // Country
  );
 
  pageTracker._addItem(
    "1234",                                     // Order ID
    "DD44",                                     // SKU
    "T-Shirt",                                  // Product Name 
    "Green Medium",                             // Category
    "11.99",                                    // Price
    "1"                                         // Quantity
  );
  pageTracker._trackTrans();
</script>

Wartości poszczególnych argumentów metod _addTrans() i _addItem() są zazwyczaj wypełniane po stronie serwera, na przykład przez wywołania PHP (na tym głównie polega różnica pomiędzy JavaScriptem a PHP i językami podobnymi – JS wykonuje przeglądarka, a PHP serwer, przed wysłaniem kodu źródłowego strony do przeglądarki).

Silniki sklepów są zazwyczaj złożonymi aplikacjami. Składają się z kilkudziesięciu (lub więcej) plików, poukładanych w określony sposób (zależnie od pełnionej funkcji). Im więcej złożoności, tym mniejsze pole manewru. Teoretycznie możliwe jest takie wykonanie silnika sklepu, by pozwalał on na poprawne działanie kodu Analytics w miejscu pierwotnie do tego przeznaczonym (czyli przed zamykającym tagiem </body>). W praktyce jednak dokonanie odpowiednich modyfikacji okazać może się bardzo czasochłonne. Co więcej, jeśli korzystamy z oprogramowania pisanego przez osoby trzecie, należy pamiętać o potrzebie dokonywania ponownych modyfikacji po każdorazowej aktualizacji silnika sklepu.

W tej sytuacji warto zastanowić się, czy lepszym rozwiązaniem nie będzie zadeklarowanie pliku ga.js w sekcji <head>. Można to zrobić albo wyłącznie dla strony z potwierdzeniem zamówienia, albo dla wszystkich stron. Należy jednak rozważyć ewentualne konsekwencje.

Kod Google Analytics ga.js – zdalnie czy lokalnie?

Zmorą osób korzystających z Analytics bywa długi czas ładowania się zdalnego pliku ga.js. Zjawisko to występuje zazwyczaj po aktualizacji pliku przez samo Google. Wtedy dosłownie cały Internet chce go pobrać na nowo :). Widzisz, że strona się załadowała, ale kółeczko w przeglądarce cały czas się kręci. Przeglądarka próbuje porozumieć się z rozgrzanym do czerwoności serwerem Google, by także pobrać plik ga.js. O ile Ty jako webmaster wiesz co jest grane, o tyle Twoi odwiedzający nie muszą takiej wiedzy posiadać. W zamian mogą mieć wrażenie, że Twoja witryna po prostu się popsuła. To nie wszystko. O wiele poważniejszy problem wystąpi jeśli, korzystając z modułu e-commerce, decydujesz się na deklarowanie ga.js w sekcji <head> strony z konwersją. Jeżeli akurat dojdzie do spowolnienia w ładowaniu tego pliku z serwerów Google – Twoja strona po prostu się nie wyświetli. Stanie się tak dlatego, że przeglądarki nie pokazują zawartości tagów <body> dopóki nie mają wszystkiego z sekcji <head>.

Wyjściem z tej sytuacji może być hostowanie ga.js na Twoim własnym serwerze, razem z resztą plików wchodzących w skład witryny. Aby wprowadzić to rozwiązanie w życie, należy wykonać następujące kroki:

  1. Skopiować plik ga.js i umieścić go w gdzieś w ramach witryny, np. w lokacji www.mojadomena.pl/js/ga.js
  2. Ustawić automatyczną aktualizację pliku ga.js. W systemach uniksowych można w tym celu wykorzystać usługę cron.
  3. Dokonać modyfikacji kodu tagującego strony – ale tylko tego fragmentu, gdzie deklarowany jest plik ga.js.

Modyfikacja polega na uaktualnieniu ścieżki do ga.js:

Oryginał:

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>

Po zmianach:

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "mojadomena.pl/js/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>

Tu często webmasterzy popełniają błąd – zapominają o zmiennej gaJsHost. Jej wartość jest zawsze dodawana do lokalizacji. Zależy natomiast od protokołu, w którym odwiedzający przegląda witrynę.

Przykład: Jeśli plik jest dostępny z adresu http://www.mojadomena.pl/js/ga.js to powyższa modyfikacja będzie działać. Ale jeśli witryna ma strony dostępne przez https, to skrypt będzie próbował deklarować plik z adresu https://ssl.mojadomena.pl/js/ga.js – z dużą dozą pewności można powiedzieć, że taki adres nie będzie działać na Twojej witrynie. Raporty w Analytics będą więc niepełne, bo skrypt zadziała tylko dla stron przeglądanych przez http.

Czasem webmasterzy wpisują pełną ścieżkę do pliku:

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "www.mojadomena.pl/ga.js' type='text/javascript'%3E%3C/script%3E"));</script>

Wtedy śledzenie nie będzie działać już w ogóle: dla http skrypt dołączy plik http://www.www.mojadomena.pl/ga.js, a dla https https://sssl.www.mojadomena.pl/ga.js. Warto więc dwa razy sprawdzić co się modyfikuje :). Dużą pomocą jest Firebug, który ładnie raportuje błędy JS.

Podsumowując proces hostowania pliku ga.js lokalnie – mamy trzy kroki, które należy wykonać. Nic więcej nie robimy. Są spece, którzy radzą lokalne hostowanie także dla pliku __utm.gif i modyfikację jego lokacji wewnątrz ga.js. Oczywiście jest to bzdurna porada – taka modyfikacja powoduje przekazywanie danych nie do Analytics ale do logów lokalnego serwera. Skrypt Analytics wywołuje wtedy za każdym razem plik http://www.mojadomena.pl/__utm.gif :).

Śledzenie jednej witryny przez dwa konta Google Analytics

Czasem uzasadnione jest śledzenie witryny przez dwa konta. Wtedy również wymagana jest modyfikacja kodu. Nie można zrobić tego po prostu łącząc kody z obu kont:

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));</script>
<script type="text/javascript">
try {var pageTracker = _gat._getTracker("UA-123123-1");

pageTracker._trackPageview();} catch(err) {}</script>
<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));</script>
<script type="text/javascript">
try {var pageTracker = _gat._getTracker("UA-234234-1");

pageTracker._trackPageview();} catch(err) {}</script>

Powyższe nie zadziała. Poprawna implementacja wygląda mniej więcej tak:

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
try {var pierwszyTracker = _gat._getTracker("UA-123456-1");
pierwszyTracker._trackPageview();
var drugiTracker = _gat._getTracker("UA-234234-1");
drugiTracker._trackPageview();
} catch(err) {}</script>

Czyli polega na tworzeniu osobnej instancji obiektu trackera dla każdego z kont.

Zapraszam do dzielenia się własnymi doświadczeniami w komentarzach. Postaram się także odpowiedzieć na każde pytanie :).

Posty o Analytics:

Komentarzy 8

  1. Przeniesieniu kodu na swoją witrynę ma duży sens w szczególnie dużych witrynach. W mniejszych nie ma to szczególnie wielkiego znaczenia. Zwłaszcza, że ten skrypt jest niejako cachowany po stronie przeglądarki.
    Faktem jest, że deveoperzy często popełniają opisywane przez Ciebie błędy w czasie przenoszenia skryptu.
    Przekonałeś się do Google Analytics :)?

  2. O, a wyglądało, że jestem uprzedzony? To nie tak. GA ma swoje zalety i wady. Wady są wprost proporcjonalne do wielkości biznesu – im większa firma, tym bardziej przeszkadza np. brak prywatności. Dlatego moim zdaniem duże przedsiębiorstwa robią błąd korzystając z Analytics.

    Z drugiej strony życie to sztuka kompromisów. Często implementacja czegokolwiek innego niż Analytics jest prawie niemożliwa. Wtedy odpowiedź na pytanie mieć GA czy nie mieć info o witrynie w ogóle jest oczywista.

    Ogólnie to ciekawy materiał na panel dyskusyjny i pomysł np. dla Ciebie na SEMCamp.

  3. Uprzedzony to za duże słowo. Nieufny :)

    Często implementacja czegokolwiek innego niż Analytics jest prawie niemożliwa

    Istnieje wiele innych bardzo dobrych programów analitycznych, które wcale nie są takie drogie dla dużej firmy (np. ClickTracks, dawne IndexTools – teraz chwilowo wstrzymane, Urchin). W niektórych przypadkach mogą się sprawdzać nawet lepiej niż Google Analytics, który jak każde rozwiązanie analityczne nie będzie pasował do potrzeb każdej witryny. Problemem jest wówczas na pewno support, a raczej jego brak, jako, że osób, które znają się na tych narzędziach jest dużo mniej niż tych znających się na Google Analytics.

    Ogólnie to ciekawy materiał na panel dyskusyjny i pomysł np. dla Ciebie na SEMCamp.

    Kto według Ciebie mógłby wziąć udział w takim panelu? Nie jest łatwo stworzyć panel dyskusyjny, który wnosi coś do tematu :(. Zecydowna większość mieści się jednym z 3 segmentów: „nawalanka”, „kółko wzajemnej adoracji” i „technika zdartej płyty”.

  4. Jeśli nieufny, to taki jestem w stosunku do Analytics (i nie tylko) cały czas.

    Urchin to jakieś 12000 zł. Clicktracks Optimizer 3500 zł, a Clicktracks Pro 18200 zł. Kupując licencję dostaje się support, tyle że techniczny. Masz rację – bez znajomości oprogramowania w danej firmie sam support na niewiele się zda, a rodzimy rynek usługodawców SEM niespecjalnie jest zainteresowany alternatywami to GA.

    Kto w panelu? Mój dream team poskładałbym z zachodnich speców. W Polsce znakomita większość przedstawicieli mainstreamowych firm SEM charakteryzuje się dwiema cechami:
    a) nie potrafią przeprowadzić w pełni merytorycznego wystąpienia bez marketingowego kitu
    b) nie mają odwagi powiedzieć coś niedobrego o Google
    Nic dziwnego więc, że wychodzą kółka adoracji.

  5. Kasia Bauer pisze:

    ClickTracks support ma, ale nie we wszystkim Ci pomoże. Wymaga on też większej znajomości tematu. Ponieważ działa on w oparciu o logi serwera HTTP może generować problemy przy prostych zmianach. Z reguły logi dużych serwisów są bardzo „okrojone” ze względu na ich wagę. Dalej: same zmiany które chcemy zaimplementować w logach może być problematyczne jeżeli nie ma się do tego kompetentnej osoby. Jeżeli korzystamy z usług hostingowych napotkamy a kolejne problemy jak „nie mamy tego w naszych usługach”, „przecież mają Państwo dostęp do statystyk” itp.

    Stąd stwierdzenie Mariusza zyskuję jeszcze większą wagę:

    (…) każde rozwiązanie analityczne nie będzie pasowało do potrzeb każdej witryny.

    Uważam, że zawsze jest dobry moment, aby zastanowić się nad zmianą. Podejmowana decyzja nie tylko powinna obejmować kwestie potrzeb, ale także typu „czy mamy osobę która jest w stanie z tym nam z pomóc?”.

  6. Robert Drózd pisze:

    Zdrowa praktyka korzystania z GA powinna obejmować to, że ważne statystyki jesteśmy w stanie zweryfikować inną metodą. Mi np. do sprawdzenia przejść ze strony na stronę często bardziej przydaje się Gemius Heatmap czy (jeśli go brak) inny program do clicktrackingu.

    Analytics potrafi mieć swoje wpadki (jak np. niezbieranie statystyk przez pół dnia, „bo tak”), no i sporo statystyk podaje „przybliżone” (ale najczęściej przed tym ostrzega), więc trzeba ostrożnie ze ślepą wiarą. :)

  7. Pawel pisze:

    Witam,
    Mam pytanko dotyczące umieszczenia pliku ga.js na swoim serwerze. Pisze żeby ustawić automatyczną aktualizację pliku. Jak to zrobić ?? Czy jest to wymagane ? Jak często jest ten plik aktualizowany przez Google ??

    Pozdrawiam,
    Paweł

  8. @Paweł
    Witaj. Ustawienie aktualizacji zależy od systemu, pod kontrolą którego działa Twoja witryna. We wpisie wspominam o cronie – jest to standardowy element systemów uniksowych. Jeśli serwer hostujący Twoją witrynę działa w oparciu o Linuksa – cron Ci pomoże. Jeśli masz serwer wirtualny, to polecam sprawdzenie czy aby nie masz opcji crona wyprowadzonej do panelu sterowania u Twojego dostawcy hostingu.

    Jeśli napotkasz na jakiekolwiek trudności możesz także zatelefonować do swojego hostingera – jeśli jesteś ich płacącym klientem to należy Ci się wsparcie techniczne :).

Dodaj Komentarz

XHTML: Możesz użyć następujących tagów: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>