Affiliate Attribution Across iGaming Platforms (2026)

Affiliate attribution in iGaming is a chain of 4 identifiers crossing a system boundary, and the chain is only as strong as the weakest handoff. The click ID is issued at first touch and must survive until registration; the player ID is created by the gaming platform and must be bound to that click ID; deposit events must reference the player ID and reach the affiliate system reliably; and the NGR figure that RevShare is calculated on must come from a source both sides agree on. Every attribution discrepancy an operator will ever investigate traces to exactly one of those four handoffs. This guide maps the full data flow, gives a diagnosis table for the eight most common mismatch causes, and covers what breaks during a platform migration.

• The click ID must be persisted server-side, not only in a browser cookie, or cross-device and delayed registrations will orphan regardless of using S2S postbacks downstream
• Binding the click ID to the player ID at registration is the only irreversible step: if it does not happen, no later event can recover the attribution
• Deposit postbacks should carry player ID, brand, amount, currency, payment method and timestamp, with an idempotency key so retries cannot double-count
• NGR calculation ownership is a decision, not a default: the gaming platform holds the inputs, the affiliate system holds the commission logic, and only one can be authoritative
• GGR and NGR are not interchangeable, and an affiliate agreement that names one while the feed delivers the other produces a dispute in the first RevShare cycle
• Reconciliation with an agreed variance tolerance is the only control that proves attribution is working; without it, discrepancies are found by partners rather than by you
• Late events, duplicate events and out-of-order events are normal at scale and must be designed for, not treated as incidents
• Attribution windows, qualification rules and negative carryover all interact: a change to one silently changes the effective value of the others
• A gaming platform migration breaks attribution in 3 places at once: click IDs in flight, player ID continuity, and historical NGR comparability

The Attribution Data Flow, Step by Step

Seven stages carry an affiliate referral from a click to a paid commission, and each stage has an owning system, a required payload, and a specific failure mode. The table below is the reference data flow for an iGaming operator whose affiliate system is separate from the gaming platform. Read it as a contract between two systems: everything that goes wrong later is a stage where the payload was underspecified or the ownership was ambiguous.

Two properties of this chain are worth internalising before any implementation detail. The first is that the stages are not equally recoverable: stages 4 through 7 can be replayed, corrected or recomputed from retained data, while stage 3 cannot. A registration that completes without a click ID bound to it is permanently unattributed, so engineering attention should be allocated in inverse proportion to recoverability rather than evenly across the chain. The second is that each stage crosses an organisational boundary as well as a technical one, with marketing owning stage 1, engineering owning stages 2 to 5, finance owning stage 6 and affiliate operations owning stage 7. Most integration defects sit exactly where those ownership boundaries meet.

Where the Click ID Lives and How Long It Survives

Click ID persistence is the design decision that determines 80% of an operator's attribution quality, and it is made once at implementation. A click ID stored only in a browser cookie survives exactly as long as that browser keeps it, which in practice means it does not survive a switch from mobile web to app, a registration completed days later on a different device, or a browser that restricts third-party and long-lived storage. Using server-to-server postbacks downstream does not fix this, because the identifier the postback needs was already lost upstream.

The durable pattern is to capture the click ID at landing, write it server-side against a session or first-party identifier that your own systems control, and carry it into the registration request rather than reading it back from the browser. Where the operator runs an app, the click ID should be passed through the same deferred-link mechanism the app already uses for other campaigns, and the app registration call should include it explicitly. Add a fallback: when a registration arrives without a click ID, capture whatever contextual signals you do hold, such as landing page, referrer and market, so that unattributed volume can at least be diagnosed rather than merely counted.

Attribution window length interacts with persistence and is often set without reference to it. A 90-day attribution window is meaningless if the click ID reliably disappears after 7 days, and an operator publishing the longer window in its affiliate terms is promising something the implementation cannot deliver. Measure the actual survival curve of your click IDs before setting the window, then publish a window you can honour. Geo-targeting adds a further wrinkle: partners driving traffic across markets need the market recorded at click time, because a player who registers under a different market than they clicked from will otherwise be attributed against the wrong rate card.

Binding the Player ID at Registration

Registration is the only irreversible stage in the attribution chain, which is why it deserves disproportionate engineering attention. Once a player account is created without a click ID bound to it, no downstream system can recover the link: the deposit event will carry a player ID the affiliate system has never seen, and the player will look organic forever. Every other failure in the chain is recoverable by replaying events or correcting data; this one is not.

Instrument the binding as a first-class metric rather than as a log line. Track the proportion of new registrations arriving with a bound click ID, segmented by device type, market, brand and traffic source, and alert when any segment moves outside its normal band. Most operators who monitor this discover at least one path where binding fails systematically, typically an app registration flow or a market-specific landing page that was deployed without the parameter. Finding that within a day is an engineering ticket; finding it at month end is a partner relationship problem and a commission adjustment negotiation.

Decide explicitly which system is authoritative on the partner-to-player link, because both will hold a version of it. If the gaming platform stores an affiliate reference on the player record and the affiliate system stores its own binding, the two can diverge through manual corrections, support actions, or a re-registration, and without a stated authority there is no defined way to resolve the difference. Write down which system wins, how the other is corrected, and who is permitted to make that correction. This also determines the difficulty of a future platform migration, since a partner-to-player link that exists only inside the gaming platform moves with the platform and has to be reconstructed on the other side.

Registration timing carries a second-order effect on commission that is easy to miss. Qualification rules and attribution windows are usually measured from registration or from first deposit, so a registration event that arrives late, even though it is bound correctly, can push a player outside a qualification window they should have met. Design the rules to evaluate against the event's own timestamp rather than its arrival time, and confirm during testing that a deliberately delayed registration still qualifies. This is the kind of defect that produces a small, persistent, unexplained shortfall in a partner's conversions, which is exactly the pattern that erodes trust without ever generating a clear incident.

Deposit Postbacks: Timing, Retries and Idempotency

Three properties make deposit postbacks safe at scale: idempotency, retry with backoff, and an explicit position on event ordering. Idempotency means every event carries a stable key so that a retried delivery cannot create a second first-time deposit; without it, a transient network failure and its retry become a double CPA. Retry with backoff means a temporarily unavailable affiliate system does not permanently lose events. And ordering matters because a deposit event arriving before its registration event will be rejected unless the receiving system is designed to hold and re-process it.

The specification detail that most often gets missed is what a deposit amount actually represents. Gross deposit, net of failed or reversed transactions, and net of bonus credit are three different numbers, and qualification rules written against one and fed by another will misfire in ways that are hard to spot because they are directionally plausible. State the definition in the integration contract, then verify it by reconciling a full month of deposit values against the platform's own report before the first CPA is paid. Payment method belongs in the payload too, because payment-method-adjusted commission and chargeback risk assessment both depend on it.

Who Owns the NGR Calculation

NGR calculation ownership is a decision that must be made explicitly, because the default is ambiguity and ambiguity is expensive. The gaming platform holds the inputs, which are the gross gaming revenue figure and the deductions for bonus cost, free bets, payment processing fees, gaming duty, jackpot contributions and provider fees. The affiliate system holds the commission logic, which is the rate structure, tiering, qualification rules and negative carryover. Only one of the two can be authoritative on the net figure, and whichever you choose, the other must reconcile to it rather than compute its own version in parallel.

Whichever model you choose, write down whether the affiliate agreement pays on GGR or NGR and make sure the feed delivers what the agreement names. This sounds trivial and is the most common contractual defect in iGaming affiliate programmes: a rate agreed against one base and a statement produced against another. The gap between the two is the deduction stack, and it is large enough that a partner who expected one and received the other will treat the difference as a breach rather than a misunderstanding.

Reconciliation: The Control That Proves Attribution Works

Reconciliation is the only control that proves attribution is working. It should run before every payout rather than after every complaint, using an agreed variance tolerance. The report compares affiliate-system figures against the gaming platform's own figures on four dimensions: registration count, first-deposit count, deposit value and NGR, sliced by brand, market and period. Set the tolerance in advance, because a tolerance agreed after seeing the result is not a control. Treat any variance outside tolerance as a blocker on that payout rather than a note for later, and require an explanation rather than an adjustment.

The reconciliation also serves a compliance purpose that is easy to overlook during implementation. Licensees under the Malta Gaming Authority and the UK Gambling Commission are accountable for how affiliates acquire players on their behalf, and locally licensed markets supervised by Germany's GGL and Italy's ADM impose their own reporting expectations, so an operator who cannot demonstrate which partner acquired which player, under which licence, and on what commercial terms is exposed on more than commercial grounds. A reconciliation report with a retained history is the artefact that answers that question, and building it at launch costs a fraction of reconstructing it under regulatory time pressure.

Set the tolerance per dimension rather than as one global figure, because the dimensions behave differently. Registration and first-deposit counts should reconcile almost exactly, since they are discrete events with clear definitions, and a variance above a fraction of a percent there indicates an identifier or duplication defect. Deposit value and NGR legitimately carry more movement because of currency conversion timing, reversals and restatement, so a wider tolerance is appropriate provided the drivers are named. An operator who tolerates a 2% gap on registration counts because the same tolerance applies to NGR has effectively disabled the control on the dimension where it works best.

How to Run an Attribution Audit: 7 Steps

Seven steps audit an existing attribution integration end to end in about 2 weeks. Run them in this order, because each step assumes the previous one is clean and diagnosing a definition problem while an identifier problem is still open wastes days. Operators who have never audited an integration typically find at least one silent defect, most often a device or market path where click IDs do not bind.

1. Day 1: measure the unattributed registration rate, segmented by device type, market, brand and landing page. Any segment that differs sharply from the others is your first suspect.
2. Days 2 to 3: trace one real referral end to end through every system, capturing the click ID at each stage. Do this manually once before automating anything, because it surfaces payload gaps that aggregate reports hide.
3. Days 3 to 5: reconcile a single day of registrations, first deposits and deposit values line by line against the gaming platform's own report, rather than comparing totals.
4. Days 5 to 7: recompute NGR from the itemised deductions and compare it against the figure the affiliate system used, then confirm the affiliate agreement names the same base the feed delivers.
5. Days 7 to 9: pull the same closed period on two different dates to detect restatement, and establish how large the post-close movement typically is.
6. Days 9 to 11: test event handling deliberately by replaying a duplicate event, an out-of-order event and a late event, and confirm each is handled as designed rather than silently accepted.
7. Days 11 to 14: check the fraud surface: self-referral matching, multi-account clusters within single partners, and bonus abuse patterns visible as high qualification rates with low player lifetime value.

Diagnosing an Attribution Mismatch

Eight causes account for the large majority of attribution mismatches between an affiliate system and a gaming platform, and the direction of the discrepancy usually identifies which one you have. The table below maps each symptom to its likely cause, the diagnostic query to run, and the fix. Work it in order: identifier problems first, then timing problems, then definition problems, because a definition mismatch investigated before an identifier problem is ruled out wastes days.

Late, Duplicate and Out-of-Order Events

Three event anomalies are normal at scale and must be designed for rather than treated as incidents: late events, duplicate events, and out-of-order events. Any integration running real volume will see a deposit event arrive before its registration event, a retry deliver the same event twice, and a correction arrive for a period that has already been paid. A system that assumes clean ordering will produce silent errors under exactly the conditions where errors matter most, which is high traffic during a campaign peak.

• Idempotency keys on every event, so a retried delivery is recognised and discarded rather than processed twice
• A holding queue for events referencing an unknown player ID, with automatic re-processing once the registration arrives and an alert if it never does
• A defined late-event policy stating how long after a period closes an event can still affect that period, and how it is treated afterwards
• Named corrections rather than silent restatement, so a partner sees an adjustment line rather than a number that changed
• A replay capability that can re-deliver a date range of events after an outage, tested before you need it
• Monitoring on event volume by type and by source, since the fastest signal of a broken feed is a count that drops rather than an error that fires

Cross-Device Journeys and App Attribution

Cross-device journeys produce the single largest source of unattributed volume in iGaming affiliate programmes, and the problem is structural rather than fixable in the general case. A player who clicks an affiliate review on a phone, considers for 2 days, and registers on a desktop leaves no shared browser state between the two sessions, so attribution depends on whatever first-party identity you can establish across them. Operators overstate what is achievable here; the honest position is that a meaningful share of this volume will remain unattributed and both you and your partners should plan on that basis.

What is achievable is worth doing. Persist the click ID server-side so that a same-device delayed registration works reliably. Use your app's existing deferred deep-link mechanism to carry the click ID into app registrations rather than treating app traffic as a separate unattributed channel. Where a player authenticates on a second device, bind the earlier click ID at that point if your identity model supports it. And measure the residual honestly: publish your unattributed rate internally, watch it by segment, and treat a sudden change as an integration alarm rather than a market shift.

Be careful about how identity stitching interacts with your licensing obligations. Any technique that links sessions across devices uses personal or device data, and in markets supervised by the Malta Gaming Authority, the UK Gambling Commission, Germany's GGL and Italy's ADM the acceptable basis for that processing is a compliance question rather than an engineering preference. The pragmatic position most operators land on is to stitch only on identifiers the player has already provided through authentication or KYC, and to accept the unattributed residual rather than reaching for broader signals. That position is also more durable, since it does not depend on device signals that platform vendors continue to restrict.

What Breaks During a Gaming Platform Migration

Three things break during a gaming platform migration, and the third surfaces months later. Click IDs in flight are lost if the new platform's registration flow is deployed without the parameter handling; player ID continuity breaks if the new platform issues new identifiers without a mapping table to the old ones; and historical NGR comparability breaks if the new platform's deduction stack differs from the old one, which makes every year-on-year affiliate report misleading without anyone noticing.

Methodology and Review Schedule

Three inputs build this guide. They are Track360 integration experience connecting affiliate systems to iGaming platform back ends, the failure patterns observed in operator reconciliation exercises and migrations, and regulatory guidance from the Malta Gaming Authority, the UK Gambling Commission, Germany's GGL and Italy's ADM on licensee accountability for affiliate acquisition. The figure that click ID persistence determines roughly 80% of attribution quality is an engineering judgement from observed implementations rather than a measured industry statistic, and is offered as a prioritisation heuristic.

Track360 publishes this page and sells a dedicated affiliate platform, which means the boundary described here is one we have a commercial interest in. The honest framing is that this boundary is a cost: an operator running a platform-bundled affiliate module has no boundary to cross and therefore avoids most of the failure modes on this page. The reason operators accept the boundary is coverage across brands and back ends, portability, and control, and those benefits should be weighed against the integration burden described here rather than assumed.

Review cadence is quarterly. This page is re-examined every 3 months against changes in tracking technology, platform integration patterns, browser storage behaviour and regulatory expectations in MGA, UKGC, GGL and ADM markets, with the updated date revised whenever a material change is made. Operators encountering a mismatch cause not covered in the diagnosis table are encouraged to report it, and additions are made at the next quarterly review.