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

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

Контекст
В 2026 году у travel-сайтов конкуренция не в баннерах и не в “похожести креатива”, а в том, как быстро они доказывают ценность для пользователя и бизнеса. Aviasales (как и многие) столкнулся с типичной проблемой: кампании вроде бы “покрываются”, но конверсия в заявку/бронирование ведёт себя нестабильно, а атрибуция становится менее предсказуемой из‑за privacy-first: last-click всё хуже отражает вклад каналов.
Параллельно росло значение RevOps: маркетинг отвечает не только за лид, но и за то, что из лида реально становится выручкой (а не “ещё одним визитом”).

Задача
Нужно было перестать оптимизироваться по “удобным” сигналам (просмотр страницы/клик по CTA) и начать оптимизацию по событиям, которые коррелируют с итоговым действием. Внутри были три боли:
— в GA4 часть ключевых событий уходила с разной структурой (одни и те же действия назывались по‑разному)
— воронка в отчётах не совпадала с тем, что видит продукт (разные шаги, разные URL-ветки)
— модели оптимизации “видели” шум: пользователи доходили до формы, но событие завершения происходило не всегда корректно

Решение (шаги как рецепт)
1) Провели аудит событий по принципу “вес ингредиента”
Сравнили в GA4 фактические события с логикой продукта: клик — это не заказ; отправка формы — не бронирование. Для каждого ключевого шага ввели единый контракт: название события + параметры (в частности, тип поиска, источник предложения, валюта/дата, статус).
Цель — чтобы одно и то же действие в разных экранах давало одно и то же событие с одинаковыми параметрами.

2) Переопределили воронку так, чтобы она отвечала бизнес-логике
Собрали новую воронку в Exploration (Исследования):
— шаг 1: пользователь начал поиск (с параметром “тип поиска”)
— шаг 2: переход к предложению (с параметром “тип тарифа/агрегатора”)
— шаг 3: отправка запроса (с параметром “статус”)
Финальный шаг сопоставили с backend-событием (серверная передача), чтобы отсечь “клики в никуда”.

3) Вынесли критичные события на server-side (серверная передача) для приватности и стабильности
Там, где клиентский трекинг чаще “терялся” (ошибки, межстраничные переходы, блокировки), подняли отправку через сервер. Это уменьшило разрыв между тем, что пользователь делает в UI, и тем, что попадает в GA4.

4) Настроили “качество” как отдельную метрику внутри отчётов
Вместо вопроса “сколько конверсий” начали смотреть “доля конверсий по корректным параметрам”: событие засчитывалось только при заполненных обязательных параметрах. Так шум перестал влиять на оптимизацию.

5) Проверили связку с рекламными целями и тестировали инкрементальность
Поскольку в 2026 атрибуция last-click теряет точность, сравнивали изменения по группам: где улучшили трекинг и воронку, а где оставили как было. Параллельно оценивали эффект через подходы наподобие incrementality (инкрементальность): смотрели, что меняется не только в отчётах, но и в итоговых показателях бизнеса.

Результат
После стандартизации событий и переноса критичных сигналов серверной передачей:
— доля “некорректных” ключевых событий упала на 31% (по параметрам)
— конверсия в следующий шаг в воронке выросла на 12% за счёт того, что оптимизация перестала обучаться на кликовом шуме
— стоимость эффективного действия (определённого как прохождение всех шагов до бизнес-события) снизилась на 18%
Отдельно важно: общая стабильность отчётности стала выше — меньше расхождений между продуктовой логикой и тем, что видит аналитика. Это как калибровка весов: когда единицы измерения одинаковые, “рецепт” начинает работать.
…