Контракт post-click событий: как договориться о данных между лендингом и трекером

Редакция mevrica

Рекламные технологии4 мин чтения

Обновлено 2 августа 2026 г.

Контракт post-click событий нужен, чтобы лендинг, трекер и отчёт одинаково понимали слова session, registration и qualified action. Это короткая договорённость о том, когда событие возникает, что оно означает и какие поля обязаны сопровождать его. Без контракта каждая команда реализует собственную версию воронки.

Простой критерий

Событие должно описывать завершившийся факт, а не намерение разработчика. Название, момент отправки и обязательные параметры позволяют другому человеку воспроизвести его смысл.

Начните с вопросов

Перед добавлением события сформулируйте, какое решение оно изменит. Нужно ли понять, загрузился ли landing, дошёл ли пользователь до формы, отправил ли её или получил подтверждение? Если два события не ведут к разным действиям команды, возможно, достаточно одного.

Название описывает факт

Хорошее имя сохраняет смысл после редизайна. form_submitted понятнее, чем green_button_clicked, если бизнес-факт заключается в отправке формы. Цвет и расположение остаются параметрами интерфейса, а не частью постоянной семантики.

Что указывать в карточке

• Машинное имя и понятное описание
• Точный момент отправки
• Обязательные и необязательные параметры
• Источник каждого значения
• Правило повторной отправки
• Версия контракта
• Владелец и потребители
• Пример допустимого и ошибочного сценария

Параметры не должны дублировать название

Параметры добавляют контекст: идентификатор маршрута, locale, версия страницы, рекламная разметка и результат шага. Не передавайте значения, которые никто не использует, и не переносите чувствительные данные только потому, что это технически возможно. Google Analytics также рассматривает параметры как дополнительные сведения о взаимодействии, а не самостоятельную замену корректному событию.

Один факт — один стабильный идентификатор

Перезагрузка страницы и повторная доставка не должны создавать новый бизнес-факт. Генерируйте event_id в точке возникновения события и сохраняйте его при повторе. Новый пользовательский шаг получает новый ID; сетевой retry старого шага — прежний.

Версия меняется вместе со смыслом

Добавление необязательного параметра может быть совместимым. Смена момента отправки, единицы суммы или обязательного поля требует новой версии и переходного периода. Dashboard должен знать, какие версии он способен объединять.

Проверка перед релизом

1. Пройти успешный путь
2. Воспроизвести отказной путь
3. Проверить обязательные поля
4. Убедиться, что retry сохраняет event_id
5. Сверить время и timezone
6. Проверить старого потребителя
7. Сравнить контрольные суммы этапов

Наблюдение после запуска

Первые часы контролируйте не только количество событий, но и долю отсутствующих параметров, неизвестные версии, дубли и задержку доставки. Нормальное общее число может скрывать полную потерю одного device или locale.

Не переименовывайте событие только в интерфейсе

Если producer продолжает старое имя, а dashboard показывает новое, документация и фактические данные расходятся. Изменение проходит через версию и проверку потребителей.

Источники и границы применимости

Google Analytics event parameters: https://developers.google.com/analytics/devguides/collection/ga4/event-parameters

Вывод

Контракт событий делает post-click воронку понятной между командами. Чёткий момент отправки, минимальные параметры, стабильный event_id и версия защищают отчёт от тихих изменений. Начинать следует с решений, а не со списка всех доступных кликов.