Разбор: как Aviasales сделал передачу данных бронирования видимой в отчётах и не потерял модель атрибуции

Разбор: как Aviasales сделал передачу данных бронирования видимой в отчётах и не потерял модель атрибуции

Контекст

У Aviasales высокая доля прямых переходов в приложение и повторных визитов. Путь пользователя нелинейный: увидел push-уведомление → открыл приложение → искал билеты через два дня → купил через десктоп-сайт. Стандартная схема Google Tag Manager (GTM) с одним пикселем рекламной платформы в браузере теряла этап между устройствами и ломала корректное отнесение выручки к источнику. Команда аналитики это понимала, но решение откладывалось: текущая отчётность «как-то работала», а миграция казалась дорогой.

Задача

Связать событие «бронирование завершено» с конкретным визитом и источником, из которого начался путь, даже если между первым касанием и покупкой прошло неделя и сменилось устройство. В рамках privacy-first атрибуции это означало переход на серверный GTM (sGTM) с собственной прокси-цепочкой и нормализацию идентификаторов пользователя.

Решение

— Подняли серверный контейнер GTM (sGTM) в облаке. Сайт и приложение стали отправлять данные в один endpoint (единая точка приёма).
— В браузерном GTM оставили только сбор first-party данных и client_id (идентификатор клиента в Google Analytics). Тег рекламной платформы больше не срабатывал в браузере.
— На сервере настроили custom template (пользовательский шаблон) для enrichment (обогащения) события: подтягивали user_id (идентификатор пользователя) из CRM по client_id, добавляли в payload (тело запроса) сумму брони и валюту.
— В мобильном SDK (комплекте средств разработки) включили передачу того же user_id. На стороне sGTM склеивали сессии по этому ключу, если client_id менялся.
— Для GA4 оставили стандартный measurement protocol (протокол передачи данных), но события из приложения и сайта теперь попадали в один stream (поток) с общим user_id.
— В офлайн-конверсии рекламным кабинетам уходил обезлишенный хеш user_id + сумма и валюта брони. Никакой передачи email, телефона или PII (персональных данных) в payload.

Результат

— Доля бронирований, которым корректно присвоен источник первого касания, выросла с ≈55% до ≈82% по внутренней сверке.
— В отчётах по кампаниям в рекламных кабинетах выручка в performance-источниках «упала» в среднем на 12–15%. Это была не потеря, а перераспределение: модель атрибуции по first-click забирала выручку у брендовых кампаний и отдавала её performance, чего раньше не происходило из-за потери данных.
— Доля анонимных событий (без user_id) в GA4 снизилась с 38% до 19%. Это прямой показатель качества склейки.
— Команда отметила, что отчёты стали «спорить» между собой реже: раньше GA4 и рекламный кабинет расходились на 25–30% по выручке, после миграции разница сократилась до 8–10%.

Урок

В 2026 году браузерная атрибуция — это заведомо потерянные 15–25% событий. Server-side GTM (серверная сторона диспетчера тегов) — не про «модный стек», а про корректную экономику решений. Если вы оптимизируете рекламный бюджет по отчёту, в котором треть выручки не привязана к источнику, вы оптимизируете вслепую.

Миграция занимает 4–6 недель для среднего проекта. Большая часть этого времени уходит не на код, а на описание событий в data layer (уровень данных) и согласование схемы с командой продукта. Без этого серверный контейнер превращается в дорогой прокси, который передаёт те же обрезки данных, что и раньше.

И ещё один практический момент, который часто упускают: переход на sGTM — повод пересмотреть data layer. Не переносите старую структуру событий «как есть» только потому, что её уже используют дашборды (информационные панели). На сервере у вас впервые появляется чистое место

— @GTMrecipesRuPro