BigQuery + Google Ads data pipeline 2026: zbuduj swój hurtownię raportową

Każda poważna operacja Google Ads w końcu wyrasta z platformowego UI i eksportowanych arkuszy. Pytania raportowe, które najbardziej się liczą — jaki jest mój prawdziwy koszt na closed-won deal, które kampanie napędzają sesje konwertujące 60 dni później, jak Google, GA4 i CRM się uzgadniają — nie mogą być odpowiedziane wewnątrz Google Ads, bo dane żyją w trzech różnych systemach. Hurtownia raportowa BigQuery to jak zespoły analityki rozwiązują to w 2026, a Google dramatycznie ułatwił wejście dzięki zarządzanemu Data Transfer Service.

To praktyczny tutorial dla analityków i inżynierów. Zbudujemy pipeline od początku do końca: utworzymy projekt Cloud, skonfigurujemy Data Transfer Service, włączymy eksport GA4, zaprojektujemy warstwowy schemat, połączymy przychody CRM po GCLID, zaplanujemy codzienne odświeżenie, postawimy Looker Studio na górze i utrzymamy koszty BigQuery pod kontrolą. Zakładamy płynność SQL i podstawową znajomość Google Cloud. Jeśli pochodzisz z fundamentu tracking-first, nasz przewodnik konfiguracji GA4 i importu konwersji jest właściwym prerequisitem.

Dlaczego budować pipeline BigQuery dla Google Ads

UI Google Ads jest świetne do zarządzania kampaniami i słabe do analizy cross-system. Trzy strukturalne limity popychają zespoły w stronę hurtowni.

Po pierwsze, luka przychodów. Google Ads wie, ile wydał i ile konwersji policzył, ale nie zna Twojego pipeline'u closed-won, długości cyklu sprzedaży ani wskaźnika zwrotów. Lead, który Google liczy jako zdarzenie konwersji 0 euro, może stać się dealem enterprise 40.000 euro dziewięć miesięcy później. Bez łączenia przychodów CRM z powrotem do kliknięcia optymalizujesz pod wolumen konwersji zamiast zysku — najczęstsza i najdroższa awaria raportowania w B2B PPC.

Po drugie, mieszanina cross-channel. Nowoczesna akwizycja działa przez Google, Meta, LinkedIn i więcej. Każda platforma raportuje w swoim walled garden ze swoją atrybucją. Hurtownia to jedyne miejsce, gdzie można zbudować pojedynczy widok mieszany, w którym wydatki i wyniki z każdego kanału siedzą w tej samej tabeli ze spójnymi definicjami. Nasz przewodnik atrybucji cross-channel pokrywa metodologię; BigQuery to gdzie ją wdrażasz.

Po trzecie, sufit analizy. Testowanie inkrementalności, modelowanie customer lifetime value, retencja kohortowa i marketing mix modeling wszystkie wymagają danych na poziomie zdarzenia i historycznych, których UI po prostu nie wystawia. Hurtownia z dwoma-trzema latami czystej historii to substrat, na którym siedzi każda zaawansowana technika pomiarowa. Własny open-source MMM framework Google, pokryty w naszym przewodniku Meridian, czyta bezpośrednio z BigQuery.

Ekonomia jest korzystna. Data Transfer Service jest darmowy. Pierwsze 10 GB storage'u BigQuery i pierwszy 1 TB przetwarzania zapytań każdego miesiąca są darmowe, a poza tym storage kosztuje około 0,02 euro za GB miesięcznie, a zapytania około 5-6 euro za TB zeskanowany. Dobrze zbudowana hurtownia pojedynczego konta rzadko przekracza 150 euro/miesiąc i często działa poniżej 50. Wobec kosztu źle alokowanych wydatków reklamowych to błąd zaokrąglenia. Inwestycja to czas inżynierski, nie rachunki chmurowe.

Wypłata jest trwała. Gdy pipeline istnieje, każde nowe pytanie staje się zapytaniem SQL zamiast ręcznego ćwiczenia export-and-pivot. Raporty same się odświeżają. Nowe kanały wpinają się w ten sam schemat. A fundament danych się składa: im dłużej hurtownia działa, tym cenniejsza staje się jej historia dla modelowania.

Przegląd architektury i trzy źródła danych

Architektura referencyjna to warstwowa hurtownia zasilana przez trzy źródła, transformowana przez zaplanowany SQL i wyświetlana w Looker Studio.

Trzy źródła danych:

Warstwowa konwencja datasetów utrzymuje hurtownię łatwą w utrzymaniu i kosztowo efektywną:

• raw_google_ads — nietknięte eksporty DTS. Nigdy nie odpytywane bezpośrednio przez raporty. Traktuj jako niezmienną strefę lądowania.
• surowy eksport GA4 — tabele events_, które GA4 ląduje w swoim datasecie, partycjonowane po dacie zdarzenia.
• staging — oczyszczone, ustandaryzowane widoki i tabele. Micros cast na walutę, kolumny przemianowane, duplikaty okna odświeżania usunięte, date spine i mapowanie kont połączone.
• reporting — wyselekcjonowane, zdenormalizowane tabele zbudowane specjalnie pod dashboardy. To jedyna warstwa, której dotyka Looker Studio.

Ta separacja ma znaczenie z trzech powodów: izoluje surowe dane, więc bug transformacji nigdy nie zepsuje źródła, koncentruje drogie joiny w zaplanowanych buildach zamiast per-dashboard-refresh, i daje Ci czystą granicę uprawnień — analitycy dostają dostęp do odczytu tylko reporting.

Orkiestracja jest celowo prosta. Data Transfer Service i eksport GA4 działają na harmonogramie Google, lądując świeże dane każdego ranka. Kilka godzin później scheduled queries BigQuery przebudowują tabele staging i reporting. Looker Studio czyta wynik. Bez zewnętrznego orkiestratora, bez serwerów, bez kontenerów. Możesz później przejść na dbt i Cloud Composer, ale nie potrzebujesz ich, by zacząć, a dodawanie ich przedwcześnie to over-engineering.

Uwaga o regionach: wybierz jedną lokalizację BigQuery (EU multi-region dla europejskiej rezydencji danych) i używaj jej dla każdego datasetu. Cross-region zapytania nie są dozwolone, więc niedopasowanie lokalizacji między Twoim datasetem DTS a CRM zepsuje joiny. Zdecyduj raz, z góry.

Konfiguracja Google Ads Data Transfer Service

Data Transfer Service (DTS) to fundament, i to naprawdę kilka kliknięć konfiguracji plus oczekiwanie na backfill.

Wymagania wstępne:

• Projekt Google Cloud z włączonym billingiem
• BigQuery API i BigQuery Data Transfer API włączone
• Konto Google z dostępem do odczytu do docelowego konta Google Ads (lub MCC)
• Customer ID konta Google Ads (10 cyfr, bez myślników)

Kroki konfiguracji:

1. W konsoli BigQuery otwórz Data transfers i kliknij Create transfer.
2. Wybierz Google Ads jako źródło.
3. Nazwij transfer, ustaw harmonogram na codzienny i wybierz czas uruchomienia wczesnym rankiem.
4. Ustaw destination dataset na raw_google_ads.
5. Wprowadź Customer ID — użyj MCC ID, aby ściągnąć wszystkie konta podrzędne w jednym transferze.
6. Skonfiguruj okno odświeżania (liczbę dni wstecz, które DTS ponownie pobiera przy każdym uruchomieniu), aby uchwycić backfill konwersji i późną atrybucję.
7. Uwierzytelnij się kontem mającym niezbędny dostęp Google Ads i zapisz.

DTS utworzy zestaw tabel w raw_google_ads — campaign, ad group, ad group criteria (keywords), conversions i więcej — każda sufiksowana datą lub partycjonowana, w zależności od tabeli. Nazewnictwo idzie za udokumentowanym schematem Google; trzymaj tę dokumentację otwartą jako referencję, bo nazwy kolumn są werbose i tabele stat oddzielają metryki od atrybutów.

Uruchom backfill natychmiast. Świeży transfer ciągnie tylko do przodu od dziś. Aby uzyskać historię, uruchom ręczny backfill na ostatnie 12 miesięcy (lub tak daleko wstecz, jak potrzebujesz i jak konto obsługuje). Backfille działają jako seria codziennych jobów i mogą trochę potrwać dla długich zakresów, ale muszą się uruchomić tylko raz.

Zwaliduj pierwszy ładunek. Po zakończeniu początkowego uruchomienia sprawdź zdrowy rozsądek: zsumuj koszt (w micros, potem podziel przez 1.000.000) za niedawny tydzień i porównaj z UI Google Ads dla tego samego okna. Małe rozbieżności są normalne z powodu okna odświeżania atrybucji i granic stref czasowych, ale sumy powinny być bliskie. Jeśli są dziko poza, sprawdź, czy wybrałeś właściwy customer ID i strefę czasową.

Rozważania MCC. Transfer MCC taguje każdy wiersz jego customer ID. To potężne dla agencji, ale mnoży wolumen danych. Z wieloma kontami partycjonowanie po dacie i klastrowanie po customer ID w warstwie staging przestaje być nice-to-have i staje się różnicą między 40-euro a 400-euro miesięcznym rachunkiem. Planuj to od pierwszej tabeli staging.

Projektowanie schematu BigQuery i warstwy staging

Surowe tabele DTS są dokładne, ale niewygodne: koszty w micros, kryptyczne nazwy kolumn, oddzielne tabele stat i atrybutów, i nakładanie się okna odświeżania. Warstwa staging naprawia to wszystko raz, aby downstream zapytania pozostały czyste.

Kluczowe transformacje staging:

-- staging.campaign_performance_daily
CREATE OR REPLACE TABLE staging.campaign_performance_daily
PARTITION BY date
CLUSTER BY customer_id, campaign_id AS
SELECT
  _DATA_DATE                         AS date,
  customer_id,
  campaign_id,
  campaign_name,
  metrics_cost_micros / 1000000      AS cost,
  metrics_impressions                AS impressions,
  metrics_clicks                     AS clicks,
  metrics_conversions                AS conversions,
  metrics_conversions_value          AS conversion_value
FROM `raw_google_ads.ads_CampaignBasicStats_*` s
JOIN `raw_google_ads.ads_Campaign_*` c USING (campaign_id)
WHERE _DATA_DATE = c._DATA_DATE;

Specyfika nazw tabel zmienia się wraz z wersją schematu DTS, ale wzorzec trzyma: cast micros, przemianuj na czytelne kolumny, joinuj stats do atrybutów, partycjonuj po dacie, klastruj po kolumnach, po których najczęściej filtrujesz.

Deduplikacja okna odświeżania. Ponieważ DTS ponownie pobiera dni wstecz, ta sama data może pojawić się w wielu ładowaniach snapshot. Wybierz najnowszy snapshot per logiczna data za pomocą window function lub czytając partycję, którą DTS oznacza jako bieżącą. Pominięcie tego kroku podwójnie liczy wydatki w najświeższych dniach — subtelny bug, który eroduje zaufanie do hurtowni.

Tabele pomocnicze, których będziesz potrzebować:

Partycjonowanie i klastrowanie nie są opcjonalne. Partycjonuj każdą zmaterializowaną tabelę staging i reporting po date. Klastruj po customer_id i campaign_id (lub czymkolwiek, po czym filtrują Twoje raporty). To dźwignia kontrolująca koszt: zapytanie za ostatni miesiąc na tabeli partycjonowanej po dacie skanuje tylko bajty ostatniego miesiąca, nie trzech lat historii. Różnica to często 30x na dojrzałej hurtowni.

Views versus tabele. Dla lekkich transformacji widoki są w porządku i nie ponoszą kosztu storage'u — ale ponownie skanują dane źródłowe przy każdym odczycie. Dla wszystkiego, co jest odpytywane wielokrotnie przez dashboardy, zmaterializuj partycjonowaną tabelę przez scheduled query. Zasada kciuka: tania transformacja czytana raz to widok; droga transformacja czytana wiele razy to zmaterializowana tabela.

Trzymaj warstwę staging nudną i deterministyczną. Powinna wykonywać dokładnie jedną pracę — zamienić surowe eksporty DTS i GA4 w czyste, dobrze otypowane, partycjonowane bloki konstrukcyjne — aby warstwa reporting mogła skupić się na ciekawych joinach.

Łączenie danych GA4, Google Ads i CRM

To tutaj hurtownia zarabia na siebie. Trzy źródła, połączone poprawnie, odpowiadają na pytania, na które żadna pojedyncza platforma nie potrafi.

GCLID to kręgosłup atrybucji przychodów. Gdy ktoś klika reklamę Google z włączonym auto-tagowaniem, Google dokłada GCLID do URL landing page. Uchwyć go w ukrytym polu formularza, utrwal go w CRM przy leadzie, i staje się kluczem łączącym kliknięcia Google Ads z przychodem closed-won.

-- reporting.campaign_to_revenue
SELECT
  ga.date,
  ga.campaign_name,
  ga.cost,
  ga.conversions,
  COUNT(DISTINCT crm.deal_id)        AS deals_closed,
  SUM(crm.closed_won_amount)         AS crm_revenue,
  SAFE_DIVIDE(ga.cost, SUM(crm.closed_won_amount)) AS cost_to_revenue_ratio
FROM staging.click_with_gclid ga
LEFT JOIN crm.deals crm
  ON ga.gclid = crm.gclid
GROUP BY ga.date, ga.campaign_name, ga.cost, ga.conversions;

LEFT JOIN jest celowy: niedopasowane wydatki muszą pozostać widoczne. Jeśli zrobisz inner-join, każde kliknięcie bez dopasowanego deala po cichu znika, a Twoja matematyka cost-per-revenue sama sobie schlebia. Trzymaj wszystkie wydatki w wyniku i traktuj match rate jako własną metrykę zdrowia.

Łączenie GA4 dla głębi behawioralnej. Eksport GA4 ląduje wiersze na poziomie zdarzenia z zagnieżdżonymi event_params. Unnest je, aby odzyskać kampanię, jakość sesji i landing page, potem agreguj do granularności, której potrzebujesz.

-- staging.ga4_sessions (kampania i landing page odzyskane z event_params)
SELECT
  PARSE_DATE('%Y%m%d', event_date) AS date,
  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'campaign') AS campaign,
  COUNTIF(event_name = 'session_start') AS sessions,
  COUNTIF(event_name = 'sign_up')       AS signups
FROM `analytics_XXXXXX.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260101' AND '20261231'
GROUP BY date, campaign;

Zawsze ograniczaj _TABLE_SUFFIX GA4 do zakresu dat — tabele events są duże, a nieograniczony wildcard scan to klasyczna pułapka kosztowa GA4.

Ładowanie CRM. Wprowadź deale do BigQuery cokolwiek pasuje do Twojego stacka: zarządzany konektor jak Fivetran, zaplanowana Cloud Function uderzająca w API Twojego CRM, lub nocny ładunek CSV. Minimalne kolumny to deal ID, GCLID, kwota closed-won, data zamknięcia i etap. Odświeżaj codziennie, aby przychody pozostały aktualne.

Gdy pokrycie GCLID jest słabe, wskaźniki dopasowania cierpią, a przychody wyglądają na zaniżone. Upstream poprawki to enhanced conversions i import konwersji offline, obie poprawiają, jak niezawodnie kliknięcia wiążą się z powrotem z wynikami — zobacz nasz przewodnik konfiguracji enhanced conversions. Jako fallback w hurtowni join oparty na UTM odzyskuje niektóre niedopasowane wiersze, ale traktuj go jako uzupełnienie o niższej pewności, nie zastępcę GCLID.

Wynikiem tej sekcji jest pojedyncza zjednoczona tabela niosąca wydatki, konwersje Google, engagement GA4 i przychody CRM obok siebie — tabela, na której zbudowany jest każdy znaczący raport PPC.

Scheduled queries i codzienne odświeżenie

Z logiką staging i reporting napisaną, zautomatyzuj codzienne budowanie, aby hurtownia sama się utrzymywała.

Natywne scheduled queries to właściwe narzędzie startowe. BigQuery pozwala zaplanować dowolne polecenie SQL na cron-like cadence bez dodatkowego kosztu poza przetwarzaniem zapytania, które zużywa. Najpierw zaplanuj build staging, potem build reporting, oba w czasie kilka godzin po tym, jak DTS i eksport GA4 typowo kończą się rano. Ta kolejność zapewnia, że każda warstwa czyta świeże dane upstream.

Użyj właściwej semantyki zapisu:

Dla większości raportowania PPC przebudowywanie N ostatnich partycji z WRITE_TRUNCATE ograniczonym do tych partycji to najprostsze poprawne podejście — naturalnie wchłania backfill okna odświeżania DTS bez duplikowania starszych danych.

Dodaj kontrolę świeżości. Małe scheduled query, które porównuje max datę w każdej tabeli źródłowej z dziś i pisze alert (lub głośno failuje), wyłapuje silent failure mode, gdzie DTS lub eksport GA4 pomija dzień, a Twoje dashboardy po cichu pokazują nieaktualne liczby. Ten pojedynczy guard zapobiega najbardziej zawstydzającej klasie incydentu raportowego.

-- monitoring.freshness_check
SELECT
  'google_ads' AS source,
  MAX(date)    AS latest_date,
  DATE_DIFF(CURRENT_DATE(), MAX(date), DAY) AS days_behind
FROM staging.campaign_performance_daily
HAVING days_behind > 1;

Jeśli to zapytanie zwróci wiersze, coś upstream jest nieaktualne i wymaga uwagi.

Kiedy przejść na dbt. Scheduled queries komfortowo obsługują hurtownię pojedynczego konta przez długi czas. Przejdź na dbt, gdy logika transformacji przekracza około 10-15 współzależnych modeli, gdy chcesz automatycznych testów i dokumentacji na poziomie kolumny, lub gdy kilku analityków edytuje ten sam SQL i potrzebują version control i lineage. dbt orkiestrowany przez Cloud Composer (zarządzane Airflow) to powszechny następny krok — ale przyjmij go, bo złożoność tego wymaga, nie dlatego że jest modny.

Dyscyplina backfilla. Gdy zmieniasz transformację, uruchom ją ponownie przez historię, aby stare partycje odzwierciedlały nową logikę. Sparametryzuj swoje scheduled queries po dacie, aby ten sam SQL obsługiwał zarówno codzienne inkrementalne uruchomienie, jak i ręczny pełny backfill.

Raportowanie Looker Studio i zarządzanie kosztami

Hurtownia jest użyteczna tylko wtedy, gdy ludzie potrafią ją czytać, a Looker Studio to naturalny front-end dla BigQuery.

Podłącz się tylko do wyselekcjonowanych tabel. Skieruj każde źródło danych Looker Studio na dataset reporting, nigdy na surowe eksporty ani szerokie tabele staging. To najważniejsza decyzja kosztowa w całym pipeline. Looker Studio odświeża zapytania na interakcję i na harmonogramie cache; jeśli popularny dashboard odpytuje tabelę pełnej historii niepartycjonowaną, zeskanowane bajty — i rachunek — szybko się składają.

Praktyczny zestaw startowy dashboardów:

• Przegląd executive — mieszane wydatki, konwersje i przychody CRM przez kanały, w trendzie czasowym.
• Przegląd konta — wydajność per-konto dla konfiguracji MCC, używając przyjaznych nazw z account-map.
• Drill-down kampanii — wydatki, CPA, cost-per-revenue i engagement GA4 po kampanii i ad group.

Kontrole kosztów, które faktycznie się liczą:

Monitoruj najdroższe zapytania. Widok INFORMATION_SCHEMA.JOBS wystawia każde zapytanie, kto je uruchomił i ile bajtów przetworzyło. Cotygodniowe spojrzenie na najwięcej konsumujących pokazuje jeden raport lub scheduled query, który po cichu dominuje Twój rachunek, abyś mógł go zoptymalizować — zazwyczaj dodając filtr partycji lub materializując join.

SELECT
  user_email,
  query,
  total_bytes_processed / POW(10, 12) AS tb_processed
FROM `region-eu`.INFORMATION_SCHEMA.JOBS
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
ORDER BY total_bytes_processed DESC
LIMIT 20;

Ustaw budżet billing i alert na projekcie Cloud, niezależnie od tego, jak ostrożny jesteś. To backstop, który zamienia runaway query z niespodzianki na koniec miesiąca w powiadomienie tego samego dnia.

Z wyselekcjonowanymi tabelami, filtrami partycji, BI Engine dla hot dashboardów i cotygodniowym monitoringiem kosztów hurtownia pojedynczego konta wygodnie pozostaje w zakresie 30-150 euro/miesiąc, jednocześnie serwując szybkie, godne zaufania raporty.

Wzorce SQL dla fundamentów inkrementalności i LTV

Hurtownia to nie tylko ładniejsze raportowanie — to substrat dla pracy pomiarowej napędzającej rzeczywiste decyzje budżetowe. Oto fundamentalne wzorce.

Inkrementalność geo-holdout. Testowanie inkrementalności pyta, jakie konwersje by się wydarzyły bez reklam. Hurtownia czyni analizę trywialną, gdy eksperyment geo zostanie uruchomiony: otaguj regiony jako test lub kontrolę, potem porównaj wskaźniki konwersji między dwoma grupami dla okna testowego.

-- lift inkrementalności po grupie regionów
SELECT
  geo_group,
  SUM(conversions) / SUM(sessions) AS conversion_rate
FROM reporting.geo_experiment
WHERE date BETWEEN @test_start AND @test_end
GROUP BY geo_group;

Lift między testem a kontrolą, znormalizowany do wielkości grupy, szacuje inkrementalny wkład. Metodologia i projekt testu żyją w naszym przewodniku testowania inkrementalności; BigQuery to gdzie obliczasz to w skali i uruchamiasz ponownie co kwartał bez ręcznego wysiłku.

Retencja kohortowa i LTV. Modelowanie lifetime value zaczyna się od kohortowania klientów po miesiącu akwizycji i śledzenia przychodów do przodu.

-- miesięczne kohorty akwizycji z kumulowanym przychodem
SELECT
  DATE_TRUNC(first_close_date, MONTH) AS cohort_month,
  DATE_DIFF(revenue_month, first_close_date, MONTH) AS month_index,
  SUM(revenue) AS cohort_revenue
FROM reporting.customer_revenue_monthly
GROUP BY cohort_month, month_index
ORDER BY cohort_month, month_index;

Ta macierz kohort to surowy materiał dla krzywych LTV, analizy okresu zwrotu i wskaźników CAC-do-LTV po kanale akwizycji — metryk, które powinny rządzić alokacją budżetu. Połączone z powrotem z kampanią, która wyprodukowała GCLID każdego klienta, możesz obliczyć LTV po kampanii, nie tylko CPA po kampanii, co jest znacznie lepszym celem optymalizacji. Nasza analiza okresu zwrotu CAC po wertykalnie pokazuje benchmarki, które te zapytania karmią.

Mieszane raportowanie cross-channel. Gdy Meta, LinkedIn i inne kanały lądują w tej samej hurtowni ze spójnymi definicjami, pojedyncze UNION ALL codziennej tabeli każdego kanału, po którym następuje GROUP BY channel z SAFE_DIVIDE(SUM(revenue), SUM(cost)) dla mieszanego ROAS produkuje widok cross-channel, którego żadne UI platformy nie potrafi. Trudna część to spójne definicje, nie SQL.

Input marketing mix modeling. Zaawansowane zespoły karmią hurtownię prosto w MMM. Open-source framework Meridian Google czyta tygodniowo zagregowane wydatki i wyniki — dokładnie ten kształt, który Twoje tabele reporting już produkują. Pojedyncze scheduled query pivotuje codzienne dane w tygodniową macierz kanałów, której oczekuje Meridian, zamykając pętlę od surowych danych kliknięć do statystycznego modelowania budżetu.

Te wzorce to fundamenty, nie gotowe modele, ale to trudna część do strukturalnego ustawienia poprawnie. Z czystymi, połączonymi, partycjonowanymi danymi w BigQuery, nakładanie inkrementalności, LTV i MMM na górę staje się ćwiczeniem analitycznym, a nie koszmarem data-plumbing.

Dla szerszego kontekstu zmian prywatności i tracking, które czynią first-party hurtownię coraz bardziej niezbędną, zobacz nasz przewodnik strategii first-party data i analizę przyszłości bez cookies.

Hurtownia raportowa mówi Ci, dokąd poszły pieniądze; warstwa optymalizacji decyduje, dokąd pójdą dalej. Jeśli chcesz optymalizacji Google Ads opartej na AI, która może działać na sygnałach cost-per-revenue, które Twój pipeline BigQuery wystawia, SteerAds prowadzi darmowy 14-dniowy audyt na kontach Google i Microsoft Ads.

Źródła

• cloud.google.com/bigquery/docs/google-ads-transfer — dokumentacja Google Ads Data Transfer Service
• cloud.google.com/bigquery/docs — dokumentacja BigQuery
• support.google.com/analytics — dokumentacja eksportu BigQuery GA4
• cloud.google.com/looker/docs/studio — dokumentacja Looker Studio
• cloud.google.com/blog/products/data-analytics — blog Google Cloud data analytics

FAQ