FTD Tracking Explained: How Gambling Media Buyers Measure Real Revenue

Last month a media buyer we work with had a Facebook source delivering registrations at $1.20 apiece — a genuinely strong number for a gambling vertical, well under the $3–4 he was used to paying. By every dashboard he had open that day, it was the best performer in the account. Then the FTD report landed three days later: 1,000 registrations, 20 first-time deposits. A 2% registration-to-deposit rate, against a portfolio average closer to 8%. At a $35 payout per FTD, that source generated $700 in revenue on $1,200 of spend — a loss he’d have scaled harder if he’d kept watching cost-per-registration instead of waiting for the number that actually pays. This is the core failure of reg-only optimization in gambling media buying, and it’s exactly why FTD tracking — measuring and optimizing on the first-time deposit event specifically, not the registration step that precedes it — is the only view of a campaign that tells you whether it’s making money.

What Is FTD Tracking, Exactly?

FTD stands for first-time deposit — the moment a registered user funds their account for the first time. In gambling and iGaming, it’s the event that converts a sign-up into a paying customer, and in almost every payout model (CPA, RevShare, or hybrid), it’s the event that triggers or unlocks revenue. FTD tracking is the practice of capturing that specific event server-side, tying it back to the original click and source, and reporting on it as its own metric — separate from registrations, separate from clicks, separate from any “conversion” bucket that lumps everything together.

The distinction matters because a registration costs the advertiser nothing beyond a form submission. A first-time deposit means real money changed hands. Any funnel report, dashboard, or optimization rule that treats these two events as interchangeable is measuring the wrong thing, and in a vertical where deposit rates can swing from 2% to 15% between sources with identical registration costs, that’s not a rounding error — it’s the difference between a profitable account and a bleeding one.

Why Registrations Lie: The Full Funnel

The gambling funnel has at least four distinct stages, and each one filters out a different kind of user:

• Click — someone taps your ad and lands on the offer.
• Registration — they fill out a sign-up form. This step is cheap to fake, cheap to farm, and heavily influenced by landing page friction that has nothing to do with buying intent.
• FTD (first-time deposit) — they add funds. This is the first point where the user has actually committed money.
• Rebill / redeposit — they deposit again. This is where lifetime value and true payback period get decided.

Registrations are the easiest stage to optimize against and the least correlated with revenue. A source can deliver cheap, plentiful registrations from bonus hunters, incentivized traffic, or simply low-intent clickers who fill out any form in front of them, and none of that shows up until the FTD stage — which, in gambling specifically, can lag registration by hours or days depending on payment method friction, KYC checks, and how aggressively the operator’s onboarding flow nudges a first deposit.

Here’s a worked funnel for a single source, spend included:

Look only at the registration row and this source is fine — $1.67 per reg is a reasonable target in most gambling verticals. Look at the FTD row and the picture changes: $33.33 cost per acquired depositor, against whatever your actual payout per FTD is, is the number that decides whether this source gets more budget or gets killed.

Worked Example: Same Reg Cost, Opposite Outcomes

The scenario that trips up almost every buyer optimizing on registrations alone is two sources with near-identical reg economics and wildly different FTD economics. Here’s a side-by-side:

Source A looks like the winner on every metric a reg-only dashboard shows: more registrations, cheaper cost per reg, better CTR. It’s also losing money. Source B looks expensive and low-volume by comparison, and it’s the only one worth scaling. This is the pattern that quietly drains gambling ad accounts — buyers pour budget into the source with the best top-of-funnel numbers because that’s the only data they’re watching in real time, while the FTD data that would tell the real story shows up late, in a separate report, that nobody cross-references against spend on a daily basis.

How FTD Actually Gets Tracked: S2S Postback, Routed by Status

Registrations and deposits typically arrive as two separate events from the operator’s platform, often minutes to days apart, which is exactly why S2S (server-to-server) postback tracking with per-status routing is the only reliable way to capture FTD. Instead of one flat “conversion” postback, the operator fires a distinct callback for each funnel event — registration, deposit, and any custom status you define — each carrying the same click_id so your tracker can stitch the whole journey back to the original ad, source, and campaign.

In DarkCore’s streams, postback routing is configured inline per stream and keyed on conversion status, not on a single generic event type:

# registration event — informational only, not the revenue trigger
https://track.yourdomain.com/pb?click_id={click_id}&status=registration&payout=0&currency={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}&currency={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}&currency={currency}

Because conversion statuses live in a per-workspace registry rather than being hardcoded, adding a new one — rebill, redeposit, or anything specific to an operator’s funnel — makes it available everywhere at once: postback routing, pixel firing, and analytics reporting, with no extra integration work per stream. That matters in gambling specifically because operators vary in what they call their events and how many stages they expose, and a tracker that can only handle “lead” and “sale” forces you to collapse distinct funnel steps into one bucket, which is the same reg-only blindness in a different form.

RevShare vs. CPA vs. Hybrid: Why the Payout Model Changes What You Optimize

The payout structure your offer runs on determines exactly how much an FTD is worth, and getting this wrong compounds the reg-only mistake:

• CPA (cost per acquisition): you’re paid a fixed amount per FTD, sometimes with a minimum deposit threshold. Here, FTD rate directly multiplies against a known payout — the math in the tables above applies cleanly. The risk is that a fixed CPA rewards volume over deposit quality; a source delivering minimum-threshold depositors who never come back looks identical to one delivering real players, until you check rebill rates.
• RevShare (revenue share): you’re paid a percentage of net gaming revenue generated by the depositing player over time, not a flat fee per FTD. A single FTD might be worth $8 or $200 depending on how the player behaves over the following weeks. Optimizing on FTD count alone under RevShare still beats optimizing on registrations, but it’s incomplete without layering in rebill and retention data — a source with a lower FTD rate but higher-value depositors can outperform a source with more, cheaper FTDs.
• Hybrid: a smaller fixed CPA plus a reduced RevShare cut. This is common in gambling specifically because it de-risks both sides — the affiliate gets some guaranteed return per FTD, the operator caps downside exposure on low-value players.

Whichever model you’re on, the payout only becomes real money once it’s reconciled against what you actually spent, source by source, over the actual settlement period — which is a large part of why a double-entry finance ledger tracking real P&L matters more in gambling than in verticals where the platform’s own reported numbers are close enough to trust.

Measuring True EPC and ROI on the FTD Event

EPC (earnings per click) calculated on registrations tells you how efficiently you’re generating sign-ups. EPC calculated on FTD tells you how efficiently you’re generating money. They are not proxies for each other, and in gambling the gap between them can be large enough to flip a source from “scale it” to “kill it.”

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

The same logic applies to click-to-FTD and install-to-FTD conversion rates, which are the numbers worth watching daily rather than click-to-registration. DarkCore’s analytics surfaces these per status — event counts, revenue, click-to-status and install-to-status rates, and EPC broken out by registration, deposit, and any custom status — so you’re comparing sources on the event that actually pays rather than the one that’s easiest to inflate. Auto-optimization rules built on real deposit data (not Facebook’s own event reporting, which has no visibility into what happens inside the operator’s platform after registration) can pause or scale a source based on FTD rate directly, instead of waiting for a manual report pull.

Common Mistakes

• Optimizing before the attribution window closes. FTDs can lag registration by several days depending on payment friction and KYC. Pulling the trigger on a source after 24 hours of reg data, before deposits have had time to land, kills sources that would have turned profitable and keeps ones that never will.
• Treating “conversion” as one flat status. If your postback setup only distinguishes lead vs. sale, registration and deposit events get merged or one silently overwrites the other, and you lose the ability to see the funnel stage that actually matters.
• Not validating the click_id match on deposit postbacks. An FTD that arrives without a matching original click gets attributed to nothing (or worse, to the wrong source), understating the real performance of the source that earned it.
• Comparing EPC across sources with different reporting windows. A source measured on 3-day FTD data next to one measured on 14-day FTD data will always look worse, purely from a shorter window to accumulate deposits — not from worse traffic.
• Ignoring rebill data under RevShare deals. Optimizing purely on FTD count when you’re paid on lifetime revenue share means you can chase cheap, low-quality depositors who never redeposit, while a slightly more expensive source with strong rebill rates quietly outearns it.

FAQ

What counts as an FTD in gambling tracking?

The first successful deposit made by a user after registering — not a pending deposit, not a bonus credit, and typically not a deposit below the operator’s minimum threshold if the offer specifies one. The exact definition should be confirmed per operator, since minimum deposit amounts and what counts as “first” (e.g., after a failed attempt) vary between offers.

How long after registration does an FTD typically happen?

It varies by vertical, payment method, and KYC requirements, but same-day deposits are common for users who convert at all, with a longer tail stretching out several days. This is exactly why judging a source on registration data alone within the first 24–48 hours is unreliable — give the FTD postback time to arrive before drawing conclusions.

Can FTD tracking work with RevShare payout models, where the value isn’t fixed?

Yes — the FTD event itself is tracked identically regardless of payout model; it’s a status, not a dollar amount. Under RevShare, you pair the FTD event with ongoing rebill/revenue postbacks over the player’s lifetime to see the full value, rather than expecting the FTD postback alone to carry final revenue.

Do I need a separate pixel for FTD, or does the postback handle it?

The S2S postback is the reliable path for FTD specifically, since deposits often happen well after the click and outside any browser session that a pixel could still be attached to. A pixel can complement it for earlier funnel stages, but for the event that actually pays, the postback is what you should trust.

FTD is the number that decides whether a gambling campaign is profitable, and it’s rarely the number sitting front and center on a dashboard built around clicks and registrations. Getting it right means routing deposit and rebill events server-side, by status, back to the click that earned them, and then judging every source on EPC and ROI calculated against that event — not the cheaper, noisier one that precedes it. If your current stack still reports registrations as the headline metric, it’s worth talking to us about what your FTD data actually looks like once it’s tracked properly.