对于产品经理、运营、数据分析师来说，数据的重要性非比寻常，直接影响最终的决策，好的数据源才是数据分析的基础。而数据分析的第一步就得做好数据的埋点工作，也是最为重要的环节之一。

本来近5000字和大家一起聊聊如何快速学会埋点操作，欢迎查缺补漏，本文目录如下：

1. 什么是埋点

2. 埋点的作用

3. 埋点方式 (3种)

4. 埋点步骤 (6大步)

1. 什么是埋点

所谓“埋点”，是数据采集领域的术语，指的是针对特定用户行为或事件进行捕获、处理和发送的相关技术及其实施过程。在此过程中收集所需信息，以跟踪用户的使用情况，最后分析数据作为后续迭代产品或者运营工作的数据支撑。

埋点也是为了满足快捷、高效、丰富的数据应用而做的用户行为过程及结果记录。数据埋点是一种常用的数据采集的方法。

埋点是数据的来源，采集的数据可以分析网站/APP的使用情况，用户行为习惯等，是建立用户画像、用户行为路径等数据产品的基础。

比如订单成交率：我们进入到商品详情页操作，同时按要求进行数据采集和上报，告诉服务器我们主动干了什么或者被动出发了什么？然后进入订单结算页面，进行其他操作，以此类推。

最后后台可以统计出各个点击事件和预置事件，根据得到的数据还原出用户的各种行为，最终将这些数据可视化出来，进行深入分析。

2. 埋点的作用

提高渠道转化：通过跟踪用户的操作路径，找到用户流失的节点，比如支付转化率，通过下图的漏斗分析，就能分析出用户在哪个环节流失率最大，找到问题并给予优化。

图1：支付率漏斗分析

精准客户运营：按照一定需求对用户打标签或分组，实现精准营销、智能推荐(千人千面)等。比如根据(电商)用户浏览行为、收藏行为、加购行为、 购买行为，可用按商品到底等维度进行分组，推荐不同价格的商品给不同分组的用户。

完善客户画像：基本属性（性别、年龄、地区等），行为属性；

数据分析：埋点作为原料放在数据仓库中。提供渠道转化、个性推荐等；

改善产品：通过用户行为分析产品是否有问题，例如用户有没有因为设计按钮过多导致用户行为无效等问题，以此发现功能设计缺陷等。

3. 埋点方式

埋点方式分为：代码埋点、可视化埋点、无埋点（全埋点）；

3.1 代码埋点

它的技术原理也很简单，在APP或网站加载的时候，初始化第三方服务商数据分析的SDK，然后在某个事件发生时就调用SDK里面相应的数据发送接口发送数据。目前，国内的主要第三方数据分析服务商有百度统计、友盟、TalkingData、神策等。

优点：

灵活性强，使用者可以比较方便的自定义属性、事件，传递各种所需的数据到服务端；

缺点：

(1) 人力成本高，每一个埋点都需要技术人员手动的添加代码；

(2) 更新成本较大，每一次更新埋点方案，可能都需要改代码；

3.2 可视化埋点

又称框架化埋点，利用可视化交互手段，业务人员都可以直接在页面上进行简单圈选，以追踪用户的行为(定义事件)，节省了开发时间。不过可视化埋点仍需要先配置相关事件，再采集。

优点：

(1) 可视化埋点很好地解决了代码埋点的人力成本高和更新成本较大的问题。

(2) 只需一开始技术在页面接入SDK的代码，后续埋点只需业务人员自己按规则操作即可，无需开发再次接入。

缺点：

(1) 可视化埋点无法做到自定义获取数据，覆盖的功能有限，目前并不是所有的控件操作都可以通过这种方案进行定制；

(2) 上报行为信息容易受限；

图2：诸葛IO可视化埋点部分操作

3.3 无埋点

无埋点是指开发人员集成采集 SDK 后，SDK 便直接开始捕捉和监测用户在应用里的所有行为，并全部上报，不需要开发人员添加额外代码；

或者是说用户展现界面元素时，通过控件绑定触发事件，事件被触发的时候系统会有相应的接口让开发者处理这些行为。

使用者通过管理后台的圈选功能来选出自己关注的用户行为，并给出事件命名。之后就可以结合时间属性、用户属性、事件进行分析了，所以无埋点并不是真的不用埋点了。

优点：

(1) 由于采集的是全量数据，所以产品迭代过程中是不需要关注埋点逻辑的，也不会出现漏埋、误埋等现象。

(2) 无埋点方式因为收集的是全量数据，可以大大减少运营和产品的试错成本，试错的可能性高了，可以带来更多启发性的信息；

(3) 无需埋点，方便快捷；

缺点：

(1) 缺点与可视化埋点相同，未解决个性化自定义获取数据的问题，缺乏数据获取的灵活性；

(2) 无埋点采集全量数据，给数据传输和服务器增加压力；

(3) 无法采集自定义属性、事件；

图3：GrowingIO无埋点部分操作

4. 埋点步骤

那么，埋点操作过程又是怎样的呢？一般可以分成以下六个步骤：确定目标/指标、数据采集规划、埋点采集数据、数据评估和数据分析、确定优化方案、如何评估解决方案的效果。

4.1 确定目标/指标

为什么要有埋点指标呢，因为产品需要量化，量化了之后才知道产品做得好不好。所以在真正设计埋点之前，就要想好怎么分析这些埋点，只有确定好了分析思路，你才知道需要哪些埋点。

比如，我们发现app每天的日活很高，但是最终完成付款却很少。那么我们的目标就是提高支付转化率，了解为什么用户没有有效支付，是哪一个环节让用户犹豫了。

我们一起看看常见的指标有哪些：

PV(page view)：即页面浏览量，用户每次对页面访问均被记录计数；

UV(unique visitor)：即独立访客，访问您网站的一台电脑客户端为一个访客，00:00-24:00内相同的客户端只被计算一次；

转化率：只在一个统计周期内，完成转化行为的次数占总数的比率；

活跃度：主要衡量产品的粘性，用户的稳定性以及核心用户的规模，观察产品在线的周期性变化，如日活、月活；

留存率：在统计周期（周/月）内，每日活跃用户数在第N日仍启动该App的用户数占比的平均值。其中N通常取2、3、7、14、30，分别对应次日留存率、三日留存率、周留存率、半月留存率和月留存率。

4.2 数据采集规划

只有对产品的结构和逻辑足够了解，才知道哪些是需要关注的数据和指标，以及怎样通过对这些指标的监控实现最终的目标，因此这时我们需要将产品功能抽象化、逻辑化和结构化，拆分成具体的逻辑层次。

比如之前图1：支付率漏斗分析的目标，我们需要拆解用户从进入app页面到完成支付的每一个步骤的数据，每一次输入的数据。比如：进入商品详情页(PV/UV) --> 点击购买(次数) --> 提交订单(次数) --> 支付操作(结果返回)等步骤。

在这环节我们可能要输出一份埋点文档，这是埋点需求分析结果的落地方案。不同平台，不同渠道，对于业务需求的不同，所产出的埋点文档结构和埋点方案都不同，接下来以神策平台埋点文档进行大致讲解。

公共属性：如果某个事件的属性，在所有事件中都会出现，可以将该属性设置为事件公共属性。设置公共属性后，之后触发的所有事件，都会自动加上设置的公共属性。

预置事件/预置属性：预置事件指平台已经定义好的事件，后端埋点时，无法自动采集预置属性，需要手动传输（其他平台可能会有不同定义）。

图4：预置事件       

图5：预置属性

自定义事件：产品经理和技术人员约定好相关规则，如事件命名规则、变量命名规则等，然后才可以开始自定义自己想要的事件。自定义事件主要由事件名称、参数、参数值组成。

列举一个“取消订单”埋点自定义事件：从文档中可看出cancelOrder是取消订单的事件名，同时cancelOrder时间被触发后，可传入order_id (订单ID)、order_amount (订单金额)等参数。

4.3 埋点采集数据

如果我们采用的是代码埋点的话，那就需要把4.2整理好埋点文档交给技术人员，让他们通过代码的手段去埋点。

这里要注意一下，手工埋点流程存在着较大的数据风险：

(1) 埋点名称不规范不统一，对于一些参数的定义也较为随意，这样就容易造成后续的埋点名称冗余且混乱，不利于后续的统一管理；

(2) 流程中诸多环节均为口头沟通，产品验收较为繁琐，某个版本漏埋点或埋点不正确的风险大大提高，对于数据的及时提供带来较大隐患。

如果是可视化埋点或者无埋点，那么由使用者通过管理后台的按照规则进行操作，基本上不需要技术人员操作。

埋点操作完成后，要对埋点采集的数据进行观测：每个事件是否正常上传数据？采集到数据是否正常范围（过大或过小）？

4.4 数据评估和数据分析

在一段时间的数据采集之后，形成相应的数据样本，要注意的是时间上过短，或者用户很少的数据是没有多大意义的。

思考一下，收集上来的数据质量如何，数据该如何分析呢？数据分析的方式还是比较多，这里不重点展开说，接下来列举一些常用的分析方法：

对比分析：通常用于对比迭代前与迭代后的数据对比；

分布分析：通常用于分析特定行为的在某个维度的分布情况，可以展现出用户对产品的依赖程度，分析客户在不同地区、不同时段所购买的不同类型的产品数量、购买频次等

如电商APP的下单行为，一天24h的下单量分布，来分析一天内哪个时间内是下单高峰期。

漏斗分析：反映用户行为状态以及从起点到终点各阶段用户转化率情况的重要分析模型，比如上面提到的电商下单流程的转化率。

用户路径分析：用户在 APP 或网站中的访问行为路径。为了衡量网站优化的效果或营销推广的效果，以及了解用户行为偏好，时常要对访问路径的转换数据进行分析。

以电商为例，买家从登录网站／APP 到支付成功要经过首页浏览、搜索商品、加入购物车、提交订单、支付订单等过程（用户真实的选购过程是一个交缠反复的过程）。

留存分析：用来分析用户参与情况/活跃程度的分析模型，考察进行初始行为的用户中，有多少人会进行后续行为。这是用来衡量产品对用户价值高低的重要方法。常见指标有次日留存、7日留存、15日留存、30日留存等。

上述是一些常用的分析思路，除此之外还有很多：点击分析、用户分群分析、属性分析、行为事件分析等等，感兴趣的同学可以自行学习。

4.5 确定优化方案

产品经理的职责就是发现问题，然后解决问题。

通过数据分析来定位问题，找到影响上述量化指标的产品问题点在哪里？

比如：确认订单到支付这步的转化率这么低情况有哪些？可能是用户无法在确认订单页面查看商品细则，为了返回上一页，因此放弃了付款，也可能是用户想修改商品数量或规格，但是确认订单页面不能修改，因此放弃了付款，当然也有可能是提交支付按钮存在Bug或者理解的偏差等等。

最后找到了问题，就得对症下药，制定解决方案。

4.6 如何评估解决方案的效果？

优化方案上线，我们的工作不意味就结束了，重点要观察对应的指标有所提高或者降低，与优化前的版本相比较是否有所改善，很多时间往往不可能一步到位就把问题解决掉，需要迭代优化，不断通过数据跟踪来修正设计策略，达到我们最终的设计目标。

大数据时代的到来，对产品经理提出了更加严格的数据分析要求，一个懂数据分析的产品经理可以利用数据驱动产品设计优化，并提升客户体验，实现更多的价值。

-END-