BigQuery dla marketerów – sesja Q&A z Mateuszem Muryjasem. DIMAQ Voice #51.

Podczas #51 edycji DIMAQ Voice jednym z prelegentów był Mateusz Muryjas z tematem “BigQuery dla marketerów”. Poniżej znajdziecie odpowiedzi na pytania jakie zadawaliście na czacie.

„Masz problem z [wstaw tutaj dowolny problem z Google Analytics 4]? Przyjacielu, musisz wdrożyć BigQuery, żeby go rozwiązać!”

Kilka kliknięć i gotowe. Brzmi znajomo, ale czy nie zbyt idealnie, żeby było prawdziwe?

Surowe dane, które zbierasz w BigQuery są jak składniki na pizzę. Kupujesz je osobno, czasem w różnych miejscach. Może się okazać, że nie wszystkie będą dobrej jakości i część trzeba będzie wyrzucić, bo zepsują cały projekt: pizza.

Od składników wyłożonych na blacie w kuchni do gorącej pizzy, która wjeżdża prosto na stół jest daleka droga. Wyrobić ciasto, przygotować sos, przyprawić, połączyć wszystkie składniki w jedną całość, włożyć i wyciągnąć z pieca w odpowiednim momencie. Wszystko to przy założeniu, że drzemie w nas mały Robert Makłowicz, mamy czas i ochotę ubrudzić sobie ręce..

Ile rzeczy może pójść nie tak? W ilu momentach powiesz sobie „w przepisie jest tak, ale my zawsze robimy inaczej, bo tak nam lepiej smakuje”. W ogóle, to może trzeba było po prostu zamówić gotowca z lokalnej restauracji?

Zaraz, czy ten post nie był o BigQuery? Był. Ale praca z danymi jest jak gotowanie. Mamy składniki i musimy stworzyć z nich danie.

---

1. Pytanie: Consent Mode — Jak analizować dane użytkowników, którzy nie wyrazili zgody na śledzenie?

W BigQuery znajdziemy dane zarówno użytkowników, którzy wyrazili zgodę na śledzenie jak i tych, którzy tej zgody nie wyrazili (w postaci zanonimizowanych zdarzeń niemożliwych do powiązania ze sobą). Warunkiem, który pozwala nam podzielić zdarzenia na te, ze zgodą i te, bez zgody może być na przykład kolumna user_pseudo_id – jeśli jej wartość jest równa NULL to znaczy, że użytkownik nie wyraził zgody na śledzenie i mamy do czynienia ze zanonimizowanym pingiem.  

Przykładowe zapytanie, które pozwala wyciągnąć z eksportu danych do BigQuery zdarzenia użytkowników, którzy nie wyrazili zgody może wyglądać następująco.

SELECT

 *

FROM

 `your-project-id.analytics_1234567890.events_*`

WHERE

 user_pseudo_id IS NOT NULL;

Warunek user_psuedo_id IS NOT NULL ogranicza rezultat zapytania do eventów, które w eksporcie danych nie zostały przypisane do użytkownika z uwagi na status wyrażonej zgody (consent).

Mimo wielu plusów płynących z analizy danych w BigQuery warto podkreślić, że anonimowe pingi (zdarzenia) zbierane w ramach śledzenia użytkowników, którzy nie wyrazili zgody na śledzenie mogą powodować problemy i być trudne do wykorzystania, szczególnie w kontekście analizy danych dotyczących źródeł ruchu. Podejście do tej grupy danych może się różnić w zależności od tego, jakie analizy prowadzimy. 

W pierwszej kolejności warto ustalić, czy brak zgody użytkownika wpływa na raport (analizę), nad którą pracujemy. Na przykład jeśli interesuje nas popularność produktów, rozumiana jako liczba wyświetleń danego produktu na stronie, to brak danych o użytkowniku nie wpływa na dane, których potrzebujemy – interesuje nas całkowita liczba zdarzeń (tutaj: view_item), bez względu czy były one wykonane przez użytkownika, który zgodę wyraził, czy nie. 

Z drugiej strony, jeśli popularność zdefiniujemy jako liczba unikalnych użytkowników, którzy widzieli dany produkt, brak zgody będzie miał wpływ na wynik – część zdarzeń view_item nie będzie mogła być przypisana do użytkowników. Analogiczna sytuacja może dotyczyć popularności treści na stronie czy wybranych danych e-commerce (transakcji, przychodów w ujęciu łącznym). Brak zgody nie wpływa też na zbieranie danych dot. urządzeń czy lokalizacji geograficznej.

Jak w takim razie radzić sobie z analizą danych użytkowników, którzy nie wyrazili zgody? Guillaume Wagner opisał najpopularniejsze podejścia w artykule 🔗 Understand the GA4 BigQuery raw data with consent mode activated jako:

• wykluczenie danych (eventów) nie posiadających informacji o użytkowniku i sesji — biorąc pod uwagę charakter analizy (ilościowy, skupiony na trendach) skorzystanie z danych posiadających zgodę daje nam reprezentacyjną próbkę do podejmowania decyzji na ich podstawie
• wykorzystanie API do zasilenia surowych danych zagregowanymi metrykami — część danych pobieranych jest z BigQuery, a inne – za pomocą API – z usługi Google Analytics 4
• odwzorowanie modelowania GA4 wykorzystując BigQuery ML — modelowanie wykorzystywane przez Google Analytics to nic innego, jak uczenie maszynowe, w którym zbiorem uczącym są dane użytkowników, którzy wyrazili zgodę; na podstawie tych danych i anonimowych pingów (zdarzeń bez zgody) tworzony jest pełny obraz ruchu na stronie

W przypadku pracy z danymi zebranymi w BigQuery możemy też spróbować tzw. fingerprintingu, czyli powiązania danych w ramach urządzenia, gdzie o unikalności urządzenia świadczyć będą dane o lokalizacji, kategorii urządzenia, czy modelu i jego marce.

2. Pytanie: Dlaczego warto korzystać z BigQuery? Jak robić to efektywnie i jak wdrożyć je w organizacji?

Efektywne wdrożenie BigQuery powinno przekładać się na wartość dla biznesu. Może to być na przykład poprawa efektywności kampanii marketingowych, ulepszenie produktu czy wzrost sprzedaży. Przed wdrożeniem warto zidentyfikować obszary (problemy), w których BigQuery może nam pomóc – na przykład:

• eliminacja produktów, które generują koszty reklamowe, a nie generują sprzedaży
• analiza LTV klienta i wzmocnienie działań mających na celu retencję klientów
• automatyzacja raportowania i analizy danych w wybranym obszarze (marketing, sprzedaż)
• integracja danych ze źródła A i B w celu uzyskania bardziej wiarygodnych metryk (wskaźników) wzrostu

Kolejnym krokiem będzie określenie źródeł danych i ich orkiestracja, czyli proces polegający na (automatycznym) pozyskiwaniu surowych danych i przetwarzaniu ich do postaci pozwalającej na ich konsumpcję – w postaci raportów (dashboardów) lub aktywacji w narzędziach marketingowych. 

Finalnie, każde działanie – w tym także wdrożenie BigQuery – powinno przekładać się na efekty dla organizacji. Warto pamiętać o monitorowaniu zmian i efektów (celów), w obszarach, które zaadresowaliśmy przed wdrożeniem.

Wśród zalet wdrożenia BigQuery możemy wymienić m. in.:

• utworzenie jednego źródła (miejsca), w którym znajdują się wszystkie dane zbierane w organizacji
• integracja danych z wielu rozproszonych źródeł w jednej przestrzeni
• poprawa jakości danych poprzez procesy orkiestracji czyszczące i walidujące przychodzące dane
• praca z wymiarami i metrykami kluczowymi dla biznesu, a nie oferowanymi przez narzędzia as-is
• własność (ownership) danych, które znajdują się w projekcie
• możliwość aktywacji zebranych danych w procesach sprzedażowych i narzędziach marketingowych

3. Pytanie: Jakie są ograniczenia i pułapki podczas korzystania z BigQuery? Czego na pewno nie możemy w nim zrobić?

Podstawową rzeczą, której nie możemy zrobić w BigQuery to iść na skróty. BigQuery nie jest dla nas, jeśli nie znamy SQLa i oczekujemy gotowych raportów, dostępnych od razu po uruchomieniu narzędzia. 

Pierwszym wyzwaniem dla osób zaczynających pracę z BigQuery jest zrozumienie pojęcia surowych danych – czyli takich, które często wymagają oczyszczenia czy agregacji, żeby stały się wartościowym insightem w raporcie. Do BigQuery trafiają często surowe dane, które następnie musimy – za pomocą 1, 2 a czasem 10 zapytań – przetworzyć przed tym, zanim trafią do raportu.

Wyzwaniem może okazać się również próg wejścia i brak kompetencji technicznych. Praca z BigQuery to nie wklejenie kody na stronę (do czego my, marketerzy, jesteśmy poniekąd przyzwyczajeni) lub kliknięcie 3 przycisków w interfejsie narzędzia. Oprócz podstaw pracy z językiem SQL musimy też często skonfigurować środowisko w Google Cloud czy zadbać o proces ETL, który technicznie odpowiada za to, aby dane trafiły z punktu A (źródło) do punktu B (nasz projekt w BigQuery). Wydłuża to czas do osiągnięcia efektu (nauka, praca z zewnętrznymi konsultantami) i może powodować niezrozumienie wartości płynącej z narzędzia przez osoby, które nie chcą tych kompetencji nabywać. 

Ograniczeniem i wyzwaniem może być również podejście i mindset w organizacji, dla której pracujemy. Ciągłe porównywanie danych pomiędzy narzędziami, które nigdy nie będą takie same, kwestionowanie jakości i poprawności danych czy brak wsparcia ze strony dostawców danych (np. działów IT czy osób, które odpowiadają za input) może przekładać się na brak oczekiwanych efektów w stosunku do założeń, których oczekują naszą stakeholderzy.

4. Pytanie: Czy w BigQuery istnieje kreator lub samouczek pozwalający na budowę raportów? 

BigQuery nie oferuje natywnego rozwiązania, wbudowanego w platformę Google Cloud, które miałoby taką funkcjonalność. Tak jak wspominaliśmy na webinarze, kluczową umiejętnością jest znajomość języka SQL, który pozwala nam na przetwarzanie danych, krok po kroku rozumiejąc co się z nimi dzieje.

Oprócz książek, które były wspomniane w prezentacji, pomocne mogą okazać się następujące zasoby:

• 🔗 GA4BigQuery — Blog dot. GA4 i BigQuery, który zawiera przykłady zapytań (wraz z omówieniem) oraz przykłady problemów biznesowych (wraz z przykładowymi zapytaniami)
• 🔗 Query GA4 Data In Google BigQuery – Simmer — Kurs na platformie Simmer stworzony przez Simo Ahava i Johan van de Werken, autora bloga GA4BigQuery

W pierwszych krokach może pomóc rozwiązanie 🔗 GA4BQ — Create Google Analytics 4 BigQuery Queries Without Knowing SQL – wtyczka do Google Chrome, która w oparciu o oczekiwane wymiary i metryki pomoże zbudować zapytanie dla danych z Google Analytics 4. Pamiętajmy jednak, że efektywna praca z BigQuery polega na zrozumieniu tego, co zwraca dane zapytanie i walidacji, czy dane, które otrzymaliśmy faktycznie są tym, czego potrzebujemy.

Pomocna może również okazać się umiejętność pracy z modelami LLM – na przykład Chat GPT — w momencie pisania odpowiedzi na pytania modele te radziły sobie bardzo przyzwoicie. Na przykład: w odpowiedzi na prompt “I’m working with Google Analytics 4 raw data in BigQuery. How to write a query that will sum up transactions and revenue?” możemy otrzymać zapytanie, które pozwoli policzyć nam liczbę transakcji i sumę przychodów e-commerce.

5. Pytanie: Czy Google Analytics 4 nie powinien upraszczać tworzenia raportów zamiast dokładać dodatkową warstwę, która komplikuje korzystanie ze zbieranych danych?

Zdecydowanie powinien i nawet tak jest! Google Analytics 4 posiada wbudowane narzędzia, które pozwalają na tworzenie raportów wewnątrz narzędzia (dostosowywanie raportów standardowych, czy moduł eksploracji danych) dużo lepiej niż jego poprzednia wersja (Universal Analytics). 

Mówiąc o BigQuery mówimy jednak o sytuacjach, które wychodzą poza podstawowe funkcjonalności GA4:

• łączenie danych z różnych źródeł 
• analiza danych uwzględniająca wrażliwe dane (np. użytkownicy, klienci, dane handlowe)
• tworzenie wymiarów i obliczanie metryk wychodzących poza standardowy katalog danych w GA4

W tym wypadku BigQuery sprawdzi się dużo lepiej. Z drugiej strony, jeśli interfejs Google Analytics 4 i wbudowane raporty wystarczają do codziennej pracy i podejmowania decyzji, a pytania biznesowe i potrzeby analityczne nie wychodzą poza oferowane funkcjonalności, to BigQuery może okazać się nietrafionym pomysłem. 

6. Pytanie: Czy dane w BigQuery są bezpieczne? Jak wygląda kwestia bezpieczeństwa zbieranych i przechowywanych danych?

BigQuery jest częścią Google Cloud Platform (GCP), czyli publiczne chmury zarządzanej przez firmę Google – zasoby, które przechowujemy w chmurze podlegają kontroli dostępu, podobnie jak każda inna przestrzeń (możemy pomyśleć o tym w analogiczny sposób, jak o hostingu przechowującym naszą stronę internetową).

Każda chmura publiczna, w tym także GCP, podchodzi bardzo poważnie do kwestii bezpieczeństwa obsługując procesy IAM (Identity and Access Management), które decydują o dostępie do danych i usług.

Oprócz klasycznego podejścia (dostęp do projektu) BigQuery posiada 🔗 role użytkowników, które mogą być ograniczane do poziomu zbiorów danych, czy tabel jak również aktywności, które mogą zostać wykonane (odczyt, zapis). Dodatkowo takie elementy jak tagi, czy tzw. row-access level security pozwalają (w sposób bardzo granularny, szczegółowy) kontrolować dostęp do danych. Jako wstęp do tematyki bezpieczeństwa danych w BigQuery polecam artykuł Pooja Kelgaonkar, w którym wyjaśnia podstawowe zagadnienia bezpieczeństwa danych w Google Cloud: 🔗 Data Security and Governance with GCP BQ 

7. Pytanie: Czy BigQuery jest aktualnie rekomendowanym narzędziem? Jakie inne narzędzia mogą realizować podobne funkcje i są warte rozważenia?

BigQuery to przykład hurtowni danych — narzędzia, którego celem jest umożliwienie integracji danych z różnych źródeł za pomocą procesów ETL (extract, transform and load) w jednym fizycznym miejscu. Rynek produktów tego typu oferuje wiele rozwiązań o podobnej funkcjonalności. Duzi dostawcy chmury posiadają swoje rozwiązania — Amazon Redshift, czy Microsoft Azure. Na rynku znajdziemy też produkty dedykowane analizie danych takie jak Snowflake, czy Databricks.

Na decyzję dotyczącą wyboru narzędzia wpływa bardzo często stack technologiczny, który jest obecnie stosowany w organizacji — większość dostawców (Amazon, Microsoft) oferuje analogiczne rozwiązania w ramach swoich chmur. Jeśli nasza organizacja aktywnie wykorzystuje już jakieś rozwiązanie, to z dużym prawdopodobieństwem lepszą decyzją będzie integracja hurtowni danych będącej częścią obecnie wykorzystywanej chmury. 

BigQuery jest obecnie jednym z najszybciej rozwijających się narzędzi w obszarze data (w rozumieniu oferowanych funkcjonalności) i dynamiki wzrostu. Jest dobrze zintegrowane z innymi usługami chmury oraz rozwiązaniami AI & ML. Dobrze integruje się również z produktami marketingowymi i analitycznymi Google, które na co dzień wykorzystują marketerzy (np. Google Analytics, Google Ads, czy Google Search Console).

 

8. Pytanie: Jaki model atrybucji jest możliwy w BigQuery? Który model wybrać, aby otrzymać rzeczywiste dane dot. wpływu kanałów reklamowych i kampanii marketingowych na sprzedaż?

Orkiestracja danych w BigQuery pozwala przypisać źródło ruchu do każdego eventu, który znalazł się w eksporcie danych GA4 → BigQuery (przy założeniu, że użytkownik wyraził zgodę na śledzenie w consent banerze). Dzięki temu możemy – prawie dowolnie – modelować nasze dane. Możliwe są zarówno analizy na poziomie źródła pojedynczego zdarzenia, sesji czy użytkownika, jak również spojrzenie przez pryzmat pierwszej lub ostatniej interakcji. 

Nie ma jednej dobrej odpowiedzi na to pytanie – z mojego subiektywnego doświadczenia najczęściej spotkamy się z odwzorowaniem modelu last non-direct source (ostatnie, niebezpośrednie źródło sesji) oraz modelem first non-direct acquisition channel będące pierwszym, niebezpośrednim kanałem pozyskania użytkownika. 

Możemy też spotkać się z podejściem, w którym oceniamy czy dany kanał (źródło) brało udział w ścieżce konwersji – np. czy użytkownik miał na swojej ścieżce kampanię w wyszukiwarce albo kliknięcie w reklamę w social media. W tym przypadku do jednej konwersji może być przypisanych wiele kanałów, więc nie są to dane rozłączne – ich celem, bardziej niż przypisanie wartości do kanału, jest odpowiedź na pytanie o to, czy kanał bierze (lub nie) udział w konwersji.

9. Pytanie: Jak połączyć dane z Facebooka z BigQuery?

BigQuery w ramach narzędzia Data Transfer Service oferuje prosty w konfiguracji interfejs do importu danych z konta reklamowego na Facebooku. W momencie odpowiedzi oferował on jednak dość ograniczoną funkcjonalność (3 podstawowe tabele z dziennym interwałem danych) – osobiście nie uważam go za wybitnie dobre rozwiązanie.

Alternatywą dla wbudowanego transferu danych są:

• rozwiązania 3rd party oferowane przez dostawców takich jak Supermetrics, Fivetran, Airbyte, Portable czy dobrze znanym marketerom Zapier
• samodzielna integracja danych z wykorzystaniem API Facebooka (Meta) i orkiestracja procesu z inżynierami danych

Obydwie alternatywy pozwalają dziś na większą elastyczność w zakresie zbieranych danych i są przeze mnie rekomendowane organizacjom, które chcą w swojej hurtowni umieścić dane o skuteczności kampanii reklamowych prowadzonych na Facebooku czy Instagramie.  

10. Pytanie: Czy w BigQuery możemy wykonać backup danych z Universal Analytics? Czy warto to zrobić?

BigQuery pozwala na przechowywanie dowolnych danych, a więc również tych, które pochodzą z Universal Analytics. Musimy przy tym pamiętać, że nie ma narzędzia, które zrobi to za nas jednym kliknięciem. 

Jeśli w swoich analizach korzystasz z danych historycznych sprzed 2 – 3 lat, to warto wyposażyć się w kopię najważniejszych danych i metryk. Przy okazji porównań warto pamiętać o różnicach danych pomiędzy UA, a GA4. Porównywanie tych danych między sobą nie zawsze może mieć sens, chociażby z uwagi na różne sposoby obliczania metryk. 

Osobiście nie jestem fanem eksportu “wszystkiego, bo może kiedyś się przyda” — z mojego doświadczenia 90% z tych danych nigdy nie ujrzy światła dziennego. Jeśli rozważasz eksport, skup się na tych danych, z których korzystasz najczęściej (źródła ruchu, popularność treści, zdarzenia, źródła transakcji i podział ruchu wg urządzeń).

Z drugiej strony zachowanie naszych danych o charakterze big picture (miesięczny wolumen ruchu z danego źródła ruchu (kampanii), procentowy udział poszczególnych kanałów w całkowitym ruchu na stronie czy podział ruchu pomiędzy urządzenia mogą być wartościowymi danymi, które warto zachować na przyszłość – na przykład w BigQuery. Zostało jednak niewiele czasu – dostęp do danych w UA zostanie wyłączony już 1 lipca 2024!