Wprowadzenie do DataOps
Praca na surowych danych a czas i koszty analizy
Złożoność danych online i etapy ich przetwarzania
Model danych jako sprawdzone rozwiązanie
Podsumowanie
W tym wpisie opisuję, jak działa DataOps w praktyce. Przedstawiam różnice pomiędzy analizami opartymi na danych przygotowanych według zasad DataOps i sprawdzonych pod względem jakości, a analizami wykonywanymi na surowych danych pobieranych bezpośrednio z narzędzi analitycznych. W artykule zostaną omówione kluczowe aspekty złożoności danych online, które są dostępne w codziennej pracy analityków. Przedstawione zostaną różnice między pracą na danych surowych a przetworzonych, na przykładzie naszego modelu danych. Zostanie również pokazane, do czego może prowadzić bagatelizowanie problemu nieustrukturyzowanych danych.
Wyobraźmy sobie sytuację, w której analityk otrzymuje proste z pozoru zadanie: ile ruchu pochodziło w marcu z poszczególnych źródeł? Jeśli korzysta z hurtowni danych, takiej jak Google BigQuery, musi sięgnąć do ogromnych, nieprzetworzonych zbiorów. Praca na takich danych, bez wcześniejszego uporządkowania i przetworzenia, może wymagać nawet 179 linii kodu, aby uzyskać odpowiedź na tak podstawowe pytanie.
Złożoność danych online sprawia, że brak odpowiedniej ich struktury i przetwarzania nie tylko utrudnia codzienną pracę, ale także prowadzi do błędów i nieefektywności. Bagatelizowanie tego problemu może przekładać się na czasochłonne analizy oraz opóźnienia w podejmowaniu decyzji biznesowych.
Odpowiednie zarządzanie danymi, ich ustrukturyzowanie i przetwarzanie są kluczowe, aby sprawnie odpowiadać na pytania biznesowe i efektywnie wykorzystywać potencjał dostępnych narzędzi analitycznych. Poniżej przykład typowego zapytania, które pozwala odpowiedzieć na konkretne pytanie analityczne. Składa się ono ze 179 linii kodu. Wynik działania tego zapytania pojawia się po jego uruchomieniu.
Takie zapytanie można jednak przetworzyć w znacznie prostszy sposób, wykorzystując wcześniej przeprocesowane dane. Wystarczy wtedy dwanaście lub dziewięć linii kodu. Po odtworzeniu tego procesu widać, że odpowiedź pojawia się znacznie szybciej. Dodatkowo, liczba przetwarzanych danych jest dużo niższa: dwadzieścia megabajtów zamiast sześciu gigabajtów w pierwszym przypadku. Oprócz szybkości działania, przetwarzana jest znacznie mniejsza ilość danych, co wpływa na koszt analizy. Wyniki pozostają takie same, jednak czas ich uzyskania jest znacznie dłuższy. Zapytanie zostało wcześniej przygotowane, jednak w praktyce za każdym razem konieczne będzie jego wykonanie. Kluczowym problemem nie są kompetencje analityka ani to, czy potrafi napisać 179 linii kodu. Główne wyzwania to czas potrzebny na przygotowanie zapytania SQL, ryzyko popełnienia błędów oraz koszt analizy w Google BigQuery.
W przypadku analizy danych surowych, szczególnie z GA4 w Google BigQuery, dane są zorganizowane w zagnieżdżonej strukturze JSON. Po otwarciu konkretnej tabeli w BigQuery okazuje się, że pojedynczy wiersz, oznaczony np. ID eventu, zawiera kilkanaście lub kilkadziesiąt zagnieżdżonych wartości, które za każdym razem wymagają rozpakowania. Warto zwrócić uwagę, jak złożona jest analiza takich danych online. W pierwszych 179 linijkach kodu SQL uwzględnionych jest co najmniej sześć czynników, które należy wziąć pod uwagę, analizując surowy eksport danych z GA4 do Google BigQuery. Pierwszym krokiem jest zbudowanie sesji na podstawie eventów. W pliku zagnieżdżonym widoczny jest pojedynczy event, jednak aby przedstawić ruch, konieczne jest odtworzenie sesji z tych eventów. Przykładowe zapytanie pokazuje, ile eventów składa się na jedną sesję – na przykład dla jednego Session ID może być to nawet 1643 eventy. Taki zbiór danych trzeba odpowiednio przetworzyć, rozpakowując informacje na potrzeby dalszej analizy. Przed przygotowaniem podziału źródeł ruchu na poszczególne kanały, należy przekształcić tabelę z eventowej na sesyjną. Dane z miesiąca w Google BigQuery przetwarzamy na podstawie kilku milionów rekordów. Analiza obejmująca cały rok, w zależności od sezonowości, zwykle oznacza proporcjonalnie większą liczbę danych. To kolejny powód, by korzystać z wstępnie przetworzonych danych, które pozwalają znacząco obniżyć koszty pracy z Google BigQuery. Szczegółowo opisałem ten temat w osobnym wpisie, do którego link znajduje się w opisie.
Pierwszym krokiem jest więc wypłaszczenie danych. Kolejnym elementem jest naprawa ruchu direct. GA4 często klasyfikuje sesje jako direct, nawet jeśli w linku występują inne parametry, takie jak UTM czy GetSleet. Na przygotowanym przykładzie zapytania widać, że w url-u pojawia się „get-lead”, co oznacza ruch z kampanii ads. Jednak po wyciągnięciu source i medium, te pola pozostają puste. Kolejnym krokiem jest naprawa tych danych, które trafiają do systemu. Zarówno interfejs GA4, jak i surowe dane w Google BigQuery, często nie są poprawnie przetworzone.
Trzecim elementem jest wykluczenie bramek płatności. Użytkownik wracający z bramki płatności do serwisu nie powinien mieć tego ruchu przypisanego do bramki płatności. W takiej sytuacji odpowiednia logika powinna pobrać źródło ruchu z poprzedniego eventu, który miał miejsce przed przekierowaniem do zewnętrznej bramki.
Piątym krokiem jest grupowanie kanałów, a ostatnim – prezentacja wyników analizy. W przypadku każdego serwisu mogą pojawić się dodatkowe, specyficzne warunki brzegowe. W tym przykładzie sześć kroków i 179 linii kodu pokazuje, jak złożony potrafi być ten proces. Analizując dane w Google Analytics 4 i BigQuery, należy zwrócić uwagę na warunki brzegowe związane z integracją tych narzędzi. Różnice między danymi w interfejsie GA4 a surowymi danymi w BigQuery często wynikają z błędów w przypisywaniu źródeł ruchu. Przykładem jest nieprawidłowe przepisywanie ruchu z Google do Direct, co prowadzi do zaniżenia metryk, takich jak ROAS z Google Ads.
Podobny problem dotyczy nieprawidłowego przypisywania parametrów, na przykład FBC Lead. Jeśli ruch z Facebooka zostanie potraktowany jako Direct, ROAS oraz META-AC również będą zaniżone. Problemy pojawiają się także przy nieprawidłowym tagowaniu kampanii UTM. Brak poprawnego przypisania źródła i medium sprawia, że ruch z danej kampanii nie pojawia się w raportach.
Warto pamiętać o tych aspektach podczas analizy danych, aby uzyskiwać wiarygodne wyniki i lepiej oceniać skuteczność prowadzonych działań marketingowych. Jednym z istotnych elementów jest bramka płatności. Transakcje są często przypisywane do bramek płatności po powrocie użytkownika z zewnętrznej strony płatności. W takim przypadku kampanie marketingowe generujące ten ruch tracą na znaczeniu w raportach. Istnieje wiele podobnych przypadków, jednak to jedne z najczęściej obserwowanych sytuacji.
Różnica między analizą surowych danych a korzystaniem z ustalonego modelu danych polega na tym, że nie trzeba każdorazowo pamiętać o wszystkich niestandardowych przypadkach. W naszym modelu danych rozwijamy i aktualizujemy te rozwiązania na bieżąco. Model powstał na bazie półtorarocznych prac i obejmuje około 95% przypadków. Przekłada się to bezpośrednio na analizę – czas odpowiedzi na proste biznesowe pytanie to 179 linii kodu w klasycznym podejściu, podczas gdy przy wykorzystaniu naszego modelu danych wystarczy jedynie 9 linii. Ryzyko popełnienia błędu jest wysokie, gdy za każdym razem kod trzeba pisać od nowa. Przy zastosowaniu modelu danych ryzyko to spada. Logika modelu została wypracowana i przetestowana na około 30 klientach, dzięki czemu jest centralizowana i sprawdzona w praktyce. W danych surowych źródła ruchu wymagają ręcznego poprawiania i uwzględniania różnych edge case’ów. Model danych natomiast narzuca gotowe, skorygowane standardy. Przy samodzielnym grupowaniu ruchu do kanałów konieczne jest tworzenie wielu dodatkowych reguł, na przykład z użyciem instrukcji if then lub case, w zależności od źródła ruchu. Model danych zapewnia jedno źródło prawdy, które można rozszerzać, gdy pojawiają się nowe źródła ruchu.
Atrybucję w danych surowych trzeba konfigurować ręcznie, dostępny jest tam tylko jeden model. W modelu danych dostępne są co najmniej trzy gotowe modele atrybucji, które można od razu wykorzystać lub dostosować do własnych potrzeb.
Identyfikacja użytkownika w danych surowych opiera się głównie na ciasteczkach przeglądarki. Model danych umożliwia unifikację użytkownika pomiędzy różnymi urządzeniami z wykorzystaniem algorytmu Unified ID. Koszt analizy surowych danych, jak w przypadku 6 GB danych miesięcznie, jest bardzo wysoki w porównaniu do minimalnych kosztów analizy 20 MB danych po wstępnym przetworzeniu. Model danych zapewnia efektywność kosztową, co jest kluczowe w podejściu DataOps.
Nasz model danych nie tylko naprawia źródła ruchu i atrybucje, ale także agreguje dane do jednego Single Source of Truth. Optymalizujemy dane pod kątem późniejszego wykorzystania, aby nie przekroczyć budżetu w Google BigQuery. System monitoruje i alarmuje w przypadku nieprawidłowości, co odzwierciedla koncepcję DataOps.
O modelu danych i DataOps można przeczytać więcej w osobnych wpisach na naszym blogu. Wkrótce pojawi się również artykuł poświęcony koncepcji GDock. Punkt szósty to analiza z wykorzystaniem różnych data produktów. Przykładem takiego rozwiązania jest AI Overview, który został omówiony w jednym z wcześniejszych wpisów na blogu. Warto zapoznać się z pełnym opisem modelu danych, gdzie szczegółowo przedstawiono tę koncepcję. Nie trzeba koniecznie korzystać z naszego modelu danych, choć oczywiście go rekomendujemy.
Podsumowując, DataOps, którego kwintesencją jest nasz model danych, stanowi sposób na efektywną analitykę. Zamiast poświęcać czas na zbieranie i porządkowanie danych, można skupić się na analizie, wyciąganiu wniosków i formułowaniu rekomendacji – czyli na tych elementach analityki, które mają największą wartość dla biznesu. Wartość analityki pojawia się na etapie wyciągania wniosków i formułowania rekomendacji. Automatyzacja zbierania danych pozwala uniknąć konieczności każdorazowego pozyskiwania surowych danych, co zmniejsza ryzyko dla biznesu. Automatyczne gromadzenie danych zwiększa bezpieczeństwo i efektywność procesów analitycznych.
Tagi:
Historie sukcesów
Ostatnie wpisy na blogu
