选取合适的用户标识对于提高用户行为分析的准确性有非常大的影响,尤其是漏斗、留存、Session 等用户相关的分析功能。因此,在进行任何数据接入之前,都应当先确定如何来标识用户。
火山引擎增长分析使用 device_id、user_unique_id、ssid 三种 id 标识设备和用户。
设备的唯一标识,系统通过设备注册服务根据获取到的设备信息为每个设备生成唯一的标识,该标识会通过客户端SDK在设备本地进行存储。一般是App产品会用到的概念,比如Android手机、iOS手机、iPad,网页端、小程序使用web_id,作用与 device_id 基本相同。
设备唯一标识类型 | 数据类型 | 生成逻辑介绍 | 特性/限制 |
---|---|---|---|
device_id | int | 如果是新设备会生成新的device_id,如果是已经存在的设备会下发已经存在的device_id,所以可以做到同一台设备上的不同App可以用相同的device_id。 | 覆盖率高、冲突率低、漂移率低、稳定性高、数据可关联、不支持业务自定义,以SDK获取为准。 |
web_id | int | 通过app_id(火山应用id),当前URL,URL的referer,当前浏览器的useragent,以及user_unique_id(一般为空值)生成,小程序侧因为没有URL等浏览器信息,主要通过app_id(火山应用id)生成。 | null |
anonymous_id | string | 如果您希望上报自己服务端/客户端生成的设备唯一标识时,可使用anonymous_id。 |
|
说明
device_id、web_id、anonymous_id均可作为设备的唯一id,使用方式类似,下文中的逻辑介绍、逻辑示例均以device_id作为示例,web_id、anonymous_id的用法类似。
用户唯一标识,一般情况直接使用产品业务中使用的用户标识,比如登录账号。当 user_unique_id 未设定时,在私有化版本中,会显示为空。
火山引擎增长分析默认使用的统计口径ID,与设备标识device_id/web_id、登录态用户标识user_unique_id 互相Mapping,能保证用户匿名和实名状态下的ID统一。各环境下的id_mapping逻辑略有区别:
ssid的主要作用 :
细分对比 | 简易关联(旧版逻辑) | 全局关联(逻辑升级) |
---|---|---|
用户id关联逻辑 |
| 通过独立的统一ID服务,为营销套件内的产品提供id生成功能,在满足旧版场景的基础上实现多口径、多主体的ID统一。
|
ID隔离颗粒度 | ssid在应用(appid)层面隔离。 | ssid在项目/集团级别隔离。即同项目下的多个应用ssid可统一标识、管理。 |
逻辑对比 |
|
|
私有化查看:
时间序列 | 自然人 | 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 |
示例场景
某银行客户的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 |
用户行为数据上报示例
昨日用户行为数据上报
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来生成内部统计口径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 说明 如果您开启了多设备修正功能,在123用户登录设备B后,匿名场景下的ssid会从ssid3被修正为ssid1。 |
设备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日,则8月3日会把用户A当做老用户进行统计;同理,如果所分析的事件发生在8月1日,则8月1日会把用户A当做新用户进行统计。
如果存在从自己的数据库导入一批历史用户的场景,此时需要调用 set_profile 接口,将用户真实的首事件的时间更新到用户属性「首事件时间」中,以保证新老用户统计结果的准确性。