如何正确地标识用户

大部分情况下，一个用户只有一台设备且您需要达成如下目标：

  1. 理解用户标识和用户关联

  2. 理解神策支持的用户关联方案

  3. 确定待接入产品的关联方案

准确地标识用户，做好用户关联，是用户行为分析的基础。

如果有一丝纰漏，后续得到的统计或分析结果，都将被打上问号，因此请高度重视本节内容。

用户标识及关联

在真实世界中，我们通过身份证号来准确标识一个自然人，在互联网业务体系中，这种方式不再适用。于是产生了两种常见方案，第一种是通过用户的设备 ID 来唯一标识这名用户，这种方式在一定程度上解决了用户标识的问题，但是这种方案缺点也很明显，比如，同一台手机被多个用户用过，产生的行为被标记为同一个“人”；而老用户换新手机也会被识别为一个全新的用户；等等问题最终都将导致数据分析的结果不准确。第二种方案则是通过用户的账号或者客户号来识别用户，这种方案在业务后台系统中比较常见，但是用户在未登录状态下发生行为是无法被识别的，因此这种方案只能准确地记录业务数据，主要在业务数仓的搭建中充当用户标识。

神策充分考虑了每种方案的优劣，制定了完善的用户标识体系。关于神策是怎么标识用户的，推荐阅读《如何准确的标识用户-基础概念》。

简单来说，在用户未登录的情况下，神策会选取设备 ID 作为唯一标识，登录状态下选取登录 ID 或者 userid ，一个用户既有设备 ID（亦称作“匿名 ID”）又有登录 ID。

接下来，通过“用户关联”将同一个用户的设备 ID 和登录 ID 关联到一起，这样不管用户是匿名和登录的状态发生的行为，我们都能准确识别到是同一个用户，这是目前为止较为通用且准确的用户标识方式。

神策支持的用户关联方案

大部分情况下，一个用户只有一台设备，因此一个用户只会有一个设备 ID 和一个登录 ID，针对这种情况，神策提供了设备 ID 和登录 ID 一对一关联的方案，详见：一对一关联方案。

针对一个用户有多台设备的情况，神策提供了多设备 ID 和一个登录 ID 之间的多对一关联的方案，详见：多对一关联方案。

此外，这种关联方案也适用于产品存在多个端的情况。比如，同时有小程序端，App 端，Web 端，此时用户在每个端的设备 ID 都不一样，等同于是一个用户会有多设备的情况。

一对一和多对一的关联方案各有优缺点，神策默认推荐使用一对一的关联方案。

当然少数情况下，产品可能没有用户账号体系，比如记事本，闹钟这类工具型产品。

针对这种情况下，我们可以选择只使用设备ID 作为用户标识即可。

详见：只使用设备 ID。

确定待接入产品的关联方案

在了解完毕神策所支持的关联方案之后，您需要为本次接入的产品确定关联方案。

需要确定的内容主要包括如下几点：

确定项 说明
关联方式 需要选择一对一还是多对一的关联方案，系统默认的是一对一的方式，如需开启多对一请联系对应的客户成功
first_id 神策在各端默认选取的设备 ID 供参考，考虑到部分客户的需求，可以选择调用 identity 接口对其进行替换
second_id 通常选取 user_id，如有其它可唯一标识用户的 id 亦可
关联时机 一般在用户发生注册、登录以及第三方登录时进行关联，另外初始化 SDK 之后，也需要调用神策的“关联接口”

建议业务方和技术方共同参与 ID 关联方案的确认。确认之后，业务方随即可以开始下一步工作。第 3 步：采集方案设计。

技术人员也可以开始做一些准备工作，包括 SDK 嵌入及初始化，ID 关联方案的实施与测试，详见第 4 步：基础数据校验。

注：本文档内容为神策产品使用和技术细节说明文档，不包含适销类条款；具体企业采购产品和技术服务内容，以商业采购合同为准。

采集方案设计

本节您需要达成以下目标：

  • 理解采集方案设计的思路

  • 了解数据采集方案的书写规范

  • 根据业务需求编写数据采集方案

什么是采集方案设计

采集用户行为数据，首先需要根据业务分析需求明确采集的目标行为，进一步搞清楚应该在哪些地方埋什么样的点。

这个环节的输出物一般被称之为“埋点需求文档（DRD）”。

在大部分互联网公司，规范的产品迭代流程是，业务侧产品经理在输出“产品需求文档（PRD）”的同时，数据产品经理或分析师等角色需要同步输出 DRD，双方的需求同步进入开发和测试验收。

由于神策的底层数据模型是 Event + User 的事件模型，因此埋点在神策分析里被称之为“事件”，埋点需求文档则被统称为“采集方案设计”，本节的工作需要借助神策方提供的《数据采集方案》模板来完成，请联系对应的客户成功或分析师提供。

采集方案设计思路

采集方案设计的核心思路，大体来说分为如下几点：

  • 将用户行为拆解为单个的点击或浏览动作；

  • 将需要分析的目标动作抽象为“事件”，添加事件维度；

  • 根据业务需求，整体完善采集方案设计；

为此我们录制了一个讲解视频，采集方案设计思路。

浏览后如仍有疑问，请联系对应的分析师。

数据采集方案模板

为了帮助您理解数据采集方案模板，我们录制了另一个讲解视频，数据采集方案模板。

浏览后如仍有疑问，请联系对应的分析师。

4. 数据采集方案设计常见问题

4.1. 结合场景设计事件

对于相似场景，比如，提交门票订单，提交机票订单，在设计事件时是针对每个场景单独设计还是合并成一个事件？

有两种设计思路共参考：

A. 设计为同一事件，适用场景：各事件所需属性相差不大；平时分析场景多整体分析。

B. 设计为不同事件，适用场景：各事件所需属性相差很大；分析场景多分别分析。如果采用本思路，也建议在一些相同属性上用一样的属性名称，便于今后使用“虚拟事件功能”来整体分析。

例: 简单的统计三个按钮 A、B、C 的点击情况时，不需要做成 “点击 A 按钮”、“点击 B 按钮”、“点击 C 按钮” 三个事件，而是做成 “点击按钮” 事件，将 A、B、C 三个按钮以属性 “按钮名称” 进行传递。

4.2 被动事件

被动事件：由于神策分析中的漏斗分析、留存分析等都需要事件的触发主体是同一个人，所以在一些场景下需要给用户触发被动事件，如用户提交认证后，需要审核，审核并不是由用户主动触发，可设置为被动事件。

4.3. 自定义指标计算要求

在事件分析的自定义指标计算中，我们可以做各个事件指标的四则运算。对于需要计算的属性，需要其属性值类型为数值。

4.4. Users 表注意的问题

单边，双边用户

单双边是针对产品有多个身份使用用户时才会进行区分。

单边用户，即仅有一类用户的产品，如健身产品 Keep ，聊天工具 QQ 等 ;

双边用户如 O2O 产品，用户可能是普通消费者，也可能是商家用户。

需要根据产品的不同，提前对用户识别和相应属性进行设计。

缓慢变化维

如果遇到一些会发生变化的属性，比如用户的 VIP 等级，不能只作为用户属 性传进用户表中，还需在事件表中，记录一个 “当前发生事件 VIP 等级” 这个 属性。

因为当前会员等级的统计，和发生事件时用户的会员等级统计是两种情况。

基础数据校验

本环节由测试人员完成，需要完成的任务如下：

  • 对事件和属性的完整性及数据类型进行校验

  • 对用户关联情况进行校验

  • 验证 App 与 H5 打通（做了打通的情况下）

1. 事件和属性完整性校验

进入神策分析页面，点击【元数据】，查看元事件和属性字段，请注意此时事件和属性显示名仍是英文，后续需要统一调整为对应的中文名。

检查项如下：

1.1. 检查事件及名字是否与《数据采集方案》一致。

事件是否有遗留或新增。如有新增事件可能是开发人员测试产生的，需要开发确认相关的埋点代码已经清除。

如有遗留则可能是漏埋了或者埋点了但是未传输过数据。

1.2. 点选事件名，检查其包含的属性是否完整，名字和类型是否正确。

属性是否有遗留或新增。

这块遗留的情况比较常见，可能是漏埋了。

属性值类型是否与数据采集方案一致。如不一致，请开发在代码里修正变量类型，然后联系技术支持同学修改变量类型，修正后的数据才可正常入库。

或者另取一个属性名，数据即可直接入库。

事件

2. 对用户关联情况进行校验

在开始本小节的校验之前，请提前阅读 第 2 步：

如何准确的标识用户 并确定理解了用户关联的概念和方案。

该环节需要结合神策分析中“自定义查询”的功能来操作，校验的目的有 3 点：

  • 检查 first_id 取值是否存在异常，是否有将 second_id 写入 first_id 的错误操作；

  • 检查 second_id 取值是否异常，是否有正常关联的用户存在；

  • 检查用户 ID 关联过程是否正常。

2.1. 检查 first_id 取值

查询 users 表，检查查询结果中 first_id 是否为设备 ID，以及是否存在异常情况。

以下是各端 SDK 默认取的设备 ID ，可根据 ID 格式大致判断 first_id 取值是否正常。

查询 sql： select * from users limit 1000
SDK 类型 ID 样式
Android 端 01c23e12e10a7810（AndroidID 为 16 位 ，字母+数字组成）
iOS 端 447BAE19-7117-4D1B-81E2-7B46AA7998A4（IDFA / IDFV / UUID 为32位，8-4-4-4-12）
H5 端 15ffdb0a3f898-02045d1cb7be78-31126a5d-250125-15ffdb0a3fa40a
微信小程序 oWDMZ0WHqfsjIz7A9B2XNQOWmN3E（28 位，字母+数字组成）

上面查询结果中可能存在的常见情况有：

first_id = second_id，这种情况可能是正常的，如果开发人员在同一台设备上登录过多个账号，则除了首个登录的账号会进行正常关联外，其余账号均会发生自关联，即出现 first_id = second_id = 账号 ID 的情况。

first_id 的实际取值不是设备 ID，而是账号 ID，而 second_id 取值为空，这种情况代表着 second_id 误写入了 first_id，可通过下方SQL 进一步检查。

查询 sql：SELECT u1.first_id, u1.second_id, u2.first_id, u2.second_id FROM users u1 JOIN users u2 ON u1.first_id = u2.second_id WHERE u1.second_id IS NULL;

如果以上查询有返回结果，原因可能但不限于如下情况:

  • $SignUp 事件传送失败，导致没有关联成功;

  • 后端在传 distinct_id 时没有设置 is_login_id 的参数值为 true;

  • 调 login 时误调用了 identify，将登录 ID 替换了匿名 ID。

2.2. 检查 second_id 取值

查询 users 表，观察 second_id 取值是否是预设的 user_id 或其他用户唯一标识。

注意，在测试环境中 second_id 大部分为空的情况可能是正常的，开发人员可能仅对少量测试账号进行了 ID 关联的尝试。

检查是否有正常关联的情况存在，即 first_id 取值为设备 ID，second_id 取值为 user_id

2.3 检查用户 ID 关联过程是否正常

在 users 表的查询结果中，选取一个正常关联的情况的 id（users 表的 id 字段）在events 表中查询行为记录。

查询 sql：select * from events where user_id = "选取的id不用加引号" order by time

查询结果中主要观察的点，首次触发 $SignUp 事件前后，events 表中的数据记录的 distinct_id 字段前后取值会由设备 ID 替换为 user_id。

存在这个情况便表示存在有正常关联的过程。

如果您采取的是多对一的关联方案，请联系对应的分析师协助这部分内容的校验。

3. 验证 App 与 H5 打通

做了 App 与 H5 打通 的情况下，才需要进行本环节的验证。

如果是开发人员，进入神策分析页面，点击【埋点管理】—>【实时导入数据查询】，事件名选择 “$pageview” ，点击【开始刷新】实时查看具体事件及属性是否正确。

在手机上，打开 App 进入到 H5 页面。

看 “$pageview” 事件的属性，如果有 “$wifi” “$network_type” 、“$app_version” 、“$carrier”等字段，说明 App 和 H5 打通成功。

（或者开启 SDK 调试日志后，在开发工具的控制台，通过输出的事件日志信息来核对）

需求梳理

埋点：全埋点 主动埋点

元数据管理：事件类型，原始数据。

事件的管理：CRUD+导入+导出

用户的管理：sessionId 用户的新增与流失。

多端统一：如果有登录，那么多端是可以统一的。

文件的统一管理

参考资料

https://manual.sensorsdata.cn/sa/latest/%E5%A6%82%E4%BD%95%E6%AD%A3%E7%A1%AE%E5%9C%B0%E6%A0%87%E8%AF%86%E7%94%A8%E6%88%B7-7538292.html