Jeden ze sposobów śledzenia adresów URL po hashu (#).

Jeden ze sposobów śledzenia adresów URL po hashu (#).
Oceń artykuł!

Standardowo, tzn. bez dodatkowych konfiguracji i zmian kodowych, Google Analytics nie śledzi tego co w adresach URL znajduje się po hashu (#). Innymi słowy GA ma problemy ze śledzeniem dynamicznie zmieniającej się treści strony. Dla zobrazowania podstrona o adresie www.domena.pl będzie odbierana w widoku konta Google Analytics bez filtrów jako Strona Główna „/”. Podstrony o adresach:

www.domena.pl/#podstrona1
www.domena.pl/#podstrona2

także będą w GA odbierane jako „/”, co mocno zaburza ważne statystyki. Do rozwiązania tego problemu należy podejść różnie w zależności od implementacji kodowej. Dla GATC (Google Analytics Tracking Code) umieszczanego standardowo w kodzie strony znajdujemy już setki porad w Internecie. Dla nowszych rozwiązań typu implementacja Google Analytics z poziomu Google Tag Managera jest ich już znacznie mniej, dlatego zaprezentujemy niżej jedno z nich. Jego zaletą jest niewątpliwa prostota, ponieważ nie wymaga implementacji żadnych dodatkowych niestandardowych tagów html czy javascript.

Mogliście się już spotkać z dedykowanym do tego typu problemów odbiornikiem historii. Czym on jest? Krótko mówiąc, zadaniem odbiornika historii jest wykrywanie zmian w URL, które dzieją się w związku z # w adresie i przekazywanie ich odpowiednio w wartościach zmiennych newUrlfragment (przyjmuje wartości na jakie zmienił się fragment URL po #) oraz oldUrlfragment (przyjmuje wartości z jakich zmienił się fragment URL po #). Nie szukalibyśmy jednak udoskonaleń, gdyby użycie samego odbiornika zawsze było wystarczające.

Mieliśmy do czynienia z trzema przypadkami:

1. Odbiornik nie rejestrował pojawiania się pierwszego adresu z hashem, a dopiero każdą kolejną zmianę. Jaśniej mówiąc przejście z www.domena.pl/ na www.domena.pl/#podstrona1 nie było rejestrowane przez odbiornik. Dopiero przejście z www.domena.pl/#podstrona1 na www.domena.pl/#podstrona2 było.

2. Przeładowanie podstrony www.domena.pl/#podstrona także nie było zarejestrowane przez odbiornik.

3. Strony zmieniały się dynamicznie, jednak fizycznie # w adresie nie było tego widać. Odbiornik działał, ale żadne zmiany nie były przekazywane do zmiennych newUrlfragment oraz oldUrlfragment.

Rozwiązaniem powyższych przypadków jest stworzenie nowego makra {{URL fragment}} i wykorzystanie go w odpowiedniej kombinacji dwóch tagów.

Pierwszym tagiem będzie implementacja odbiornika historii. W Google Tag Manager wybieramy odpowiedni tag i ustawiamy regułę dla wszystkich stron (opcjonalnie dla stron odpowiedniej domeny).

Następny tag będzie służył rejestracji wszystkich odsłon. Makro {{id GA}} to oczywiście numer usługi jednoznacznie identyfikujący, gdzie do Google Analytics mają wpadać dane. Ważną czynnością jest dokonanie zmian w sekcji Więcej ustawień -> Podstawowa konfiguracja, gdzie w polu Ścieżka dokumentu należy wpisać w zależności od struktury URLi serwisu {{url path}}/{{url fragment}} lub {{url}}/{{url fragment}}.

W ścieżce pierwsze makro {{URL}} lub {{URL path}} będzie zawsze odpowiadało za adres URL poprzedzający hash. Definicje można znaleźć w samym interfejsie Google Tag Managera, jak pokazano na zrzutach niżej.

{{URL}}

{{URL path}}

Drugie makro w ścieżce do dokumentu {{URL fragment}} (screen poniżej) odpowiada za przekazywanie wartości po hashu i tym samym rozwiązuje problem nr 3, ponieważ nie wykorzystuje zmiennych newUrlfragment oraz oldUrlfragment.

Ważne, by odpowiednio zdefiniować także reguły mówiące o tym, w jakich warunkach ten tag powinien zadziałać. Na jednym z powyższych zrzutów te reguły zaznaczone są numerami 1 i 2. Pierwsza będzie uruchamiała tag dla zmian bez przeładowań strony. Opiera się ona na działaniu wcześniej zaimplementowanego odbiornika historii.

Reguła z numerem 2 to reguła ‘All pages’. Wysyła ona hity odsłon dla każdej strony z przeładowaniem i jest defaultowa. Używaliśmy jej już wcześniej. Jednak teraz adresy podstron wysyłane do GA będą już zawierały także fragment adresu z hashem. W ten sposób rozwiązaliśmy problem 1 i 2.

Dobrnęliśmy właśnie do końca implementacji śledzenia podstron po hashu. Proste rozwiązanie wielu problemów. 🙂

Redaktor