Жизненный цикл статуса конверсии: pending, approved, rejected и корректировки

Редакция mevrica

Рекламные технологии4 мин чтения

Обновлено 1 августа 2026 г.

Статус конверсии — это состояние коммерческого решения, а не неизменяемое свойство пользователя. Событие появляется, проходит проверку, получает результат и иногда корректируется. Если система хранит только последнее слово, команда теряет момент изменения, применявшиеся условия и объяснение финансового пересчёта.

Главный принцип

Храните неизменяемую историю переходов и отдельно вычисляйте текущее состояние. Каждая новая версия ссылается на event_id, имеет status_version, decided_at и reason_code.

Минимальные состояния

Received

Событие технически принято, подпись и контракт прошли первичную проверку. Это ещё не означает коммерческий pending: запись может ожидать связи с кликом или проверки обязательных полей.

Pending

Событие участвует в квалификации. Для отчёта важны дата начала и ожидаемый срок, но сумма остаётся прогнозной.

Approved

Условия квалификации выполнены по применимой редакции. Начисление может создаваться отдельным финансовым движением, чтобы статус и деньги не смешивались.

Rejected

Событие не прошло квалификацию. Нужен стабильный reason_code и, где допустимо, пояснение уровня кампании без раскрытия лишних пользовательских данных.

Adjusted или reversed

Поздняя корректировка не должна стирать approved. Она создаёт новый переход и отдельную финансовую запись со ссылкой на исходное решение.

Допустимые переходы

Обычный путь: received → pending → approved или rejected. Повторная доставка того же status_version не меняет состояние. Версия выше текущей применяется, ниже — сохраняется как опоздавшая, но не откатывает результат. Переход approved → pending обычно требует отдельного договорного основания и аудита; свободное возвращение назад делает отчёт неустойчивым.

Поля истории

• event_id и conversion_id
• status и status_version
• occurred_at, received_at и decided_at
• reason_code и terms_version
• sender_id и payload hash
• actor_type: автоматическое правило или ручное решение
• ссылка на финансовую корректировку, если она есть

Пример опоздавшей доставки

В 10:00 получатель принял version=3 со статусом approved. В 10:05 сеть повторила задержанный version=2 rejected. Если обработчик ориентируется на время получения, approved исчезнет. Правильное правило сравнивает status_version: version=2 остаётся в журнале как поздняя доставка, текущее состояние не меняется.

Неизвестный статус

Когда программа добавляет under_review, система не должна автоматически считать его pending или rejected. Событие сохраняют в карантине, отчёт помечают как неполный, владельцу контракта отправляют алерт. После добавления явного mapping карантин обрабатывают повторно. Такой подход медленнее угадывания, но не искажает деньги.

Причины решений

Reason code должен быть машинным и стабильным: existing_customer, geo_mismatch, threshold_not_met, duplicate, payment_reversed. Текстовое пояснение можно менять для человека, код — только через версию справочника. Общий код quality_issue мало полезен: он не сообщает, какое действие исправлять.

Отчёты по двум датам

Операционный отчёт группирует изменения по decided_at и показывает нагрузку сегодня. Когортный отчёт возвращает результат к occurred_at или дате привлечения и показывает качество закупки. Оба верны для разных вопросов; смешивать их в одном графике без пояснения нельзя.

Финансовое разделение

Статус approved не обязан содержать сумму. Начисление создаётся в ledger по модели CPA, RevShare или Hybrid и может иметь собственную валюту и период. Тогда пересчёт выплаты не переписывает историю квалификации, а отмена имеет отдельную строку.

Проверки автоматики

1. Повтор одного event_id и version не создаёт дубль.
2. Version=3, пришедшая раньше version=2, остаётся текущей.
3. Неизвестный статус попадает в карантин.
4. Переход без terms_version отклоняется или маркируется неполным.
5. Корректировка создаёт историю и финансовое движение.
6. Отчёты по occurred_at и decided_at воспроизводятся независимо.

Не удаляйте спорное событие

Даже ошибочный postback полезен для расследования. Ограничьте доступ, пометьте его невалидным и сохраните аудиторский след в рамках установленного срока.

Вывод

Жизненный цикл превращает строку «конверсия» в объяснимый процесс. Версии защищают от опоздавших postback, reason codes делают качество управляемым, а отдельный ledger не позволяет финансовой корректировке переписать факт события.