OneID: A Unified Identity System for Cross-Platform Users

Summary: OneID models identifiers such as devices, accounts, and contact points as nodes, models verifiable relationships between them as edges, and then uses connectivity to recognize the same user behind all of them.

Key Takeaways

• OneID models identifiers such as devices, accounts, and contact points as nodes, and verifiable relationships between them as edges, then uses connectivity to recognize the same user.
• High-confidence strong associations can be merged straight away; low-confidence weak associations should be merged only once several pieces of evidence cross a threshold, which keeps mistaken merges under control.
• The full implementation chain covers log ingestion, identifier standardization, association computing, unified identity generation, and two-way identity lookup.
• Cross-platform identity attribution also requires data authorization, protection of sensitive identifiers, access control, and auditable merge rules.

1. What Is OneID

1.1 The Identity Challenge in a Multi-Device World

In the digital era, users leave traces across many devices and many platforms. The same person may reach a service from a phone, a tablet, and a laptop, may register a different account on each channel, and generates a large volume of scattered identifier data in the process. Those identifiers – phone numbers, device IDs, email addresses, IP addresses – are like scattered puzzle pieces that resist being assembled into a complete user profile.

Working out reliably whether "this is the same user" has become a core challenge of digital operations. OneID was built for exactly this. It is a unified user identification system based on connected-graph theory that intelligently links scattered identifiers and assigns every natural person a single digital identity.

1.2 Core Principle: Connected Graphs and Union-Find

OneID is grounded in the connected-graph principle from graph theory. The core idea is to abstract scattered user identifiers into nodes in a graph, build edges from the relationships between identifiers, and finally aggregate every identifier belonging to the same natural person into one connected component.

In that process, the union-find algorithm (Union-Find) plays the key role. It is an efficient data-structure algorithm for partition problems, supporting fast find and union operations. With union-find, the system can quickly decide whether two identifiers belong to the same connected component and merge related identifiers into the same user set.

graph TD
    subgraph Real world
        A[Natural person A]
        B[Natural person B]
        C[Natural person C]
    end
    subgraph "Connected-graph abstraction"
        D["Node 1 (phone number 138xxxx5678)"]
        E["Node 2 (device ID = imei123)"]
        F["Node 3 (email user#example.com)"]
        G["Node 4 (phone number 139xxxx1234)"]
        H["Node 5 (device ID = imei456)"]
        I["Node 6 (MAC address = aa:bb:cc:dd:ee:ff)"]
        J["Node 7 (IP = 192.168.1.100)"]
        K["Node 8 (JA3 = ja3hash123)"]

        %% first connected component (natural person A)
        D -- "strong association: login binding" --> E
        E -- "strong association: same device" --> F

        %% second connected component (natural person B)
        G -- "strong association: login binding" --> H
        H -- "weak association: same IP" --> J

        %% isolated component (natural person C)
        K["Node 9 (MAC address = ff:ee:dd:cc:bb:aa)"]
    end
    A -->|maps to| D
    A -->|maps to| E
    A -->|maps to| F
    B -->|maps to| G
    B -->|maps to| H
    B -->|maps to| J
    C -->|maps to| K

1.3 Core Concepts

1.4 Association Rules: Strong and Weak

Associations between identifiers come in two strengths, and the strength decides the merge strategy:

1.5 How Connected Components Are Computed

OneID is generated through the following flow:

1. Node initialization: every user identifier starts as an independent node
2. Edge loading: load all valid association edges; strong edges are always loaded, weak edges only when they satisfy the rules
3. Component merging (union-find): traverse every edge and merge the source node with the target node
4. Strong edges: force the merge of the two components the nodes belong to
5. Weak edges: merge only when the co-occurrence count reaches the threshold
6. After merging, mark the connected component with the root node ID
7. OneID assignment: hash the root node ID of the connected component to generate a unique OneID, so that the same component always produces the same OneID

1.6 Handling Special Scenarios

Multi-Device Scenario

When a user logs into the same account from a phone and from a laptop, the phone and the account form a strong edge, the laptop and the account form a strong edge, and all three merge into one connected component that yields a single OneID.

Multi-User Device Scenario

When a family shares a tablet, several people log in on the same device. The system judges the primary user from usage duration (for example, the user accounting for 60% of usage time) and the associated users (for example, a user accounting for 40% of usage time), and marks device attribution at the output layer so that behavioral data is attributed accurately.

2. Why You Need OneID

2.1 Business Pain Points

2.2 The Business Value of OneID

3. How to Implement OneID

3.1 Overall Architecture

OneID uses a layered architecture. Data flows through "identifier node, association edge, connected component, OneID mapping" to produce a unified user identity.

3.2 Data Table Design

ODS Layer: Raw Data Ingestion

ods_user_register_login_df (registration and login log table)

ods_user_behavior_df (user behavior log table)

ods_cdn_access_df (CDN access log table)

DWD Layer: Identifier Node Standardization

dwd_user_identity_node_df (user identifier node table)

DWS Layer: Connected-Graph Modeling

dws_user_identity_edge_df (user identifier association edge table)

dws_user_oneid_component_df (OneID connected component table)

ADS Layer: Query Service

ads_user_oneid_to_identity_df (OneID to identifier mapping table)

ads_user_identity_to_oneid_df (identifier to OneID mapping table)

3.3 Core Processing Logic

Identifier Standardization

Extract every kind of user identifier from the raw logs and standardize it:

-- Example: extract and standardize user identifiers from the registration and login log
-- Phone number masking
CASE
    WHEN identity_type = 'PHONE'
    THEN CONCAT(SUBSTR(phone, 1, 3), '****', SUBSTR(phone, 8, 4))
    ELSE identity_value
END AS identity_value

Processing logic:

• Phone number: masked for display (keep the first 3 digits and the last 4 digits)
• Email address: keep the full format, used for association
• Device ID: standardize by stripping whitespace and other invalid characters
• IP address: keep the original format, used for network-environment association

Building Association Edges

Build association edges between identifiers from business rules:

-- Example: strong association edges built from the same user_id
SELECT
    a.node_id AS source_node_id,
    b.node_id AS target_node_id,
    'STRONG' AS relation_type,
    'login binding to the same user_id' AS relation_reason
FROM dwd_user_identity_node_df a
JOIN dwd_user_identity_node_df b
    ON a.user_id = b.user_id
    AND a.node_id < b.node_id  -- avoid duplicate edges

Association edge types:

• Strong edges: all identifiers of the same user_id, multiple identifiers of the same device
• Weak edges: multiple devices behind one IP, multiple identifiers sharing a JA3 fingerprint

Computing Connected Components

Compute connected components with union-find:

-- Example: union-find UDF computing connected components
SELECT
    node_id,
    UnionFindUDF(node_id, edge_list) AS component_id
FROM tmp_user_edge_list

Generate OneID from the connected component:

-- Example: generate OneID by hash encoding
SELECT
    CASE
        WHEN user_id IS NOT NULL
        THEN CONCAT('oneid_', TOLOWER(HEX(HASH_CODE(user_id))))
        ELSE CONCAT('oneid_', TOLOWER(HEX(HASH_CODE(component_id))))
    END AS oneid

Two-Way Lookup

OneID to identifiers (forward lookup)

-- Query every identifier linked to a given OneID
SELECT identity_type, identity_value, is_primary, is_valid
FROM ads_user_oneid_to_identity_df
WHERE oneid = 'oneid_8f7e6d5c';

Identifiers to OneID (reverse lookup)

-- Look up the OneID for a given identifier
SELECT oneid, relation_type, is_primary
FROM ads_user_identity_to_oneid_df
WHERE identity_type = 'PHONE'
  AND identity_value = '138\*\*\*\*5678';

4. What OneID Solves

4.1 Risk Control

By linking every identifier of a user, OneID identifies risky behavior precisely:

4.2 Marketing

OneID enables precise marketing and improves marketing efficiency:

4.3 User Operations

OneID improves the efficiency and precision of user operations:

4.4 Security Audit

OneID can trace a complete user activity trail:

4.5 Service Optimization

OneID raises service quality substantially:

4.6 Customer Experience

OneID supports a seamless customer experience:

4.7 Business Decision Support

OneID supplies the data behind business decisions:

5. Data Privacy and Security

5.1 Data Masking Rules

5.2 Data Security Controls

• Minimum necessary: collect only the identifiers the business actually needs, nothing unrelated
• Encrypted storage: store sensitive data encrypted to prevent leakage
• Access control: strict permission management and access auditing to prevent unauthorized access
• Data retention: follow the retention period and purge expired data automatically

5.3 User Rights

Users hold the following rights over their own data:

• Right of access: query the data the system holds about them
• Right of correction: request correction of inaccurate personal information
• Right of deletion: request deletion of personal data where the law allows it

6. Conclusion

OneID is a unified user identification system built on connected-graph theory. By intelligently linking scattered identifiers, it constructs a complete digital identity for every natural person. It solves the identification problem of a multi-device, multi-platform world, and it gives risk control, marketing, operations, and service a solid data foundation.

On the technical side, OneID uses mature techniques – connected-graph theory, union-find, and hash encoding – which keep the system accurate, efficient, and stable. With data masking and privacy protection built in, it delivers business value while protecting user privacy.

As digitalization deepens, OneID will matter more and more in user growth, precise marketing, risk prevention, and service optimization, and will become core infrastructure for digital operations.

FAQ

Q: What is the difference between OneID and a user ID?

A user ID is the account identifier inside a business system; OneID is a unified identity identifier that spans systems and devices and links every identifier of the same user.

Q: Does OneID leak user privacy?

OneID itself contains no personal information. It is only a unique code produced by hashing, and the original user data cannot be derived back from it.

Q: Is OneID generated in real time?

OneID is usually generated by T+1 batch processing, which keeps data processing stable and accurate.

Q: Can one user have several OneIDs?

Normally a natural person has exactly one OneID. In extreme cases, such as devices used with no association at all, several may exist, but association rules are tuned continuously to reduce such cases.

Q: How does OneID handle shared devices?

It weighs usage duration, login frequency, and similar signals to judge the primary user and the associated users, so behavioral data is attributed accurately.

Q: What is the difference between strong and weak associations?

A strong association is deterministic, such as devices behind the same account, and can be merged directly. A weak association is probabilistic, such as devices behind the same IP, and needs several corroborating signals before merging.

Q: Can a OneID expire?

The OneID itself stays valid long term, but the identifiers linked to it can expire after long inactivity, which keeps the data current.

Q: Can OneID be used across platforms?

Yes. For any platforms inside the same data system, OneID can recognize the same user across them.

Q: How is OneID uniqueness guaranteed?

It is generated by hashing the root node of the connected component, so the same component always produces the same OneID.

About Tengence

Cross-platform identity recognition is a prerequisite for refined private-domain operations, and it belongs to the growth-technology domain Tengence works on. Tengence is the enterprise growth engine for the AI era, focused on public-traffic acquisition and private-domain conversion.

Get Started

• Book a free expert consultation and audit
• Start your free trial
• Learn about Tengence GEO