Медіабаєр заливає нутра-оффер через мережу, яка платить за FTD. Дашборд його трекера показує 340 кліків і 4 конверсії за день — CR, при якому будь-яку кампанію одразу поставили б на паузу. Але власна статистика мережі по тому самому трафіку за той самий період показує 19 конверсій. Ніхто нічого не краде і не бреше: мережа відправляє подію підтвердження зі свого бекенду, через кілька днів після кліку, на домені, до якого браузер баєра більше не звертається. Якщо трекер так і не дізнався про ці 15 конверсій — їх для нього не існує, хоч скільки б реального доходу за ними стояло. Server-to-server (S2S) постбек-трекінг існує саме для того, щоб закрити цей розрив, і зробити це неправильно — один з найпоширеніших способів, як медіабаєри непомітно занижують власні показники.
Що таке S2S-постбек насправді
S2S-постбек (іноді його називають server callback або IPN — instant payment notification, термін, запозичений з платіжних систем) — це HTTP-запит, який сервер афілійованої мережі чи рекламодавця надсилає напряму на сервер вашого трекера в момент, коли відбувається конверсія. Жодного браузера, JavaScript, кукі чи залежності від того, чи пристрій користувача онлайн, розблокований чи взагалі досі належить тій самій людині, яка клікнула по рекламі.
Флоу крок за кроком:
- Користувач клікає по вашій рекламі і потрапляє на оффер через ваше трекінгове посилання.
- Ваш трекер генерує унікальний
click_id, логує клік (джерело, кампанію, оголошення, sub ID, гео, таймстемп) і передає цейclick_idдалі до оффера як URL-параметр. - Лендінг оффера, форма реєстрації чи флоу депозиту проносить цей
click_idчерез власну воронку — зазвичай як приховане поле або sub-ID, який мережа вже підтримує. - Коли користувач конвертиться — реєструється, депонить, проходить KYC, що б там оффер не вважав платною подією, — сервер мережі викликає ваш postback URL із тим самим
click_idі статусом. - Ваш трекер зіставляє
click_idз початковим кліком і записує конверсію на своєму боці, незалежно від того, що після цього відбувалося в браузері користувача.
Оскільки весь обмін відбувається server-to-server, йому байдуже до iOS ITP, блокувальників реклами, обмежень на сторонні кукі, закритої вкладки чи повільної сторінки, яка так і не встигла виконати скрипт. Йому так само байдуже, що конверсія відбулася через три дні, на домені, який ви не контролюєте, з пристрою, відмінного від того, з якого клікнули по рекламі. У цьому й суть — це єдиний шар трекінгу, побудований так, щоб пережити реальну форму афілійованої воронки.
Піксель проти постбека: що насправді бачить кожен шар
Пікселі не марні — вони дешеві, швидкі і цілком підходять для ранніх сигналів воронки на кшталт перегляду лендінгу. Але коли піксель стає джерелом правди для подій доходу, баєри в результаті оптимізуються під цифри, які ніколи не були повними.
| Піксель-трекінг | S2S-постбек | |
|---|---|---|
| Залежить від браузера/кукі | Так | Ні |
| Переживає блокувальники реклами | Ні | Так |
| Працює, якщо користувач закрив вкладку | Ні | Так |
| Працює через редірект на власний домен рекламодавця | Ні | Так |
| Точність для відкладених конверсій (депозити через кілька днів) | Погана | Надійна |
| Спрацьовує на | Завантаження сторінки / клієнтську подію | Підтверджену server-side зміну статусу |
| Володіння даними | Розподілено між клієнтськими скриптами | Повністю на боці сервера |
Якщо ви також ведете Facebook CAPI паралельно з постбеком, варто розуміти, де закінчується зона відповідальності кожного шару — дивіться Піксель проти Conversions API проти S2S-постбека, як насправді ці три шари ділять роботу, а не конкурують.
Анатомія postback URL
Postback URL — це ендпоінт на вашому трекері, заповнений макросами, які система мережі динамічно підставляє в момент відправки колбека. Типова структура:
https://track.yourdomain.com/postback?click_id={click_id}&status={status}&payout={payout}¤cy={currency}Довідник макросів
Назви макросів відрізняються між мережами, але майже всі вони відображають одні й ті самі концепції:
| Макрос (типова форма) | Що передає | Альтернативні назви |
|---|---|---|
{click_id} | Унікальний ID, що зв’язує конверсію з початковим кліком | {clickid}, {subid}, {aff_click_id} |
{status} | Тип події конверсії | {event}, {action}, {goal} |
{payout} | Значення доходу/комісії | {amount}, {revenue}, {sum} |
{currency} | Валюта виплати | {cur} |
{sub1}–{sub5} | Ваші кастомні sub-ID параметри для сегментації | {s1}–{s5}, {subid1}–{subid5} |
{transaction_id} | Власний внутрішній ID мережі для конверсії (корисно для дедупу/спорів) | {trans_id}, {conversion_id} |
Не вважайте назву макроса універсальною, поки не перевірили документацію мережі по постбекам. Пропущений чи неправильно написаний макрос непомітний рівно до того моменту, поки перша реальна конверсія тихо не провалить зіставлення.
Розібраний приклад
Ось як виглядає реальний postback-запит, коли мережа фактично його відправляє, з макросами, заповненими для події депозиту на гемблінг-оффері:
https://track.yourdomain.com/postback?click_id=8f2a91c0d3&status=deposit&payout=45.00¤cy=USD&sub1=fb_lookalike_3Ваш трекер отримує це, шукає click_id=8f2a91c0d3 у своєму лозі кліків, знаходить початковий клік (кампанію, оголошення, гео, sub1) і записує конверсію deposit вартістю $45.00, прив’язану до повного контексту цього кліку — жодної ручної звірки, жодних таблиць, жодного очікування, поки дашборд мережі почне відображати реальність.
Особливості різних мереж, які варто знати
Налаштування постбека виглядає однаково в теорії й поводиться по-різному на практиці залежно від мережі:
- Неоднорідність назв макросів.
{clickid}в однієї мережі — це{subid}в іншої і{aff_sub}у третьої. Вставляйте у свій postback URL саме той синтаксис макросів, який використовує мережа — не покладайтеся на те, що він збігається з останньою мережею, яку ви налаштовували. - Один постбек проти постбека на кожен статус. Деякі мережі відправляють окреме URL-поле для кожного статусу (окремі поля для “lead” і “sale”); інші відправляють один URL і очікують, що ви читатимете макрос
{status}. Налаштування під неправильну модель означає, що кожна подія після першої тихо губиться. - Затримані і повторювані постбеки. Одні мережі ставлять в чергу і повторюють невдалі доставки протягом годин чи днів; інші відправляють один раз і більше не повторюють. Знайте, з якою поведінкою маєте справу — від цього залежить, чи коштує вам простій кілька конверсій, чи всі одразу.
- IP allowlisting і HTTPS. Частина мереж вимагає додати їхні вихідні IP в allowlist або взагалі відхиляє postback-ендпоінти на звичайному HTTP. Перевіряйте обидва напрямки, перш ніж вважати налаштування зламаним.
Налаштування і маршрутизація постбеків за статусом
- Згенеруйте postback URL у своєму трекері, включно з кожним макросом, який мережа дійсно підтримує — беручи це з їхньої документації, а не вгадуючи за шаблоном.
- Вставте його в поле постбека мережі. Якщо вони підтримують URL по кожному статусу окремо — мапте кожен потрібний вам статус (реєстрація, депозит, продаж) індивідуально, а не тільки перший, який ви налаштували.
- Запустіть тестову конверсію, якщо пісочниця мережі це дозволяє, або перевірте їхній лог доставки постбеків після реальної, щоб підтвердити, що запит справді пішов з їхнього сервера.
- Перевірте збіг на боці свого трекера — підтвердіть, що
click_id, який прийшов, відповідає кліку, який ви дійсно залогували, а не є сирітським чи некоректним запитом. - Замапте кожен потрібний статус, а не тільки перший, який спрацьовує. Налаштування, яке ловить лише “реєстрацію” й губить “депозит” через три дні, виглядає нормально рівно до того моменту, поки ваші цифри доходу не перестануть рухатись.
Більшість трекерів трактують кожен постбек як одну плоску подію і очікують, що ви самі приберете обробку статусів. DarkCore з самого початку трактує статус конверсії як повноцінну концепцію: маршрутизація постбеків налаштовується прямо на кожному стрімі, по статусах — реєстрація, депозит чи будь-який кастомний статус, який потрібен вашій вертикалі.
Статуси конверсій існують як реєстр на рівні воркспейсу, а не як захардкожені категорії. Додайте новий — верифіковану KYC-віху, поріг другого депозиту, що завгодно, що реально відстежує ваша воронка — і він миттєво стає доступним всюди: маршрутизація постбеків, спрацювання пікселя, аналітичні метрики і фільтри push-аудиторій, без жодної інженерної роботи. Ви не подаєте тікет, щоб новий статус розпізнавався, — ви просто додаєте рядок.
Саме тут тихо ламаються інструменти, побудовані навколо однієї загальної події “конверсія”: постбеки реєстрації нормально приходять в перший же день, а постбеки депозиту чи продажу — ті, що фактично несуть дохід — приходять через кілька днів і губляться, неправильно маршрутизуються або зливаються з усім іншим, бо система ніколи не була побудована розрізняти статуси. Якщо ви також ведете Facebook CAPI поверх даних постбека, той самий реєстр керує мапінгом подій і там — дивіться як трекати конверсії Facebook-реклами для афілійованих офферів, як ці два механізми з’єднуються наскрізно.
Дебаг зламаного ланцюжка постбеків
Коли конверсії не з’являються, проходьте ланцюжок по порядку, а не вгадуйте:
- Підтвердіть, що клік взагалі залогувався. Відкрийте лог кліків трекера і знайдіть клік, що відповідає очікуваному часу і джерелу. Якщо кліку немає — нижче по ланцюжку нічому зіставляти.
- Підтвердіть, що
click_idпережив редірект на оффер. Багато “зламаних” налаштувань постбека насправді — зламаний passthrough: лендінг мережі чи форма реєстрації втратили параметр ще до того, як спрацювала їхня подія конверсії. - Перевірте лог доставки постбеків мережі, якщо вони його показують. Це підкаже, чи запит взагалі пішов з їхнього сервера і що він насправді містив — часто відрізняється від того, що описано в документації.
- Перевірте вхідний лог запитів трекера на предмет сирого хіта постбека. Якщо він прийшов, але не зіставився з кліком, значення
click_id, ймовірно, некоректне, обрізане або використовує неправильну назву макроса. - Підтвердіть, що статус змапився на щось, що розпізнає ваш стрім. Постбек зі
status=ftd, коли ваш стрім мапить тількиdeposit, потрапляє як нерозпізнана подія — перевірте розбіжності в назвах між тим, що відправляє мережа, і тим, що очікує ваш реєстр статусів. - Звірте з власним дашбордом мережі за короткий недавній період, коли відкладені події вже встигли з’явитись. Невеликий постійний розрив може бути нормою; великий чи зростаючий означає, що якийсь крок вище все ще зламаний.
Типові помилки
- Мапити лише перший статус, що спрацьовує. Реєстрація працює, депозит — ні, бо ніхто не налаштував маршрутизацію для нічого після першої події у воронці.
- Довіряти документації макросів мережі без перевірки. Документація застаріває. Макрос, що колись був
{subid}, після міграції платформи стає{sub_id}, і ніхто не оновлює сторінку. - Не перевіряти passthrough
click_id. Якщо лендінг мережі чи форма реєстрації ненадійно проносять ваш ідентифікатор кліку у свою систему, постбеку, що зрештою спрацює, немає з чим зіставлятися — “успішна” доставка, яка породжує неатрибутовану конверсію. - Припускати, що збій доставки буде видно одразу. Деякі мережі мовчки повторюють спроби днями; інші відкидають невдалу доставку без жодного алерту. Якщо у вашого ендпоінта був простій, перевіряйте лог доставки мережі, а не вважайте, що все дійшло.
- Вважати одну плоску подію “конверсія” достатньою. Реєстрації, депозити і ребіли — різні сигнали з різною цінністю. Звести їх до одного статусу робить подальшу автоматизацію — авто-правила, що діють на реальні депозити, аналітику, push-сегментацію — сліпою до різниці між лідом за $0 і FTD за $200.
FAQ
Чи складно налаштувати S2S-постбек-трекінг порівняно з пікселем?
Початкове налаштування вимагає трохи більше координації — потрібна співпраця мережі, щоб пронести ваш click_id через їхню воронку і викликати колбек — але сама конфігурація це один URL з макросами, не складніше, ніж вставити код пікселя. Виграш — у довговічності: раз правильно підключений, він продовжує працювати незалежно від змін у браузерах, блокувальників реклами чи того, скільки днів минуло між кліком і конверсією.
Чи можна використовувати піксель і S2S-постбек одночасно?
Так, і для більшості афілійованих воронок так і варто робити — піксель для дешевих ранніх сигналів воронки на кшталт переглядів сторінки, а постбек — для подій нижче по воронці, які фактично несуть дохід. Вони не конкурують за одну й ту саму роботу; постбек існує саме для того, щоб ловити те, що піксель структурно не здатен.
Що робити, якщо афілійована мережа взагалі не підтримує postback URL?
Ви обмежені тим трекінгом, який вони надають, — зазвичай ручний експорт чи власний дашборд, обидва з відставанням від реального часу і вимагають ручної звірки. Якщо мережа не може відправити server-side колбек на конверсію, отримати з неї атрибутовані дані про дохід в реальному часі неможливо; це реальне обмеження при виборі оффера, яке варто зважити проти виплати.
Чому мій трекер показує менше конверсій, ніж власний дашборд мережі?
Майже завжди одна з причин: click_id не переживає редірект у воронку мережі, у postback URL відсутнє мапування статусу для подій після першої, або мережа мовчки повторює невдалу доставку замість того, щоб вас сповістити. Пройдіться по ланцюжку від логу кліків назовні, а не вважайте розрив невиправним.
Як зробити все правильно з першого разу
У цьому немає нічого екзотичного — це URL, кілька макросів і статус, який ваш трекер справді вміє маршрутизувати. Заплутує людей те, що вони трактують постбек як одноразове налаштування, а не як ланцюжок з кількома місцями, де він може тихо зламатись: втрачений click_id, немаплений статус, політика повторів, яку ніхто не перевірив. DarkCore бере на себе те, що зазвичай прикручують як щось другорядне: маршрутизація по статусах, налаштована прямо на стрімі, реєстр статусів, який розширюється на пікселі й аналітику без додаткового налаштування, і трекер, побудований на припущенні, що конверсія, яка вас цікавить, часто відбувається значно пізніше кліку. Якщо ваші поточні цифри не збігаються з тим, за що насправді платить мережа, варто простежити ланцюжок, перш ніж простежувати бюджет — напишіть нам у Telegram.