Статус конверсии холд: что попадает в ваш пиксель

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

Транспортная сторона цепочки - постбеки, хопы и их разрывы - живёт в гайде от постбека CPA сети до Conversions API; здесь - слой решений поверх неё.

Кому принадлежит холд: сетям и трекерам, но не площадкам

Холд - понятие из области выплат. Партнёрские сети держат конверсии, пока у рекламодателя работают антифрод, колл-центры и рефанд-окна; только потом деньги становятся вашими. Трекер моделирует ту же реальность статусами: постбек-контракт Keitaro требует статус у каждой конверсии - lead, sale, rejected, registration, deposit, trash - и управляет переходами между ними в настройках типов конверсий (документация постбеков Keitaro).

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

Три политики для холдовых конверсий

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

Площадочная обвязка двухпоточного подхода - кастомные имена событий включительно - в гайде кастомные конверсии Facebook CAPI для арбитражных офферов.

Что заслуживает каждый статус

Маппинг статусов на действия площадки:

1. Лид / регистрация. Реальное действие пользователя с неизвестным качеством. Как событие - да, если ваша политика использует лид-поток; как Purchase - никогда.
2. Approved / продажа. Подтверждённая выплата. Ради неё существует ваш Purchase - несите выплату как value.
3. Холд. Не статус, который площадка когда-либо поймёт, а комната ожидания. Событие стреляет, когда ожидание кончилось - Purchase при аппруве, ничего при отклонении.
4. Rejected / trash. Только отчёты. Отправка отклонённых конверсий событиями учит площадку находить больше того, за что вам не заплатили.
5. Ребилл / повторный платёж. Новая конверсия с собственной транзакционной идентичностью, а не перезапись первой - ниже о том, почему.

Keitaro делает статус единицей доставки: каждый настроенный S2S-постбек стреляет по выбранному статусу конверсии, поэтому лид-поток и purchase-поток - буквально две строки постбеков с разными статусами (настройка S2S постбеков).

Задержка аппрува против окна приёма

Площадки документируют, насколько старым может быть событие в момент отправки. Conversions API Meta принимает event_time максимум на семь дней в прошлое, и одно протухшее событие валит весь запрос, не обрабатывая ни одного (using the API). События physical store - офлайн-путь подтверждения с action_source = physical_store - получают вместо этого окно в 62 дня (офлайн-события).

Арифметика холда следует напрямую. Оффер, чей рекламодатель подтверждает COD-заказы за три дня, оставляет четыре дня запаса в семидневном окне Meta. Двухнедельный холд обычным веб-событием отправить нельзя вообще - аппрув приземлится за окном, и единственный документированный длинный путь - офлайновый physical store, который веб-воронку не описывает. Поэтому байеры с длинными холдами делают наоборот - не ждут: они шлют по сигналу, приходящему рано - верифицированная регистрация, депозит, - а не по финальному подтверждению выплаты.

Два тайминговых замечания достраивают картину. Часы идут от event_time, то есть от момента конверсии - см. окно атрибуции, - а не от вашей отправки, поэтому постбек, сам пришедший поздно, уже потратил часть бюджета (откуда берётся задержка событий). А знаменитая ошибка за нарушение окна описана в разборе 2804003.

Коррекция учёта после смены статусов

Холдовые конверсии разрешаются в обе стороны, и учёт должен двигаться вместе с ними:

• В трекере. Постбек-контракт Keitaro умеет коррекции нативно, опираясь на conversion ID исходного клика: новый постбек с тем же subid, но изменёнными параметрами перезаписывает предыдущую конверсию, а переходы статусов валидируются - конверсия не может прыгнуть в состояние, которое её настроенные переходы не позволяют («conversion cannot transition to sale» - документированная запись лога с починкой в настройках типов конверсий).
• На площадке. Площадка получила событие, а события не отзываются - документированная дедупликация Meta сводит браузерное событие пикселя с серверным, поэтому два серверных события с одним event_id не склеиваются (дедупликация). Коррекции поэтому происходят через саму статусную политику: придерживайте событие до подтверждения, меняющего исход, а исправленные цифры держите в трекере и своей отчётности, не переписывая площадочную историю.

Кросс-системная версия этой проблемы - трекер, сеть и площадка расходятся в итоговой цифре - предмет гайдов дедупликация пикселя и CAPI и discrepancy-статей кластера.

Выбор политики по вертикали

Входные данные решения - вертикальные факты:

1. COD и колл-центры. Подтверждение медленное, отклонение реально. Разделённая политика - лид в регистрации, Purchase по подтверждённому депозиту - держит алгоритм сытым, не приучая его к неподтверждённым регистрациям.
2. Триалы и кард-сабмиты. Подтверждение быстрое; аппрув всё же может откатиться в рефанд-окно. Отправка Purchase в момент подтверждения со value работает, пока холд короткий.
3. Нутра и свипстейк-подобные потоки. Процент отклона высокий, а отказы приходят поздно. Отправка только по аппруву защищает оптимизацию ценой объёма - терпимо лишь при запасе кликов.

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

Статус конверсии холд: частые вопросы

Источники