Трекинг конверсий в медиабаинге: где теряются данные между кликом и постбэком
Расхождения между трекером и партнёркой — одна из самых частых проблем в арбитраже трафика. При этом мало кто действительно разбирает, где именно теряются данные.
Теряются они, как правило, во вполне конкретных точках. Большинство этих проблем не требует сложных решений — нужно просто знать, куда смотреть.
Как выглядит вся цепочка передачи данных
Базовая схема трекинга конверсий выглядит так:
Сломаться может на любом шаге. Пройдём по цепочке.
Редирект: скорость и отказоустойчивость
Задержка между кликом и загрузкой лендинга влияет на конверсию. Даже 500–800 мс уже заметны на мобильном трафике, особенно в гео с медленным интернетом.
Но есть проблема серьёзнее: если сервер упал, трафик не дойдёт до лендинга, пока кто-нибудь это не заметит и не починит. При правильно настроенной технической инфраструктуре домены автоматически переключаются на резервный сервер, а команда получает уведомление — вместо того чтобы узнать об инциденте через час по нулям в статистике.
Мониторинг доменов — отдельная тема. Истёкший домен, жалоба, попадание в блэклист — обо всём этом нужно узнавать заранее, а не когда трафик уже слит.
Лендинг: пиксель, CAPI и потерянная атрибуция
Конверсию на лендинге обычно снимают двумя способами: браузерным пикселем и серверным CAPI. Пиксель могут заблокировать расширения браузера и политики приватности — iOS, Safari ITP и большинство десктопных блокировщиков рекламы. Один пиксель без CAPI не покрывает заметную долю конверсий.
CAPI работает через сервер, поэтому не зависит от ограничений браузера. Но его нужно правильно настроить. Если event_id, email или другие данные передаются некорректно, Meta не может надёжно сопоставить событие с пользователем, и алгоритмы оптимизации работают хуже.
Ещё одна частая проблема — ручная вставка кода на каждый лендинг. Когда пиксель, CAPI и прочие скрипты добавляются руками при каждой загрузке лендинга, рано или поздно что-то забудут или вставят с ошибкой. Проблему решают глобальные макросы, которые автоматически подставляются в каждый загруженный в систему лендинг, — именно так это устроено в AIO.
A/B-тест лендинга: когда результату нельзя верить
Сплит-тест идёт, данные собраны, а результат всё равно нельзя интерпретировать. Такое случается чаще, чем кажется.
Неравномерное распределение трафика. Один вариант получил в три раза больше показов — данные несопоставимы. Обычно так выходит, когда веса распределяют без учёта кеширования или особенностей источника трафика.
Нет связи с конверсионной метрикой. Видно, что по одному варианту больше кликов на кнопку. А какой принёс больше лидов — непонятно, потому что событие конверсии не привязано к конкретному варианту сплита.
Тест остановили слишком рано. Статистической значимости ещё нет, но визуально один вариант выглядит лучше. Решение принимается до того, как собрано достаточно данных.
Корректный сплит-тест требует внятного распределения весов, одной целевой метрики на весь тест, автоматического выбора победителя по конверсии и правил показа по гео или устройству. Плюс тепловые карты — чтобы понимать поведение пользователя, а не только итоговые цифры.
Постбэк: откуда берутся расхождения с партнёркой
Трекер показывает 100 конверсий, партнёрка — 80. Особенно часто встречаются несколько сценариев:
- Постбэк не ушёл из-за сбоя сервера в момент конверсии. Если постбэки не логируются с подробными статусами, восстановить картину задним числом невозможно.
- Дубли конверсий. Пиксель и CAPI оба отправили событие, но дедупликация не сработала — event_id отсутствовал или не совпал, и Meta засчитала конверсию дважды.
- Часовые пояса. Конверсия попала в другой отчётный день, потому что у трекера и партнёрки разные таймзоны.
- Неполные параметры постбэка. Партнёрка не смогла сопоставить событие с кликом, и конверсия не засчиталась.
Как это устроено в AIO
Описанные проблемы — лишь часть того, что AIO помогает решать баинг-командам. Хотите увидеть, как это работает на практике, — закажите демо.
Ещё можно почитать о том, как проблемы инфраструктуры влияют на общую эффективность команды.
