如何做好埋点设计
Salvation lies within.
救赎之道，就在其中。
关于如何设计埋点，对埋点进行开发和监控，网上有非常多的相关资料。如果你想从事数据产品经理或者大数据相关工作，你可以在 Growing IO 的增长学堂或者在神策学堂中找到大量资料，本文底部提供了参考文档以供阅读。
如开篇所说，网上有非常多关于数据埋点的文章和视频，但关于产品经理应该如何设计、管理埋点的部分却很少，主流共识一直认为这是数分部门的工作。作为 PM，似乎只需要写好埋点文档，对接开发、定时监控、反馈问题就足够了。虽然事是那么回事，但不要忘记我们产品入门手册的宗旨：To the best！
数据埋点：一条线索
想象一下，你所在的城市发生了一起凶杀案，你作为一名侦探，正在观察凶手在犯罪现场留下的蛛丝马迹。在这其中，有遗落在房间的凶器、死者脖颈上的勒痕、凶手的鞋印和毛发，以及他因慌乱，不小心在花瓶摆具上遗留的半截指纹。这些痕迹就是线索，通过线索，我们能够去发现案件背后的真相。
但假如你只是一个普通人呢？你只是觉得到处都是血迹，有被破坏的家具，现场看起来很混乱，你一心想要离开这个令人害怕的地方。实际上，普通人并不具备专业人士的素养，也无法分析线索背后的秘密。
这里我说的侦探并不是真的侦探，你可以理解为是掌握专业技能的职能人员，他们在平时的训练中被要求掌握洞察细节的能力，并在多次实践中逐渐形成一种异于常人的直觉：
通过这个例子，我们大概了解了线索和分析的重要性。实际上，通过数据埋点进行设计和分析，这个过程也是类似的：发现线索，分析线索，解决问题。
作为产品经理，我们要像侦探一样，拥有发现线索、分析线索的能力，最终才能发现真相。这意味着，我们不仅要有设计埋点的能力，还要知道如何进行数据分析。最后才能正确地评估问题，解决问题。
回到互联网的语境中，数据埋点就像是一个侦探工具。想象一下，如果你是一个游戏的制作者，你想知道玩家们最喜欢游戏的哪个关卡，或者他们在游戏中卡住的地方在哪里。数据埋点就能帮助你找到这些答案。
数据埋点的工作原理是这样的：在游戏或者应用程序的某些地方，我们会放一些特殊的标记。当玩家到达这些地方或者完成某些动作时，这些标记就会记录下来，比如他们在 某个关卡花了多长时间，或者他们最喜欢点击哪个按钮。
传统定义认为，数据埋点是一种在产品中嵌入追踪代码的技术，用于自动收集用户在应用程序中的操作行为数据，以便于分析和优化产品性能和用户体验。
但对于我来说，数据埋点如同每个城市的摄像头，每一个摄像头就是城市里的一个埋点，监控着这个区域发生的一切，并且记录下来，满足交通、市政、企业等等的管理需求。
数据埋点引导着产品经理发现数据背后的用户和问题。
做埋点，为了更好的决策
假设现在你正在负责一款新产品的开发，经过几个艰辛的开发周期，产品终于成功上线。此时，老板来问你新产品的数据情况怎么样，你猛然发现自己忘记了做数据埋点。卒。
数据埋点有助于我们了解用户，发现产品问题。比如通过下载新产品的用户数，大概了解产品在市场中的反响。通过推广下载的用户数，来确认推广渠道是否有效。其次，如果有些功能的点击量少得可怜，或者某个环节的转化率过低，我们都能通过埋点去发现问题，进而改进。
数据埋点是产品经理的利器。它反映出来的数据问题能够作为我们向开发提出产品优化的有力证据。比如某个功能的点击量过少，是不是埋点定位错啦？还是这个功能存在问题呢？等等。这样一来，既能明确问题所在，而且有理由去提出优化和改进方案。
除了以上四个原因，使用数据埋点的场景还有很多，比如：
- 分析用户转化、存留情况：如下载的用户数量，注册的用户数量，一段时间之后的留存用户数量；
- 分析用户偏好：如通过用户行为的分析，可以对用户的偏好做一定的概括，便于定向推送，或者是开发不同的用户体验（一个反面例子：旅游 App 会针对不同机型、性别的用户调整酒店价格区间）；
- 收集市场反馈：如针对新功能的用户行为进行统计，就可以分析出功能的市场反馈，为是否保留功能或者改良方向提供依据。这是数据埋点所起的主要作用；
- 保障用户数据安全：如用户的地理位置数据在短时间内突然发生了异常变更，这一秒在北京，下一秒突然就在美国登录了，那说明账号发生了异常，需要对账号身份进行验证，以确保用户数据的安全；通常，涉及隐私较多的软件，比如社交、邮箱、网盘、办公等软件，对异地登录的安全限制较高；
- 定位异常：如特定的数据（比如注册）在某一段时间内数据突然无缘由发生持续性异常，说明该功能可能存在异常，需要及时做排查。比如说某个时间段注册用户数量飙升，且集中参与了某个运营活动。这个时候就需要判断是不是被薅羊毛了。
- 其他作用：如当某一个较早机型占比降低到某一个阀值时，就可以在下一个版本中去掉对该设备的支持。原因在于对多版本（尤其是老版本）进行适配会大大增加开发难度和工作量；
总体来看，数据埋点具有三个作用：了解用户行为、发现产品问题、支持产品决策。
怎么做好数据埋点
在正式开始设计数据埋点之前，首先需要明确三个问题：
- 数据是如何采集的，从哪里采集，采集的方式是什么？
- 埋点的分类和方式有哪些，应该选择哪种？
- 最重要的，设计埋点的目的是什么？
埋点数据从哪里采集？
如同摄像头是监控视频的采集工具，埋点同样有采集工具。而且通常会随不同的平台，有不一样的埋点手段。目前常见的平台通常包括移动端，PC 端，移动设备和服务器四种平台。
- 移动产品，称之为 M 端（Mobile，移动端），包括手机 APP，H5 页面，小程序等；
- 网页产品，称之为 PC 端，通常包括 Web 页面，PC 客户端等；
- 移动设备，比如智能手环，POS 机等等各种智能设备，掌上电脑；
- 服务器，一般是指服务端服务器资源。
各种平台常见的埋点手段如下所示：
| 设备类型 | 展现形式 | 展示形式 | 采集工具 |
|---|---|---|---|
| PC 设备 | PC站 | Web页面 | JS |
| PC客户端 | 客户端 | JS | |
| 移动设备 | 手机App | App内嵌H5页面 | SDK、http |
| M站 | Web页面 | JS | |
| 微信 | Web页面 | JS | |
| 微信小程序 | Web页面 | JS | |
| 手机QQ | Web页面 | JS | |
| 服务器 | 服务接口 | 服务接口 | http |
| 移动终端 | 智能设备 | 移动应用 | SDK、http |
| 掌上电脑 | 硬件服务 | http |
埋点的分类和方式
1、分类
按照获取数据的类型以及用户触发行为的不同，埋点一般可以分为三种事件，分别是点击事件、曝光事件和页面事件。
点击事件
用户在应用内的每一次点击行为，都可以记为一次点击事件。比如按钮的点击，区域的点击，商品的点击，每一条新闻的点击等，都可以成为一个点击事件。一般通过点击事件，我们可以知道页面的浏览量（PV）和用户点击量（UV）。
Tips：PV 和 UV 的区别在于，PV 的统计是以浏览量来计数的，比如说一个用户多次点击页面，这也算是 PV。但 UV 仅记录用户一次点击页面的数据，适用于纵向去看用户参与的比例。
曝光事件
曝光事件是为了统计应用内的某些局部区域是否被用户有效浏览。比如推荐区域，某个按钮，首焦等等。
举个例子，当一个产品比较成熟的时候，通常它的主页会比较长，比如淘宝、美团等。为了衡量页面某个区域用户的点击率的时候，首先需要搞清楚的就是这个区域到底被多少用户看到了。每被用户看到一次，计入一次曝光事件。
曝光率对于电商 产品而言相当重要，重要性不仅体现在数据上，和信息流的收入也息息相关。比方说电商产品知道哪些区域曝光率较高，哪些较低，那么就可以根据数据情况来收取相应的阶梯费用。
PS：现在是不是觉得数据很重要了呢 😎
页面事件
页面事件通常是指页面的各种维度信息的统计。常见的比如页面浏览 PV，页面浏览 UV。
页面事件通常统计的信息包括以下几个部分：
- 浏览器信息：浏览器版本，浏览器语言，浏览器编码，屏幕分辨率等等；
- 访问信息：用户账号，当前页面 url，上次访问时间，访问时长，页面停留时间等等；
- 来源信息：广告来源，上一页面 url 等等；
- 物品信息：不同的业务，这部分信息有较大差别。
2、方式
埋点的方式主要分为两种，埋点和无（全）埋点。埋点在上文已经提及过，那无埋点是什么意思呢，莫非是不要埋点吗？
无埋点不是不埋点的意思。无埋点的定义是指数据采集 SDK 无区别的对待所有事件的，将所有事件（页面的加载成功事件、控件的浏览和点击事件）全部获取后先存下来，到使用的时候，再根据具体的页面路径和控件名称，去捞取相应的数据。
简单来说，埋点是根据需求有章法地埋点，无埋点是我全埋了，到时候想找哪一个我再给你挖出来。这样看来，似乎无埋点更方便一些，那为什么大多数产品还需要专门设计数据埋点呢？原因在于无埋点的灵活性较差，十分耗费用户流量、占存储空间。整体来看，埋点和无埋点各有优劣势：
| 数据采集方式 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|
| 埋点 | 1. 数据定义清晰 2. 可以添加业务属性以支持维度拆解和下钻分析 | 1. 需提前规划，跨团队协作确定埋点方案 2. 历史数据不能回溯 | 适用于 “监控与分析式” 数据场景 · 核心 KPI 数据 · 需要长期监控和存储 · 业务属性丰富 |
| 无埋点 | 1. 自主性高，便于灵活采集 2. 可以回溯过去 7 天数据 | 1. 受制于产品开发框架和开发规范 2. 事件级维度无法拆分，且无法采集滑动等行为 | 适用于 “探索式” 数据场景 · 交互属性强 · 突发问题快速及时分析 作为补充数据相互印证 |
设计埋点的目的
无论是大厂还是小厂，日常做的比较多的还是埋点设计。无埋点虽然在采集用户数据上比较方便，但它并不能解释设计埋点的目的：产品之所以要设计埋点，是为了了解用户行为、发现产品问题、支持产品决策。
讲得更明确一点：
数据埋点的设计需要围绕 KPI，或者说我们最关心的地方来做。我们关心的地方就是了解用户行为、发现产品问题，最终来支持产品决策。
比如：
- 券商产品：关注用户注册登录数、开户数和交易量，因为这关乎经纪业务的收入；
- 电商产品：关注GMV、成交量、页面的点击量和曝光数据，这和 C 端、B 端的收入息息相关；
- 游戏产品：关注虚拟物品充值和交易、关卡活动进度和耗时等等。这直接关系到游戏的盈利；
- ...
所以在我看来，数据埋点并非一种广泛搜集数据的方式，而是有明确地目的去寻找答案的方式。不过在实际场景中，通常也会采用埋点和无埋点两种形式。
PS：如果你发现打开一个 App 特别慢的时候，很可能是它埋了非常多的点，而不是你的手机卡顿...
数据埋点迭代历程
在数据埋点还未进入产品研发流程的时候，埋点的使用其实比较尴尬，它更像是一种事后手段，而非事前准备。过去在完成产品设计后一般直接上线。什么数据埋点、数据监控和反馈，统统不存在。除非是老板或上级要求，才会进行埋点或让开发调取全埋点的数据。在这一阶段，公司更看重主营业务数据，如果业务不出太大差错，那么平日里的产品数据一般很少会过问。
后来，为了推进业务发展，构建用户画像等要求，产品部门开始被要求或主动推进数字化进程。如果你有印象，在疫情前几年有非常多关于企业数字化的广告，也产生了许多数据分析的岗位。这个阶段属于由混乱（chaos）走向有序的时期，公司开始注重数据，确定数据指标。但产品和数据部门对于指标的定义喋喋不休，过去遗留的数据不精准，当下的数据因为沟通不清经常反复修改，可用的数据无法支持产品决策... 等等问题频繁发生。
现在，大部分大厂已经具备了完善的数据埋点体系，通过版本迭代和定期维护也能逐步满足工作使用。还记得数据埋点的目的是什么吗？了解用户行为、发现产品问题、支持产品决策。目前大部分工具和方案已经能让我们更快地达成这三个目标。
即便如此，目前的数据埋点体系仍未尽善尽美，还未形成统一的设计规范。日常会出现许多小问题：
-
缺乏维护和更新机制： 队来了一位新 同学，想分析某个功能的数据情况，但感觉无从下手。便问老员工这个功能对应的埋点、那个页面对应的参数，得到的不是一句 “不然问问XX？”，就是一个又一个的文档链接... 内心估计都快骂娘了。
-
埋点流程缺少审核流程： 版本上线后进行效果分析，发现埋点出现纰漏，此时若是重要数据，需要紧急找人发版，时间紧张又担心焦虑；若此时是一般数据，开发同学的回复大概率是：“和下个版一起迭代”，时隔半年一年再进行分析，那就失去了数据分析的意义了（丧失时效性）。
-
埋点设计、开发不规范： 点文档测试同学拿着协作的埋点文档，测试过程中发现不是字段对应错误就是信息维护不全，解读起来麻烦不说，如果碰到大版本还需要进行埋点回归，不仅测试过程中工作量大，还有漏测的风险。
-
...
Emm... 问题很多，但并非没有解决方案。那第一步应该怎么做呢？不是马上学着埋点文档照猫画虎，而是先理解埋点设计的整个过程，建立起思考框架。
如何思考埋点设计？
思考埋点设计是一个从无到有的过程，但并不是说产品经理就只能凭空想象。在 数据分析体系的价值和原则 中，我们探讨了数据分析体系的搭建和迭代方法，这套方法同样也适用于数据埋点体系的搭建。这要求我们需要按照产品和业务要求去设计数据埋点。在这之前，我们需要了解推进产品和业务发展需要哪些指标来衡量。
Tips：如果你在读完本节后仍有疑问，请阅读：事件–用户模型
确定模块和产品特性
1、逻辑推导
确定模块和产品特性是一个定义问题。作为产品经理，我们必须需要知道所负责的产品或功能对应的关键指标是什么？市面上的大部分产品或功能基本能用以下几个模块进行划分，大家在使用时可通过这个模块进行相似归类。
完成归类之后，我们可以通过产品或功能的属性，来确定我们的关注点是什么，进而推导出常用或者可能使用的数据指标。
| 产品/功能 | 关注点 | 常用指标 |
|---|---|---|
| 内容 | 1. 用户使用时长 2. 用户使用频次 | 1. 浏览数 2. 浏览时长 3. 内容互动情况（弹幕、评论、点赞） |
| 社交 | 1. 用户与用户之间的关系密度（紧密、多少） 2. 用户活跃程度 | 1. 发布量（社区使用） 2. 互动量 3. 关系密度（关注用户数、发送消息数） |
| 工具 | 1. 用户使用频次 2. 功能使用完成度 | 1. 功能使用量、频次 2. 使用流程达成率（目标产品的用户流程较为简单，查看用户是否完成整个流程 |
| 交易 | 1. 用户交易规模 2. 交易流程的转化率 | 1. 详情页转化率（核心场景转化率） 2. 金额（总交易规模） 3. 客单价 4. 复购率 |
| ... | ... | ... |
*以上内容仅作示例，在实际场景下需要以真实的产品或功能进行思考
2、竞品调研
除了根据产品或功能进行逻辑推导，我们还可以使用竞品分析来确定我们应该关注哪些数据，使用哪些指标。举个例子：
- 对手 A 内容平台每天新增 100 篇文章，阅读量为 3000 次，平均评论数为 100 条；
- 竞品 B 平台的内容模块每天新增 50 篇文章，阅读量为 3000 次，平均评论数为 20 条；
- 我们 C 内容平台每天新增 500 篇文章，阅读量为 3000 次，平均评论数为 20 条
根据竞品调研的数据，我们可以发现：
- A 平台每日新增的文章数量远低于 C 平台，但文章的平均阅读量和评论数要比 C 平台高。原因可能是 A 平台的用户粘性和用户对于内容的认可度较高；
- 同样，B 平台每日新增的文章数量远低于 C 平台，但阅读量和平均评论数和 C 平台持平。原因可能是因为平台带来的整体流量比 C 平台高，即便新增文章数量少，但是用户体量也能给文章带来相当的流量；
- ...
根据以上情况，我们可以得出一个推论：在保持文章增量的基础上，提高内容质量；通过激励手段，提高用户的打开率和互动率。你看，我们是不是就得到了内容质量、文章打开率、文章互动率三个数据指标了呢？
3、基于产品和业务的思考逻辑
在这一小节我提到了可以基于逻辑推导和竞品调研两种方法去确定模块和产品特性，这两种方法实际上是基于产品和业务去进行思考的。
什么是产品？产品是满足用户需求的东西。什么是业务？是产品满足用户需求并实现盈利的部分。对于数据埋点这项工作，产品经理可能只需要关注当前业务比较重要的几个数据指标，设定好阈值和范围，我们能够很好地验证实际场景是否能符合我们的想法。但最终我们还是要回到这个思考逻辑当中，去思考做数据埋点到底是为了什么：
设计数据埋点是为了更好地推进产品和业务发展。
4、不能用单一指标衡量产品
一个产品可能有多条业务线，这意味着一个产品并不是由单一的模块进行定义和划分。比如说抖音，它不仅是一个短视频内容产品，它还具备了 社交、电商（交易）和短视频创作（工具）等功能，我们不能以单一的指标去衡量一个产品是否达标，是否优秀。
确认产品业务和场景
知道自己做的产品或功能具备的特性后，接下来需要做的就是确认产品业务和场景。对于业务的理解，要求产品经理需要知晓产品从哪些地方盈利。场景则是用户在产品或功能中历经的流程。比如在电商产品中，用户最主要的场景是浏览商品 - 购物 - 下单。通过业务和场景的确认，能够帮助产品经理找到体现核心业务健康程度的指标。我们分别用两个例子来说明如何确认产品业务和场景。
1、宏观层面
宏观层面，也即从整体维度来确认产品从哪里盈利：
- 平台靠用户浏览广告进行盈利，核心业务卖广告，体现核心业务健康情况的关键指标为平台流量。
- 平台靠售卖商品进行盈利，体现核心业务健康情况的关键指标为 GMV 总销售额。
- 平台靠售卖会员进行盈利，体现核心业务健康情况的关键指标为会员用户量。
- ...
2、微观层面
微观层面，也即从产品某个功能点出发，去看影响这个功能发展最关键的指标。产品的某些功能可能短期内不能实现盈利，或者这些功能是作为入口或引流使用，所以需要具体分析，此处仅为补充。
比如说：
- 证券 App 中，行情功能并非产品的盈利 来源，但大部分用户都要浏览股票行情之后再确认下单，进而产生交易行为。那么在证券软件中，行情功能的页面停留时长，交易功能点击、添加自选等用户操作就是体现该功能健康程度的指标。
- 教培 App 中，社区功能也并不是产品的盈利来源，但是社区中对于课程、老师、考试的讨论，能够引起用户兴趣，进而产生咨询、购课的行为。那么在教培软件中，社区互动率、活跃度、付费商品跳转率等指标就可以体现功能的健康程度。
因此，推导产品核心指标主要看产品的核心业务是什么，核心业务就看产品依靠哪些部分实现盈利。在明确业务之后，接下来需要找到贯穿这些业务的场景。
关于如何找到指标关联场景， 产品设计必备的五张图 中有详细的说明。这里简单描述一下：
- 广告：用户从进入 App，到发现、点击广告，在广告中成单或下载。
- 电商：用户从浏览、购买、下单商品，最终确认收货，完成商品交易。
- 会员：用户自发或通过营销广告购买，或在会员功能界面进行会员付费。
确定埋点方式
确定关键场景后，我们来到埋点设计的最后一步，埋点确认。数据埋点通常有两种确认方式。第一种是按业务流程，第二种是以功能模块拆解进行埋点。
- 以业务流程进行埋点
简单来说就 是梳理业务流程，即核心的用户路径，再统计各个流程的数据。这种埋点方式可以发现用户前后的两个环节是否有巨大断层，在行业水平中处于哪种位置，通过判断和推导来优化各个环节的转化率。这种方法就是漏斗分析。
漏斗分析方法适用于明确的业务流程，每个页面都有明确的业务目标的情况。诸如电商 App（从浏览到下单）等有清晰业务流程的业务就比较适合这种分析方法。漏斗分析的使用方法也并不复杂，梳理完业务流程之后，在每个页面的关键位置进行埋点就可以了。此外在设计漏斗分析的时候要思考用户行为的许多细节。比如用户操作的顺序是否连贯，和你思考的是否一致；用户停留的时长，（多）少于多少秒可以认为是无效操作等等。
举个例子，用户在半年前浏览了小红书一篇带货帖子，半年后他通过小红书下单了同一款产品。那么能认为用户本次的购物行为和半年前浏览的带货帖子相关吗？显然不能。所以在设计漏斗的时候也需要注重时间因素。同理，用户进入到商品下单页或支付页的时候，也需要考虑不计入的时间区间，因为可能存在用户误触下单的情况。
一般，漏斗分析大体包括三个维度的数据，如下图所示。中间是根据业务流程梳理出来的页面。左边是根据事件进行埋点得到的数据，右边为去重后的用户数据。
这张图包含了许多信息。如果我们基于用户 视角进行分析，那么我们可以得到单个用户的转化和流失情况：
| 用户数 | 转化率 | 流失率 | 总体转化率 | |
|---|---|---|---|---|
| 漏斗1 | 900 | - | - | 2.78% |
| 漏斗2 | 700 | 77.78% | 22.22% | |
| 漏斗3 | 200 | 28.57% | 71.43% | |
| 漏斗4 | 25 | 12.50% | 87.50% |
如果基于事件视角进行分析，那么我们可以发现漏斗在哪些环节发现了较大的数据变化：
| 页面浏览量 | 转化率 | 流失率 | 总体转化率 | |
|---|---|---|---|---|
| 漏斗1 | 1000 | - | - | 3.10% |
| 漏斗2 | 800 | 80.00% | 20.00% | |
| 漏斗3 | 700 | 87.50% | 12.50% | |
| 漏斗4 | 31 | 4.43% | 95.57% |
之所以列举这两则数据，其实是想告诉大家，基于用户或事件的视角得到的数据是不同的。基于事件分析，我们很可能忽略漏斗 3 的流失率，似乎它看起来很正常，流失率仅有 12.5%。但基于用户视角，我们能发现在同个环节，流失率达到了 71.43%，这意味着页面 2 到页面 3 这个过程中，一定出现了哪些原因导致了过高的流失率。所以更多时候，将用户和事件视角结合起来分析，才更有可能发现数据背后的秘密。
2、以功能模块拆解进行埋点
关于产品功能模块更详细的内容可以参见 什么是产品思维？以及 产品设计必备的五张图。以功能模块进行拆解，也就是我们不走产品业务流程的路子，直接通过业务指标来设计埋点，这种埋点方式可以体现功能模块的健康程度。
以社交产品为例更为直观一些：
同样，在收集数据的时候也要注意时间这一要素，某些产品具有明显的周期性特征。比如说券商和银行软件，一般周末交易所休市，使用券商 App 的用户相对较少；周末（单日）银行营业部不营业，这也导致了用户使用银行软件的次数会明显下降。在对比数据的时候，还可以选择以周、月的维度，以及同比或环比的比较方式，以使用场景来确定使用方式。
示例：券商产品
我们以券商产品为例，来简单过一遍数据埋点的思考过程。
1、确认模块和产品特性
作为产品经理，我负责的是券商产品，它主要的模块属性是交易和工具。交易属性在于，产品提供了从开户、下单交易、出入金等有关交易的功能；工具属性在于，产品提供了行情、自选、资讯、社区等相关功能。
2、确认产品业务和场景
一般来说，使用我们产品的用户都是我们的客户（券商产品大部分功能都需要登录所属券商的交易账户），产品业务，也即盈利来源，来自用户交易过程中产生的手续费和佣金等费用，可以简单理解为用户产生交易，产品就能产生收入。因此，券商产品最核心的指标就是交易规模、交易转化率，关联场景就是行情浏览、自选添加、下单交易（买卖撤）、出入金功能。
3、确定埋点方式
最后一步是确定采取的埋点方式，是以业务流程还是以功能模块进行设计。如果是以业务流程，那么我们可以继续采用漏斗分析的方式：
如果是以功能模块进行设计，通过业务指标的拆解，我们也能够知道需要埋哪些数据：
