Трекинг конверсий арбитражника: полный гайд

Ремесло под названием трекинг конверсий арбитражника - это измерение конверсий, которые случаются на лендинге, вам не принадлежащем: оффер находится у партнёрской сети, пиксель стоит на их домене, и единственная надёжная связь - постбек, который идёт от сети через ваш трекер до рекламной площадки. Эта страница - вход в весь арбитражный раздел. Она разбирает цепочку целиком, называет места, где конверсии утекают, и маршрутизирует к глубокому гайду по каждой конкретной поломке.

Серверный трекинг - хребет этой цепочки, а Conversions API - её конечная точка. Всё, что между ними, существует ради одного: сохранить доказательство, что клик, за который вы заплатили, стал конверсией, которую кто-то подтвердил.

Что на самом деле измеряет трекинг конверсий арбитражника

Классическая связка на своём сайте считает продажу в момент, когда пиксель срабатывает на вашем собственном чекауте. У арбитражника другая реальность. Продажа случается на сайте рекламодателя, рекламодатель сообщает о ней сети, сеть сообщает вам постбеком, и только потом событие может доехать до рекламной площадки, которая продала вам клик.

Это расстояние меняет всю дисциплину. Каждый хоп добавляет задержку, каждый хоп может потерять идентификаторы, и каждый хоп ведёт собственную бухгалтерию. Ремесло трекинга конверсий арбитражника - сохранить идентичность клика и факты о конверсии через все три хопа. Не потому, что какая-то система ненадёжна, а потому, что три системы никогда не были спроектированы так, чтобы сходиться.

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

Цепочка постбеков: сеть, трекер, рекламная площадка

В любой арбитражной вертикали цепочка выглядит одинаково:

1. Пользователь кликает ваше объявление. Площадка добавляет свой click ID - fbclid у Meta, ttclid у TikTok, rdt_cid у Reddit - и ваш трекер сохраняет клик с этим идентификатором.
2. Дальше трекер перенаправляет пользователя через прелендинг или сразу на URL оффера, дописывая собственный sub ID - обычно параметр subid или aff_sub, который сеть обещала вернуть эхом.
3. Где-то на странице рекламодателя пользователь конвертится. Подтверждение сначала попадает к сети.
4. После подтверждения сеть отправляет сервер-ту-сервер постбек вашему трекеру, возвращая sub ID и детали конверсии.
5. Трекер матчит постбек с исходным кликом и пересылает конверсию рекламной площадке - обычно через её интеграцию с Conversions API.

Свою сторону пятого шага Keitaro документирует как S2S постбеки: «инструмент аналитики и сбора данных на стороне источника трафика», где каждый URL постбека несёт плейсхолдеры вроде {external_id} для click ID и {conversion_revenue} для выплаты, а исходящие запросы «собираются в очередь» с исключением дублей (см. документацию S2S постбеков Keitaro).

Таблица объясняет классическое раздражение: все три системы правы и все три цифры различаются, потому что каждая считает в разной точке цепочки с разным набором знаний. Почему цифры расходятся и что с этим делать - седьмой раздел.

Механика обвязки одной площадки - Meta со встроенной интеграцией Keitaro и ручным S2S-путём - в гайде Facebook CAPI Keitaro: настройка без потери конверсий.

Click ID и sub ID: сохранить идентичность через воронку

Каждый хоп цепочки передаёт идентичность дальше, и каждый хоп - шанс её потерять. Click ID площадки должен дожить от клика по объявлению до сохранения в трекере. Sub ID трекера должен дожить от редиректа до постбека сети. Сломается любое звено - конверсия всё равно случится, но придёт в трекер не сматченной или на площадку неатрибутированной, и ваши деньги купили событие, которое никому не засчитали.

Meta ожидает свои идентификаторы назад на серверных событиях, когда они существуют: документированные значения браузерных кук _fbp и _fbc передаются в полях fbp и fbc объекта user_data вызова Conversions API, причём _fbc можно собрать на сервере из URL-параметра fbclid, когда браузерной куки нет (Meta документирует оба параметра на странице fbp and fbc parameters). Имена по каждой площадке собраны в глоссарной статье про click ID, а глубокий разбор точек потери - в гайде где теряются fbclid и ttclid.

К sub ID та же дисциплина. Документация Keitaro проговаривает режим отказа прямо: если {external_id} приходит в URL постбека пустым, «источник не передаёт параметр» - сеть не вернула ваш sub ID эхом, и никакая настройка трекера это с вашей стороны не починит. Прогнать полный цикл тестовой конверсией до масштабирования дешевле, чем обнаружить дыру по неделе не сматченных постбеков.

Статусы конверсий: что каждый значит для вашего пикселя

Партнёрские сети не сообщают финальные истины - они сообщают статусы. Конверсия может прийти как регистрация, получить подтверждение колл-центра рекламодателя, зависнуть в холде на время рефанд-окна или вернуться отклонённой. Сети и трекеры моделируют это статусом при каждой конверсии, а Keitaro позволяет настроить, какой статус какой постбек зажигает: в настройке S2S постбека вы «выбираете статус конверсии для отправки постбека», и каждый статус может вести в свой адрес.

Одна эта настройка решает, чему учится ваш пиксель. Слать каждый сырой лид как Purchase - значит учить алгоритм оптимизироваться под регистрации, которые никогда не заплатят. Отправлять одни подтверждённые продажи - морить его голодом на время подтверждения. Большинство арбитражников осознанно останавливаются между крайностями, и выбор делается по офферу: COD-вертикаль с аппрувом 40 процентов ведёт себя совсем не так, как триальная воронка с мгновенным списанием.

У статусной обвязки свои глубокие разборы: постбеки против Conversions API сравнивают каналы доставки, а статусная обвязка Keitaro для двух площадок - в гайде настройка постбеков Keitaro для Facebook и TikTok.

От трекера до Conversions API: как работает доставка

Последний хоп повторяет один паттерн для каждой площадки: трекер - или автоматизация, действующая от его имени, - POST-запросом отправляет конверсию на серверный эндпоинт площадки, авторизуется токеном и прикладывает идентификаторы и факты о событии, которые площадка требует.

Conversions API Meta требует, чтобы website-события несли action_source, event_source_url и client_user_agent, принимает event_time максимум на семь дней в прошлое и валит весь запрос из-за одного протухшего события (Meta документирует это на странице Conversions API parameters и в гайде using-the-api). Серверные события Reddit принимаются в течение семи дней от конверсии, а дедупликация с пикселем идёт по conversion ID; путь настройки - в гайде настройка Reddit Conversions API. Серверный аналог TikTok - Events API, документированный в статье о TikTok Events API, с трекерной обвязкой в гайде TikTok Events API для арбитражных трекеров.

У серверного хопа есть два следствия, важных каждому арбитражнику. Первое: время перестаёт быть абстракцией - постбек, дошедший до трекера через три дня после клика, всё ещё должен уехать в окне приёма площадки, поэтому задержки доставки складываются по всей цепочке. Второе: площадка оценивает полноту данных события - это предмет раздела про качество ниже.

Выплата сети как conversion value

Свой магазин отправляет с событием Purchase стоимость заказа. Арбитражник отправляет выплату, которую отчитала сеть, - трекер уже получил её в постбеке, для этого хопа у Keitaro существует плейсхолдер {conversion_revenue}. Уехав в поле value с currency, выплата даёт value-based оптимизации работать с реальными деньгами вместо плоского счётчика.

Интересная механика начинается там, где выплаты не плоские: частичные аппрувы, ребиллы в подписочных офферах, расхождения валют между отчётом сети и рекламным кабинетом. Эти случаи решают, что несёт value - грязную выплату, подтверждённую сумму или ожидаемое значение; глубокий разбор передачи выплаты - отдельный гайд.

Для полного гайда достаточно зафиксировать принцип: площадка способна оптимизироваться только на значение, которое вы реально передаёте. Плоский Purchase без value учит алгоритм объёму; честная value учит его деньгам.

Дубли конверсий: три системы, три цифры

Каждый арбитражник однажды спрашивает, почему трекер показывает 80 продаж, баланс сети - 74, а Ads Manager - 92. Разрыв редко оказывается одной ошибкой - это сумма правил подсчёта, расхождений окон и настоящих дублей. Платформенный дедуп документирован и механичен: Meta хранит первую копию события с теми же event_id и event_name, пришедшую в 48-часовом окне, так что пиксель и серверный POST об одной и той же покупке считаются один раз (метод задокументирован на странице дедупликации); Reddit сводит пиксельные и серверные события по conversion ID в собственном окне.

Сложнее - дубли бизнес-логики: сеть переотправляет постбек после смены статуса, или одну подтверждённую продажу пересылают и трекер, и CRM. Keitaro исключает дубликаты внутри своей S2S-очереди, но очередь способна дедуплицировать только то, что пришло с одинаковой идентичностью - именно поэтому дисциплина event ID важна по всей цепочке, а не только на границе с площадкой.

Дедупликация пиксель-против-CAPI конкретно для Meta - в гайде дедупликация событий Facebook Pixel и CAPI. Вопрос расхождения трекера с деньгами разобран отдельно: почему ROI трекера не сходится с ROAS Ads Manager.

Качество данных: за что площадки ставят оценки

Серверная доставка положила оценку качества на стол арбитражника. Event Match Quality у Meta оценивает, насколько полно события идентифицируют пользователя за конверсией - хешированные email или телефон, client IP и user agent, куки fbp и fbc - и эта оценка влияет на пригодность события для атрибуции и оптимизации (Meta описывает метрику в About Event Match Quality). Конверсия, уехавшая с одним таймстампом и именем события, почти не имеет поверхности для матчинга.

Для арбитражных воронок у проблемы качества есть поворот: конверсия случается на домене, которым вы не управляете, поэтому первопартийные сигналы вроде кук и браузерных данных по построению скудны. Что под вашим контролем - передача click ID, отправка сохранённых трекером IP и user agent исходного клика, хеширование контактных данных, которыми сеть реально делится, - и решает, в какой конец шкалы качества упадут ваши события. Наш глоссарий про качество событий и статья про ключ матчинга разбирают поля по каждой площадке.

Качество данных - ещё и причина, по которой мусорные клики стоят дороже, чем выглядят: боты и трэш-сегменты, конвертящиеся в фейковые лиды, отравляют и поток событий, и оптимизацию, обученную на нём. Фильтрация до отправки событий - работа трекерной стороны, и в этом разделе у неё будет собственный гайд.

Прогрев пикселя без его сожжения

«Прогрев пикселя» - арбитражный термин для последовательности, которую каждая площадка подразумевает, но ни одна не превращает в чеклист: гоняйте трафик, дающий чистые, хорошо атрибутированные события, чтобы система доставки получила надёжный базлайн до того, как вы надавите на бюджеты. Механика не зависит от площадки:

1. Стартуйте с узкой, хорошо таргетированной аудитории и одного конверсионного события, которое реально можете кормить.
2. Убедитесь, что доставка событий работает - тестовые события видны в инструментах площадки - до масштабирования расхода.
3. Держите идентификаторы и value полными на каждом событии: в базлайн-период оценка качества имеет самые долгосрочные последствия - как положительные, так и отрицательные.
4. Масштабируйте бюджеты постепенно, чтобы оптимизация продолжала учиться на свежих консистентных данных, а не переучивалась на шоках.

Режимы отказа столь же консистентны: прогрев на неподтверждённых лидах, прогрев событиями без ключей матчинга или масштабирование в широкую аудиторию до появления базлайна. Определение держит глоссарная статья про прогрев пикселя, а пошаговый практический гайд этого раздела разбирает всю процедуру.

Когда цифры расходятся: карта поиска неисправностей

Опыт кластера сжимается в короткую диагностическую карту. Когда что-то выглядит сломанным, сначала найдите группу:

1. На трекере конверсии нет вообще. Постбек сети не пришёл или принёс пустой sub ID. Смотрите лог постбеков - S2S-лог Keitaro показывает, «какой subid инициирует отправку, какая ссылка конвертнула» и ответ источника.
2. На трекере конверсия есть, на площадке - ничего. Сломалась доставка: токен, эндпоинт или событие выпало из окна приёма. Семидневный лимит event_time у Meta и правило «одно протухшее событие валит весь запрос» - классические тихие убийцы.
3. Конверсия пришла, но не сматчилась. Click ID или пользовательские идентификаторы потеряны выше по цепочке; событие приземлилось с тощим ключом матчинга.
4. Всё доехало, цифры всё равно разные. Правила подсчёта: окна атрибуции площадки, холд-политики сети и разница атрибуции делают свою работу. Сверяйтесь с определениями, а не «чините» трубу.
5. Внезапный сдвиг после рабочего периода. В цепочке что-то изменилось - миграция URL оффера, новый прелендинг, потерявший параметры, истёкший токен. Диффьте цепочку против последнего рабочего состояния.

Чеклист поиска неисправностей постбеков разворачивает эту карту в полный проход, а задержка событий Meta CAPI разбирает временную группу в глубину.

Автоматизация цепочки: трекеры, Pixel Activator, Most

Каждая часть этого гайда умеет запускаться вручную один раз: собранный руками POST в Conversions API доказывает работоспособность токена и параметров, точно так же, как Pixel Activator позволяет бесплатно стрелять тестовыми конверсиями без какой-либо инфраструктуры. Ручное доказательство - правильный инструмент для настройки и отладки.

Регулярная доставка - другая работа. Постбеки приходят в три часа ночи, у площадок случаются транзиентные ошибки, статусы меняются постфактум, и каждый режим отказа из этого гайда однажды случается на живой воронке. Это работа Most: он сидит между вашим трекером и рекламными площадками, маршрутизирует каждую конверсию с её идентификаторами и value, ретраит неудачные доставки и не пускает дубли - вся цепочка этого гайда, работающая без присмотра.

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

Трекинг конверсий арбитражника: частые вопросы

Источники