Affiliate Tracking During a Platform Migration: Data Integrity (2026)

Three failures break affiliate attribution during a platform migration, and each surfaces on a different clock. Click IDs in flight break within hours of cutover, player-ID continuity breaks within days, and historical NGR baselines break silently and surface months later in year-on-year reporting. Because the three failures appear at different times, a migration that looks clean in its first week can still be quietly corrupting attribution that nobody notices until an annual review or a partner dispute. The purpose of this guide is to make all three failures visible before cutover, protect against each with a specific control, and give you a reconciliation method that proves to partners there was zero attribution discrepancy across the switch.

• A migration breaks attribution in 3 places at once: click IDs in flight at cutover, player-ID continuity across old and new identifiers, and historical NGR baselines used for comparison
• The old-to-new player-ID mapping table is the single most important migration artefact, and it must be built and retained before cutover, because it cannot be reconstructed reliably afterwards
• Click IDs referring visitors who click before cutover but register after it are lost unless the new registration flow carries the same parameter handling as the old one
• A parallel run, where both systems receive events for an overlap window, is the only way to compare old and new attribution on identical live traffic before committing
• A changed deduction stack alters the effective NGR even when nothing about the commission rate changes, and partners experience that as an unannounced rate cut
• Negative carryover balances and pending qualification progress are partner-owned state that must be transferred explicitly, not recreated from a fresh start
• Reconciliation before and after cutover, on the same agreed variance tolerance, is what converts a claim of zero discrepancy into a demonstrable one
• Licensees under the MGA, UKGC, GGL and ADM remain accountable for affiliate acquisition records through a migration, so the audit trail cannot go dark across the switch

The Three Things That Break, and When

Three failures surface on three separate timelines, so none of them coincides with the cutover event that caused it. A click ID in flight is lost within hours, when a visitor who clicked yesterday registers today on a new flow that does not recognise the parameter. Player-ID continuity breaks within days, once existing players start depositing and their revenue no longer maps to the partner who acquired them. The deduction stack and historical baseline break slowest of all, first appearing in the RevShare cycle after cutover and then again, more expensively, in annual reporting. Sequencing your protections to those clocks matters more than treating the migration as a single event.

The Player-ID Mapping Table Is the Whole Game

The old-to-new player-ID mapping table is the artefact that determines whether attribution survives, and it has one property that makes it unforgiving: it can only be built while both identifier spaces exist at once. A new gaming platform issues its own player identifiers, and unless you capture the correspondence between each old ID and its new one during migration, there is no later query that reconstructs it, because the shared attribute that linked them may not survive the move either. Build the table keyed on a stable business attribute such as a verified account identity, not on export row order or a sequence that the new platform reassigns.

Retain the mapping as production data, not as a throwaway migration script output. The affiliate system needs it to translate every incoming event that references a new player ID back to the partner binding established under the old ID, for as long as those players remain active and generate RevShare. Treat a player who appears in deposit events but is absent from the mapping table as a migration defect that blocks reconciliation, not as a new organic player, because misclassifying migrated players as organic is the exact mechanism by which a partner's earned revenue silently disappears after a cutover.

Pre-Migration Data-Integrity Checklist

Nine steps protect attribution through a migration, run in order over the weeks before cutover rather than in the cutover window itself. Each step assumes the previous one is complete, because a parallel run is meaningless if the mapping table is not built, and a reconciliation is meaningless if the parallel run has not produced comparable data. Operators who compress these into cutover weekend discover the defects live, in front of partners, which is the outcome the sequence exists to prevent.

1. Freeze the contract: document, for every partner, the current commission model, rate, base (GGR or NGR), attribution window, qualification rules and negative-carryover balance, so there is an agreed pre-migration state to reconcile against.
2. Build the old-to-new player-ID mapping table keyed on a stable identity attribute, and validate that every active player with attribution history has exactly one mapped new identifier.
3. Export the authoritative partner-to-player bindings from whichever system owns them, and confirm the count matches the mapping table before importing them into the new environment.
4. Deploy identical click-ID parameter handling on the new registration and app flows, then trace a live test referral end to end through the new flow to prove the binding fires.
5. Recompute the previous full month's NGR under both the old and new deduction stacks, quantify the per-partner delta, and decide how any difference is disclosed before it reaches a statement.
6. Run both systems in parallel over an agreed overlap window, delivering the same live events to each, and hold negative-carryover balances frozen for the duration.
7. Reconcile the parallel-run data on registration count, first-deposit count, deposit value and NGR, sliced by partner, brand and market, and resolve every variance above tolerance before cutover.
8. Transfer negative-carryover balances and pending qualification progress partner by partner, with written confirmation from each partner that their opening balance on the new system is correct.
9. Cut over only after every reconciliation dimension is within tolerance, then re-run the same reconciliation on the first post-cutover period to prove continuity.

Parallel Run: Comparing Old and New on Live Traffic

A parallel run is the only test that exercises old and new attribution on identical live traffic, and it is worth the operational cost because no synthetic test reproduces the messy reality of real referrals. During the overlap window both the old and new systems receive the same live event stream, each produces its own attribution, and the two are compared continuously rather than at a single checkpoint. The value is not in the new system working in isolation, which a staging test already shows, but in the two systems agreeing on the same live players, deposits and NGR, because agreement on live data is the only evidence that the migration preserved attribution rather than merely reproducing it approximately.

Decide in advance what a parallel-run divergence means and who acts on it. A player attributed to a partner on the old system but organic on the new one points to a click-ID or mapping defect; a deposit value that differs between the two points to a definition or currency-timing difference; an NGR gap points to the deduction stack. Freeze partner-facing balances during the window so that neither system pays on data that is still being validated, and treat the parallel run as complete only when divergence sits inside the agreed tolerance across every dimension for a full settlement period, not merely for a quiet afternoon of traffic.

Proving Zero Partner-Facing Discrepancy

The only deliverable that protects partner trust is a reconciliation that demonstrates zero discrepancy, not an assurance that offers one. Run the same reconciliation report immediately before and immediately after cutover, on the same four dimensions and the same variance tolerance, and share the result with partners as the migration record. Registration and first-deposit counts should reconcile almost exactly across the boundary, because they are discrete events; deposit value and NGR carry legitimate movement from currency timing and restatement, so a wider tolerance is appropriate provided the drivers are named rather than waved away. A partner who receives a before-and-after reconciliation showing their numbers held is a partner who does not open a dispute.

This record also discharges a compliance obligation that a migration puts at risk. Licensees under the Malta Gaming Authority and the UK Gambling Commission remain 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 the audit trail linking partner to player cannot go dark across a cutover. A retained mapping table plus the before-and-after reconciliation is the artefact that answers which partner acquired which player, under which licence, across the migration boundary, and assembling it during the migration costs a fraction of reconstructing it later under regulatory or partner pressure.

Methodology and Review Schedule

Three inputs build this guide. The first is Track360 experience migrating operators between gaming platforms and between affiliate systems. The second is the failure patterns observed in reconciliation exercises across those migrations. The third is regulatory guidance from the Malta Gaming Authority, the UK Gambling Commission, Germany's GGL and Italy's ADM on licensee accountability for affiliate acquisition through operational change. The claim that a migration breaks attribution in exactly three places is a structural framing drawn from observed migrations rather than a measured statistic, offered as a way to allocate attention across the cutover rather than as a precise count.

Track360 publishes this page and sells a dedicated affiliate platform, so a migration onto or off a separate affiliate system is a scenario we have a commercial interest in. The honest framing is that a portable affiliate system is what makes a gaming-platform migration survivable at all, because the partner bindings, balances and history live on a system that does not move when the gaming platform changes; an operator whose affiliate module is bundled into the gaming platform migrates all of that state at once, with far less room for a parallel run. That trade-off should be weighed on its merits rather than assumed. Review cadence is quarterly, and the updated date is revised whenever a material change is made.