Ротация офферов трекинг: много офферов, один пиксель, ноль смешивания

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

Саму цепочку, по которой метка доходит до события, разбирает гайд от постбека до CAPI; здесь - как держать офферы различимыми внутри неё.

Почему ротация ломает наивный трекинг

С одним оффером каждый Purchase неявно принадлежит ему - метки не нужны. Ротируйте офферы - и неявная связь умирает: событие Purchase говорит «кто-то заплатил», но не говорит, какая воронка произвела платёж, какой креатив принёс результат и какая выплата соответствует экономике какого оффера.

На стороне площадки следствие точное: оптимизатор и отчёты способны делить конверсии только по меткам, которые вы передали. event_name события и его параметры custom_data - единственная информация об оффере в payload (параметры серверных событий). Если три оффера шлют Purchase с разными value, площадка охотно оптимизирует смесь - а смесь оптимизируется в сторону самого дешёвого по конверсии оффера, а не самого платящего.

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

Пометьте оффер на клике

Ротация случается в трекере - его потоки решают, какой оффер видит клик, - поэтому строка клика и есть место рождения метки оффера. Постбек-контракт Keitaro даёт метке дорогу домой: sub_id_1..sub_id_30 документированы как «дополнительные данные, обновляющие запись клика» - ровно место для тега оффера, - а система алиасов ставит в эти поля параметр с любым именем, который прислала сеть (документация постбеков Keitaro).

Цепочка метки:

1. Каждая ветка ротации дописывает собственный маркер к URL оффера - параметр sub ID оффера несёт различающее значение на оффер.
2. Постбек сети возвращает маркер эхом через те же поля sub ID.
3. Трекер хранит маркер в строке клика конверсии; слой доставки читает его при сборке события площадки.

С этой точки идентичность оффера - данные, а не догадки: макросы S2S-постбека - {external_id} для клика, {conversion_revenue} для выплаты, {offer_name} для самого оффера - позволяют слою доставки адресовать каждый оффер отдельно (S2S постбеки). Полный словарь макросов - в справочнике макросов Keitaro.

Сопоставьте каждый оффер с его событием

Две документированные формы покрывают ротацию на стороне площадки:

Кастомные события держат офферы разделёнными на верхнем уровне площадки - каждое имя строит собственную кастомную конверсию, отдельно появляется в отчётности и выбирается в выпадающем списке оптимизации ad set'а (кастомные конверсии). Параметровая разметка держит список событий коротким и делит офферы внутри Events Manager по правилам; цена - сырой счёт событий остаётся смешанным, пока правило его не разделит.

Обе формы работают; их смешивание на лету - нет. Переименование событий после накопления объёма делит историю каждого оффера между двумя именами - самая частая ошибка, которую арбитражник при ротации делает сам.

Value-правила при ротации

Ротация делает дисциплину value обязательной, потому что у офферов разные деньги:

1. Выплата оффера как value. {conversion_revenue} постбека - это выплата конкретного оффера, уезжающая как value с currency (параметры custom data; сам этап выплаты разобран в гайде о передаче выплаты). Усреднённое value отравляет оптимизацию всех офферов разом.
2. Окна приёма по офферам. Окно event_time - семь дней у Conversions API Meta - не зависит от оффера (документации по использованию API), но задержки подтверждения у офферов разные, поэтому медленные офферы ближе к краю.
3. Идентичность по офферам. Мультиконверсионным офферам нужен транзакционный параметр класса tid, чтобы повторы не перезаписывали (Postback URL); ребилльным офферам - собственные события циклов, как в подписочной воронке.

Единица конфигурации - оффер, а не кампания: имя, источник value, сопоставление статусов и правило идентичности задаются на оффер в одном месте - слое доставки, - чтобы ротация переставляла трафик без правки обвязки.

Ловушки, сливающие данные офферов

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

Противоядие у всех ловушек одно - метки как данные, заданные для оффера и применяемые слоем доставки, - и тест один: по одной конверсии на оффер через реальную цепочку, проверенные в логе постбеков и Test Events (быстром старте Conversions API), до масштабирования ротации. Какие поломки этот тест вылавливает - разобрано в чеклисте поиска неисправностей постбеков.

Ротация офферов трекинг: частые вопросы

Источники