Google Tag Gateway через Cloudflare — докладна інструкція

Стисло: що ви отримаєте з цієї інструкції

• Для кого: інтернет-магазини, у яких домен уже на Cloudflare.
• Скільки часу потрібно: 10–15 хвилин, без участі розробника.
• Результат: +11–25% повернутих конверсій у Google Ads і GA4, безкоштовно.

1. Що таке Google Tag Gateway і навіщо він вам

Google Tag Gateway (GTG) — це безкоштовний сервіс від Google у партнерстві з Cloudflare, запущений у травні 2025 року. Працює як «наскрізний проксі», який робить так, щоб скрипти Google Analytics 4 і Google Ads доставлялися через ваш власний домен замість googletagmanager.com або google-analytics.com.

Чому це важливо

Сьогодні приблизно у 15–30% відвідувачів e-commerce встановлено блокувальник реклами (uBlock Origin, AdBlock Plus, Brave Shields), який блокує скрипти з доменів Google. Крім того, Safari на пристроях iOS обмежує сторонні cookies сімома днями.

Результат: втрата 15–40% конверсій і в Google Ads, і в GA4 → рекламні алгоритми оптимізуються на неповних даних → вищий CPA і нижчий ROAS.

✅ Що GTG вирішує

• Обходить блокувальники реклами — скрипти приходять з вашого домену, а не з домену Google
• Забезпечує «first-party» контекст для Safari → скрипт більше не третя сторона
• Середній приріст звітних конверсій: +11% (офіційні дані Google, медіана за квітень 2025)
• Заміряний діапазон в агенцій: 9–18%
• Повертає 70–85% втрат трекінгу, спричинених ад-блокерами

⚠️ Чого GTG не вирішує

• Facebook/Meta Pixel, TikTok Events API, Pinterest — GTG працює лише з екосистемою Google
• Трансформацію та збагачення даних (це вміє лише повноцінний server-side GTM)
• Проблеми на боці iOS ATT (втрата даних Meta Pixel на мобільних)
• Обрізання Safari ITP JavaScript-cookies до 7 днів (cookies так само створює gtag.js у браузері)

2. Передумови — який сценарій ваш?

Перед активацією GTG перевірте, який сценарій на вас чекає:

Сценарій A — домен уже на Cloudflare

Якщо в dash.cloudflare.com ви бачите свій домен зі статусом Active — вам пощастило. Переходьте одразу до розділу 4 (активація GTG, 10–15 хвилин).

Сценарій B — домен ще в іншого реєстратора / DNS-провайдера

Тобто звичайний стан більшості інтернет-магазинів: домен зареєстрований через Subreg / Forpsi / GoDaddy / Namecheap, DNS керується у реєстратора або на хостингу. Спершу пройдіть розділ 3 (міграція на Cloudflare, 30–60 хвилин + 1–24 год очікування), і лише потім розділ 4.

Незалежно від сценарію — врешті вам знадобиться:

Вимога	Як перевірити
Домен на Cloudflare зі статусом Active	Дашборд Cloudflare → ваш домен → статус «Active»
Робочий Google Tag (gtag.js) або GTM на сайті	Відкрити сайт → Chrome DevTools → Network → фільтр «gtag» → бачите запити?
SSL/HTTPS активний	Сайт відкривається через https://
Адміністраторський доступ до акаунта Cloudflare	Увійти → бачите розділ «Rules»
Адміністраторський доступ до Google Ads і GA4	Для перевірки результатів
Consent Mode v2 правильно налаштований через CMP	Cookiebot/Usercentrics/OneTrust — якщо сумніваєтесь, зв’яжіться з нами

Якщо якась із цих умов не виконана, дайте нам знати — вирішимо це до вмикання GTG.

---

3. Міграція домену на Cloudflare (тільки сценарій B)

Якщо ваш домен уже на Cloudflare, цей розділ пропустіть і переходьте до розділу 4.

Міграція — процес зі своїми підводними каменями: різні реєстратори називають речі по-різному, у деяких кроків є email-confirmation, поширення DNS триває годинами. Цей розділ збирає універсальний шаблон і 5 найчастіших пасток, на які ми натрапили в наших клієнтів.

Що вам знадобиться

• Доступ до панелі реєстратора домену (там, де ви купували домен)
• Доступ до e-mail власника домену (реєстратура зазвичай надсилає лист-підтвердження)
• Приблизно 30–60 хвилин активної роботи + 1–24 години пасивного очікування поширення DNS
• Спокій — якщо зробите 5 pre-flight перевірок із пункту 3.3, ні сайт, ні пошта не впадуть

3.1. Створити зону в Cloudflare (3 хвилини)

1. Реєстрація на cloudflare.com — безкоштовного плану вистачає більшості інтернет-магазинів
2. Add a Site → введіть свій домен (без www) → виберіть Free plan
3. Cloudflare запустить Quick Scan — автоматично імпортує DNS-записи з поточної зони

3.2. Перевірити імпортовані DNS-записи (5 хвилин)

Quick Scan зазвичай ловить 90–95% записів, але не 100%. Пройдіть за списком і переконайтеся, що там є все, що у вас у поточній зоні:

• A / AAAA на apex (сам домен, IPv4 / IPv6)
• CNAME www (або A www) — інакше www.vasedomena.cz не працюватиме
• MX записи — без них не ходитиме пошта
• TXT: SPF (v=spf1...), DKIM (_domainkey), DMARC (_dmarc) — без них листи впадуть у спам
• TXT: google-site-verification, Heureka, верифікація Search Console, Microsoft, Facebook domain verification — усе, що у вас там є сьогодні
• Субдомени: m., shop., admin., api. — усі, які реально використовуєте

Що, навпаки, видалити:

• NS-записи на кшталт ns.vasregisrator.com в імпортованій зоні — це артефакти старого DNS, після міграції вони непотрібні й лише плутають

Якщо чогось бракує — Add record і дописати вручну. Зразок зони вивантажте в поточного DNS-провайдера (BIND export) і звірте запис за записом.

3.3. Pre-flight перевірки (10 хвилин) — 5 найчастіших пасток

Це перевірки, пропуск яких валив у клієнтів сайт або пошту. Зробіть усі 5 ще до зміни неймсерверів:

1. SSL/TLS Mode = Full (strict)

Дашборд Cloudflare → SSL/TLS → Overview → виберіть Full (strict).

НІКОЛИ не залишайте «Flexible» — він ламає POST-форми (логін, чекаут) і створює петлі редиректів. Якщо ваш origin-сервер підтримує HTTPS (а у 2026 році його підтримує практично будь-який хостинг), Full (strict) — правильний вибір.

2. DNSSEC вимкнути в поточному DNS

У панелі реєстратора знайти розділ DNSSEC / DNS Security → вимкнути. Якщо він був увімкнений, зачекати ~1 годину, поки DS-записи в parent registry спливуть, — і лише потім міняти неймсервери.

Швидка перевірка в терміналі: dig DS vasedomena.cz +short. Порожній вивід = ОК, можна продовжувати. Якщо бачите щось на кшталт 2371 13 2 ABC123... = DNSSEC ще активний у реєстратурі, зачекайте.

Чому це так важливо: якщо ви зміните неймсервери без вимкнення DNSSEC, домен може бути недоступним 1–7 днів (резолвери повернуть SERVFAIL), поки DS-записи в реєстратурі не спливуть. Це найчастіший спосіб завалити міграцію.

3. CAA-записи перевірити та перенести

В експорті вашої поточної зони (BIND export у реєстратора) знайдіть CAA. Якщо вони є — додайте їх у Cloudflare DNS вручну (Add record → тип CAA).

CAA-записи кажуть, який Certificate Authority може видавати SSL-сертифікати для вашого домену. Без них після міграції може зламатися автоматичний renewal Let’s Encrypt на origin-сервері.

4. Speed Settings — залишити дефолти

Дашборд Cloudflare → Speed → Optimization. Налаштування за замовчуванням у 2026 році безпечні:

• Rocket Loader: OFF (дефолт на нових зонах) — не вмикати наосліп, може ламати React/Vue-застосунки
• Auto Minify: deprecated, розбиратися не потрібно
• Brotli: auto-on, розбиратися не потрібно
• Polish: вимагає платний план, за замовчуванням Disabled

Не вмикайте Polish / Mirage / Rocket Loader без тесту на staging — вони можуть змінити поведінку JS/CSS так, що завалять конкретну функціональність вашого сайту.

5. Proxy (помаранчева проти сірої хмаринки) — рішення щодо кожного запису

Кожен A/AAAA/CNAME-запис має вибір Proxied (🟠 помаранчева) або DNS only (☁️ сіра):

• apex (root) + www → 🟠 Proxied (отримуєте CDN, WAF, bot mitigation, GTG — заради цього ви взагалі й мігруєте)
• wildcard *. або специфічні субдомени (admin, mail, ftp) → ☁️ DNS only — у них часто whitelist origin IP, і проксі це зламає
• MX-записи → завжди DNS only (Cloudflare не тунелює SMTP)

Якщо не впевнені — увімкніть 🟠 Proxied лише на apex і www, усе інше залиште ☁️ DNS only. Після успішної міграції по одному вмикайте помаранчеву на решту субдоменів і тестуйте.

3.4. Зміна неймсерверів у реєстратора (5 хвилин + e-mail confirmation)

У дашборді Cloudflare, у розділі Overview, ви знайдете 2 видані неймсервери (виглядають як xxx.ns.cloudflare.com). Ці 2 значення скопіюйте.

У панелі вашого реєстратора:

1. Знайти розділ для неймсерверів — називається по-різному: «Nameservers», «DNS Settings», «Змінити неймсервери», «NSSET» (реєстратура .cz), «Manage DNS», «Edit nameservers»
2. Видалити / замінити всі поточні неймсервери
3. Вставити 2 неймсервери від Cloudflare
4. Зберегти / Save / Submit

⚠️ E-mail confirmation — часта пастка

Багато реєстраторів (особливо .cz через CZ-NIC, але й міжнародні на кшталт Namecheap, GoDaddy) надсилають лист-підтвердження на адресу власника домену, вказану у WHOIS. Без кліку за посиланням підтвердження зміна не застосується — заявка так і висітиме у статусі «New» / «Pending» 7–14 днів, а потім спливе.

Якщо у вас немає доступу до e-mail власника — домовтеся з клієнтом, щоб він переслав вам листа або клікнув за посиланням сам.

3.5. Дочекатися статусу Active (5 хвилин — 24 години)

Поширення DNS не детерміноване. Зазвичай минає за 5–30 хвилин, у виняткових випадках тягнеться до 24–48 год (залежить від TTL попередніх неймсерверів і поведінки конкретних резолверів).

Швидка перевірка в терміналі:

dig NS vasedomena.cz +short

Якщо вивід містить ваші Cloudflare NS (наприклад, diva.ns.cloudflare.com), у вас поширення минуло.

У дашборді Cloudflare:

• Натисніть «I updated my nameservers» — Cloudflare проведе власну перевірку
• Коли Cloudflare виявить зміну, прийде лист «Your site is now active on Cloudflare»
• Статус в Overview зміниться з Pending nameserver update на Active

3.6. Smoke-тест після Active (10 хвилин)

Перш ніж переходити до розділу 4 (вмикання GTG), переконайтеся, що міграція нічого не зламала:

• ✅ Головна сторінка відповідає: https://vasedomena.cz
• ✅ www-версія працює / правильно редиректить: https://www.vasedomena.cz
• ✅ SSL валідний (браузер показує замочок без попереджень)
• ✅ Пошта працює — надішліть тестовий лист з [email protected] на свій Gmail, зачекайте 1–2 хвилини
• ✅ Усі критичні субдомени відповідають (admin, m., shop., api., webmail. — що використовуєте)
• ✅ Для інтернет-магазинів: фіди в Heureka / Zboží / Glami / Google Merchant Center тягнуться (перевірити в адмінці Heureka, коли був останній fetch)
• ✅ Усі форми (логін, чекаут, контакти) проходять

Що робити, якщо щось не працює:

• Найчастіша причина (90% випадків): SSL/TLS mode стоїть «Flexible» → повернутися до 3.3 крок 1, перемкнути на Full (strict)
• Origin-сервер відхиляє IP Cloudflare → додати діапазони IP CF у whitelist на хостингу
• Конкретний субдомен не працює за проксі → перемкнути його на ☁️ DNS only (сіра хмаринка) і поступово дебажити
• У крайньому разі: тимчасово перемкнути apex+www на DNS only — сайт піде напряму на origin, і ви виграєте час на дебаг

Коли всі 7 пунктів smoke-тесту відмічені ✅ — вітаємо, ви на Cloudflare. Продовжуйте розділом 4.

---

4. Активація Google Tag Gateway (5–10 хвилин)

1. Вхід у Cloudflare

Відкрийте dash.cloudflare.com, увійдіть і в списку доменів виберіть домен свого інтернет-магазину.

2. Навігація в Google Tag Gateway

У лівому меню знайдіть розділ Rules → Google Tag Gateway.

Примітка: У деяких старих акаунтах пункт розташований в Apps → Google Tag Gateway. Якщо ви його не бачите, спробуйте вписати у верхній пошук «Google Tag Gateway».

3. Активація

Натисніть кнопку Enable (або Activate Google Tag Gateway). Cloudflare покаже список сервісів Google, які можна проксувати. Позначте:

• ☑ Google Analytics 4
• ☑ Google Ads
• ☑ Google Tag Manager (клієнтська частина)

Натисніть Save / Activate.

4. Перевірка в Cloudflare

Після активації Cloudflare автоматично:

• Створить Worker в edge-мережі
• Налаштує правила роутингу для шляхів /gtag/js, /gtm.js, /g/collect
• Забезпечить проксувальний server-to-server fetch з доменів Google

У коді вашого сайту міняти нічого не потрібно — скрипти Google самі виявляють режим GTG і починають перенаправляти запити на ваш домен.

5. Зачекати 5–10 хвилин

Поширення налаштувань по edge-мережі Cloudflare займає кілька хвилин. У цей час нормально, якщо іноді бачите затримані відповіді.

---

5. Як перевірити, що GTG працює (3 перевірки)

Перевірка № 1 — миттєва, у Chrome DevTools

1. Відкрийте свій інтернет-магазин у браузері Chrome
2. Натисніть F12 (або права кнопка → Inspect)
3. Перемкніться на вкладку Network
4. Оновіть сторінку (Ctrl + R / Cmd + R)
5. У фільтр введіть: gtag або collect
6. Перевірте, звідки приходять запити:

До GTG:

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

Після вмикання GTG (правильний стан):

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

Якщо бачите свій домен — GTG працює ✓

Перевірка № 2 — реальний трафік

1. Здійсніть на сайті тестову покупку або дію, яка запускає конверсію
2. Зайдіть у GA4 → Reports → Realtime
3. Перевірте, що подія з’явилася протягом 1–2 хвилин

Перевірка № 3 — Data Strength у Google Ads (через 7 днів)

Найважливіша метрика, яка покаже реальну користь GTG:

1. Google Ads → Tools and Settings → Measurement → Conversions
2. За кожною конверсією дивіться стовпець Data Strength (Сила даних)

Значення	Сенс	Коментар
🟢 High	GTG приносить більше ніж 15% повернутих даних	Чудовий результат
🟡 Medium	5–15%	Нормально
🟠 Low	Менше ніж 5%	Найімовірніше, потрібне додаткове доналаштування
⚪ Insufficient	Мало трафіку	Зачекати — Google потрібно більше даних

Перші 7 днів після вмикання метрика може ще не показувати фінальне значення — Google потрібно зібрати референсні дані.

---

6. Що насправді відбувається під капотом — технічний погляд

Цей розділ для тих, хто хоче зрозуміти, як саме GTG працює на рівні HTTP-запитів. Корисно, коли пояснюєте рішення своєму розробнику або технічному колезі.

Приклад № 1 — Завантаження скрипта gtag.js

ДО вмикання GTG — що відбувається при кожному завантаженні сторінки. Браузер надсилає:

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

Що бачить блокувальник реклами: домен googletagmanager.com у його чорному списку → запит відкинуто, скрипт не завантажується, трекінг не працює.

Що бачить Safari: скрипт від третьої сторони → застосовує обмеження ITP.

ПІСЛЯ вмикання GTG — те саме завантаження сторінки. Браузер надсилає:

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

Що бачить блокувальник реклами: домен eshop.cz — це ваш сайт, first-party → запит пропущено.

Що бачить Safari: first-party скрипт → жодних обмежень ITP.

Що відбувається на Cloudflare edge (невидимо для браузера): Worker перехоплює запит і робить server-to-server fetch на googletagmanager.com. Google відповідає тим самим скриптом, що й завжди. Worker повертає його браузеру. З погляду браузера це виглядає так, ніби скрипт прийшов прямо з вашого домену.

Як справи з cookies — важливе уточнення

GTG не змінює спосіб, яким створюються cookies. Cookies _ga і _gcl_aw так само створює скрипт gtag.js засобами JavaScript у браузері (а не сервер через HTTP-заголовок Set-Cookie).

Проблема	Чи вирішує GTG?
Блокувальники реклами блокують домен google-analytics.com	✅ Так
Safari застосовує ITP до скриптів від третьої сторони	✅ Так (скрипт тепер first-party)
Safari ITP обрізає створені JavaScript’ом cookies до 7 днів	❌ Ні (cookies так само створює JS)
Brave з CNAME uncloaking виявляє проксі	⚠️ Частково (залежить від версії)
iOS ATT обмежує Facebook Pixel	❌ Ні (інша проблема, інша платформа)

Для повного вирішення Safari ITP (cookies з довшим життям) потрібен server-side tagging (sGTM), де сервер створює cookies через HTTP-заголовки і позначає їх HttpOnly. Це окрема інфраструктура, поза межами GTG.

Що відбувається з вашими даними в Google

З погляду Google не змінюється нічого. Google отримує рівно ті самі дані, що й раніше — той самий payload, ті самі cookies, ті самі ідентифікатори. Різниця лише в тому, що дані йдуть через Cloudflare edge, а не напряму з браузера.

GTG — не рішення для захисту приватності від Google: у Google так само повний доступ до всіх даних, які він отримав би і без GTG. GTG лише забезпечує, що вони взагалі дійдуть.

---

7. Підсумок: що GTG фізично змінює

На рівні	Без GTG	З GTG
URL скрипта в HTML	googletagmanager.com/gtag/js	eshop.cz/gtm.js
URL конверсійного пінга	google-analytics.com/g/collect	eshop.cz/g/collect
Домен cookie (_ga)	.eshop.cz (уже сьогодні)	.eshop.cz (без змін)
Час життя cookie _ga	7 днів у Safari	7 днів у Safari (GTG не змінює)
Видимість для блокувальників реклами	заблокований	пропущений
Швидкість завантаження	з Google CDN	з Cloudflare edge (часто швидше)
Дані, які отримує Google	ті самі	ті самі

---

8. Після вмикання GTG (рекомендовані подальші заходи)

a) Enhanced Conversions (дуже важливо)

Якщо ще не ввімкнено, увімкнути в Google Ads:

1. Google Ads → Tools → Conversions → вибрати вашу конверсію
2. Enhanced Conversions for the web → Turn on
3. Метод: Google tag (автоматично бере дані з форм)
4. Домен: залишити налаштування за замовчуванням

Ефект: покращення зіставлення конверсій ще на 10–40% (офіційні дані Google).

b) Перевірка Consent Mode v2

Переконатися, що ваш CMP (Cookiebot / Usercentrics / OneTrust) правильно надсилає всі 4 сигнали:

• ad_storage
• analytics_storage
• ad_user_data
• ad_personalization

Без них Google Ads і GA4 в ЄС перестають збирати дані про нових відвідувачів — обов’язково з березня 2024.

c) Регулярне тестування

Раз на місяць перевіряти:

• Data Strength у Google Ads
• Обсяг подій у GA4 (не впав?)
• Realtime-звіт у GA4 (події приходять?)

---

9. Можливі проблеми та їх вирішення

Проблема	Причина	Вирішення
Після вмикання сайт завантажується неправильно	SSL mode у Cloudflare стоїть на «Flexible»	Cloudflare → SSL/TLS → перемкнути на Full (strict)
Data Strength залишається «Low»	Consent Mode v2 налаштований неправильно	Перевірити CMP, зв’язатися з нами
У DevTools так само бачу googletagmanager.com	Кеш браузера	Ctrl+Shift+R (hard refresh) або відкрити в анонімному вікні
GTM web container перестав працювати	Конфлікт із власним custom-доменом у GTM	GTM → Admin → Container Settings → видалити custom domain mapping
Конверсії виглядають задвоєними	Паралельно працює старий замір + GTG	Зазвичай ні — GTG не додає подій, він їх лише проксує. Перевірте інші джерела дублів
У перші години після вмикання бракує частини даних	Кеш edge-мережі поширюється	Зачекати 15–30 хвилин, за потреби Cloudflare → Caching → Purge Everything
GTG активний, але в HTML так само бачу googletagmanager.com	У CMS закрита шаблонна система — вона не дає вставити власний HTML-код у <head>, і GTM-сніпет генерується з жорстко заданим URL	Розгорнути Cloudflare Worker для HTML rewriting на edge — див. рішення нижче

Специфічні проблеми фази міграції (розділ 3)

Проблема	Причина	Вирішення
Домен 1–7 днів недоступний після зміни неймсерверів	DNSSEC не був вимкнений до зміни NS — DS-записи в parent registry все ще існують, резолвери повертають SERVFAIL	Вимкнути DNSSEC у реєстратора і зачекати, поки DS-записи спливуть (може тривати до 7 днів). Наступного разу: перевірка 3.3 крок 2 до зміни NS
Статус у Cloudflare залишається «Pending nameserver update» навіть через годину	Зміна NS у реєстратора чекає на e-mail confirmation від власника	Знайти лист від реєстратури / реєстратора з посиланням підтвердження. Якщо доступу немає — домовитися з клієнтом про пересилання
Листи перестали приходити	MX-записи не імпортувалися в Quick Scan або були поставлені на Proxied	Cloudflare → DNS → перевірити, що MX-записи стоять ☁️ DNS only (не Proxied) і вказують на правильний поштовий сервер. Дописати відсутні
Після міграції зламався renewal SSL-сертифіката на origin-сервері	CAA-записи з вихідної зони не імпортувалися	У Cloudflare → DNS додати CAA-записи вручну за експортом вихідної зони (зазвичай 0 issue "letsencrypt.org")
Конкретний субдомен (admin, FTP) перестав працювати за проксі	В origin-сервера whitelist IP-адрес, а проксі Cloudflare змінює вихідний IP	Перемкнути проблемний субдомен на ☁️ DNS only або додати діапазони IP CF у whitelist
Heureka / Google Merchant feed перестав читати дані	Кравлери не отримують відповідь за проксі Cloudflare (rate limit, bot challenge)	Cloudflare → Security → Bots → створити allow rule для known crawlers або тимчасово перемкнути субдомен із фідом на ☁️ DNS only

Коли CMS не дозволяє вставити власний HTML-код (рішення через Cloudflare Worker)

Трудомісткість усього рішення: реально 3–4 години — закладайте це чесно. Включає: аудит CMS (чи є взагалі якась можливість вставити свій HTML, чи це справді неможливо) → research альтернатив → написання і розгортання Worker’а → конфігурацію route з режимом Fail-open → перевірку в Chrome DevTools → перевірку в GA4 Realtime → контроль, що нічого не зламалося. Окремі кроки швидкі (клік в UI), але повний прохід разом із діагностикою, дебагом і перевіркою помітно довший, ніж «пара хвилин на Worker».

Проблема: Деякі закриті e-commerce платформи (наприклад, Binargon, деякі версії BigCommerce і старі шаблони Joomla) не генерують HTML через редаговане поле — GTM-сніпет жорстко зашитий у шаблоні з URL https://www.googletagmanager.com/gtm.js?id=.... Змінити її через адмін-інтерфейс не можна.

Cloudflare Google Tag Gateway хоч і проксує запити на /měření-cesta, але сам HTML не переписує — якщо GTM-сніпет на сторінці захардкоджений на googletagmanager.com, браузер завантажить його у третьої сторони, і весь сенс GTG зникає.

Рішення: Cloudflare Worker (~25 рядків коду), який сидить між відвідувачем і origin, читає HTML-відповідь і замінює URL на first-party шлях. Worker працює на краю мережі (edge), додає ~10 мс затримки, безкоштовний до 100 000 запитів на добу.

Коли це вам потрібно

• Ви активували GTG (розділ 4), і при перевірці (розділ 5) так само бачите в HTML googletagmanager.com
• У вашої CMS немає в адмінці поля «Власний HTML-код у шапці» / «Custom <head> insert»
• Провайдер CMS відмовляється або довго розмірковує над додаванням такої функції

Код Worker’а

Цей приклад використовує домен vase-domena.cz і вимірювальний шлях /pulse. Для власного розгортання замініть vase-domena.cz/pulse своїм доменом і вимірювальним шляхом, заданим у 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);
    }
  }
};

Розгортання через Cloudflare Dashboard (10 хвилин)

1. Cloudflare Dashboard (top-level, не всередині зони) → Workers & Pages → Create application → Create Worker
2. Вибрати Start with Hello World! → назвати (наприклад, vase-domena-gtg-rewriter) → Deploy
3. На сторінці Worker’а → Edit code → видалити код за замовчуванням → вставити код вище (не забудьте виправити URL) → Save and Deploy
4. Settings → Domains & Routes → + Add → Route: Zone: ваш домен Route: vase-domena.cz/* Failure mode: Fail open (proceed) — критично! При помилці Worker’а запит піде прямо на origin, сайт залишиться робочим
5. Опційно: вимкнути URL workers.dev у Domains & Routes (best practice — Worker не має бути доступним поза вашим route)

Перевірка

# 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 — що станеться, якщо Worker відмовить

Завдяки Failure mode: Fail open і try/catch усередині коду Worker має два незалежні шари захисту:

1. Внутрішній: catch (err) перехопить будь-яку помилку в логіці rewrite і поверне origin response без змін
2. Зовнішній: Якщо Worker впаде настільки фатально, що не відпрацює навіть catch (наприклад, timeout, OOM), Cloudflare обійде Worker цілком і надішле запит прямо на origin

Наслідок: сайт ніколи не впаде через Worker. У найгіршому разі GTG тимчасово перестане працювати (теги завантажаться від третьої сторони, як до активації) — жоден користувач помилки не побачить.

---

10. Реальні сценарії — що може піти не так

7 найчастіших ситуацій із практики. За кожною: як проявляється, як це з’ясувати, що з цим робити.

Сценарій № 1: Сайт після вмикання перестав завантажуватися

Симптоми: Користувачі бачать помилку ERR_SSL_VERSION_OR_CIPHER_MISMATCH або «Ця сторінка не захищена». У Cloudflare Analytics стрибком зростають 5xx-помилки.

Причина: У Cloudflare SSL mode стоїть на Flexible. GTG вимагає шифрованого зв’язку і між Cloudflare, і вашим початковим сервером.

Що зробити негайно (за 5 хвилин):

1. Дашборд Cloudflare → SSL/TLS → Overview
2. Перемкнути з Flexible на Full (strict)
3. Зачекати 30–60 секунд на поширення
4. Перевірити сайт в анонімному вікні

Сценарій № 2: Data Strength залишається «Low» навіть через 14 днів

Можливі причини (у порядку ймовірності):

1. Consent Mode v2 налаштований неправильно — користувачі в ЄС не погодилися на cookies → дані не надсилаються. Діагностика: GA4 → DebugView → стежити за сигналом ad_user_data. Якщо він постійно denied, проблема в CMP. Вирішення: ревізія конфігурації Cookiebot/Usercentrics.
2. Enhanced Conversions не активні Діагностика: Google Ads → Conversion → розділ Enhanced Conversions. Вирішення: увімкнути (порядок у розділі 8a).
3. Низький обсяг конверсій (менше ніж 30/місяць) Вирішення: зачекати, поки набереться достатньо даних (2–3 місяці).
4. Конфліктний custom domain у GTM Діагностика: GTM → Admin → Container Settings → Custom Domain. Вирішення: видалити або синхронізувати з налаштуванням GTG.

Сценарій № 3: У GA4 почали з’являтися задвоєні події

Причина: Одночасно працюють два шляхи надсилання подій: старий client-side трекінг (gtag.js через google-analytics.com) + новий через GTG (eshop.cz/g/collect). Теоретично такого бути не мало б, але це може статися, якщо:

• У вас кілька GTM-контейнерів на одній сторінці
• У вас вручну вставлений gtag.js на додачу до GTM
• Інший інструмент (скажімо, OptinMonster, Hotjar) теж надсилає в GA4

Діагностика:

1. View source сторінки (Ctrl+U) → знайти gtag → скільки разів він там?
2. GTM Preview mode → скільки тегів «GA4 Event» спрацьовує на одну подію?
3. GA4 → Admin → DebugView → відкрити тестову сесію і порахувати дублі

Вирішення: знайти й прибрати дублі на сторінці. Залишити лише одне джерело — або GTM, або прямий gtag, але не обидва.

Сценарій № 4: Стрибкоподібне зростання «New Users» і зміна Bounce Rate у GA4

⚠️ Важливо: це НЕ помилка

GTG почав вимірювати користувачів, у яких раніше трекінг був заблокований (ад-блокери, Safari). Ці дані у вас були завжди — просто ви їх не бачили.

• Нові користувачі зросли → бо користувачі з ад-блокерами раніше були невидимі
• Bounce rate змінився → у цих користувачів інша типологія поведінки (часто tech-savvy, швидше сканують)
• Конверсії зросли → їхній реальний вплив раніше був «примарним»

Що зробити: задати новий baseline. Графіки в GA4 візуально «зламаються» в день вмикання GTG — варто позначити це нотаткою в Annotations, щоб усі в команді знали, що сталося.

Сценарій № 5: Браузер Brave так само блокує трекінг

Причина: У Brave є функція CNAME uncloaking — він перевіряє, куди домен реально веде. Якщо виявить, що eshop.cz/gtm.js закінчується у трекінгового сервісу, може заблокувати запит.

Варіанти:

1. Прийняти — у Brave ~1% ринку, для більшості інтернет-магазинів знехтувано мало
2. Server-side tagging (sGTM) — це глибший проксі, який Brave виявляє гірше
3. Комбінація GTG + sGTM + same-origin deployment через CF Worker

Реалістичне очікування: Після вмикання GTG у вас буде покрито ~99% користувачів Chrome, ~90% Safari, ~95% Firefox, але лише ~50–70% Brave.

Сценарій № 6: GTM Preview mode перестав працювати

Причина: GTG може фільтрувати спеціальні debug-cookies і заголовки (X-Gtm-Server-Preview), які використовує GTM Preview.

Вирішення:

1. Cloudflare → Rules → створити bypass rule для вашої IP-адреси (на час дебагу)
2. Як альтернатива: дебаг в анонімному вікні з вручну виставленою debug-cookie
3. Після завершення дебагу bypass rule видалити

Сценарій № 7: «Ви обіцяли +11%, а я цього не бачу»

Реальний контекст:

• +11% — це медіана по всіх акаунтах (офіційні дані Google, квітень 2025)
• Розкид на практиці: +3% до +25%
• Конкретний результат залежить від: Структури аудиторії — клієнт із 80% Chrome без блокувальників побачить +3%, клієнт із 30% Safari і великою часткою користувачів з ад-блокерами побачить +20% Поточної якості Consent Mode — якщо він був налаштований погано, користь GTG буде замаскована вирішенням іншої проблеми Обсягу конверсій — у сайту з 10 конверсіями на місяць +11% статистично нечитабельні (для надійного заміру потрібно 100+ конверсій)

Як це правильно донести:

1. Метрику Data Strength у Google Ads вважайте головним індикатором, а не абсолютне число конверсій
2. Вікно 30 днів щонайменше, не 7 днів
3. Показати обсяг подій у GA4 (а не лише конверсій) — там різниця помітніша
4. Порівнювати week-over-week, а не день за днем (сезонність спотворює)

---

11. Що конкретно ви побачите в даних

У Google Ads

Коли	Що побачите
Одразу (день 1)	У Conversions → Diagnostics зникне попередження «Tag blocked». У DevTools — правильний домен у запитів.
Через 7 днів	Стовпець Data Strength зі значенням. All Conversions зазвичай зростає на 5–20%.
Через 14–30 днів	CPA може впасти на 5–15%. ROAS може зрости на 10–25%. Smart Bidding підлаштовується.

У GA4

Коли	Що побачите
Одразу	Realtime-звіт показує події з усіх браузерів. DebugView показує параметри gcs і gcd.
Тиждень 1–2	Event count зростає на 10–30%. Total Users зростає на 10–30%. Bounce Rate може змінитися (візуальний злам — нормально).
Місяць 1–3	Атрибуційні моделі точніші. Audiences зростають (більший пул для ремаркетингу).

Що НЕ ЗМІНИТЬСЯ (де GTG не допомагає)

Інструмент	Чому не зміниться
Facebook Ads Manager	GTG не включає Facebook Pixel
TikTok Ads	Інша екосистема
Snapchat, Pinterest, LinkedIn	Поза охопленням GTG
Klaviyo, Mailchimp, ActiveCampaign	Власні трекінгові інтеграції
Hotjar, Smartlook, Clarity	Власні скрипти
CRM (HubSpot, Pipedrive)	Зазвичай не пов’язані з GTG

Приклад конкретного інтернет-магазину (анонімізований)

Клієнт: середній інтернет-магазин у Чехії, місячний бюджет Google Ads ≈ 80 000 Kč.

Період	Конверсії Google Ads	CPA	Користувачі GA4	Data Strength
До GTG (серпень 2025)	245/місяць	327 Kč	38 400	—
Після вмикання (вересень 2025)	281 (+14,7%)	285 Kč (−12,8%)	47 200 (+22,9%)	Medium
Через 3 місяці (листопад 2025)	312 (+27,3%)	256 Kč (−21,7%)	—	High

Цей випадок вищий за медіану (+11%) — у клієнта початково був слабкий Consent Mode і велика частка аудиторії Safari. В інших клієнтів із уже добре налаштованим трекінгом покращення може бути суттєво меншим (+3–7%).

Timeline очікувань

Коли	Що побачите
Хвилина 1	DevTools показує правильний домен
Година 1	Realtime у GA4 відображає дані
День 1	Обсяг подій починає зростати
День 7	З’являється метрика Data Strength
Тиждень 2	Стійке значення Data Strength
Місяць 1	Зниження CPA завдяки кращій оптимізації
Місяць 2–3	Повний вплив на кампанії

---

12. Часті запитання

Чи можу я вимкнути GTG будь-якої миті? Так, тим самим способом, що й вмикання — один клік у Cloudflare. Зміна миттєва.

Чи вплине GTG на швидкість сайту? Позитивно. Скрипти Google завантажуються з edge-мережі Cloudflare, у якої 300+ локацій по всьому світу — зазвичай швидше, ніж оригінальний Google CDN. Заміри показують покращення LCP на 3–10%.

Чи можу я використовувати GTG з Google Tag Manager (GTM)? Так, вони повністю сумісні. GTG проксує і сам скрипт GTM.

Чи працює це для Facebook Pixel, TikTok, Pinterest? Ні. GTG працює виключно із сервісами Google. Для Meta/TikTok потрібен server-side tagging (sGTM) — окремий проєкт.

Чи підвищить це ціну за Cloudflare? Ні. GTG включений і в безкоштовний план Cloudflare. Він не зараховується в ліміт Workers requests.

Чи відповідає це GDPR? Саме по собі GTG не змінює правової ситуації — дані все одно опиняються в Google. Consent Mode v2 і ваш CMP мають бути налаштовані правильно (це умова і без GTG). Сам GTG згоду не обходить.

Скільки чекати видимих результатів? У Chrome DevTools результат видно одразу. Data Strength у Google Ads з’явиться через 7 днів. Повний вплив на кампанії — через 14–30 днів (алгоритми підлаштовуються під чистіші дані).

А якщо в мене сайт на Shopify? Shopify керує власним Cloudflare — доступу до його налаштувань у вас немає. Для Shopify рекомендуємо альтернативу: Enhanced Conversions + Shopify-застосунок для server-side трекінгу (Elevar, Conversios). Зв’яжіться з нами — підготуємо план.

---

13. Що нам потрібно від вас (чек-лист)

Якщо хочете, щоб GTG налаштували ми

• Доступ у дашборд Cloudflare (або додайте нас адміном)
• Підтвердження, що хочете проксі для: GA4, Google Ads, GTM
• Контакт технічного спеціаліста з боку клієнта для можливих питань щодо DNS/SSL
• Підтвердження, що у вас налаштований Consent Mode v2 (якщо ні — вирішимо)

✅ Якщо робитимете самі

• Пройти розділ 2 (з’ясувати свій сценарій) і розділ 3 (лише сценарій B — міграція на CF)
• Активувати GTG за розділом 4
• Провести перевірку за розділом 5
• Через 7 днів перевірити Data Strength у Google Ads
• Дати нам знати результати — допоможемо інтерпретувати

---

14. Очікуваний результат

Через 7 днів після вмикання:

• +11–25% повернутих конверсій у Google Ads
• Data Strength: Medium або High
• Обсяг подій у GA4 зріс

Через 30 днів:

• Краща оптимізація рекламних алгоритмів (на повніших даних)
• Зниження CPA на 5–15% у Google Ads (завдяки точнішій атрибуції)
• Точніші звіти для ухвалення рішень

Якщо цих результатів ви не побачите — зв’яжіться з нами, перевіримо правильність налаштування. Звичайні причини: погано сконфігурований Consent Mode, відсутні Enhanced Conversions, конфлікт з наявними custom domain у GTM.

---

15. Наступний крок після GTG

GTG — це перший поверх просунутішої інфраструктури трекінгу. Якщо у вас значний бюджет на Meta Ads / TikTok / Pinterest (від ~250 000 Kč на місяць), наступним кроком рекомендуємо:

Server-side tagging (sGTM) — окремий сервер, який обслуговує Meta Conversions API, TikTok Events API та інші платформи. Вирішує схожі проблеми, але для всієї рекламної лінійки. Ціна: 500–5 000 Kč/місяць + setup.

Це ми робимо окремим проєктом — дайте знати, якщо є сенс це обговорити.

---

✅ Повний чек-лист від початку до кінця

Фаза 1 — Міграція домену на Cloudflare (лише сценарій B, розділ 3):

• Акаунт Cloudflare створений, домен доданий (Add a Site)
• Quick Scan пройшов, DNS-записи перевірені (A/AAAA/CNAME/MX/TXT) — усе імпортовано
• Видалені артефакти старих NS-записів (на кшталт ns.registrátor.com) із зони
• SSL/TLS mode: Full (strict)
• DNSSEC вимкнений у поточному DNS (dig DS повертає порожньо)
• CAA-записи перевірені та перенесені (якщо були)
• Speed settings на дефолтах (Rocket Loader OFF, Polish disabled)
• Proxy status вирішений: 🟠 apex+www, ☁️ DNS only для чутливих субдоменів
• Неймсервери змінені у реєстратора на 2 неймсервери CF
• E-mail confirmation від реєстратури підтверджений (кліком за посиланням)
• Статус у CF Overview = Active
• Smoke-тест пройдений: сайт, www, пошта, субдомени, SSL, форми

Фаза 2 — Активація GTG (обидва сценарії, розділи 4–5):

• У Cloudflare → Rules → Google Tag Gateway = ON
• Позначені: GA4, Google Ads, GTM
• У DevTools у запитів бачу свій домен (не googletagmanager.com)
• У GA4 Realtime з’являються події

Фаза 3 — Додаткові заходи (розділ 8):

• Consent Mode v2 налаштований через CMP (Cookiebot/Usercentrics/OneTrust)
• Enhanced Conversions увімкнені в Google Ads
• У GA4 позначена Annotation у день вмикання (для командного контексту)
• Через 7 днів — перевірити Data Strength у Google Ads
• Через 30 днів — оцінити зміну CPA / ROAS

З будь-яких питань щодо налаштування — не соромтеся писати. [email protected]