埋点设计指南
#
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 的同类抽象在进行事件设计时,可能会遇到以下问题:
1、要统计三个关卡 A、B、C 的通关情况,对每个关卡设计一个通过事件吗?
2、在设计「申请验证码」的功能埋点时,用户注册时、用户登录时、修改密码时等多场景都会下「申请验证码」,对每个关卡设计一个「申请验证码」事件吗?
关于不同场景下的行为是否设置为同一个 Event,我们可以基于同类抽象判断原则:
- 重要的事件行为或者特别关注的事件行为,可以单独将事件行为作为单独 Event 进行跟踪和属性设置;
- 重要程度一般的行为,比如只需要分析参与次数、参与人数的行为,可以将多个相似类型的行为设置成一个 Event,通过属性的方式标识具体的行为;
1、不同关卡通关情况的事件设计:如果简单统计三个关卡 A、B、C 的通关情况时,不需要做成 「A 关卡通关」、「B 关卡通关」、「C 关卡通关」 三个事件,只需设计成 「关卡通关」 事件,将 A、B、C 三个关卡名以属性 「关卡名称」 进行标识。
2、「申请验证码」的功能埋点:可将其定义为一个事件「申请验证码」,并在属性字段增加 「场景」,借此从场景来区分用户究竟在什么情况下申请验证码。
#
3.2 Event 的命名规范在设计事件显示名时,注意确保事件没有二义性。按照 页面名-模块名-具体事件名的方式来命名,可以帮助分析师通过名字与备注准确理解事件所代表的用户行为。要避免因为说明的不准确而引发错误的分析结论。 对 App 页面和模块命名进行统一的梳理和维护是有意义的准备工作,它帮助我们确保了所有人的理解是一致的。