Na czym to polega w sklepie
BigQuery rozlicza skanowane bajty - nie liczbę wierszy w wyniku. SELECT * na surowym events_* z koszykiem, ecommerce i dziesiątkami parametrów to setki razy drożej niż pięć potrzebnych kolumn. Przed ciężkim jobem włącz estymację lub dry run.
Przykład ze sklepu internetowego
Zespół BI w marketplace odpytuje purchase codziennie z Lookera. Zamiast SELECT * - tylko kolumny potrzebne do raportu revenue:
-- Zły wzorzec: SELECT * FROM events_* WHERE ...
-- Lepszy:
SELECT
event_date,
event_name,
transaction_id,
ecommerce.purchase_revenue
FROM `project.analytics.events_*`
WHERE _TABLE_SUFFIX = '20260601'
AND event_name = 'purchase';
-- Podgląd kosztu (CLI): bq query --dry_run --use_legacy_sql=false '...'Co zrobić po stronie biznesu
- Zbuduj tabelę mart z dziennej agregacji - analitycy i Looker odpytują mały widok, nie surowiec.
- Przenieś raporty z ciągłego skanowania events_* na scheduled query - stały, przewidywalny koszt.
- Wyłącz cache przy testach powtarzalnych kosztów w QA - inaczej drugie uruchomienie myli wynik optymalizacji.
W skrócie
Warstwa mart + partycja to kontrola kosztów całego zespołu. Surowy eksport GA4 zostaw do audytu tagów; codzienny ROAS niech jedzie z lekkiego, zagregowanego widoku.