Власний трекер: постбеки й підпис HMAC

Постбек — запит партнерки в AdFleet про конверсію. Швидкий шлях: «Трекер» → «Постбеки» → «Підключити партнерку» (Owner, Head, Team lead; до 30 токенів) → обери платформу (Scaleo, Affise, Everflow, 1xBet Partners, Melbet або «Інша партнерка») → «Підключити». На наступному екрані — що додати в посилання офера (для Scaleo &aff_click_id={click_id}), готові рядки постбека з токеном і статус «чекаємо на перший постбек», який оновлюється сам. Для 1xBet Partners і Melbet впиши свою ставку CPA — ці кабінети виплату не передають.

Вручну: «Випустити токен вручну» — «Назва», «Партнерка», «Дозволені IP партнерки» (по одній IP або підмережі на рядок, порожньо — з будь-якої адреси), «Синоніми подій» (first-deposit=ftd), «Статуси партнерки» (1=approved), «Секрет підпису HMAC» (необов'язково).

Адреса показується один раз — скопіюй одразу:

https://<твій домен>/pb/<ТОКЕН>

Параметри

GET або POST (форма чи JSON), імена без урахування регістру; при збігу імені значення з тіла головніше. Імена Keitaro, Binom і Voluum теж приймаються.

• click_id (або clickid, subid, sub_id, cid, cnv_id) — обов'язково: наш {click_id} із посилання.
• event (et) — обов'язково: lead, reg, ftd (перший депозит), dep (депозит), sale або своя (латиниця, цифри, _, до 32). registration → reg, first_deposit → ftd, deposit / redeposit → dep.
• payout (revenue) — виплата партнерки, кома допустима; від'ємна — коригування або чарджбек; немає — 0.
• amount (sumdep) — сума депозиту або замовлення, окремо від виплати, у тій самій валюті.
• currency (cur, cnv_currency) — три літери; немає — валюта трекера.
• tx (txid, tid, transaction_id) — ID конверсії в партнерки: відрізняє повторні депозити одного кліку.
• status (cnv_status) — approved / hold / rejected і звичайні синоніми (pending, confirmed, declined…); trash і fraud — відмова з причиною; chargeback / refund — чарджбек; немає — approved. Числові статуси (1, 2, 3…) — лише через «Статуси партнерки» токена (у шаблоні Affise вже задано).
• ts (timestamp) — час події в партнерки, unix або ISO-8601; гроші ляжуть у цей день.

Незаповнений макрос ({payout}, [STATUS], %sum%…) вважається відсутнім.

Приклад для партнерки:

https://<домен>/pb/<ТОКЕН>?click_id={subid}&event={goal}&payout={payout}&amount={amount}&currency={currency}&status={status}&tx={transaction_id}

Як зараховується

• Дубль — той самий клік, подія й tx з тим самим статусом і виплатою. Той самий статус з іншою виплатою чи сумою — оновлення. Переходи: hold → approved, hold → rejected, approved → rejected (чарджбек), rejected → approved (повторне схвалення, зокрема після «сміття» і «фроду»). На холд конверсія не повертається.
• Перемагає останній постбек, що надійшов, як у Keitaro: approved → rejected → approved — конверсію знову схвалено, плюс у день надходження. Постбек, що збігається з поточним станом конверсії, нічого не змінює. Якщо партнерка надсилає ts, порядок — за ним: постбек, старший за вже застосований, конверсію не змінює.
• Чарджбек — мінус у день скасування: день схвалення не переписується, підсумки за кліком і офером сходяться. Повторне схвалення — плюс у свій день.
• Перший депозит кліку позначається як FTD (і ftd, і перший dep); ftd і dep з одним tx — один депозит. Повторний депозит без tx не відрізнити від повтору — журнал попросить додати макрос id транзакції.
• Клік, старший за вікно атрибуції (за замовчуванням 30 днів, «Налаштування трекера»), не зараховується.
• Виплата перераховується у валюту трекера за курсом дня події (UTC); курсу ще немає — сума заповниться пізніше.
• Клік не знайдено — повтор через 1, 5 і 30 хвилин, далі «клік не знайдено».

Відповідь

Завжди 200 «OK» — є такий клік чи ні. Понад 600 запитів на хвилину на токен — 429, збій запису — 503: партнерка повторить, нічого не загубиться. «Журнал постбеків» — останні 100 запитів із результатом і причиною.

Підпис HMAC

Якщо задано секрет: hex HMAC-SHA256 цим секретом — у заголовку X-Signature (префікс sha256= допустимий) або в параметрі sig / signature. Невірний підпис чи IP не зі списку — запит записується як відхилений.

Рядок, що підписується, однаковий для GET і POST:

1. Усі параметри запиту й тіла (для одного імені — значення з тіла), імена — як надіслані, крім самого підпису (sig / signature); вкладені JSON-значення пропускаються.
2. Сортування за іменем за зростанням.
3. Ім'я й значення кодуються за RFC 3986 в UTF-8: без змін лише A–Z a–z 0–9 - . _ ~, пробіл → %20.
4. Вигляд name=value, через &. Числа JSON — як текст, true / false — малими, null — порожньо.

Приклад: b=x y і a=1+1 → підписується a=1%2B1&b=x%20y.