Техническое задание на postback перечисляет события registration, FTD и approved action, а также event ID, player ID, campaign ID, сумму, валюту, статус, timestamp и подпись.
Что считаем
Список событий и момент их отправки
Названия параметров и допустимые значения
Метод подписи или общий секрет
Политика retries и дедупликации
Сценарий
Поддержку и формат postback необходимо подтвердить в аккаунте: готовим список событий, параметры, безопасность и тесты.
Как сверяем
- Согласовать пример запроса для каждого события
- Проверить URL на тестовом endpoint
- Вернуть 2xx только после успешной записи
- Дедуплицировать повтор по event ID
Риски
- Считать любой deposit событием FTD
- Принимать запрос без проверки подписи
- Создавать дубликаты при повторной доставке
Что должно быть в техническом задании
События, поля, подпись, retries, event ID и коды ответа описываются до разработки. Приёмка включает повторную доставку одного события, чтобы доказать дедупликацию. Без сырого лога невозможно понять, ошибка возникла у отправителя, в сети или на endpoint.
Приёмка интеграции
Успешный ответ 200 ещё не доказывает корректную обработку. Endpoint должен сохранить event ID, связать событие с click ID и безопасно принять повторную доставку без второй конверсии. В журнале остаются время, подпись, тело запроса и код ответа, но не секретные ключи в открытом виде.
Отдельно проверьте неизвестное событие и запрос с неверной подписью. Система должна отклонить их предсказуемо, чтобы случайный или поддельный запрос не попал в статистику.
Что делает postback пригодным для расследования
У каждого события должен быть стабильный event ID и понятная связь с click или SUB_ID. Получатель сохраняет timestamp, тип события, сумму, валюту и статус, а секрет подписи не пишет в открытый лог. При повторной доставке тот же event ID обновляет или подтверждает запись, но не создаёт вторую конверсию.
Отдельный негативный тест нужен для неверной подписи и неизвестного event type. Предсказуемый отказ важен не меньше успешного 200: он показывает, что случайный запрос не сможет тихо попасть в статистику.
Postback готов, когда один тестовый event можно найти в логах отправителя и получателя по одному ID. Ошибка имеет понятный статус, а повторная доставка не увеличивает конверсию.
Частые вопросы
Какие поля обязательно должны быть в postback-запросе?
Event ID, player ID, campaign ID, сумма, валюта, статус, timestamp и подпись — без них сложно связать событие с конкретным кликом и защититься от подделки.
Как проверить, что postback не создаёт дублирующиеся конверсии?
Отправить одно и то же событие повторно и убедиться, что оно дедуплицируется по event ID, а не засчитывается как вторая конверсия.
Что должен вернуть endpoint, чтобы приёмка считалась успешной?
Код 200 только после того, как событие реально сохранено, а не сразу при получении запроса — иначе ошибка сети может выглядеть как успешная обработка.