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

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

В 2026 году у команд performance и аналитики одна боль почти у всех: данные рвутся на куски, а бизнес просит ответить на вопрос “что реально двигает выручку” без last-click-иллюзий. У Aviasales это проявилось после расширения трекинга на мобильные устройства, подключений у партнеров и перехода на более строгие privacy-настройки — часть событий стала теряться, а отчеты по воронке начали жить собственной жизнью.

Контекст
— Платформу и каналы (веб и мобильные сценарии) подключали разными способами, и каждый раз появлялся “локальный” счетчик, который учитывал чуть иначе.
— В аналитике выросла доля расхождений между источниками: формы “дошли” до одного отчета, но не “дошли” до другого; визиты в одной системе считались, в другой — уходили в “неизвестное”.
— Маркетинг в логике RevOps (responsibility за выручку всей цепочки) хотел одинаковую терминологию: что считать лидом, что — квалифицированным действием, а что — шагом к покупке.

Задача
1) Собрать события так, чтобы логика была одинаковой для всех каналов и устройств.
2) Уменьшить влияние блокировок/потерь на стороне браузера и приложений.
3) Сделать атрибуцию управляемой: не “последний клик”, а более надежную картину по поведению и качеству.
4) Дать Sales/Customer Success метрики, на которые можно опираться: без сюрпризов в определениях MQL/SQL-эквивалентов и без “плавающих” конверсий.

Решение (GTM recipes)
Мы спроектировали трекинг вокруг server-side GTM (серверная витрина событий) и дисциплины схемы данных.

— Контракт событий (единый словарь)
Определили ключевые события: view_search, submit_quote, start_booking, booking_success, плюс вспомогательные — login_attempt, coupon_view (если применимо). Для каждого события задали: обязательные параметры, допустимые значения и правила “когда событие имеет право стрелять”.

— Транспорт: из клиента на сервер
В браузер/GTM Web оставили минимальный сбор: отправка “сырых” событий на endpoint server-side контейнера. Так удалось снизить потери от блокировок на клиенте и контролировать формат/валидацию до отправки в GA4/BI/CRM.

— Валидация и дедупликация
На сервере добавили фильтры:
— проверка обязательных параметров (например, route/страница, тип запроса, валюта, идентификатор сессии)
— контроль повторов по event_id + timestamp bucket
Это убрало эффект “троения” событий при повторной отрисовке страницы/возврате в приложение.

— Enrichment до передачи в аналитику
В server-side добавили нормализацию utm-параметров (с правилом приоритета, чтобы источник не конфликтовал с переадресациями), гео-агрегацию по разрешенным данным и маркировку по типу пользователя. Важно: все изменения протоколировали — чтобы аналитики видели, *почему* параметр стал таким.

— Связка с конверсией (booking_success как North Star)
Сделали “лестницу” промежуточных событий и отдельные события для отказов (например, quote_failed/booking_cancel), но в отчетах закрепили главную конверсию — booking_success. Это позволило не терять детализацию и при этом не “размывать” KPI.

— Релевантность к RevOps
Для передачи в CRM/BI задали маппинг: какие события формируют “лидоподобный” сигнал (например, submit_quote) и какие — “качественный” (start_booking + booking_success). Сustomer success получил события, которые помогают объяснять retention-поведение: повторные поиски после неуспешного шага, возврат к бренду и т.д.

Результат
После внедрения и выверки схемы:
— доля потерянных/несогласованных событий в отчетах по ключевой воронке сократилась (по внутренним замерам команды) на **20–30%** относительно базовой линии до server-side.
— расхождения “веб vs аналитическая витрина” по booking_success уменьшились до диапазона погрешности **в пределах 1–3%**.
— время на разбор расхождений у аналитиков сократилось примерно на **40%**: вместо “каждая система по-своему” появилась единая проверяемая логика (контракт событий + правила дедупликации).
— маркетинг получил более стабильную картину для оптимизации: кампании перестали “выглядет
…