iGaming Conversion Tracking: How to Tie Every FTD to the Banner That Earned It

Your media buyer reports 400 registrations from a new sports site. Finance reports 38 first-time deposits for the week, from all sources combined.

Neither report says which banner, on which placement, produced those deposits. You renew the site anyway, because the registration number looks good.

That gap between the click you paid for and the deposit you earned is what iGaming conversion tracking closes. This guide is written for operators who buy placements directly, on sites they know, and need to prove which placement pays.

What Is iGaming Conversion Tracking?

iGaming conversion tracking is the process of linking each player action, such as registration, first-time deposit, re-deposit or withdrawal, back to the ad impression and click that started it. It tells an operator which placement, creative and source produced deposits, not only registrations.

Two terms carry the whole topic. A first-time deposit (FTD) is the moment a registered player funds an account for the first time. It is the main KPI because registration alone earns nothing.

A postback is a server-to-server message from your backend to the ad platform that says "this click converted". Our guide to postback tracking covers the mechanics.

Affiliates and operators track the same events for different reasons. An affiliate needs to prove the FTD to get paid. An operator needs to know which spend to keep.

Why Does the FTD Get Lost?

The FTD happens after the click, often days later, and often somewhere the original browser can't see. A player clicks a banner on a mobile site, registers in the browser, then deposits three days later in the casino app. Every tool that relies on the browser loses that player somewhere between the steps.

Four things break the chain:

• Time. A cookie or a stored click ID must survive days between click and deposit. Safari's Intelligent Tracking Prevention caps cookies set by scripts at seven days, or 24 hours when the visitor arrives from a known tracker's decorated link, and wipes other script-written storage after seven days without a visit.
• Devices and apps. The click happens on one device and the deposit on another. A pixel on a web "thank you" page never fires inside a native app.
• Who confirms the deposit. Your payment system confirms an FTD, not the player's browser. A browser-side pixel can only guess.
• Ad blockers and privacy browsers. They let the player see and click some ads but block the tracking around them: the redirect, the conversion pixel, or the click ID in the URL. The player arrives, but without the ID, and later shows up as a direct or organic sign-up.

The result is a funnel that reports registrations well and deposits badly. Sources that send cheap sign-ups look strong. Sources that send depositors look average, because many of their FTDs never get credited.

Tracker, Ad Server or Affiliate Platform: Who Tracks What?

Three kinds of tools track iGaming conversions, and each one sees a different slice of your traffic. Most confusion about "the right tracking tool" comes from expecting one of them to do another's job.

An operator that buys placements directly needs the ad server layer for those campaigns. The ad server already knows which impression and click came first, so a tracker on the same placements counts each click a second time, and the two counts will differ. A click tracker stays useful as the layer over everything else you buy.

If you run an affiliate programme, the affiliate platform runs alongside. It pays partners; it doesn't serve or measure media. The only overlap is the FTD event itself, which your backend can send to both.

If you keep a tracker on those placements anyway, the banner's click URL points to the tracker's campaign. The ad server's click ID travels along in that URL. The tracker or your backend then sends the conversion back to the ad server.

Both systems end up with the same FTD, each in its own context.

How Do You Track an FTD Across Devices and Days?

Store the click ID on the player account at registration, then send it back with the FTD in a server-to-server postback. This is the one setup that survives app installs and device switches once the ID reaches the registration form because the ID lives in your database and not in the browser.

The flow takes four steps:

1. The ad platform adds a click ID to the landing URL. For example, ?clickid=abc123.
2. Your registration form saves that click ID to the new player's account. One extra column in the players table.
3. When the payment system confirms the first deposit, your backend sends a postback to the ad platform with the same click ID and the conversion type, for example "ftd".
4. The ad platform attributes the FTD to the impression and click that produced it.

Set the attribution window to match how your players behave. A sportsbook sign-up before a big match may deposit within an hour. A casino player may take two weeks. Check whether your platform lets you set separate post-click and post-view windows for each conversion type, and whether those windows also apply to server-to-server conversions.

Check what counts as an impression before you give post-view credit. Ad servers usually log an impression when the ad loads on the page, not when the player sees it. A long post-view window can then credit FTDs to banners below the fold that no player saw. Turn on viewability measurement if your platform offers it, or keep the post-view window short.

In Epom Ad Server: each conversion action has its own post-click and post-view window, from seconds up to years; new actions start at 7 days post-click and 1 day post-view. A setting decides whether the window also limits server-to-server conversions. Our conversion attribution update lists the postback parameters.

What Should an FTD Postback Contain?

An FTD postback needs two things to count: the identifier of the conversion type and the click ID you saved at registration. Everything else refines how the conversion is priced, attributed and checked. Field names differ by platform, but the same five fields appear in most specs.

A few tips for better control over attribution:

• Read the response, not only the HTTP status. A postback can reach the platform and still not count: the click is outside the attribution window, the click ID was truncated, or the conversion is a duplicate. Check whether your platform returns a reason with each response, and log it next to the player ID.
• Keep the FTD and re-deposits apart. Create two conversion types. Reject duplicates on the FTD, so a retried postback can't count one deposit twice, and allow several re-deposits per click.
• Decide what the payout field carries. On many platforms the payout is the price charged for the conversion, so a deposit sent there sets both the publisher's revenue share and what the advertiser is billed. The Epom Ad Server postback reference below shows one full spec.

How Should You Track the Whole Ad Funnel, Not Only the FTD?

Treat each step of the player journey as its own conversion type, all tied to the same click ID. Registration, FTD, re-deposit and withdrawal tell different stories about the same source.

Count players once, and steps many times. A source with 100 registrations and 10 FTDs has sent 100 people, not 110 conversions. Keep each step as a separate conversion type so reports show the funnel, not a sum.

In the FTD postback, put the CPA you pay for that player in the payout field: the platform bills you that number and pays the publisher's share out of it.

Build retargeting audiences from your own data. "Registered but never deposited" and "deposited, then withdrew" are the two audiences most operators want. Neither comes ready-made from an ad platform. You build them by matching event logs against your CRM, then uploading the list as a first-party audience, within your consent rules.

Why Should Raw Event Data Land in Your Own Warehouse?

Here is why, and how the logs fit together:

1. Because the vendor deletes it first. Ad platforms keep personal event data, such as IP address, user agent and device identifiers, for days, not months. Privacy rules push retention down, and the funnel you want to analyse runs longer than that.
2. Every request carries an ID that joins the logs. A raw impression log, click log and conversion log each record one row per event. A request or transaction ID links an impression to its click and a click to its conversion, so the full path can be rebuilt row by row.
3. Join long funnels in your own storage. If a deposit arrives three days after the click, the ad platform still attributes it through the click ID. To analyse the raw path behind it, you need a raw event export in your own warehouse, where you decide how long it stays. Our guide to log-level data explains what each log contains.

In Epom Ad Server: raw impression, click and conversion events are exported hourly as gzipped Parquet files to your S3, Google Cloud Storage or SFTP. Epom support sets up the export, which is part of the Advanced Analytics add-on. Raw event logs inside the platform are kept for a few days, so the copy in your storage is the long-term record.

Why iGaming Conversion Tracking Numbers Do Not Match Across Tools?

Each system counts at a different point in the redirect chain, so a gap of a few percent between the publisher, the ad server, the tracker and your site is normal. The publisher counts the tap. The ad server counts the click when its redirect fires. The tracker counts again on its own redirect, and your landing page counts the visit that arrives.

Every hop loses some visitors. A player closes the tab before the landing page loads, a browser blocks a redirect, or antivirus software flags the chain as suspicious. Redirect-heavy ad formats such as popunders lose more than standard banners.

Tighter frequency caps won't close the gap. A cap is one more filter in the chain, so it can widen the difference between what the publisher reports and what the ad server counts.

Decide which count you pay on, then watch the trend. Name the billing source in the publisher agreement, and compare counts at the same step: clicks with clicks, not clicks with visits. When the gap for a source jumps, match raw click logs against your landing-page logs to see which clicks never arrived.

How Does Fake-GEO Traffic Skew iGaming Conversion Tracking?

Fake-GEO traffic brings registrations at tier-1 prices and FTDs that never come. To catch it, compare the country of the visitor's IP address with the country of their browser's time zone. A VPN changes the IP, but it rarely changes the clock on the device.

Some legitimate players use a VPN, and travellers carry home time zones. A single mismatch proves nothing. A source where half the "Netherlands" traffic runs on a South Asian time zone tells you what you are paying premium-GEO prices for.

Before and after (illustrative example). An operator buys tier-1 inventory from a site that promises 80% Netherlands traffic.

• Before: the site looks like the best partner by registrations and the worst by FTDs. The reason is unclear.
• After a week of daily scoring: half its requests show an IP country that doesn't match the browser's time zone. The operator cuts the source before the next invoice and moves the budget to two sites with low mismatch.

In Epom Ad Server: the geo-mismatch signal is part of a daily Traffic Quality score per placement, calculated for yesterday's traffic once a placement has 500 requests with both IP country and time zone known, and graded at 15%, 30% and 50% mismatch. It flags the source; you block it with a targeting rule. Epom support switches Traffic Quality on; read more about the Traffic Quality analyzer.

What Should Your CISO Ask Any Tracking Vendor?

Licensed operators answer to a security team before any tag goes live. These six questions work for any tracker, ad server or affiliate platform, and a vendor should answer each one in writing.

iGaming Conversion Tracking With Epom Ad Server

Epom Ad Server is an ad server for operators and networks that serve their own campaigns. It is not a click tracker. For placements you buy directly and run through it, it covers the chain from impression to FTD without a second tool.

• Attribution: click ID in the landing URL, server-to-server postbacks, separate post-click and post-view windows for each conversion action.
• Funnel: registration, FTD, re-deposit and withdrawal as separate conversion actions, with deposit value passed as the conversion payout for revenue share.
• Data: hourly raw event export to your S3, Google Cloud Storage or SFTP, with Advanced Analytics.
• Traffic quality: a daily geo-mismatch score per placement, alongside crawler, headless browser and fast-click signals.
• Works with your tracker: banner click URLs can point to a tracker campaign with the click ID and sub-parameters passed through, and conversions can be forwarded onward.

It fits operators who buy placements directly on sites they know, need each FTD tied to a banner and placement, and want raw events in their own warehouse. It is the wrong choice if your security policy rules out any hosted processor, or most of your spend goes through Google Ads and Meta, where a click tracker comes first.

FTD Postback Reference for Epom Ad Server

The banner's landing URL carries the $$CLICK_ID$$ macro, for example https://casino.example/welcome?easclid=$$CLICK_ID$$. Store easclid with the player at registration. On the first deposit, your backend calls:

Your tracker or player account system fills {click_id} and {player_ip} before the call; Epom doesn't expand them.

Partner values sub1 to sub10 aren't sent on the postback; they travel inside the click ID. The keys value, amount and sum are refused on purpose: the conversion still counts at the campaign's own rate, and the response carries XD-warning: payout-word-refused. A transaction ID on its own never matches a conversion, because it identifies an impression, not a click.

Read the XD-reason response header, not the HTTP status. An expired conversion is logged as a diagnostic, so it returns 200 while the header says expired.

For FTD versus re-deposit, create two actions with separate keys. Turn on Reject duplicate conversions for the FTD, with network-level S2S deduplication on as well, and leave it off for re-deposits.

FAQs