Что делает postback
Postback — это серверная передача события между системами. В партнёрском маркетинге он помогает вернуть информацию о регистрации, FTD или подтверждённом действии в трекер или рекламную систему без зависимости от браузерного cookie.
Какие данные нужны для связи события
Ключевой элемент — идентификатор клика или другая метка, которую можно передать при переходе и получить обратно при событии. Без этого система знает, что конверсия произошла, но не понимает, к какой кампании её привязать.
| Элемент | Задача |
|---|---|
| click_id | связать событие с исходным кликом |
| SubID | сохранить разрез кампании |
| event | понять тип конверсии |
| payout / value | передать значение, если это предусмотрено |
| timestamp | помочь при сверке времени |
Как тестировать интеграцию
Не начинайте с реального рекламного бюджета. Сначала сделайте контролируемый тестовый переход с уникальным идентификатором. Затем проверьте цепочку по шагам:
- click_id записался на переходе;
- он виден в партнёрской системе;
- тестовое событие сформировано;
- postback отправлен;
- трекер принял нужный event;
- событие связано с исходным кликом.
Почему тест «получили 200 OK» недостаточен
HTTP 200 означает только то, что endpoint ответил успешно. Он не гарантирует правильное значение event, валюты или идентификатора. После запроса нужно посмотреть, как событие реально записалось в принимающей системе.
Частые причины расхождений
- click_id обрезается редиректом;
- одна система кодирует значение иначе;
- события отправляются в другом часовом поясе;
- используется неверное имя параметра;
- повторное событие считается дублем;
- тест проводится с кэшированным старым URL.
Как вести лог
Для диагностики полезно сохранять дату, URL без чувствительных данных, код ответа и идентификатор события. Не логируйте пароли, токены и персональные данные в открытом виде.
Связь с разметкой
Postback не заменяет аккуратную структуру кампаний. Сначала определите UTM и SubID, затем возвращайте события в тот же аналитический контекст. Так отчёт отвечает не только на вопрос «сколько было FTD», но и «откуда пришли подтверждённые FTD».
Разделите тестирование по событиям
Не пытайтесь сразу проверить всю цепочку registration → FTD → confirmed. Протестируйте каждое событие отдельно и убедитесь, что оно имеет уникальное имя и правильный статус. Если один endpoint принимает несколько типов событий, ошибка в названии может приводить к тому, что все они записываются одинаково.
Повторная отправка и дедупликация
Хорошая интеграция должна понимать, что будет при повторном запросе. Если сеть временно вернула ошибку, система может попытаться отправить событие снова. Нужен стабильный идентификатор, чтобы повтор не превратился в вторую конверсию.
Безопасность параметров
Токены и секреты не должны попадать в публичные страницы, скриншоты или UTM. Если endpoint требует секретный параметр, храните его на серверной стороне. Логи для диагностики тоже должны исключать чувствительные значения.
Документация интеграции
Сохраните рабочий пример URL с заменёнными секретами, описание каждого параметра и дату теста. Через полгода это позволит быстро понять текущую схему, даже если интеграцию настраивал другой человек.
Обрабатывайте ошибки явно
Если принимающая сторона временно недоступна, интеграция должна различать успешный ответ и ошибку. Для критичных событий полезна очередь повторной отправки с ограничением числа попыток. Иначе краткий сбой превращается в постоянную дыру в аналитике.
Следите за порядком событий
Иногда FTD приходит раньше, чем registration успел обработаться в другой системе. Если логика жёстко требует определённой последовательности, событие может потеряться. Тестируйте не только «идеальный» порядок, но и задержки.
Контроль после изменений
Любая смена домена, трекера, редиректа или параметров ссылки — повод повторить end-to-end тест. Интеграция может выглядеть независимой, но click_id часто проходит через всю цепочку и легко теряется при миграции.