最近更新时间:2023.07.07 13:55:04
首次发布时间:2021.02.23 10:41:55
火山引擎A/B测试使用 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统一。ssid的主要作用 :
1、同一移动设备多人登录登出
时间序列 | 自然人 | 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(退出) | A | 1 |
4 | 李四 | a | null(未登录) | A | 1 |
5 | 李四 | a | B(登录) | B | 2 |
6 | 李四 | a | null(退出) | B | 2 |
2、不同的移动设备同一个人使用
时间序列 | 自然人 | 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,这样就可以确保用户登录前后的行为归属于同一人。
具体举例如下:
deviceid | user_unique_id | ssid | 备注 | |
---|---|---|---|---|
设备A-匿名 | A | ssid1 | ||
设备A-注册 | A | 123 | ssid1 | 新用户在相同设备下注册前后ssid不变 |
设备A-登出 | A | ssid1 | ||
设备A-切换用户 | A | 234 | ssid2 | 用户切换后,新生成ssid |
设备B-匿名 | B | ssid3 | 新设备生成新的ssid | |
设备B-登陆 | B | 123 | ssid1 | 新设备登陆老用户,ssid取之前uuid对应的ssid |
设备B-切换用户 | B | 234 | ssid2 | |
设备B-注册 | B | 345 | ssid4 | 新注册用户重新生成ssid |
历史导入用户 | 789 | ssid5 | ||
设备C-匿名 | C | ssid6 | ||
设备C-登陆 | C | 789 | ssid5 |
我们提供了一个虚拟用户属性“user_is_new”,使用时会判断用户属性中保存的第一条事件发生日期和分析时所选定时间的中某一天是否为同一天来判断用户在该日是否为新用户。
举例如下:
用户A的属性中记录的首事件时间对应的日期是8月1日,所分析的事件发生在8月3日,那么分析时。
导入用户数据后,需要调用 set_profile 接口将首事件时间更新一次,将用户真实的首次上报数据的时间更新到用户属性对应的字段中。