Серверный Google Tag Manager оброс обещаниями: вернёт потерянные конверсии, обойдёт блокировщики, починит атрибуцию. Часть этого правда, часть — нет, и разница видна только после того, как поставишь его сам.
Мы поставили. Ниже — решения, которые пришлось принять, и что из них вышло.
Что вообще меняется
В классической схеме браузер отправляет данные на домены Google. В серверной он отправляет их на ваш собственный эндпоинт, а уже тот передаёт их дальше — в аналитику, в рекламные системы, куда нужно.
Меняется не то, что вы измеряете. Меняется, чьим доменом подписан запрос и кто контролирует данные по дороге.
Главное решение: путь, а не поддомен
Стандартный совет — выделить поддомен вроде t.вашсайт.com. Мы начинали именно так и потом переделали на директорию на домене самого сайта. Причина того стоит.
Поддомен t.сайт.com
- блокируется списками — это имя хоста
- требует отдельной записи в CSP
- новая DNS-запись и новый сертификат
- работает даже если сайт на чужом хостинге
Единственное реальное преимущество поддомена — он не требует контроля над веб-сервером сайта.
Путь /сборник
- не блокируется без блокировки сайта
- уже покрыт правилом self в CSP
- никакого DNS и никакого сертификата
- нужен контроль над веб-сервером
Тот же origin означает, что для строгой политики безопасности это просто ваш сайт.
Блокировка — решающий пункт. Поддомен это имя хоста, а имена хостов попадают в списки. Выбирать t. вместо gtm. означает лишь обойти простейшие из них. Директория на домене сайта не блокируется иначе, чем вместе с сайтом.
Второе преимущество оказалось очень конкретным. Наш сайт отдаётся со строгой политикой безопасности без подстановок, и каждый новый домен для тегов там пришлось бы добавлять отдельно — то есть менять код и передеплоивать. Тот же origin не требует ни строки.
Цена этого решения тоже конкретна: нужен контроль над веб-сервером, который отдаёт домен. Пока сайт стоял на чужом шаред-хостинге, сделать так было невозможно — маршрут к директории настраивается там, где живёт домен. Именно поэтому работа ждала переезда сайта, а не наоборот.
Ловушка с поддоменом, в которую мы попали
Один случай стоит рассказать, потому что он не гуглится.
Превью-сервер сначала подняли тоже на поддомене. Оказалось, что общая символьная запись *.домен резолвила его на прокси старого хостера, чей сертификат выписан на совсем другое имя. Сервер тегов пошёл туда по HTTPS, получил несоответствие имени в сертификате — и режим превью отдавал HTTP 500 без всякой подсказки, что дело в DNS.
Перенос превью на директорию убрал из уравнения и DNS, и сертификат сразу. Мораль уже, чем «путь лучше»: каждый поддомен, который вы добавляете, наследует чужие записи, о которых вы забыли.
Что это действительно чинит, а что нет
| Что говорят | Что на самом деле | Масштаб |
|---|---|---|
| «Вернёт потерянные конверсии» | часть — те, что терялись на блокировке запросов к чужим доменам | проценты, не половина |
| «Обойдёт блокировщики» | запрос к своему домену не блокируется; само событие всё равно требует согласия | зависит от доли согласий |
| «Продлит жизнь кукам» | да — кука ставится вашим сервером, а не третьей стороной | реальный эффект, особенно в Safari |
| «Ускорит сайт» | только если вынести на свой домен ещё и загрузку скриптов | отдельный шаг, не из коробки |
Главное, чего оно не делает: не видит людей, которые не дали согласия, и не восстанавливает данных, которых не было. Серверная схема улучшает доставку — она не создаёт событий.
Пункт о скорости стоит раскрыть, потому что он контринтуитивен. Базовый серверный контейнер умеет принимать измерения аналитики — и возвращает ошибку на попытки отдать из него сами скрипты. Это не поломка: чтобы отдавать ещё и JavaScript со своего домена, в контейнер добавляется отдельный клиент. Именно тот шаг даёт выигрыш в скорости; сама по себе серверная схема его не даёт.
Сколько это стоит
Три варианта, и разница между ними не в деньгах, а в том, чья это ответственность.
Готовый сервис. Ежемесячная плата, ноль настроек, данные проходят через посредника.
Облако крупного провайдера. Плата за использование, автоматическое масштабирование, стандартный путь из документации.
Свой сервер. Если коробка уже есть — фактически бесплатно: образ весит около 110 МБ, одной виртуальной машины достаточно, больше одного ядра на экземпляр не используется вообще.
И здесь нужна честность, которой в описаниях этой технологии обычно недостаёт. Рекомендация вендора для продакшена — не менее трёх экземпляров. Мы сознательно работаем на одном. Это значит, что перезапуск контейнера — это пропуск в сборе данных, а не замедленный ответ. Для агентского сайта приемлемо; для магазина с миллионными оборотами — нет.
Ещё одна деталь из собственных граблей: контейнеры не стоит публиковать портами наружу. Docker пишет собственные правила фаервола в обход обычного, поэтому опубликованный порт доступен из мира, что бы ни показывал статус фаервола.
Кому это нужно, а кому нет
Не нужно, если у вас ещё не настроено обычное отслеживание конверсий. Серверная схема улучшает доставку события — она не делает событие правильным. Сначала цепочка от формы до отчёта, потом всё остальное.
Нужно, если вы упираетесь в потолок: значительная доля трафика из браузеров, ограничивающих сторонние куки, длинный цикл сделки, где важно не потерять связь между визитами, или требование держать данные у себя.
Промежуточный вариант — начать с измерения потерь. Сравните количество заявок в своей CRM с количеством конверсий в аналитике за тот же месяц. Разрыв и есть верхняя граница того, что серверная схема способна отыграть.
С чего начать
Проверьте базовое: совпадают ли цифры конверсий с реальными заявками. Чек-лист аналитики проходит это за шесть блоков, и его стоит закрыть до любых серверных работ.
Если базовое в порядке и вопрос в том, стоит ли серверная схема захода именно у вас, — посмотрите, как мы работаем с аналитикой и отслеживанием.