W jaki sposób kolidujesz z kodem Google Analytics?

Question

Czy każdy może udostępniać sprawdzone metody rozwiązywania problemów z kodem anlytics w serwisie google?

Czy ktoś zbudował narzędzie do debugowania? Czy Google ma jakiś ukryty skrytka? Czy ktokolwiek ma dobry diagram logiki triage?

Będę okresowo konfigurował różne części GA i wydaje się, że za każdym razem, gdy to robię, potrzeba 4 lub 5 dni, aby działało.

Workflow wygląda następująco:

Read the docs on the feature (e.g. events, custom variables). 
Implement what appears to be the correct code based on the docs. 
Wait a day. 
See no data. 
Google every version of the problem I can imagine. Find what may be a solution. 
Change my code. 
Wait a day. 
See no data. 
Loop: 
    Randomly move elements of the tracking code around. 
    Wait a day. 
    If other parts break, tell ceo, get yelled at, revert changes. 
    If data appears, break. 
Pray it continues to work/I never have to change the tracking code again. 

Z oczywistych powodów, nie jestem zadowolony z tego obiegu i nadzieją, ktoś zorientowali się coś, czego nie ma.

Answer 1

Wszystko, co robię, debugowanie kodu GA, zatrzymuje się i zaczyna się od Google Analytics Debugger Chrome Extension. Wydrukuje do konsoli podsumowanie danych przesłanych do Google Analytics, które są wszystkim, czego potrzebujesz, z wyjątkiem filtrów profilu testowego. To wyeliminuje krok "czekaj jeden dzień".

Jeśli nie jesteś fanem Google Chrome, możesz samodzielnie sprawdzić żądania HTTP, aby zobaczyć, jak dane są analizowane. Możesz użyć this guide, aby dowiedzieć się, co reprezentuje każdy z parametrów w adresie URL.

Jeśli chodzi o zapewnienie zainstalowanych funkcji lub sam kod, otworzę nową przeglądarkę (wyczyszczoną z plików cookie) i przejdę do strony testowanej przez wyszukiwarkę Google. Przejdę do wszystkich istotnych stron i wyzwolę wszystkie istotne zdarzenia, zapewniając jednocześnie, że żądania są wysyłane do Google, i że sesja nie jest przerwana w żadnym momencie (przez utrzymywanie oka na liczba sesji, lub zapewnienie, że źródłem ruchu nie zmienia się od organiczny/google do kierowania lub self-skierowanie

ekranu.

Answer 2

yahelc odpowiedź brzmi świetnie, ale jestem Chciałbym dodać tutaj moje 2c:

Zdobądź sobie ładny sniffer, aby zobaczyć przepływające hity.Nicea opcje:

• Wasp
• Charles
• HTTPFox
• Fiddler

następnie wdrożyć zmiany dotyczące QA.

Sprawdź tę nową konfigurację w QA. Rzeczy, które powinieneś mieć na oku.

• Zawsze należy się upewnić, że podstawowy odsłon strony zostanie wywołany. Powinien mieć wartość co najmniej utmp i nie być ustawiona.
• Upewnij się, że identyfikator gościa nie zostanie nadpisany. To jest drugi numer na ciasteczku __utma. Ten numer powinien być Twoim identyfikatorem użytkownika, jeśli się zmieni, to wszystko zostanie zepsute.
• Upewnij się, że odsłony zawierają ustawione przez ciebie zmienne strony i sesji. Jeśli ustawisz dowolne.Są one zakodowane w parametrze utme.
• Upewnij się, że niestandardowy var użytkownika jest uruchamiany przed podstawową odsłoną strony. utmt=custom variable
• Upewnij się, że dane źródłowe nie są nadpisane (Kampania/medium/źródło/treść/słowo kluczowe) - Są one ustawiane w pliku cookie __utmz. Jeśli zostanie nadpisany przez bezpośrednie lub odesłanie do Twojej witryny, coś jest nie tak.
• Jeśli przegapisz jakiekolwiek zdarzenie, może to być spowodowane brakiem wymaganego pola lub ostatnią wartością będącą spławem lub ciągiem znaków. Wartość zdarzenia musi być liczbą całkowitą.
• Jeśli korzystasz z ekomeru, sprawdź dokładnie wszystkie parametry. Upewnij się, że wypalasz wszystko jako ciągi tutaj i że nieużywane parametry są pustymi ciągami.
• potrójne sprawdzenie numeru konta. UA-XXXXX-X.
• Jeśli robisz coś z niestandardowym JS, upewnij się, że testujesz we wszystkich przeglądarkach i staraj się uzyskać co najmniej podstawowe śledzenie w bezpiecznej strefie, w której masz pewność, że rzeczy się nie zepsują.
• Wysyła informacje dotyczące debugowania dotyczące kodu javascript, który może przerwać działanie GA na GA. Check this.

Answer 3

Na początek ta odpowiedź nie kłóci się z żadną częścią żadnej z dwóch odpowiedzi przed moją - tj. z pewnością można je wszystkie wdrożyć bez konfliktów.

Moja odpowiedź odzwierciedla jedynie mój własny priorytet, czyli problem z opóźnieniem. Opóźnienie powoduje, że debugowanie jest znacznie trudniejsze niż powinno być. Dziesięć minut opóźnienia w oczekiwaniu na zakończenie kompilatora jest irytujące, cztery godziny (minimalne opóźnienie GA) są bolesne.

Więc dla mnie, pierwszym krokiem w budowaniu de-podsłuch ram GA było jakoś uzyskać wyniki GA w czasie rzeczywistym --W Innymi słowy, jeśli zmieniłem filtr wyrażenie regularne, potrzebowałem aby przechwycić ruch przetwarzany przez ten filtr. Dlatego usunięcie 4-24-godzinnego opóźnienia w uzyskaniu wyników z serwera GA było krytyczne.

Najprostszym sposobem znalazłem tak daleko, aby to zrobić, aby zmodyfikować kod śledzenia GA na każdej stronie witryny, tak aby przesyła kopię każdego żądania GIF na własnym serwerze.

Aby to zrobić, zaraz przed wywołaniem trackPageview(), dodaj linię:

pageTracker._setLocalRemoteServerMode(); 

Ten wyśle ​​całą nagłówka prośby do serwera dostępu dzienniku, który można przetworzyć w czas rzeczywisty. (W szczególności twój serwer zapisuje do dziennika dostępu po jednej linii na raz - jedna linia odpowiada jednemu żądaniu.Wszystkie dane GA są spakowane i ustawione jako nagłówek żądania, więc istnieje idealna koincydencja między tymi dwoma.