OneID与用户ID打通
总结
| 记忆点 | 内容 |
|---|---|
| OneID目标 | 多端多渠道ID映射为统一用户ID |
| 三种方案 | 确定性匹配（主力）→ 图算法（补充）→ 概率性（特定场景） |
| 核心表 | dim_id_mapping，存ID类型+ID值+one_id映射 |
| 常见坑 | 公共设备、ID漂移、关系过期 |
| 面试关键 | 说出具体方案和踩过的坑，不要只背理论 |
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
高阶 | 大数据面试 · 数仓建模系列
| 面试真题 你们是怎么做用户ID打通的？一个用户在不同端、不同渠道有不同的ID，怎么识别为同一个人？ |
|---|
为什么需要OneID？
先说一个真实场景。用户张三在你的App上有三种身份：没登录时只有设备ID（IDFA/OAID）；微信登录有一个微信OpenID；手机号登录有一个手机号。这三条数据在数仓里是三个「人」。如果不打通，DAU虚高（一个人算三个），留存率算不准，广告归因也对不上。
OneID的目标：把同一个人在不同端、不同渠道的ID，映射到一个统一ID上。
| Wood的实战经验 我在做出海业务的广告归因时，深刻体会到OneID的重要性。用户从TikTok广告点击到App安装再到首次付费，中间经历了广告平台ID → 设备ID → App内user_id三次身份切换。没有ID打通，归因链路直接断掉，根本算不清ROI。 这不是一个理论问题，这是一个每天都影响几十万广告预算分配的真实问题。ROI算不清，投放团队就不知道哪个渠道该加预算哪个该砍预算，广告费就在白白浪费。 |
|---|
ID打通的三种方案
方案一：确定性匹配（最常用）
通过强关联关系直接匹配。比如用户登录时，设备ID和user_id同时出现 → 确定是同一个人；用户绑定手机号时，user_id和手机号关联 → 确定是同一个人。准确率接近100%，但覆盖率低（未登录用户打不通）。
| -- 构建ID关系表：确定性匹配 CREATE TABLE id_mapping AS SELECT user_id, device_id, phone, FIRST_VALUE(user_id) OVER( PARTITION BY device_id ORDER BY create_time ) AS one_id FROM user_login_log WHERE user_id IS NOT NULL; |
|---|
方案二：图算法打通（进阶）
当关系链比较复杂时，用连通图的思路：设备A → user_id_1 → 手机号X，设备B → user_id_2 → 同一个手机号X → 说明它们都是同一个人。用Union-Find/Connected Components算法把所有能通过关系链连接起来的ID合并到同一个集合。覆盖率高，但有误关联风险（公共设备、家庭共享手机）。
方案三：概率性匹配（特定场景）
通过设备指纹、IP、行为特征等弱信号推测。准确率低，一般作为确定性匹配的补充，只在广告归因等特定场景用。
要注意的坑
公共设备问题：网吧电脑、公司iPad可能多人使用，一个device_id关联了多个user_id。需要设置规则：一个设备关联超过N个用户就标记为公共设备，不参与打通。
ID漂移：用户换手机后，旧设备ID和新设备ID如何关联？需要通过user_id作为桥接。
数据时效性：ID关系可能过期，半年前的设备ID现在可能已经是别人的了。需要设置关系有效期。
| 面试加分提示 OneID是高级面试题，面试官考察的是你对复杂数据关系的处理能力： 「我们用的是确定性匹配为主的方案。核心是一张ID关系表，存储user_id、device_id、phone等多种ID之间的映射关系。用户登录时自动采集关联关系，通过最早的user_id作为one_id。遇到过公共设备的问题，一个iPad关联了50多个user_id，我们加了阈值规则：一个设备关联超过10个用户就排除。准确率大概在95%以上，覆盖了80%的活跃用户。」 关键：说出具体方案 + 遇到的问题 + 解决办法 + 效果数据。 |
|---|