- 平台介绍
- 接入指引
- 版本信息
- 使用流程
- 功能手册
- 操作视频
- 技术文档
- 基础知识
- 客户端SDK
- 服务端SDK
- 数据导入
- API功能
- SQL手册
- DML
- SQL函数
- 日期函数
- convert_tz
- curdate,current_date
- current_timestamp
- curtime,current_time
- date_add
- date_format
- date_sub
- datediff
- day
- dayname
- dayofmonth
- dayofweek
- dayofyear
- from_days
- from_unixtime
- hour
- makedate
- minute
- month
- monthname
- now
- second
- str_to_date
- time_round
- timediff
- timestampadd
- timestampdiff
- to_date
- to_days
- unix_timestamp
- utc_timestamp
- week
- weekday
- weekofyear
- year
- yearweek
- localtime,localtimestamp
- quarter
- last_day
- extract
- date_trunc
- minutes_add
- minutes_diff
- minutes_sub
- seconds_add
- seconds_diff
- seconds_sub
- hours_add
- hours_diff
- hours_sub
- days_add
- days_diff
- days_sub
- weeks_add
- weeks_diff
- weeks_sub
- months_add
- months_diff
- months_sub
- years_add
- years_diff
- years_sub
- 字符串函数
- append_trailing_char_if_absent
- to_base64
- from_base64
- ascii
- length
- bit_length
- char_length
- lpad
- rpad
- lower
- lcase
- upper
- ucase
- initcap
- repeat
- reverse
- char
- concat
- concat_ws
- substr
- substring
- sub_replace
- ends_with
- starts_with
- trim
- ltrim
- rtrim
- null_or_empty
- not_null_or_empty
- hex
- unhex
- elt
- instr
- locate
- find_in_set
- replace
- left
- right
- strleft
- strright
- split_part
- split_by_string
- substring_index
- money_format
- parse_url
- convert_to
- extract_url_parameter
- uuid
- space
- sleep
- 日期函数
- 数据类型
- 数据管理
- 常见问题
- 合规说明
- 资源下载
- AB测试
用户识别
1. 用户识别
用户识别是分析中一个重要的组成部分,在分析用户之前我们必须首先能够识别每个用户,分辨出哪些是新用户,哪些是留存用户。这样不但能够更加清晰地了解到底有多少用户访问了你的网站,分辨他们是谁(用户ID、邮箱、性别年龄等);同时也能够帮助你更好地跟踪你的用户,发现它们的行为特征,兴趣爱好及个性化的设置等,以便于更好地把握用户需求,提升用户体验。在实际业务中用户可能含有多个ID体系,通过ID-Mapping(用户融合和识别)可以在同一个主体上建立统一的标签体系,然后基于此进行人群圈选或洞察,还原用户真实画像,以便于能够在分析中数智化洞察用户的的行为及业务特征,总结规律,然后再实际运营中为不同分层用户设计针对性的服务与营销策略。那么海纳是怎么设计识别用户的呢?
1.1 用户识别 ID
海纳嗨数主要使用三个字段进行用户识别
- 设备 ID(distinct_id):不一定为设备的唯一标识,一个设备ID只会指向一个设备,但一个设备会有多个设备ID,我们通过设备注册服务获取到的设备信息会通过客户端sdk在设备本地进行存储。
- 账号 ID(account_id):客户业务系统中用户唯一标识,一般情况直接使用产品业务中使用的用户标识,比如登录账号。
- 用户 ID(user_id):海纳嗨数分析平台为用户/设备自动分配的唯一标识,并与各个平台的账号ID相关联,以实现对匿名和实名状态用户的统一标识。
1.1.1 设备 ID
设备 ID 即匿名ID,用户未登录情况下,SDK会自动生成一个唯一标识来,识别用户,当用户登录后SDK会自动将设备ID 设置为账户ID。
1.1.2账号 ID
账号 ID 指的是用户在客户平台上注册生成的唯一编号,后续的客户相关行为操作都通过该唯一编号进行关联用户相关信息。
1.1.3用户 ID
用户 ID是海纳嗨数内部用来识别用户的唯一标识 ID。所有入库数据,系统都会根据“账号 ID”与“设备 ID”生成该条数据的“用户 ID”,以标识用户属性和行为数据归属。
1.2 用户识别方案详解
在不同的业务或平台导致,用户标识使用不一样,用户场景主要归类为三种情况:
A、只使用设备 ID
B、关联设备 ID 和账号 ID(一对一)
C、关联设备 ID 和账号 ID(多对一)
1.2.1 方案一:只使用设备 ID
1.2.1.1 适用场景
平台没有用户注册体系,或者极少数用户会进行多设备登录的产品,如工具类产品、搜索引擎等;用户跨设备使用或者多用户共用设备不是产品的常见场景的。
1.2.1.2 局限性
- 同一用户在不同设备使用会被认为不同的用户(设备ID不同,对应user_id 也不一样),导致出现真实客户为一个,但是系统识别出多个用户出来,影响后续的用户分析统计(即用户换新手机,新手机的操作行为无法关联之前手机行为数据)。
- 不同用户在相同设备使用会被认为是一个用户(设备ID相同,对应user_id 也一样),导致出现多个真实用户,被系统识别成一个用户,影响后续的用户分析统计有影响(即用户把手机送给朋友,但朋友的操作行为仍为该用户下)。
1.2.1.3 案例分析
流程说明:
- 安装APP:张三用户在华为手机上新安装了 App,并进入APP进行操作,集成到APP中的SDK会基于设备信息生成设备 ID 为 A,上送的 distinct_id 为 A,海纳嗨数会生成user_id为u01,若客户端SDK 调用接口 profile_set方法 ,则将设备 ID A和 user_id 存入 users 表的 user_id, distinct_id 字段中。
- 登录APP:张三在华为手机上注册并登录,由于是原来的手机设备,发送的 distinct_id 仍为 A,所以user_id 仍为 u01。
- 操作APP:张三登录之后继续进行一系列操作,发送的 distinct_id 仍 为 A,所以user_id 仍为 u01。
- 退出APP:张三退出登录并进行了一系列操作,发送的 distinct_id 仍为 A,所以user_id 仍为 u01。
- 登录APP: 张三把华为手机送给朋友李四了,李四用自己的账号登录,由于手机设备没变,所以发送的 distinct_id 仍为 A,user_id 仍为 u01。
- 操作APP: 李四使用账号 B 在该华为手机上操作,设备 A 上进行了一系列操作,由于设备未变,所以发送的 distinct_id 仍为 A,user_id 仍为 u01。
- 安装APP:张三更换了一个苹果手机,并在APP上进行操作,由于设备 ID 变为 B,发送的 distinct_id 为 B,分配的user_id 为 u02,若调用接口 profile_set方法 ,则将设备 ID为B和 user_id为u02 存入 users 表的 user_id, distinct_id 字段中。
- 登录APP:张三在苹果手机上使用账号 A 进行登录,由于还是苹果手机设备,发送的 distinct_id 为 B,所以对应user_id 仍为 u02。
- 操作APP:张三该登录之后的后续操作,由于还是苹果手机设备,发送的 distinct_id 为 B,所以对应user_id 仍为 u02,只要不更换设备。
1.2.2 方案二:设备 ID 和登录 ID(一对一)
使用设备 ID 标识用户虽然简单,但是对于某些应用场景这种方式不够准确,因此海纳嗨数SDK提供了“设备ID”与”登录ID“的方案,从而解决方案一的局限性,从而更准确的进行用户追踪分析。
1.2.2.1 适用场景
- “设备ID” 和“登录ID”绑定后,用户在该设备ID上或该登录ID下的行为就会进行聚合,被认为是同一个用户行为数据。在进行海纳嗨数用户分析时,更加精准。
- “设备ID” 和“登录ID”绑定实现了更准确的用户追踪,需要增加埋点接入的复杂度。所以需要根据匹配的场景选择适当的方案。
1.2.2.2 局限性
- 一个设备 ID 只能和一个登录 ID 绑定,而事实上一台设备可能有多个用户使用(比如把手机送朋友)。
- 一个登录 ID 只能和一个设备 ID 绑定,而事实上一个用户可能用一个登录 ID 在多台设备上登录(比如用户新买手机)。
1.2.2.3 案例分析
流程说明:
- 安装APP:张三用户在华为手机上新安装了 App,并进入APP进行操作,集成到APP中的SDK会基于设备信息生成设备 ID 为 A,上送的 distinct_id 为 A,海纳嗨数会生成user_id为u01,若客户端SDK 调用接口 profile_set方法 ,则将设备 ID A和 user_id 存入 users 表的 user_id , distinct_id 字段中。
- 登录APP:张三在华为手机上注册并登录,由于是原来的手机设备,这里会调用 SDK 的 login(客户端)或 track_signup 接口(服务端),设备ID(A)和登录ID[zhangsan] 关联成功,那user表中account_id 为zhangsan,distinct_id 为 A,user_id依然为步骤1内部生成的海纳ID。
- 使用APP:张三登录之后继续进行一系列操作,发送的 distinct_id 仍 为 A,所以user_id 仍为 u01。
- 退出APP:张三退出登录并进行了一系列操作,发送的 distinct_id 仍为 A,所以user_id 仍为 u01。
- 登录APP: 张三把华为手机送给朋友李四了,李四用自己的账号登录,由于手机设备没变,在登录过程中设备ID为A尝试与李四进行关联绑定,由于设备ID已经绑定了用户张三,所以李四绑定失败,系统重新创建一个用户lisi,那user表中account_id 为lisi,distinct_id 为 lisi,user_id内部生成的海纳ID[u02]。
- 使用APP:李四使用账号 B 在该华为手机上操作,设备 A 上进行了一系列操作,由于该设备已经标记为lisi,所以发送的 distinct_id 为 lisi,user_id 仍为 u02。
- 使用APP:张三更换了一个苹果手机,并在APP上进行操作,由于设备 ID 变为 B,发送的 distinct_id 为 B,分配的user_id 为 u03,若调用接口 profile_set方法 ,则将设备 ID为B和 user_id为u03 存入 users 表的 user_id, distinct_id 字段中。
- 登录APP:张三在苹果手机上使用账号zhangsan进行登录,由于账户zhangsan已经在用户表中,发送的 distinct_id 为 B,但是已存在用户,所以对应user_id 为 u01。
- 使用APP:张三该登录之后的后续操作,由于用户名没变,所以对应user_id 仍为 u01。
1.2.3 方案三:设备 ID 和登录 ID(多对一)
1.2.3.1 适用场景
客户系统平台有多个客户端(PC端、iOS端、安卓端等),就会出现一个用户可能会在多个客户端设备上进行一系列操作,海纳嗨数分析系统支持一个登录ID绑定多个设备,多个设备的一系列操作会归纳为一个海纳ID(user_id)。
1.2.3.2 局限性
一个设备ID一旦跟登录ID绑定,就不能进行解绑,在其他用户未登录前的一些列操作都会归类为绑定的登录ID,所以在海纳嗨数分析会出现微量的误差。
1.2.3.3 案例分析
流程说明:
- 安装APP:张三用户在华为手机上新安装了 App,并进入APP进行操作,集成到APP中的SDK会基于设备信息生成设备 ID 为 A,上送的 distinct_id 为 A,海纳嗨数会生成user_id为u01,若客户端SDK 调用接口 profile_set方法 ,则将设备 ID A和 user_id 存入 users 表的 user_id , distinct_id 字段中。
- 登录APP:张三在华为手机上注册并登录,由于是原来的手机设备,这里会调用 SDK 的 login(客户端)或 track_signup 接口(服务端),设备ID(A)和登录ID[zhangsan] 关联成功,那user表中account_id 为zhangsan,distinct_id 为 A,user_id依然为步骤1内部生成的海纳ID。
- 使用APP:张三登录之后继续进行一系列操作,发送的 distinct_id 仍 为 A,所以user_id 仍为 u01。
- 退出APP:张三退出登录并进行了一系列操作,发送的 distinct_id 仍为 A,所以user_id 仍为 u01。
- 登录APP: 张三把华为手机送给朋友李四了,李四用自己的账号登录,由于手机设备没变,在登录过程中设备ID为A尝试与李四进行关联绑定,由于设备ID已经绑定了用户张三,所以李四绑定失败,系统重新创建一个用户lisi,那user表中account_id 为lisi,distinct_id 为 lisi,user_id内部生成的海纳ID[u02]。
- 使用APP:李四使用账号 B 在该华为手机上操作,设备 A 上进行了一系列操作,由于该设备已经标记为lisi,所以发送的 distinct_id 为 lisi,user_id 仍为 u02。
- 使用APP:张三更换了一个苹果手机,并在APP上进行操作,由于设备 ID 变为 B,发送的 distinct_id 为 B,分配的user_id 为 u03,若调用接口 profile_set方法 ,则将设备 ID为B和 user_id为u03 存入 users 表的 user_id, distinct_id 字段中。
- 登录APP:张三在苹果手机上使用账号zhangsan进行登录,由于账户zhangsan已经在用户表中,发送的 distinct_id 为 B,且张三已是存在的用户,所以对应user_id 为 u01,但设备B为绑定用户,所以该设备B关联在zhangsan用户下,导致设备B对应的user_id为u03,设置在关联设备用户ID集合(associated_user_id_list)字段下,且将用户为u03的用户记录删除,在数据分析时会将关联设备用户行为数据归类为绑定用户上。
- 使用APP:张三该登录之后的后续操作,由于用户名没变,所以对应user_id 仍为 u01。
1.2.4 总结
三种方案并没有那个更好,建议租户结合自身应用场景选择对应方案。
最后编辑:刘建雄 更新时间:2024-09-05 21:06