Постбек может вернуть 200 OK и всё равно не создать конверсию. Он может появиться в трекере, но не попасть в рекламную платформу. А повторный callback иногда выглядит как «ещё одна продажа», хотя это обычный retry партнёрской сети.
Поэтому вопрос «приходит ли постбек» слишком общий. Нужно проверить четыре независимых слоя: доставка запроса, поиск клика, интерпретация события и запись результата. Ниже — практический порядок диагностики, который локализует поломку, а не маскирует её повторной настройкой URL.
Если сначала нужно понять роли параметров, откройте гайд по Click ID, Sub ID и макросам. Для сборки тестового callback используйте Postback URL Builder.
Как выглядит исправная цепочка
- Трекер создаёт уникальный внутренний click ID.
- Этот ID передаётся в оффер через подходящее sub-поле.
- Партнёрская система сохраняет значение без изменений.
- При конверсии она подставляет значение в свой postback-макрос.
- Трекер получает callback, находит исходный клик и нормализует статус.
- Уникальный transaction ID защищает выручку от повторов.
- При необходимости подтверждённое событие отправляется в Meta, TikTok или другую платформу.
Проблема на любом шаге требует своего исправления. Смена домена не поможет, если сеть возвращает campaign ID вместо click ID; новый токен API не исправит незамапленный статус dep.
Быстрый pass/fail-чек-лист
| Участок | Ожидание | Факт | Pass? |
|---|---|---|---|
| Входной клик | Создан один уникальный click ID | Запишите ID из raw click log | ☐ |
| URL оффера | ID передан в согласованное sub-поле | Сравните финальный URL после редиректа | ☐ |
| Хранение | Сеть сохранила значение побайтно | Проверьте click/conversion log сети | ☐ |
| Callback URL | Макрос раскрыт, скобок в запросе нет | Сохраните сырой URL | ☐ |
| HTTP | Запрос дошёл до правильного endpoint | Код, время, response body | ☐ |
| Поиск клика | Трекер нашёл исходный click ID | Не только HTTP 200, но и ingress result | ☐ |
| Статус | Сырой статус попал в нужную цель | dep → deposit, например | ☐ |
| Деньги | Payout и currency распознаны правильно | Сверьте с записью сети | ☐ |
| Dedup | Повтор не создаёт вторую выручку | Отправьте тот же transaction ID дважды | ☐ |
| Feedback | В платформу ушло правильное событие | Проверьте журнал CAPI/Events API | ☐ |
Шаг 1. Зафиксируйте один контрольный клик
Не диагностируйте постбек на потоке из тысяч переходов. Создайте один контрольный клик и запишите:
- точное время и timezone;
- внутренний click ID трекера;
- campaign, stream и offer;
- полный outbound URL после всех редиректов;
- поле, в которое сеть должна сохранить ID.
Click ID — непрозрачная строка. Его нельзя обрезать, приводить к числу, менять регистр или декодировать «для удобства». Даже одно отличие означает другой ключ.
Шаг 2. Проверьте передачу ID вперёд
Допустим, сеть принимает произвольное значение в aff_sub:
https://network.example/offer?aff_sub={click_id}После редиректа вы должны увидеть реальное значение:
https://network.example/offer?aff_sub=dc_01K2A7M9X4Если остались {click_id} или %7Bclick_id%7D, макрос не раскрылся. Если поле пустое — проверьте, где именно выполняется шаблонизация: в трекере, PWA, лендинге или внешнем redirect-сервисе. Если ID виден в первом URL, но теряется после промежуточного редиректа, постбек здесь ни при чём: сначала сохраните параметр на forward-path.
Шаг 3. Разберите сырой callback, а не шаблон
Настроенный шаблон может выглядеть правильно:
https://track.example/p?click_id={aff_sub}&status={status}&payout={payout}Но важен запрос, который реально отправила сеть:
https://track.example/p?click_id=dc_01K2A7M9X4&status=dep&payout=45.00&txid=7719Проверьте четыре вещи:
- макросы раскрыты;
- значение click ID точно совпадает с контрольным кликом;
- специальные символы корректно URL-encoded;
- endpoint принадлежит нужному workspace и окружению.
Согласно диагностическому гайду Adset, типовые причины — сырой макрос вместо значения, изменённый идентификатор, неверное соответствие статусов и ошибка авторизации. Эти причины удобно проверять именно по сырому запросу.
Шаг 4. Не считайте 200 OK доказательством конверсии
HTTP-код отвечает только на вопрос, принял ли endpoint запрос на транспортном уровне. Многие системы возвращают общий успешный ответ и для неизвестного click ID, дубля или события, которое сознательно проигнорировано.
В ingress-журнале нужен машинно различимый результат:
accepted— новая конверсия записана;duplicate— событие уже было обработано;click_not_found— идентификатор не найден;status_unmapped— сырой статус неизвестен;invalid_payout— сумма не распознана;unauthorized— неверный ключ или подпись.
Если такого журнала нет, ставьте промежуточный request catcher только для теста. Не отправляйте туда реальные персональные данные или production-токены.
Шаг 5. Проверьте статус отдельно от click ID
Найденный клик ещё не означает правильную бизнес-конверсию. Одна сеть отправляет lead, sale, dep; другая — registration, ftd, approved. Зафиксируйте явную таблицу:
| Сырой статус | Внутренний статус | Отправлять в платформу? | Учитывать revenue? |
|---|---|---|---|
reg | Registration | По политике оптимизации | Нет |
dep | First deposit | Да | Да |
approved | Approved sale | Да | Да |
rejected | Rejected | Нет или correction | Нет |
В DarkCore статусы настраиваются в Conversion Statuses. Не подменяйте различие «регистрация против депозита» одним событием Lead: это ухудшает и отчётность, и обратную связь рекламной платформе.
Шаг 6. Проверьте payout, currency и correction
payout=45 может означать комиссию, доход рекламодателя или сумму заказа. Договоритесь о семантике до интеграции. Передавайте число отдельно от currency и проверьте десятичный разделитель.
Особый случай — изменение статуса или суммы после первой записи. Здесь нужен не второй независимый sale, а корректировка существующей транзакции. Используйте стабильный transaction_id и сохраняйте историю изменений, иначе reconciliation превратится в ручное вычитание.
Шаг 7. Проведите тест на дубль
Отправьте один и тот же callback дважды. Ожидаемый результат:
- первый запрос создаёт событие;
- второй фиксируется как duplicate;
- количество конверсий и revenue не увеличивается;
- downstream CAPI/Events API не получает второе событие.
Надёжный ключ дедупликации — уникальный ID транзакции от источника плюс тип события. Один click ID сам по себе не всегда достаточен: один пользователь может дать регистрацию, первый и повторный депозит.
Шаг 8. Если событие есть в трекере, но его нет в Meta или TikTok
Это уже отдельный участок. Проверьте:
- разрешено ли отправлять именно этот внутренний статус;
- сохранён ли идентификатор платформы (
fbclid/fbcилиttclid); - валиден ли access token;
- принято ли событие API, а не только поставлено в очередь;
- одинаков ли
event_idу Browser Pixel и CAPI-копии; - нет ли задержки или отклонения по качеству данных.
Роли Pixel, CAPI и S2S postback разобраны в сравнении Pixel vs CAPI vs Postback. Официальная документация TikTok подтверждает, что ttclid добавляется к landing URL и используется для атрибуции и измерения; его нельзя заменять произвольным campaign-параметром (TikTok Ads Help).
Частые симптомы и вероятная причина
| Симптом | Сначала проверьте |
|---|---|
В callback остались {...} | Синтаксис макроса системы-отправителя |
click_not_found | Forward-параметр и точное значение click ID |
| Конверсия на другой кампании | Переиспользование или перезапись sub-поля |
| Есть registration, нет deposit | Отдельный callback и маппинг статуса dep/ftd |
| Revenue удваивается | Transaction ID и idempotency |
| Трекер видит событие, Meta нет | Click identifier, token, event policy и API log |
| Meta показывает больше | Окна, modeled attribution и Pixel+CAPI dedup |
| Трекер показывает больше | Неподходящий фильтр статусов или органические события |
Минимальный пакет доказательств для поддержки
Вместо «постбек не работает» отправьте:
- timestamp с timezone;
- тестовый click ID;
- outbound URL без секретов;
- сырой callback URL с замаскированным токеном;
- HTTP code и response body;
- ingress result;
- ожидаемый и фактический статус;
- transaction ID;
- скрин или export одной строки конверсии.
Такой пакет позволяет поддержке сразу работать с конкретным участком, а не просить повторить настройку вслепую.
FAQ
Почему тестовый postback работает, а реальный нет?
Ручной тест часто содержит правильно подставленный click ID, а production-шаблон возвращает пустое поле или буквальный макрос. Сравните сырой URL реального запроса с тестовым побайтно.
Можно ли диагностировать через браузер?
Можно проверить доступность GET-endpoint, но браузер не доказывает, что партнёрская сеть умеет раскрыть макросы, подписать запрос и повторить его по своей retry-политике.
Какой параметр обязательный?
Для атрибуции — стабильный click ID. Для безопасного учёта нескольких событий и повторов также нужен transaction ID. Статус и payout необходимы, если они влияют на оптимизацию и финансы.
Когда считать проблему закрытой?
Только после end-to-end теста: контрольный клик → оффер → первая конверсия → повтор callback → смена статуса/суммы → downstream feedback. Результатом должна быть заполненная pass/fail-таблица, а не ощущение, что «вроде приходит».