Pytania o dane GA4 i kontrola odpowiedzi za pomocą SQL

Jasne pytanie to dopiero początek

Ile zakupów odnotowano wczoraj? Pytanie może dotyczyć zdarzeń purchase, różnych identyfikatorów transakcji albo uzgodnionych zamówień. Wyniki mogą się różnić. Przydatna analiza zaczyna się więc od krótkiej definicji liczonej wielkości.

Co zapewnia Conversational Analytics

Google ogłosiło ogólną dostępność Conversational Analytics w BigQuery 30 czerwca 2026 roku. Pytania w zwykłym języku prowadzą do zapytań i analiz. Analiza danych z własnej usługi GA4 wymaga skonfigurowanego eksportu do BigQuery. Publiczny przykład poniżej nie wymaga eksportu z własnej usługi. Asystent nie odtworzy brakujących zdarzeń historycznych. Dostępność wybranego interfejsu oraz uprawnienia Cloud wymagają sprawdzenia w konkretnym projekcie.

Krótka definicja pomiaru

Na początek przydaje się liczba zdarzeń purchase według event_date w tabelach dziennych dla minionych dat między dwiema stałymi datami. Definicja wskazuje też zbiór danych, strefę czasową usługi i czas wykonania zapytania. Takie obliczenie liczy zdarzenia, a nie zamówienia po usunięciu duplikatów. Zwroty i przychód pozostają poza zakresem wskaźnika.

Prosty punkt odniesienia

Poniższy SQL liczy wiersze purchase w publicznym przykładowym zbiorze GA4. Historyczny zakres dat służy jako powtarzalny wzorzec. Własny eksport wymaga zmiany projektu, zbioru i dat. Zapytanie nie zostało wykonane w BigQuery na potrzeby artykułu, dlatego artykuł nie podaje wyniku tego zapytania. Publiczny zbiór zawiera celowo zmienione dane i służy do ćwiczeń, a nie do kontroli rzeczywistych wyników firmy. Zapytanie nie zwraca wiersza dla dnia bez zdarzenia purchase. Sam brak daty nie potwierdza więc luki w danych. Pełny ciąg dat z wartościami zerowymi wymaga tabeli kalendarza i połączenia LEFT JOIN.

SELECT event_date, COUNT(*) AS purchase_events
FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20210101' AND '20210107'
  AND event_name = 'purchase'
GROUP BY event_date
ORDER BY event_date;

To samo pytanie, te same dane

Polecenie dla asystenta powinno określać te same tabele, daty, zdarzenie i grupowanie. Kontroli wymagają zarówno wygenerowany SQL, jak i wynik. Czy granice dat oraz filtry są zgodne? Dodatkowe UNNEST tablicy items może zwielokrotnić wiersze zdarzeń. Liczenie różnych transaction_id odpowiada już na inne pytanie. Przekonujący opis nie zastępuje takiej kontroli.

Dlaczego raport GA4 nadal może się różnić

Eksport surowych danych i raporty Analytics korzystają z różnych sposobów przetwarzania. Na porównanie wpływają między innymi tożsamość, modelowanie, atrybucja i aktualność danych. Google uzupełnia tabele dzienne o opóźnione zdarzenia jeszcze przez maksymalnie trzy dni po dacie zdarzenia. Zapis czasu zapytania pomaga oddzielić zmianę danych od zmiany obliczenia.

Koszt przed wykonaniem

Dry run sprawdza zapytanie i szacuje ilość przetwarzanych danych bez obliczania wyniku. Wąski zakres tabel oraz wskazane kolumny ułatwiają kontrolę. Uruchomienie produkcyjne wymaga odpowiedniego limitu kosztu i przeglądu wykonanych zadań. Samo LIMIT nie ogranicza niezawodnie ilości odczytywanych danych.

Measurement Summary

Wskaźnik to liczba wierszy zdarzeń purchase według event_date. Zapytanie referencyjne i zapytanie AI muszą korzystać z tych samych tabel, dat, filtrów i stanu danych. Kontrola obejmuje brakujące dni, powielone wiersze wyniku oraz różnice dzienne. Artykuł nie zawiera uwierzytelnionego uruchomienia BigQuery ani pomiaru dokładności.

Narzędzia i dalsza lektura

• Kreator zapytań GA4 dla BigQuery
• Generator zapytań BigQuery i UNNEST dla GA4
• GA4 Advisor: weryfikacja przez runReport
• Koszty BigQuery przy eksporcie GA4: które tabele i kolumny czyta zapytanie oraz bezpłatny dry run

Interaktywna ścieżka nauki pomiaru Analytics

Źródła

• Google Cloud: Conversational Analytics announcement
• BigQuery: Conversational analytics overview
• GA4: BigQuery Export schema
• BigQuery: Query syntax and dry runs
• GA4: publiczny przykładowy zbiór BigQuery