Події та конверсії: грошовий шар воронки

Клік - це витрата, доки подія не підтвердить, що він окупився. У Leadgram кожна конверсія - старт бота, реєстрація, депозит - це подія, прив'язана до одного конкретного кліку. І саме цей зв'язок живить усе інше: дохід у Звітах, постбеки в партнерські трекери, серверні конверсії, які ви віддаєте назад у Meta й Google, і пуш підписнику, який конвертнувся, якщо у флоу для цього є вузол. Налаштуйте події правильно - і решта трекера почне казати вам правду про ваш спенд.

Типи подій

• Події воронки - click, land, bot_start, channel_join, join_request, first_dm, miniapp_launch. Показують, як користувач рухається вашою Telegram-воронкою.
• Конверсійні події - lead, registration, deposit, ftd, purchase. Це події, за які платить рекламодавець.
• Кастомні події - custom_1…custom_8 під усе, що специфічне для офера.

Більшість конверсійних подій також просувають статус кліку на сторінці Кліки: Клік → Лендінг → Старт → Реєстрація → Лід → Депозит → FTD. Статус рухається лише вперед - пізня registration, що приходить після ftd, клік не відкотить. Виняток - purchase: вона тарифікується і потрапляє у звіти як будь-яка інша конверсія, але статусу кліку не торкається. Так само як channel_join і події custom_* - усі три записуються, просто не просувають кліки сходами воронки.

Як події потрапляють у систему

1. S2S / API. Ваш бекенд (або постбек-скрипт рекламодавця) викликає POST /api/events із clickId, типом події (type) і опційно payout та nonce. Для зовнішніх інструментів на кшталт Keitaro чи власних скриптів створіть API-ключ у Налаштуваннях → API ключі. Щоб звірити, що реально спрацювало, з власними записами, витягуйте події назад через GET /api/events (з пагінацією, з фільтром за type).
2. Флоу. Додайте вузол «Тригер події» у Флоу - і подія спрацює автоматично, щойно підписник дійде до цього кроку: реєстрації й депозити прямо з Telegram-воронки, без коду.

Дедуплікація детермінована: повторне надсилання того самого clickId + type без nonce вважається ретраєм тієї самої конверсії - другого рядка, другого списання чи дубля Purchase у Meta не буде. Справжня повторна конверсія (другий депозит із того самого кліку) мусить іти з унікальним nonce.

Білінговий шлюз

Записати подію і доставити її далі - не одне й те саме. Кожен рядок події несе billing_status: спочатку pending, поки йде списання, потім він осідає в charged або free. Відправка в CAPI, постбеки і пуш підписнику, що конвертнувся, спрацьовують лише після того, як статус визначиться як charged або free - призупинена організація або порожній баланс лишають рядок у стані blocked (невдале списання - error), і подія просто лежить у базі, так і не діставшись Meta, Google, вашого постбек-ендпоінта чи підписника.

Поле payout

Передавайте payout (USD, до двох знаків після коми) з кожною платною конверсією. Він живить два місця:

• Дохід у Звітах - колонка доходу підсумовує payout по підтверджених подіях.
• Google Ads - payout стає conversionValue на серверній конверсії, тож Smart Bidding оптимізується на реальні гроші.

Постбеки payout не передають. Макроси, доступні партнерському трекеру: {click_id}, {event_type}, суб-ланцюжок і нативні click id майданчиків - повний список у Постбеках. Якщо трекеру потрібна сума конверсії, передайте її через власну інтеграцію.

Що означає колонка CAPI

У таблиці «Останні події» на Дашборді кожна подія має статус CAPI: Надіслано - усі прив'язані до кампанії рекламні майданчики прийняли конверсію; Очікує - щонайменше одна доставка ще в черзі або падає. Деталі по платформах - спроби, остання помилка, повторне відправлення в один клік - на сторінці Доставка конверсій.

Безпечна тест-подія

На сторінці Facebook у кожного CAPI-акаунта Meta є кнопка «Надіслати тест-подію». Вона відправляє синтетичний Purchase із вашим Test Events кодом з Meta Events Manager, тож подія з'являється у вкладці Test Events і ніколи не впливає на оптимізацію реклами, атрибуцію чи білінг. Це найшвидший спосіб переконатися, що піксель і токен працюють, ще до першого витраченого долара. Без коду кнопка не спрацює - подію без коду Meta зарахувала б як справжню.

Типові граблі

• Пропуск nonce на повторній конверсії - другий депозит мовчки зарахується як ретрай і не запишеться.
• Відправлення подій без payout - дохід у Звітах лишається нульовим, а Google отримує конверсії без цінності.
• Надсилання registration на клік, що вже дійшов до ftd, в очікуванні, що статус зміниться - не зміниться, так задумано.
• Очікування, що purchase посуне статус воронки кліку - ніколи не посуне, хоча тарифікується як будь-яка інша конверсія.
• Сприйняття «Очікує» в колонці CAPI як бага - спершу зазирніть у Доставку конверсій, там зазвичай видно конкретну помилку платформи.
• Припущення, що записана подія вже доставлена - статуси білінгу blocked, error і pending означають, що вона так і не дійшла до CAPI, постбеків чи пушів.