支持的用户唯一标识

选取合适的用户标识对于提高用户行为分析的准确性有非常大的影响，尤其是漏斗、留存、Session 等用户相关的分析功能。因此，我们在进行任何数据接入之前，都应当先确定如何来标识用户。

火山引擎增长分析使用 device_id、user_unique_id、ssid 三种 id 标识设备和用户。

device_id/web_id

设备的唯一标识，我们通过设备注册服务根据获取到的设备信息（国内比如idfv、openudid、imei、mac、机型等、海外使用gaid等）为每个设备生成唯一的标识，该标识会通过客户端SDK在设备本地进行存储。一般是App产品会用到的概念，比如Android手机、iOS手机、iPad，网页端、小程序使用web_id，作用与 device_id 基本相同。

• device_id生成逻辑：如果是新设备会生成新的device_id，如果是已经存在的设备会下发已经存在的device_id，所以可以做到同一台设备上的不同App可以用相同的device_id。
• 特性：覆盖率高、冲突率低、漂移率低、稳定性高、数据可关联、不支持业务自定义，以SDK获取为准。
• web_id生成逻辑：通过app_id（火山应用id），当前URL，URL的referer，当前浏览器的useragent，以及user_unique_id(一般为空值)生成，小程序侧因为没有URL等浏览器信息，主要通过app_id（火山应用id）生成。

user_unique_id

用户唯一标识，一般情况直接使用产品业务中使用的用户标识，比如登录账号。当 user_unique_id 未设定时，在SaaS版本中，系统会自动使用 device_id/web_id 替代，在私有化版本中，会显示为空。

ssid

火山引擎增长分析默认使用的统计口径ID，与设备标识device_id/web_id、登录态用户标识user_unique_id 互相Mapping，能保证用户匿名和实名状态下的ID统一。在字节云以及私有化未开启统一ID服务的场景下，id_mapping是按照应用粒度隔离的，在火山云以及私有化开启统一ID服务的场景下，id_mapping是按照主体粒度隔离的（集团内默认一个主体）。
ssid的主要作用 ：

• 可以贯通一个用户在一个设备上注册（登录）前后的行为，同时不会因为登录行为被重复记作新增用户；
• 可以打通一个注册用户在不同设备上登录之后的行为；
• 可以解决同一设备多个账户登录的各用户行为归属问题。

同一移动设备多人登录登出

• SaaS查看：

  时间序列	自然人	device_id	登录账号	user_unique_id	ssid
  1	张三	a	null(未登录)	a	1
  2	张三	a	A（登录）	A	1
  3	张三	a	null(退出)	a	1
  4	李四	a	null(未登录)	a	1
  5	李四	a	B（登录）	B	2
  6	李四	a	null(退出）	a	2

• 私有化查看：

  时间序列	自然人	device_id	登录账号	user_unique_id	ssid
  1	张三	a	null(未登录)	null	1
  2	张三	a	A（登录）	A	1
  3	张三	a	null(退出)	null	1
  4	李四	a	null(未登录)	null	1
  5	李四	a	B（登录）	B	2
  6	李四	a	null(退出）	null	2

不同的移动设备同一个人使用

• SaaS查看：

  时间序列	自然人	device_id	登录账号	user_unique_id	ssid
  1	张三	a	null(未登录)	a	1
  2	张三	a	A（登录）	A	1
  3	张三	a	null(退出)	a	1
  4	张三	b	null(未登录)	b	2
  5	张三	b	A（登录）	A	1
  6	张三	b	null(退出）	b	1

• 私有化查看：

  时间序列	自然人	device_id	登录账号	user_unique_id	ssid
  1	张三	a	null(未登录)	null	1
  2	张三	a	A（登录）	A	1
  3	张三	a	null(退出)	A	1
  4	张三	b	null(未登录)	null	2
  5	张三	b	A（登录）	A	1
  6	张三	b	A	A	1
  7	张三	b	null(退出）	A	1

我们会基于访问者的设备和访问者的ID来生成内部统计口径SSID（用户）。设备ID相同的情况下，当用户进行了注册登录，我们会给该用户分配与其未登录匿名时相同的 SSID，这样就可以确保用户登录前后的行为归属于同一人。
具体举例如下：

我们提供了一个虚拟用户属性“user_is_new”，使用时会判断用户属性中保存的第一条事件发生日期和分析时所选定时间的中某一天是否为同一天来判断用户在该日是否为新用户。
举例如下：
用户A的属性中记录的首事件时间对应的日期是8月1日，所分析的事件发生在8月3日，则8月3日会把用户A当做老用户进行统计；同理，如果所分析的事件发生在8月1日，则8月1日会把用户A当做新用户进行统计。

如果存在从自己的数据库导入一批历史用户的场景，此时需要调用 set_profile 接口，将用户真实的首事件的时间更新到用户属性「首事件时间」中，以保证新老用户统计结果的准确性。