Статусы конверсий Keitaro: что делать с каждым

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

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

Документированный список статусов

Постбек-контракт требует статус у каждой входящей конверсии: «Без subid и статуса трекер не может корректно обработать постбек». Документированные примеры - lead, sale, rejected, registration, deposit, trash (документация постбеков Keitaro) - словарь, ложащийся на этапы арбитражной воронки:

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

Переходы статусов: как меняется запись

Арбитражные конверсии меняют статус: лид становится продажей, иногда продажу откатывают. Keitaro моделирует это переходами, настроенными по типам конверсий в настройках, и валидация проговорена в документации поиска неисправностей - ошибка в логе «Conversion cannot transition to sale: next status already exists for the sent conversion but not for the existing one» означает, что запрошенный переход не входит в правила переходов (postback troubleshooting).

Дополняющее правило - перезапись: новый постбек с тем же subid, но изменёнными параметрами перезаписывает строку предыдущей конверсии. Вместе оба правила дают жизненный цикл:

1. Сеть постит lead на subid; строка создана.
2. Подтверждение приезжает постбеком sale на тот же subid; переход разрешён, строка обновляется.
3. Отказ приезжает как rejected; в зависимости от настроенных переходов строка сдвигается или обновление отвергается - в обоих случаях осознанно.

Когда статус отвергнут, починка - конфигурация, а не ретрай: добавьте недостающий переход или недостающий тип конверсии («Conversion type not found» лечится так же) в настройках.

Маппинг статусов в события площадки

Маппинг статусов в события площадки случается в сетке S2S-постбеков: каждая строка выбирает статус и адресат, поэтому лид-поток и sale-поток - отдельные строки с отдельными URL (S2S постбеки). Плейсхолдер {status} выносит имя статуса наружу, а {status:mapping} - например {status:lead=install sale=bill rejected=trash} - переименовывает статусы под адресата, не трогая записи трекера (плейсхолдеры).

Таблица маппинга, которую стоит записать до проводки:

1. registration и lead - события класса лида, если ваша политика их вообще шлёт.
2. deposit и sale - денежные события со value; какой из них становится Purchase, зависит от вертикали, как в обвязке FTD.
3. rejected и trash - никаких площадочных событий, всегда.
4. Всё остальное - осознанное решение, а не дефолт: не смаппленные статусы молчат, и молчание - правильный исход для статусов, по которым вы не решили.

Коррекции: что допускает каждый статус

Статусы меняются постфактум, и контракт это покрывает: перезапись по тому же subid обновляет строку при изменении параметров, а параметр выплаты «поддерживает положительные и отрицательные значения» - списания (клоубэки) едут тем же полем, что и заработок (postback URL). На стороне площадки отправленные события стоят, поэтому коррекция случается в статусной политике до доставки, как аргументирует гайд про холд.

Ежедневная проверка всего этого - два лога: Postbacks для того, что пришло и как менялись строки, S2S postbacks для того, что ушло и что ответило (логи).

Статусы конверсий Keitaro: частые вопросы

Источники