Свой трекер: постбэки и подпись 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.