COD аппрув рейт: какое событие стреляет при подтверждении

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

Статусно-политический фундамент - в гайде про холд-статусы; эта страница - COD-специфичная надстройка.

Два события: что каждое говорит оптимизатору

Каждая COD-воронка производит два факта в разные моменты:

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

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

Как подтверждение едет через трекер

На стороне трекера COD-заказ - это конверсия, меняющая статус. Постбек-контракт Keitaro моделирует это напрямую: статусы вроде lead и sale - документированные значения параметра статуса, переходы валидируются - конверсия не может прыгнуть в состояние, запрещённое её настроенными переходами, - а настройки определяют, какой статус какой исходящий постбек зажигает (postback URL, postback troubleshooting).

COD-обвязка читается как машина состояний:

1. Форма заказа конвертится; сеть постит конверсию со статусом lead, привязанную к subid клика.
2. Колл-центр звонит. Подтверждения и отказы возвращаются через сеть новыми постбеками по тому же subid (без отдельного параметра tid, чтобы трекер обновлял существующую запись, а не создавал вторую конверсию).
3. Правила переходов трекера двигают строку из лида в продажу - или в rejected, - и S2S-постбек, настроенный на статус sale, стреляет в слой доставки (S2S постбеки).
4. Слой доставки отправляет событие класса Purchase с подтверждённой выплатой как value (параметры custom data).

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

Аппрув-рейт: число, которое выбирает вашу политику

Это не платформенный термин: аппрув-рейт - арифметика на данных трекера. По каждому срезу кампании делите подтверждённые заказы на все заказы за период:

approve_rate = подтверждённые продажи / все лиды

При аппрув-рейте 70 процентов событие лида - приличное обещание, и оптимизатор может на него опираться. Около 25 процентов лид-события - по большей части шум, и вес должен нести purchase-поток. Практические применения:

1. Триаж бюджета. Кампания, чей аппрув-рейт рухнул после смены креатива, нашла новый вид мусора - ставьте на паузу, пока purchase-поток не утонул.
2. Взвешивание событий. Чем ниже аппрув-рейт, тем сильнее отчётность и оптимизация должны опираться на подтверждённые продажи, а лид-события - оставаться сигналом объёма.
3. Сравнение офферов. Тот же источник трафика, разные колл-центры - честная метрика сравнения это аппрув-рейт, и живёт он целиком в отчётах трекера.

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

Задержка подтверждения против окна площадки

Conversions API Meta принимает event_time максимум на семь дней в прошлое, и одно протухшее событие валит весь запрос (using the API). COD-подтверждения обычно приезжают за часы или несколько дней, оставляя запас, - но полный лаг цепочки складывается из колл-центра, отчётности сети и вашей очереди доставки, и медленные вертикали способны съесть бюджет.

Два правила держат поток в безопасности. Первое: измеряйте реальные перцентили лага по логам трекера вместо гадания - логи постбеков и S2S Keitaro показывают, когда конверсии приходили и что стреляло (логи). А если подтверждения структурно вылезают за окно, починка - выше по течению: более быстро подтверждающие офферы или лид-событие, несущее вес оптимизации, пока продажи обслуживают отчётность, как в дисциплине прогрева.

Проверка COD-потока

1. Сделайте реальный тестовый заказ через ссылку кампании; тестовые постбеки сетей не несут настоящего subid.
2. Проверьте прибытие лид-события на площадку - Test Events у Meta показывает его сразу; Events Manager - примерно за 20 минут (get started).
3. Подтвердите заказ в трекере (или дождитесь подтверждения) и зафиксируйте отправку sale-события с верным value.
4. Сверьте цифры: один заказ должен показать один лид и одну продажу по всей цепочке - большее означает сломанную двухсобытийную обвязку.

Pixel Activator способен бесплатно протестировать отправку на стороне площадки; полный чеклист поиска неисправностей постбеков покрывает трекерные режимы отказа.

COD аппрув рейт: частые вопросы

Источники