一文详解数据埋点｜马同学的数据笔记

数据流程：数据生产-数据采集-数据处理-数据分析和挖掘-数据驱动/用户反馈-产品优化/迭代。

数据埋点是基于业务需求或产品需求对用户在应用内产生行为的每一个事件对应的页面和位置植入相关代码，并通过采集工具上报统计数据，以便相关人员追踪用户行为（点击、浏览），推动产品优化或指导运营的一项工程。

为什么要做数据埋点？

埋点将产品数据分析的深度下钻到流量分布和流动层面，通过对产品中的用户交互行为的统计分析，对宏观指标进行深入剖析，发现指标背后的问题，寻找人群的行为特点和关系，洞察用户行为与提升业务价值之间的潜在关联，了解组成特定数据现象的原因，并据此构建产品优化迭代和运营策略。

• 获取关键指标。埋点可以获得一些关键指标——浏览人数、点击率、转化率、退出率等等。
• 定位问题，监控产品的流畅性，挖掘流失点，优化产品。（漏斗优化、用户增长、流失用户预警）通过获得来的数据，我们可以判断出哪些功能模块对于用户有较强的吸引作用，哪些功能模块用户浏览、点击较少，从而定位出问题，对产品进行改进。
• 分析运营策略的合理性，优化用户体验，提高使用效率。（精准营销、场景化提示/私人助理）比如用户去餐厅购买产品，每次都需要在APP中选择是否使用优惠券，但是通过埋点发现，全部的用户对于该商家都是选择的否，那么说明该商家是从来没有进行优惠券的发放，那么就可以考虑在商家版中增加一个是否让用户选择优惠券的选项，若商家没有优惠券，那么用户就可以直接跳过选择是否使用优惠券，从而提升用户体验及使用效率。
• 分析用户消费行为，分析不同渠道用户行为差异。（风险识别）

埋点方式

前端的埋点方式主要分为代码埋点、可视化埋点、无埋点三种。

1.代码埋点

在终端嵌入SDK，定义事件并添加事件代码，用户所有操作行为会调用SDK的相应数据接口然后把数据发送服务端（数据库）。按需采集，业务信息更完善，对数据的分析更聚焦，因此代码埋点是一种以业务价值为出发的行为分析。

• 优点：数据准确性高，自定义程度高，具有很强的灵活性，可以控制发送的时机和发送方式等。

埋点准确性顺序：代码埋点＞可视化埋点＞全埋点，SDK较小，对应用本身的使用体验没有影响，是最可控的埋点方式。

• 缺点：需要开发工程师手工开发，工作量大，人力成本较高；有时候还要依赖App发版来生效。
• 市面上产品有：GA（google analytics）、友盟、百度统计

举例·应用场景：

• 如果你不希望在采集数据的同时，降低用户体验
• 如果你不希望采集到海量无用数据
• 如果你希望采集的数据：颗粒度更细，维度更多，数据分析的准确性更高那么，从业务增长的长远价值考虑，请选择代码埋点。
• 常见的如：页面停留时间，页面浏览深度，视频播放时长，用户鼠标轨迹，表单项停留及终止等等。尤其是一些非点击的、不可视的行为，是非要代码埋点来实现不可了。

2.可视化埋点

可视化埋点以前端可视化的方式记录前端设置页面元素与对其操作的关系，然后以后端截屏的方式统计数据。无须进行添加代码，只需在相应应用界面追加事件数据点即可（对于点击操作的埋点是目前可视化埋点的主攻点）。核心代码与资源配置器分开，当启动应用时从服务端更新配置和资源，应用根据新的配置和资源发送数据。

支持可视化埋点的SDK 会在被监测的网站或移动应用被访问时向服务器校验是否有新的埋点，如果发现更新的埋点，则会从服务器下载并且立即生效。这样就能确保服务器收到最新的埋点后，所有客户端都能在下一次访问时得到部署了。

• 优点：界面化配置，无需开发（可视化埋点的理念是提升原工作流程的效率——依然要梳理需求、设计埋点），埋点更新便捷，生效快（可直接在网站或移动应用的真实界面上操作埋点，而且埋点之后立即可以验证埋点是否正确，而且将埋点部署到所有客户端也是几乎实时生效的。）。
• 缺点：不灵活，存在部分数据死角（埋点自定义属性支持较差；重构或者页面变化时需要重新配置），同时每次启动加载服务端配置资源，消耗资源；从实际情况看，复杂页面、不标准页面、动态页面都给可视化埋点增加不可用的风险，一旦遇到就还是只能代码埋点了。
• 市面上产品有：诸葛IO、神策

3.无埋点/全埋点

无埋点采用“全部采集，按需选取”的形式，通过绑定页面的各个控件，当事件触发时就会调用相关的接口上报数据。并不是说不要埋点，而是SDk利用css选择器技术和监听控件的事件触发技术，在应用嵌入SDK，SDK会把页面中所有交互元素的用户行为数据尽可能的采集下来，通过“统计数据筛”，配置待处理的数据的特征。

无埋点/全埋点优点：可视化展示界面，部署简单、收集数据多，一切操作皆埋点，无需埋点统计数据按需处理

无埋点/全埋点缺点：

1. a)     无埋点只能采集到用户交互数据，且适合标准化的采集（无埋点无法深入到更细、更深的粒度），自定义属性的采集需要代码埋点来辅助（现阶段全埋点对于用户身份信息和行为附带的属性信息也几乎无能为力。）。
2. b)    无埋点具有前端埋点的固有缺陷，如数据采集深度较浅、传输时效性较差、数据可靠性无法保障等问题。
3. c)      数据维度单一（仅点击、加载、刷新）；影响用户使用体验——用户使用过程中容易出现卡顿，严重影响用户体验；噪点多，数据准确性不高，容易产生干扰；不能自定义埋点收集信息。
4. d)     全埋点的“全”以采集上报的数据量为代价，随着数据量上升导致客户端崩溃的概率也会上升。尤其是移动端，更多的数据量意味着更多的电量、流量和内存消耗。从这个角度来看，想做到真正的“全”在现阶段也是很难。即使全部行为数据可以被接收回来，具体分析时的二次梳理和加工也无法避免，甚至痛苦。因为机器无法在采集时能按照我们想要的方式对全部事件进行有意义的命名，甚至无法保证采集上来的事件都正好是正确的。于是前期埋点时节省下来的人力成本，这个时候又都搭进去了。
5. l  应用场景：

主要应用于简单页面，比如：短期活动中的落地页/专题页中，需要快速衡量点击分布等效果。

• 产品：Heap Analyitcs、诸葛IO

最理想的埋点方案是根据根据不同的业务和场景以及行业特性和自身实际需求，将埋点通过优劣互补方式进行组合，比如：

1、代码埋点+全埋点：在需要对落地页进行整体点击分析时，细节位置逐一埋点的工作量相对较大，且在频繁优化调整落地页时，更新埋点的工作量更加不容小觑，但复杂的页面存在着全埋点不能采集的死角，因此，可将代码埋点作为辅助，将用户核心行为进行采集，从而实现精准的可交叉的用户行为分析；

2、代码埋点+服务端埋点：以电商平台为例，用户在支付环节，由于中途会跳转到第三方支付平台，是否支付成功需要通过服务器中的交易数据来验证，此时可通过代码埋点和服务端埋点相结合的方式，提升数据的准确性；

3、代码埋点+可视化埋点：因代码埋点工作量大，可通过核心事件代码埋点，可视化埋点用于追加和补充的方式采集数据。

埋点事件

在记录埋点信息时，主要的埋点事件分为点击事件、曝光事件、页面事件三类。

1)  点击事件

用户在应用内的每一次点击行为，都可以记为一次点击事件。比如按钮的点击，区域的点击，商品的点击，每一条新闻的点击等，都可以成为一个点击事件。一般通过点击事件，可以拿到点击PV，点击UV。

2)  曝光事件

曝光事件是为了统计应用内的某些局部区域是否被用户有效浏览。比如推荐区域，某个按钮，首焦等等。

比如一般来说我们在衡量页面某个区域用户的点击率的时候，首先需要搞清楚的就是这个区域到底被多少用户看到了，每被用户看到一次就是一个简单的曝光事件，然后才能计算点击率。

做曝光埋点的时候需要注意两个事情：第一，有效曝光的定义要科学，合理；第二，为了不影响页面性能以及用户体验，不能在应用内的所有区域都加曝光埋点。

曝光埋点即不发生点击行为，内容曝光时上报的埋点，多用于内容流（商品流）的数据分析，用来计算CTR（点击通过率，点击次数/曝光次数），用户时长（曝光时长）。

下面以某电商App首页商品流为例做埋点示例：

3）页面事件

页面事件通常是指页面的各种维度信息的统计。常见的比如页面浏览PV，页面浏览UV。

页面事件通常通过页面参数来传递。

页面事件通常统计的信息包括以下几个部分：

• 浏览器信息：浏览器版本，浏览器语言，浏览器编码，屏幕分辨率等；
• 访问信息：用户账号，当前页面url，上次访问时间，访问时长，页面停留时间等；
• 来源信息：广告来源，上一页面url等；
• 物品信息：不同的业务，这部分信息区别很大。

现在App端的数据埋点一般采取Key-Value的形式，Key一般表示某个事件，Value代表相对应的值，一个Key可以对应一个Value或者多个Value。在埋点过程中，同种属性的多个事件要命名成一个埋点事件ID，并以Key-Value的形式区分。不同属性的多个事件应该命名成多个埋点事件ID，此时也尽量不用Key-Value的形式埋点。

事件三要素：

• 操作（action），定义一个操作动作，如点击（click）、浏览（view）
• 属性，这个事件相关的内容，比如一个商品浏览事件，属性包含商品ID、商品标题、商品价格、所属店铺等信息。
• 属性值，则表示该属性对应的值，例如商品标题=“日本品牌一次性医用口罩…”

埋点流程

• 运营：一主要需求方，根据业务场景，提出并明确具体的数据分析需求。
• 数据产品经理：收集业务方的需求，将分析需求整理成埋点需求，并组织埋点需求评审、校验埋点数据。
• 开发团队：确认埋点可行性和排期，负责埋点开发、测试和上线。

（1）业务需求：确定场景或目标

梳理业务，确定一个场景/目标。

需求阶段：进行需求采集和需求分析，保证埋点满足核心业务需求。

• 数据需求池：对数据需求进行整体维护，记录需求业务场景、需求内容、提出者、时间等
• 产品信息架构：梳理产品结构，熟悉产品（梳理产品交互架构和页面设计布局）。
• 用户行为路径：分析用户路径，建立用户行为流程图，得到核心业务指标，定义好该事件的触发时机

优先级评估——KANO模型

KANO模型定义了三个层次的用户需求:基本型需求、期望型需求、兴奋型需求。

这三种需求根据绩效指标分类就是基本因素、绩效因素和激励因素。

（2）埋点设计：数据采集规划，确定关键指标

设计阶段：埋点版本规划和埋点设计(1，确认事件与变量；2，明确事件的触发时机；3， 规范命名；4，明确优先级)

• 埋点版本规划：根据需求优先级，分版本上线，快速迭代；
• 埋点文档：详细描写版本记录、数据流程图、埋点事件等内容；
• 埋点的基本信息：业务、等级、应用、使用说明、打点时机、测试说明、需求文档等；
• 埋点对应角色：产品经理/业务部、数据产品经理、开发团队；
• 埋点对应字段和字段取值。
• 埋点位置。即需要添加埋点相关信息的位置，比如页面上的按钮，搜索结果的每一个卡片，推荐位上的每一个卡片，每一个曝光区域等等；
• 埋点标识。每一个位置上面需要设置一个埋点的标识来代表这个点击位；
• 埋点参数。是指你想要在用户到达这个位置or页面，或者点击这个位置的时候，除了正常的流量数据（pv，uv），还想看到那些数据；
• 页面名称。是指当前埋点所属的页面，有这个才能定位到当前埋点是属于哪个页面的数据；
• 应用标识。是指当前应用的唯一标识，有的也叫站点。用来进行数据归属划分。

产品的埋点方案通常由产品经理来进行梳理，梳理完毕之后需要协同数据的同事进行确认，核对，保证方案的可行性。

（3）评审开发：埋点工具植入

采集工具通常为埋点代码，通常有三种：js文件，SDK，http请求。

埋点代码等同于一个监控系统的中枢，可以说是整个产品埋点的引擎，控制着埋点的数据的采集上报，只有它才能够在用户与应用发生交互的时候上报点击位信息，曝光信息，页面信息等等。

这块通常是研发来做，产品经理参与。

（4）测试验收：埋点测试与数据评估

埋点测试是指完成埋点工作后，需要对埋点的有效性进行测试。这块通常由测试来做，产品经理参与。

埋点12字诀：引没引，埋没埋，报没报，落没落。

• 引：是指埋点代码是否引入，引入的代码是否与当前产品形态吻合；
• 埋：是指是否产品的所有模块都添加了埋点；
• 报：是指埋点之后数据是否能够正常上报；
• 落：是指上报的数据最后是否落到了对应的表里面。

(5) 上线应用

埋点采集的缺点：依赖经验导向；沟通成本高；大量时间数据清洗；数据漏采错采。