S2S tracking в партнёрке казино: архитектура надёжной передачи событий

Где находится S2S в цепочке данных

Трекер создаёт click ID и передаёт его партнёрской платформе. Когда происходит регистрация, FTD или изменение статуса, сервер платформы отправляет запрос на endpoint партнёра.

Postback является конкретным уведомлением внутри S2S-схемы. Полная архитектура также включает хранение кликов, сопоставление статусов, повторные попытки, защиту от дублей и финансовую сверку.

Как спроектировать интеграцию

Сначала составьте карту событий и идентификаторов, а уже затем собирайте URL или API-запрос.

• назначить уникальный click ID и правила его хранения
• описать события и допустимые переходы статусов
• защитить запрос токеном или подписью
• сделать обработку повторов идемпотентной
• добавить журнал, алерт и процедуру повторной сверки

Показатели качества интеграции

S2S считается рабочим не после одного успешного теста, а когда стабильно передаёт и объясняет все события.

Технические риски

Большинство сбоев не видно пользователю и обнаруживается только по логам или расхождению отчётов.

• click ID обрезается на промежуточном редиректе
• один статус имеет разные названия в системах
• повтор запроса создаёт двойной доход
• endpoint недоступен без очереди повторов
• секрет хранится в открытом репозитории или логе

Обработка смены статуса

Событие FTD сначала приходит как pending, затем как approved. Если трекер создаёт две отдельные конверсии, доход удваивается. Правильная схема использует единый event ID и обновляет статус существующей записи.

При повторной отправке того же approved-запроса endpoint возвращает успешный ответ, но не изменяет баланс второй раз. Это и есть идемпотентная обработка.

Архитектура S2S должна переживать повторную отправку

Click ID создаётся на вашей стороне и передаётся в партнёрскую систему. При postback он должен вернуться без изменения. Endpoint обязан проверять подпись или источник, логировать запрос и корректно обрабатывать повтор события.

Заранее определите ключ дедупликации и правила обновления статуса. Иначе pending и approved одного события могут превратиться в две конверсии.

Идемпотентность и повторная доставка событий

Серверные события могут отправляться повторно при таймауте или временной ошибке. Поэтому event ID должен быть уникальным, а при повторе система обязана обновить статус или вернуть успешный ответ без создания второй конверсии.

Логируйте время получения, исходный payload, результат валидации и ответ endpoint. Чувствительные данные не следует помещать в открытые query-параметры. Для теста используйте отдельный click ID и последовательно проверьте регистрацию, FTD, изменение статуса и повторную доставку.

Схема контроля данных между системами

Ежедневная сверка сравнивает количество событий и суммы по дате события, а не только по дате получения. Расхождение разделяют на задержанные события, дубли, неизвестные click ID и разные статусы. Для каждого класса задаётся допустимый порог.

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

План восстановления после сбоя

Определите, можно ли переотправить события из журнала и как избежать дублей. При сбое сохраните временной диапазон, affected endpoint и список event ID. После восстановления сначала обработайте небольшой пакет и сверьте результат.

Ручная массовая переотправка без idempotency способна создать больший ущерб, чем исходная потеря.

Ответственность за интеграцию

Назначьте владельца endpoint и контакт со стороны партнёрки. При инциденте должно быть понятно, кто проверяет доставку, кто бизнес-статус и кто принимает решение о переотправке. Техническая ошибка без владельца часто остаётся незамеченной до выплаты.