规范的数据埋点和分析，可以高效得辅助企业构建业务数据体系，多维度分析用户，为企业提供业务决策、产品迭代、营销转化、精细化运营支撑。

本文尝试从认知建立，价值了解，实现方案三个角度系统梳理埋点体系，最后通过业务和技术俩个视角给出埋点体系的推荐体系化搭建实战。

认知建立

埋点，用一句话来讲是指对用户行为或事件进行捕获、处理、上报的过程。比如用户某个 icon 点击次数、观看某个视频的时长等等。

技术角度来讲，通过监听软件应用运行过程中的事件（点击或请求），当需要关注的事件发生时进行判断并捕获上报。

围绕着数据埋色主要包含了这么几条角色线：产品线、广告线、运营线、数据线。前三条线基于不同的目的将需求提出到数据线，由数据团队完成业务拆解分析，埋点文档建设，埋点开发测试环节等，支持业务看数用数需求。

价值了解

其实与埋点相关的价值有很多，总结主要分为这么几个方面：面向渠道、投放的评估，业务的精细化与数据化运营，产品迭代支持。

• 营销渠道评估：找寻优质渠道资源，调整营销策略，提升线索转化率，从而提高市场整体 ROI。

• 数字化 / 精细化运营：精准定位不同用户群，个性化营销引导。针对用户的特定动作，出发对应的运营策略，实现产品运营的自动化和智能化。

• 产品迭代支持：产品每日流量、产品所处的生命周期，活动前后数据变化趋势分析等。用户行为的转化漏斗，基于用户行为 (浏览、点击、关注、收藏、加购、评论、分享)、商品、店铺、品类、 大促活动等的转化率，快速验证改版产品方案，行为分析（用户的使用习惯、用户的决策路径、用户使用产品的热 力图分布等）等。

实现方案

目前的埋点方案从埋点的实现方式角度主要分为代码埋点，全埋点，可视化埋点三大类。

代码埋点：指开发工程师将埋点结合到代码逻辑中，在 APP 或者界面初始化的时候，初始化第三方数据分析服务商的 SDK，然后在某个事件发生时就调用 SDK 里面相应的数据发送接口发送数据，此种方式是从代码逻辑上捕获用户行为并且上报数据。此外代码埋点又按照位置不同可具体细分为前端（APP、小程序、Web）埋点，后端埋点。

全埋点：就是通过在软件端引入埋点 SDK，然后无差别的将端的所有响应和交互都传递到数据库，这种方案数据库会存在大量无价值的数据，且分析时需要大量的数据清洗工作量。可视化埋点，其实让业务方或运营，通过自主的方案，选择需要观察的动作或事件。

可视化埋点：是一种不需要额外去写代码的埋点方式，而是由业务/运营人员通过访问分析平台的埋点圈选功能，“圈”出需要对用户行为进行捕捉的控件，并给出相应的事件命名。当圈选完毕后，这些配置会从平台侧同步到所有用户终端，当终端有触发已圈选的事件，SDK 就会按照圈选的配置自动进行用户行为数据的采集和发送。

对于中大型公司或者业务体量达到一定高度时，几乎都会采用代码埋点的方式，搭建公司的埋点体系，比如埋点字典，埋点管理平台，埋点流程等。所以本文讲的埋点体系化搭建，也是基于代码埋点方案的设计实现。

如何体系化搭建

大体上可以分为两个方面：业务侧和技术侧。业务侧主要围绕分析框架来展开，比如业务链路的熟悉，业务需求与数据需求并重等内容。技术侧则侧重于埋点数据流的链路设计和模型实现。接下来两个分类，咱们一一展开。

业务侧

业务链路梳理

所有的埋点需求都是基于分析主题的需要，分析建立在对业务的充分了解基础之上，所以埋点需求的第一步就是了解并梳理业务。

业务梳理及拆解

事件埋点设计之前，需要先盘清楚业务，可以从这几个方面拆解：核心业务流程，用户操作路径，细分业务场景。以电商场景为例：

梳理业务流程：商品浏览→商品详情→下单支付→物流配送

用户操作路径：首页触达→搜索→列表浏览→商品详情→下单/加购→收货。

细分业务场景：搜索场景，支付场景，商品维护场景，首页推荐场景等。

熟悉业务场景，不仅需要熟悉用户的操作，不同用户路径下有什么页面，运营位、按钮、弹窗，而且还需要了解产品所有功能，部分或者极少用户使用的业务也要做到心中有数。清楚业务后，需要针对每个业务模块/分类制定目标，根据目标拆解为一个个确定的数据指标，然后把指标细分成一个或者多个埋点事件，即多个埋点事件都能直接影响指标。

指标体系搭建

在充分了解终端的业务情况和场景拆解后，输出要提升的指标和特定事件，指标和事件的拆解，可能是一对一或者一对多的关系，即一个指标可能由一个或者多个埋点事件组成；

其次，需要充分考虑到这些事件会用于哪些指标的分析，需要上报哪些字段或属性，具体分析时的核心应用的是哪些。以电商业务为例指标体系优先级如下图所示：

设计埋点事件

针对拆解的业务场景，梳理指标和事件，抽取指标与事件之间的关联，再结合相应的属性，确定要上报的事件、属性以及上报时机等 5 要素设计埋点事件。

埋点生产研发

埋点开发同事根据埋点设计实施埋点并上报，需要考虑事件埋点方式和事件上报触发逻辑。

事件上报的触发逻辑可做如下分类：

根据业务场景做最优的触发上报逻辑。

埋点数据校验测试

根据上报的埋点数据，验证埋点的准确性，从流量埋点事件（如点击、曝光）上报到业务、财务指标逐渐递升，汇聚成多流量、内容、业务、财务的数据指标，构建用户全方位的数据指标体系；埋点测试验收应该保证埋点数据正确性、顺序性、完整性：

正确性：最基础的是确认是否有数据上报，其次，检查数据内容与字段是否与埋点设计文档一致；

顺序性：数据上报正确，还需要检查上报的顺序是否正确；

完整性：测试时，针对多场景要全部测试，如申请验证码的各个场景都应该上报。

需要注意的是，埋点上线并不意味就结束，重点要观察对应的指标是否准确上报，对业务是否指导作用，与优化前的版本相比较是否有所改善。很多时候可能不能一步到位就把问题解决掉，需要迭代优化，不断通过数据跟踪来修正优化策略，达到最终设计目标。

埋点数据 ETL 与分析

到这一步就是基础的数据工作了，包括数据清洗、存储、聚合转换，以及最后的分析，其中分析环节，在电商类公司从 0 到 1 的场景下，一般会做两个事情：数据报表的搭建和数据看板的搭建。数据报表主要是基于数仓环境下，集市层的数据开发。数据看板体系则是面向管理层，一线运营执行人员搭建不同主题的数据可视化看板。

电商业务场景下的，看板体系大致会有：分析总览，用户主题分析，商品主题分析，平台主题分析等。这里以某策平台为例，大家可以参考下。

埋点需求文档

埋点数据建模部分主要是面向的是技术上的 SDK 设计，对于业务、分析师、产品经理角色，主要维护和经常使用的是埋点需求文档（一般前期是在线的 Excel 维护，后续可能基于自研的埋点管理平台维护）。

基础的埋点需求文档关键内容，参考如下：

埋点需求协作

埋点文档是一个非常重要的沟通枢纽，连接了业务方，数据产品经理，分析师，埋点开发人员，测试人员，可以说埋点文档是整个埋点体系的核心都不为过，后续的数据分析，也会参考买点文档中的数据定义和含义等内容。

以下参见一个常见的埋点需求协作流程 SOP。

技术侧

埋点数据建模

埋点设计参考模型 4W1H：

WHO：即参与这个事件的用户是谁，如：用户 ID，设备 ID。

WHEN：即这个事件发生的时间，如：时间戳。

WHERE：IP、国家、省、市区等用户属性，如：IP 地址。

HOW：即用户从事这个事件的方式，如：上报时机，页面属性。

WHAT： 描述了一个事件具体是什么，如：事件名称/页面标题名。

根据参考模型设计，盘点需要的数据，设计埋点入仓时的数据模型。

以上包含了最核心的埋点模型，具体业务场景，可以酌情调整。

这里多讲一下 define_args，这个是一个自定义参数，对应的数据类型的是 json，这是一个取巧的设计，因为升级 SDK 是一个比较重的操作，如果此时要去追加一些新的参数，就可以把新参数放在自定义字段的 json 中，这样就不用升级 SDK，达到灵活响应业务的目标。

对于 event_type 来说，一般分为两大类曝光（view）,点击（click）。具体的业务场景中，可以基于此字段继续扩展。

曝光事件：页面曝光、弹窗曝光、按钮/文案曝光、运营位/广告 banner 位曝光等；比如某 Android 应用，首页运营位的曝光数据；

点击事件：运营位/banner 位点击、按钮/文案点击；比如某 iOS 应用，拍照功能的点击数据；

数据链路搭建

根据数据模型和埋点需求，搭建一条从用户点击到数据落库的技术链路。这里以实时埋点数仓构建为例来进行简单说明。

可以看到，埋点经过各种端的 SDK 先达到埋点服务器，然后经由 Kafka 进行各种数据处理上的路由。可以看到数据经过了 ETL 的加工，最终汇聚到基于 Druid 为引擎的实时数仓架构中。同样的离线数仓的数据流大题相似，经由 Kafka 路由到基于 Hive 为引擎的离线数仓架构中。

以上就是关于埋点基础的全部内容，如果有疑问，欢迎联系作者交流讨论。

文章结构：