Affiliate Attribution Mismatch: Diagnosing iGaming Discrepancies (2026)

An affiliate attribution mismatch is a gap between the players and revenue an affiliate system credits to a partner and what the gaming platform records for those same players. In iGaming every mismatch traces to exactly one of eight causes across three categories: identifiers, timing and definitions. The direction of the gap usually names the category before you run a single query. When the affiliate system shows fewer registrations than the platform attributes to partners, you have an identifier problem. When the two match early in the month and diverge later, you have a timing problem. When they differ by a consistent percentage every period, you have a definition problem. This guide gives the diagnosis table that maps each symptom to its cause and fix, then covers reconciliation with an agreed variance tolerance and the decision on who owns the NGR figure.

• Diagnose in order: identifier problems first, then timing problems, then definition problems, because a definition check run while an identifier defect is open wastes days
• A consistent percentage gap every period is a definition mismatch; a gap that grows through the month is restatement timing
• Fewer attributed registrations on the affiliate side almost always means a click ID that failed to bind at registration on one device or market path
• More first deposits on the affiliate side than the platform reports means duplicate events from retries sent without an idempotency key
• Counts that match while values differ is a deposit-amount definition gap: gross versus net of reversals or bonus
• NGR and GGR are not interchangeable, and an agreement naming one while the feed delivers the other produces a dispute in the first RevShare cycle
• Reconciliation is only a control if the variance tolerance is agreed in advance and set per dimension, not as one global figure
• Unattributed registration history is not recoverable, so identifier defects cost more the longer they run undiscovered
• Licensees under MGA, UKGC, GGL and ADM are accountable for which partner acquired which player, so a retained reconciliation history is a compliance artefact as well as a commercial one

Why Two Systems Disagree in the First Place

Two systems disagree because attribution is split across a system boundary. The affiliate system issues the click ID and owns the commission logic; the gaming platform creates the player ID and owns the revenue inputs. Between those two systems sit a registration binding, a set of postbacks and a revenue feed, and a discrepancy is simply a place where the two sides recorded the same underlying event differently or one side did not record it at all. This is why the fix is almost never to adjust a number until the two agree. The number is a symptom. The cause is a specific handoff that is dropping, duplicating, mistiming or redefining an event, and only fixing that handoff stops the mismatch from returning next period.

The categories are ranked by recoverability, which is why the diagnosis order matters. Identifier problems are the most damaging because unattributed history cannot be reconstructed: a registration that completed without a click ID bound to it is permanently organic. Timing problems are recoverable, because late, duplicate and out-of-order events can be replayed or de-duplicated from retained data. Definition problems are the cheapest to fix once found, because the data is correct and only the interpretation is wrong. Investigating a definition gap before ruling out an identifier defect means you may spend days reconciling numbers that were never going to agree, so always clear the identifier layer first.

The Attribution Mismatch Diagnosis Table

Eight symptoms map to eight likely causes across three categories, and the table below pairs each symptom with the diagnostic to run and the fix. Read the symptom column against your own reconciliation output, then run the named diagnostic before touching any figure. The ordering of the rows is the order to work them: identifier rows first, timing rows next, definition and fraud rows last. A symptom that matches more than one row is worked top down, because the higher rows are both more common and more damaging when left open.

Identifier Mismatches: When the Click ID Never Bound

An identifier mismatch is the most damaging of the three failures, common and expensive at once, because the lost attribution cannot be recovered. The signature is a registration count that is lower on the affiliate side than the platform's partner-attributed total, and the diagnostic is always the same: segment the unattributed registration rate by device type, market, brand and landing page. One segment will stand out. In practice it is usually an app registration flow deployed without the click ID parameter, or a market-specific landing page pushed live without the tracking script, so a whole class of players registers looking organic while the partner who drove them sees nothing.

The reason to instrument binding as a live metric rather than discovering it at reconciliation is purely economic. A binding defect found within a day is an engineering ticket on a single deploy. The same defect found at month end is a partner relationship problem, a commission adjustment negotiation and a block of players that are unattributed forever. Track the proportion of new registrations arriving with a bound click ID, segmented the same way, and alert when a segment leaves its normal band. Most operators who add this monitoring find at least one systematically failing path they did not know existed, and the value of finding it is proportional to how quickly you find it.

Timing Mismatches: Duplicates, Late Events and Restatement

A timing mismatch is a recoverable defect, which changes how you treat it: these are design gaps rather than lost data. A duplicate first deposit is the classic case. Without an idempotency key on the deposit postback, a transient network failure and its automatic retry deliver the same event twice, and the affiliate system counts a second first-time deposit that never happened, which inflates CPA. The diagnostic is to group deposit events by player ID and timestamp proximity and look for near-identical pairs; the fix is an idempotency key going forward and a de-duplication pass over the affected history.

Restatement is the timing mismatch that fools operators into chasing a definition problem. NGR that matches in the first week and drifts apart by month end is usually not a calculation difference at all; it is the gaming platform revising figures after the affiliate period has closed, as chargebacks, reversals and bonus adjustments settle. The way to confirm it is to pull the same closed period on two different dates and measure how much it moved. Once you know the typical post-close movement, publish a restatement calendar so partners expect it, and treat post-close changes as named correction lines rather than silently editing a number a partner has already seen, because a visible adjustment is tolerated where a changed number reads as a breach.

Definition Mismatches: NGR, GGR and the Deduction Stack

Definition mismatches produce the cleanest signature of all: a gap that is a consistent percentage every single period. That consistency is the tell, because a real data defect is noisy while a definition difference is arithmetically stable. The most common version is an affiliate agreement that pays on NGR while the feed delivers GGR, or the reverse, and the gap between the two is the entire deduction stack: bonus cost, free bets, payment processing fees, gaming duty, jackpot contributions and provider fees. On a typical casino programme that stack is large enough that a partner who expected one base and was paid on the other will treat the difference as a breach rather than a misunderstanding.

The diagnostic is to recompute NGR from the itemised deductions and compare it against the figure the affiliate system used, then confirm that the affiliate agreement names the same base the feed delivers. This is where the fix is contractual as much as technical: align the feed to the definition named in the agreement, document the deduction stack explicitly, and reconcile a full period before the next payout. Getting the definition written down once removes an entire class of recurring dispute, which is why it belongs in the integration contract rather than in a support thread.

Reconciliation and Variance Tolerance

Reconciliation is the only control that proves attribution is working, and it earns that status only when the variance tolerance is agreed in advance. A tolerance set after seeing the result is not a control; it is a rationalisation. Run the reconciliation before every payout rather than after every complaint, comparing affiliate-system figures against the gaming platform's own figures on four dimensions: registration count, first-deposit count, deposit value and NGR, each sliced by brand, market and period. Treat any variance outside tolerance as a blocker on that payout and require an explanation rather than an adjustment, because an adjustment hides the cause while an explanation exposes it.

Set the tolerance per dimension, because the dimensions behave differently and a single global figure disables the control where it works best. Registration and first-deposit counts are discrete events with clear definitions and should reconcile almost exactly; a variance above a fraction of a percent there is an identifier or duplication defect, not noise. Deposit value and NGR legitimately carry more movement from currency conversion timing, reversals and restatement, so a wider tolerance is appropriate provided the drivers are named. An operator who tolerates a two percent gap on registration counts because the same tolerance was set for NGR has effectively switched off the control on the dimension where a gap is most diagnostic.

Who Owns the NGR Figure

Platforms cannot share NGR authority with the affiliate system: only one system can be authoritative, and choosing which is a decision, not a default. The gaming platform holds the inputs: gross gaming revenue and the deductions for bonus cost, free bets, processing fees, gaming duty, jackpot contributions and provider fees. The affiliate system holds the commission logic: rate structure, tiering, qualification rules and negative carryover. If both compute NGR independently and no one is authoritative, the programme is guaranteed a recurring variance with no defined path to resolve it, which is the single most common self-inflicted mismatch in iGaming affiliate operations.

Platform-authoritative means the platform delivers the net figure and the affiliate system applies commission logic only. Finance and affiliate figures agree by construction, but the affiliate team cannot explain a number it did not compute, so partner queries route back to the platform. Affiliate-system-authoritative means the platform delivers GGR plus itemised deductions and the affiliate system derives NGR, which is transparent and auditable but depends on a complete and timely deduction feed or the derived figure drifts from finance. Whichever you pick, write down which system wins, how the other reconciles to it, and who is permitted to correct a divergence. The absence of that written authority is itself a cause of mismatch, because two correct systems with no tiebreaker will disagree the moment a manual correction is made on one side.

A Reconciliation and Diagnosis Checklist

Six steps take a suspected mismatch from symptom to root cause without wasted effort. Run them in order, because each assumes the previous layer is clean, and stop at the step that reproduces your symptom rather than completing all six every time.

1. Measure the unattributed registration rate segmented by device, market, brand and landing page, and flag any segment that differs sharply from the others as the first suspect.
2. Reconcile a single day of registrations, first deposits and deposit values line by line against the gaming platform's own report, rather than comparing period totals.
3. Group deposit events by player ID and timestamp proximity to detect duplicates from retries, and confirm every postback carries an idempotency key.
4. Recompute NGR from the itemised deductions, compare it against the affiliate-system figure, and confirm the affiliate agreement names the base the feed delivers.
5. Pull the same closed period on two different dates to quantify restatement, and establish the typical size and timing of post-close movement.
6. Check the fraud surface: self-referral identifier matches, multi-account clusters inside single partners, and high qualification rates paired with low player lifetime value.

Methodology and Review Schedule

This guide draws on three inputs: Track360 integration experience reconciling affiliate systems against iGaming back ends, recurring failure patterns from operator reconciliation exercises, and regulatory guidance from the MGA, UKGC, GGL and ADM. Those regulators hold licensees accountable for which partner acquired which player, so a retained reconciliation history is a compliance artefact as well as a commercial one. The claim that eight causes account for the large majority of mismatches is an engineering generalisation from observed integrations offered as a diagnostic aid, not a measured industry statistic. Track360 sells a dedicated affiliate platform, so the system boundary described here is one the company has a commercial interest in; the honest framing is that a platform-bundled affiliate module has no boundary to cross and avoids most of these mismatches, and the trade for accepting the boundary is coverage across brands and back ends, portability and control.

Review cadence is quarterly. This page is re-examined every three months against changes in tracking technology, platform integration patterns and regulatory expectations in MGA, UKGC, GGL and ADM markets, with the updated date revised on any material change. Operators encountering a mismatch cause not represented in the diagnosis table are encouraged to report it so it can be added at the next review.