Cross-Device Affiliate Attribution in iGaming (2026)

Cross-device affiliate attribution is the problem of connecting one player's actions across separate devices when there is no shared browser state to carry the referral between them. The canonical iGaming journey is a click on an affiliate review on mobile web, a registration in the operator's app days later, and a first deposit on a desktop, and those three events happen in three storage contexts that do not natively know about each other. A cookie set on mobile web is invisible to the app and to the desktop browser, so an attribution model that relies on the click's browser state loses the referral at the first device change. Bridging the gap requires either a deterministic identifier that both events share or a probabilistic guess that both events came from the same person, and the difference between those two approaches is the difference between attribution you can defend to a partner and attribution you cannot. This guide covers both, why server-side click-ID persistence is the foundation for either, and how deep-link and app-install attribution close specific gaps.

• The cross-device journey is the single largest source of unattributed volume in iGaming affiliate programs, because click, registration and deposit routinely happen on different devices
• Deterministic matching links events through an identifier both share, such as a login or a persisted click ID, and it is accurate enough to pay commission on
• Probabilistic matching infers that two events came from the same person using signals such as IP, timing and device attributes, and it is a diagnostic aid rather than a payout basis
• A click ID stored only in a browser cookie does not survive a device change, so cookie-based attribution fails at exactly the moment cross-device begins
• Server-side click-ID persistence keeps the identifier under systems you control and lets it be carried into a registration on any device the player authenticates on
• Deferred deep links carry the click ID through an app install so an app registration is attributed to the web click that drove it
• Attribution windows must be set against the measured click-to-registration delay, because cross-device journeys are slower than same-device ones
• Any identity stitching across devices touches personal or device data, so the acceptable basis is a compliance question in MGA, UKGC and locally licensed markets

The Cross-Device Problem, Concretely

Four device paths break affiliate attribution, and naming them separately makes each one addressable. Mobile web to app is the most common: a player clicks an affiliate link in a mobile browser, then downloads and registers in the operator's app, where the browser cookie that held the click ID is unreachable. Mobile to desktop is the classic considered-purchase pattern: a player reads a review on a phone during the day and registers on a laptop that evening, with no shared storage between the two. App to desktop and desktop to app appear whenever a player who already has an account acts on a second device. Each of these breaks the same assumption, that the state set at click time is still readable at conversion time, and each requires the same fix, an identifier that lives somewhere both events can reach.

The reason this dominates unattributed volume in iGaming specifically is that the consideration period is long and the acquisition surface is device-fragmented. Affiliates drive discovery on content that is read on phones, while registration and deposit often happen later on whichever device the player trusts for payment. An operator that measures its unattributed registration rate by device path almost always finds that the cross-device paths are where attribution leaks, and the honest starting position is that a meaningful share of this volume will remain unattributed no matter how good the implementation. The goal is to recover the recoverable share deterministically and to size the residual honestly rather than to claim a solution that does not exist.

Deterministic vs Probabilistic Matching

Deterministic matching is the only method accurate enough to pay commission on, because it links two events through an identifier they demonstrably share. The shared identifier is usually a login the player uses on both devices or a click ID that was persisted server-side and carried into the registration. When it is present, the match is certain rather than inferred: the same click ID appears at click and at registration, or the same authenticated account appears on both devices, so the referral is attributed without guesswork. Deterministic matching is the target for every cross-device path, and most engineering effort should go into making the click ID survive and the login link fire rather than into inferring matches after the fact.

Probabilistic matching infers that two events came from the same person using signals such as IP address, approximate timing, and device or browser attributes. It fills gaps deterministic matching cannot reach, but it is a statistical guess, and in a regulated, money-moving context a guess is a poor basis for paying commission or resolving a partner dispute. IP-based matching in particular degrades badly on shared or mobile networks, where many players share an address, and privacy-driven restrictions on device signals continue to erode the inputs it depends on. Treat probabilistic matching as a diagnostic that helps you estimate the unattributed residual and spot where deterministic coverage is weak, not as a number you settle payouts against.

Why Server-Side Click-ID Persistence Beats Cookies

Server-side click-ID persistence is the foundation of durable cross-device attribution because it moves the identifier out of the one place a device change destroys it. A cookie lives in a single browser on a single device and is subject to expiry and storage restrictions, so a click ID held only in a cookie is gone the moment the player switches to the app or to a desktop. Persisting the click ID server-side, against a session or first-party identifier your own systems control, means the identifier survives independently of any one browser and can be attached to a registration request from the server rather than read back from the client. Using server-to-server postbacks downstream does not rescue a cookie-only design, because the identifier the postback needs was already lost upstream when the device changed.

The durable pattern is to capture the click ID at landing, write it server-side immediately, and carry it forward into whatever registration path the player takes, including the app. Add a fallback for registrations that arrive without a click ID: capture contextual signals such as landing page, referrer and market so that unattributed volume can be diagnosed by segment rather than merely counted. This fallback is where probabilistic signals earn their place, not to pay commission but to tell you which device path is leaking. Persistence also interacts with the attribution window: a 90-day window is meaningless if the underlying identifier reliably disappears after a device change, so measure the real survival of your click IDs and publish only a window you can honour.

Deep-Link and App-Install Attribution

A deferred deep link is the mechanism that connects a web click to an app registration after the install completes. When a player clicks an affiliate link on mobile web and does not yet have the app, a deferred deep link preserves the referral context, including the click ID, through the app-store install and into the first app session, so the app registration can be attributed to the click that drove it. Without this mechanism, app traffic becomes a separate, largely unattributed channel, and affiliates who drive installs are systematically under-credited because their contribution vanishes at the install boundary. The app registration call should include the click ID explicitly rather than relying on the app to rediscover it.

Treat app-install attribution as a first-class path with its own monitoring rather than an afterthought bolted onto web tracking. Instrument the proportion of app registrations that arrive with a bound click ID, segmented by campaign and source, and alert when it moves outside its normal band, because a broken deep-link configuration fails silently and shows up only as a quiet decline in one partner's attributed conversions. The most common defect is an app registration flow deployed without the parameter handling, which orphans every install-driven referral until someone notices the partner complaint. Finding that as an engineering alert within a day is cheap; finding it as a month-end dispute is a commission adjustment and a damaged partner relationship.

How to Audit Cross-Device Attribution: 6 Steps

Six steps audit cross-device attribution end to end and size the residual honestly. Run them in order, because each assumes the previous one is clean, and an operator who has never audited by device path almost always finds at least one path where the click ID does not survive.

1. Measure the unattributed registration rate segmented by device path: mobile web to app, mobile to desktop, app to desktop and same-device. The path that differs sharply is your first suspect.
2. Trace one real cross-device referral end to end, capturing the click ID at click, at registration and at deposit, before automating anything, because it surfaces the exact stage where the identifier is lost.
3. Confirm the click ID is persisted server-side at landing and read back into registration from the server rather than from a browser cookie.
4. Verify the deferred deep-link flow carries the click ID through an app install into the first app session, and that the app registration call includes it explicitly.
5. Compare the published attribution window against the measured click-to-registration delay distribution, and shorten the published window or extend persistence until they agree.
6. Confirm any cross-device identity stitching relies only on identifiers the player has provided through authentication or KYC, and document the basis for that processing.

Compliance and Identity Stitching

Operators must treat cross-device attribution and player-identity processing as one activity, so the compliance boundary is designed in rather than added later. Any technique that links sessions across devices uses personal or device data, and in markets supervised by the Malta Gaming Authority and the UK Gambling Commission the acceptable basis for that processing is a regulatory question rather than an engineering preference, with licensees remaining accountable for how affiliates acquire players on their behalf. The position most operators land on is to stitch identities only on identifiers the player has already provided through authentication or KYC, and to accept the unattributed residual rather than reaching for broader device signals. That position is also more durable technically, because it does not depend on fingerprinting inputs that platform vendors and privacy regimes continue to restrict, so a deterministic, login-anchored model both satisfies the regulator and outlasts the erosion of probabilistic signals.

Methodology and Review Schedule

Three inputs build this guide. The first is Track360 experience implementing cross-device tracking, deferred deep-linking and server-side click-ID persistence for iGaming operators. The second is the failure patterns observed when operators segment unattributed volume by device path. The third is regulatory guidance from the Malta Gaming Authority and the UK Gambling Commission on licensee accountability for affiliate acquisition. The claim that cross-device journeys are the single largest source of unattributed volume 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 affiliate tracking infrastructure, so it has a commercial interest in the topic; the honest framing is that a meaningful share of cross-device volume remains unattributed under any implementation, and the realistic goal is to recover the deterministically recoverable share and size the residual rather than to eliminate it. Review cadence is quarterly, re-examined against changes in browser and device signal availability, deep-linking behaviour and MGA and UKGC expectations, with the updated date revised on any material change.