You need to enable JavaScript to run this app.
导航
支持的用户唯一标识
最近更新时间:2024.05.10 10:43:51首次发布时间:2021.02.23 10:41:55

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

基本概念

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

device_id/web_id/anonymous_id

设备的唯一标识,系统通过设备注册服务根据获取到的设备信息(国内比如idfv、openudid、imei、mac、机型等、海外使用gaid等)为每个设备生成唯一的标识,该标识会通过客户端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通常为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,与设备标识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标识逻辑

新版与旧版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:易关联标识

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

  • 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(退出)

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

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 接口,将用户真实的首事件的时间更新到用户属性「首事件时间」中,以保证新老用户统计结果的准确性。