Статус конверсии в Keitaro - не метаданные, а переключатель всей доставки. Он решает, какой исходящий постбек уйдёт, каким событием площадки станет конверсия и попадут ли деньги в ваши отчёты или останутся сноской. Keitaro документирует конкретный список статусов, правила проверки их смены и постбеки по статусам; гайд проходит все три части и заканчивается тем, как статусы превращаются в события, которые затем получают ваши пиксели.
Стратегический вопрос - какие статусы вообще заслуживают событий площадки - разобран в гайде про холд-статусы; эта страница остаётся на механике, которую документирует Keitaro.
Документированный список статусов
Постбек-контракт требует статус у каждой входящей конверсии: «Без subid и статуса трекер не может корректно обработать постбек». Документированные примеры - lead, sale, rejected, registration, deposit, trash (документация постбеков Keitaro) - словарь, который хорошо ложится на этапы арбитражной воронки:
| Статус | Смысл в воронке | Типичное действие на площадке |
|---|---|---|
registration | Аккаунт создан | Событие класса лида, редко со value |
lead | Подтверждённое действие, оплата впереди | Событие класса лида; сигнал объёма |
deposit | Деньги реально пришли | Депозит/FTD-событие со value |
sale | Подтверждённая к выплате продажа | Purchase-событие со value |
rejected | Рекламодатель отклонил | Только отчёты - никогда событие |
trash | Известный мусор | Только отчёты |
Два статуса заслуживают акцента. 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, но изменёнными параметрами перезаписывает строку предыдущей конверсии. Вместе оба правила дают жизненный цикл:
- Сеть постит
leadна subid; строка создана. - Подтверждение приходит от сети постбеком
saleна тот же subid; переход разрешён, строка обновляется. - Отказ приходит как
rejected; в зависимости от настроенных переходов строка переходит в другой статус либо обновление не принимается - и в том и в другом случае осознанно.
Если статус не принят, чинить нужно конфигурацию, а не повторять запрос: добавьте в настройках недостающий переход или недостающий тип конверсии («Conversion type not found» лечится так же).
Сопоставление статусов с событиями площадки
Связь статусов с событиями площадки настраивается в списке S2S-постбеков: каждая строка выбирает статус и адресат, поэтому лид-поток и sale-поток - отдельные строки с отдельными URL (S2S постбеки). Плейсхолдер {status} передаёт имя статуса как есть, а {status:mapping} - например {status:lead=install sale=bill rejected=trash} - подставляет вместо него имена адресата, не трогая записи трекера (плейсхолдеры).
Таблица соответствий, которую стоит составить до настройки:
registrationиlead- события класса лида, если ваша политика вообще их отправляет.depositиsale- денежные события со value; какой из них становится Purchase, зависит от вертикали, как в настройке FTD.rejectedиtrash- никаких площадочных событий, всегда.- Всё остальное - осознанное решение, а не настройка по умолчанию: статусы без заданного соответствия никуда не отправляются, и для статусов, по которым вы ещё не решили, это правильный исход.
Коррекции: что допускает каждый статус
Статусы меняются постфактум, и контракт это покрывает: перезапись по тому же subid обновляет строку при изменении параметров, а параметр выплаты «поддерживает положительные и отрицательные значения» - списания (клоубэки) уходят тем же полем, что и заработок (postback URL). На стороне площадки отправленное событие уже не отозвать, поэтому коррекция закладывается в политику статусов до доставки - так аргументирует гайд про холд.
Проверка на каждый день - это два лога: Postbacks показывает, что пришло и как менялись строки, S2S postbacks - что ушло и что ответило (логи).
Статусы конверсий Keitaro: частые вопросы
Frequently asked questions
Источники
Sources
- Тест на каждый статус: Pixel Activator бесплатно отправляет именованные тестовые события для каждого соответствия.
- Статусы в события на автопилоте: Most направляет каждый подтверждённый статус в нужное событие площадки.