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

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

device_id/web_id/anonymous_id

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

user_unique_id

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

ssid

火山引擎增长分析默认使用的统计口径ID（即DataFinder默认的用户标识统计口径都是ssid），与设备标识device_id/web_id、登录态用户标识user_unique_id 互相Mapping，能保证用户匿名和实名状态下的ID统一。各环境下的id_mapping逻辑略有区别：

• 私有化环境中，未开启统一ID服务的场景下，id_mapping是按照应用粒度隔离的，详细id_mapping逻辑请参见下文的标识用户逻辑：简易关联。
• 私有化环境中，开启统一ID服务的场景下，id_mapping是按照集团粒度隔离的（集团内默认一个主体），详细id_mapping逻辑请参见下文的标识用户逻辑：全局关联（逻辑升级）。

ssid的主要作用 ：

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

新版与旧版ssid标识逻辑

细分对比	简易关联（旧版逻辑）	全局关联（逻辑升级）
用户id关联逻辑	ssid由device_id/web_id和user_unique_id共同生成，device_id/web_id和user_unique_id之间相互参照，user_unique_id优先级大于device_id/web_id 在生成ssid时，会绑定各个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 在生成ssid时，会绑定各个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关系
ID隔离颗粒度	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：简易关联标识

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

• 私有化查看：

  时间序列	自然人	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

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

• 私有化查看：

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

示例2：全局关联标识

• 示例场景
  某银行客户的App中需要集成数据接入的SDK进行行为数据的采集，用户在未注册时可以获取到设备号，使用设备号上报匿名数据，在用户注册后可以获取手机号，并拿手机号进行实名数据的上报，用户在绑卡之后可以获取卡号与手机号之间的关系，并在服务端使用卡号来进行交易数据的上报，同时客户还有1个微信小程序，从微信小程序中可以获取小程序union_id，在微信小程序中使用union_id来进行上报。

• 用户user_unique_id类型设置（多口径设置）

  业务ID	是否与ssid强制1:1	离线实时关系	user_unique_id_type
  卡号	是	实时高于离线	card_id
  手机号	是	离线高于实时	phone_id
  小程序union_id	否	离线高于实时	union_id
  设备号	否	只有实时输入	device_id

• 用户行为数据上报示例
  昨日用户行为数据上报

  1. 用户下载使用app，使用device_id上报匿名事件，发生了e1事件，此时有device_id1，device_id1未绑定过任何ssid，新生成一个ssid1作为e1的ssid
  2. 用户注册登录，使用device_id和phone_id上报实名事件，串联匿名前后的行为，发生了e2事件，此时有device_id1和phone_id1，phone_id1未绑定过ssid，device_id1绑定过ssid1，ssid1未绑定过phone_id，因此使用ssid1作为e2的ssid，同时将ssid1与phone_id1互相绑定
  3. 用户绑定卡号，能够获取到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互相绑定
  4. 用户使用服务端上报支付行为，发生了e3事件，此时有card_id1，card_id1绑定到了ssid1，因此使用ssid1作为e3的ssid
  5. 另外一台设备下载使用app，使用device_id上报匿名事件，发生了e4事件，此时有device_id2，device_id2未绑定过任何ssid，新生成一个ssid2作为e4的ssid
  6. 用户使用小程序，使用union_id和device_id来上报数据，发生了e5事件，此时有union_id1和device_id2，device_id2绑定过ssid2，使用ssid2作为e5的ssid，同时绑定union_id1和device_id2
  7. 用户在小程序授权手机号，拿到了phone_id1，调用id_bind接口将union_id1和phone_id1进行绑定，phone_id1已经绑定了ssid1，因此union_id1也被绑定到了ssid1
  8. 用户继续使用小程序，发生了e6事件，此时有union_id1和device_id2，union_id1绑定到了ssid1，因此使用ssid1作为e6的ssid，同时device_id2和ssid1互相绑定

• ssid关联示例

  event	card_id	phone_id	union_id	device_id	ssid
  e1				device_id1	ssid1
  e2		phone_id1		device_id1	ssid1
  e3	card_id1			device_id1	ssid1
  e4				device_id2	ssid2
  e5			union_id1	device_id2	ssid2
  e6			union_id1	device_id2	ssid1
  e7		phone_id1		device_id1	ssid3

  其中：

  • 今日离线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，这样就可以确保用户登录前后的行为归属于同一人。
具体举例如下：

系统提供了一个虚拟用户属性“user_is_new”，使用时会判断用户属性中保存的第一条事件发生日期和分析时所选定时间的中某一天是否为同一天来判断用户在该日是否为新用户。

举例如下：
用户A的属性中记录的首事件时间对应的日期是8月1日，所分析的事件发生在8月3日，则8月3日会把用户A当做老用户进行统计；同理，如果所分析的事件发生在8月1日，则8月1日会把用户A当做新用户进行统计。

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