Google Tag Gateway přes Cloudflare — podrobný návod

Stručně: co z tohoto návodu získáte

• Pro koho: e-shopy, které už mají doménu na Cloudflare.
• Čas potřebný: 10–15 minut, bez zásahu vývojáře.
• Výsledek: +11–25 % získaných konverzí v Google Ads a GA4, zdarma.

1. Co je Google Tag Gateway a proč to potřebujete

Google Tag Gateway (GTG) je bezplatná služba od Googlu ve spolupráci s Cloudflare, spuštěná v květnu 2025. Funguje jako „průchozí proxy”, která zajistí, aby skripty Google Analytics 4 a Google Ads byly doručovány přes vaši vlastní doménu místo googletagmanager.com nebo google-analytics.com.

Proč je to důležité

Dnes přibližně 15–30 % e-commerce návštěvníků má nainstalovaný blokátor reklam (uBlock Origin, AdBlock Plus, Brave Shields), který blokuje skripty z domén Googlu. Safari na zařízeních iOS navíc omezuje cookies třetích stran na 7 dní.

Výsledek: ztráta 15–40 % konverzí v Google Ads i GA4 → reklamní algoritmy optimalizují na neúplných datech → vyšší CPA a nižší ROAS.

✅ Co GTG řeší

• Obchází blokátory reklam — skripty přicházejí z vaší domény, ne z domény Googlu
• Ošetřuje „first-party” kontext pro Safari → skript už není třetí strana
• Průměrný nárůst reportovaných konverzí: +11 % (oficiální data Googlu, medián za duben 2025)
• Naměřený rozsah u agentur: 9–18 %
• Získává zpět 70–85 % ztráty trackingu způsobené ad-blockery

⚠️ Co GTG neřeší

• Facebook/Meta Pixel, TikTok Events API, Pinterest — GTG pracuje pouze s Google ekosystémem
• Transformaci a obohacování dat (to umí pouze plnohodnotný server-side GTM)
• Problémy na straně iOS ATT (ztráta dat z Meta Pixelu na mobilech)
• Safari ITP ořezávání JavaScriptových cookies na 7 dní (cookies stále vytváří gtag.js v prohlížeči)

2. Předpoklady — který scénář je váš?

Před aktivací GTG zkontrolujte, který scénář vás čeká:

Scénář A — doména už je na Cloudflare

Pokud v dash.cloudflare.com vidíte vaši doménu se statusem Active — máte vyhráno. Přejděte rovnou na sekci 4 (aktivace GTG, 10–15 minut).

Scénář B — doména je ještě u jiného registrátora / DNS providera

Tedy běžný stav většiny e-shopů: doména registrovaná přes Subreg / Forpsi / GoDaddy / Namecheap, DNS spravované u registrátora nebo u hostingu. Nejdřív projděte sekci 3 (migrace na Cloudflare, 30–60 minut + 1–24 h čekání), pak teprve sekci 4.

Bez ohledu na scénář — finálně budete potřebovat:

Požadavek	Jak zkontrolovat
Doména na Cloudflare se statusem Active	Cloudflare dashboard → vaše doména → status „Active”
Fungující Google Tag (gtag.js) nebo GTM na webu	Otevřít web → Chrome DevTools → Network → filtr „gtag” → vidíte požadavky?
SSL/HTTPS aktivní	Web se otevírá přes https://
Administrátorský přístup do Cloudflare účtu	Přihlásit se → vidíte sekci „Rules”
Administrátorský přístup do Google Ads a GA4	Pro ověření výsledků
Consent Mode v2 správně nastavený přes CMP	Cookiebot/Usercentrics/OneTrust — v případě pochybností nás kontaktujte

Pokud některá z těchto podmínek není splněna, dejte nám vědět — vyřešíme to před zapnutím GTG.

---

3. Migrace domény na Cloudflare (jen scénář B)

Pokud je vaše doména už na Cloudflare, tuto sekci přeskočte a pokračujte sekcí 4.

Migrace je proces, který má vlastní úskalí — různé registrátory pojmenovávají věci odlišně, některé kroky mají email-confirmation, propagace DNS trvá hodiny. Tato sekce shrnuje univerzální vzor a 5 nejčastějších pastí, na které jsme narazili u našich klientů.

Co budete potřebovat

• Přístup do administrace registrátora domény (kde jste si doménu kupovali)
• Přístup k e-mailu vlastníka domény (registry obvykle posílá potvrzovací e-mail)
• Cca 30–60 minut aktivní práce + 1–24 hodin pasivního čekání na DNS propagaci
• Klid — pokud uděláte 5 pre-flight kontrol z bodu 3.3, web ani e-mail nespadnou

3.1. Vytvořit zónu v Cloudflare (3 minuty)

1. Registrace na cloudflare.com — Free plán stačí pro většinu e-shopů
2. Add a Site → zadejte vaši doménu (bez www) → vyberte Free plan
3. Cloudflare spustí Quick Scan — automaticky importuje DNS záznamy z aktuální zóny

3.2. Zkontrolovat naimportované DNS záznamy (5 minut)

Quick Scan většinou zachytí 90–95 % záznamů, ale ne 100 %. Projděte seznam a ověřte, že je tam vše, co máte v aktuální zóně:

• A / AAAA na apex (samotná doména, IPv4 / IPv6)
• CNAME www (nebo A www) — jinak www.vasedomena.cz nebude fungovat
• MX záznamy — bez nich nebude chodit pošta
• TXT: SPF (v=spf1...), DKIM (_domainkey), DMARC (_dmarc) — bez nich e-maily padnou do spamu
• TXT: google-site-verification, Heureka, Search Console verifikace, Microsoft, Facebook domain verification — cokoliv, co tam dnes máte
• Subdoména: m., shop., admin., api. — všechny, které reálně používáte

Co naopak smazat:

• NS záznamy typu ns.vasregisrator.com v importované zóně — to jsou artefakty starého DNS, po migraci jsou nepotřebné a matoucí

Pokud něco chybí — Add record a doplnit ručně. Vzor zóny si exportujte z aktuálního DNS providera (BIND export) a porovnejte záznam po záznamu.

3.3. Pre-flight kontroly (10 minut) — 5 nejčastějších pastí

Toto jsou kontroly, jejichž opomenutí nám u klientů shodilo web nebo e-mail. Udělejte všech 5 ještě před změnou nameserverů:

1. SSL/TLS Mode = Full (strict)

Cloudflare dashboard → SSL/TLS → Overview → vyberte Full (strict).

NIKDY nenechávejte „Flexible” — láme POST formuláře (login, checkout) a vytváří redirect smyčky. Pokud váš origin server podporuje HTTPS (a v roce 2026 ho podporuje prakticky každý hosting), Full (strict) je správná volba.

2. DNSSEC vypnout v aktuálním DNS

V administraci registrátora najít sekci DNSSEC / DNS Security → vypnout. Pokud byl zapnutý, počkat ~1 hodinu, než DS záznamy v parent registry expirují — teprve potom měnit nameservery.

Quick check v terminálu: dig DS vasedomena.cz +short. Prázdný výstup = OK, můžete pokračovat. Pokud vidíte něco jako 2371 13 2 ABC123... = DNSSEC ještě je aktivní v registry, počkejte.

Proč to je tak důležité: pokud změníte nameservery bez vypnutí DNSSEC, doména může být nedostupná 1–7 dní (resolvery vrátí SERVFAIL), dokud DS záznamy v registry neexpirují. Toto je nejčastější způsob, jak shodit migraci.

3. CAA záznamy zkontrolovat a přenést

V exportu vaší aktuální zóny (BIND export u registrátora) vyhledejte CAA. Pokud existují — přidejte je do Cloudflare DNS ručně (Add record → typ CAA).

CAA záznamy říkají, která Certificate Authority může vydávat SSL certifikáty pro vaši doménu. Bez nich se po migraci může rozbít automatický renewal Let’s Encrypt na origin serveru.

4. Speed Settings — nechat defaulty

Cloudflare dashboard → Speed → Optimization. Defaultní nastavení v roce 2026 jsou bezpečná:

• Rocket Loader: OFF (default na nových zónách) — neaktivovat naslepo, může lámat React/Vue aplikace
• Auto Minify: deprecated, není potřeba řešit
• Brotli: auto-on, není potřeba řešit
• Polish: vyžaduje placený plán, default Disabled

Neaktivujte Polish / Mirage / Rocket Loader bez testu na staging — mohou změnit chování JS/CSS způsobem, který shodí konkrétní funkčnost vašeho webu.

5. Proxy (oranžový vs šedý mráček) — rozhodnutí pro každý záznam

Každý A/AAAA/CNAME záznam má volbu Proxied (🟠 oranžový) nebo DNS only (☁️ šedý):

• apex (root) + www → 🟠 Proxied (získáte CDN, WAF, bot mitigation, GTG — toto je proč vůbec migrujete)
• wildcard *. nebo specifické subdomény (admin, mail, ftp) → ☁️ DNS only — tyto často mají whitelist origin IP, proxy by to rozbila
• MX záznamy → vždy DNS only (Cloudflare netuneluje SMTP)

Pokud si nejste jistí — zapněte 🟠 Proxied jen na apex a www, vše ostatní nechte ☁️ DNS only. Po úspěšné migraci po jednom zapínejte oranžovou na další subdomény a testujte.

3.4. Změna nameserverů u registrátora (5 minut + e-mail confirmation)

V Cloudflare dashboard, pod sekcí Overview, najdete 2 přidělené nameservery (vypadají jako xxx.ns.cloudflare.com). Tyto 2 hodnoty zkopírujte.

V administraci vašeho registrátora:

1. Najít sekci pro nameservery — pojmenování se liší: „Nameservers”, „DNS Settings”, „Změnit nameservery”, „NSSET” (.cz registry), „Manage DNS”, „Edit nameservers”
2. Smazat / nahradit všechny aktuální nameservery
3. Vložit 2 nameservery od Cloudflare
4. Uložit / Save / Submit

⚠️ E-mail confirmation — častá past

Mnoho registrátorů (zejména .cz přes CZ-NIC, ale i mezinárodní jako Namecheap, GoDaddy) odešle potvrzovací e-mail na adresu vlastníka domény uvedenou ve WHOIS. Bez kliknutí na potvrzovací odkaz se změna neaplikuje — objednávka zůstane viset ve stavu „New” / „Pending” 7–14 dní a pak vyprší.

Pokud nemáte přístup k e-mailu vlastníka — domluvte se s klientem, ať vám e-mail přepošle, nebo ať na odkaz klikne sám.

3.5. Počkat na status Active (5 minut — 24 hodin)

DNS propagace není deterministická. Obvykle proběhne 5–30 minut, výjimečně se táhne až 24–48 h (záleží na TTL původních nameserverů a chování konkrétních resolverů).

Quick check v terminálu:

dig NS vasedomena.cz +short

Pokud výstup obsahuje vaše Cloudflare NS (např. diva.ns.cloudflare.com), propagace u vás proběhla.

V Cloudflare dashboard:

• Klikněte „I updated my nameservers” — Cloudflare provede vlastní kontrolu
• Když Cloudflare detekuje změnu, přijde e-mail „Your site is now active on Cloudflare”
• Status v Overview se změní z Pending nameserver update na Active

3.6. Smoke test po Active (10 minut)

Než přejdete na sekci 4 (zapnutí GTG), ověřte, že migrace nic nerozbila:

• ✅ Hlavní stránka odpovídá: https://vasedomena.cz
• ✅ www verze funguje / správně přesměrovává: https://www.vasedomena.cz
• ✅ SSL je validní (prohlížeč zobrazuje zámeček bez varování)
• ✅ E-mail funguje — odešlete testovací mail z [email protected] na svůj Gmail, počkejte 1–2 minuty
• ✅ Všechny kritické subdomény odpovídají (admin, m., shop., api., webmail. — co používáte)
• ✅ Pro e-shopy: feedy do Heureka / Zboží / Glami / Google Merchant Center se taháchnou (zkontrolovat v adminu Heureky, kdy proběhl poslední fetch)
• ✅ Všechny formuláře (login, checkout, kontakt) prochází

Co dělat, když něco nefunguje:

• Nejčastější příčina (90 % případů): SSL/TLS mode je „Flexible” → vrátit se na 3.3 krok 1, přepnout na Full (strict)
• Origin server odmítá Cloudflare IP → přidat CF IP rozsahy do whitelistu na hostingu
• Konkrétní subdoména nefunguje za proxy → přepnout ji na ☁️ DNS only (šedý mráček) a postupně debugovat
• V krajním případě: dočasně přepnout apex+www na DNS only — web pojede přímo na origin a získáte čas na debug

Když všech 7 položek smoke testu odškrtnete ✅ — gratulujeme, jste na Cloudflare. Pokračujte sekcí 4.

---

4. Aktivace Google Tag Gateway (5–10 minut)

1. Přihlášení do Cloudflare

Otevřete dash.cloudflare.com, přihlaste se a v seznamu domén vyberte doménu vašeho e-shopu.

2. Navigace do Google Tag Gateway

V levém menu najděte sekci Rules → Google Tag Gateway.

Poznámka: V některých starších účtech je položka umístěna v Apps → Google Tag Gateway. Pokud ji nevidíte, zkuste v horním vyhledávání napsat „Google Tag Gateway”.

3. Aktivace

Klikněte na tlačítko Enable (nebo Activate Google Tag Gateway). Cloudflare zobrazí seznam Google služeb, které je možné proxovat. Zaškrtněte:

• ☑ Google Analytics 4
• ☑ Google Ads
• ☑ Google Tag Manager (klientská část)

Klikněte Save / Activate.

4. Ověření v Cloudflare

Po aktivaci Cloudflare automaticky:

• Vytvoří Workera na edge síti
• Nastaví routing pravidla pro cesty /gtag/js, /gtm.js, /g/collect
• Zajistí proxy server-to-server fetchování z domén Googlu

V kódu vašeho webu se nemusí nic měnit — Google skripty samy detekují GTG režim a začnou přesměrovávat požadavky na vaši doménu.

5. Počkat 5–10 minut

Propagace nastavení po Cloudflare edge síti trvá několik minut. V této době je normální, když občas vidíte zpožděné odpovědi.

---

5. Jak ověřit, že GTG funguje (3 kontroly)

Kontrola č. 1 — okamžitá, v Chrome DevTools

1. Otevřete váš e-shop v prohlížeči Chrome
2. Stiskněte F12 (nebo pravé tlačítko → Inspect)
3. Přepněte na záložku Network
4. Obnovte stránku (Ctrl + R / Cmd + R)
5. Do filtru zadejte: gtag nebo collect
6. Zkontrolujte odkud požadavky přicházejí:

Před GTG:

Request URL: https://www.googletagmanager.com/gtag/js?id=G-XXXXX
Request URL: https://www.google-analytics.com/g/collect?...

Po zapnutí GTG (správný stav):

Request URL: https://vase-domena.cz/gtm.js?id=G-XXXXX   ✓
Request URL: https://vase-domena.cz/g/collect?...        ✓

Pokud vidíte svou doménu — GTG funguje ✓

Kontrola č. 2 — reálný provoz

1. Proveďte na webu testovací nákup nebo akci, která spouští konverzi
2. Jděte do GA4 → Reports → Realtime
3. Zkontrolujte, že se událost objevila během 1–2 minut

Kontrola č. 3 — Data Strength v Google Ads (po 7 dnech)

Nejdůležitější metrika, která ukáže skutečný přínos GTG:

1. Google Ads → Tools and Settings → Measurement → Conversions
2. U každé konverze sledujte sloupec Data Strength (Síla dat)

Hodnota	Význam	Komentář
🟢 High	GTG přináší více než 15 % získaných dat	Výborný výsledek
🟡 Medium	5–15 %	Normální
🟠 Low	Méně než 5 %	Pravděpodobně je potřeba dodatečné ladění
⚪ Insufficient	Málo provozu	Počkat — Google potřebuje víc dat

Prvních 7 dní po zapnutí metrika ještě nemusí ukazovat finální hodnotu — Google potřebuje sesbírat referenční data.

---

6. Co se skutečně děje pod kapotou — technický pohled

Tato sekce je pro ty, kdo chtějí pochopit, jak přesně GTG funguje na úrovni HTTP požadavků. Užitečné, když vysvětlujete řešení svému vývojáři nebo technickému kolegovi.

Příklad č. 1 — Načítání skriptu gtag.js

PŘED zapnutím GTG — co se děje při každém načtení stránky. Prohlížeč odesílá:

GET /gtag/js?id=G-XXXXX HTTP/1.1
Host: www.googletagmanager.com
User-Agent: Mozilla/5.0 ...
Referer: https://eshop.cz/produkt/123

Co vidí blokátor reklam: doména googletagmanager.com je na jeho blacklistu → požadavek zahozen, skript se nenačte, tracking nefunguje.

Co vidí Safari: skript ze třetí strany → aplikuje omezení ITP.

PO zapnutí GTG — stejné načtení stránky. Prohlížeč odesílá:

GET /gtm.js?id=G-XXXXX HTTP/1.1
Host: eshop.cz                    ← vaše doména, ne Google!
User-Agent: Mozilla/5.0 ...
Referer: https://eshop.cz/produkt/123

Co vidí blokátor reklam: doména eshop.cz — to je váš web, first-party → požadavek propuštěn.

Co vidí Safari: first-party skript → žádná omezení ITP.

Co se děje na Cloudflare edge (neviditelné pro prohlížeč): Worker zachytí požadavek a provede server-to-server fetch na googletagmanager.com. Google odpoví stejným skriptem jako vždy. Worker jej vrátí prohlížeči. Z pohledu prohlížeče to vypadá, jako by skript byl přímo z vaší domény.

Jak je to s cookies — důležité upřesnění

GTG nemění způsob, jakým jsou cookies vytvářeny. Cookies _ga a _gcl_aw stále vytváří skript gtag.js pomocí JavaScriptu v prohlížeči (nikoliv server přes HTTP hlavičku Set-Cookie).

Problém	Řeší GTG?
Blokátory reklam blokují doménu google-analytics.com	✅ Ano
Safari aplikuje ITP na skripty ze třetí strany	✅ Ano (skript je teď first-party)
Safari ITP ořeže JavaScriptem vytvořené cookies na 7 dní	❌ Ne (cookies stále vytváří JS)
Brave s CNAME uncloaking detekuje proxy	⚠️ Částečně (závisí na verzi)
iOS ATT omezuje Facebook Pixel	❌ Ne (jiný problém, jiná platforma)

Pro kompletní vyřešení Safari ITP (cookies s delší životností) je potřeba server-side tagging (sGTM), kde server vytváří cookies přes HTTP hlavičky a označuje je HttpOnly. To je samostatná infrastruktura, nad rámec GTG.

Co se děje s vašimi daty u Googlu

Z pohledu Googlu se nic nemění. Google obdrží přesně stejná data jako dřív — stejný payload, stejné cookies, stejné identifikátory. Rozdíl je pouze v tom, že data putují přes Cloudflare edge namísto přímo z prohlížeče.

GTG není řešení pro ochranu soukromí vůči Googlu — Google má stále plný přístup ke všem datům, která by měl i bez GTG. GTG pouze zajistí, že vůbec doputují.

---

7. Shrnutí: co GTG fyzicky mění

Na úrovni	Bez GTG	S GTG
URL skriptu v HTML	googletagmanager.com/gtag/js	eshop.cz/gtm.js
URL konverzního pingu	google-analytics.com/g/collect	eshop.cz/g/collect
Cookie doména (_ga)	.eshop.cz (už dnes)	.eshop.cz (beze změny)
Životnost _ga cookie	7 dní v Safari	7 dní v Safari (nezměněno GTG)
Viditelnost pro blokátory reklam	blokován	propuštěn
Rychlost načítání	z Google CDN	z Cloudflare edge (často rychlejší)
Data, která Google obdrží	stejná	stejná

---

8. Po zapnutí GTG (doporučená další opatření)

a) Enhanced Conversions (velmi důležité)

Pokud ještě nemáte zapnuté, zapnout v Google Ads:

1. Google Ads → Tools → Conversions → vybrat vaši konverzi
2. Enhanced Conversions for the web → Turn on
3. Metoda: Google tag (automaticky vezme data z formulářů)
4. Doména: ponechat defaultní nastavení

Efekt: zlepšení párování konverzí o dalších 10–40 % (oficiální data Googlu).

b) Kontrola Consent Mode v2

Ujistit se, že váš CMP (Cookiebot / Usercentrics / OneTrust) správně posílá všechny 4 signály:

• ad_storage
• analytics_storage
• ad_user_data
• ad_personalization

Bez nich Google Ads a GA4 v EU přestávají sbírat data o nových návštěvnících — povinné od března 2024.

c) Pravidelné testování

Jednou měsíčně zkontrolovat:

• Data Strength v Google Ads
• Objem událostí v GA4 (neklesl?)
• Realtime report v GA4 (události přicházejí?)

---

9. Možné problémy a jejich řešení

Problém	Příčina	Řešení
Po zapnutí se web nenačítá správně	Cloudflare SSL mode je na „Flexible”	Cloudflare → SSL/TLS → přepnout na Full (strict)
Data Strength zůstává „Low”	Consent Mode v2 není správně nastavený	Zkontrolovat CMP, kontaktovat nás
V DevTools stále vidím googletagmanager.com	Cache prohlížeče	Ctrl+Shift+R (hard refresh) nebo otevřít v anonymním okně
GTM web container přestal fungovat	Konflikt s vlastní custom doménou v GTM	GTM → Admin → Container Settings → odstranit custom domain mapping
Konverze vypadají dvakrát	Souběžně běží staré měření + GTG	Obvykle ne — GTG nepřidává události, pouze je proxyje. Zkontrolujte jiné zdroje duplikátů
První hodiny po zapnutí chybí část dat	Cache edge sítě se propaguje	Počkat 15–30 minut, případně Cloudflare → Caching → Purge Everything
GTG je aktivní, ale v HTML stále vidím googletagmanager.com	CMS má uzavřený šablonovací systém — neumožňuje vložit vlastní HTML kód do <head> a GTM snippet je generován s pevně danou URL	Nasadit Cloudflare Worker pro HTML rewriting na edge — viz řešení níže

Specifické problémy z fáze migrace (sekce 3)

Problém	Příčina	Řešení
Doména je 1–7 dní nedostupná po změně nameserverů	DNSSEC nebyl vypnutý před změnou NS — DS záznamy v parent registry stále existují, resolvery vrací SERVFAIL	Vypnout DNSSEC u registrátora a počkat, než DS záznamy expirují (může trvat až 7 dní). Příště: kontrola 3.3 krok 2 před změnou NS
Status v Cloudflare zůstává „Pending nameserver update” i po hodině	Změna NS u registrátora čeká na e-mail confirmation od vlastníka	Najít e-mail od registry / registrátora s potvrzovacím odkazem. Pokud nemáte přístup — domluvit s klientem forward
E-maily přestaly chodit	MX záznamy se v Quick Scan nenaimportovaly nebo byly nastaveny na Proxied	Cloudflare → DNS → ověřit, že MX záznamy jsou ☁️ DNS only (ne Proxied) a směřují na správný mailserver. Doplnit chybějící
Po migraci se rozbil renewal SSL certifikátu na origin serveru	CAA záznamy z původní zóny se nenaimportovaly	V Cloudflare → DNS přidat CAA záznamy ručně podle exportu původní zóny (typicky 0 issue "letsencrypt.org")
Konkrétní subdoména (admin, FTP) přestala fungovat za proxy	Origin server má whitelist IP adres a Cloudflare proxy mění zdrojovou IP	Přepnout problémovou subdoménu na ☁️ DNS only, nebo přidat CF IP rozsahy do whitelistu
Heureka / Google Merchant feed přestal číst data	Crawlery nedostávají odpověď za Cloudflare proxy (rate limit, bot challenge)	Cloudflare → Security → Bots → vytvořit allow rule pro known crawlers, nebo dočasně přepnout subdoménu s feedem na ☁️ DNS only

Když CMS neumožňuje vlastní HTML kód (řešení přes Cloudflare Worker)

Časová náročnost celého řešení: reálně 3–4 hodiny — počítejte s tím poctivě. Zahrnuje: audit CMS (jestli má vůbec nějakou možnost vložit vlastní HTML, nebo to opravdu nejde) → research alternativ → napsání a nasazení Workeru → konfigurace route s Fail-open režimem → ověření v Chrome DevTools → ověření v GA4 Realtime → kontrola, že se nic nerozbilo. Jednotlivé kroky jsou rychlé (kliknutí v UI), ale celkový průchod včetně diagnostiky, debuggingu a ověření je výrazně delší než „pár minut na Worker”.

Problém: Některé uzavřené e-commerce platformy (např. Binargon, některé verze BigCommerce a starší Joomla šablony) negenerují HTML přes editovatelné pole — GTM snippet je v šabloně pevně zakódovaný s URL https://www.googletagmanager.com/gtm.js?id=.... Nelze ji změnit přes admin rozhraní.

Cloudflare Google Tag Gateway sice proxyje požadavky na /měření-cesta, ale HTML samo o sobě neprepisuje — pokud je GTM snippet v stránce hardcoded na googletagmanager.com, prohlížeč si ho stáhne třetí stranou a celý smysl GTG je pryč.

Řešení: Cloudflare Worker (~25 řádků kódu), který sedí mezi návštěvníkem a originem, čte HTML odpověď a nahrazuje URL na first-party cestu. Worker poběží na okraji sítě (edge), přidá ~10 ms latence, je zdarma do 100 000 požadavků denně.

Kdy to potřebujete

• Aktivovali jste GTG (sekce 4) a v ověření (sekce 5) stále vidíte v HTML googletagmanager.com
• Vaše CMS nemá v adminu pole „Vlastní HTML kód v hlavičce” / „Custom <head> insert”
• Provider CMS odmítá nebo dlouho zvažuje přidání takové funkce

Kód Workeru

Tento příklad používá doménu vase-domena.cz a měřící cestu /pulse. Pro vlastní nasazení nahraďte vase-domena.cz/pulse svojí doménou a měřící cestou nastavenou v GTG.

export default {
  async fetch(request, env, ctx) {
    try {
      const response = await fetch(request);
      const contentType = response.headers.get('content-type') || '';

      // Skip non-HTML — proxy as-is
      if (!contentType.includes('text/html')) {
        return response;
      }

      const original = await response.text();
      const modified = original.replace(
        /(?:https?:)?\/\/www\.googletagmanager\.com\/(gtm\.js|ns\.html)/g,
        'https://vase-domena.cz/pulse/$1'
      );

      const headers = new Headers(response.headers);
      headers.delete('content-length');

      return new Response(modified, {
        status: response.status,
        statusText: response.statusText,
        headers
      });
    } catch (err) {
      // Fail-safe: any error → origin passthrough
      return fetch(request);
    }
  }
};

Nasazení přes Cloudflare Dashboard (10 minut)

1. Cloudflare Dashboard (top-level, ne uvnitř zóny) → Workers & Pages → Create application → Create Worker
2. Vybrat Start with Hello World! → pojmenovat (např. vase-domena-gtg-rewriter) → Deploy
3. Na stránce Workeru → Edit code → smazat výchozí kód → vložit kód výše (nezapomeňte upravit URL) → Save and Deploy
4. Settings → Domains & Routes → + Add → Route: Zone: vaše doména Route: vase-domena.cz/* Failure mode: Fail open (proceed) — kritické! Při chybě Workeru pojde request přímo na origin, web zůstane funkční
5. Volitelně: vypnout workers.dev URL v Domains & Routes (best practice — Worker by neměl být přístupný mimo váš route)

Ověření

# 1. V HTML by měly být přepsané URL
curl -s -L "https://vase-domena.cz/" \
  | grep -oE "(googletagmanager\.com|vase-domena\.cz/měřicí-cesta)[^\"' ]{0,40}" \
  | sort -u
# Očekávaný výsledek:
#   vase-domena.cz/měřicí-cesta/gtm.js?id=
#   vase-domena.cz/měřicí-cesta/ns.html?id=GTM-XXXXXXX

# 2. Web žije
curl -s -o /dev/null -w "HTTP %{http_code} | %{time_total}s\n" "https://vase-domena.cz/"
# Očekávaný výsledek: HTTP 200, čas pod 1.5s

Fail-safe — co se stane, když Worker selže

Díky Failure mode: Fail open a try/catch uvnitř kódu má Worker dvě nezávislé vrstvy obrany:

1. Vnitřní: catch (err) zachytí jakoukoliv chybu v rewrite logice a vrátí origin response beze změny
2. Vnější: Pokud Worker spadne tak fatálně, že ani catch neproběhne (např. timeout, OOM), Cloudflare obejde Worker úplně a pošle request přímo na origin

Důsledek: web nikdy nepadne kvůli Workeru. V nejhorším případě GTG dočasně přestane fungovat (tagy se načtou ze třetí strany jako před aktivací) — žádný uživatel nevidí chybu.

---

10. Reálné scénáře — co může jít špatně

7 nejčastějších situací z praxe. U každé: jak se projeví, jak to zjistit, co s tím dělat.

Scénář č. 1: Web se po zapnutí přestal načítat

Příznaky: Uživatelé vidí chybu ERR_SSL_VERSION_OR_CIPHER_MISMATCH nebo „Tato stránka není zabezpečená”. V Cloudflare Analytics skokově narostou 5xx chyby.

Příčina: Cloudflare má SSL mode nastavený na Flexible. GTG vyžaduje šifrovanou komunikaci i mezi Cloudflare a vaším původním serverem.

Co udělat okamžitě (do 5 minut):

1. Cloudflare dashboard → SSL/TLS → Overview
2. Přepnout z Flexible na Full (strict)
3. Počkat 30–60 sekund na propagaci
4. Ověřit web v anonymním okně

Scénář č. 2: Data Strength zůstává „Low” i po 14 dnech

Možné příčiny (v pořadí pravděpodobnosti):

1. Consent Mode v2 není správně nastavený — uživatelé v EU neodsouhlasili cookies → data se neposílají. Diagnostika: GA4 → DebugView → sledovat ad_user_data signál. Pokud je trvale denied, problém je v CMP. Řešení: revize Cookiebot/Usercentrics konfigurace.
2. Enhanced Conversions nejsou aktivní Diagnostika: Google Ads → Conversion → sekce Enhanced Conversions. Řešení: zapnout (postup v sekci 8a).
3. Nízký objem konverzí (méně než 30/měsíc) Řešení: počkat, než se nasbírá dostatek dat (2–3 měsíce).
4. Konfliktní custom domain v GTM Diagnostika: GTM → Admin → Container Settings → Custom Domain. Řešení: odstranit nebo synchronizovat s GTG nastavením.

Scénář č. 3: V GA4 se začaly objevovat zdvojené události

Příčina: Současně běží dvě cesty odesílání událostí: starý client-side tracking (gtag.js přes google-analytics.com) + nové přes GTG (eshop.cz/g/collect). To by teoreticky nemělo nastat, ale může se to stát, když:

• Máte více GTM kontejnerů na stejné stránce
• Máte ručně vložený gtag.js navíc ke GTM
• Jiný nástroj (třeba OptinMonster, Hotjar) také odesílá do GA4

Diagnostika:

1. View source stránky (Ctrl+U) → vyhledat gtag → kolikrát je tam?
2. GTM Preview mode → kolik tagů „GA4 Event” se spouští při jedné události?
3. GA4 → Admin → DebugView → otevřít testovací relaci a spočítat duplikáty

Řešení: najít a odstranit duplikáty na stránce. Ponechat pouze jeden zdroj — buď GTM, nebo přímý gtag, ne oba.

Scénář č. 4: Skokový nárůst „New Users” a změna Bounce Rate v GA4

⚠️ Důležité: toto NENÍ chyba

GTG začal měřit uživatele, kteří dřív měli zablokovaný tracking (ad blockery, Safari). Tato data jste vždycky měli — jenom jste je neviděli.

• Noví uživatelé narostli → protože ad-blocker uživatelé byli dřív neviditelní
• Bounce rate se změnil → tito uživatelé mají jinou typologii chování (často tech-savvy, rychlejší skenování)
• Konverze narostly → jejich reálný dopad byl dřív „ghost”

Co udělat: nastavit novou baseline. Grafy v GA4 se vizuálně „zlomí” v den zapnutí GTG — je dobré si to označit poznámkou v Annotations, aby všichni v týmu věděli, co se stalo.

Scénář č. 5: Brave prohlížeč stále blokuje tracking

Příčina: Brave má funkci CNAME uncloaking — kontroluje, kam doména reálně směřuje. Pokud detekuje, že eshop.cz/gtm.js končí u trackovací služby, může request zablokovat.

Možnosti:

1. Akceptovat — Brave má ~1 % trhu, zanedbatelné pro většinu e-shopů
2. Server-side tagging (sGTM) — jde o hlubší proxy, kterou Brave detekuje hůř
3. Kombinace GTG + sGTM + same-origin deployment přes CF Worker

Realistické očekávání: Po zapnutí GTG budete mít pokryto ~99 % Chrome uživatelů, ~90 % Safari, ~95 % Firefox, ale jen ~50–70 % Brave.

Scénář č. 6: GTM Preview mode přestal fungovat

Příčina: GTG může filtrovat speciální debug cookies a hlavičky (X-Gtm-Server-Preview), které GTM Preview používá.

Řešení:

1. Cloudflare → Rules → vytvořit bypass rule pro vaši IP adresu (po dobu debugování)
2. Alternativně: debug v anonymním okně s ručně nastavenou debug cookie
3. Po dokončení debugování bypass rule smazat

Scénář č. 7: „Slíbili jste +11 %, ale já to nevidím”

Reálný kontext:

• +11 % je medián napříč všemi účty (oficiální data Google, duben 2025)
• Rozpětí v praxi: +3 % až +25 %
• Konkrétní výsledek závisí na: Struktuře publika — klient s 80 % Chrome bez blokátorů uvidí +3 %, klient s 30 % Safari + velkým podílem ad-blocker uživatelů uvidí +20 % Stávající kvalitě Consent Mode — pokud byl špatně nastavený, přínos GTG bude maskován řešením jiného problému Objemu konverzí — u webu s 10 konverzemi/měsíc je +11 % statisticky nečitelných (potřebujete 100+ konverzí pro spolehlivé měření)

Jak to správně odkomunikovat:

1. Metriku Data Strength v Google Ads považujte za hlavní indikátor, ne absolutní počet konverzí
2. 30denní okno minimálně, ne 7denní
3. Ukázat objem událostí v GA4 (ne jen konverzí) — tam je rozdíl viditelnější
4. Porovnat week-over-week, ne den po dni (sezónnost zkresluje)

---

11. Co konkrétně uvidíte v datech

V Google Ads

Kdy	Co uvidíte
Okamžitě (den 1)	V Conversions → Diagnostics zmizí varování „Tag blocked”. V DevTools správná doména u požadavků.
Za 7 dní	Sloupec Data Strength s hodnotou. All Conversions typicky naroste o 5–20 %.
Za 14–30 dní	CPA může klesnout o 5–15 %. ROAS může narůst o 10–25 %. Smart Bidding se přizpůsobuje.

V GA4

Kdy	Co uvidíte
Okamžitě	Realtime report ukazuje události ze všech prohlížečů. DebugView ukazuje gcs a gcd parametry.
Týden 1–2	Event count narůstá o 10–30 %. Total Users narůstá o 10–30 %. Bounce Rate se může změnit (vizuální zlom — normální).
Měsíc 1–3	Atribuční modely jsou přesnější. Audiences rostou (větší pool pro remarketing).

Co se NEZMĚNÍ (kde GTG nepomáhá)

Nástroj	Proč se nezmění
Facebook Ads Manager	GTG nezahrnuje Facebook Pixel
TikTok Ads	Jiný ekosystém
Snapchat, Pinterest, LinkedIn	Mimo rozsah GTG
Klaviyo, Mailchimp, ActiveCampaign	Vlastní trackingové integrace
Hotjar, Smartlook, Clarity	Vlastní skripty
CRM (HubSpot, Pipedrive)	Obvykle nepropojeno s GTG

Příklad konkrétního e-shopu (anonymizovaný)

Klient: střední e-shop v ČR, měsíční rozpočet Google Ads ≈ 80 000 Kč.

Období	Google Ads konverze	CPA	GA4 uživatelé	Data Strength
Před GTG (srpen 2025)	245/měsíc	327 Kč	38 400	—
Po zapnutí (září 2025)	281 (+14,7 %)	285 Kč (−12,8 %)	47 200 (+22,9 %)	Medium
Po 3 měsících (listopad 2025)	312 (+27,3 %)	256 Kč (−21,7 %)	—	High

Tento případ je nad mediánem (+11 %) — klient měl původně slabý Consent Mode a velkou část Safari publika. U jiných klientů s už dobře nastaveným trackingem může být zlepšení podstatně menší (+3–7 %).

Timeline očekávání

Kdy	Co uvidíte
Minuta 1	DevTools ukazuje správnou doménu
Hodina 1	Realtime v GA4 zobrazuje data
Den 1	Objem událostí začíná růst
Den 7	Data Strength metrika se objeví
Týden 2	Solidní Data Strength hodnota
Měsíc 1	Snížení CPA díky lepší optimalizaci
Měsíc 2–3	Plný dopad na kampaně

---

12. Často kladené otázky

Mohu GTG kdykoliv vypnout? Ano, stejným způsobem jako zapnutí — jedno kliknutí v Cloudflare. Změna je okamžitá.

Ovlivní GTG rychlost webu? Pozitivně. Google skripty se načítají z Cloudflare edge sítě, která má 300+ lokací po celém světě — typicky rychleji než originální Google CDN. Měření ukazují zlepšení LCP o 3–10 %.

Můžu GTG použít s Google Tag Manager (GTM)? Ano, jsou plně kompatibilní. GTG proxyje i samotný GTM skript.

Funguje to pro Facebook Pixel, TikTok, Pinterest? Ne. GTG pracuje výhradně s Google službami. Pro Meta/TikTok je potřeba server-side tagging (sGTM) — samostatný projekt.

Zvýší to cenu za Cloudflare? Ne. GTG je zahrnut i v Cloudflare Free plánu. Není započítán v limitu Workers requests.

Je to v souladu s GDPR? Samo o sobě GTG nemění právní situaci — data stále končí u Googlu. Consent Mode v2 a váš CMP musí být správně nastavené (to je podmínkou i bez GTG). GTG sám neobchází souhlas.

Jak dlouho čekat na viditelné výsledky? V Chrome DevTools vidíte výsledek ihned. Data Strength v Google Ads se objeví za 7 dní. Plný vliv na kampaně za 14–30 dní (algoritmy se přizpůsobují na čistší data).

Co když mám web na Shopify? Shopify spravuje vlastní Cloudflare — do jeho nastavení nemáte přístup. Pro Shopify doporučujeme alternativu: Enhanced Conversions + Shopify app pro server-side tracking (Elevar, Conversios). Kontaktujte nás — připravíme plán.

---

13. Co potřebujeme od vás (checklist)

Pokud chcete, abychom GTG nastavili my

• Přístup do Cloudflare dashboard (nebo přidáte nás jako admina)
• Potvrzení, že chcete proxy pro: GA4, Google Ads, GTM
• Kontakt technika ze strany klienta pro případné DNS/SSL dotazy
• Potvrzení, že máte Consent Mode v2 nastavený (pokud ne — vyřešíme)

✅ Pokud budete postupovat sami

• Projít sekci 2 (zjistit svůj scénář) a sekci 3 (jen scénář B — migrace na CF)
• Aktivovat GTG podle sekce 4
• Provést ověření podle sekce 5
• Za 7 dní zkontrolovat Data Strength v Google Ads
• Dát nám vědět výsledky — pomůžeme interpretovat

---

14. Očekávaný výsledek

Za 7 dní po zapnutí:

• +11–25 % získaných konverzí v Google Ads
• Data Strength: Medium až High
• Objem událostí v GA4 narostl

Za 30 dní:

• Lepší optimalizace reklamních algoritmů (na úplnějších datech)
• Snížení CPA o 5–15 % v Google Ads (díky přesnější atribuci)
• Přesnější reporty pro rozhodování

Pokud tyto výsledky neuvidíte — kontaktujte nás, prověříme správnost nastavení. Obvyklé příčiny: špatně nakonfigurovaný Consent Mode, chybějící Enhanced Conversions, konflikt s existujícími custom domain v GTM.

---

15. Další krok po GTG

GTG je první patro pokročilejší tracking infrastruktury. Pokud máte významný rozpočet na Meta Ads / TikTok / Pinterest (od ~250 000 Kč měsíčně), doporučujeme jako další krok:

Server-side tagging (sGTM) — samostatný server, který obsluhuje Meta Conversions API, TikTok Events API a další platformy. Řeší podobné problémy, ale pro celou reklamní škálu. Cena: 500–5 000 Kč/měsíc + setup.

Toto řešíme jako samostatný projekt — dejte vědět, pokud má smysl to probrat.

---

✅ Kompletní checklist od začátku do konce

Fáze 1 — Migrace domény na Cloudflare (jen scénář B, sekce 3):

• Cloudflare účet vytvořený, doména přidaná (Add a Site)
• Quick Scan proběhl, DNS záznamy zkontrolované (A/AAAA/CNAME/MX/TXT) — vše naimportováno
• Smazané artefakty starých NS záznamů (typu ns.registrátor.com) ze zóny
• SSL/TLS mode: Full (strict)
• DNSSEC vypnutý v aktuálním DNS (dig DS vrací prázdno)
• CAA záznamy zkontrolovány a přeneseny (pokud existovaly)
• Speed settings na defaultech (Rocket Loader OFF, Polish disabled)
• Proxy status rozhodnutý: 🟠 apex+www, ☁️ DNS only pro citlivé subdomény
• Nameservery změněny u registrátora na 2 CF nameservery
• E-mail confirmation od registry potvrzen (klikem na odkaz)
• Status v CF Overview = Active
• Smoke test prošel: web, www, e-mail, subdomény, SSL, formuláře

Fáze 2 — Aktivace GTG (oba scénáře, sekce 4–5):

• V Cloudflare → Rules → Google Tag Gateway = ON
• Zaškrtnuty: GA4, Google Ads, GTM
• V DevTools u požadavků vidím svou doménu (ne googletagmanager.com)
• V GA4 Realtime se objevují události

Fáze 3 — Doplňková opatření (sekce 8):

• Consent Mode v2 nastavený přes CMP (Cookiebot/Usercentrics/OneTrust)
• Enhanced Conversions zapnuté v Google Ads
• V GA4 označená Annotation v den zapnutí (pro týmový kontext)
• Za 7 dní — zkontrolovat Data Strength v Google Ads
• Za 30 dní — vyhodnotit změnu CPA / ROAS

V případě jakýchkoli dotazů k nastavení se neváhejte ozvat. [email protected]