什么是 ID 关联
同一位用户在不同渠道、不同设备上会留下不同的标识：未登录时是匿名 ID（设备 ID），登录后是登录 ID（账号），业务上还可能有手机号、邮箱等自定义 ID。ID 关联的作用是把这些标识关联到同一个用户身份上，让分散的行为数据按「人」聚合分析，典型场景包括跨端打通、跨设备打通和登录前后行为打通。
系统为每个用户生成一个项目内唯一的神策 ID，作为分析、分群、画布等场景统一的用户主键。关联在数据上报时自动完成：一条数据同时携带多个 ID（如登录事件同时带匿名 ID 和登录 ID）时，系统按项目配置的关联策略建立关联。
三种关联策略
名词定义
两ID：仅登录ID 和匿名ID 参与用户关联。（$identity_login_id、$identity_anonymous_id）
多ID：用户可选择更多有业务含义的用户表示参与关联。（$identity_email、identity_xxx）
关联策略
关联策略是项目级配置，可在「数据管理 > 用户表 > 配置用户标识」中查看。三种策略的核心区别：
首次关联保持
规则最简单：只在匿名 ID 和登录 ID 之间做一次性关联。
- 匿名 ID 第一次遇到登录 ID 时建立关联，此后长期保持，不再改绑；
- 用户一旦记录了登录 ID，就不再接纳新的关联，也不会与其他用户合并；
- 换新设备后，新匿名 ID 不会并入既有用户（登录前的行为仍算独立用户），因此用户数可能偏高，可通过「用登录后事件做 UV 口径」等方式规避。
- 同一个登录ID 最多绑定一个匿名ID
特点：事件入库后归属不再变化，统计口径最稳定、可解释性最强，性能和吞吐最佳。适合有强账号体系、不太关注登录前后行为关联的场景，或纯工具类应用。
尽可能关联
通用策略，也是新建、重置项目后的默认策略。把一条数据中的所有 ID 尽量关联到同一个用户。
- 已有用户遇到新 ID（新设备、新渠道）时自动关联进来；
- 一条数据中的多个 ID 分属不同用户时，自动合并这些用户，历史行为一并归并；
- 业务 ID 可为多值（如 3 台设备的设备 ID），ID 之间可两两关联并推断（手机号 A 关联登录 ID 1，手机号 A 又关联设备 B，则三者属于同一用户）。
两种使用模式：
- 2 ID 模式：只用匿名 ID + 登录 ID，行为与历史版本兼容，性能最佳；
- 多 ID 模式：可自定义多种 ID（手机号、邮箱、微信 openid 等）并设置优先级，一条数据中的 ID 都是新的时候，按优先级最高的 ID 生成新用户。
保护规则：每个用户最多一个登录 ID；两个绑定了不同登录 ID 的用户不会被合并，相关数据按 ID 优先级归属。
特点：跨端识别覆盖最广，多渠道、多设备数据能缝合到同一用户，数据资产更完整。代价是用户合并会修正历史数据归属——UV 可能随时间小幅减少，新增用户统计有波动期，建议延迟统计；且不支持解绑，错误关联需修复流程处理。
动态可变关联
在尽可能关联基础上，额外支持解绑，是唯一支持关联关系动态调整的策略。
- 可解绑指定的匿名 ID 或自定义 ID，之后重新绑定（如换手机号：解绑手机号 A，再绑定手机号 B）；
- 登录 ID 不可解绑；被解绑的 ID 不能是该用户除登录 ID 外唯一的 ID；
- 支持在定义 ID 时为每类 ID 单独设置数量上限，即同一用户下该 ID 可绑定的值的个数（如限制一个用户最多绑定 10 个 Cookie ID），超过上限后新值不再绑定或按配置淘汰最早绑定的值，可应对 Cookie 泛滥、黑产刷量等问题。
特点：最灵活，可在线纠正错误关联。但对数据上报时序要求高（解绑需发生在绑定之后，因此不适合有历史数据导入的场景），且只能顺序处理，吞吐最低，适合数据量适中的场景。
如何选择
- 业务只有「匿名 → 登录」一条路径，且一个登录ID最多只能关联一个匿名ID，希望口径最稳定：选首次关联保持；
- 有多渠道、多设备触点，需要完整用户识别：选尽可能关联（默认）；
- 在此基础上还需换绑、注销、在线纠错：选动态可变关联。
无论选择哪种策略，都建议谨慎选择登录 ID：使用注册 ID、会员 ID 等持久不变的业务标识，不要用手机号等可变信息（可变信息更适合作为自定义 ID，在动态可变关联下通过解绑换绑）。切换策略会影响既有数据的处理，请在神策实施与技术支持团队评估下操作。
常见问题
Q：登录 ID 可以解绑吗？ A：不可以。所有策略下登录 ID 都是用户的稳定主标识。
Q：两个不同登录ID的用户会被自动合并吗？ A：不会。每个用户最多一个登录 ID，两个已绑定不同登录 ID 的用户不会合并，数据按 ID 优先级归属。
Q：换了新设备，登录前的匿名行为还能归到我名下吗？ A：首次关联保持下不能，新设备的匿名 ID 不会并入既有用户；尽可能关联和动态可变关联下可以，登录后自动归并。