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í.
Pokud uvažujete o serverovém měření, dříve nebo později narazíte na otázku, kde ho vlastně rozjet. Stape, vlastní Cloud Run, nebo úplně jiná cesta? Pro někoho dává smysl Stape, pro jiného vlastní Cloud Run v Google Cloud Platform - a právě tomu se budeme věnovat v tomto článku. Projdeme si rozdíly mezi Stape a Cloud Run a detailně projdeme co všechno budete k nasazení na Cloud Run potřebovat. Zaměříme se na věci, které v běžných návodech chybí - jak pojmenovat servery, který region zvolit, kolik stojí provoz, kdy se vyplatí load balancer nebo jak se nenapálit při výběru typu billingu.
Nasadit serverové GTM jde více způsoby. Lze ho rozjet na vlastním fyzickém serveru nebo ve vámi preferovaném cloudu. Nejběžnější jsou dva přístupy - nastavit si manuálně sGTM v rámci služby Cloud Run v Google Cloud Platform (GCP) nebo outsourcovat služby jiné firmy, která nasazení a provoz zařídí za vás, například Stape.
My samozřejmě preferujeme vlastní Cloud Run, protože tím snižujeme závislost na fungování a supportu třetích stran.
Nastavení celého Cloud Run je technicky složitější a navíc cca každý rok vychází update, který celý proces občas změní. Podrobný postup najdete například u Simo Ahava (hlavně jeho kurz v Simmer) nebo na Analytics Mania. V tomto článku projdeme to nejdůležitější a věnovat se budeme hlavně tipům z praxe - z nasazování u klientů.
Serverový kontejner se v GTM zakládá stejně jako webový, ale s důležitým rozdílem - vyžaduje admin práva a při zakládání získáte Container Configuration string, který bude potřeba při zakládání serveru v dalším kroku.
Jedno nebo více serverových GTM?
Můžete mít více frontendových GTM a jedno serverové. Pro ukázku - domena.cz a domena.sk mají každá své frontendové GTM. Protože jejich návštěvnost je nízká a rozdíly mezi weby nejsou velké, lze obě domény namapovat na jeden server, na kterém pojede jedno serverové GTM.
Řešte to spíše s ohledem na organizaci práce - pokud jsou pro každou zemi oddělené týmy, oddělené budgety nebo velké rozdíly v mediálních skriptech, volte 2 servery a 2 sGTM. Musíte pak ale počítat, že zaplatíte dvojnásobek nákladů jen za provoz 2 serverů.
Serverové GTM potřebuje dva oddělené servery - preview a produkci.
Preview server slouží výhradně pro debugování. Nastavuje se na minimum (0–1 instance).
Produkční server je ten, který skutečně zpracovává data. Nastavuje se s vyšším auto-scalingem (1–10 instancí) a má environment proměnnou PREVIEW_SERVER_URL ukazující na preview server.
Oba dva servery se propojí přes Container Config se serverovým GTM.
Při nastavování narazíte na pojmy, které nemusí být na první dobrou jasné. Níže je několik z nich.
Název serveru - název projektu/ klienta + rozlišení na preview/production a pokud je to důležité, tak region, kde si server od Google pronajímáte. V Cloud Run mohou běžet i další služby, tak ať se v tom potom vyznáte. Například server-side-tagging-europe-west1-nazev_projektu-production a server-side-tagging-europe-west1-nazev_projektu-preview.
Region - pokud sbíráte data, která jsou primárně z Čech, je potřeba vybrat region, nabízející serverovou infrastrukturu nejblíže nám, tedy europe-west3 = Frankfurt nebo europe-central2 = Varšava. Pro soulad s regulacemi o ochraně dat je potřeba umístění Evropa a pro minimalizaci nákladů za transport dat ideálně region co nejblíže ČR.
Instance = alokovaná výpočetní kapacita. Kolik požadavků jedna instance zpracuje závisí na dostupné kapacitě CPU. Kolik instancí a jak dlouho běží je to, za co zaplatíte.
Autoscaling - pro většinu webů máme nastaveno 1-10 instancí a bohatě to stačí. Minimálně 1 instance znamená, že 1 instance je vždy připravena a nemusí se startovat . Pokud nastavíte minimum na 0, pak není připravena žádná instance a první request čeká na cold start - pokud vám hodně kolísá návštěvnost, a potřebujete rychle reagovat, toto řešení pro vás není ideální. Pokud mám vyšší návštěvnost a potřebuji rychle odbavovat více požadavků, je dobré mít připraveny 2 instance (min 2 instance). Nicméně to znamená, že platím vždy za 2 instance. Autoscaling neboli škálování znamená, že si server může nastartovat další instance podle potřeby, do max 10 instancí. Z druhé strany - pokud by na vás zaútočil spam traffic, neutratíte více než za provoz 10 instancí. I to však může být drahé, a je dobré mít na toto nastavený alerting. Tomu se budeme věnovat v některém z dalších dílů.
Instance-based vs request-based billing
- při request-based billing platíte pouze za dobu, kdy instance aktivně zpracovává request . Mezi requesty instance 'spí' - CPU nic nedělá a neúčtuje se. Platíte pouze za paměť alokovaných instancí a za CPU jen po dobu aktivního zpracování requestu. Při minimu 2 instances jsou 2 instance připravené a relativně rychle se nastartují, ale pokud by přišla návštěvnost vyžadující více instancí, bude potřeba více času k probuzení než u instance-based a může docházet ke zpoždění odbavování požadavků (request latency) a v extrémním případě zahlcení serveru.
- při instance-based billing platíte za alokované instance, jsou vždy připravené a dokáží rychle reagovat na požadavky z webu.
Pokud je výkon vyšší a neustálý, je výhodnější mít instance neustále připravené (instance-based), pokud návštěvnost kolísá, je výhodnější platit za requesty.
Při instance-based billing stojí při minimum 1 instance cca 45 Kč/den (berte to jen jako orientační údaj), minimum 2 instances stojí 90 Kč - > za měsíc to pak dělá mezi 1 350 Kč - 2 700 Kč. Za to máte relativní jistotu, že váš web zvládne výkyvy návštěv a requesty budou spolehlivě zpracovány.
Při request-based billing můžete v minimu jít na cca 300 Kč, ale při rychlých změnách požadavků na server nemusí tento vždy stíhat.
Debugging - sGTM nemá izolované prostředí jako u frontendového měření, preview requesty fyzicky tečou přes produkční infrastrukturu. Když debugujete, prohlížeč pošle request na váš produkční sGTM endpoint. Request obsahuje hlavičku X-Gtm-Server-Preview - a produkční server podle té hlavičky pozná, že jde o preview request a přepošle ho na preview Cloud Run instanci.
Tedy produkční server request přijme, vyhodnotí hlavičku a přepošle - to znamená že produkční server je vždy minimálně trochu zatížen. Zjistíte to hlavně ve chvíli, kdy zapomenete zavřít debuggovací okno a přijdou vám alerty, že se výrazně zhoršila request latency, tedy rychlost odbavování požadavků serverem.
Application Load balancer - ano nebo ne?
Load balancer vstupní brána na server, je to taková recepce ve firmě. Bez něj firma (rozuměj server) funguje, ale když přijde návštěvník (request) nemáte jak předat informace, co je to za firmu, navést návštěvníka určitým směrem, nebo třeba kam umístit ostrahu v podobě Cloud Armor.
Správně, technicky, je to reverzní proxy - sedí před serverem a přijímá veškerý příchozí provoz. Prohlížeč se připojí na load balancer, který request zpracuje a přepošle dál na správný server. "Reverzní" proto, že na rozdíl od klasické proxy, která chrání uživatele, tato vrstva chrání a řídí přístup k serveru.
Nastavení load balanceru je technicky složitější a stojí nějaké stokoruny měsíčně navíc, ale bez něj přijdete o klíčové výhody serverového měření. Bez vlastní domény (ta se totiž mapuje právě na load balancer) totiž data z frontendu odcházejí na automaticky vygenerovanou adresu typu *.run.app a tím ztrácíte 1st party context: data jsou snadným cílem pro adblockery a Safari zkrátí životnost cookies na maximum 7 dní.
Tedy dá se žít i bez něj, ale za nás rozhodně lépe s ním.
Poznámka: Cloud Run nabízí funkci domain mapping, která by custom doménu umožnila bez load balanceru. V praxi ji ale spíše nelze použít - v evropských regionech kde standardně nasazujeme (Frankfurt, Varšava) není dostupná vůbec, a v regionech kde dostupná je (Netherlands třeba), Google sám označuje tuto funkci jako Preview a nedoporučuje ji pro produkční služby.
Postup v kostce:
Podrobný postup, jak bylo zmíněno výše, Simo Ahava (hlavně jeho kurz v Simmer) nebo Analytics Mania.
Serverová subdoména:
Ideální je vytvořit subdoménu, která není ničím nápadná, tedy ne “tracking.vasedomena.cz” ale třeba “hub” nebo náhodný string. Pokud máte třeba klientskou zónu, která sedí na jiné doméně, je potřeba vytvořit subdomény pro obě vlastní domény, protože hlavní cíl je zachovat 1st party kontext, tedy data z webu posílat na stejnou doménu. Obě pak můžete namapovat na jeden server a spojit jedním serverovým GTM. Ušetříte tím náklady za provoz i nastavení.
Kdy CloudRun nastavit?
Pokud chcete spustit serverové měření teď, potvrďte si serverovou subdoménu a projděte celým procesem výše.
Někdy se může stát, že zároveň upravujete vlastní měření, řešíte s vývojem nastavení DL pushů, nebo čekáte na jiné akce, a ostré serverové měření se spustí třeba až za měsíc. Za rezervaci statické IP adresy a vytvoření load balanceru se platí poplatek cca 400 Kč/měsíčně, bez ohledu na to, zda už jste spustili měření nebo ne. Pozor, ať zbytečně neplatíte náklady na Cloud Run moc brzy.
Test 1 - Ověřte, že doména funguje a SSL certifikát je aktivní
Do prohlížeče zadejte: https://hub.tvadomena.cz/healthy
Pokud vrátí ok - server běží, SSL funguje, load balancer routuje správně.
Pokud vrátí chybu nebo SSL warning - certifikát se ještě provisionuje (může trvat až 24 hodin po nastavení DNS).
Test 2 - Ověřte, že preview server funguje
https://hub.tvadomena.cz/gtm/preview
Mělo by vrátit nějakou odpověď - ne 404.
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.
