Минулого місяця в одного медіабаєра, з яким ми працюємо, було джерело на Facebook, що давало реєстрації по $1.20 за штуку — справді сильний показник для гемблінг-вертикалі, суттєво нижче за звичні $3–4. За будь-яким дашбордом, який він тримав відкритим того дня, це джерело було найкращим в акаунті. А потім, через три дні, прийшов звіт по FTD: 1000 реєстрацій, 20 перших депозитів. Конверсія реєстрація → депозит 2%, тоді як середня по портфелю була ближче до 8%. За виплати $35 за FTD це джерело принесло $700 доходу на $1200 витрат — збиток, який він масштабував би ще сильніше, якби продовжував дивитися на вартість реєстрації замість того, щоб дочекатися цифри, яка справді показує гроші. Це фундаментальна помилка оптимізації тільки по реєстраціях у гемблінг-медіабаїнгу, і саме тому FTD-трекінг — вимірювання та оптимізація конкретно по події першого депозиту, а не по кроку реєстрації, що йому передує, — це єдиний погляд на кампанію, який показує, чи заробляє вона гроші.
Що таке FTD-трекінг насправді
FTD (first-time deposit) — це перший депозит, момент, коли зареєстрований користувач вперше поповнює свій рахунок. У гемблінгу та iGaming це та подія, яка перетворює реєстрацію на платного клієнта, і практично в будь-якій моделі виплат (CPA, RevShare чи гібрид) саме вона запускає або розблоковує дохід. FTD-трекінг — це практика фіксації цієї конкретної події на сервері, прив’язки її до початкового кліка й джерела та звітування по ній як по окремій метриці — окремо від реєстрацій, окремо від кліків, окремо від будь-якого загального “конверсійного” кошика, куди звалюють усе підряд.
Ця різниця важлива, бо реєстрація не коштує рекламодавцю нічого, окрім заповнення форми. Перший депозит означає, що реально перейшли гроші. Будь-який звіт по воронці, дашборд чи правило оптимізації, яке ставить знак рівності між цими двома подіями, вимірює не те, що треба, а у вертикалі, де конверсія в депозит може коливатись від 2% до 15% між джерелами з однаковою вартістю реєстрації, це не похибка округлення — це різниця між прибутковим акаунтом і акаунтом, який зливає бюджет.
Чому реєстрації брешуть: повна воронка
Воронка в гемблінгу має щонайменше чотири окремі етапи, і кожен з них відсіює інший тип користувачів:
- Клік — людина тапає по рекламі й потрапляє на оффер.
- Реєстрація — заповнює форму реєстрації. Цей крок легко підробити, легко зафармити, і на нього сильно впливає фрикшн лендінгу, який не має нічого спільного з реальним наміром купити.
- FTD (перший депозит) — поповнює рахунок. Це перша точка, де користувач реально вкладає гроші.
- Ребіл / повторний депозит — депозитить ще раз. Саме тут вирішується lifetime value і реальний період окупності.
Реєстрації — найлегший етап для оптимізації і найменш пов’язаний з доходом. Джерело може давати дешеві реєстрації у великій кількості від бонусхантерів, мотивованого трафіку чи просто клікерів з низьким наміром, які заповнять будь-яку форму перед носом, і все це не проявиться до етапу FTD — а в гемблінгу FTD може відставати від реєстрації на години чи дні залежно від фрикшну платіжного методу, перевірок KYC і того, наскільки агресивно онбординг оператора підштовхує до першого депозиту.
Ось приклад воронки для одного джерела, з витратами:
| Етап | Кількість | Конверсія з попереднього етапу | Вартість / значення |
|---|---|---|---|
| Кліки | 15,000 | — | $1,500 витрат ($0.10 CPC) |
| Реєстрації | 900 | 6.0% клік → реєстрація | $1.67 вартість реєстрації |
| FTD (перший депозит) | 45 | 5.0% реєстрація → FTD | $33.33 вартість FTD |
| Ребіл / 2-й депозит | 18 | 40% FTD → ребіл | формує 30-денний LTV |
Якщо дивитись тільки на рядок реєстрацій, джерело виглядає нормально — $1.67 за реєстрацію це прийнятний таргет для більшості гемблінг-вертикалей. Але подивіться на рядок FTD, і картина міняється: $33.33 за залученого депозитора, зіставлені з реальною виплатою за FTD, — саме та цифра, яка вирішує, отримає це джерело додатковий бюджет чи буде вбите.
Практичний приклад: однакова вартість реєстрації, протилежні результати
Сценарій, на якому спотикається майже кожен баєр, що оптимізує тільки по реєстраціях, — це два джерела з майже однаковою економікою реєстрацій, але кардинально різною економікою FTD. Ось порівняння:
| Метрика | Джерело A (оптимізоване по реєстраціях) | Джерело B (оптимізоване по FTD) |
|---|---|---|
| Витрати | $1,200 | $1,200 |
| Реєстрації | 1,000 | 480 |
| Вартість реєстрації | $1.20 | $2.50 |
| FTD rate (реєстрація → FTD) | 2% | 11% |
| FTD | 20 | 53 |
| Вартість FTD | $60.00 | $22.64 |
| Виплата за FTD (приклад CPA) | $35 | $35 |
| Дохід | $700 | $1,855 |
| Чистий результат | -$500 | +$655 |
Джерело A виглядає переможцем за будь-якою метрикою, яку показує дашборд, орієнтований тільки на реєстрації: більше реєстрацій, дешевша вартість реєстрації, кращий CTR. При цьому воно зливає гроші. Джерело B на його фоні виглядає дорогим і малооб’ємним, і саме воно єдине варте масштабування. Це той патерн, який тихо зливає гемблінг-рекламні акаунти — баєри вливають бюджет у джерело з найкращими цифрами на вершині воронки, бо це єдині дані, які вони бачать у реальному часі, тоді як дані по FTD, які показали б реальну картину, приходять із затримкою, в окремому звіті, який ніхто не звіряє з витратами щодня.
Як насправді трекається FTD: S2S-постбек з маршрутизацією по статусу
Реєстрації та депозити зазвичай приходять з платформи оператора як дві окремі події, часто з різницею від кількох хвилин до кількох днів, і саме тому S2S (server-to-server) постбек-трекінг з маршрутизацією по статусу — єдиний надійний спосіб зафіксувати FTD. Замість одного плоского постбеку “конверсія” оператор відправляє окремий callback для кожної події воронки — реєстрація, депозит і будь-який кастомний статус, який ви визначите, — і кожен несе той самий click_id, щоб ваш трекер міг зшити весь шлях назад до початкової реклами, джерела й кампанії.
У стрімах DarkCore маршрутизація постбеків налаштовується прямо в стрімі й ключується по статусу конверсії, а не по одному загальному типу події:
# registration event — informational only, not the revenue trigger
https://track.yourdomain.com/pb?click_id={click_id}&status=registration&payout=0¤cy={currency}
# first-time deposit (FTD) event — this is the one that pays
https://track.yourdomain.com/pb?click_id={click_id}&status=deposit&payout={payout}¤cy={currency}&sub1={sub1}
# rebill / redeposit — custom status, same click_id, drives LTV reporting
https://track.yourdomain.com/pb?click_id={click_id}&status=rebill&payout={payout}¤cy={currency}Оскільки статуси конверсій зберігаються в реєстрі на рівні воркспейсу, а не захардкожені, додавання нового — rebill, redeposit чи будь-якого специфічного для воронки оператора — робить його доступним одразу всюди: в маршрутизації постбеків, у спрацюванні пікселя й в аналітичних звітах, без додаткової інтеграційної роботи для кожного стріму. У гемблінгу це особливо важливо, бо оператори по-різному називають свої події й розкривають різну кількість етапів, а трекер, що вміє лише “лід” і “продаж”, змушує вас звалювати різні кроки воронки в один кошик — а це та сама сліпота “тільки по реєстраціях”, просто в іншій формі.
RevShare проти CPA проти гібриду: чому модель виплат змінює те, що ви оптимізуєте
Структура виплат вашого оффера визначає, скільки саме коштує один FTD, і помилка тут лише посилює проблему оптимізації тільки по реєстраціях:
- CPA (cost per acquisition): вам платять фіксовану суму за кожен FTD, іноді з мінімальним порогом депозиту. Тут FTD rate напряму множиться на відому виплату — математика з таблиць вище працює без ускладнень. Ризик у тому, що фіксований CPA винагороджує обсяг, а не якість депозиту: джерело, яке приносить депозиторів на мінімальному порозі, що ніколи не повертаються, виглядає ідентично джерелу з реальними гравцями — доки ви не перевірите ребіл-рейт.
- RevShare (ревшара): вам платять відсоток від чистого ігрового доходу, який депозитор генерує з часом, а не фіксовану суму за FTD. Один FTD може коштувати $8 або $200 залежно від того, як гравець поводиться в наступні тижні. Оптимізація тільки по кількості FTD при RevShare все одно краща за оптимізацію по реєстраціях, але без даних по ребілу й ретеншену картина неповна — джерело з нижчим FTD rate, але дорожчими депозиторами, може обійти джерело з більшою кількістю дешевших FTD.
- Гібрид: менший фіксований CPA плюс зменшена частка RevShare. У гемблінгу це поширено саме тому, що знижує ризики для обох сторін — партнер отримує гарантовану віддачу за FTD, а оператор обмежує свої втрати на малоцінних гравцях.
Незалежно від моделі, виплата стає реальними грошима лише тоді, коли вона звірена з тим, що ви реально витратили, джерело за джерелом, за фактичний період розрахунку — і це велика частина причини, чому фінансовий облік з подвійним записом, що відстежує реальний P&L, важливіший саме в гемблінгу, ніж у вертикалях, де власні цифри платформи достатньо близькі до правди, щоб їм довіряти.
Як рахувати реальний EPC та ROI по події FTD
EPC (дохід на клік), розрахований по реєстраціях, показує, наскільки ефективно ви генеруєте реєстрації. EPC, розрахований по FTD, показує, наскільки ефективно ви генеруєте гроші. Одне не є проксі для іншого, і в гемблінгу розрив між ними буває достатньо великим, щоб перевернути статус джерела з “масштабувати” на “вбити”.
EPC (on FTD) = Total FTD Revenue / Total Clicks
Example (Source B from above, CPA model):
53 FTDs x $35 payout = $1,855 revenue
$1,855 / 15,000 clicks = $0.124 EPC (FTD-based)
Registration-based EPC for the same source (misleading):
480 regs counted as "conversions" — tells you nothing
about how many of those regs actually depositedТа сама логіка стосується конверсій клік-у-FTD та інстал-у-FTD — саме ці цифри варто дивитися щодня, а не клік-у-реєстрацію. Аналітика DarkCore показує все це по кожному статусу — кількість подій, дохід, конверсії клік-у-статус та інстал-у-статус, а також EPC у розбивці по реєстрації, депозиту й будь-якому кастомному статусу — тож ви порівнюєте джерела по події, яка реально платить, а не по тій, яку найлегше накрутити. Правила авто-оптимізації, побудовані на реальних даних по депозитах (а не на власній звітності Facebook по подіях, яка не бачить, що відбувається всередині платформи оператора після реєстрації), можуть ставити джерело на паузу чи масштабувати його напряму по FTD rate, замість того щоб чекати на ручне витягування звіту.
Типові помилки
- Оптимізація до закриття вікна атрибуції. FTD може відставати від реєстрації на кілька днів залежно від фрикшну оплати й KYC. Прийняття рішення по джерелу через 24 години даних по реєстраціях, ще до того як депозити встигли прийти, вбиває джерела, які могли б стати прибутковими, і залишає ті, що прибутковими ніколи не стануть.
- Ставлення до “конверсії” як до одного плоского статусу. Якщо ваша система постбеків розрізняє тільки lead і sale, події реєстрації й депозиту зливаються, або одна тихо перезаписує іншу, і ви втрачаєте можливість бачити той етап воронки, який реально важливий.
- Відсутність валідації збігу
click_idна постбеках депозиту. FTD, що приходить без відповідного початкового кліка, не атрибутується взагалі (або, що гірше, атрибутується не тому джерелу), занижуючи реальну ефективність джерела, яке його заробило. - Порівняння EPC між джерелами з різними вікнами звітності. Джерело, виміряне за 3-денними даними по FTD, поруч з тим, що виміряне за 14-денними, завжди виглядатиме гірше — просто через коротше вікно накопичення депозитів, а не через гірший трафік.
- Ігнорування даних по ребілу в угодах на RevShare. Оптимізація виключно по кількості FTD, коли вам платять частку від довічного доходу, означає, що ви можете ганятися за дешевими малоякісними депозиторами, які ніколи не депозитять повторно, тоді як трохи дорожче джерело з хорошим ребіл-рейтом тихо заробляє більше.
FAQ
Що вважається FTD у гемблінг-трекінгу?
Перший успішний депозит, який користувач робить після реєстрації — не депозит в очікуванні, не бонусний кредит і зазвичай не депозит нижче за мінімальний поріг оператора, якщо оффер його визначає. Точне визначення варто уточнювати по кожному оператору окремо, бо мінімальні суми депозиту й те, що вважається “першим” (наприклад, після невдалої спроби), відрізняються між офферами.
Скільки часу зазвичай минає між реєстрацією і FTD?
Залежить від вертикалі, платіжного методу й вимог KYC, але для користувачів, які взагалі конвертуються, депозит в той самий день — звичайна справа, з довшим хвостом, що розтягується на кілька днів. Саме тому оцінювати джерело лише по даних реєстрацій у перші 24–48 годин ненадійно — дайте постбеку FTD час прийти, перш ніж робити висновки.
Чи працює FTD-трекінг з моделями виплат RevShare, де значення не фіксоване?
Так — сама подія FTD трекається однаково незалежно від моделі виплат, це статус, а не сума в доларах. При RevShare подію FTD доповнюють постійними постбеками по ребілу/доходу протягом усього життєвого циклу гравця, щоб побачити повну цінність, замість того щоб очікувати, що один-єдиний постбек FTD принесе фінальний дохід.
Чи потрібен окремий піксель для FTD, чи достатньо постбеку?
S2S-постбек — надійний шлях саме для FTD, бо депозити часто відбуваються значно пізніше кліка й поза будь-якою браузерною сесією, до якої ще міг би бути прикріплений піксель. Піксель може доповнювати його на ранніх етапах воронки, але для події, яка реально платить, довіряти варто саме постбеку.
FTD — це та цифра, яка вирішує, чи прибуткова гемблінг-кампанія, і вона рідко стоїть на видному місці в дашборді, побудованому навколо кліків і реєстрацій. Зробити правильно означає маршрутизувати події депозиту й ребілу на сервері, по статусу, назад до кліка, який їх заробив, а потім оцінювати кожне джерело по EPC і ROI, розрахованих саме по цій події — а не по дешевшій і галасливішій, що їй передує. Якщо ваш поточний стек досі показує реєстрації як головну метрику, варто поговорити з нами про те, як насправді виглядають ваші дані по FTD, коли їх трекають правильно.