S2S-постбек-трекінг передає дані про конверсії та статуси лідів від рекламодавців і баєрів назад у систему, яка відправила трафік. Клік може привести користувача на офер, але поки баєр не повідомить, що сталося далі, ваша платформа не знатиме, чи став цей клік прийнятим лідом, відхиленим лідом або конверсією. Без цього сигналу маршрутизація працює наосліп: ви продовжуєте надсилати трафік, не знаючи, які напрямки приносять результат.
Постбек пов’язує клік із його результатом за допомогою ID, який передається між системами. Це робить його важливою частиною трекінгу партнерських посилань і роботи з лідами. Постбек також дає команді змогу діяти на основі фідбеку від баєрів: поставити на паузу напрямок, що досяг капа, обійти джерело відмов або спрямувати більше трафіку на офер, який приймає ліди й конвертує їх.
Налаштувати все нескладно, але невідповідність навіть у дрібницях може порушити роботу інтеграції. ID кліку має зберігатися під час кожного редиректу, баєр має викликати правильний URL, а обидві сторони — однаково трактувати кожен статус. Розгляньмо, як поєднати всі компоненти.
Як працює S2S-постбек-трекінг
Типовий ланцюжок S2S-трекінгу має такий вигляд:
- Клік отримує ID. Трекінгова платформа створює унікальний ID, коли користувач клікає на партнерське посилання або переходить у лід-флоу. ID записується разом із даними про кампанію, джерело, гео та пристрій.
- ID передається оферу або баєру. Редирект чи інтеграція для розподілу лідів додає ID кліку до URL або запиту на цільову сторінку. Цільова система має зберегти його разом із даними про клік або лід.
- З’являється конверсія або статус ліда. Баєр чи рекламодавець обробляє подію. Це може бути прийнятий страховий лід, відхилена заявка на фінансовий продукт, продаж з nutra-оферу або конверсія зі sweepstakes-оферу.
- Сервер баєра викликає ваш постбек-URL. У запиті передаються початковий ID кліку та результат. Також можуть передаватися виплата, ID транзакції або інші поля, які використовує ваше налаштування.
- Платформа знаходить і записує подію. Вона знаходить клік за ID, додає статус і суму до початкового запису про трафік та оновлює звітність.
- Спрацьовує постбек партнеру, якщо його налаштовано. Ваша платформа може передати результат афіліату, мережі або іншій системі, використовуючи потрібні цьому партнеру назви параметрів і мапінг статусів.
Останній крок особливо важливий, якщо ви працюєте з кількома партнерами. Баєр може передавати статус «accepted», тоді як афіліат очікує «approved». Зіставляйте статуси явно, а не пересилайте вихідні значення навмання, сподіваючись, що кожна система трактуватиме їх однаково.
У схемі лідогенерації ця логіка може працювати разом із API для розподілу лідів. API може передати лід баєру й отримати миттєву відповідь, а постбек — повідомити про пізніший результат, наприклад про те, чи прийняв баєр лід або чи конвертував його. Для надійної інтеграції з API баєра визначте, які події надходять у відповіді API, а які передаються пізніше через постбек.
Структура постбек-URL
Постбек-URL — це кінцева точка, яка отримує дані про результат. Ваша трекінгова платформа надає базовий URL і список підтримуваних токенів. Під час надсилання колбеку баєр підставляє в ці токени значення зі своєї системи.
Приклад: https://tracker.example/postback?click_id={click_id}&status={status}&payout={payout}&sub1={sub1}&sub2={sub2}&txid={transaction_id}
Це шаблон, а не універсальний формат. Одна платформа може очікувати параметр click_id, а інша — використовувати іншу назву токена. Перевірте параметри платформи, яка прийматиме запит, і зіставте їх із доступними полями баєра. Якщо баєр використовує інші назви статусів, узгодьте значення до запуску.
| Параметр | Призначення | Типова помилка |
|---|---|---|
| click_id | Зіставляє результат із початковим кліком або лідом. | Передати інший ID, обрізати його або втратити під час редиректу. |
| status | Передає подію, наприклад прийняття, відхилення або конверсію. | Використати значення, яке платформа-отримувач не розпізнає, або позначити прийняття як конверсію. |
| payout | Передає суму, пов’язану з подією. | Надіслати форматоване значення із символом валюти, хоча платформа очікує число. |
| sub-ID | Передають дані для атрибуції, наприклад джерело, розміщення або ID паблішера. | Перезаписати sub-ID або вважати його ID кліку. |
| ID транзакції | Ідентифікує подію в системі баєра та допомагає виявляти дублікати колбеків. | Не передати його, коли він доступний, або використати замість ID кліку. |
Використовуйте sub-ID для значень, які справді потрібні у звітності або звірці з партнером. Залишайте ID кліку для зіставлення подій. Якщо ви також передаєте персональні дані про ліда, дотримуйтеся партнерських угод і збирайте лише те, що потрібно для флоу.
Перед запуском значного обсягу трафіку перевірте шлях на реальному кліку. Переконайтеся, що ID кліку доходить до цільової системи, запустіть тестову подію та перевірте, чи платформа записала правильний статус і виплату. Потім переконайтеся, що партнерський постбек містить очікувані ID і зіставлені значення. Успішна HTTP-відповідь сама по собі не доводить, що подію зіставлено з правильним кліком.
Піксель, S2S-постбек чи API
| Метод | Надійність | Залежність від cookie | Складність налаштування | Для чого найкраще підходить |
|---|---|---|---|---|
| Піксель | Подію можна втратити, якщо сторінка не завантажиться, браузер закриється або скрипти буде заблоковано. | Часто залежить від ідентифікаторів або cookie на боці браузера — залежно від реалізації. | Зазвичай легко встановити, але потрібно перевірити поведінку браузера. | Базові події в браузері, якщо ви контролюєте сторінку підтвердження. |
| S2S-постбек | Сервер напряму надсилає подію; зіставлення й надалі залежить від правильних ID та обробки колбеків. | Для колбеку не потрібні сторонні cookie в браузері. | Потрібно передавати ID, налаштувати URL і зіставити статуси. | Партнерські конверсії та результати баєрів, зокрема відкладені статуси лідів. |
| API | Підтримує структуровані запити й відповіді; надійність залежить від реалізації, повторних спроб і обробки помилок. | Не залежить безпосередньо від cookie браузера. | Потребує більше координації та розробки, ніж базовий колбек. | Передача лідів, інтеграції з баєрами та процеси, яким потрібен обмін розширеними даними. |
У партнерському маркетингу та лідогенерації S2S зазвичай використовують для передачі результатів, оскільки баєр може повідомити платформу зі свого сервера, не покладаючись на завантаження сторінки конверсії в браузері користувача. Але це не забезпечує атрибуцію автоматично: якщо ID кліку втрачено, постбек не зможе виправити зіставлення. А якщо баєр узагалі не надішле колбек, платформі не буде чого записувати як результат.
Використовуйте пікселі для простих подій у браузері, якщо контролюєте сторінку. API стане в пригоді, коли потрібно передавати ліди, обмінюватися структурованими даними або обробляти відповіді в межах робочого процесу. S2S-постбеки використовуйте, щоб передавати результати системі, яка відстежувала або маршрутизувала трафік. Докладніше про трекінг із меншою залежністю від даних у браузері читайте в матеріалі трекінг із мінімальним використанням cookie.
Отримані сигнали можна використовувати для наступних рішень щодо маршрутизації. Hyperone враховує результати баєрів разом із правилами капів, джерел, гео та доступності напрямків. Так трафік можна перенаправити, щойно баєр перестане приймати ліди, замість того щоб і далі відправляти їх у глухий кут.
Три потрібні потоки постбеків
Повне налаштування S2S-постбек-трекінгу передає результати між усіма сторонами, яким вони потрібні. Точний ланцюжок залежить від того, чи ви відстежуєте конверсію з оферу, надсилаєте дані паблішеру або розподіляєте ліди між баєрами.
Від рекламодавця до мережі: конверсії
Коли рекламодавець фіксує конверсію, його сервер викликає постбек-URL вашої мережі, передаючи ID кліку та деталі конверсії. Платформа знаходить початковий візит за ID кліку, а потім записує статус, виплату та, за наявності, ID транзакції.
До запуску узгодьте, що саме вважається подією. Надсилання форми, схвалення заявки та виданий кредит — це різні результати. Якщо рекламодавець позначає лід як конверсію одразу після надсилання форми, а ваша команда очікує на схвалення, звіти й рішення з оптимізації не збігатимуться.
Від мережі до паблішера: партнерські постбеки із sub-ID
Зіставивши результат, мережа може надіслати партнерський постбек паблішеру, який залучив клік. Передавайте ID кліку паблішера та значення sub-ID, що використовуються для ідентифікації кампанії, розміщення або креативу. Так паблішер зможе побачити, який трафік приніс результат, без передавання зайвої персональної інформації.
Використовуйте однакові назви параметрів і значення статусів у всіх кампаніях. Якщо один офер передає «approved», а інший для тієї самої події — «sale», задокументуйте мапінг, щоб паблішер міг правильно трактувати обидва значення.
Від баєра до дистриб’ютора лідів: прийнято, відхилено, повернено
У лідогенерації баєр або його CRM має передавати дистриб’ютору чіткий статус ліда. Типові статуси: прийнятий, відхилений і повернений. Ці результати можна передавати через API для розподілу лідів або інтеграцію з API баєра, а для простішого налаштування може вистачити колбеку чи постбек-URL.
Визначте, коли кожен статус вважається остаточним і які дані передаються разом із ним. Наприклад, причина відхилення — дублікат, нецільове гео або некоректні контактні дані — допоможе виявити проблеми з якістю та покращити рішення щодо маршрутизації.
Як використовувати статуси баєрів для маршрутизації
Не обмежуйтеся використанням постбеків лише для звітності. Якщо правила вказують на проблеми з якістю, відхилення та повернення мають знижувати пріоритет джерела для цього баєра. Статус прийняття допомагає контролювати капи баєрів і визначати, чи може трафік і далі надходити на цей напрямок.
За можливості використовуйте коди причин. Відхилення ліда через нецільове гео може вказувати на помилку в гео-правилі; часті відхилення через некоректні контактні дані можуть бути підставою знизити пріоритет цього джерела. Повернений лід може означати, що баєр виявив проблему вже пізніше, тому команда має відрізняти такий статус від первинного відхилення.
Припустімо, денний кап баєра — 200 лідів. Якщо кількість прийнятих лідів наближається до капа, правила розподілу можуть спрямувати наступний відповідний лід іншому доступному баєру, а не продовжувати надсилати його на напрямок, який досяг капа. Якщо баєр частіше відхиляє ліди з певного джерела, можна знизити пріоритет цього джерела для нього, залишивши його доступним для інших. Налаштуйте капи баєрів і резервну маршрутизацію з урахуванням статусів і лімітів, важливих для ваших кампаній.
Переконайтеся, що колбек надходить достатньо швидко, аби бути корисним. Статус, який потрапляє в систему через кілька годин після передачі ліда, допоможе у звітності, але може надійти запізно для наступного рішення щодо маршрутизації.
Тестування та усунення проблем
Перш ніж надсилати живий трафік, протестуйте весь ланцюжок. Успішна відповідь сервера не доводить, що клік було зіставлено, статус правильно перетворено або партнер отримав потрібну подію.
- Перевірте клік від початку до кінця. Створіть тестовий клік, передайте його ID через флоу оферу або баєра, запустіть тестову подію та переконайтеся, що вона з’явилася у правильному записі.
- Перевірте макроси. Переконайтеся, що кожна система підставляє замість ID кліку та інших макросів реальні значення. Якщо в отриманому URL залишився незмінений токен, зазвичай це означає, що макрос не підтримується або зіставлений неправильно.
- Перевірте дублікати ID транзакцій. Надішліть ту саму тестову подію двічі. Переконайтеся, що система дедуплікує її або позначає повтор, а не зараховує конверсію двічі.
- Перевірте часові пояси та мапінг статусів. Порівняйте час подій у різних системах і переконайтеся, що статуси «прийнято», «відхилено» та «повернено» відповідають потрібним внутрішнім статусам.
- Перевірте повторні спроби. Зімітуйте тимчасову помилку на стороні отримувача й перевірте, чи відправник повторює запит. Узгодьте логіку повторних спроб, щоб затриманий колбек не створював дублікати результатів.
- Перегляньте логи. Перевірте вихідний URL, код відповіді, час запиту та зіставлений ID кліку або ліда. Зберігайте достатньо даних для діагностики, але не збирайте більше персональної інформації, ніж потрібно.
- Налаштуйте сповіщення про відсутність постбеків. Відстежуйте, чи надходять колбеки, як очікується. Раптова зупинка може вказувати на зламану інтеграцію, прострочені облікові дані або зміни на стороні баєра.
Де тут працює Hyperone
Hyperone об’єднує маршрутизацію та зворотний зв’язок щодо результатів в одному робочому циклі. Статуси від баєра та CRM можуть надходити через колбеки й API-підключення, а потім впливати на наступне рішення щодо маршрутизації. Так дані про прийняті, відхилені та конвертовані ліди допомагають визначати, як працювати з доступним трафіком.
Капи, доступність напрямків і правила резервної маршрутизації діють до передавання ліда. Якщо баєр вичерпав кап або недоступний, налаштовані правила можуть спрямувати лід до іншого доступного напрямку, а не відправляти його в нікуди. Intelligent Hubs маршрутизують кожен клік або лід за вашими правилами, а UAD Manager може спрямовувати трафік на офери з кращими результатами й перенаправляти його, якщо напрямок стає недоступним.
Тарифи Hyperone починаються від $499 на місяць. Перегляньте ціни, щоб дізнатися більше про доступні плани.
FAQ
Що таке S2S-постбек?
S2S-постбек — це повідомлення між серверами, яке передає іншій платформі інформацію про подію, наприклад конверсію або статус ліда. Зазвичай воно містить ідентифікатор, за яким система-отримувач може зіставити подію з початковим кліком або лідом.
Чи точніше відстеження через S2S, ніж через піксель?
Відстеження через S2S не залежить від завантаження пікселя в браузері, тож допомагає уникнути деяких проблем, пов’язаних із браузерами та файлами cookie. Водночас воно залежить від правильних ідентифікаторів, визначень подій і налаштування інтеграції: неправильно налаштований постбек може передати хибний результат або не зіставити подію.
Які параметри потрібні для постбеку?
Щонайменше додайте ID кліка або ліда та статус події. Залежно від потреб звітності й розрахунків додайте ID транзакції, виплату, часову позначку, причину відхилення або погоджені sub-ID.
Як перевірити URL постбеку?
Надішліть тестову подію, використовуючи відомий ID кліка або ліда, а потім перевірте відповідь і переконайтеся, що подія з’явилася в потрібному записі з очікуваним статусом. Перегляньте логи на наявність незамінених макросів, дублікатів подій, розбіжностей у часових позначках і невдалих повторних спроб.
Завантаження...
