Постбэки в партнёрском маркетинге: от click ID до подтверждённой конверсии
Как на практике выстроить серверный учёт конверсий: click ID, проверка постбэков, дубли, смена статусов и сверка.
Что делает постбэк
Постбэк — это серверное уведомление (server-to-server), которое сообщает о событии другой системе. В партнёрской аналитике он связывает более позднюю конверсию с исходным кликом. Admitad описывает постбэки для вебмастеров как способ передавать данные о конверсиях напрямую в систему вебмастера.
Постбэк — это способ доставки, а не гарантия одобрения комиссии. Событие может описывать ожидающее действие, подтверждение или позднее изменение. Ваша интеграция должна интерпретировать статус и модель событий провайдера, а не рассматривать каждый запрос как новый доход.
Сохраняйте клик до того, как отправить посетителя дальше
Сгенерируйте обезличенный click ID и сохраните к нему партнёра, оффер, место размещения и время. Передайте этот ID в поддерживаемое сетью поле трекинга. Когда придёт постбэк, найдите исходный клик в базе. Не полагайтесь на метку партнёра из постбэка вместо этой связи.
Если сеть не умеет возвращать ваш click ID, до запуска договоритесь о другом задокументированном ключе для сверки. По отчёту, где есть только общие итоги кампании, нельзя надёжно распределить результаты между несколькими партнёрами.
Проверяйте и обрабатывайте постбэки безопасно
Используйте авторизацию или подпись, которые поддерживает сеть, храните секреты только на сервере и отклоняйте некорректные запросы. Проверяйте допустимые статусы, формат суммы, валюту и ID транзакций. Не переходите по произвольным URL из входящих полей и не пишите секреты постбэков в логи.
Сначала надёжно сохраните событие и только потом подтверждайте его приём. Обрабатывайте события в транзакции или через очередь с повторами. Если сервис упадёт после получения события, но до обновления итогов, повторная обработка должна завершить обновление без дублирования. Неудачные события храните для разбора.
Сделайте повторную доставку безопасной
Используйте ID транзакции в рамках конкретной сети, а также ID события или версии, если они есть. Повторное уведомление не должно добавлять вторую комиссию. Более позднее обновление статуса той же транзакции должно менять её состояние, сохраняя историю событий.
Допустим, транзакция пришла сначала в статусе «ожидает», потом «одобрена», потом её скорректировали. Одобренная сумма не должна учитываться заново при каждом уведомлении. Если события приходят не по порядку, опирайтесь на задокументированную последовательность сети или на время обновления; если это невозможно, помечайте спорный случай, а не придумывайте своё правило.
Сверяйтесь, даже если постбэки работают
Регулярно сверяйте сохранённые транзакции с отчётами сети. Пропущенные постбэки, click ID без пары и изменённые суммы должны попадать в список расхождений. Дату последней успешной сверки храните отдельно от даты последнего постбэка.
- Отправьте одно и то же событие дважды и проверьте, что итоги не изменились.
- Проверьте неверную авторизацию и неизвестные click ID.
- Отправьте обновления статусов в обратном порядке.
- Остановите обработку и повторите событие.
- Сверьте итоговые суммы партнёров с исходным отчётом.
Это рекомендации по внедрению, а не утверждение, что все сети передают одинаковые данные. Подробнее — в статье об отчётности по статусам конверсий (как показывать партнёрам отложенные и скорректированные результаты).