Server-Side Tracking for iGaming: Clicks to FTDs

If the vocabulary is new, the glossary has the click ID, the postback URL and the first-time deposit.

A pixel works when the conversion happens on a page you control, soon after the click, in a browser that lets the script run. An iGaming conversion fails all three conditions, and usually at once.

• Ad blockers

  Blocker lists target the domains of tracking scripts, and the gambling audience runs them. A blocked pixel sends nothing, so the click it should have recorded never existed as far as your report is concerned.

• Safari's tracking prevention

  WebKit deletes cookies written by JavaScript after seven days without interaction, and caps them at 24 hours on a landing page reached through a decorated link. A player who deposits on day nine arrives with no cookie left.

• The redirect to the operator

  Registration and the cashier run on the operator's domain. Operators do not let affiliates place scripts there, so your pixel stops at your page and never sees the reg or the deposit.

• The FTD comes days later

  Players register, claim the bonus and deposit on day three, or day eleven, often on another device. Whatever the browser held at the click has to survive that long, on a site that is not yours.

Server-side tracking changes where each piece is recorded. The click is written by your server on your own domain, so there is no third-party script for a blocker to stop. The click ID lives in your database, so Safari's cookie caps do not decide how long it lasts. And the reg and the FTD never had to be seen in a browser at all: the program already knows about them, and it tells you through a postback. That is the whole idea behind server-side tracking.

Four events carry an iGaming affiliate's month. Each one has a different owner, a different meaning and a different use in the ad platforms, and mixing them up is the most common reason a campaign looks profitable in Ads Manager and is not on the statement.

Where a deal has a minimum deposit, the qualified FTD is the event that pays, so send that one. Reg to FTD per source separates depositors from bonus hunters: the keyword with cheap regs and few FTDs looks best and pays worst. What arrives by postback depends on the program, and NGR is the operator's calculation, so it reaches you on a postback or the statement, never from your own tracking. The CPA to compare against is the cost per FTD, not per reg.

Everything hangs on one string: the click ID your tracker issues at the click, which the program keeps on the player and returns on every postback. Four steps, none of them on the operator's site.

1. The click. The visitor clicks from your review page, bonus keyword ad or stream link. Your server records the click on your own tracking domain with a click ID, the source, page, keyword, geo and, when the visit came from an ad, the platform's own click ID (GCLID, GBRAID, fbclid).
2. The hand-off. The redirect to the operator carries your click ID in the sub ID or tracking variable the program offers. The program stores it with the player when they register.
3. The postback. When the player registers, deposits for the first time and deposits again, the program fires your postback URL with the click ID and the event filled in, plus the amount where the program has one.
4. The match. Your tracker finds the click by its ID and lands the event on it. The FTD on day three now sits on the keyword that sent the player on day zero.

https://track.your-domain.com/postback
  ?click_id={CLICK_ID}
  &event={EVENT}          // reg, ftd, deposit
  &amount={AMOUNT}        // the deposit or the CPA, where the program posts one
  &currency={CURRENCY}
  &player={PLAYER_ID}     // lets a redeposit find the same player

The names in braces are placeholders: every program platform has its own macro names for the same fields, and the program's own documentation is where to read them. What does not change is the rule that the click ID must leave your server on the way out and come back on the way in. The full setup, test postbacks included, is in our guide to iGaming affiliate postbacks.

A bonus keyword campaign that only ever sees clicks optimises for clicks. To make Smart Bidding buy depositors, Google has to be told which click produced an FTD, and for an affiliate the route is offline conversion import keyed on the GCLID you stored at the click.

• Matched on the GCLIDGoogle matches an imported conversion to the click by its GCLID, and supports GBRAID for iOS and Safari traffic. Without the ID stored at the click, there is nothing to match.
• Value and currencyBoth are optional fields on the import, with currency as an ISO 4217 code. Send the CPA as the value on a CPA deal, the deposit on a rev share deal, and keep one rule across the account.
• The conversion windowThe click-through window defaults to 30 days and goes up to 90 depending on the conversion source. An FTD after the window is not recorded, so set it to the real click to FTD time, not the default.
• TimingGoogle says a conversion within a day of its click may not be recorded yet, and to allow 24 to 48 hours of processing. Send in real time and expect the report to lag a day.

Two notes on the tooling. Enhanced conversions for leads supplements imports with hashed user data that a tag collects on your own form, and the affiliate never sees the player's email: the operator's form collects it. For an affiliate the GCLID is the match, and Google says it is required when no such tag runs. And Google's API documentation says that from 15 June 2026 a developer token that never uploaded offline conversions before gets its UploadClickConversion requests refused, with the Data Manager API as the route instead. A script written today should start there.

Meta has no import keyed on a click ID in the Google sense. The FTD goes in through the Conversions API as a server event, and what makes Meta match it to the ad is the fbc value you kept from the first visit.

• Keep the fbclid at the click. Meta's format for fbc is fb.subdomainIndex.creationTime.fbclid, and its documentation says you can build it from the fbclid in the landing URL when no _fbc cookie exists, using the time you first saw the fbclid. Store it with your click.
• Send the FTD within seven days of the deposit. event_time is when the event happened, and Meta accepts events up to seven days old. A postback that arrives in real time is fine; a program that reports FTDs in a monthly batch is too late for Meta.
• Pick one event and keep it. A standard Purchase with value and currency, or a custom event you build a custom conversion on. Either works for optimisation; switching between them restarts what the campaign has learned.
• Send the value. The CPA or the deposit, the same rule you use for Google, in custom_data with a currency.

{
  "data": [
    {
      "event_name": "Purchase",
      "event_time": <FTD_TIME_UNIX_SECONDS>,
      "event_id": "ftd-<PLAYER_ID>",
      "action_source": "website",
      "event_source_url": "<YOUR_LANDING_PAGE_URL>",
      "user_data": {
        "fbc": "fb.1.<FIRST_SEEN_MS>.<FBCLID>",
        "client_ip_address": "<IP_AT_THE_CLICK>",
        "client_user_agent": "<USER_AGENT_AT_THE_CLICK>"
      },
      "custom_data": { "value": 200, "currency": "EUR" }
    }
  ]
}

The affiliate's match keys are thin by nature: the click's IP, its user agent and the fbc, and no email or phone, because the player typed those into the operator's form. That is why the fbc stored at the click matters more here than for a store or a lead form, and why a tracker that loses the fbclid on the redirect loses the FTD for Meta. More on the Meta Conversions API.

An affiliate's browser never saw the FTD, so duplicates come from elsewhere: a program firing the postback twice, a test left in, two systems sending the same FTD, or the FTD reported again as a deposit.

• One ID per FTDMeta deduplicates on event_id plus event_name, within 48 hours of the first copy. Build the ID from the player, ftd-<player ID>, and a repeated postback produces the same ID rather than a second FTD.
• An order ID for GoogleGoogle's API calls order_id optional and strongly recommended for imported conversions, because it makes later adjustments possible. The same player-based ID works.
• FTD and deposit kept apartThe first deposit is the FTD, and only redeposits count as deposits. Read the program's postback log once to see whether its deposit event includes the first one.
• One sender per platformWhatever sends FTDs to Google and Meta, make it one system. Two senders with two ID schemes are two conversions that no deduplication can pair.

Tracking FTDs is only useful on traffic you are allowed to buy, and both platforms gate gambling before a single ad serves. What follows is read from their own policy pages on 2 October 2026; the pages change, so read them again before you apply, and the licence questions are for your own lawyer, not this article.

Google Ads: certification per country

• Certification first. Google's gambling and games policy says advertisers need to apply for certification to run gambling and gambling-promoting content, one application per country.
• Affiliates are a category of their own. The allowed form of gambling-promoting content is "aggregator or affiliate sites that provide information about, or a comparison of, other gambling services". Such a site may not offer gambling itself or link to services it owns, and may only promote products licensed in the country it targets.
• Not every country allows affiliates. Google's words: "Where online gambling-promoting content is not listed for a particular country, it may not be advertised there." On 2 October 2026 sixteen country entries list it, among them the United Kingdom, France, Ireland, Denmark, Portugal, Mexico and the United States, where the form limits it to specific states. Germany, Spain and the Netherlands have no such entry.
• The landing page carries obligations. Responsible gambling information, an age warning, never targeting minors, and for an affiliate without a licence of its own, links only to licensed operators plus a footer statement saying so.
• The certificate is for one website. Ads can only use the site in the application, and a material change means recertifying.

Meta: authorization in Business Suite

• Authorization, not just an ad review. Meta's online gambling and games policy requires the ad account to be authorized through the Authorizations and Verifications tab in Meta Business Suite, with evidence that the gambling is licensed or lawful in the target territory. Older guides call this prior written permission.
• Affiliates included. The policy names "aggregator or affiliate sites" whose landing pages promote online gambling, even when nobody can gamble on that page.
• Ages and countries. No targeting under 18, intent declared before the first ad in a new jurisdiction, and nineteen unsupported markets listed on the page, among them India, Indonesia, the Philippines, Singapore, Thailand and Vietnam.

An operator buying its own traffic has the opposite problem. The registration and the cashier are on its domain, so it can see every FTD, but the payment usually completes at a payment provider, and the event that proves the deposit is a webhook to the backend, not a page load in the browser.

1. Store the click IDs at registration. Read the GCLID, GBRAID and fbclid from the landing URL, keep them first-party (a cookie your server sets, not a script), and write them onto the player record when the account is created.
2. Fire the FTD from the backend. When the payment provider's webhook confirms the first successful deposit, look up the player's stored click IDs and send the FTD to Google and Meta from the server, with the deposit as the value.
3. Keep reg and FTD as separate conversions, and optimise on the FTD. Redeposits can go as value inside each platform's window.

LeadJourney's iGaming product is built for the affiliate's side of that hand-off, not as an operator's casino platform or partner program software. The operator's half is plumbing on the operator's own backend, and the same rules for value, windows and IDs apply.

1. Point a subdomain of your own at your tracker, so every click is recorded first-party.
2. Store your click ID and the ad platform's click ID (GCLID, GBRAID, fbclid) with every click.
3. Pass your click ID in each program's tracking link, and paste your postback URL into each program with the click ID, event and amount macros.
4. Fire a test reg and a test FTD, and see both match in the postback log.
5. Pick the event that pays (FTD or qualified FTD), its value rule, and one ID per FTD.
6. Hold Google certification and Meta authorization for every country you target, then send the FTD to both, inside their windows.

• The best iGaming tracking software: the trackers that do the click and the postback, compared.
• iGaming affiliate postbacks: macros, tests and the postback log in depth.
• In the glossary: first-time deposit, postback URL, click ID, server-side tracking and offline conversion tracking.
• On the product side: iGaming tracking software, tracking for affiliate marketers, and how it compares with Voluum and RedTrack.