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

Со стороны ротация офферов трекинг выглядит безобидно до первого случая смешивания: три оффера ротируются через одну кампанию, один пиксель, одно имя события - и отчёт говорит, что кампания работает, но молчит, какой оффер платит. Ротация превращает маленькую проблему маппинга в проблему владения данными: каждая конверсия обязана остаться приписанной своему офферу через ещё четыре хопа сантехники. Этот гайд собирает маппинг, выживающий при ротации: пометьте оффер на клике, пронесите метку через постбек, смаппите каждый оффер на своё событие и 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 постбеки).

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

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

Кастомные события держат офферы разделёнными на верхнем уровне площадки - каждое имя строит собственную кастомную конверсию, отдельно появляется в отчётности и может обслуживать optimization dropdown 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), до масштабирования ротации. Режимы отказа, которые вымывает тест, разобраны в чеклисте поиска неисправностей постбеков.

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

Источники