埋点设计指南
1. 从案例开始
你是否有过这种困扰：好不容易让一些用户接触到了自己的游戏，但在他们登录账号前就因为一些技术问题流失了不少。下面是一个我们利用自定义事件分析完成「用户从打开 App 到真正创建角色」过程中流失的真实案例。 我们当时按照以下思路设计了分析步骤：
1. 确定分析目标：了解用户在创建角色之前的流失情况；
2. 明确具体流程：对用户打开 App 到创建角色的流程进行拆解：
- 点击游戏 icon
- Unity 初始化
- 出现安卓存储权限允许界面
- SDK 初始化 （新增设备记录点）
- 弹出隐私协议确认框【选「否」会退出即 SDK 初始化失败】
- 检查版本
- 确认下载按钮（4G 环境下）/ WIFI 环境下自动下载
- 开始下载资源
- 资源下载中
- 资源下载完成，进入登录界面
- 点击 TapTap 登录按钮
- 跳出弹窗，可选 Tap 打开或者 Tap 加速器打开
- 选择完成，跳转唤起登录授权
- 点击同意，返回游戏
- TapTap 登录完成 （转化设备记录点）
- 游戏服务器认证用户
- 登录游戏服务器
- 输入昵称创角
- 创建成功，进入大厅
3. 定义分析指标：根据上述流程，我们以漏斗思维，设计的几个关键指标为：
- 资源确认下载率（确认下载的用户 / 更新弹窗的曝光用户）；
- 资源下载成功率（下载成功的用户 / 开始下载资源的用户）；
- TapTap 登录率（登录成功的用户 / 点击登录的用户）；
- 角色创建率（角色创建成功的用户 / 登录成功的用户）；
4. 明确事件：一般来说，事件 Event 会有三个类型：
| 事件类型 | 描述 |
|---|---|
| 曝光 | XX 页面的曝光、XX 弹窗的曝光 |
| 点击 | XX 按钮的点击 |
| 系统事件 | 初始化、检查版本、资源下载等 |
在上一步，我们确定了分析指标。接下来我们明确了统计哪些事件可以得到以上数据，初步确定了事件名称和事件类型：
- 曝光：【更新提示弹窗】
- 点击：【更新提示弹窗 - 确认下载按钮】
- 系统事件：【更新下载成功】
- 点击：【首页 - TapTap 登录按钮】
- 系统事件：【登录成功】
- 系统事件：【成功创建角色】
5. 定义事件属性： 基于事件名和事件类型，我们整理了更完整的埋点文档如下：
| 事件名 | 事件显示名 | 属性名 | 属性显示名 | 属性值 | 触发时机 |
|---|---|---|---|---|---|
| pv_download | 更新提示弹窗 | #ts | 时间戳 | 弹窗展示时触发 | |
| click_download | 更新提示弹窗 - 确认下载按钮 | #networtype | 网络类型 | WiFi、4g、5g、3g、2g | 点击按钮时触发 |
| download_success | 更新下载成功 | #ts | 时间戳 | 系统后台触发 | |
| login_start | 首页 - TapTap 登录按钮 | #ts | 时间戳 | 点击按钮时触发 | |
| login_success | 登录成功 | #ts | 时间戳 | 系统后台触发 | |
| create_role | 创建角色 | #ts | 时间戳 | 创建角色成功时触发 |
通过以上步骤，我们就完成了埋点的设计。
随后我们将准确无误的埋点信息（事件名、事件显示名、属性名、属性显示名）录入 TapDB 的「配置」-「事件管理」。
研发根据的埋点文档进行埋点开发，开发完成后进行数据校验。
埋点上线后，我们使用「事件」和「看板」功能对「 用户从打开 App 到真正创建角色」过程流失用户进行分析，如下图所示：
「更新下载成功（步骤 3）」到「首页 - TapTap 登录按钮（步骤 4）」的转化率非常低，接下来就需要进行详细的数据分析。点击 TapDB 使用指南 查看详细数据分析方法。
2. 埋点设计思路
我们根据这个案例总结了以下思路，建议参考以下步骤进行埋点设计：
1. 确定分析场景；
2. 明确具体流程；
3. 定义分析指标；
4. 明确事件：设计 Event，确定其类型，名称等细节；
5. 定义事件属性：明确所需要的信息，通过事件属性完成上报；
3. 其他设计技巧
3.1 Event 的同类抽象
在进行事件设计时，可能会遇到以下问题：
- 要统计三个关卡 A、B、C 的通关情况，对每个关卡设计一个通过事件吗？
- 在设计「申请验证码」的功能埋点时，用户注册时、用户登录时、修改密码时等多场景都会下「申请验证码」，对每个场景设 计一个「申请验证码」事件吗？
关于不同场景下的行为是否设置为同一个 Event，我们可以基于同类抽象判断原则：
- 重要的事件行为或者特别关注的事件行为，可以单独将事件行为作为单独 Event 进行跟踪和属性设置；
- 重要程度一般的行为，比如只需要分析参与次数、参与人数的行为，可以将多个相似类型的行为设置成一个 Event，通过属性的方式标识具体的行为；
- 不同关卡通关情况的事件设计：如果简单统计三个关卡 A、B、C 的通关情况时，不需要做成 「A 关卡通关」、「B 关卡通关」、「C 关卡通关」 三个事件，只需设计成 「关卡通关」 事件，将 A、B、C 三个关卡名以属性 「关卡名称」 进行标识。
- 「申请验证码」的功能埋点：可将其定义为一个事件「申请验证码」，并在属性字段增加 「场景」，借此从场景来区分用户究竟在什么情况下申请验证码。
3.2 Event 的命名规范
在设计事件显示名时，注意确保事件没有二义性。按照 页面名-模块名-具体事件名的方式来命名，可以帮助分析师通过名字与备注准确理解事件所代表的用户行为。要避免因为说明的不准确而引发错误的分析结论。 对 App 页面和模块命名进行统一的梳理和维护是有意义的准备工作，它帮助我们确保了所有人的理解是一致的。