From Click to FTD: How to Track an iGaming Funnel When the Conversion Arrives a Week Late

Update, September 2026: Brazil banned fixed-odds betting and online casino, including advertising, with Provisional Measure 1.394. Brazil figures below describe the market before the ban.

From Click to FTD: How to Track an iGaming Funnel When the Conversion Arrives a Week Late

A joint guide by Traffic Nomads and Binom.

If you came to iGaming from nutra, sweepstakes, dating or e-commerce, your tracking instincts are wrong here. Not slightly wrong. Structurally wrong.

In most verticals the conversion is the click's close relative. Someone lands, submits, buys, and the postback fires inside the same session. You launch on Monday, read the report on Wednesday, cut the losing zones, and scale what's left. That loop works because the data is complete when you look at it.

iGaming does not work like that. The event you actually get paid for, the first-time deposit, can land hours or days after the click that created it. Every intermediate signal you see before then is a partial picture, and most media buyers make their most expensive decisions inside that window.

This guide covers how to structure an iGaming funnel in Binom so you are optimizing against deposits instead of noise, and how to make decisions on incomplete data without either burning budget or killing winners early.

The Four Events That Matter

The first mistake is treating iGaming as a single-conversion vertical. It has a chain, and each link has a different meaning, a different volume, and a different level of trust.

Event	What it tells you	Volume	How much you should trust it
Click	Traffic was delivered	Highest	Delivery only, says nothing about quality
Registration	The user filled a form	Orders of magnitude lower	Weak signal, easily faked, easily incentivized
FTD	The user moved real money	Lower again	The real signal, and the one that pays
Redeposit / qualified player	The user has retention value	Lowest	The signal that tells you whether the FTD was worth buying

Most campaigns are built to see the first two clearly and the last two badly. That is the entire problem in one sentence.

Why Optimizing on Registration Destroys ROI

Registration feels like a reasonable proxy. It arrives fast, it has volume, and it correlates with deposits. The issue is how wide that correlation actually is.

Public benchmark work from OptiKPI puts registration-to-FTD rates roughly at:

Traffic source (Tier 1)	Registration to FTD
Organic brand search	35 to 55%
Affiliate review and comparison	22 to 40%
Paid search	15 to 28%
Paid social	5 to 15%
Display and programmatic	3 to 10%

Those are directional figures rather than audited industry data, and OptiKPI says so plainly. But the shape is what matters: the spread between the best and worst source types is roughly five to ten times. Regional spread compounds it. The same source cited registration-to-FTD ranges of 12 to 28% in the UK, Germany and Sweden against 25 to 50% across Brazil, Mexico and LATAM, largely because KYC friction and payment rails differ.

Run the arithmetic. Two zones deliver 100 registrations each at the same CPA. Zone A converts at 4% to deposit, Zone B at 20%. You paid the same for 4 depositors and 20 depositors. If you are optimizing on registrations, those two zones look identical in your report and you will happily scale the wrong one.

This is also why registration-optimized campaigns attract a specific kind of fraud. A fake registration is cheap to manufacture and looks exactly like a real one until the deposit fails to arrive. Deposit-level tracking is not just an optimization tool, it is your cheapest anti-fraud layer.

The Attribution Lag Problem

Here is the part nobody warns you about.

The time between click and deposit is not fixed and it is not short. A user can click a pop at 23:00, register out of curiosity, sleep on it, and deposit two days later after checking the bonus terms. In sportsbook, the gap often stretches to the next fixture that interests them. OptiKPI notes that median time from registration to FTD can exceed 48 hours in some markets, and registration itself is already downstream of the click.

That produces a specific failure mode. On day two your campaign looks terrible, because day-two data contains all of the cost and only a fraction of the revenue that cost will eventually produce. If you cut zones on a day-two read, you are systematically eliminating the sources whose users take longer to decide. Those are not always the worst users. In some GEOs they are the better ones.

Three rules follow from this, and they are the operational core of everything below.

Cohort by click date, not by conversion date. A report that shows yesterday's spend against yesterday's conversions is comparing two different populations. You need conversions attributed back to the click that produced them, then read as a cohort that matures over time. Binom's Conversions page carries Time click, Time conversion and Time since click on every record, which is the raw material for this, and the Time since click distribution is worth looking at on its own before you set any decision window. Build the cohort view from there, whether through filtering or an export, rather than reading the default date-based stats view and assuming it answers the question.

Define a maturity window before you launch, not after. Pick a number of days after which you consider a cohort readable. Then measure how much your cohorts actually move after that point. If day-7 numbers are materially different from day-3 numbers, your window is too short. Write it down and apply it consistently, because the temptation to make an exception always arrives on the campaign you are emotionally invested in.

Use two decision gates, not one. Early gate: cut on delivery quality only, meaning bots, blank sessions, impossible time-on-page, zero registrations at high volume. Late gate: cut on deposit economics once the cohort has matured. Mixing the two is how buyers kill profitable zones on day two.

Setting It Up in Binom

Binom handles this well because it treats a click as an object that can keep receiving information long after the click happened. Three mechanics do the heavy lifting.

1. Multiple postbacks against the same clickid

Your postback structure follows the standard format:

https://your-tracker-domain/click.php?cnv_id={clickid}&payout={sum}&cnv_status={status}

The parameters that matter for a multi-stage funnel:

• cnv_id receives the clickid you passed to the operator or affiliate network
• payout carries the value of that specific event
• cnv_status and cnv_status2 let you label what kind of event it was
• cnv_currency matters more in iGaming than most verticals, because operators frequently report in local currency
• disable_postback=1 stops the outgoing postback to the traffic source, which you will want on some intermediate events and definitely not on your FTD

Set a distinct status per funnel stage. Registration, FTD, redeposit. The exact labels are yours to define, since status values are not standardized across networks, so agree them with your operator before you launch rather than reverse-engineering them from a report later.

Critically, enable the Upsell option. It is a checkbox in the offer settings, so it is set per offer rather than globally, which means it is easy to have it on for one offer and silently off for the next. Without it, a second postback on the same clickid replaces the payout of the first. With it, Binom sums the payouts across multiple postbacks for the same click. In a vertical where one user generates a registration, a deposit and then redeposits, replacement behaviour will quietly understate your best cohorts.

2. Events as funnel counters

Binom v2 supports up to 30 numeric events per click, passed as &event1=1 to set a value or &add_event1=1 to increment one. These are counters, not conversions, and that distinction is useful.

Use conversions with statuses for the money events, and use events for the countable behaviours you want in a custom column: number of deposits, number of sessions, bonus claimed, KYC completed. Then build the ratios you actually manage against, under Settings, Stats settings, Columns, Add custom column, using the same formula syntax Binom documents for custom metrics. Binom's own documented example is event_1/clicks*100, and the underscore variables run from event_1 to event_30. If event1 increments on registration and event2 on deposit, an event_2/event_1*100 column gives you a live registration-to-deposit rate you can group by zone. Check how your build renders it on rows where event_1 is zero, which will be most of your long tail of zones, before you start making cut decisions from that column.

One caveat from Binom's documentation: if you have the e-commerce status scheme enabled, events 25 to 30 are unavailable. Plan your event map around that before you wire anything up, because renumbering events after a campaign has history is painful.

3. Grouping depth for zone-level truth

Binom supports up to five grouping levels in a report. In iGaming, the grouping that earns its keep is usually:

Traffic source → GEO → Zone / SubID → Format → Creative

Then sort by cost per FTD rather than by conversions, filtered to cohorts that have passed your maturity window. That single report replaces about eighty percent of the guesswork in a scaling decision.

Closing the Loop: The Tracker Measures, the Network Optimizes

Everything above makes your data honest. It does not by itself make your campaign better, because Binom is measuring, not buying. The buying decisions happen inside your traffic source, and a traffic source can only optimize toward events it receives.

This is where most iGaming setups quietly leak performance. The buyer builds a beautiful deposit-level tracking structure in Binom, then sends the ad network nothing but clicks, or at best registrations. The network's algorithm dutifully optimizes toward the metric it can see, which is the metric that does not pay.

On the Traffic Nomads side this is what FTD Magnet AI exists to solve. It takes the deposit event as the optimization target instead of clicks or registrations, and evaluates traffic segments against signals that correlate with depositor behaviour: source, GEO and device combinations, funnel interaction patterns, and timing signals associated with deposit likelihood. It runs on Pop, Push and In-Page Push, which between them carry most iGaming testing and scaling volume, including the iOS and browser environments where classic push cannot reach.

In our own case study across a group of iGaming campaigns spanning multiple GEOs and traffic sources, deposit-optimized campaigns showed up to 8x higher conversion rates and up to 5x lower cost per event compared with manual bidding on comparable offers, and 66% of all post-click events between registrations and FTDs were generated by campaigns using it. That is vendor data on our own network rather than independent research, and you should treat it accordingly. The mechanism is the part worth taking seriously: an algorithm optimizing toward deposits will always beat one optimizing toward clicks, whoever is running it.

The practical requirement is simple. Fire your FTD postback back to the traffic source, not just into your tracker. In Binom that means leaving the outgoing postback enabled on your deposit event, even if you disable it on intermediate steps.

The Mistakes Worth Checking For

Before your next launch, run through this list.

• Optimizing on registrations because the FTD postback was never wired up
• Cutting zones on day-two data when your cohorts mature on day five
• Upsell disabled, so redeposits are overwriting FTD payouts instead of adding to them
• Reading reports by conversion date instead of click date
• One status for all conversions, making registration and FTD indistinguishable in reports
• Comparing GEOs on raw registration-to-deposit rate without accounting for KYC friction
• Sending deposit data to the tracker but not back to the ad network
• Benchmarking against a single industry number instead of your own historical cohorts

The Short Version

iGaming pays on an event that arrives late, and every tracking habit built in fast-conversion verticals will mislead you here. Structure the funnel as four distinct events. Give each one a status. Turn Upsell on. Read by click date, wait for the cohort to mature, and decide with two gates instead of one. Then send the deposit signal back upstream so the money being spent is optimizing toward the same event you are measuring.

Get that loop closed and iGaming stops being a vertical where you hope the numbers work out, and becomes one where you can see exactly which zone bought you a depositor.