Google Tag Gateway через Cloudflare — подробная инструкция

Как за 10–15 минут включить Google Tag Gateway через Cloudflare и вернуть 11–25% потерянных конверсий в Google Ads и GA4. Шаг за шагом, на русском.

Коротко: что вы получите из этой инструкции

Для кого: интернет-магазины, у которых домен уже на 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 минуты)

Регистрация на cloudflare.com — бесплатного плана хватает большинству интернет-магазинов
Add a Site → введите свой домен (без www) → выберите Free plan
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 значения скопируйте.

В панели вашего регистратора:

Найти раздел для неймсерверов — называется по-разному: «Nameservers», «DNS Settings», «Сменить неймсерверы», «NSSET» (регистратура .cz), «Manage DNS», «Edit nameservers»
Удалить / заменить все текущие неймсерверы
Вставить 2 неймсервера от Cloudflare
Сохранить / 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

Откройте свой интернет-магазин в браузере Chrome
Нажмите F12 (или правая кнопка → Inspect)
Переключитесь на вкладку Network
Обновите страницу (Ctrl + R / Cmd + R)
В фильтр введите: gtag или collect
Проверьте, откуда приходят запросы:

До 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 — реальный трафик

Совершите на сайте тестовую покупку или действие, которое запускает конверсию
Зайдите в GA4 → Reports → Realtime
Проверьте, что событие появилось в течение 1–2 минут

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

Самая важная метрика, которая покажет реальную пользу GTG:

Google Ads → Tools and Settings → Measurement → Conversions
По каждой конверсии смотрите столбец 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:

Google Ads → Tools → Conversions → выбрать вашу конверсию
Enhanced Conversions for the web → Turn on
Метод: Google tag (автоматически берёт данные из форм)
Домен: оставить настройку по умолчанию

Эффект: улучшение сопоставления конверсий ещё на 10–40% (официальные данные Google).

Убедиться, что ваш 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 минут)

Cloudflare Dashboard (top-level, не внутри зоны) → Workers & Pages → Create application → Create Worker
Выбрать Start with Hello World! → назвать (например, vase-domena-gtg-rewriter) → Deploy
На странице Worker’а → Edit code → удалить код по умолчанию → вставить код выше (не забудьте поправить URL) → Save and Deploy
Settings → Domains & Routes → + Add → Route: Zone: ваш домен Route: vase-domena.cz/* Failure mode: Fail open (proceed) — критично! При ошибке Worker’а запрос пойдёт прямо на origin, сайт останется рабочим
Опционально: выключить 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’а два независимых слоя защиты:

Внутренний: catch (err) перехватит любую ошибку в логике rewrite и вернёт origin response без изменений
Внешний: Если 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 минут):

Дашборд Cloudflare → SSL/TLS → Overview
Переключить с Flexible на Full (strict)
Подождать 30–60 секунд на распространение
Проверить сайт в анонимном окне

Сценарий № 2: Data Strength остаётся «Low» даже через 14 дней

Возможные причины (в порядке вероятности):

Consent Mode v2 настроен неправильно — пользователи в ЕС не согласились на cookies → данные не отправляются. Диагностика: GA4 → DebugView → следить за сигналом ad_user_data. Если он постоянно denied, проблема в CMP. Решение: ревизия конфигурации Cookiebot/Usercentrics.
Enhanced Conversions не активны Диагностика: Google Ads → Conversion → раздел Enhanced Conversions. Решение: включить (порядок в разделе 8a).
Низкий объём конверсий (меньше 30/месяц) Решение: подождать, пока наберётся достаточно данных (2–3 месяца).
Конфликтующий 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

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

View source страницы (Ctrl+U) → найти gtag → сколько раз он там?
GTM Preview mode → сколько тегов «GA4 Event» срабатывает на одно событие?
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 заканчивается у трекингового сервиса, может заблокировать запрос.

Варианты:

Принять — у Brave ~1% рынка, для большинства интернет-магазинов пренебрежимо
Server-side tagging (sGTM) — это более глубокий прокси, который Brave обнаруживает хуже
Комбинация 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.

Решение:

Cloudflare → Rules → создать bypass rule для вашего IP-адреса (на время дебага)
Как альтернатива: дебаг в анонимном окне с вручную выставленной debug-cookie
После завершения дебага bypass rule удалить

Сценарий № 7: «Вы обещали +11%, а я этого не вижу»

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

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

Как это правильно донести:

Метрику Data Strength в Google Ads считайте главным индикатором, а не абсолютное число конверсий
Окно 30 дней минимум, не 7 дней
Показать объём событий в GA4 (а не только конверсий) — там разница заметнее
Сравнивать 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]

Ещё по теме

24 апреля 2026 г.