AE 用户 ID 绑定诊断
诊断 AE 系统中多端上报导致的用户 ID 碎片化问题，自动检测 Account ID / Distinct ID 缺失率，定位碎片化根因并输出代码级修复方案。
数据分析
异常诊断全行业AE 用户 ID 映射异常排查是 ThinkingAI 行业 Skill 库中的一项数据质量能力，帮助数据工程师在 AE 系统中诊断多端上报（客户端+服务端）导致的用户 ID 碎片化问题，自动检测 Account ID 与 Distinct ID 的缺失比例，区分正常业务行为与异常碎片化，定位根因并输出代码级修复方案。这正是 ThinkingAI「10 年行业经验沉淀为开箱即用 Skill」的体现。
#distinct_id / #account_id / #user_id 覆盖率#account_id 缺失 25%，服务端事件 #distinct_id 缺失 30%#user_id排查完成。不是 AE 的 ID 归并规则出了问题，是两端上报各缺一条腿——客户端事件缺 #account_id、服务端事件缺 #distinct_id，同一个玩家被拆成了两个 #user_id，登录记在 A、付费记在 B，留存自然偏低。
一、ID 绑定链路逐环检查
| 链路环节 | 上报来源 | 检查项 | 结果 |
|---|---|---|---|
| 设备初始化 | 客户端 | #distinct_id 生成 | 正常 · 覆盖率 100% |
| 登录回调 | 客户端 | #account_id 绑定 | 断点一 · 缺失 25% |
| 服务端上报 | 服务端 | #distinct_id 透传 | 断点二 · 缺失 30% |
| ID 归并 | AE 系统 | #user_id 生成 | 规则正常，但输入残缺 |
二、归因链
客户端登录成功后没有立即调用绑定接口 → 登录事件只带 #distinct_id → 服务端支付上报又只带 #account_id → AE 拿不到任何一条同时含两个 ID 的事件做归并 → 同一玩家生成两个 #user_id → 登录链和付费链各归一人。按当前缺失率测算，留存率计算偏差约 3–5 个百分点，行为序列完整性只有 70%——策划的体感是对的。
修复只动两处代码：① 客户端在登录回调里立即绑定 `#account_id`，不要等下一个事件；② 服务端上报时从登录态透传 `#distinct_id`。两处都是 SDK 调用层的改动，不涉及 AE 配置。
#account_id 缺失率可降至 0.5%、#distinct_id 缺失率降至 1%，行为序列完整性从 70% 回到 98%。边界说明：本 Skill 定位断点并给出上报代码修改建议，不会代改线上 SDK；修复上线后建议回跑一次本诊断做验证，历史已碎片化的数据是否重算需另行评估。行业痛点
AE 系统中用户身份识别依赖 #distinct_id、#account_id、#user_id 三个字段。在多端上报场景下，约 50% 的双端上报项目存在 ID 缺失问题，缺失率通常在 15-40% 之间。客户端事件有 #distinct_id 但缺少 #account_id，服务端事件有 #account_id 但缺少 #distinct_id，导致同一用户被拆成多条记录，直接影响留存、渠道归因和用户行为序列。
核心价值
- 区分正常与异常：先判断是正常业务行为（如多角色登录）还是异常碎片化（如服务端上报缺失 ID），避免误诊
- SQL 自动检测：自动执行 SQL 查询 Account ID / Distinct ID 缺失比例，量化碎片化严重程度
- 代码级修复方案：不只诊断问题，还提供 SDK 上报代码修改建议，从根因层面解决 ID 碎片化
适用场景
多端上报场景下的用户 ID 碎片化排查
AE 系统中 Account ID 缺失率异常偏高时的诊断
Distinct ID 缺失导致渠道归因偏差的排查
新 SDK 版本上线后的 ID 上报完整性验证
用户行为序列中出现断裂时的 ID 映射排查
实战案例
常见疑问
多角色登录算 ID 碎片化吗？
不算。同一设备创建多个角色是正常业务行为。Skill 会先区分正常与异常，只有上报缺失 ID 导致的碎片化才进入排查。
修复方案是改 SDK 代码还是改 AE 配置？
通常是改 SDK 上报代码，确保客户端登录后绑定 account_id，服务端上报时透传 distinct_id。
ID 碎片化对数据影响有多大？
影响留存分析、付费归因和渠道分析。10% 的 ID 碎片化可能导致留存率计算偏差 3-5 个百分点。
相关 Skills 推荐
用「AE 用户 ID 绑定诊断」武装你的 Agent
预约演示，看看它如何在你的业务场景中落地
