数据埋点方案和规范确定

用户的行为分析是产品调整迭代，运营推广、精准营销等的基础，此类行为的一切均基于良好的数据采集方案。当下几乎所有互联网公司的数据源都是通过埋点方式获得基础的业务数据。

简单来说，数据埋点就是传统的数据打点，在网站或者APP中加入一些统计代码进行数据采集。具体埋点的价值以及正确埋点的重要性已经无需多言，基本上所有的产品或者数据人员都得需要了解自己业务的埋点方案。

基本的埋点介绍和流程相对比较固定：

作为产品经理或者数据分析人员，本身未必需要完整的掌握埋点的技术，但是作为数据需求方在了解完整埋点方案的情况下，需要着重考虑两个方面以确定埋点方案和可行性。

一 基于哪些维度埋点

埋点的目的是为了获取有效的数据，而数据是否有效是由数据需求拆解到具体 “指标 + 维度”。

1 基于谷歌分析的AARRR模型来拆分产品方案，通过产品逻辑拆解出分析维度和业务逻辑。

AARRR（分别是指获取、激活、留存、收入和推荐）

正常情况下数据埋点的事件维度是基于一个Session,即一个用户完整的从注册进入系统到注销退出系统之间所经过的时间。拆解用户的产品逻辑判断出用户所属的周期继而制定分析的维度。比如整个产品体系处于初生期，整个运维的重心在于获客，整个逻辑是用户通过不同的渠道来源进入APP，继而留存或流失，埋点的重心必然是在如何获客的渠道来源上。

2 基于后期分析方法判定埋点目标

任务流分析法：根据产品设计的任务流，在任务流开始和结束处埋点，分析用户处理任务的情况。

页面转化分析法：统计相关页面的转化率及页面元素点击率，分析用户行为。

情景分析法：列出各种用户使用场景，自己或多人体验不同场景下产品的使用流程，寻找依据设立数据埋点，通过数据反馈验证用户行为。

埋点前首先要考虑清楚埋点的目的，比如是为了获取用户群体的某些行为特征以更深层次地理解用户，又或者是为了检验新功能的使用情况是否符合预期，再或者是监控程序运行过程中的异常情况。其次要考虑清楚如何利用结果数据去达到你的目的，一般来说目的明确，接下去也很顺畅了。

3 基于商业目的埋点

首先基于产品和业务确定商业目标，继而将商业目标拆解。比如盒马鲜生的商业目标是营收。营收就可以拆解=用户量*客单价*净利润，再细分用户群=实体店流量+线上用户量。等等，继续拆解。不断的细分拆解，一直到最后的支付环节。完整的梳理交互流程，主要从关键行为的页面和入口来分解，此外还有一些不依赖APP本身的入口，比如短信营销、外部分享等。

根据所有梳理出的关键行为，生成相应的埋点方案。等到埋点回溯之后，就可以从下至上，从数据还原整个商业目标，以便实时监控和分析了。

二 形成统一规范的埋点方案或者埋点表

目前大部分公司基本上是采用第三方数据统计平台，不同平台的埋点文档大同小异，但是同一个公司如没有统一的埋点规范和埋点管理平台，就会留下大量的坑。（一千个产品有一千个规范，一千个点可能就有一千个坑），因此标准的埋点文档很有必要。

数据埋点是为了更好的数据采集，通常记录用户行为的基本要素采用4W+1H的方式，即人物（Who）、时间（When）、地点（Where）、行为（What）、方式（How）。用户在什么时间什么地点使用什么方式产生了什么样的行为来记录。

人物（Who）：参与事件的用户，一般使用开发过程中对用户定义的唯一ID，包含用户的设备ID、UserID、等非敏感信息。对用户的姓名、手机号、身份证号码等敏感信息不建议直接采集，如必须采集可采用脱敏的方式进行。

时间（When）：记录行为发生的时间，常见标准的YYYY-MM-DD HH-MM-SS的时间戳以外还可以使用服务端的Session或登录序号等。记录值将用于区分用户的登陆次数，界定活跃次数和行为归属。

地点（Where）：记录行为发生的地点，包括用户的IP地址、GPS位置、场景或来源（WEB/微信/APP）。

行为（What）：事件的内容，即发生的细节，可以采用记录事件的属性/参数生成记录值，常见格式为Key-Value模式。

方式（How）：事件所处环境和发生方式，常见的记录值有：网络环境（WIFI/4G）、系统版本（iOS 12.0.1/Android 8.0)、设备型号（HUAWEI/XIAOMI/Apple）。

下面是部分第三方公司的数据平台结构和埋点

诸葛IO：

友盟：

神策分析：

Growing IO

百度统计

各个平台基于事件维度，同时有一定的个性维度组建了数据分析维度。但是整体的埋点基本上符合几个维度，这这些维度的基础上随着业务线的延展扩充和下钻深度。

（1）事件类型字段：用于说明当前埋点是点击事件还是浏览

（2）中文名字段：用于描述X功能模块内X位置，例如起名叫：支付页——扫码

（3）事件ID字段：每一个埋点都对应唯一一个事件ID，可以通过事件ID去后台取数使用。事件ID的命名规范各个公司不一样，但一定要明确详细。比如翼支付某一个页面ID，011212131212,每两个数字都代表不同的含义，前两位代表部门等等。通过限制区分保证页面ID的唯一性和有效性。

（4）记录规则字段：定义什么情况下触发埋点，例如：在列表页点击一次记录一次

（5）描述字段：每一个完成的页面埋点或者按钮点击的埋点都需要加一个描述字段进行业务阐释

(6）备注字段:用于描述当前埋点什么时间新增？什么时间修改过？原因？什么时间被删除？谁删除的？等信息记录，为了信息的完整性和可追溯性最好每一次变动都要备注。

以上均为最简单APP中所需要的必备字段，随着业务线的扩展以及细分产品的增多，越来越多的按钮和页面会出现在二级页面甚至在三节界面。埋点方式和查询方式与主界面方式一致的

如下为一些现有APP的埋点样式：

确认埋点区域、内容、形式和APP产品逻辑的对应后，将所有需要埋点的内容整理成埋点方案。撰写方案过程中要注意：

• 业务名称即APP上的功能或事件名称，以保证方案内容与APP呈现对应关系；
• 事件ID命名时，一定要保证唯一性
• 自定义事件ID设定时遵循唯一性排他性，不可出现重复命名
• 数据标签不是越多越好，在满足功能需求下尽可能简洁。越繁琐的埋点文档越容易产生不一致。

当然，埋点文档的完成必须和技术侧双方达成一致且有效才算第一步完成，最后的的数据校验才才能算是埋点有效。

未经允许不得转载（声明：本文内容由互联网用户自发贡献自行上传，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任。如果您发现有涉嫌版权的内容，欢迎发送邮件至：net-net@foxmail.com进行举报，并提供相关证据，工作人员会在10个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。）：策信智库资讯网 » 数据埋点方案和规范确定