Jak dostat data z reklamních systémů do jednoho warehouse, typicky BigQuery? Projdeme si základní architekturu a rozhodování, než se pustíte do exportů dat z Google Ads, Meta Ads, Skliku a dalších.
Nevybavuji si klienta, který by neměl ani jeden reklamní systém. A jakmile jich máte víc, dříve nebo později narazíte na otázku, jak jejich data dostat na jedno místo.
Tento článek otevírá sérii o tom, jak takové pipelines stavíme. V dalších dílech projdu Google Ads, Meta Ads, Sklik a DV360 každý zvlášť, ale několik věcí platí napříč systémy. Architektonické možnosti, identity management, backfill dat a výpočty metrik je lepší vysvětlit na jednom místě a v dalších článcích už se k nim jen odkazovat.
Kód a doplňkové materiály k celé sérii najdete ve public repu pub__BQ-media-pipelines-GCP.
Když chcete dotáhnout data z reklamního systému do BigQuery, máte v principu tři možnosti. Pořadí, v jakém je tu uvádím, odpovídá tomu, jak často je v praxi volíme.
Google poskytuje sadu předpřipravených konektorů přímo v BigQuery. Aktuálně pokrývají Google Ads, Meta Ads, DV360, YouTube a několik dalších služeb. Setup probíhá v GCP.
Kdy to volíme:
Vždycky, když existuje a pokrývá metriky, které potřebujeme. Pro Google Ads je to jasná volba. Pro Meta Ads to bylo dlouhou dobu diskutabilní, nicméně s novou verzí konektoru je nativní řešení rovněž preferované.
Co je třeba vědět:
Každý konektor má svoje specifické limity – refresh window, granularitu, dostupné tabulky… Každý datový transfer má svá specifika a je potřeba na ně při stavění pipelines myslet.
V MeasureDesign jsme měli poměrně rozsáhlý research a ještě rozsáhlejší diskusi o tom, jaký nástroj použít. Keboole hrálo do karet, že má dostupnou komponentu pro Sklik, který většina našich klientů běžně používá. Existují podobné nástroje (Fivetran, Supermetrics, Stitch, Airbyte), ale Keboola se v našem kontextu osvědčila kombinací nižších nákladů, dostatečně širokého katalogu konektorů a slušného UX pro transformační vrstvu.
Kdy to volíme:
Co je třeba vědět:
Cloud Run / Cloud Function, která zavolá API reklamního systému, zpracuje response a zapíše data do BQ. Maximální flexibilita, nezávislost na poskytovateli (nástroje třetích stran), plná kontrola nad schématem.
Kdy to volíme:
Jen pokud není vhodná cesta A nebo B. Důvod není elegance, ale ekonomika. Custom pipeline znamená napsat ji, otestovat ji, monitorovat ji a spravovat ji, když se změní API protistrany. Pro jeden zdroj dat to dává smysl jen tehdy, pokud Keboola ani DTS nestačí a klient je ochoten platit za maintenance.
Praktická výjimka:
File-based zdroje. Pokud reklamní systém posílá data v souborech (CSV) do GCS bucketu, odpadají nevýhody API řešení a custom pipeline s Cloud Run triggerem na file arrival je často nejjednodušší řešení. Tohle je třeba běžné u systému Adjust pro měření mobilních aplikací.
Tahle sekce je nejdůležitější napříč celou sérií. Kdykoliv v dalších článcích uvidíte „nastavíme service account a přiřadíme mu potřebné role“, mrkněte sem.
Většina DTS konektorů při setupu defaultně použije identitu uživatele, který transfer zakládá. Funguje to, výsledné běhy se autentizují pod tímto účtem. Problém přijde v okamžiku, kdy:
Ve všech těchto případech pipeline tiše přestane fungovat. Nepřijde error e-mail (pokud nemáte nastavený alespoň Basic monitoring, notifikace defaultně chodí jen tomu, kdo transfer zakládal, což je ten uživatel, který už nemá k assetu přístup). Data se přestanou stahovat a nikdo si toho nevšimne, dokud někdo neotevře reporting a nezačne se ptát, proč v posledních dvou týdnech nemáme dostupná Google Ads data.
Service account je oproti tomu nezávislá identita. Vlastní ji projekt, ne osoba. Žije, dokud žije pipeline. Spravuje se centrálně, dá se snadno „předat“ a v logu je okamžitě poznat, že akci provedl SA.
SA pro Google Ads nepotřebuje vidět Meta Ads, Sklik ani DV360. Každé oprávnění navíc zvyšuje riziko chyb – pokud SA někdo omylem revokuje nebo nastaví špatně, padne víc pipelines najednou. Doporučená konvence pojmenování:
sa-googleads-<klient>@<projekt>.iam.gserviceaccount.com
sa-meta-<klient>@<projekt>.iam.gserviceaccount.com
sa-dv360-<klient>@<projekt>.iam.gserviceaccount.com
sa-sklik-<klient>@<projekt>.iam.gserviceaccount.com
GCP konzole → IAM & Admin → Service Accounts → Create service account. Pojmenujte dle naming konvence a vyplňte popisek.
JSON klíč nevytvářejte. Pro DTS není potřeba – autentizace se řeší přes IAM impersonaci.
Otevřete dataset pro daný mediální systém → Sharing → Permissions a přidejte SA e-mail (formát sa-googleads-<klient>@<projekt>.iam.gserviceaccount.com) s rolí:
Na úrovni projektu pak SA potřebuje:
GCP konzole → IAM & Admin → Service Accounts → klikněte na vytvořený SA → Principals with access:
Bez tohoto kroku vám DTS UI nedovolí transfer pod SA založit. Pokud uvidíte chybu „permission denied to act as service account", chybí vám tahle role.
Pozor: v některých kontextech (Scheduled Queries, Dataform workflows, Workflows) je potřeba kromě serviceAccountTokenCreator přidat i roles/iam.serviceAccountUser. Pro DTS přes UI postačí Token Creator, ale pokud něco selže s chybou „permission denied to act as“, přidejte i ServiceAccountUser.
Default notifikace DTS chodí na e-mail uživatele, který transfer zakládal. Pokud transfer běží pod SA, tato notifikace de facto nikam nechodí – SA nemá inbox. Je proto nutné nastavit alespoň základní verzi alertingu (k této problematice brzy vyjde další článek).
Většina DTS konektorů funguje jako daily incremental – každý den se přepíše partition pro daný den (a případně refresh window za X dní zpátky). Ve spoustě případů je to dostačující, ale neřeší situace, kdy chceme dostahovat i data za posledních několik měsíců, ne jen od data nastavení transferu.
DTS umí backfill přes UI (Schedule backfill), ale s vážnými omezeními:
Praktické řešení, které u nás funguje: bash skript přes bq CLI, který projde zadané období den po dni, před každým dalším dnem počká, až bude konektor volný, a teprve potom spustí další běh.
Plná verze skriptu s timeoutem na čekání (aby v případě zaseknutého runu neběžel přes noc do nekonečna) je v repu pod DTS_backfill_terminal.bash.
Doporučení z praxe: i s tímto skriptem nepouštět backfill přes velmi dlouhé období naráz. Lepší je rozdělit ho na okna 10–14 dní a v případě potřeby spustit víckrát.
Defaultní hodnoty, které dává Google v UI, jsou skoro vždycky nedostatečné. Pro Google Ads je default 7, my dáváme 14–30. Pro Meta DTS je default pouze 1 den, dle reporting window nastavte klidně i 28. Důvod je attribution late arrival – konverze připsané dnes přes 7d_click okno patří partition staré 7 dní; pokud refresh window pokrývá jen poslední 1–2 dny, tahle data se nikdy nepropíšou.
Napříč sérií pracujeme s vrstvenou architekturou, ale u čistě mediálních dat se většinou pohybujeme na úrovni raw exportů a vrstvy L0 – minimum transformací, jen sjednocení názvů tabulek, ošetření NULL přes IFNULL, přidání konstant (market, platform) a join metadat (názvy kampaní) na performance metriky.
Důležité je, že L0 už zpravidla slouží přímo pro reporting – pro samostatný pohled na jednu platformu není potřeba stavět nic dalšího. Vyšší vrstvy přicházejí na řadu až ve chvíli, kdy media data potřebujeme více transformovat nebo je napojit na další zdroje: L1 (staging/normalized) sjednocuje data napříč platformami do společného modelu (stejné názvy sloupců, datové typy, měny…) a řeší věci jako currency conversion nebo deduplikaci; L2 (mart/reporting) je pak agregovaná vrstva pod konkrétní report nebo dataset kombinující víc zdrojů.
Po prvním běhu vždy ověřte, že čísla v BQ sedí s tím, co ukazuje rozhraní zdrojové platformy.
Nestačí porovnat jen celkový spend. Validujte na úrovni, kterou pak reálně reportujete: spend, impressions, clicks per kampaň per den. Agregát může sedět náhodou (dvě chyby se vyruší), zatímco rozpad odhalí systematický posun.
Validujte na datech starších než cca 14 dní (ideálně více než 30 dní). Čerstvá data (poslední dny) většina reklamních systémů ještě dodatečně upravuje – úprava konverzí, korekce, pozdější agregace – takže rozdíl mezi BQ a UI na včerejších datech nemusí znamenat chybu v pipeline, jen to, že čísla ještě nejsou finální. Data starší než dva týdny už jsou víceméně ustálená (aspoň co se impresí, spendů a prokliků týče, konverze se ještě mohou měnit), takže případný nesoulad je spolehlivější signál skutečného problému.
Časové pásmo a měna jako první podezřelí. Většina nesouladů, které nejsou bug v pipeline, jde na vrub dvou věcí: rozhraní reportuje v jiné timezone než UTC (posun spendu o den) a v jiné měně (MCC měna vs. měna child účtu). Před hledáním chyby v SQL ověřte, že porovnáváte stejnou timezone a stejnou měnu.
Validujte po každé změně schématu, ne jen při setupu. Jednorázová validace na začátku nestačí – když Google/Meta změní schéma nebo přejmenuje sloupec, pipeline může tiše začít tahat jinak. Stojí za to mít validaci jako opakovatelný krok, ne jednorázový. Je také dobré čas od času (třeba jednou měsíčně) porovnat základní metriky z rozhraní vůči exportům.
Tento článek je obecný framework pro práci s mediálními daty v GCP. V dalších dílech si ukážeme konkrétní nastavení a specifika jednotlivých platforem.
Jak dostat data z reklamních systémů do jednoho warehouse, typicky BigQuery? Projdeme si základní architekturu a rozhodování, než se pustíte do exportů dat z Google Ads, Meta Ads, Skliku a dalších.
Třetí díl seriálu o first-party datech bude opět hodně technický – ukážeme si, jak zkontrolovat, že data správně odcházejí do jednotlivých systémů a dělají to, co mají. Podíváme se na odchozí hity v DevTools i na kontrolu přímo v reklamních platformá
Detailní průvodce sessionizací GA4 BigQuery exportu – od identifikace session a spolehlivého řazení eventů po dva atribuční modely (First Event Available a Session Start), jejich limity a validaci shody mezi nimi.
Nahlédněte do našeho řešení zálohování ClickUpu. Automatické exporty, GitHub repozitář a praktický postup, jak mít firemní data pod kontrolou.
Naučte se, jak nasadit serverový GTM na Cloud Run. Porovnáme Stape s vlastním řešením, vysvětlíme náklady a typy účtování a ukážeme, jak se vyhnout častým chybám při nastavení.
Kompletní technický průvodce sběrem first-party dat přes dataLayer, jejich normalizací, hashováním a odesíláním přes server-side GTM do Google Ads a Meta.
Testovali jsme ClickUp MCP pro management úkolů za pomoci AI. Zjistěte víc o praktických limitech, bezpečnostních omezeních a pro koho se tento nástroj hodí.
Naučte se jak first-party data zlepšují výkon kampaní. Základní příručka pro rozšíření konverze a pokročilý matching.
Zjistěte jak jsme migrovali 250 mediálních tagů (Facebook CAPI, Google Ads, Sklik, Bing) na server-side GTM. Praktické tipy, návody a zkušenosti.
Pokročilé workshopy digitální analytiky pro agenturní týmy. BigQuery, server-side tracking, správa souhlasů a marketingové datové sklady v praxi.
Ženy v analytice se často potýkají s imposter syndromem, přestože vynikají v práci s detailem i datovém storytellingu. Přidejte se ke komunitě Data Sisters.
Naučte se, jak přenést historická data z Google Analytics 4 do nového projektu v BigQuery pomocí Data Transfer Service. Podrobný návod krok za krokem se screenshoty.
Reshoper poradenská zóna a několik hodin konzultací pro návštěvníky veletrhu – letos v příjemných prostorách Křižíkových pavilonů na Výstavišti.
48 hodin vývoje aplikace s AI na hackathonu #HackYourWeekend v Brně. Od nápadu po nasazení pomocí Claude Code, měření přes BigQuery a získané zkušenosti.
6. 9. se v prostorách Brněnského Gen konal další ročník MeasureCamp - naší oblíbené komunitní akce. Potěšilo nás, že MeasureCampu se letos zúčastnilo 74 žen.
Postřehy z víkendového PPC kempu: legální cookieless tracking, pokročilý Consent Mode, Facebook konverze bez souhlasu a export Google Ads do BigQuery.
Výpočet dat Velikonoc v BigQuery pomocí algoritmu Computus. SQL skript generuje data Velikonoční neděle, Velkého pátku a Velikonočního pondělí pro analýzu dat z GA4.
Přednáška o integraci GA4 s BigQuery na akci Visibility Digital. Praktické ukázky využití od IKEA, Shoptetu, McDonald’s a České spořitelny.
80minutový podcast o digitální analytice pro e-commerce: metriky v GA4, náklady na server-side tracking, přínosy BigQuery a vyhodnocování kampaní.
Naučte se využívat export Google Ads do BigQuery pro získávání byznysových insightů. Kombinujte jej s daty z GA4 a CRM, řešte atribuční výzvy a zlepšete reporting.
Data retention v GA4 určuje, jak dlouho budou k dispozici informace o uživatelích a událostech. Prodlužte si dobu uchovávání až na 14 měsíců.
Poslední květnový den jsme strávili s týmem neziskové organizace Tereza a věnovali se základům Google Analytics 4 pro jejich program Učíme se venku.
Přednáška o nových možnostech e-commerce analytiky s využitím GA4, BigQuery a Google Cloud Platform pro maximalizaci hodnoty dat a výkonnosti kampaní.
Naučte se pracovat s raw daty z GA4 v BigQuery a Google Cloud Platform. Materiály z workshopu, SQL dotazy a praktické příklady z Marketing Festivalu 2024.
Vojta se v MeasureDesign věnuje vývoji technických a datových řešení, která mají být nejen funkční, ale i dobře použitelná v praxi. Baví ho propojovat webový vývoj, automatizaci a práci s daty tak, aby věci dávaly smysl jak z pohledu uživatele, tak z pohledu technického fungování na pozadí. Nejvíc ho těší moment, kdy se podaří složit komplexnější problém do čistého a spolehlivého řešení.
Jirka pracuje v marketingu přes 10 let a pokud existuje něco, co ho baví více než čísla sama, tak je to jejich propojování. Miluje matematiku a datovou analytiku a protože rád zkoumá i zdrojové kódy, dokáže se hravě domluvit i s programátory jejich jazykem. V MeasureDesign se specializuje na napojování nových datových zdrojů – vytváří vlastní konektory pomocí Pythonu, testuje kvalitu dat a zkoumá, co všeho by se dalo propojit, aby to mělo význam pro business. S Looker Studiem je jako ryba ve vodě a velkou zkušenost má také s vyhodnocováním PPC kampaní.
Lenka se k MeasureDesign připojila na konci roku 2025 s bohatými zkušenostmi z PPC marketingu, kde dlouhodobě pracovala s Google Ads, Meta Ads a dalšími reklamními systémy. Právě při řízení kampaní ale opakovaně narážela na tentýž problém – špatně nebo nedostatečně nastavenou webovou analytiku, která znemožňovala efektivní optimalizaci. To ji vedlo k tomu, že se analytice začala věnovat nejdřív z nutnosti, postupně však zjistila, že ji baví víc než samotné reklamy. Dnes se zaměřuje především na implementaci webové analytiky a datových řešení, která firmám zajišťují kvalitní a spolehlivá data pro strategické rozhodování i výkonný marketing. Část PPC projektů si ponechává – jednak proto, že ji stále baví, ale hlavně aby zůstala v kontaktu s realitou mediálních systémů a skutečnými potřebami klientů.
Marťa se k MeasureDesign připojila v roce 2025 během studia webových aplikací. Fascinuje ji, jak rychle se vyvíjí svět umělé inteligence, a proto se zaměřila na výzkum velkých jazykových modelů. Ve firmě pomáhá integrovat AI do každodenní práce – tak, aby byla rychlejší, efektivnější a zároveň dostupná pro všechny členy týmu. Nejvíc ji baví hledat způsoby, jak AI využít prakticky a přetavit nové technologie v užitečné nástroje.
Markéta začínala v marketingu, ale pak přišla mateřská – a s ní nekonečný chaos. Potřebovala si zachovat aspoň zbytky zdravého rozumu, a tak se vrhla na data. Čísla totiž nekřičí, nerozsypávají křupíky do klávesnice a dávají aspoň nějaký smysl. V Engeto Academy prošla kurzem datové analytiky, kde se spřátelila se SQL, Power BI, Excelem a Pythonem a začala hledat vzorce i mimo dětské omalovánky. Dnes v MeasureDesign pomáhá klientům zjistit, co jim jejich čísla doopravdy říkají.
Blanka se stala součástí našeho týmu v roce 2024 a od té doby má na starosti oblast back office, včetně fakturace a administrativních úkolů. Využívá své zkušenosti z České pošty a vzdělání v oboru finančního managementu, aby zajistila hladký chod všech procesů. Ve volném čase se věnuje svým dvěma dětem, s nimiž ráda cestuje, a zároveň si užívá práci na zahrádce, kde nachází svůj odpočinek.
Do MeasureDesign nastoupila v roce 2023 a specializuje se na implementaci měření a reporting. Největší radost jí dělá moment, kdy se po všech nastaveních a testech konečně rozběhnou první data. Naopak největší výzvou jsou nečekané (a často nezadokumentované) změny od Google – chvíle, kdy se z analytika stává paranormal behaviour expert. 👻 Byla členkou našeho týmu do léta 2026.
Anička má více jak 7 let zkušeností z agenturního prostředí, kde spravovala pro klienty reklamní kampaně na sociálních sítích, nejradši pro obsahové weby. Chtěla získat trochu větší pohled nejen na kampaňová data, a tak více směřovala svou práci k webové analytice. K našemu týmu se přidala v roce 2022 a nyní se zaměřuje na datovou analytiku, kde s využitím GA4, BigQuery, Looker Studia a dalších nástrojů může propojovat a analyzovat data ještě víc do hloubky a přinést klientům zajímavé analýzy i podklady pro business rozhodování. Anička byla členkou našeho teamu do roku 2026.
Klára je ve firmě od roku 2019. Věnuje se hlavně webové analytice, ale nezalekne se ani práce s daty v BigQuery. Nejvíc ji baví, když může klienta provést od definování jeho potřeb přes implementaci měření až k výsledné vizualizaci dat. Až podezřele velkou radost jí dělá pohled na hezky přehledný GTM kontejner nebo report plný užitečných dat.
Vašek se již více než 15 let věnuje digitální analytice – od nastavování měření po uložení, vizualizaci a interpretaci dat. Firmám pomáhá mít v datech pořádek a umět je naplno využít. Věnuje se primárně datům z digitálních platforem jako jsou weby, aplikace, klientské zóny apod. a propojování těchto dat s dalšími firemními daty jako jsou mediální a zákaznická data. Po letech na volné noze spoluzaložil analytické studio MeasureDesign, kde kromě analytických projektů a školení na míru vzdělává nové analytičky a analytiky.
Zuzčina kariéra vedla přes řízení inovací a výzkumu v korporátu, vedení “wom” (word of mouth) projektů do digitální agentury, kde projektově řídila tvorby webových stránek. Zuzka je ale dost zvědavá a potřebovala vědět, jak web funguje, když je vypuštěn do světa. To ji motivovalo ke studiu webové analytiky, a následně přivedlo k osudové spolupráci s Vaškem a v roce 2019 spolu založili firmu.
