火山引擎增长分析：支持的用户唯一标识（device_id、user_unique_id、ssid） 原文标题：
内容概要总结
火山引擎（字节跳动）增长分析（DataFinder）官方文档，说明其标识设备与用户的三种 ID：device_id/web_id/anonymous_id、user_unique_id、ssid。文档明确指出 device_id 由设备注册服务生成并本地存储，「如果是已经存在的设备会下发已经存在的 device_id，所以可以做到同一台设备上的不同 App 可以用相同的 device_id」——即字节官方明文承认跨 App 共享同一 device_id。文档还讲解 ssid 作为默认统计口径，与 device_id/web_id、user_unique_id 互相 Mapping，区分「简易关联（应用粒度隔离）」与「全局关联（集团粒度隔离）」两套 id_mapping 逻辑。
原文内容（原文即中文）
A/B测试
iOS 接入隐私配置 PrivacyInfo.xcprivacy
复制全文
下载 pdf
复制全文
下载 pdf
文档反馈
问问助手
选取合适的用户标识对于提高用户行为分析的准确性有非常大的影响，尤其是漏斗、留存、Session 等用户相关的分析功能。因此，在进行任何数据接入之前，都应当先确定如何来标识用户。
火山引擎增长分析使用 device_id、user_unique_id、ssid 三种 id 标识设备和用户。
device_id/web_id/anonymous_id
设备的唯一标识，系统通过设备注册服务根据获取到的设备信息为每个设备生成唯一的标识，该标识会通过客户端SDK在设备本地进行存储。一般是App产品会用到的概念，比如Android手机、iOS手机、iPad，网页端、小程序使用web_id，作用与 device_id 基本相同。
如果是新设备会生成新的device_id，如果是已经存在的设备会下发已经存在的device_id，所以可以做到同一台设备上的不同App可以用相同的device_id。
覆盖率高、冲突率低、漂移率低、稳定性高、数据可关联、不支持业务自定义，以SDK获取为准。
通过app_id（火山应用id），当前URL，URL的referer，当前浏览器的useragent，以及user_unique_id（一般为空值）生成，小程序侧因为没有URL等浏览器信息，主要通过app_id（火山应用id）生成。
如果您希望上报自己服务端/客户端生成的设备唯一标识时，可使用anonymous_id。
device_id、web_id通常为DataFinder生成后由客户端进行上报，使用anonymous_id时，客户端在上报device_id、web_id的同时会将客户侧生成的唯一设备标识上报为anonymous_id。
- SaaS-云原生环境支持使用，SaaS-非云原生环境不支持。
- 私有化环境中如果已开启统一ID服务，则可直接使用；如果未开启，需联系技术支持人员进行配置，完成后可使用。
- iOS客户端、Android客户端不支持上报anonymous_id。
device_id、web_id、anonymous_id均可作为设备的唯一id，使用方式类似，下文中的逻辑介绍、逻辑示例均以device_id作为示例，web_id、anonymous_id的用法类似。
user_unique_id
用户唯一标识，一般情况直接使用产品业务中使用的用户标识，比如登录账号。当 user_unique_id 未设定时，在SaaS版本中，系统会自动使用 device_id/web_id 替代，在私有化版本中，会显示为空。
ssid
火山引擎增长分析默认使用的统计口径ID（即DataFinder默认的用户标识统计口径都是ssid），与设备标识device_id/web_id、登录态用户标识user_unique_id 互相Mapping，能保证用户匿名和实名状态下的ID统一。各环境下的id_mapping逻辑略有区别：
- 在SaaS-非云原生以及私有化环境中，未开启统一ID服务的场景下，id_mapping是按照应用粒度隔离的，详细id_mapping逻辑请参见下文的标识用户逻辑：简易关联。
- 在SaaS-云原生及私有化环境中，开启统一ID服务的场景下，id_mapping是按照集团粒度隔离的（集团内默认一个主体），详细id_mapping逻辑请参见下文的标识用户逻辑：全局关联（逻辑升级）。
- 可以贯通一个用户在一个设备上注册（登录）前后的行为，同时不会因为登录行为被重复记作新增用户；
- 可以解决同一设备多个账户登录的各用户行为归属问题。
新版与旧版ssid标识逻辑
- ssid由device_id/web_id和user_unique_id共同生成，device_id/web_id和user_unique_id之间相互参照，user_unique_id优先级大于device_id/web_id
- device_id/web_id与ssid之间是n:n的关系，通过device_id/web_id只能查到该id最新绑定的ssid，通过ssid也只能查到该ssid最新绑定的device_id/web_id
- user_unique_id和ssid之间是1:1关系
通过独立的统一ID服务，为营销套件内的产品提供id生成功能，在满足旧版场景的基础上实现多口径、多主体的ID统一。
- ssid由device_id/web_id和user_unique_id共同生成，device_id/web_id和user_unique_id之间相互参照，user_unique_id优先级大于device_id/web_id
- device_id/web_id与ssid之间是n:n的关系，通过device_id/web_id只能查到该id最新绑定的ssid，通过ssid也只能查到该ssid最新绑定的device_id/web_id
- user_unique_id支持多类，可通过user_unique_id_type参数来设置类型，每类user_unique_id和ssid之间可以是1:1或n:1关系
ssid在应用（appid）层面隔离。
在旧的ID体系中，一个应用（appid）下相同的的user_unique_id对应的ssid相同，不同应用（appid）下相同的user_unique_id对应的ssid不同
ssid在集团级别隔离。即集团下的多个应用ssid可统一标识、管理。
- 应用场景：实现了用户从匿名到实名和从实名到匿名，通过ssid的串联。
- 局限性：user_unique_id没有明确的含义，且只允许设置成一种业务ID，无法支持多口径，多业务场景的数据无法打通。
例如，某银行客户的App中已经集成了数据接入的SDK进行行为数据的采集，同时user_unique_id设置为了客户号。用户的登录形态中还包括注册未绑卡，此时获取不到客户号，但是能够获取到手机号，但是由于上报时不能携带其他类型的业务ID，因此产生的相关事件数据都只能记录为匿名的，客户想要通过手机号向用户发送绑卡短信的需求无法满足。
- 优势：支持多应用（主体）、多口径场景下的用户统一标识。
示例1：简易关联标识
同一移动设备多人登录登出
不同的移动设备同一个人使用
示例2：全局关联标识
示例场景
某银行客户的App中需要集成数据接入的SDK进行行为数据的采集，用户在未注册时可以获取到设备号，使用设备号上报匿名数据，在用户注册后可以获取手机号，并拿手机号进行实名数据的上报，用户在绑卡之后可以获取卡号与手机号之间的关系，并在服务端使用卡号来进行交易数据的上报，同时客户还有1个微信小程序，从微信小程序中可以获取小程序union_id，在微信小程序中使用union_id来进行上报。
用户user_unique_id类型设置（多口径设置）
示例场景2：今日离线id-mapping&用户行为数据上报
- 用户下载使用app，使用device_id上报匿名事件，发生了e1事件，此时有device_id1，device_id1未绑定过任何ssid，新生成一个ssid1作为e1的ssid
- 用户注册登录，使用device_id和phone_id上报实名事件，串联匿名前后的行为，发生了e2事件，此时有device_id1和phone_id1，phone_id1未绑定过ssid，device_id1绑定过ssid1，ssid1未绑定过phone_id，因此使用ssid1作为e2的ssid，同时将ssid1与phone_id1互相绑定
- 用户绑定卡号，能够获取到card_id和phone_id的关系，因此使用id_bind绑定card_id和phone_id，此时有phone_id1和card_id1，card_id1未绑定过ssid，phone_id1绑定过ssid1，ssid1未绑定过card_id，因此将card_id1与ssid1互相绑定
- 用户使用服务端上报支付行为，发生了e3事件，此时有card_id1，card_id1绑定到了ssid1，因此使用ssid1作为e3的ssid
- 另外一台设备下载使用app，使用device_id上报匿名事件，发生了e4事件，此时有device_id2，device_id2未绑定过任何ssid，新生成一个ssid2作为e4的ssid
- 用户使用小程序，使用union_id和device_id来上报数据，发生了e5事件，此时有union_id1和device_id2，device_id2绑定过ssid2，使用ssid2作为e5的ssid，同时绑定union_id1和device_id2
- 用户在小程序授权手机号，拿到了phone_id1，调用id_bind接口将union_id1和phone_id1进行绑定，phone_id1已经绑定了ssid1，因此union_id1也被绑定到了ssid1
- 用户继续使用小程序，发生了e6事件，此时有union_id1和device_id2，union_id1绑定到了ssid1，因此使用ssid1作为e6的ssid，同时device_id2和ssid1互相绑定
- 今日离线id-mapping时：
离线id-mapping时，假设phone_id1绑定了ssid3，由于phoine_id离线优先级高于实时，因此phone_id1会被重新绑定到ssid3，并且会写入到实时id-mapping中，实时id-mapping中phone_id1被绑定到ssid3
- 今日用户行为数据上报：
用户在登录场景下，发生了e7事件，此时有device_id1和phone_id1，phone_id1绑定了ssid3，因此使用ssid3作为e7的ssid
系统会基于访问者的设备和访问者的ID来生成内部统计口径SSID（用户）。设备ID相同的情况下，当用户进行了注册登录，系统会给该用户分配与其未登录匿名时相同的 SSID，这样就可以确保用户登录前后的行为归属于同一人。
具体举例如下：
新设备登录老用户，ssid取之前uuid对应的ssid
- 如果您使用的是私有化环境，且开启了多设备修正功能，在123用户登录设备B后，匿名场景下的ssid会从ssid3被修正为ssid1。
系统提供了一个虚拟用户属性“user_is_new”，使用时会判断用户属性中保存的第一条事件发生日期和分析时所选定时间的中某一天是否为同一天来判断用户在该日是否为新用户。
DataFinder的默认用户标识的统计口径是ssid，因此用户属性“user_is_new”的统计口径也是ssid。
举例如下：
用户A的属性中记录的首事件时间对应的日期是8月1日，所分析的事件发生在8月3日，则8月3日会把用户A当做老用户进行统计；同理，如果所分析的事件发生在8月1日，则8月1日会把用户A当做新用户进行统计。
如果存在从自己的数据库导入一批历史用户的场景，此时需要调用 set_profile 接口，将用户真实的首事件的时间更新到用户属性「首事件时间」中，以保证新老用户统计结果的准确性。
此外，DataFinder还提供是否首日访问（$is_first_day）属性，新老用户（user_is_new）和是否首日访问（$is_first_day）两者都是根据用户属性激活时间（first_event_time，SaaS-云原生和私有化环境）/注册时间（$user_register_time，SaaS-非云原生环境）来进行计算的，最主要的区别在于前者受所选时间周期的影响，而后者不受影响，因此后者在不同的图表类型中得到的计算结果有更好的一致性。
- 是否首日访问（$is_first_day）：目标事件和首个事件发生在同一天。
- 新老用户（user_is_new）：目标事件和首个事件发生在同一周期。比如在柱形图中，周期就是用户所选的时间范围。
- 建议使用是否首日访问（$is_first_day）来判断新老用户。
- 仅在DataFinder的高级分析内可使用新老用户（user_is_new），其它场景尽量不要直接使用新老用户（user_is_new），数据可能会不符合用户预期。
- 如果需要灵活设置时间范围时，也可以使用用户属性激活时间（first_event_time，SaaS-云原生、私有化环境）/注册时间（$user_register_time，SaaS-非云原生环境）。
更多两者的逻辑对比和介绍请参见新老用户/是否首日相关。
最近更新时间：2026.01.22 15:00:28