Один заказ, три источника
В учебном магазине посетитель сначала нашёл статью в поиске, затем вернулся через контекстную рекламу и оформил заказ после перехода с сайта партнёра. Аналитика может показать вклад каждого канала, а договор программы указывает, какой переход участвует в оплате. Сравните дату и часовой пояс, последовательность касаний и согласованное окно. Отдельно прочитайте правила для промокодов и существующих покупателей, если они влияют на право на выплату.
Храните для сверки стабильный идентификатор заказа, историю смены статуса и разрешённые технические сведения об источнике. Сверьте, что выгрузка аналитики и реестр выплат используют совместимые идентификаторы и границы периода. Если у партнёра и рекламной системы разные определения конверсии, две отметки в интерфейсах могут описывать один заказ. Решение об оплате должно следовать из условий программы и проверяемых событий.
Отделяем ошибку данных от возможного фрода
Если за минуту в кабинете появились три одинаковые суммы, сначала сравните идентификаторы. Один идентификатор с несколькими попытками доставки может означать повтор после сетевой ошибки. Три разных заказа могут оказаться настоящими покупками с типовым чеком. Сопоставьте записи с заказами CRM и запросите журнал обмена. Если данных недостаточно, оставьте спорные события на ручной проверке в пределах согласованного срока и зафиксируйте причину.
В учебном примере из 24 отмеченных записей 12 оказались повторной доставкой, семь совпали с подтверждёнными заказами и ещё пять требуют проверки. После исправления повторов разберите только пять спорных строк. Одинаковая длительность сессии или одна подсеть помогают выбрать выборку для просмотра. Для отказа нужна установленная причина, которую можно объяснить партнёру и подтвердить данными.
Оформляем решение и исправляем причину
Заведите разные коды для атрибуции в пользу другого источника, технического повтора, отменённого заказа и нарушения условий. Передайте вебмастеру технический ключ, статус и описание правила в пределах договора и допустимого обмена данными. Назначьте срок ответа и сотрудника, который сможет сверить исходное событие при апелляции.
После разбора проверьте, что сделанное исправление устраняет причину. Если проблема была в повторном постбэке, смоделируйте потерянный ответ при уже сохранённой записи. Если проблема возникла из-за границ окна атрибуции, добавьте в проверку события прямо до и после его окончания. Через следующий закрытый период сравните число ручных разбирательств и долю решений, которые пришлось менять.