Server-side GTM и “сделка” между аналитикой и безопасностью: кейс Aviasales и защита данных при росте точности

Server-side GTM и “сделка” между аналитикой и безопасностью: кейс Aviasales и защита данных при росте точности

В 2026 многое поменялось в учёте: last-click уже не главный, растёт доля server-side (серверная отправка событий), а privacy-first подход требует дисциплины по сбору данных. На практике это выглядит так: маркетинг хочет точные метрики, а ИБ и юристы — минимизацию и контроль. Классическая ловушка — “починили теги, но сломали доверие” или “сделали безопасно, но получили хаос в данных”.

Контекст
Aviasales вёл активную performance-коммуникацию (поиск билетов, ретаргет, CRM-переходы), а измерения постоянно упирались в три вещи:
— уменьшение доли “видимых” идентификаторов из‑за ограничений браузеров;
— разрывы между тем, что регистрирует сайт, и тем, что реально происходит воронке (переходы, возвраты, отмены брони);
— требования комплаенса: меньше персональных данных, больше агрегированного и управляемого.

Задача
Нужно было одновременно:
1) перевести ключевые события в server-side, чтобы уменьшить потери при блокировках и повысить стабильность отправки;
2) сделать “контракт” данных: что именно мы отправляем (поля), как мапим (соответствие параметров), и кто отвечает за изменения;
3) сохранить связку с ключевыми целями (просмотр результатов поиска, клик по тарифу, начало бронирования, подтверждение), чтобы команда могла оценивать эффективность кампаний не по “красивым кликам”, а по бизнес-минимуму.

Решение
Команда сделала рецепт в логике GTM: сначала нормализация, потом маршрутизация, затем контроль качества.

— Контроль событий через единый событийный словарь
В GTM сформировали стандартизированные события и параметры:
view_search (просмотр результатов), click_offer (клик по тарифу), begin_booking (начало бронирования), purchase_booking (подтверждение/оплата).
Для каждого события описали обязательные поля (например, тип перелёта, валюту, агрегированную цену диапазоном, без лишних персональных).

— Server-side отправка через “мапу” из браузера
На стороне клиента оставили только минимальную обвязку: отправка событий в контейнер/endpoint с заранее утверждёнными параметрами.
На сервере — валидация схемы: если параметр не входит в словарь или выглядит как “неразрешённое поле”, событие логируется и отбрасывается до попадания в хранилище.

— Дедупликация и согласование таймингов
Чтобы не раздувать объём данных и не ломать конверсию, добавили дедуп по transaction-like параметрам: один и тот же “begin_booking” не должен уходить повторно при ретраях сети.
Отдельно синхронизировали тайминги: “purchase_booking” связывали с ближайшим корректным “begin_booking”, а не просто по счетчикам.

— Версионирование и роль владельца тега
Любое изменение payload (набора параметров) проходило через версионирование событийного словаря. У маркетинга и у аналитиков появился общий интерфейс правок: что можно менять без ИБ, что требует согласования.

Результат
После внедрения подхода Aviasales получил два измеримых эффекта:
— устойчивость отправки ключевых событий: доля “провалившихся” событий в цепочке снизилась за счёт серверной обработки сетевых сбоев и блокировок;
— качество аналитики: отчёты по верхней и нижней частям воронки стали совпадать с фактическим поведением пользователей (особенно по переходам “клик по тарифу → начало бронирования”).

Если говорить цифрами уровня управления (не обещая “магии”), типовой результат таких внедрений в крупных проектах выглядит как снижение несоответствий между событиями на десятки процентов и рост доли корректно связных конверсий на заметный процентный пункт в сравнении с браузерной отправкой. Важнее другое: измерение стало предсказуемым, а значит — управляемым.
…