Jak sprawdzić dokładność danych analitycznych witryny

Jak sprawdzić, czy dane analityczne witryny są dokładne

Raporty analityczne mogą wyglądać na precyzyjne, a mimo to zliczać niewłaściwe zdarzenia. Wyświetlenie strony może zostać zarejestrowane dwukrotnie, wysłanie formularza może nie zostać odnotowane, a zamówienie może być przypisane do niewłaściwego źródła. Nie chodzi o to, by każdy raport dokładnie zgadzał się z każdym innym systemem, lecz o to, czy dane odzwierciedlają działania, które ma rejestrować skonfigurowany pomiar. Ukierunkowany audyt kilku zdarzeń może pokazać, gdzie wyniki zaczynają się różnić.

Jeśli zastanawiasz się, jak sprawdzić dokładność danych analitycznych i poprawność pomiaru, zacznij od powtarzalnego testu, a nie od ogólnego przeglądu wszystkich paneli. Wybierz niewielką próbkę, prześledź każde zdarzenie na kolejnych etapach zbierania danych i porównaj wyniki z systemem, który rejestruje samo działanie. Zapisuj warunki testu, bo wyniki w przeglądarce, w której zalogowano się do serwisu, mogą różnić się od tych w nowej sesji.

1. Wybierz niewielką grupę zdarzeń do audytu

Wybierz dwa lub trzy zdarzenia istotne z punktu widzenia witryny. W przypadku firmy usługowej mogą to być wyświetlenie strony, wysłanie formularza kontaktowego i kliknięcie numeru telefonu. W sklepie internetowym wybierz wyświetlenie produktu, dodanie go do koszyka i sfinalizowanie zakupu. Krótka lista ułatwia przeprowadzenie audytu i dokładne sprawdzenie każdego zdarzenia.

Przy każdym zdarzeniu zapisz, co powinno je wywołać i jakie dowody potwierdzą, że do niego doszło. Pomyślne wysłanie formularza może wymagać wyświetlenia komunikatu potwierdzającego i pojawienia się nowego wpisu w skrzynce formularza; zakup — złożenia zamówienia w systemie sprzedażowym. Nie uznawaj kliknięcia przycisku za zakup, jeśli płatność może się jeszcze nie powieść.

• Wyświetlenie strony: jedno załadowanie strony powinno wygenerować jedno zdarzenie wyświetlenia strony.
• Wysłanie formularza: poprawnie wysłany formularz powinien wygenerować jedno zdarzenie i jeden zapis odpowiedzi.
• Zakup: sfinalizowane zamówienie powinno mieć identyfikator transakcji i zarejestrowaną wartość.

Uwzględnij też oczekiwane warunki. Jeśli zdarzenie związane z formularzem ma być wywoływane dopiero po pomyślnej walidacji, nieudana próba nie powinna być zliczana. To ważne, gdy ktoś kliknie „Wyślij”, nie wypełniając wymaganego pola: przycisk został kliknięty, ale formularz nie został wysłany.

2. Prześledź każde zdarzenie od działania do raportu

Aby sprawdzić, jak audytować śledzenie zdarzeń na stronie, prześledź pojedynczą testową akcję przez wszystkie etapy jej obsługi: warstwę danych lub kod śledzący witryny, wysyłane żądanie, system zbierania danych analitycznych, a na końcu raport. Narzędzia deweloperskie przeglądarki pokażą, czy żądanie zostało wysłane i jaką nazwę zdarzenia lub jakie parametry zawierało. Jeśli żądanie się nie pojawia, problem prawdopodobnie leży po stronie witryny lub przeglądarki; jeśli jest widoczne, ale brakuje go w raporcie, sprawdź ustawienia przetwarzania i raportowania.

Na przykład wyślij testowy formularz i zanotuj nazwę zdarzenia, adres URL strony oraz godzinę. Sprawdź, czy żądanie analityczne zawiera właściwe zdarzenie, a następnie poszukaj go w widoku czasu rzeczywistego lub debugowania platformy, zanim zajrzysz do standardowego raportu. Przetworzenie danych może zająć trochę czasu, więc pusty raport kilka sekund po teście nie dowodzi sam w sobie, że śledzenie nie działa. Zanim uznasz tę różnicę za błąd, sprawdź, z jakim opóźnieniem platforma aktualizuje raporty.

Zachowaj tę samą nazwę zdarzenia na każdym etapie. Witryna może wysyłać zdarzenie form_success, podczas gdy raport jest skonfigurowany tak, by wyświetlać generate_lead. Obie nazwy mogą być sensowne, ale musi je łączyć mapowanie lub reguła raportowania. Zespołom zarządzającym kilkoma usługami może pomóc narzędzie do monitorowania, takie jak platforma do analityki i monitorowania witryn, ale nie zastąpi ono sprawdzenia samego zdarzenia.

3. Przeprowadzaj kontrolowane testy w nowej sesji przeglądarki

Jeśli to możliwe, użyj nowego profilu przeglądarki lub okna prywatnego z wyłączonymi rozszerzeniami. Ograniczy to wpływ zapisanych plików cookie, wcześniejszych wizyt i dodatków do przeglądarki. Zapisz dokładne kroki i godzinę: otwórz stronę docelową o 10:04, wyświetl jeden produkt, dodaj go do koszyka i zakończ test. Znaczniki czasu ułatwiają powiązanie aktywności w przeglądarce z żądaniami analitycznymi i zapisami na serwerze.

Ogranicz zakres testu. Nie otwieraj kilku kart, nie odświeżaj wielokrotnie strony i nie klikaj innych elementów, gdy sprawdzasz zdarzenie. Takie działania mogą wygenerować dodatkowe wyświetlenia strony i sprawić, że prawidłowa konfiguracja będzie wyglądać na zdublowaną. Jeśli chcesz przetestować powracającego użytkownika, przeprowadź osobny test i wyraźnie go oznacz.

Jeśli witryna daje taką możliwość, wykonaj jeden test po wyrażeniu zgody na analitykę, a drugi po jej odrzuceniu. Zapisz, co się zmieniło. Brak zdarzenia analitycznego po odrzuceniu zgody może być zamierzony, natomiast brak zdarzenia po jej zaakceptowaniu może wskazywać na problem z konfiguracją. Wynik ma sens tylko wtedy, gdy w dokumentacji testu uwzględniono stan zgody.

4. Porównaj dane analityczne z niezależnym źródłem

Porównaj niewielką próbkę z innym systemem, który rejestruje samo działanie. W przypadku wysłanych formularzy skorzystaj ze skrzynki odbiorczej lub bazy danych formularza. Zamówienia sprawdź wśród sfinalizowanych transakcji w systemie sprzedażowym. Logi serwera mogą pomóc potwierdzić, że zażądano strony lub punktu końcowego, ale sam wpis w logu nie zawsze oznacza, że ktoś zobaczył stronę lub wykonał daną czynność.

Wybierz konkretny przedział czasu i niewielką liczbę rekordów testowych. Jeśli to możliwe, dopasuj je na podstawie godziny, identyfikatora zamówienia lub innego wspólnego identyfikatora. Nie porównuj ogólnych sum z różnych zakresów dat: strefy czasowe, opóźnienia w przetwarzaniu, filtry i zasady przechowywania danych mogą zmieniać wyniki. Jeśli analityka wykazuje 12 zakupów, a system zamówień — 12 sfinalizowanych zamówień w tym samym przedziale testowym, to cenna wskazówka, ale nadal sprawdź, czy zgadzają się poszczególne identyfikatory transakcji.

Załóż, że pewne różnice są możliwe, ponieważ systemy rejestrują różne rzeczy. Log serwera może obejmować automatyczne żądania i ponowne ładowanie stron, a platforma analityczna może pomijać wizyty, podczas których śledzenie zostało zablokowane lub użytkownik nie wyraził zgody. Więcej o jednym ze źródeł zawyżonych wyników przeczytasz w artykule Dlaczego dane analityczne witryny są zawyżone?. Porównanie powinno wyjaśnić rozbieżność, a nie zakładać, że jeden system zawsze ma rację.

5. Sprawdź, czy zdarzenia nie są duplikowane lub pomijane

Powtórz tę samą czynność kilka razy, ale każdą próbę przeprowadź osobno. Wyślij testowy formularz raz, poczekaj na potwierdzenie, a potem sprawdź, czy utworzono jedno zdarzenie i jeden wpis. Jeśli zdarzenie pojawi się dwukrotnie, sprawdź, czy jest wywoływane zarówno kliknięciem przycisku, jak i wyświetleniem strony potwierdzenia albo czy nie wysyła się ponownie po odświeżeniu strony.

Przerwane ścieżki użytkownika ujawniają inny rodzaj błędu. Rozpocznij proces płatności, przerwij go przed zapłatą i upewnij się, że nie pojawiło się zdarzenie sfinalizowanego zakupu. Następnie sfinalizuj testowe zamówienie i sprawdź, czy zdarzenie uruchomiło się raz oraz zawiera prawidłowy identyfikator transakcji. Zdarzenie zakupu wywoływane kliknięciem „Złóż zamówienie” może zawyżać wyniki, gdy płatność się nie powiedzie lub klient wróci na stronę.

Trudniej zauważyć brakujące zdarzenia niż duplikaty. Przetestuj błędy walidacji, wolne połączenie i powrót do strony za pomocą przycisku Wstecz, jeśli takie sytuacje zdarzają się w witrynie. Formularz może pomyślnie zapisać odpowiedź, nawet jeśli skrypt nie zdoła wysłać zdarzenia analitycznego. To problem ze śledzeniem, a nie brak potencjalnego klienta.

6. Sprawdź wpływ zgody, blokowania i przejść między domenami

Przeprowadzaj testy w warunkach, w jakich korzystają z witryny prawdziwi użytkownicy: po wyrażeniu i odmowie zgody, w przeglądarce z włączoną ochroną prywatności oraz — jeśli ma to znaczenie — z blokerem reklam. Przy każdej próbie zapisz przeglądarkę i wybór dotyczący zgody. Zablokowane żądanie może w ogóle nie dotrzeć do systemu analitycznego, mimo że strona lub formularz działa poprawnie. Dlatego nie zawsze da się uzyskać dokładną zgodność jeden do jednego z zapisami po stronie serwera.

Podróże między domenami wymagają osobnego sprawdzenia. Jeśli klient przechodzi ze sklepu do operatora płatności, a potem wraca, upewnij się, że konfiguracja analityki prawidłowo obsługuje to przejście i że strona powrotna nie rozpoczyna nowej, niezwiązanej sesji. Przetestuj jedną sfinalizowaną transakcję i sprawdź domenę odsyłającą, szczegóły sesji oraz identyfikator transakcji. Jeśli przekierowanie nie jest poprawnie skonfigurowane, operator płatności może pojawić się jako źródło odesłania.

Zasady dotyczące zgody i mechanizmy ochrony prywatności w przeglądarkach mogą również zmieniać zakres dostępnych informacji. Nie traktuj niższej liczby w analityce jako dowodu, że witryna utraciła taką samą liczbę transakcji. Najpierw ustal, jakie działania każdy system może i ma rejestrować. Informacje o zmianach w przeglądarkach znajdziesz w artykule jak włączyć pliki cookie stron trzecich.

7. Dokumentuj wyniki i powtarzaj testy po wprowadzeniu zmian

Prowadź krótką dokumentację audytu, zapisując datę, przeglądarkę, wybór dotyczący zgody, wykonane kroki, oczekiwane zdarzenie, zaobserwowane zdarzenie i wszelkie pasujące identyfikatory rekordów. Zaznacz, czy wynik pochodził z raportu na żywo, widoku debugowania czy systemu zaplecza. Dzięki temu członek zespołu nie uzna chwilowego opóźnienia w przetwarzaniu za potwierdzony błąd śledzenia.

Po naprawie powtórz ten sam test w identycznych warunkach. Jeśli wcześniej zdarzenie było wysyłane dwukrotnie, sprawdź, czy po poprawce wysyła się raz i czy formularz nadal tworzy swój wpis. Ponawiaj testy po większych zmianach w witrynie, takich jak przebudowa formularza lub aktualizacja procesu płatności, ponieważ mogą one zmienić sposób wywoływania zdarzeń, nawet jeśli sam panel analityczny pozostał bez zmian.

Jeśli chcesz ustalić, jak sprawdzić poprawność analityki witryny całościowo, połącz te kroki: sprawdź wybrane zdarzenia, prześledź ich wysyłanie, porównaj je z niezależnymi zapisami i powtórz test po każdej istotnej zmianie.