Онлайн-школа из урока про устройство серверного GTM уже месяц отправляет данные через сервер. В понедельник таргетолог открывает отчёт за прошлую неделю. На рекламу ушло 200 000 ₸: 120 000 ₸ в Instagram и 80 000 ₸ в Google. В CRM за неделю 15 оплат курса за 25 000 ₸, из них 12 пришли по рекламным меткам, по 6 из Meta и Google. Оплаты из Telegram и без меток в ROAS не входят, так что по CRM выходит 300 000 ₸ на 200 000 ₸, то есть 1,5. GA4 показывает 4 покупки с рекламы на 100 000 ₸ и ROAS 0,5, и все четыре пришлись на понедельник и вторник (цифры условные). Кампании никто не трогал, зато в среду разработчик опубликовал в серверном контейнере новое преобразование.
Совпадение по времени - повод открыть контейнер, а не готовый вывод. Разберём, где серверный GTM теряет нужные тегу поля и где пропускает лишние, а в конце найдём причину этой недели в предварительном просмотре.
Когда полей три, Allow и Exclude дают одно и то же
| Поле исходного события | Exclude internal_note | Allow event_name, value |
|---|---|---|
| event_name | Остаётся | Остаётся |
| value | Остаётся | Остаётся |
| internal_note | Убирается | Убирается |
В настоящем событии GA4 полей больше: этот Allow уберёт client_id и адрес страницы, нужные тегу.
Кто забрал запрос
Запрос забирает первый подходящий клиент по приоритету клиентов, а какие запросы клиент считает своими, решают условия активации. Клиент GA4 по умолчанию отвечает на стандартные пути GA4 вроде /g/collect (клиент GA4).
На рабочем проекте клиентов в контейнере бывает несколько, и отсюда первая поломка, которую ищут в предварительном просмотре. Допустим, клиент для данных из CRM настроен принимать запросы на любой путь и стоит выше клиента GA4. Тогда запросы сайта до клиента GA4 не доходят, и тег GA4 молчит, хотя на сайте всё в порядке. На вкладке «Запрос» видно, какой клиент забрал запрос (предварительный просмотр и отладка). Если там не тот, кого вы ждали, причина найдена.
Данные события: что лежит внутри
Клиент собирает данные события, и дальше теги и преобразования работают только с ними. Часть полей в них клиент заполняет сам, по самому запросу: client_id, IP-адрес в ip_override, user_agent, адрес страницы. В списке общих параметров Google есть и user_data с email, телефоном и адресом, если отправитель их передал (общие данные событий). Так что персональные данные на сервере - это обычное поле в событии, которое любой тег может переслать дальше.
Из одних и тех же данных каждый тег берёт своё. Тег GA4 забирает всё, что собрал клиент GA4, а тег Meta или TikTok раскладывает поля по формату своего получателя. Поэтому то, что ушло получателю, смотрят по каждому тегу отдельно, в его исходящем запросе. Если параметр нужен в другом теге, его достают переменной типа Event Data, указав имя параметра в Key Path (отправка данных на сервер).
Преобразования: порядок и область действия
У каждого из трёх типов преобразований своё слабое место (преобразования):
| Тип | Где ломается |
|---|---|
| Allow | Отбрасывает всё, чего нет в списке, включая поля, без которых не работают теги Google |
| Augment | Меняет значение, которое тег ожидал получить в другом виде |
| Exclude | Убирает обязательное поле, и тег не срабатывает |
По умолчанию порядок такой: Allow, затем Augment, затем Exclude. Из него следуют две вещи. Параметр, который добавил Augment, тег получит, даже если его нет в списке Allow: к этому моменту Allow уже отработал. А Exclude срабатывает последним и уберёт параметр, даже если Augment его только что добавил. Порядок меняют приоритетом, и у кого число больше, тот срабатывает раньше. Поменяли приоритет - перечитайте все преобразования, которые касаются того же тега.
Без выбранных «Затронутых тегов» преобразование действует на все теги сразу. Так в контейнере школы и оказался узкий Allow: его делали для одного тега, а получили все.
Теперь о таблице. В обоих столбцах у тега остались event_name и value, и к такому результату ведут два разных преобразования. Exclude с internal_note убирает одно поле, остальное тег получает как раньше. Allow с event_name и value оставляет только эти два поля. В таблице разницы не видно, потому что в событии всего три поля. В настоящем событии GA4 их намного больше, и Allow отрежет client_id, адрес страницы и всё, без чего тег GA4 не работает.
Где это видно. В предварительном просмотре выберите событие и откройте вкладку «Теги». Сведения о преобразованиях есть только у сработавших тегов: там указано, какие преобразования прошли и в каком порядке, а блок «Данные события» с отметкой «Показать исходные данные» показывает поля до и после. Если преобразование убрало обязательное поле и тег не сработал, сведений не будет, и искать надо в списке преобразований.
Согласие на сервер приходит по-разному
В базовом режиме согласия теги Google без согласия не загружаются вовсе, и от таких посетителей сервер ничего не получит. В расширенном режиме теги загружаются всегда, а при отказе отправляют обезличенные измерения без cookies (consent mode на сервере). То есть в расширенном режиме до сервера доходят события и тех, кто отказался: недаром в примере Google с Exclude параметры убирают у запросов, где gcs равен G100 или G110. Теги Google подстроятся под отказ сами. Тег Meta или TikTok сработает по своему триггеру, если вы не поставили условие на согласие, поэтому после перехода сайта на расширенный режим каждый сторонний тег в серверном контейнере перепроверяют отказом, как в разборе Consent Mode v2 и server-side GTM.
Свой домен - это контекст, а не гарантия
Поддомен или путь на основном домене дают серверу контекст сайта: он может ставить свои cookies, в том числе HttpOnly (свой домен для сервера). На этом заслуги домена заканчиваются. Законной передачу данных он не делает, и согласие посетителя по-прежнему решает, какие теги могут сработать. Сервер с адресом на вашем домене всё так же работает в Google Cloud или у провайдера, а владелец этой среды может иметь доступ к данным (ручная настройка). Сколько проживёт cookie, решает браузер по своим правилам, и запись в DNS их не меняет. Экземпляры, журналы и расходы на сервер выбирают вместе с хостингом sGTM.
Отладка до ответа получателя
На одном тестовом событии пройдите цепочку в предварительном просмотре:
- Слева есть входящий запрос и события под ним. Запроса нет - ищите проблему у отправителя: адрес сервера и браузер, в котором открыт просмотр.
- На вкладке «Запрос» в блоке клиента стоит тот клиент, которого вы ждали.
- В «Данных события» имя события,
value,currencyиtransaction_idтакие же, как на сайте. - На вкладке «Теги» нужный тег сработал, а в его сведениях видно, какие преобразования прошли.
- На вкладке «Запрос» в исходящих запросах видно, что ушло получателю и какой код ответа он вернул.
- На вкладке «Консоль» нет ошибок тегов.
Сработавший тег и ответ 200 значат, что контейнер сделал свою работу. Верна ли сама покупка, покажет только сверка номеров заказов с CRM. После публикации поток смотрят у получателя (отчёт в реальном времени GA4, диагностика в Events Manager) и в журнале сервера.
Упражнение: найдите пропавшие покупки
Возьмите тестовый серверный контейнер, который вы собрали по уроку про устройство серверного GTM, и повторите неделю школы.
Выполнено 0 из 5
После первого шага тег GA4 не сработает или завершится ошибкой: Allow отбрасывает поля, которые нужны тегам Google. Тот же Allow без затронутых тегов режет поля у всех тегов, поэтому смотреть надо каждый, а не только GA4. В ситуации школы причина подтверждается тем же способом: пять дней без покупок в GA4 только подсказали, куда смотреть, а доказал её повтор в предварительном просмотре. Сообщение заказчику может выглядеть так: «В среду в серверный контейнер добавили фильтр полей для журнала выручки. Он применился ко всем тегам, и нужные поля перестали получать тег GA4 и рекламные теги: в Meta и Google Ads покупок со среды тоже нет, а на тестовой покупке мы это повторили. Фильтр ограничили одним тегом, покупки снова уходят во все системы, а ROAS за прошлую неделю считаем по CRM: 12 оплат с рекламы, 300 000 ₸ на 200 000 ₸ расхода, то есть 1,5».
Видео: настройка серверного GTM
Видео на русском.