概念

可以先看一本书《精通Web Analytics 2.0》

埋点是什么

所谓埋点就是在应用中特定的流程收集一些信息，用来跟踪应用使用的状况，后续用来进一步优化产品或是提供运营的数据支撑，包括访问数（Visits），访客数（Visitor），停留时长（Time On Site），页面浏览数（Page Views）和跳出率（Bounce Rate）。这样的信息收集可以大致分为两种：页面统计（track this virtual page view），统计操作行为（track this button by an event）。

埋点是谁的工作

现在公司通常都会有数据产品经理或业务线数据分析师，结合版本迭代过程进行埋点规划。如果是代码埋点，还需要开发完成相应的埋点代码。

埋点的意义

埋点就是为了对产品进行持续追踪，通过深度数据分析不断优化产品。好比去医院体检，医生测了你身体的各个健康指标，以此来判断你的健康状况。埋点的目的，其实就是随时或者定期监测你的产品的“健康”状况。

任何一个系统在设计初始阶段只关心核心业务的功能，等到系统上线以后，数据分析师对用户行为分析时会发现缺少很多数据，此时需要采用埋点的方法进行采集需要的数据。

业务人员主要通过自有或第三方的数据统计平台了解产品的概览性数据指标，包括新增用户数、活跃用户数等。这些指标能帮助企业宏观的了解用户访问的整体情况和趋势，从整体上把握产品的运营状况，但很难基于这些指标直接得到切实的产品改进策略。

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

对于产品来说，用户在你的产品里做了什么、停留了多久、有什么异样，都是需要关注的。比如用户点击率怎么样？用户在核心使用路径上是否顺畅？有没有得到用户的认可？有没有因为设计按钮过多导致用户行为无效？用户希望有什么样的功能更新等等问题都可以通过埋点的方法实现。

埋点做好才能用来进行数据驱动产品和精细化运营。而埋点质量的好坏也直接影响到了产品运营的质量。因此它贯穿了产品的整个生命周期，为产品优化指明了方向。所以说，好的数据埋点，就成功了一半。

when && where

埋点是目的导向。

在产品规划时就要思考数据埋点问题，如果在产品外发后再考虑怎么埋点，就会导致前期版本用户的数据无法收集，想要看某个数据时就会非常无奈，只有等到新版本完善来弥补。

思考要埋哪些点、埋点的形式，需要紧密结合产品迭代的方向、运营需求，并和数据开发等进行充分沟通以确认：

埋点能够得到想要的数据解决/支持；
能够得到当前版本的复盘情况；
后续版本的数据支撑。

通常的沟通过程以埋点文档为载体；数据埋点评审为终结。

当前版本的复盘情况：

新版本功能使用情况，是否符合预期；
新功能上线后对其他功能点的影响？是否为整体均有积极作用；
版本运营活动目标群体的特征获取;
新增商业化目标的监测……

后续版本的数据支撑：

规划方向的用户行为分析
画像特征分析

埋点指标：

基础指标

基础指标是一些常用的参数指标，比如用户行为相关的，有用户数、新增用户数、活跃用户数等；用户设备相关的，比如电脑系统、地区、语言、国家、产品版本等；用户属性相关的，性别、年龄等。这一部分一般很难通过埋点拿到，但是通过一般第三方工具可以看个大概。

用户行为数据指标

用户行为的行为数据，就是埋点的核心了。这一部分根据不同的产品，收集的数据也不同。再拿PC端的腾讯视频举例，每个用户每天使用腾讯视频的时长是多少？每次看的是哪些视频？用户最喜欢看哪个频道的视频？每个频道的使用情况是怎么样的？用户一般是在一天中的哪个时间段打开腾讯视频的。想要看的数据非常多，而这些，都是要提前规划好，有目的性得去决定要埋什么点、怎么埋。如果你的目的是为了研究一下用户对弹幕的接受程度，那围绕弹幕，设置一些指标数据，比如发布弹幕的次数和频率？看视频时是否开启了弹幕？这样的话，就能够通过数据，看出用户对弹幕的真实反映，对于提升产品功能和运营都有很大帮助。

核心质量指标

Crash等一些因为产品质量引起的问题，都是用户所不能忍受的。而且用户量越大，越容易出现产品质量问题。尤其是一些产品，他的产品属性决定了，产品质量是吸引用户购买的一个很重要的因素。比如迅雷、photoshop等软件，核心质量的指标能帮助我们监控产品的“健康”情况。

这里说的质量指标，不单单指产品的异常退出率、Crash率，还包括和产品自身业务相关的指标。比如，对于视频编辑产品，编辑成功率是很重要的指标；对于迅雷，下载成功率是核心指标；对于在线类产品，资源解析成功率是核心指标……

访问与访客

访问次数（Visits）与访问人数（Vistors）是几乎所有应用都需要统计的指标，这也是最基础的指标。对于应用的统计来说，经常看到的DAU（日活跃用户数量），MAU（用户数量统计），UV（独立（IP）访客）等指标都是指统计访客（Vistors）。访问（Visits）是指会话层，用户打开应用花一段时间浏览又离开，从指标定义（访问次数）来说这被称之为统计会话（Session）数。一次会话（Session 或 Visit）是打开应用的第一个请求（打开应用）和最后一个请求决定的。如果用户打开应用然后放下手机或是离开电脑，并在接下来30分钟内没有任何动作，此次会话自动结束，通常也算作一次访问或会话期（30分钟是早起网页版应用约定俗成的会话数定义，目前用户停留在应用的时长变长，30分钟的限定也可能随之不同，总之是能代表一次用户访问的时长）。在计算访问人数（Vistors）时，埋点上报的数据是尽可能接近真实访客的人数。对于有需要统计独立访客这个指标的场景，这里还是需要强调一下，访问人数（Vistors）并不是真实独立的人，因此收集数据时必须知道访问人数虽然能够很好的反映使用应用的真实访问者的数量，但不等于使用应用的真实人数。（原因是，重复安装的应用，或是手机参数被修改都会使得独立访客的指标收到影响。计算访问人数的埋点都是依赖Cookie，用户打开应用，应用都会在此人的终端创建一个独立Cookie, Cookie会被保留，但还是难免会被用户手动清理或是Cookie被禁用导致同一用户使用应用Cookie不一致，所以独立访客只能高度接近于使用应用的真实人数。）

停留时长

停留时长用来衡量用户在应用的某一个页面或是一次访问（会话）所停留的时间。页面停留时长，表示在每个页面所花费的时间；例如：首页就是进入首页（10：00）到离开首页进入下一个页面(10:01)的时长，首页停留时长计算为1分钟。页面A是2分钟。停留时长的数据并不都是一定采集得到的，比如页面B进入时间（10：03），离开出现异常或是退出时间没有记录，这时候计算就是0 （所以指标计算时需要了解埋点的状况，剔除这样的无效数据）。应用的停留时长，表示一次访问（会话）所停留的时间，计算起来就是所有页面的访问时长，同样是上一个流程，应用的停留时长就是4分钟。

跳出率

跳出率的计算方法现在在各个公司还是很多种，最经常被使用的是：用户只访问了一个页面所占的会话比例（原因是：假设这种场景，用户来了访问了一个页面就离开了，想想用户使用的心里画面应该是：打开应用，心想什么鬼，然后关闭应用甚至卸载了。这个场景多可怕，这也是为什么跳出率指标被如此关注）跳出率可以分解到两个层次：一是整个应用的跳出率，二是重点的着陆页的跳出率，甚至是搜索关键词的跳出率。跳出率的指标可操作性非常强，通过统计跳出率可以直接发现页面的问题发现关键词的问题。

退出率

退出率是针对页面的，这个指标的目标很简单，就是在针对某个页面有多少用户离开了应用，主要用户反映用户从应用离开的情况。哪些页面需要被改进最快的方式被发掘。（注意：退出率高不一定是坏事。例如：预测流程的最终节点的退出率就应该是高的）

转化率

我们在产品上投入这么多，不就是为了衡量产出么？所以对于电商类应用，还有比转化率更值得关注的指标吗？转化率的计算方法是某种产出除以独立访客或是访问量，对于电商产品来说，就是提交订单用户数除以独立访客。转化率的计算看起来想到那简单，但却是埋点中最贴近业务的数据收集。这也是最体现埋点技巧的指标，需要结合业务特点制定计算方法。提交订单量/访客数是最基本的转化率，转化率还可以分层次，指定用户路径的，如：完成某条路径的提交订单数/访客数。

参与度

参与度并不是一个指标，而是一系列的指标的统称，例如访问深度，访问频次，针对电商的下单次数，针对内容服务商的播放次数，及用户行为序列这些都可以是衡量参与度的指标。之所以把参与度列为一个指标，是希望大家明白把指标结合业务，产生化学反应，活学活用去发现事物的本质。

数据采集普遍遇到的几个问题

实时性，对于工具性产品在无网条件下的数据，无法实时上报；
完整性，由于用户隐私协议&欧盟通用数据保护条例的，部分数据无法采集；
异常，android_id、idfa、idfv 随版本升级变化或无法获取。

怎么埋点

代码埋点

以为需要监测网站上/app上用户的行为，是需要在网页/app中加上一些代码的，当用户触发相应行为时，进行数据上报，也就是代码埋点。这样的代码，在网站上叫监测代码，在app中叫SDK（Software Development Kit）。市场上的第三方数据采集均支持代码埋点，GA, GrowingIO，神策等。

优点
- 采集的数据比较具有针对性，更加适合精细化数据分析。
- 同时也能提高数据的准确性。
缺点
- 每一个控件的埋点都需要添加相应的代码，不仅工作量大，而且限定了必须是技术开发人员才能完成。
- 每一次产品迭代，都需要更新埋点方案。
适用场景
- 有具体的业务分析需求，且按照各个事件埋点的方式不能满足。
- 需要对埋点事件进行传参等自定义属性设置。代码埋点虽然较复杂，但功能最完善，覆盖了埋点中的不同业务需求。

可视化埋点

利用可视化交互手段，数据产品/数据分析师可以通过可视化界面（管理后台连接设备）配置事件，如下是腾讯移动分析的可视化埋点界面。可视化埋点仍需要先配置相关事件，再采集。

例如腾讯的https://mta.qq.com/

蚂蚁金服的移动开发平台
https://tech.antfin.com/docs/2/49549

优点
- 业务人员可用，无需技术人员进行SDK嵌入，不懂代码的产品运营人员也可通过后台可视化界面配置和统计埋点并实时下发到客户端生效。
- 无需版本更新，由于不需要嵌入新SDK，不需要发布新版本，可谓即时生效。
- 对所有版本生效：新增埋点在所有版本生效，不存在迭代问题。
缺点
- 可覆盖的功能有限，目前并不是所有控件操作都可以通过这种方案进行定制。
- 不能自定义交互事件属性，由于获取的是交互事件元素的DOMpath，无法对具体事件设置参数。
- 不支持可以不断加载的内容瀑布流交互。
适用场景
- 分析或统计需求简单，不需要对埋点事件进行传参等自定义属性设置。
- 频繁上线或更新的H5类型的运营活动

无埋点

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

数据分析师/数据产品通过管理后台的圈选功能来选出自己关注的用户行为，并给出事件命名。之后就可以结合时间属性、用户属性、事件进行分析了。所以无埋点并不是真的不用埋点了。目前市场第三方工具GrowingIO支持无埋点全量行为数据抓取https://growingio.jinshuju.com/

优点
- 因为无埋点对页面所有元素进行埋点，那么这个页面每个元素被点击的概率你也就知道，对点击概率比较大的元素可以进行深入分析。
- 可以在系统上线后使用，支持基于全量的数据回溯，因为无埋点在你部署SDK的时候数据就一直在收集，可帮助进行启发式、探索式的数据分析。
- 它技术门槛低，部署简单。
缺点
- 无埋点无法采集自定义属性，只使用通用大部门，通用的场景。
- 数据形式非业务导向，因为是对所有事件数据的自动收集，没有按照业务需求进行事件或区域设置，业务或数据人员在使用时或许不能直接使用，需要二次计算或处理。
- 兼容性不好，传输时效性较差等问题，因为是对所有的元素数据都收集，会给数据传输和服务器带来较大的压力。
适用场景
- 分析或统计需求简单，不需要对埋点事件进行传参等自定义属性设置的事件。
- 针对快速、频繁上线和迭代的H5类型的运营活动的评估。

总体来说，无埋点和可视化埋点更侧重结果的展现，对过程追溯少，更适合产品经理分析基础的产品功能流畅度、用户体验、产品路径设置等。代码埋点和后端埋点，不仅能展现结果，也会记录用户行为过程，支持深度的行为分析和偏好洞察，还可将行为数据与业务数据打通，适合产品和运营人员深度使用。

无论采用哪种埋点方式，都应该根据业务场景和产品阶段，梳理和构建数据分析体系。埋点规划混乱、数据采集无序、数据分析断层，最终将会让企业陷入“有数据而无价值”的境地。

架构设计

通过日志埋点来实现业务监控和行为分析主要需要以下4个步骤

数据生成(埋点)
数据收集
数据解析(结构化)
数据落盘
数据使用(展示/分析)

数据使用

如何做数据埋点

其实这个问题不应该问别人，应该问你自己，通过上文，我们已经知道了，如果你想绘制基础的人群画像你就需要获取用户机型、网络类型、操作系统，IP地域等数据；如果你想分析每一个注册转化率，你就需要获取每一个步骤的点击次数，然后制作成漏斗，看那一步转化率出现了问题……目的不一样，获取的数据也不一样，使用的埋点技术也不一样。

那么，我们该如何选择埋点方式呢？

我们的目的是实现深度数据分析，不应该采用与其他企业通用的埋点方法，应该采用适合自己的埋点方法。也就是做到“因系统而异、避免千系统一面的情况。

在系统刚上线的初期阶段，我们可以采用无埋点的方式。因为我们通过UV、PV、点击率等基本指标及即可满足数据分析需求。如果产品上线时间很长，我们需要进行深度数据分析则选择代码埋点。它可以帮我们收集需要的属性。另外，如何埋点既可以在前端实现，也可以在后端实现，我们推荐在后端实现。因为后端数据可以保证数据的准确性。最后，如果您为了方便快捷并且免费，可以选择第三方统计工具，但是一定要选择适合自己业务的统计工具。

从业务过程中采集埋点，是数据驱动型公司的必要条件。一般公司的产品功能评审环节，不仅有 PRD (Product requirement document），还加入了对应的 DRD ( Data requirement document）。对于埋点而言，DRD 需要明确业务目标与埋点缺口之间的关系以及需求的优先级。埋点的需求大多来自于 DRD，整个过程会涉及多个角色，主要包括产品经理、业务数据负责人、开发工程师、测试工程师，如图所示。

总之，如果您需要深度分析，选择后端（手动）埋点和无埋点组合的方案；如果您只是想看宏观数据，可以选择无埋点。无论采用哪种埋点方法，一定要慎重，根据需要来设置，最好不要出现错埋或者漏埋的情况。最后，数据分析师一定要和业务工程团队（部署实施埋点的部门）配合好才能实现完美的数据采集方案，有时候沟通比选择埋点方式更重。