项目埋点实现

2.1 需求调研

需求调研的准备工作：

Step 1：熟悉调研产品 --- 提前对调研的产品进行操作并熟悉主流程；了解调研的对象及所属部门。

Step 2：确定调研框架 --- 基于提前体验的产品梳理出的用户生命旅程或遇到的问题，及访谈对象的业务目标，确定调研框架

Step 3：准备调研提纲 --- 梳理已知需求信息，结合产品使用体验，提前准备好需求调研的问题大纲，可按预设时间的2倍去准备问题量（例如：预设调研1小时，就要准备2小时的问题量）

需求调研注意事项：

• 避免什么需求都想要：提需求时避免大而空，大而全，想要覆盖所有用户旅程所有行为的埋点；未从实际业务需求和核心目标出发
• 避免抽象答复：如果遇到业务人员提不出需求或者讲不清需求的时候，需要进行适当引导，将抽象拆为具象需求；例如“我想知道用户喜不喜欢这个产品？“，这个时候就需要我们引导出衡量的标准是什么，才能为后续的指标体系打下基础
• 避免数据需求的模糊定义：针对每个指标，都要明确指标的定义，要严谨，不能出现模糊的情况
• 避免忽略细节问题：一些我们看似容易实现的需求，但是要涉及到跨部门合作或者系统的重构等，需要我们提前预判并及时提出。比如：需求是“想追踪用户的付费推广渠道信息“ ，这就需要产品部门或技术部门对渠道打上标签的需求，那么涉及投放的链接是否可以重新配置并投放，投放平台是否允许添加自定义链接等问题都需要沟通清楚；还有涉及到产品的改版升级，改版的时间和周期等都需要问清楚

需求调研问题案例：

明确需求方目标，了解痛点，知晓预期

产品主要使用场景和过程

针对运营活动的问题

2.2 指标体系

这里输出的指标体系，是经过需求调研后，提炼出的，能解决业务问题的指标体系。

指标体系要有指标层级、指标名称、指标维度组成

指标体系 = 业务主题 + 限定词 + 行为修饰词 + 统计对象 + 计算维度

例如：

指标体系方法论（这里不展开说明每个模型的意义和作用，有需要的同学可以参考我另一篇文章：数据分析思维（2）：走进方法论）

OSM模型：明确业务的核心KPI，能帮助我们快速理清指标体系的大方向，才能赋能业务，一般配合UJM一起使用

UJM模型：从用户角度出发，实际模拟了用户进入产品的整个路径流程，比如注册、登录、点击、加购、购买等流程

AARRR模型：AARRR模型是基于产品角度，通过拉新、促活、付费、留存、推广来了解一个产品的生命周期流程

MECE模型：对核心KPI向下进行3到5层的拆解，就用到指标体系分级治理模型。MECE模型的指导思想是完全独立，相互穷尽，根据这个原则拆分可以暴露业务最本质的问题，帮助数据分析师们快速定位业务问题

指标体系设计注意事项

• 一切维度设计均要从需求调研中的分析需求出发
• 指标是有明确定义的，比如“产品健康度”这样的指标需要有明确的计算公式才具有衡量意义，绝对要避免模糊不清的名字出现

例1：监控过去90天内淘宝下单成功的情况

指标：下单成功人数

时间：过去90天

目标群体：全部用户

维度：无

例2：监控淘宝不同城市的用户下单流程各个环节转化率

指标：浏览到点击转化率、点击到加购转化率、点击到购买转化率、加购到购买转化率

时间：过去X天

目标群体：针对全部用户

维度：城市

例3：希望了解使用【切换城市】功能的用户中，选择异地城市的用户分布情况

指标：用户人数

时间：近X天

目标群体：针对全部用户

维度：是否异地

例4：完成订单的用户中，邮寄偏好的选择情况

指标：完成订单用户人数

时间：过去X天

目标群体：全部用户

维度：邮寄偏好

2.3 埋点方案设计

埋点方案设计的八要素：

• 合理的指标命名及标识符

（1）用中文为事件（指标）、事件属性命名，标识符使用中文的英文翻译；标识符仅支持以字母开头，与数字、下划线组合的字符；区分大小写（详情可以参照Google编程命名规范）

（2）动词 + 名词 或者 名词 + 动词

eg.

加入购物车 --- addToCart

商品点击 --- productClick

（3）各业务线添加各业务线前缀，避免入库时标识符重复

eg.

每个业务线都有查询、搜索等功能时，需要加上前缀：

社区传媒管理系统-社区媒体资源搜索成功：CMMS_mediaReasourceSearchSuccess

• 明确的事件触发时机

（1）事件触发的具体条件要明确清楚

eg.

分享成功：分享链接并被打开算是分享成功，还是分享链接算是分享成功？

浏览量：点击页面打开算是浏览量，还是页面内容加载完毕算浏览量？

• 关联的事件属性及其标识符

（1）事件、属性关系要明确清楚

事件：操作行为，eg. 页面的浏览、搜索等

属性：对事件的描述（维度）eg. 页面的名称、搜索词、城市

（2）设计事件时，需要从分析的维度出发，以【搜索成功】这个指标为例，想要进一步监控用户是用什么搜索词进行搜索时，就需要用【搜索词】这个维度去细分【搜索成功】；以【支付成功订单数量】为例，如果想要进一步监控正是订单的类型，比如是用户自主生成的还是业务员协助生成的订单，就需要用【订单类型】这个维度来拆解【支付成功订单数】

• 事件属性

（1）事件属性的取值，需要以简单易懂的方式穷举，方便后期埋点

eg. 前面提到的【订单类型】属性（维度）需求，需要解释清楚【订单类型】都包含哪些，要穷举出来

（2）建议优先以中文取值，若有些属性无法上报中文，则需要确认取值的内容及是否有影射关系，比如：1 --是，0 -- 否

（3）需要填写取值的样例

• 埋点事件优先级

（1）建议业务方根据优先级将埋点方案里各埋点进行优先级处理，可分高、中、低级别

（2）目的：在资源有限或者时间紧急的情况下，便于做工作排期

（3）

判断原则：

优先保证主业务流程的核心节点，关联的事件属性尽量不排优先级；

其次再保证主业务流程上的非核心节点，更多是涉及用户体验的小节点；

最后是保证其余非核心功能的监控

• 埋点所在端

（1）前端埋点 VS 后端埋点

前端埋点 VS 后端埋点

前端埋点：更详细，但容易丢失和漏埋

后端埋点：更准确，但采集信息有限

（2）在埋点资源上，客户端埋点需要分别对多个客户端开发团队的埋点资源（Android、IOS、PC），而是用服务端埋点，则可以节省多个开发团队的沟通成本

（3）用户无法触发的埋点，只能采用服务端上报的方式

• 埋点事件对应截图示例

（1）为了方便业务或技术更好理解，可以适当加入截图示例

（2）若存在多入口的情况，可以通过截图示例的方式避免漏埋

• 事件属性类型

（1）事件属性类型分为字符串、整数、小数类型

（2）当需要对事件级变量进行运算时，才需选择数值类型；其他情况建议优先选择字符串类型。

（3）整数与小数的区别为是否要精确到小数点后

（4）创建成功变量类型不可修改，如要修改可删除后重新创建

埋点方案文档

事件属性 VS 用户属性

事件属性 VS 用户属性

埋点方案注意事项

（1）善于用【是否xxx】的事件属性

（2）涉及时长的指标都作为埋点事件属性设计，同时触发时机需要是用户行为完成时才触发

eg. 想要监控意向订单指派时长，要明确是否为完成配送时，还是开始配送时间

（3）支付相关的埋点，建议上报唯一ID，方便做核对和追踪

eg. 订单ID作为唯一上报ID

（4）用在漏斗里的指标若涉及不同维度的分析，则需要这些指标都要带上共同的事件属性

eg. 在”查看投放建议-点击提交意向单-提交意向单成功“的漏斗中，还想加上【城市】维度做分析，那么就需要在三个埋点事件中，带上【城市】这个事件属性

（5）监控功能类的埋点一般存在【点击】和【成功使用】两个状态，容易被忽略，同时触发时机需要更明确

eg. 编写触发条件描述的时候，不可以只写”使用XXX触发“，这样的描述不明确

（6）整数、小数的事件属性建议要确定单位

eg. 时间的单位（小时还是分钟？）、金额的单位（元、千元还是万元？）、投放占比（0.6、0.6%还是60%？）

（7）若技术反馈有取不到值的情况，建议上报”-“

eg. 若该变量是暂时取不到值，现阶段还需要保留改变量的情况，可以上报”-“，以减少校验环节的沟通，避免探查时误以为埋点不完善而漏报的情况。若确认变量未来也取不到值，可删除。

2.4 数据校验流程

四种数据校验的工具介绍

• 适合产品经理使用：Mobile Debugger、事件实时查询功能、创建图表查看数据
• 适合技术经理使用：Zeppelin数据库查询

Mobile Debugger数据请求类型及详情介绍

Mobile Debugger数据请求类型及详情介绍

Mobile Debugger 使用场景一

Mobile Debugger 使用场景二

移动端数据校验

事件实施查询详情介绍

通过选择所需要验证的用户（一般为自己），然后在查询结果和数据详情展示框中，看到自己所操作的行为数据上报情况，是否被完全读取

创建图表查询详情介绍

通过创建图表来验证单个指标数据正确

Zeppelin 数据校验：通过SQL查询数据库

数据校验注意事项：

• 准确触发

（1）未触发

原因比较多，需要具体核对，一般是漏埋

（2）延迟上报

前端模块有依赖关系，导致埋点触发时，某些取值未完成数据获取，因此导致延迟上报

（3）错误触发

技术埋点的上报时机不是业务方指定的触发时机

触发的上报事件与埋点文档指定事件或属性不符，例如埋点事件时cstm（消费者）而显示上报的是ppl（游客）

（4）重复触发

可能多埋点导致数据多发

• 准确上报

（1）属性传值不准确

埋点时与业务逻辑不一致

（2）属性漏报

原因比较多，需要具体核对，一般为该属性无法取到值

（3）属性传值不可解读

比如需求上报页面名称，但上报了页面URL

（4）标识符上报错误

当埋点事件或事件属性、用户属性在代码里上报的标识符与埋点工具后台配置的标识符不一致时，会导致数据无法接收

• 覆盖完整

（1）多入口覆盖不全

根据埋点方案中填写的取值依次校验，不能遗漏

（2）多端数据覆盖不全

若存在iOS、安卓、H5、小程序时，需要确保代码在多端同步

• 符合逻辑

（1）需要通过图表来查看数据整体性是否符合业务逻辑

比如说支付逻辑、业务流程逻辑、活动逻辑

数据校验反馈

• 针对每个事件属性进行校验结果的填写，而并非埋点事件；若为未关联事件属性的埋点，可直接针对该埋点校验结果填写
• 写明问题原因，不要写”错误“这类无法明确到具体原因的词。比如：变量未上报、标识符错误
• 建议附上校验截图，方便复查
• 及时沟通校验反馈，讨论解决方案，推动埋点修复

3. 埋点流程总结

埋点的主要流程：需求整理 --> 指标体系 --> 埋点方案 --> 埋点实施 --> 数据校验 --> 数据应用

根据整个埋点的时间划分主要分为三个过程：方案期、实施期、应用期

3.1 方案期

需求整理 --> 指标体系 --> 埋点方案

这个时期主要输出物为：调研问卷、指标体系、埋点方案

3.2 实施期

埋点实施 --> 数据校验

这个时期主要输出物为：埋点方案校验反馈文档

3.3 应用期

这一时期主要是对采集到的埋点数据进行应用，主要的输出物为：BI看板、报表等可视化方式