Проверка заявок: статусы, сроки и разбор спорных решений
Регламент проверки заявок для рекламодателя: ответственные, сроки, доказательства, причины отказа и пересмотр решений. Учебные примеры и чек-лист.
Заявка может попасть в систему вовремя и всё равно неделями оставаться без понятного решения. Вебмастер видит ожидание, рекламодатель — очередь, а оператор разбирает переписку вместо конкретного события. Решение начинается с договорённости: кто проверяет заявку, по каким условиям, до какого срока и с каким объяснением.
Эта инструкция помогает подготовить регламент обработки уже поступивших заявок. Она рассчитана на рекламодателей и операционные команды, применима к разрешённым продуктам разных регионов после проверки местных требований. Все сроки, коды и числа ниже — учебные, а не условия AffiliateCore. Пример относится к обычному цифровому сервису; он не подтверждает доступность такого оффера в каталоге.
1. Определите предмет решения
Разделите три вопроса: произошло ли событие, соответствует ли оно согласованным условиям и завершён ли финансовый расчёт. Получение постбека доказывает получение сообщения, но само по себе не подтверждает качество заявки. Подтверждённая конверсия также не означает, что деньги уже доступны к выплате: отдельно учитываются холд и финансовые операции.
До запуска зафиксируйте событие, обязательные признаки, допустимые источники, правила повторных обращений, окно наблюдения и версию условий. Например, для учебной заявки на демонстрацию сервиса событие — отправленная форма с выбранным продуктом. «Покупка в течение месяца» не может незаметно стать новым условием приёмки после получения трафика. Если оплата предусмотрена за другое событие, его определяют заранее.
Результат этого шага — одна страница правил с датой начала действия. Храните предыдущую версию: при споре нужно восстановить условия конкретной заявки. Изменение требований согласуют для будущих событий, а не используют для снижения числа уже принятых результатов.
2. Назначьте владельца каждого этапа
Один сотрудник принимает очередь, другой при необходимости проверяет технические доказательства, уполномоченный оператор фиксирует итог. Для небольшой команды роли может совмещать человек, но спор желательно передать тому, кто не принимал первоначальное решение. Назначьте замену на отпуск и отдельный контакт для эскалации.
Учебная схема процесса: получено → идентифицировано → проверены условия → решение с основанием → уведомление → пересмотр при новых доказательствах. Если данных недостаточно, появляется задача на уточнение с владельцем и сроком. Это схема работы команды, не изображение встроенного процесса AffiliateCore.
Подготовив правила, можно зарегистрироваться рекламодателем AffiliateCore, заполнить необходимые сведения и использовать их при подготовке своего предложения. Регистрация сама по себе не подтверждает допуск продукта или готовность к запуску.
3. Сопоставьте рабочие этапы со статусами
В проверенном кабинете рекламодателя AffiliateCore есть просмотр конверсий, фильтр по статусу, тип события, внешний идентификатор, сумма и валюта события, начисление рекламодателю, причина отклонения, оффер и время события. Рекламодатель не получает через этот список свободное редактирование или удаление конверсий.
| Статус в списке | Что проверить в рабочем процессе |
|---|---|
| pending | Кто отвечает за проверку и когда ожидается решение |
| confirmed | Какое условие подтверждено; отдельно проверить холд и расчёты |
| rejected | Какое правило нарушено и где доказательство |
| reversed | Почему прежний результат отменён; не путать с первым отказом |
| disputed | Какой вопрос оспаривается и кто отвечает за его разбор |
Наличие названия disputed не доказывает существование автоматической подачи апелляции, таймера или отдельного кабинета споров. Полноценный пользовательский процесс апелляций при проверке не подтверждён. Поэтому журнал обращений и сроки из этой статьи ведите в своём согласованном рабочем инструменте, а изменение системного статуса поручайте уполномоченной стороне. Не обещайте партнёру кнопку, которой у него нет.
4. Задайте сроки с точкой отсчёта
Плохо: «проверяем быстро». Лучше: «первичный разбор — до следующего рабочего дня после поступления; если нужны сведения, сообщаем перечень и новую дату». Для учебного пилота можно выделить два рабочих дня на обычное решение и ещё один на эскалацию просрочки. Эти значения нужно согласовать с реальной загрузкой, выходными, регионом и временем наступления целевого события.
Записывайте отдельно время события, время получения и крайний срок решения. Используйте один часовой пояс в регламенте, а при обмене данными передавайте смещение. Поздно доставленное событие не следует автоматически объявлять нарушением со стороны вебмастера. Сначала установите причину задержки и применимое правило.
Ожидание сведений не должно незаметно обнулять возраст заявки. Сохраняйте первоначальный срок, причину продления, ответственного и новую дату. Истечение срока означает эскалацию, а не автоматический отказ или начисление, если такой механизм не согласован и не реализован.
5. Собирайте минимально достаточные доказательства
Для каждой проверки нужны идентификатор события в источнике, идентификатор конверсии платформы при наличии, связь с кликом, оффер, время, версия правила и ссылка на подтверждение. Идентификатор пользователя не заменяет идентификатор события: у одного человека могут быть разные допустимые действия.
В журнале решения добавьте прежний и новый статус, сотрудника, дату, основание и связь с предыдущим решением. Повторная доставка одного сообщения не является новой заявкой. Но совпавший IP или похожий адрес сами по себе также не доказывают дубль или мошенничество. Проверяйте идентичность события и заранее согласованные условия.
Не пересылайте партнёру пароли, секреты постбеков, полные документы или лишние контактные данные посетителей. Дайте ссылку на ограниченный доступ либо обезличенную выдержку, достаточную для понимания причины. Общие рекомендации по составу и защите журналов есть в OWASP Logging Cheat Sheet; приведённый здесь регламент обработки заявок — редакционный практический шаблон.
6. Разделите причины отказа и задачи на уточнение
Учебные коды помогают избежать формулировки «плохой трафик». Они не являются встроенным справочником AffiliateCore.
EVENT_DUPLICATE — Подтверждена повторная запись того же события. Что приложить: Ссылку на исходное событие и критерий совпадения.
TERMS_MISMATCH — Нарушено конкретное действовавшее условие. Что приложить: Пункт и версию условий, проверяемый факт.
EVENT_NOT_MET — Согласованное целевое действие не завершилось. Что приложить: Состояние источника на конец окна наблюдения.
NEEDS_EVIDENCE — Пока недостаточно информации для решения. Что приложить: Точный запрос, получателя и срок ответа.
Последняя строка — рабочая задача, а не окончательное основание отказа. Сигнал антифрода тоже требует интерпретации. Если доказательства недоступны из-за сбоя вашей системы, зафиксируйте технический инцидент и срок разбора. Не подменяйте неопределённость обвинением партнёра.
7. Учебный пример: разберите очередь без искажения долей
В учебном цифровом сервисе за неделю зарегистрированы 100 уникальных заявок после удаления повторных доставок. К моменту отчёта 60 подтверждены, 20 отклонены по проверенным основаниям, 20 ожидают решения. Завершено 80 проверок. Доля подтверждения среди решённых — 60 / 80 = 75%; среди всех поступивших — 60 / 100 = 60%. Это разные показатели, указывайте знаменатель.
Из 20 ожидающих восемь уже просрочены. Просроченная часть открытой очереди — 8 / 20 = 40%. Нельзя назвать остальные 20 отказами для красивого закрытия отчёта. Сначала назначьте владельцев восьми просрочек, затем разберите возраст остальных и причины ожидания.
Если 12 из 20 отказов связаны с повторными сообщениями, проверьте метод формирования когорты: действительно ли это уникальные заявки? В нашем расчёте повторные доставки уже исключены, поэтому такое объяснение потребовало бы исправления исходных данных. Арифметика должна соответствовать определению единицы учёта, а не только сходиться до ста.
Практическое задание: подготовьте такую таблицу для своего предложения без персональных данных. В кабинете рекламодателя сопоставьте её с доступными статусами конверсий; расхождения оформите отдельным списком для ответственного оператора. Не создавайте фиктивные оплачиваемые события ради проверки таблицы.
8. Учебный пример: пересмотрите спорное решение
Заявка L-041 отклонена как дубль L-019. Партнёр показывает, что это два разных идентификатора событий. Проверяющий восстанавливает версию условий: повторное обращение допустимо только для другого продукта. Затем сверяет продукт и время в источнике. Один лишь другой идентификатор ещё не доказывает правоту партнёра; один и тот же IP не доказывает правоту отказа.
Если подтверждено другое допустимое событие, уполномоченная сторона исправляет результат штатным способом. Сохраните первоначальное решение, новые доказательства, дату пересмотра и причину. Финансовое отражение проверяется отдельно: повторный постбек не должен использоваться как способ «добавить недостающее начисление».
Если решение остаётся прежним, ответ содержит конкретное правило и факт, а не только слово «отказ». Если доказательств всё ещё нет, назначьте следующий шаг и дату. Закрывать обращение только потому, что истёк внутренний срок, — плохая замена содержательному решению.
9. Измеряйте работу проверки, а не удобную цифру
Раз в неделю смотрите размер открытой очереди на конкретное время, число просрочек, медиану и 90-й процентиль времени до первого решения, долю решений с указанным основанием и результат пересмотров. Для времени до решения берите завершённые записи и отдельно показывайте возраст ещё открытых: иначе долгие нерешённые заявки исчезнут из показателя скорости.
Долю отменённых первоначальных решений считайте от разобранных обращений, а не от всех заявок. При трёх пересмотрах вывод о качестве источника ненадёжен. Сравнивайте одинаковые периоды, версии условий и достаточно созревшие когорты. Рост отказов может означать изменение определения события или ошибку обработки; сначала исследуйте причину.
10. Проверка готовности и следующий шаг
Перед пилотом убедитесь, что определены событие и версия условий; у очереди есть владелец и замена; сроки имеют точку отсчёта; причины сопровождаются доказательствами; запрос уточнения отличается от отказа; спор принимает назначенная сторона; изменения сохраняют историю; отчёт разделяет открытые и решённые заявки.
Проведите настольный разбор трёх учебных карточек: обычная заявка, повторное сообщение и спор с новыми данными. Критерий готовности — сотрудник по каждой карточке может назвать правило, следующий шаг, ответственного и срок. Если нет, уточните регламент до запуска, а не добавляйте новые статусы наугад.
Для подготовки предложения используйте материалы о понятной упаковке оффера и расхождениях отчётов. Здесь основной результат — воспроизводимое решение по каждой заявке, а не настройка атрибуции или обещание процента приёмки.
Зарегистрируйтесь рекламодателем AffiliateCore, заполните обязательные сведения и подготовьте свой оффер с согласованными условиями проверки. Допуск, необходимые проверки и модерация остаются отдельными этапами; создание предложения не гарантирует запуск или трафик. Сохраните регламент у своей команды и подтвердите доступный порядок взаимодействия с платформой до первого теста.