The FTD That Never Got Counted: Affiliate Tracking Explained

Every commission you earn depends on a sequence of handoffs completing without error. A visitor clicks your tracking link. The affiliate platform records the click, generates a unique identifier, and redirects the visitor to the operator with that identifier attached. The operator stores it, ties it to the account the player creates, and later fires events back to the platform when the player registers and deposits. Only then does an FTD land in your reports.

The chain matters because it is only as strong as its weakest handoff. A click that never gets an ID, an ID the operator drops during registration, or a deposit event that never fires all produce the same outcome: an untracked player. Untracked players are the purest form of lost revenue in this business, because you already paid for the traffic.

Vanity metrics hide these breaks. A dashboard full of clicks looks healthy while registrations quietly fail to attribute. The metric that exposes tracking health is the ratio between the events, not any single count.

• Click: recorded by your tracking platform, stamped with a unique ID
• Redirect: the visitor lands on the operator's page with your ID in the URL
• Registration: the operator binds your ID to the new player account
• FTD: the first real-money deposit fires an event back to your platform
• Commission: the attributed FTD enters your deal's payment logic

A click ID is a unique token generated per click, passed to the operator in the tracking URL, and echoed back in every subsequent event. It is the only durable connection between your traffic and the operator's player database. Sub-IDs and campaign parameters describe where the click came from; the click ID proves the click happened and belongs to you.

Because the ID is generated per click, it survives things that cookies do not: the player switching devices matters, but within a single session the ID rides the redirect itself, not the browser's storage. This is why serious programs attribute on click ID rather than on cookies alone, and why the ID must be stored server-side by the operator at registration, not just floated in the URL.

The practical test is simple. Open your own tracking link, follow the redirect, and confirm the ID parameter arrives intact on the operator's landing page. If a redirect in the middle strips query parameters, attribution is dead before the player ever sees a signup form. This failure is invisible in click counts and fatal to everything downstream.

A pixel is a snippet that fires in the player's browser when a conversion page loads. An S2S postback is an HTTP request the operator's server sends directly to your tracking platform's server, carrying the click ID and the event type. Both report conversions. Only one of them is reliable.

Pixels fail for reasons that have nothing to do with whether the conversion happened: ad blockers strip them, browsers restrict third-party cookies and storage, the player closes the tab before the confirmation page renders, or the operator's page simply never loads the snippet. Every one of those failures is a conversion that occurred and was never reported. Postbacks bypass the browser entirely. If the operator's system records a deposit, the server fires the event, regardless of what the player's device is doing.

In iGaming, where the events that pay you happen days after the click and inside the operator's cashier rather than on a public web page, pixels are structurally unfit. Treat S2S postbacks as the baseline requirement for any program you work with, and treat a pixel-only program as a program that will underreport your conversions.

• Pixels execute client-side and depend on the player's browser cooperating
• Postbacks execute server-to-server and depend only on the operator's system
• Deposit events happen inside the cashier, where no pixel can fire
• A postback URL carries the click ID, event type, and often the amount
• If an operator cannot support postbacks, question everything else about their infrastructure

iGaming tracking is multi-event by nature. A click is not a conversion. A registration is not a conversion either, in revenue terms; it is a checkpoint. The event that moves money is the FTD, the first-time deposit, because it marks the moment a visitor became a real-money player. Deals are priced on FTDs for a reason: they are hard to fake at scale and they correlate with actual operator revenue.

You want every checkpoint reported as its own postback, not just the final one. Registration events let you compute click-to-registration and registration-to-FTD rates, and those two ratios diagnose problems that a single FTD number cannot. A healthy click-to-reg rate with a collapsed reg-to-FTD rate points at the operator's cashier or bonus terms. A collapsed click-to-reg rate points at your landing page, your geo targeting, or a broken redirect.

Some programs also fire qualified-deposit events, where the FTD only counts above a minimum amount, or after wagering thresholds. Read those definitions before you sign, because an FTD that does not meet the qualification never becomes a commission, and no tracking setup can fix a definition you agreed to.

• Click: proves traffic delivery, pays nothing by itself
• Registration: diagnostic checkpoint, occasionally paid in CPL-style deals
• FTD: the revenue event, the basis of CPA counts and revshare cohorts
• Qualified FTD: an FTD gated by minimum deposit or wagering conditions
• Ask for all events as separate postbacks, even when only FTDs are paid

Deduplication is the logic that ensures each real-world event is counted a single time. It sounds trivial and fails constantly. Operators retry failed postbacks, players double-submit registration forms, and network hiccups deliver the same event twice. Without dedup keys, your reports inflate; the moment the operator reconciles, the inflated numbers get clawed back and your forecast was fiction.

The inverse failure is worse. Overly aggressive dedup, usually keyed on the wrong field, silently drops legitimate events. If dedup keys on player ID and a player deposits, withdraws, and is later re-flagged in a migration, a second event with the same player ID can erase a real FTD. Correct dedup keys on a transaction-level identifier plus the event type, so one deposit equals one event, forever.

The operational habit that catches dedup problems is comparing your platform counts against the operator's affiliate program stats on a fixed cadence. The two systems will never match to the decimal on revshare, but FTD counts are integers. When integers disagree, one of the two systems is dropping or duplicating, and the discrepancy is a list of specific players you can dispute rather than a vague complaint.

Most tracking losses come from a short list of known failures. None of them announce themselves. All of them are detectable if you know what to look for, and every one costs real commission because the player converts either untracked or attributed to nobody.

The pattern across all of these is the same: the loss is silent, the operator has no incentive to hunt for it, and the burden of detection sits with you. An affiliate who monitors event ratios weekly catches these in days. An affiliate who only reads monthly payment reports catches them never.

• Stripped parameters: an intermediate redirect or link shortener drops the click ID before the operator's page loads
• Postback misconfiguration: the operator maps your events to the wrong URL or the wrong parameter names after a platform update on their side
• Landing page changes: the operator moves or retires the page your links point to, and the redirect chain 404s or lands on an untagged homepage
• Cross-device signups: the player clicks on mobile, registers later on desktop by typing the brand name, and attribution depends entirely on how long the operator persists your ID
• Geo mismatches: your link routes to a brand not licensed in the player's country, the operator blocks registration, and the click is spent
• Silent postback outages: the operator's event queue fails for a day, nothing is ever replayed, and that day's FTDs simply do not exist in your reports
• Wrong event mapping: registrations fire as FTDs or vice versa, corrupting both counts and your funnel ratios at once

You do not need the operator's cooperation to verify most of the chain. A disciplined self-test at link launch and on a recurring schedule catches the majority of failures before they cost a month of traffic.

Run the test from a clean browser session and, when possible, from the geo you are targeting via a VPN, because redirect behavior often differs by country. Follow the full chain: click your link, inspect the final URL for your click ID, complete a test registration where the program permits it, and confirm the registration postback arrives in your platform within the expected window. Where test registrations are not permitted, at minimum verify the redirect and parameter integrity, then watch your live event ratios for the first days of traffic.

Ratios are your alarm system. Establish a baseline click-to-registration rate per campaign, then alert on deviation rather than on absolute numbers. A campaign whose registration rate halves overnight has a broken link or a changed landing page far more often than it has worse traffic. Investigate the infrastructure before blaming the audience.

• At launch: click every link variant, confirm the click ID survives to the final page
• Weekly: compare FTD integers between your platform and each program's stats
• On any operator email about migrations or new landing pages: retest everything they touched
• Continuously: alert on click-to-reg and reg-to-FTD ratio drops per campaign
• Keep timestamped records of tests; they are your evidence in attribution disputes

Tracking is not a setup task, it is an operating discipline. The affiliates who keep their commissions treat every link as infrastructure with an owner, a test date, and a monitoring signal, the same way an engineer treats a production endpoint. The ones who lose commissions treat links as content, published once and forgotten.

The economics justify the discipline. Your cost per click is fixed the moment you buy or earn the traffic. Every percentage point of attribution loss is a direct haircut on revenue with zero offsetting savings. Recovering a single misattributed FTD on a decent CPA deal usually pays for more monitoring than most affiliates ever build. This is also why FTD-level visibility beats click dashboards: clicks tell you what you spent, attributed FTDs tell you what you keep.

Centralize it. When your links, postback logs, and per-program FTD counts live in one place, a discrepancy is a five-minute query instead of a spreadsheet archaeology project. That consolidation, more than any single technique in this guide, is what separates affiliates who catch leaks in days from those who discover them at payment time, when the dispute window has often already closed.