Jak monitorować jakość danych — szczegółowy przewodnik

Łatwiej jest zapobiegać błędom w gromadzeniu danych niż radzić sobie z ich konsekwencjami. Rozsądek podejmowanych przez Ciebie decyzji biznesowych zależy od jakości Twoich danych. W tym artykule podpowiemy, jak sprawdzić jakość danych na wszystkich etapach ich zbierania, od zestawienia prac po wypełnione raporty.

Niestety, wiele firm, które wydają znaczne środki na przechowywanie i przetwarzanie danych, nadal podejmuje ważne decyzje, kierując się intuicją i własnymi oczekiwaniami, a nie danymi.

Dlaczego tak się dzieje? Nieufność do danych potęgują sytuacje, w których dane dostarczają odpowiedzi, która jest sprzeczna z oczekiwaniami decydenta. Ponadto, jeśli ktoś napotkał w przeszłości błędy w danych lub raportach, jest skłonny faworyzować intuicję. Jest to zrozumiałe, ponieważ decyzja podjęta na podstawie błędnych danych może Cię odrzucić, a nie popchnąć do przodu.

Wyobraź sobie, że masz projekt wielowalutowy. Twój analityk skonfigurował Google Analytics w jednej walucie, a marketer odpowiedzialny za reklamy kontekstowe skonfigurował import kosztów do Google Analytics w innej walucie. W rezultacie masz nierealistyczny zwrot z nakładów na reklamę (ROAS) w raportach kampanii reklamowych. Jeśli nie zauważysz tego błędu na czas, możesz wyłączyć dochodowe kampanie lub zwiększyć budżet na te przynoszące straty.

Ponadto programiści są zwykle bardzo zajęci, a wdrażanie analityki internetowej jest dla nich zadaniem drugorzędnym. Wdrażając nową funkcjonalność – na przykład nowy projekt jednostki z akcesoriami – programiści mogą zapomnieć o sprawdzeniu, czy dane są gromadzone w Google Analytics. W rezultacie, gdy przychodzi czas na ocenę skuteczności nowego projektu, okazuje się, że zbieranie danych zostało przerwane dwa tygodnie temu. Niespodzianka.

Wyobraź sobie, że popełniłeś błąd w fazie specyfikacji. Jeśli go znajdziesz i natychmiast poprawisz, poprawka będzie stosunkowo tania. Jeśli błąd zostanie ujawniony po wdrożeniu, przy budowaniu raportów, a nawet przy podejmowaniu decyzji, koszt jego naprawy będzie bardzo wysoki.

Zbieranie danych zazwyczaj składa się z pięciu kluczowych etapów:

1. Sformułuj wyzwanie biznesowe. Załóżmy, że musisz ocenić skuteczność algorytmu wyboru towarów w bloku rekomendacji.
2. Analityk lub osoba odpowiedzialna za zbieranie danych projektuje system metryk do śledzenia w serwisie.
3. Osoba konfiguruje Google Analytics i Google Tag Managera.
4. Ten wysyła warunki do wdrożenia dla programistów.
5. Gdy deweloper zaimplementuje metryki i skonfiguruje zbieranie danych, analityk pracuje z raportami.

Na prawie wszystkich tych etapach bardzo ważne jest sprawdzenie danych. Niezbędne jest przetestowanie dokumentacji technicznej, ustawień Google Analytics i Google Tag Managera oraz oczywiście jakości danych zbieranych w Twojej witrynie lub w Twojej aplikacji mobilnej.

Zanim przejdziesz do każdego kroku, przyjrzyjmy się niektórym wymaganiom dotyczącym testowania danych:

• Nie możesz testować bez narzędzi. Jako minimum będziesz musiał pracować z konsolą programisty w przeglądarce.
• Nie ma abstrakcyjnego oczekiwanego wyniku. Musisz dokładnie wiedzieć, z czym powinieneś skończyć. Zawsze mamy określony zestaw parametrów, które musimy zebrać w przypadku interakcji użytkownika z witryną. I znamy wartości, jakie te parametry powinny przyjąć.
• Niezbędna jest specjalna wiedza. Musisz przynajmniej zapoznać się z dokumentacją narzędzi do analityki internetowej, z których korzystasz, praktyką i doświadczeniem uczestników rynku.

Jak już wspomnieliśmy, znacznie łatwiej jest naprawić błąd, jeśli znajdziesz go w specyfikacji. Dlatego sprawdzanie dokumentacji zaczyna się na długo przed zebraniem danych. Zastanówmy się, dlaczego musimy sprawdzić Twoją dokumentację.

Cele dokumentacji testowej:

• Napraw błędy przy niewielkim wysiłku. Błąd w dokumentacji to po prostu błąd w tekście pisanym, więc wszystko, co musisz zrobić, to dokonać szybkiej edycji.
• Zapobiegaj potrzebie zmian w przyszłości, które mogą wpłynąć na architekturę witryny/aplikacji.
• Chroń reputację analityka. Instrument z błędami w opracowaniu mógłby kwestionować kompetencje osoby, która go sporządziła.

Najczęstsze błędy w specyfikacjach:

1. Literówki. Deweloper może skopiować nazwy parametrów bez ich czytania. Nie chodzi tu o błędy gramatyczne lub ortograficzne, ale raczej o nieprawidłowe nazwy parametrów lub wartości, które te parametry przechowują.
2. Ignorowanie pól podczas śledzenia zdarzeń. Na przykład komunikat o błędzie może zostać zignorowany, jeśli formularz nie został przesłany pomyślnie.
3. Nieprawidłowe nazwy pól i niezgodność ze schematem rozszerzonego e-commerce. Implementacja ulepszonego e-commerce za pomocą zmiennej dataLayer wymaga przejrzystej dokumentacji. Dlatego lepiej jest dwukrotnie sprawdzić wszystkie pola podczas tworzenia specyfikacji.
4. Nie masz obsługi walut dla witryny wielowalutowej. Ten problem dotyczy wszystkich raportów dotyczących przychodów.
5. Limity trafień nie są brane pod uwagę. Załóżmy na przykład, że na stronie katalogu może znajdować się do 30 różnych produktów. Jeśli przekazujemy informacje o wyświetleniach jednocześnie dla wszystkich produktów, prawdopodobnie trafienie w Google Analytics nie zostanie przeniesione.

Następnym krokiem po sprawdzeniu dokumentacji technicznej jest sprawdzenie ustawień Google Analytics i Menedżera tagów Google.

Po co testować ustawienia Google Analytics i Menedżera tagów Google?

• Upewnij się, że parametry są poprawnie przetwarzane przez systemy gromadzenia danych. Google Analytics i Google Tag Manager można skonfigurować równolegle z implementacją metryk w Twojej witrynie. A dopóki analityk nie skończy, dane nie pojawią się w Google Analytics.
• Ułatw testowanie metryk osadzonych w witrynie. Będziesz musiał skoncentrować się tylko na części pracy programisty. Na końcowym etapie X musisz szukać przyczyny błędu bezpośrednio w witrynie, a nie w ustawieniach platformy.
• Niski koszt naprawy, ponieważ nie ma potrzeby angażowania programistów.

Najczęstsze błędy w Google Analytics:

1. Nie utworzono zmiennej niestandardowej. Jest to szczególnie istotne w przypadku kont Google Analytics 360, które mogą mieć do 200 danych i 200 parametrów. W takim przypadku bardzo łatwo go przegapić.
2. Podany zakres dostępu jest nieprawidłowy. Nie będzie można wykryć tego błędu podczas fazy sprawdzania dataLayer ani sprawdzania wysyłanego działania, ale podczas tworzenia raportu zobaczysz, że dane nie wyglądają zgodnie z oczekiwaniami.
3. Otrzymasz duplikat istniejącego parametru. Ten błąd nie wpływa na przesyłane dane, ale może powodować problemy podczas sprawdzania i tworzenia raportów.

Najczęstsze błędy w Menedżerze tagów Google:

1. Nie dodano żadnych parametrów, takich jak tag Universal Analytics lub zmienna Ustawienia Google Analytics.
2. Indeks w tagu nie pasuje do parametru w Google Analytics, co stwarza ryzyko, że wartości zostaną przekazane do niewłaściwych parametrów. Załóżmy na przykład, że określiłeś indeks parametru liczby użytkowników w GTM dla parametru oceny przedmiotu. Ten błąd prawdopodobnie zostanie natychmiast wykryty podczas tworzenia raportów, ale nie będziesz już mieć wpływu na zebrane dane.
3. Nieprawidłowa nazwa zmiennej określona w dataLayer. Podczas tworzenia warstwy dataLayer należy określić, pod jaką nazwą zmienna zostanie znaleziona w tablicy dataLayer. Jeśli wpiszesz lub zapiszesz inną wartość, ta zmienna nigdy nie zostanie odczytana z dataLayer.
4. Śledzenie ulepszonego e-commerce nie jest włączone.
5. Wyzwalacz startu nie jest poprawnie skonfigurowany. Na przykład wyrażenie regularne wyzwalające X jest napisane niepoprawnie lub występuje błąd w nazwie zdarzenia.

Ostatnim etapem testowania jest testowanie bezpośrednio w serwisie. Ten etap wymaga większej wiedzy technicznej, ponieważ będziesz musiał obejrzeć kod, sprawdzić sposób instalacji kontenera i przeczytać logi. Musisz więc być sprytny i używać odpowiednich narzędzi.

Po co testować osadzone metryki?

• Sprawdź, czy wdrożone elementy są zgodne ze specyfikacjami i zanotuj wszelkie błędy.
• Sprawdź, czy wartości do wysłania są odpowiednie. Sprawdź, czy parametry przesyłają wartości do przesłania. Na przykład kategoria towarów nie przekazuje zamiast tego swojej nazwy.
• Przekaż deweloperom opinię na temat jakości wdrożenia. Na podstawie tych opinii programiści mogą wprowadzać zmiany w witrynie.

Najczęstsze błędy:

1. Nie wszystkie scenariusze są uwzględnione. Załóżmy na przykład, że element można dodać do koszyka w produkcie, katalogu, promocji lub na stronie wzorcowej — czyli w dowolnym miejscu, w którym znajduje się łącze do elementu. Przy tak wielu punktach wejścia możesz coś przegapić.
2. Zadanie nie jest zaimplementowane na wszystkich stronach. Oznacza to, że w przypadku niektórych stron lub niektórych partycji/katalogów dane nie są gromadzone w ogóle lub są gromadzone tylko częściowo. Aby zapobiec takim sytuacjom, możemy sporządzić listę kontrolną. W niektórych przypadkach możemy mieć nawet 100 sprawdzeń dla jednej funkcji.
3. Nie wszystkie parametry są zaimplementowane; oznacza to, że dataLayer jest zaimplementowana tylko częściowo.
4. Schemat dataLayer dla ulepszonego e-commerce jest uszkodzony. Dotyczy to zwłaszcza wydarzeń, takich jak dodawanie produktów do koszyka, przechodzenie między etapami kasy i klikanie produktów. Jednym z najczęstszych błędów we wdrażaniu ulepszonego e-commerce jest brak nawiasów kwadratowych w tablicy Produkty .
5. DataLayer używa pustego ciągu zamiast wartości null lub undefined do zerowania parametru. W takim przypadku raporty Google Analytics zawierają puste wiersze. Jeśli użyjesz wartości null lub undefined, ta opcja nie zostanie nawet uwzględniona w wysyłanym działaniu.

Narzędzia, których używamy do testowania danych:

• Rozszerzenie Google Analytics Debugger do przeglądarki Chrome
• GTM Debugger, za pomocą którego możesz włączyć tryb podglądu w Google Tag Manager
• Polecenie dataLayer w konsoli programisty
• Karta Sieć w konsoli programisty
• Rozszerzenie Google Tag Assistant do przeglądarki Chrome

Przyjrzyjmy się bliżej tym narzędziom.

Aby rozpocząć, musisz zainstalować to rozszerzenie w przeglądarce i włączyć je. Następnie otwórz identyfikator strony i przejdź do zakładki Konsola. Informacje, które widzisz, są dostarczane przez rozszerzenie.

Ten ekran pokazuje parametry, które są przesyłane z trafieniami oraz wartości, które są przesyłane dla tych parametrów:

Jest też rozbudowany blok e-commerce. Możesz go znaleźć w konsoli jako ec :

Ponadto wyświetlane są tutaj komunikaty o błędach, takie jak przekroczenie limitu rozmiaru trafień.

Jeśli chcesz sprawdzić skład dataLayer, najłatwiej to zrobić, wpisując w konsoli komendę dataLayer :

Oto wszystkie przesyłane parametry. Możesz je szczegółowo przestudiować i zweryfikować. Każda akcja w witrynie jest odzwierciedlona w dataLayer. Powiedzmy, że masz siedem obiektów. Jeśli klikniesz puste pole i ponownie wywołasz polecenie dataLayer , w konsoli powinien pojawić się ósmy obiekt.

Aby uzyskać dostęp do debugera Menedżera tagów Google, otwórz konto Menedżera tagów Google i kliknij przycisk Podgląd :

Następnie otwórz swoją witrynę i odśwież stronę. W dolnym okienku powinien pojawić się panel, który pokazuje wszystkie tagi uruchomione na tej stronie.

Zdarzenia dodane do dataLayer są wyświetlane po lewej stronie. Klikając na nie, możesz sprawdzić skład dataLayer w czasie rzeczywistym.

Funkcje testowania przeglądarki mobilnej:

• Na smartfonach i tabletach strony mogą być uruchamiane w trybie adaptacyjnym lub może istnieć osobna wersja mobilna strony. Jeśli uruchomisz mobilną wersję witryny na komputerze, będzie się ona różnić od tej samej wersji na telefonie.
• Ogólnie rzecz biorąc, rozszerzeń nie można instalować w przeglądarkach mobilnych.
• Aby to zrekompensować, musisz włączyć tryb debugowania w tagu Universal Analytics lub w kodzie śledzenia Google Analytics w witrynie.

Funkcje testowania aplikacji mobilnych:

• Praca z kodem aplikacji wymaga większej wiedzy technicznej.
• Do przechwytywania trafień potrzebny będzie lokalny serwer proxy. Aby śledzić liczbę żądań wysyłanych przez urządzenie, możesz filtrować żądania według nazwy aplikacji lub hosta, do którego są wysyłane.
• Wszystkie trafienia są zbierane w formacie Measurement Protocol i wymagają dodatkowego przetwarzania. Po zebraniu i przefiltrowaniu trafień należy je skopiować i przeanalizować do parametrów. Możesz to zrobić za pomocą dowolnego wygodnego narzędzia: narzędzia Hit Builder, formuł w Arkuszach Google lub aplikacji JavaScript lub Python. Wszystko zależy od tego, co jest dla Ciebie wygodniejsze. Dodatkowo będziesz potrzebować znajomości parametrów protokołu pomiaru, aby zidentyfikować błędy w wysłanych działaniach.

1. Podłącz swoje urządzenie mobilne do laptopa przez USB.
2. Otwórz Google Chrome na swoim urządzeniu.
3. W konsoli programisty Chrome otwórz raport Urządzenia zdalne:

1. Potwierdź połączenie z urządzeniem, klikając OK w oknie dialogowym. Następnie wybierz kartę, którą chcesz sprawdzić i kliknij Sprawdź .
2. Teraz możesz pracować z konsolą programisty w trybie standardowym, tak jak w przeglądarce. Będziesz mieć wszystkie znane zakładki: Konsola, Sieć i inne.

1. Aby pracować z aplikacją mobilną, musisz zainstalować i uruchomić serwer proxy. Polecamy Karola.
2. Po zainstalowaniu serwera proxy sprawdź, z jakim adresem IP łączy się aplikacja:

3. Następnie weź swoje urządzenie i skonfiguruj połączenie Wi-Fi przez serwer proxy przy użyciu portu 8888. Jest to port, którego Charles używa domyślnie.

4. Potem nadszedł czas na zbieranie trafień. Zwróć uwagę, że w aplikacjach trafienia nie są wysyłane w celu zebrania, ale wsadowego. Partia to pakietowe żądanie, które umożliwia wysyłanie wielu żądań. Po pierwsze, oszczędza zasoby aplikacji. Po drugie, jeśli wystąpią problemy z siecią, żądania zostaną zapisane w aplikacji, a po przywróceniu połączenia sieciowego zostanie wysłana jedna wspólna pula.

5. Na koniec zebrane dane muszą zostać przeanalizowane (rozłożone) na parametry, sprawdzone w kolejności i sprawdzone pod kątem specyfikacji.

Ten krok jest najszybszy i najłatwiejszy. Jednocześnie dba o to, by dane zbierane w Google Analytics miały sens. W swoich raportach możesz sprawdzić setki różnych scenariuszy i spojrzeć na wskaźniki w zależności od urządzenia, przeglądarki itp. Jeśli znajdziesz jakieś anomalie w danych, możesz odtworzyć skrypt na konkretnym urządzeniu i w określonej przeglądarce.

Możesz również skorzystać z raportów Google Analytics, aby sprawdzić kompletność danych przesyłanych do dataLayer. Oznacza to, że w zależności od każdego ze scenariuszy zmienna jest wypełniana, czy są w niej wszystkie parametry, czy parametry przyjmują prawidłowe wartości itp.

Chcemy podzielić się najbardziej przydatnymi raportami (naszym zdaniem). Możesz ich użyć jako listy kontrolnej zbierania danych:

• Raporty e-commerce:
  • Wydajność produktu
  • Wydajność listy produktów
  • Promocja wewnętrzna
• Zachowanie — Wydarzenia — Najważniejsze wydarzenia
• Akwizycja — Kampanie — Analiza kosztów
• Raporty niestandardowe — na przykład taki, który pokazuje zduplikowane zamówienia

Zobaczmy, jak te raporty wyglądają w interfejsie i na które z tych raportów należy najpierw zwrócić uwagę.

Najcenniejszą zakładką w tym raporcie jest Zachowanie zakupowe. Analizuje kompletność zbierania danych na każdym etapie rozszerzonego e-commerce. Oznacza to, że możemy sprawdzić, czy Google Analytics przenosi wyświetlenia listy produktów, kliknięcia, wyświetlenia szczegółów produktu, dodawanie/usuwanie produktów do/z koszyka oraz same zakupy.

Na co tu zwrócić uwagę? Po pierwsze, bardzo dziwne jest, że w którejkolwiek z kolumn masz wartości zerowe. Po drugie, jeśli na pewnym etapie masz więcej wartości niż na poprzednim etapie, prawdopodobnie będziesz mieć problemy z gromadzeniem danych. Załóżmy na przykład, że liczba unikalnych zakupów przedmiotu jest większa niż liczba kas. To dziwne i warto na to zwrócić uwagę.

Możesz także przełączać się między innymi parametrami w tym raporcie, który również powinien zostać przesłany do ulepszonego e-commerce. Na przykład, jeśli jako główną opcję wybierzesz Kategoria przedmiotu, możesz zobaczyć sprzedaż niektórych kategorii przedmiotów, ale nie ma widoków tych przedmiotów, nie dodaje się do koszyka itp.

Przede wszystkim należy przejrzeć wszystkie parametry, które są przesyłane do Google Analytics i zobaczyć, jakie wartości przybiera każdy parametr. Zwykle od razu wiadomo, czy wszystko jest w porządku. Bardziej szczegółową analizę dla każdego ze zdarzeń można przeprowadzić w raportach niestandardowych.

Innym standardowym raportem, który może być przydatny do sprawdzania importu danych o wydatkach do Google Analytics, jest Analiza Kosztów.

Często widzimy raporty, w których są wydatki na jakieś źródło lub kampanię reklamową, ale nie ma sesji. Może to być spowodowane problemami lub błędami w tagach UTM. Alternatywnie filtry w Google Analytics mogą wykluczać sesje z określonego źródła. Raporty te należy od czasu do czasu sprawdzać.

Chcielibyśmy zwrócić uwagę na raport niestandardowy, który umożliwia śledzenie zduplikowanych transakcji. Konfiguracja jest bardzo prosta: parametr musi być identyfikatorem transakcji, a kluczowym wymiarem muszą być transakcje.

Pamiętaj, że jeśli w raporcie znajduje się więcej niż jedna transakcja, oznacza to, że informacje o tym samym zamówieniu zostały wysłane więcej niż raz.

Jeśli znajdziesz podobny problem, przeczytaj te szczegółowe instrukcje, jak go naprawić.

Google Analytics ma bardzo dobre narzędzie alertów niestandardowych, które pozwala śledzić ważne zmiany bez przeglądania raportów. Na przykład, jeśli przestaniesz zbierać informacje o sesjach Google Analytics, możesz otrzymać powiadomienie e-mail.

Zalecamy skonfigurowanie powiadomień dla co najmniej tych czterech wskaźników:

• Liczba sesji
• Współczynnik odrzuceń
• Przychód
• Liczba transakcji

Z naszego doświadczenia wynika, że ​​jest to najtrudniejsze i najbardziej czasochłonne zadanie — wąska linia, na której najczęściej popełniane są błędy.

Aby uniknąć problemów z implementacją dataLayer, kontrole należy przeprowadzać przynajmniej raz w tygodniu. Generalnie częstotliwość powinna zależeć od tego, jak często wprowadzasz zmiany w serwisie. Idealnie byłoby, gdyby po każdej znaczącej zmianie trzeba było przetestować dataLayer. Robienie tego ręcznie jest czasochłonne, dlatego postanowiliśmy zautomatyzować ten proces.

Aby zautomatyzować testowanie, zbudowaliśmy rozwiązanie oparte na chmurze, które umożliwia nam:

• Sprawdź, czy zmienna dataLayer w witrynie odpowiada wartości referencyjnej
• Sprawdź dostępność i funkcjonalność kodu Menedżera tagów Google
• Sprawdź, czy dane są przesyłane do Google Analytics i OWOX BI
• Zbieraj raporty o błędach w Google BigQuery

Zalety automatyzacji testów:

• Znacząco zwiększ szybkość testowania. Z naszego doświadczenia wynika, że ​​w kilka godzin możesz przetestować tysiące stron.
• Uzyskaj dokładniejsze wyniki, ponieważ czynnik ludzki jest wykluczony.
• Obniż koszty testów, ponieważ potrzebujesz mniej specjalistów.
• Zwiększ częstotliwość testów, ponieważ możesz je uruchamiać po każdej zmianie w witrynie.

Uproszczony schemat algorytmu, którego używamy:

Gdy logujesz się do naszej aplikacji, musisz określić strony, które chcesz zweryfikować. Możesz to zrobić, przesyłając plik CSV, określając link do mapy witryny lub po prostu określając adres URL witryny, w którym to przypadku aplikacja sama znajdzie mapę witryny.

Następnie ważne jest określenie schematu dataLayer dla każdego testowanego scenariusza: stron, zdarzeń, skryptów (sekwencja działań, np. przy kasie). Następnie możesz użyć wyrażeń regularnych, aby określić, że typy stron odpowiadają adresowi URL.

Po otrzymaniu wszystkich tych informacji nasza aplikacja przechodzi przez wszystkie strony i zdarzenia zgodnie z harmonogramem, sprawdza każdy skrypt i przesyła wyniki testów do Google BigQuery. Na podstawie tych danych konfigurujemy powiadomienia e-mail i Slack.

PS Jeśli potrzebujesz pełnego audytu strony internetowej, możesz poprosić o doradztwo w OWOX BI. Zapisz się na demo, a omówimy możliwości.