数据埋点是开启数据分析的第一步。但埋点过程本身，涉及产品、运营、技术等多环节多职能。即使在互联网公司，很多运营人对埋点也是一头雾水，对埋点规划、埋点与数据分析的关系、典型场景埋点方案，都是在摸索中前行。
一、什么是数据埋点？
数据埋点是一种常用的数据采集方法，方便产品/运营系统性的统计分析复杂的用户数据。我们在App端所设置的自定义事件，就是通过数据埋点的方式，实现对用户行为的追踪，以及记录行为发生的具体细节。
通常情况下，我们会对一些关键节点、关键按钮进行监测，比如关键路径的转化率。另外，还可以通过埋点统计核心业务数据。以电商类App为例，在提交订单环节，将用户购买的商品名称、类别、价格等明细数据进行上报，便于后续分析用户行为与洞察用户偏好。
二、数据埋点有几种方式？
目前国内主流的数据埋点方式有四类：全埋点、可视化埋点、代码埋点、后端埋点。每种方式都有优缺点，需要根据业务需求评估选择。
总体来说，全埋点和可视化埋点更侧重结果的展现，对过程追溯少，更适合产品经理分析基础的产品功能流畅度、用户体验、产品路径设置等。
代码埋点和后端埋点，不仅能展现结果，也会记录用户行为过程，支持深度的行为分析和偏好洞察，还可将行为数据与业务数据打通，适合产品和运营人员深度使用。
01点全埋
定义：从名字就可以看出，全埋点会自动采集所有的数据点位，是土豪的埋码方式。
- 优点：几乎可以监测和分析用户在App端的所有行为数据，并且可追溯。
- 缺点：数据存储、计算、分析成本高昂，对用户在前端的加载也有影响。主流App几乎都不会采取此种方式。
02可视化埋点
定义：通过点击交互，在产品界面上直接进行埋点。先分析，再圈选，是一种所见即所得的埋点方式。
- 优点：跳过技术部署，集成简单，小白也能很快上手；能够监测产品前端用户交互数据
- 缺点：所采集的数据，属于前端浅层数据，而侧重属性的数据带不回来。例如，对于新闻类App，能监测到用户点击标题的行为，但作者、细分标签、发布时间等数据无法采集，且无法进行数据追溯。
03代码埋点
定义：通过技术代码在App接口中进行埋点，需产品、技术、运营的通力配合。
- 优点：代码埋点可以采集到你想要的所有数据（服务端、客户端）；前期需要系统性规划，数据分析会更贴合业务场景；且数据维度更丰富和深入，适合精细化分析和用户行为洞察。
- 缺点：前期工作量会稍大，包括埋点规划和技术实施。产品新增功能后，需要技术埋点并且发布App后才能统计到数据。
04后端埋点
定义：通过导入工具或系统，将数据（通常是后端日志）直接进行上报。从经验上判断，后端采集适合结合深度业务数据的挖掘，而前端采集适合基于用户行为的产品运营。
- 优点：做为“独立”的上报通道，其安全性、准确性较高。（前端通过用户层面的上报，可能会因为各种环境丢失数据、可能在传输途中被劫持）；可结合相关业务数据，将整个业务过程进行更全面的描述；同质化的采集，使用后端替代前端采集，可提升因前端采集带来的性能流失，给用户带来更好的体验。
- 缺点：有些纯前端的行为，没有记录对应的后端日志，这部分数据无法采集和获知。
特别强调：无论采用哪种埋点方式，都应该根据业务场景和产品阶段，梳理和构建数据分析体系。埋点规划混乱、数据采集无序、数据分析断层，最终将会让企业陷入“有数据而无价值”的境地。
三、谁负责埋点？
全埋点和可视化埋点，产品经理和运营人员就可以操作实现。代码埋点和后端埋点则需要技术同学配合完成。友盟+支持代码埋点，为开发者提供API接口，通过技术层面实现数据上报。
极简埋点的3步骤：
1、需求梳理，埋点目的是什么，有哪些业务场景，需要哪些维度的数据，如何构建数据分析体系。
2、需求落地，埋点不是越多越好，需要与技术讨论埋点的合理性和可行性，大致一致之后，再开始行动。
3、开始埋点，在App端埋点后，与第三方平台API对接。上传相应的事件ID与事件名称，与代码中的ID与名称一致。
四、埋点与数据分析的关系
1、埋点和数据分析是因与果的关系
只有前期将埋点规划好，后期才可能做用户行为分析，而且埋点的分层做的越细致，可分析的维度也就越细致。要统计的数据庞大时，建议分阶段分版本进行埋点，先对主要事件关键路径进行埋点，一步一步完善。
2、产品技术运营的多方协同
埋点一定是需求方提出的（产品和运营为主），业务场景和需求整理、制定埋点方案，与技术团队对接埋点规划、测试上线。另外，埋点由专人维护，如果这个环节出现问题，就会造成埋点混乱，结果就是采集到的数据都不知道是什么，数据价值下降。
3、区分测试数据与正式环境
切记先测试，数据无误后再正式发版，且不要将测试数据混淆统计。
4、数据埋点命名规范
建立一套内部的数据埋点规范，每个点都有专属ID，防止后期数据量大而对应不到具体点位。
五、代码埋点规划
一个埋点规划原则：将相同属性的事件进行归类；事件下的属性拆分的越丰富，用户分析的维度也就越详细。
在U-App AI版中，我们将事件分为3级：事件（Event）、属性（Key）、属性值（Value）。
01事件（Event）
定义：对用户使用产品过程中的互动行为的描述，比如说新手注册、加入购物车、购买或播放音乐等。
应用示例：对某事件进行分组查看，如查看不同渠道中“购买”事件的触发情况；查找符合某类筛选条件的事件，如找到触发“播放”事件且触发次数 > 5次用户。
02属性（Key）
应用示例：如“加入沟通车”这个行为，事件名是“加入购物车”，那么这个事件的属性可以细分出“产品名称、产品类别、金额”等。
以“播放”事件为例，事件名称是“播放”，那么这个事件的属性可以细分出“播放内容、播放类型”等。
03属性值（Value）
定义：属性值是一个变量，需要根据用户真实触发的内容进行上报，如把某产品加入了购物车，针对“产品名称”这个属性，属性值需要上报的就是用户点击过产品的真实名称。
特别注意：
以前开发者做埋点多是平铺式，没有利用属性来针对事件做结构化处理。
以“用户点击按钮”这个事件为例，大多数开发者会把每个按钮当做一个事件来统计，这样做看似直观，可以直接看到按钮A、按钮B分别被点击的次数与人数。但弊端也非常明显，不容易做归类分析。例如，当分析首页所有按钮被点击情况时，只能一个一个事件去相加。
如果在前期埋点时做结构化处理，很容易通过U-App AI版的事件功能做归类分析。
1、扁平化埋点示意图：
2、结构化的事件埋点示意图：
将一类行为当做一个事件，通过属性进行拆分，既能看事件整体，也能拆分细分维度。
注：属性值需根据实际情况动态获取。
六、埋点应用：听书类App埋点方案
我们以听书类App为例，拆解出通用的埋点样例。在做埋点规划时，我们将有相同属性的事件进行归类。
事件结构分为6块：内容、注册、搜索、充值、购买和点击。
例如，将“阅读数据”拆分出6组属性，帮助App分析用户对哪些类型的书籍感兴趣、用那种形式了解内容、从那个入口获取到的内容等。这样归类的好处是不仅看到整体书籍被阅读的情况，也能细分出用户对内容的偏好和兴趣。
进行以上埋点之后，就可以在U-App AI版中进行数据分析了。
评论留言