Likwidacja luki między interfejsem Google Analytics a eksportem BigQuery

Minhaz Kazi, Developer Advocate, Google Analytics – kwiecień 2023 r.


„Ale dlaczego liczby nie będą zgodne z wynikami w interfejsie?”

Jeśli zdarzyło Ci się już pracować z danymi eksportu zdarzeń BigQuery na potrzeby usługi w GA4, na pewno już wiesz, jak to zrobić. Albo, co gorsza, ktoś inny Cię o to poprosił. Próbując udzielić na nie odpowiedzi, pewnie zadano Wam jedno z tych pytań:

„A gdzie to jest napisane?”

W tym artykule postaramy się rzucić nieco światła na oba.

Zanim przejdziemy do szczegółowych informacji o różnicach w wynikach, warto wiedzieć, jaki jest cel eksportu danych zdarzeń BigQuery. Użytkownicy Google Analytics przesyłają zebrane dane do Google Analytics za pomocą jednej z tych metod zbierania danych: tagu Google, Menedżera tagów Google, Measurement Protocol, pakietów SDK lub importu danych. Na podstawie ustawień usługi w Google Analytics usługa Google Analytics wnosi znaczną wartość do zebranych danych, zanim trafią one do standardowych platform raportowania, m.in. do raportów standardowych, Eksploracji i interfejsu Data API. Te dodatkowe korzyści mogą obejmować uwzględnienie Google Signals, modelowanie, atrybucję ruchu, prognozy itp.

Standardowe platformy raportowania dążą do zapewnienia użytkownikom Google Analytics jak największej wartości przy najprostszych problemach. Zdajemy sobie jednak sprawę, że wśród szerokiego grona użytkowników mogą być dodatkowe korzyści z Google Analytics, a nawet wprowadzać coś całkowicie dostosowanego do ich potrzeb. W przypadku tych użytkowników eksport zdarzeń BigQuery będzie punktem wyjścia. Eksport zdarzeń BigQuery będzie obejmował zebrane dane, które są wysyłane z klienta lub aplikacji do Google Analytics. Eksport zdarzeń BigQuery nie będzie zawierał szczegółowych danych o większości przypadków dodania wartości wymienionych powyżej.

Z tego względu w wielu przypadkach standardowe platformy raportowania i dane z BigQuery Export nie będą uzgadniane w tych elementach dodawania wartości. Jeśli oba rodzaje danych są spójne i pasują do tego, co zbierasz, nie musisz nic robić.

Teraz omówimy konkretne przyczyny tych różnic i przyjrzymy się temu, jak można je wyeliminować. Ten artykuł dotyczy tylko codziennego eksportu zdarzeń BigQuery, a nie eksportu strumieniowego.

Próbkowanie

Aby uzyskać dokładne porównanie danych z eksportu BigQuery z raportami standardowymi, raportami interfejsu API danych lub raportami eksploracji, upewnij się, że nie opierają się one na próbkowanych danych. Strona Próbkowanie danych w GA4 zawiera więcej informacji i informacje o sposobach rozwiązywania problemów.

Aktywni użytkownicy

Jeśli zbierzesz wszystkich użytkowników, którzy wywołali w usłudze GA4 co najmniej 1 zdarzenie, otrzymasz dane Całkowita liczba użytkowników. Chociaż w narzędziu Eksploracje w interfejsie GA4 dostępne są dane Całkowita liczba użytkowników, podstawowe dane o użytkownikach używane w raportach w GA4 to Aktywni użytkownicy. Jeśli w interfejsie GA4 i w raportach występuje tylko nazwa Użytkownicy, zwykle jest to termin Aktywni użytkownicy. Podczas obliczania liczby użytkowników na podstawie danych BigQuery musisz więc odfiltrować i zachować tylko aktywnych użytkowników, aby dane były porównywalne z danymi w interfejsie Google Analytics. Metoda obliczania będzie się też różnić w zależności od wybranej tożsamości na potrzeby raportowania.

Implementacja techniczna

Jeśli w przypadku eksportu danych do BigQuery zliczasz różne identyfikatory użytkowników, otrzymasz wartość Całkowita liczba użytkowników. Oto przykładowe zapytanie, które pokazuje łączną liczbę użytkowników i liczbę nowych użytkowników na podstawie danych z kolumny user_pseudo_id:

-- Example: Get 'Total User' count and 'New User' count.

WITH
  UserInfo AS (
    SELECT
      user_pseudo_id,
      MAX(IF(event_name IN ('first_visit', 'first_open'), 1, 0)) AS is_new_user
    -- Replace table name.
    FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
    -- Replace date range.
    WHERE _TABLE_SUFFIX BETWEEN '20201101' AND '20201130'
    GROUP BY 1
  )
SELECT
  COUNT(*) AS user_count,
  SUM(is_new_user) AS new_user_count
FROM UserInfo;

Aby wybrać tylko aktywnych użytkowników, ogranicz zapytanie do zdarzeń, dla których is_active_user ma wartość true:

-- Example: Get exact and approximate Active User count.

WITH
  ActiveUsers AS (
    SELECT
      user_pseudo_id
    -- Replace table name.
    FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
    -- Replace date range.
    WHERE _TABLE_SUFFIX BETWEEN '20201101' AND '20201130'
      AND is_active_user
    GROUP BY 1
  )
SELECT
  COUNT(DISTINCT user_pseudo_id) AS exact_active_user_count,
  APPROX_COUNT_DISTINCT(user_pseudo_id) AS approx_active_user_count
FROM ActiveUsers;

HyperLogLog++

Google Analytics stosuje algorytm HyperLogLog++ (HLL++), aby szacować moc zbioru typowych wskaźników, takich jak Aktywni użytkownicy i Sesje. Oznacza to, że gdy przeglądasz unikalne wskaźniki tych wskaźników w interfejsie użytkownika lub za pomocą interfejsu API, są one przybliżone z pewną precyzją. Ponieważ masz dostęp do szczegółowych danych w BigQuery, możesz obliczyć dokładną moc zbioru tych wskaźników. Dlatego dane mogą się nieznacznie różnić. Przy przedziale ufności 95% dokładność może wynosić ±1, 63% dla liczby sesji. Poziomy dokładności będą się różnić w zależności od wskaźników i będą się zmieniać zgodnie z przedziałami ufności. W sekcji HLL++ Szkice znajdziesz poziomy precyzji w różnych przedziałach ufności dla różnych parametrów precyzji HLL++.

Implementacja techniczna

Z artykułu Przybliżenie liczby unikalnych użytkowników w Google Analytics dowiesz się, jak wdrożono HLL++ w Google Analytics i jak możesz odtworzyć tę funkcję za pomocą zapytań BigQuery.

Opóźnienie zbierania danych

Tabele eksportów dziennych są tworzone po zebraniu wszystkich zdarzeń z danego dnia przez Google Analytics. Tabele dzienne mogą być aktualizowane najpóźniej 72 godziny od daty utworzenia tabeli za pomocą zdarzeń oznaczonych sygnaturami czasowymi z datą tabeli. Poczytaj na ten temat i zapoznaj się z przykładami. Problem ten występuje częściej, jeśli pakiet SDK Firebase lub implementacja Measurement Protocol wysyła zdarzenia offline lub opóźnione. W zależności od tego, kiedy standardowa platforma do raportowania i BigQuery zostaną zaktualizowane w ciągu tych 72 godzin, możesz zauważyć różnice między tymi usługami. W takim przypadku porównania należy przeprowadzać na danych starszych niż 72 godziny.

Raporty o dużej mocy zbioru

Załóżmy, że wyświetlasz raport za pomocą raportów standardowych lub interfejsu Data API. Raport zawiera dużą ilość danych i zawiera wymiary o dużej mocy zbioru. Wymiary o dużej mocy zbioru mogą spowodować, że raport przekroczy limit mocy zbioru dla tabeli, na której bazuje ta moc. Gdy tak się stanie, Google Analytics zgrupuje rzadziej używane wartości i oznaczy je etykietą (inne).

W przykładzie uproszczonej i małej skali, jeśli limit mocy zbioru bazowej tabeli wynosi 10 wierszy, powinno dziać się tak:

Przykład uproszczonych danych podstawowych i tabeli zbiorczej z innym wierszem

Jak widać, łączna liczba zdarzeń pozostaje bez zmian. Jednak rzadsze wartości są grupowane i nie można ponownie zagregować tabeli na podstawie żadnego wymiaru (np. nie można uzyskać z dużej dokładności łącznej liczby zdarzeń dla danego miasta w tabeli zbiorczej). Przykład staje się bardziej zrozumiały, jeśli filtrujesz dane zbiorcze na podstawie dowolnego wymiaru.

Wiersze „(inne)” są grupowane tylko w module raportowania i interfejsie Data API, gdy raport przekracza limit mocy zbioru. Jeśli wykonujesz obliczenia w BigQuery, zawsze otrzymujesz dane podstawowe, czyli najbardziej szczegółowe wiersze. Dowiedz się więcej o wierszu „(inne)” i o sprawdzonych metodach zapobiegania takim problemom.

Google Signals

Aktywowanie Google Signals w usłudze w GA4 przynosi liczne korzyści, w tym duplikowanie użytkowników na różnych platformach i urządzeniach. Zakładając, że funkcja User-ID i Google Signals nie są zaimplementowane, a użytkownik wyświetli Twoją witrynę w 3 różnych przeglądarkach, Google Analytics zliczy ją jako 3 różnych użytkowników, a BigQuery Export będzie mieć 3 osobne komponenty user_pseudo_id. Gdy jednak włączysz funkcję Google Signals i osoba zalogowała się na swoje pojedyncze konto Google we wszystkich 3 przeglądarkach, Google Analytics zduplikuje jednego użytkownika i będzie wyświetlać tę liczbę na standardowych platformach raportowania. W BigQuery nadal będą jednak wyświetlane 3 osobne komponenty user_pseudo_id. W eksporcie BigQuery nie są dostępne żadne informacje z Google Signals. Dlatego raporty z danymi Google Signals prawdopodobnie będą miały mniejszą liczbę użytkowników niż raporty z BigQuery.

Najlepszym sposobem na ograniczenie tego efektu jest zaimplementowanie identyfikatorów User-ID w usłudze w GA4 wraz z aktywacją Google Signals. Dzięki temu duplikowanie nastąpi w pierwszej kolejności na podstawie kolumny user_id. W przypadku zalogowanych użytkowników pole user_id będzie wypełnione w BigQuery i może być używane do obliczeń. W przypadku użytkowników, którzy nie są zalogowani (tj. sesji bez user_id), do usuwania duplikatów będziemy używać Google Signals.

Pamiętaj też, że niektóre raporty w standardowych platformach raportowania mogą mieć zastosowany próg i nie zwracać określonych danych. Większość informacji, które mogą podlegać progom, zwykle nie jest dostępna w narzędziu BigQuery Export.

Tryb uzyskiwania zgody w witrynach i aplikacjach mobilnych umożliwia informowanie Google o stanie zgody użytkownika na stosowanie plików cookie lub identyfikatorów aplikacji. Jeśli użytkownicy nie wyrazili zgody, GA4 wypełnia luki w zbieranych danych za pomocą modelowania kluczowych zdarzeń i modelowania behawioralnego. Żadne dane modelowane nie są dostępne w eksporcie zdarzeń BigQuery. Po zaimplementowaniu trybu uzyskiwania zgody zbiór danych BigQuery będzie zawierał pingi bez plików cookie gromadzone przez Google Analytics, a każda sesja będzie miała inny element user_pseudo_id. Z powodu modelowania będą występować różnice między standardowymi platformami raportowania a szczegółowymi danymi w BigQuery. Na przykład z powodu modelowania behawioralnego możesz zauważyć mniejszą liczbę aktywnych użytkowników w porównaniu z BigQuery Export, ponieważ modelowanie może próbować przewidywać liczne sesje poszczególnych użytkowników, którzy nie wyrazili zgody.

Aby ograniczyć to zjawisko, zaimplementuj identyfikatory User-ID w usłudze w GA4. user_id i wymiary niestandardowe są eksportowane do BigQuery niezależnie od stanu zgody użytkowników.

Dane atrybucji ruchu

W BigQuery dane atrybucji ruchu są dostępne na poziomie użytkownika (pierwszej wizyty) i zdarzenia. To są zebrane dane. Ponieważ jednak Google Analytics implementuje własny model atrybucji na poziomie sesji, informacje te nie są bezpośrednio dostępne w eksporcie BigQuery ani nie można ich obliczyć z pełną dokładnością na podstawie dostępnych danych. W zależności od zastosowania możesz połączyć zbiór danych BigQuery z odpowiednimi danymi własnymi i utworzyć własny model atrybucji. W przyszłości dodatkowe dane na potrzeby atrybucji ruchu mogą być dostępne za pomocą eksportu zdarzeń BigQuery.

Typowe błędy w obliczeniach

  • Metoda obliczania: pamiętaj, by przy obliczaniu różnych danych w BigQuery używać właściwej metodologii. Na przykład:
    • Standardowa metoda zliczania sesji w usługach w Google Analytics 4 polega na zliczaniu unikalnych kombinacji parametrów user_pseudo_id/user_id i ga_session_id niezależnie od przedziału czasu. W Universal Analytics sesje były resetowane o północy. Jeśli korzystasz z modelu UA, obliczasz sesje każdego dnia i dodajesz je, aby uzyskać łączną liczbę sesji, sesje obejmujące kilka dni zostały zliczone podwójnie.
    • W zależności od wybranej tożsamości na potrzeby raportowania musisz zaktualizować metodę obliczania liczby użytkowników.
  • Zakres wymiaru i danych: sprawdź, czy w obliczeniach korzystasz z właściwego zakresu na poziomie użytkownika, sesji, produktu lub zdarzenia.
  • Strefa czasowa: w eksporcie BigQuery event_date to strefa czasowa raportowania, a event_timestamp to sygnatura czasowa UTC w mikrosekundach. Jeśli więc użytkownik korzysta w zapytaniu z pola event_timestamp, należy go dostosować do właściwej strefy czasowej raportowania, porównując go z danymi w interfejsie.
  • Limity filtrowania i eksportowania danych: jeśli masz skonfigurowane filtrowanie danych na potrzeby eksportu zdarzeń BigQuery lub dzienna liczba eksportowanych zdarzeń przekroczyła limit, dane eksportu zdarzeń BigQuery nie będą się zgadzać ze standardowymi platformami raportowania.

Z tym wszystkim w tym poście jest coś do UNNEST. Mam nadzieję, że wśród wskazówek znajdziesz odpowiednie rozwiązania do swojego projektu. Jeśli masz pytania, DOŁĄCZ DO serwera Discorda w GA, gdzie możesz zadawać pytania!

Wstecz
Rozwiązania dla firm
Dalej
Przybliżona liczba unikalnych wartości w HLL++