Players often have multiple accounts across different games and platforms, but without a way to link those accounts, ad suppression, recommendations, and fraud signals cannot cross game boundaries. ID mapping merges fragmented account and device identifiers into a single unified identity per player. This page shows how to build an ID mapping solution for gaming using PolarDB for AI operators.
Use cases
ID mapping applies wherever a player appears under different identifiers across systems:
-
Cross-game ad suppression: A player gives a thumbs-down to an ad in Game A. Without ID mapping, the same ad reappears in Game B because there is no link between the two accounts. ID mapping associates both accounts to one player identity, so ad suppression carries across games.
-
Targeted marketing: Associate a player's behavior across games and devices to build a complete profile, enabling more accurate recommendations and promotions.
-
Fraud detection: Identify click fraud — one device cycling through multiple user IDs to exploit coupons or commissions, or one user ID jumping between devices to avoid bans.
-
User profile enrichment: Discover device and account relationships to fill in sparse user profiles, including inferring shared preferences across household members.
How it works
ID mapping builds a graph where each column value is a node. Two nodes are connected when they appear together in the same row of a data table — for example, a device_id and a user_id that co-occur in a login event. PolarDB for AI then computes connected subgraphs: all nodes reachable from one another are grouped under a single csg_id, which becomes the unified identity.
The workflow has three stages:
-
Create the initial graph — Load the first table as a graph feature using
CREATE FEATURE. -
Add more data — Merge additional tables into the graph using
UPDATE FEATURE. Repeat for each table. -
Generate the mapping table — Run a connected subgraph computation using
CREATE FEATUREwithfeature_class = 'connected_subgraph'.
All PolarDB for AI operators use the /*polar4ai*/ comment prefix.
Prerequisites
Before you begin, make sure you have:
-
A PolarDB for MySQL cluster with PolarDB for AI enabled
-
The following data tables loaded into the cluster:
-
user_info— user attribute information -
game_platform_info— game platform login records -
game_info— in-game account login records
-
ID types in gaming
Gaming data typically contains two categories of identifiers:
Account IDs — identifiers tied to a specific account:
-
Platform user ID and game account ID
-
Phone number and email address
Device IDs — identifiers tied to a physical device:
-
IMEI (International Mobile Equipment Identity)
-
IMSI (International Mobile Subscriber Identity)
-
OAID (Open Anonymous Device Identifier)
-
Android ID
-
IDFA (Identifier for Advertisers, iOS)
-
Google advertising ID
Build an ID mapping solution
Step 1: Understand the table schemas
This example uses three tables. Review the schemas before writing the SELECT statements in later steps — column names matter.
`user_info` — user attribute information:
| Column | Description | Example |
|---|---|---|
plat_user_id |
Platform user ID | 0b887f9e1e915XXXX |
phone_number |
Phone number | — |
email |
Email address | xxx@alibaba-inc.com |
device_id |
Primary device ID | 0b887fXXXX915e355 |
`game_platform_info` — game platform login records:
| Column | Description | Example |
|---|---|---|
device_id |
Device ID | 0b887f9e1e915XXXX |
android_id |
Android ID | 02bd2a91190c1a6406866302942f4XXXX |
oaid |
OAID | 106ed9425b12664364a06c51aXXXX |
ip |
IP address | 182.XX.XX.146 |
ts |
Timestamp | 1647137327 |
user_id |
Platform user ID | 447268XXXX |
`game_info` — in-game account login records:
| Column | Description | Example |
|---|---|---|
device_id |
Device ID | 0b887f9e1e915XXXX |
user_id |
Game account ID | 02bd2a91190c1a606866302942XXXX |
ipv4 |
IPv4 address | 182.XX.XX.146 |
ipv6 |
IPv6 address | 240e:337:1026:XXXX:XXXX:a26d:4a34:920d |
imei |
IMEI | 45ca53a497897c0b39f4373b0c14XXXX |
idfa |
IDFA (iOS) | 8301c9fcgg6a16fd3XXXX0e30e1854a78a |
googleid |
Google advertising ID | f09adce39gr564c7f178bd9ebf64b9XXXX |
android_id |
Android ID (changes after the device is flashed) | a9d26756755rtr7b8faf6b2e0b6d414XXXX |
oaid |
OAID | 4aad25ea19rtr769fe84cc46244b2aeXXXX |
timestamp |
Timestamp | 1647137327 |
Column name collisions to watch for:
Two types of collision can silently corrupt the graph if not handled in the SELECT statement:
| Collision type | Example | How to handle |
|---|---|---|
| Same concept, different column names | user_info.plat_user_id and game_platform_info.user_id both hold the platform user ID |
Alias to the same name: SELECT plat_user_id AS user_id |
| Same column name, different concepts | game_platform_info.user_id (platform user ID) vs game_info.user_id (game account ID) |
Alias to distinct names: SELECT user_id AS game_user_id |
Step 2: Create the initial graph feature
Load user_info as the starting graph. This creates a graph feature named oneID where plat_user_id (aliased to user_id) and device_id are connected nodes.
/*polar4ai*/CREATE FEATURE oneID WITH ( feature_class = 'graph',parameters=()) AS (SELECT plat_user_id as user_id, device_id FROM user_info)
Check whether the operation has finished:
/*polar4ai*/SHOW FEATURE oneID;
-
If
FeaturePathshowsFINISHED, proceed to the next step. -
If
FeaturePathshowsPlease wait for the feature calculation to finish, wait and check again.
Step 3: Merge game platform data
Once step 2 shows FINISHED, add game_platform_info to the graph. This links device identifiers (device_id, android_id, oaid, ip) to the platform user ID (user_id).
/*polar4ai*/UPDATE FEATURE oneID WITH (parameters=()) AS (SELECT device_id, android_id,oaid,ip,user_id FROM game_platform_info)
Check the status:
/*polar4ai*/SHOW FEATURE oneID;
Step 4: Merge in-game account data
Once step 3 shows FINISHED, add game_info. Note that user_id in this table holds the game account ID — a different concept from the platform user ID — so alias it to game_user_id to avoid a collision. Similarly, alias ipv4 to ip so it matches the node already in the graph.
/*polar4ai*/UPDATE FEATURE oneID WITH (parameters=()) AS (SELECT device_id,user_id as game_user_id,ipv4 as ip,ipv6,imei,idfa,googleid,android_id,oaid FROM game_info)
Step 5: Generate the mapping table
Compute connected subgraphs from the oneID graph. Every node reachable from every other node is assigned the same csg_id.
/*polar4ai*/CREATE FEATURE csg_1 WITH ( feature_class = 'connected_subgraph',parameters=()) USING FEATURE oneID
Check the status:
/*polar4ai*/SHOW FEATURE csg_1;
When FeaturePath shows FINISHED, the OSS path to the mapping table result is returned. Copy the path into your browser to view the output.
Step 6: Read the mapping table
The output table has three columns:
| Column | Description |
|---|---|
csg_id |
The subgraph ID — all rows with the same csg_id belong to the same unified identity |
column |
The column name from the source tables |
value |
The value of that column |
Example output:
csg_id |
column |
value |
|---|---|---|
| 0 | user_id | user1 |
| 0 | device_id | device1 |
| 0 | oaid | oaid1 |
| 1 | user_id | user2 |
| 1 | device_id | device2 |
In this result, user1, device1, and oaid1 are all associated with the same player (csg_id = 0). user2 and device2 belong to a different player (csg_id = 1).
Other use cases of ID mapping
Augment user behaviors
Data processed through ID mapping provides better support for upper-layer services such as custom search and recommendation to help improve their effectiveness. Data related to the behaviors of a user on different applications can be aggregated. For example, in e-commerce scenarios, data about a user who shops offline and online can be aggregated for more comprehensive analysis based on the preferences of the user.
Discover malicious groups
In the e-commerce industry, click farming is a thorny issue. Click farmers have multiple devices and multiple accounts on platforms and use them to commit fraudulent behaviors such as earning commissions without authorization, scrambling for limited coupons, and giving fake positive reviews. ID mapping can associate the different IDs to detect account exceptions. For example, one device has multiple active user IDs, or one user ID uses multiple device IDs within a short period of time. The interactions between associated accounts can also be used to discover malicious groups.
Expand user portraits
User portraits generated based on basic user data and behaviors can provide information such as a user's preference for a brand or a product category. However, user portraits may not cover all users. ID mapping can discover the relationship between IDs and supplement user information to expand user portraits. For example, if an ID belongs to a user who has a preference for a product category and is a member of a family, the IDs of the other members of the family can be discovered and their owners may have the same preference.
Advertise targeting
Advertisements can be delivered based on interests and device types of users. For example, a player may play multiple games on a gaming platform or use multiple devices to play their games. ID mapping associates different game accounts and device information of the same user, and targets the user for advertising across devices and games. An advertisement can be shown to the user when the user plays different games or uses different devices. This helps provide better advertising results compared with only sending the advertisement on a single game based on user preference.