Настройка postback в iGaming: события, макросы и тестирование

Как движутся данные

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

Трекер получает запрос, находит исходный клик и обновляет конверсию. Если идентификатор потерян или макрос указан неверно, событие не свяжется с расходом.

Порядок настройки

Работайте по документации конкретного кабинета: названия параметров и макросов нельзя угадывать.

• создать тестовую кампанию и click ID
• передать идентификатор в поддерживаемый sub-параметр
• собрать URL с макросами event, payout и currency
• выполнить тестовый запрос для каждого нужного статуса
• проверить журнал ответов и защиту от дублей

Что мониторить после запуска

Даже рабочая интеграция может деградировать после изменения URL, трекера или формата макроса.

Безопасность и отказоустойчивость

Postback URL не должен позволять постороннему легко создавать фиктивные события.

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

Диагностика пропавших событий

Клики видны в партнёрке, а FTD не появляются в трекере. В журнале postback обнаруживаются ответы 404: после переноса трекера URL изменился, но кабинет остался со старым адресом.

Команда обновляет endpoint, отправляет тестовое событие и проверяет click ID. После исправления новые конверсии приходят, а исторические можно восстановить только если кабинет позволяет повторную отправку или экспорт.

Тест postback должен быть воспроизводимым

Запишите URL, названия макросов, обязательные параметры, валюту, формат суммы и ожидаемый ответ сервера. Затем вызовите одно доступное тестовое событие и сохраните полный request/response.

Если событие не дошло, проверьте HTTP-код, кодировку, пустые параметры, дедупликацию и соответствие имени события. Повторная ручная отправка без понимания причины может создать дубль.

Минимальный тестовый набор postback

Начните с небольшого набора событий: registration, FTD и qualified/approved. Для каждого определите уникальный event ID, click ID, сумму, валюту, статус и время. Endpoint должен отвечать кодом 2xx только после успешной обработки, а повтор события с тем же ID не должен удваивать конверсию.

event=ftd&click_id={click_id}&event_id={event_id}&amount={amount}&currency={currency}&status={status}

Во время теста сохраните исходящий запрос программы и входящий лог трекера. Проверьте URL-кодирование, пустые макросы, HTTPS, таймауты и повторные отправки. После запуска настройте уведомление о росте ошибок и расхождении между кабинетом и полученными событиями.

Чек-лист приёмки интеграции

• тестовый клик виден в трекере и кабинете;
• registration и FTD приходят с правильными event ID;
• валюта и сумма не меняют формат между событиями;
• повторный запрос не создаёт дубль;
• изменение pending→approved обновляет существующую запись;
• ошибка endpoint попадает в мониторинг и журнал повторов.

Интеграция считается принятой только после полного сценария. Успешный одиночный ping без реальной атрибуции не подтверждает готовность.

Мониторинг после запуска

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

Логи должны храниться достаточно долго, чтобы покрывать холд и позднее изменение статуса. При этом персональные данные следует минимизировать и защищать.

Безопасность endpoint

Принимайте запросы только по HTTPS, проверяйте секрет или подпись, ограничивайте размер payload и не выводите чувствительные параметры в публичные логи. Ошибочный endpoint не должен раскрывать стек приложения. Доступ к журналам выдаётся только тем, кто отвечает за интеграцию.