Uzupełnij lukę między interfejsem Google Analytics a eksportem do BigQuery

Minhaz Kazi, przedstawiciel ds. kontaktu z deweloperami, Google Analytics – kwiecień 2023 r.

„Ale dlaczego te liczby nie zgadzają się z interfejsem?”

Jeśli masz już doświadczenie w korzystaniu z danych eksportu zdarzeń BigQuery w usłudze w GA4, to pytanie na pewno padło już kiedyś. Albo, co gorsza – ktoś inny o to poprosił(a). Próba udzielenia na nie odpowiedzi zapewne spytała Cię przerażające pytanie:

„A gdzie to jest napisane?”

W tym poście postaramy się zwrócić uwagę na te kwestie.

Zanim przejdziemy do szczegółowych informacji na temat wahań tych liczb, ważne jest, aby zrozumieć, przeznaczenia danych eksportu zdarzeń BigQuery. Użytkownicy Google Analytics wysyła zebrane dane do Google Analytics za pomocą jednej z metod zbierania danych: Google Tag, Menedżer tagów Google, Measurement Protocol, pakiety SDK i Import danych. Na podstawie ustawień usługi w Google Analytics usługa Google Analytics w uzupełnieniu zebranych danych, zanim trafią one do standardowych platform raportowania w tym raporty standardowe, narzędzie Eksploracje i interfejs Data API. Te wartości Można dodać m.in. Google Signals, modelowanie, ruch atrybucja, prognoza itp.

Standardowe platformy raportowania mają zapewniać użytkownikom Google Analytics maksymalną wartość czyli najmniejszego tarcia. Wiemy jednak, że w szerokim spektrum użytkowników niektórzy mogą chcieć uzupełniać oferty Google Analytics o dodatkowe wartości, coś całkowicie spersonalizowanego. W przypadku tych użytkowników eksport zdarzeń BigQuery jest planowanego punktu początkowego. Eksport zdarzeń BigQuery będzie zawierał zebrane dane, który jest wysyłany od klienta lub aplikacji do Google Analytics. Eksportowanie zdarzeń BigQuery nie będzie zawierać szczegółowych danych na temat większości dodatkowych wartości wymienionych powyżej.

Dlatego w wielu przypadkach użycia standardowe platformy raportowania W przypadku tych danych dane z BigQuery nie powinny być uzgadniane. dodatkowe wartości. Jeśli w obu usługach występuje wewnętrzna spójność i są one zgodne na podstawie zebranych danych.

Przyjrzyjmy się teraz konkretnym przyczynom różnic i poznajmy sposobów na ich złagodzenie. Ten post dotyczy BigQuery Tylko eksport zdarzeń dziennych, bez eksportu strumieniowego.

Próbkowanie

Aby uzyskać dokładne porównanie danych BigQuery Export ze standardowymi raportami, możesz Raporty interfejsu API lub raportów Eksploracji potwierdzają, że nie opierają się one na próbkowanych danych. Próbkowanie danych w GA4 zawiera więcej informacji i sposobów rozwiązywania problemów z próbkowaniem.

Aktywni użytkownicy

Jeśli liczysz wszystkich użytkowników, którzy zarejestrowali w GA4 co najmniej 1 zdarzenie otrzymasz dane Całkowita liczba użytkowników. Mimo że Całkowita liczba użytkowników są dostępne w narzędziu Eksploracje w interfejsie GA4. Są to podstawowe dane o użytkownikach, i raportowanie w GA4 to Aktywni użytkownicy. w interfejsie GA4 i w raportach, jeśli tylko w sekcji Użytkownicy; zwykle odnosi się do Aktywnych użytkowników. Zatem obliczanie liczby użytkowników z danych BigQuery, musisz przefiltrować i zachować tylko aktywnych użytkowników aby porównać liczby z danymi w interfejsie Google Analytics. Metoda obliczania różnią się w zależności od wybranej tożsamości na potrzeby raportowania.

Implementacja techniczna

Jeśli w danych eksportu zdarzeń BigQuery liczysz liczbę unikalnych identyfikatorów użytkowników, poda wartość Całkowita liczba użytkowników. Oto przykładowe zapytanie, które pokazuje wartości Łącznie Użytkownicy i nowi użytkownicy na podstawie danych z 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ń, w których is_active_user jest 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 do szacowania mocy zbioru używa algorytmu HyperLogLog++ (HLL++) aby znaleźć typowe dane, w tym Aktywni użytkownicy i Sesje. Oznacza to, że gdy wyświetlisz unikalnych danych wyświetlanych w interfejsie użytkownika lub interfejsie API, z pewną precyzją. W BigQuery masz dostęp do szczegółowych danych, możesz obliczyć dokładną moc zbioru tych danych. No więc mogą różnić się o niewielki procent. Przy przedziale ufności 95% precyzja może wynosić ±1,63% dla liczby sesji. Poziomy dokładności będą się różnić różnych danych i będą się zmieniać odpowiednio do przedziałów ufności. Zobacz Skecze HLL++ dla poziomów dokładności z różnymi przedziałami ufności różne parametry dokładności HLL++.

Implementacja techniczna

Zapoznaj się z artykułem Przybliżona liczba unikalnych użytkowników w Google Analytics, aby dowiedzieć się, jak HLL++ implementowanych w Google Analytics i powielania tej funkcji, za pomocą zapytań BigQuery.

Opóźnienie gromadzenia danych

Tabele dziennych eksportów są tworzone po zebraniu przez Google Analytics wszystkich zdarzeń w danym dniu. Tabele dzienne mogą być aktualizowane maksymalnie 72 godziny po dacie utworzenia tabeli z wydarzeniami oznaczonymi datą tabeli. Przeczytaj szczegóły i zobacz przykłady. Występuje tu raczej problem, pakiet SDK Firebase lub platforma Measurement Protocol wysyła offline lub wydarzeniami opóźnionymi. W zależności od tego, kiedy standardowa platforma raportowania i BigQuery aktualizacji w ciągu tych 72 godzin, między nimi. Aby je wdrożyć, należy porównywać dane pochodzące ze starszych wersji. ponad 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 ma wymiary o dużej moc zbioru. Wymiary o dużej mocy zbioru mogą spowodować, że raport przekroczy limit mocy zbioru dla tabeli bazowej. W takim przypadku Google Analytics będzie grupować rzadziej używane wartości i oznaczyć je etykietą (inne).

Skorzystaj z przykładu uproszczonego i małego, jeśli limit mocy zbioru dla wartości podstawowa tabela ma 10 wierszy, wygląda to tak:

Jak widać, łączna liczba wydarzeń pozostaje bez zmian. Jednak mniej często są grupowane razem i nie można ponownie zagregować danych w tabeli na podstawie dla żadnego wymiaru (np. w tabeli zbiorczej nie można obliczyć sumy liczby zdarzeń dla konkretnego miasta). Przykład zawiera więcej informacji będzie bardzo przydatna, jeśli filtrujesz dane zbiorcze na podstawie dowolnego wymiaru.

Wiersz „(inne)” jest grupowany tylko w module raportowania, Data API, gdy raport przekroczy limit mocy zbioru. Jeśli w obliczeniach BigQuery, zawsze otrzymasz dane ground truth – do bardziej szczegółowych wierszy. Dowiedz się więcej o wierszu „(inne)” i sprawdzonych metodach dotyczących jak tego uniknąć.

Google Signals

Włączenie Google Signals w usłudze w GA4 ma kilka zalet, w tym: duplikowanie użytkowników na różnych platformach i urządzeniach. Jeśli nie zbierasz informacji o użytkownikach identyfikatorów lub aktywacji Google Signals, a użytkownik wyświetla Twoją witrynę na 3 urządzeniach różnych przeglądarek internetowych, Google Analytics przypisuje tę aktywność do trzech różnych użytkowników, a BigQuery Export będzie mieć 3 osobne instancje user_pseudo_id. Jeśli natomiast jest włączony Google Signals, a osoba zalogowała się jedno konto Google we wszystkich trzech przeglądarkach, atrybuty Google Analytics na jednego użytkownika, co odzwierciedla tę liczbę w standardowych platformach raportowania. BigQuery nadal będzie jednak wyświetlać 3 osobne komponenty user_pseudo_id, ponieważ Informacje z Google Signals nie są dostępne w eksporcie BigQuery. W związku z tym: raporty z danymi Google Signals prawdopodobnie będą mieć mniejszą liczbę użytkowników w porównaniu do BigQuery Export.

Najlepszym sposobem na ograniczenie tego efektu jest wdrożenie w GA4 identyfikatorów User-ID wraz z aktywacją Google Signals. Dzięki temu deduplikacja odbywa się najpierw na podstawie argumentu user_id. W przypadku zalogowanych użytkowników: user_id zostanie wypełnione w BigQuery i może być używane do obliczeń. Jednak w przypadku użytkowników, którzy nie są zalogowani (tj. sesji bez user_id), Do usuwania duplikatów nadal będzie używane Google Signals.

Niektóre raporty na standardowych platformach raportowania mogą mieć zastosowano próg i nie zwrócisz określonych danych. Większość informacji, które można podlegające progom zwykle nie są dostępne w eksportach BigQuery.

Tryb uzyskiwania zgody i dane modelowane

Tryb uzyskiwania zgody w witrynach i aplikacjach mobilnych pozwala informować użytkowników o stanu zgody użytkownika na stosowanie plików cookie lub identyfikatorów aplikacji. Jeśli użytkownik odmówi zgody, GA4 wypełnia luki w zbieraniu danych za pomocą modelowania kluczowych zdarzeń i behawioralnych W eksporcie zdarzeń BigQuery nie są dostępne żadne modelowane dane. Gdy wdrożysz tryb uzyskiwania zgody, zbiór danych BigQuery będzie zawierać pingi bez plików cookie zebrane przez Google Analytics, a każda sesja będzie miała inny user_pseudo_id. Z powodu będą występować różnice między standardowymi platformami raportowania szczegółowych danych w BigQuery. Na przykład dzięki modelowaniu behawioralnym możesz zauważyć mniejszą liczbę aktywnych użytkowników w porównaniu z BigQuery Export, modelowanie może próbować przewidywać liczne sesje od użytkownika, który nie wyraził zgody na przetwarzanie danych, użytkowników.

Aby ograniczyć takie przypadki, w GA4 musisz zaimplementować identyfikatory User-ID. usłudze. Wymiary user_id i wymiary niestandardowe są eksportowane do BigQuery niezależnie od tego, czy: stan zgody użytkowników.

Dane atrybucji ruchu

W BigQuery dane o atrybucji ruchu są dostępne na poziomie użytkownika (pierwsza wizyta) na poziomie zdarzenia. To są zbierane dane. Ponieważ jednak Google Analytics stosuje własny model atrybucji na poziomie sesji, informacje nie jest dostępny bezpośrednio w BigQuery Export ani nie można go obliczyć z pełnym dokładności z dostępnymi danymi. W zależności od zastosowania: złączenie zbioru danych BigQuery z odpowiednimi danymi własnymi i kompilacją, z własnym modelem atrybucji. W przyszłości będą zbierane dodatkowe dane o ruchu atrybucja może być dostępna w ramach eksportu zdarzeń BigQuery.

Typowe błędy obliczeniowe

• Metoda obliczania: podczas obliczania różnych danych w BigQuery upewnić się, że stosujesz właściwą metodologię. Na przykład:
  • Standardowa metoda zliczania sesji w Google Analytics 4 usługi zlicza unikalne kombinacje user_pseudo_id/user_id i ga_session_id niezależnie od parametru w określonym czasie. W Universal Analytics sesje były resetowane o północy. Jeśli korzystasz z modelu UA, obliczasz sesje na każdy dzień i je dodajesz aby uzyskać łączną liczbę sesji, które obejmują kilka dni.
  • W zależności od wybranej tożsamości na potrzeby raportowania liczba użytkowników Trzeba zaktualizować metodę obliczania.
• Zakres wymiarów i danych: upewnij się, że w obliczeniach używasz funkcji prawidłowy zakres na poziomie użytkownika, sesji, produktu lub zdarzenia.
• Strefa czasowa: w eksportowaniu BigQuery wartość event_date oznacza czas raportowania. , a event_timestamp to sygnatura czasowa UTC w mikrosekundach. No więc Najlepiej, jeśli w zapytaniu używane jest event_timestamp, musi ono być dostosowane pod kątem prawidłowej strefy czasowej raportowania podczas porównywania z danymi w interfejsie.
• Limity eksportu i filtrowania danych: jeśli masz skonfigurowane filtrowanie danych dla przekroczono limit eksportowanych zdarzeń BigQuery lub została przekroczona dzienna liczba eksportowanych zdarzeń limit, dane eksportu zdarzeń BigQuery nie będą zgodne ze standardowym platform raportowania.

W tym poście jest jeszcze trochę treści UNNEST. Mam nadzieję, że potrafisz WYBRAĆ wybrać właściwe rozwiązania dla swojego projektu DISTINCT na podstawie podanych tu wskazówek. Jeśli macie pytania, PRZYŁĄCZ SIĘ do serwera Google Analytics Discord, GDZIE MASZ fajne pytania.