Cross-platform identity: account linking done right

Most mobile games have, until recently, gotten away with a fairly loose concept of player identity. The platform account (Apple ID, Google Play account) handled the basics — what device the player was on, what they'd purchased through the in-app store, who got billed for what. Studios layered their own player_id on top, mostly for analytics and progression saves. The two systems were broadly aligned because almost every interaction happened inside the platform's walled garden.

The 2026 monetisation stack has broken that alignment. Web shops put a real payment transaction outside the platform. Subscriptions need to track entitlement across devices. Rewarded ad networks need to attribute users without compromising privacy. Each of these channels demands a player identity that's resolvable across contexts the platform account can't see. Studios that haven't built that identity layer end up with players who buy something on the web that never appears in their game, or with entitlement gaps when a player switches devices, or with attribution holes that make their measurement unreliable.

Getting account linking right isn't optional anymore. It's the foundation underneath every diversified monetisation strategy.

What a unified identity actually needs to do

The minimum capability is that the same player produces the same identifier across every channel that touches them. The web shop knows the same player_id the game knows. The subscription system knows the same player_id the ad network knows. When the player is referenced in any system, the reference resolves to the same canonical identity.

This sounds simple. The complications come from the directions the linking can fail. A player who buys on the web before linking has a transaction that needs to find a home when they later link. A player who plays on two devices needs both devices to resolve to the same identity. A player who lost their device needs to be able to recover their identity on a new one. A player who shares a device with a family member needs the system to keep their identity separate.

Each of these scenarios is common enough that they collectively account for a significant share of the support volume in any game with a meaningful player base. Getting the architecture right means making each scenario resolve cleanly — not just at the happy-path level but at the edges.

Anchoring identity to something durable

The first design decision is what the identity anchors to. A few options exist, with different tradeoffs.

Device-anchored identity uses something derived from the device — the platform account, the advertising identifier, a hardware fingerprint. It's easy to set up and requires no player action. It fails when the player changes devices, when the device identifier rotates (which iOS and Android both increasingly do), or when multiple players share a device.

Game-account-anchored identity uses an account the player explicitly created in the game — typically tied to an email address or social login. It's robust across devices and persistent across identifier rotation, but it requires the player to actively create the account at some point, which is friction.

Platform-account-anchored identity uses the platform's account system as the authoritative identity. It's robust within the platform, but it breaks when the player interacts with the game on the web, where the platform isn't involved.

What works in 2026 is a layered approach where device-anchored identity is the default for first-session continuity, and an explicit game account becomes the canonical identity once the player has reason to create one — typically the first purchase, the first cross-device session, or the first web shop visit. The system handles both kinds of identity simultaneously, with clear rules for migrating device-anchored progress into a game account when one is created.

The transaction-on-an-unknown-account problem

The hardest scenario in account linking is the player who buys on the web shop without first linking their game account. The transaction is real, the payment cleared, but the system doesn't know which player_id to credit.

The naive solution is to require account creation before any web purchase. This works structurally but produces a measurable drop in web shop conversion, because every additional step before payment costs you transactions.

The better solution is to capture enough information at the web purchase to defer the linking. The player provides an email or a player tag in the game; the purchase is held in a pending state; when the player later logs into the game with the same email or surfaces the tag, the purchase resolves automatically. The player experiences a slight delay between paying and seeing the items credited, but doesn't experience a hard friction wall before paying.

The implementation requires careful handling of edge cases: pending purchases that never get claimed, claims that don't match any in-game identity, claims that match multiple identities. Each of these needs an explicit resolution path, with timeouts and audit trails. Studios who build the happy path and assume the edges are rare find out they're not.

Multi-device and recovery

A player on a phone and a tablet is a single player who wants both devices to reflect the same progression and entitlements. A player who lost their phone needs to recover their identity on a new device.

The mechanism is the same: the game account is the canonical identity, and devices link to that account. The first device a player uses generates a device-anchored identity that becomes the canonical identity until or unless they create a game account. Once they do, the game account becomes canonical, and additional devices link to it.

Recovery works the same way. A player who lost their device sets up a new one, logs into their game account, and the new device picks up the entitlements and progression associated with that account. The platform-account-level state on the lost device is gone (Apple or Google handles that side), but the game-account-level state persists.

The failure mode here is studios who never properly separate the device-anchored and game-account-anchored identities. They keep all entitlement state on the device, with the game account as a backup; when the device is lost, the player can sign in but their progress is incomplete because some entitlements were only ever device-side. The right architecture treats the device as a presentation layer for state that lives in the account, not as the authoritative source.

Shared devices and family use

A device that's used by multiple players is more common than studios assume — particularly in markets where one phone is shared in a household. A game that conflates "this device" with "this player" produces strange results when two family members both play: progress gets confused, purchases get credited to the wrong player, and the system's behaviour becomes unpredictable to the people using it.

The right pattern is explicit account switching. The device knows multiple game accounts; the player selects which one is active at the start of a session. Each account has its own state, and the device doesn't store player-specific state outside the account scope.

This adds a small friction at session start, which is usually acceptable for the case it solves. Players who don't share devices don't notice it; players who do share devices experience the system working correctly instead of confusingly. The friction is paying for clarity that the alternative architecture doesn't deliver.

Privacy and the unified identity

Building a unified identity that crosses platforms also creates a unified record of player behaviour across those platforms. That data is more sensitive than any single-channel record, and it's also more useful for measurement and personalisation. The tradeoff is real and worth being deliberate about.

The defensible position is that the unified identity stores only what the studio needs to deliver service to that player — entitlements, progress, account-tier preferences. Behavioural data tied to the identity should be governed by the same privacy rules the studio applies to any per-player data, with appropriate consent flows and the ability for the player to request deletion or export.

Studios who use the unified identity to build aggressive behavioural profiles that follow the player across channels need to ensure the consent and disclosure layer supports that. The regulatory direction in 2026 is increasingly toward player control over cross-channel data, and identity systems built without that control in mind become liabilities as those regulations mature.

See how we approach player identity across channels →

Account linking used to be a feature studios could put off until they hit problems. In 2026 it's foundational infrastructure that determines whether your monetisation stack actually works as a stack or whether each channel produces isolated transactions that the other channels can't see. Getting it right early is much easier than retrofitting it after the channels are already live.

Talk to us about identity infrastructure for diversified monetisation →