Найбільше плутанини часто викликає цілком невинний Postback URL:
https://track.example.com/p?click_id={subid}&status={status}&payout={payout}Чому зліва написано click_id, а справа — {subid}? Де тут справжній click ID? І чому інший трекер для тієї самої задачі може використовувати cid={s2}?
Коротка відповідь: у параметра постбека є два власники. Трекер, який приймає запит, визначає ключ зліва від =. Партнерська мережа, яка надсилає запит, визначає макрос справа. У момент відправлення мережа замінює макрос реальним значенням. Назви не зобов’язані збігатися — збігатися має значення.
Нижче розберемо це мапування, різницю між click ID та sub ID і тести, які справді доводять, що постбек працює. Якщо спочатку потрібна загальна механіка server-to-server, прочитайте що таке S2S-трекінг постбеків.
Три різні речі, які називають «макросом»
Візьмемо таку пару:
click_id={subid}У ній є три окремі рівні:
| Рівень | Приклад | Хто контролює | Завдання |
|---|---|---|---|
| Ключ параметра приймача | click_id= | Трекер, що приймає запит | Показує, звідки приймачу читати значення |
| Макрос відправника | {subid} | Мережа, що надсилає запит | Показує, яке збережене значення підставити |
| Реальне значення | 8f2a91c0d3 | Створене раніше у флоу кліку | Ідентифікує конкретний клік |
Після підстановки макросів у запиті вже немає фігурних дужок:
https://track.example.com/p?click_id=8f2a91c0d3&status=deposit&payout=45.00Якщо в сирому запиті досі видно click_id={subid}, мережа не розпізнала або не розкрила макрос. Браузер може навіть отримати 200 OK, але атрибуція вже зламана.
Click ID і sub ID: пов’язані, але не однакові
Click ID — унікальний ідентифікатор одного відстеженого кліку. Це ключ зв’язку між вихідним переходом і пізнішою конверсією. Якщо клікнули 10 000 людей, трекер має створити 10 000 click ID.
Sub ID — універсальне поле для перенесення або зберігання значення. У ньому може лежати click ID трекера, але також плейсмент, код баєра, креативний підхід чи назва кампанії. sub1=facebook_feed корисний для сегментації, однак не є унікальним ідентифікатором кліку.
Саме тому мережа може попросити передати ваш click ID у своє поле subid, aff_sub, s2 або sub1. Вона не змінює сам ідентифікатор. Вона зберігає його у вільному слоті, щоб повернути те саме значення після конверсії.
Не плутайте їх із такими даними:
- Campaign, ad set чи ad ID: визначає групу кліків, а не один клік. Для цієї ієрархії використовуйте мапування URL-параметрів Facebook або мапування макросів TikTok.
fbclidабоttclid: ідентифікатор кліку рекламної платформи. Він допомагає атрибуції платформи, але трекеру все одно потрібен стабільний внутрішній click ID для пошуку конверсії.- Transaction ID: визначає одну конверсію. Один клік може дати реєстрацію, перший депозит і повторний депозит — з окремим transaction ID для кожної події.
Повний цикл від кліку до постбека
Уявімо, що DarkCore відправляє трафік у партнерську мережу, де доступне поле aff_sub.
1. Трекер створює click ID
Користувач відкриває Track Link. DarkCore записує контекст джерела й створює:
dc_01K2A7M9X42. Трекер передає його в оффер
URL оффера містить вихідний макрос DarkCore:
https://network.example/offer?aff_sub={click_id}Перед редіректом DarkCore підставляє реальне значення:
https://network.example/offer?aff_sub=dc_01K2A7M9X4Мережа отримує його у своєму ключі aff_sub і зберігає.
3. Мережа повертає значення
У налаштуваннях постбека мережі напрямок змінюється:
https://track.example.com/p?click_id={aff_sub}&status={status}&payout={payout}&transaction_id={conversion_id}Тепер click_id і transaction_id — ключі, які розуміє трекер-приймач. {aff_sub}, {status}, {payout} та {conversion_id} — макроси, які розуміє мережа-відправник.
4. Трекер атрибутує конверсію
Реальний callback може мати такий вигляд:
https://track.example.com/p?click_id=dc_01K2A7M9X4&status=ftd&payout=45.00&transaction_id=conv_7719Трекер знаходить початковий клік, мапить ftd у потрібний статус конверсії, додає payout і використовує conv_7719, щоб розпізнати буквальний повтор.
Це і є весь контракт постбека: передати вперед одне точне значення click ID, зберегти його без змін і повернути під ключем, який приймає трекер.
Чому синтаксис макросів у трекерах і мережах відрізняється
Універсального стандарту макросів немає. Кожен продукт має власний шаблонізатор і словник параметрів.
В офіційному гайді Keitaro для пошуку кліку використано subid і описано псевдоніми вхідних параметрів. Документація Voluum показує, як те саме значення змінює назви на маршруті: Voluum-макрос {clickid} можна зберегти в полі мережі s2, а потім повернути у Voluum як cid={s2}. Affise документує варіанти {clickid} і {click_id} залежно від інтеграції.
Практичне правило просте:
Зліва використовуйте параметр, який приймає ваша система. Справа — точний синтаксис макроса із документації системи-відправника.
Не копіюйте весь шаблон постбека з іншого трекера лише тому, що концепції схожі. {click_id}, {clickid}, {subid}, ${click_subid} і {s2} десь можуть позначати значення кліку, але це не взаємозамінний синтаксис шаблонів.
Які параметри постбека приймає DarkCore
DarkCore приймає поширені псевдоніми, тому партнеру не завжди потрібно перейменовувати власні поля:
| Значення | Допустимі вхідні ключі |
|---|---|
| Click ID | click_id, clickid, cid, subid, sub_id |
| Статус | status, goal, event |
| Payout | payout, sum, amount, revenue |
| Transaction ID | transaction_id, txid, tx_id, transactionid, conversion_id, conv_id |
| Час конверсії | event_at, event_time |
Це ключі вхідного запиту, а не обіцянка, що кожна мережа розуміє однойменні макроси. Якщо мережа документує {click_subid}, правильне мапування може виглядати так:
https://track.example.com/p?click_id={click_subid}&status={goal}&payout={commission}Справа використовуйте точні макроси мережі. Зліва — один із ключів, які приймає трекер.
Статус, payout і transaction ID мапляться окремо
Повернути click ID необхідно, але цього недостатньо для повного запису конверсії.
Статус
Мережі можуть надсилати lead, reg, registration, sale, deposit, dep або ftd. Замапте сирі значення мережі на статуси конверсій у вашому workspace. Навіть правильно знайдений клік із неправильним статусом може піти не за тим маршрутом або не потрапити в метрику оптимізації.
Payout
Передавайте числову комісію, а не форматований рядок на кшталт $45 USD. Окремо перевірте, що означає макрос мережі: валову виручку, вашу комісію чи суму замовлення. Число може успішно розпарситися, але все одно бути не тією бізнес-метрикою.
Transaction ID
Коли мережа має унікальний ID конверсії, завжди передавайте його. У DarkCore наявний transaction ID робить ідемпотентність окремою для цієї конверсії та статусу. Без нього безпечний fallback — click ID плюс канонічний статус. Різниця критична, коли один клік може породити кілька реальних транзакцій.
Pass/fail-перевірка всього ланцюга
Не завершуйте тест словами «URL відкрився» або «ендпоїнт повернув 200». Зафіксуйте доказ на кожному переході:
| Тест | Умова pass | Pass? |
|---|---|---|
| Початковий клік | Трекер записав новий клік і створив click ID | ☐ |
| Вихідний URL оффера | Мережа отримала точний click ID, у значенні не залишилось {click_id} | ☐ |
| Збереження в мережі | У її логу кліків/конверсій видно те саме значення в налаштованому sub-полі | ☐ |
| Сирий постбек | Повернене значення побайтно збігається та лежить у допустимому click-ключі | ☐ |
| Статус | Сирий статус замаплено в правильну канонічну конверсію | ☐ |
| Транзакція | Є унікальний ID конверсії, якщо мережа його надає | ☐ |
| Виручка | Payout є числом і відповідає погодженій бізнес-величині | ☐ |
| Повтор | Той самий transaction не дублює конверсію чи виручку | ☐ |
| Звітність | Конверсія з’явилась на початковому кліку, кампанії та стрімі | ☐ |
Скористайтеся Postback URL Builder і S2S-тестером, щоб зібрати callback і отримати безпечну тестову команду. Потім перевірте сирий ingress-лог і фінальний рядок конверсії. 200 OK показує лише відповідь ендпоїнта; він не доводить, що клік знайдено, статус правильний, а payout означає саме те, що ви очікували.
Повний приклад від outbound link до callback є в гайді про affiliate tracking link. Якщо click належить Keitaro, використовуйте окрему інструкцію з Keitaro postback для subid, status training, payout і tid.
Типові поломки
- У проді повернулися фігурні дужки. Відправник не розпізнав макрос. Перевірте його документацію і чи підтримує конкретне поле postback-макроси.
- Click ID змінив регістр, довжину або кодування. Сприймайте його як непрозорий рядок. Не парсьте, не обрізайте й не збирайте заново між системами.
- Замість
click_idповертається campaign ID. Тисячі кліків схлопуються в одне неунікальне значення, тому атрибуції довіряти не можна. - Передача вперед працює, повернення — ні. Макроси URL оффера належать трекеру, а макроси постбека — мережі. Напрямок змінився, отже змінився і шаблонізатор.
- Видно тільки реєстрацію. Для депозиту може бути окреме поле URL або сирий статус, який ніхто не замапив.
- Кожен retry додає виручку. Передайте стабільний transaction ID і двічі повторіть ідентичний callback.
- У sub ID записали чутливі дані. Не передавайте email, телефон, ім’я чи інший прямий ідентифікатор у query-параметрах. URL регулярно потрапляють у логи доступу та кабінети партнерів.
FAQ
subid — це те саме, що click_id?
Не за визначенням. click_id описує роль значення — унікально визначити один клік. subid описує гнучке поле зберігання. Sub ID стає носієм click ID лише тоді, коли ви навмисно записали туди click ID.
Назви з обох боків = мають збігатися?
Ні. click_id={subid} є коректним, якщо приймач очікує click_id, а відправник зберігає ваше значення кліку під subid. Важливо, щоб збіглось підставлене значення.
Чи можна використовувати один Postback URL для всіх статусів?
Так, якщо мережа підставляє макрос статусу, а трекер мапить усі потрібні вам значення. Якщо мережа дає окремі callback-поля для різних цілей, налаштуйте кожне явно.
Чому постбек повернув 200, але конверсія не з’явилась?
Багато ендпоїнтів навмисно відповідають загальним success навіть на некоректний, невідомий або дубльований callback — щоб не створювати retry storm і не розкривати внутрішній стан. Перевірте ingress result, пошук кліку, мапування статусу та фінальний запис конверсії.
Ментальна модель, яка не застаріває
Не запам’ятовуйте всі варіанти написання макросів. Натомість простежте власників:
- Хто створює значення click ID?
- Під яким ключем наступна система його приймає та зберігає?
- Яким макросом ця система повертає збережене значення?
- Який вхідний ключ приймає трекер?
- Який transaction ID не дає повтору перетворитися на зайву виручку?
Коли ці п’ять відповідей записані, різний синтаксис трекерів перестає бути загадкою. Це лише адаптери навколо одного інваріанта: той самий ідентифікатор кліку має пройти весь цикл без змін.