В прошлом месяце у одного медиабаера, с которым мы работаем, был источник на 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, когда их трекают правильно.