如何结合分析需求，设计数据埋点？

小提示：您能找到这篇{如何结合分析需求，设计数据埋点？}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的如何结合分析需求，设计数据埋点？内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

通过数据埋点，我们能够看到产品设计与功能在数据上的反馈，并通过分析其中的数据特征驱动业务发展。

做了快3年的产品经理，相比3年前刚入行的时，现在的企业对产品岗位的要求逐渐趋于理性化。产品经理不再是“靠着一个点子就能改变世界”的玄学职位，客观的数据与理性的分析越来越受到大家的重视。

鉴于此，这里想通过文章分享我对于数据分析的一些理解和感受。鉴于涉及内容太多，这里先说开头：关于数据埋点的那点事。

一、那什么是埋点呢？

一句话概括：埋点就是一小段上报事件的代码。简单来说，就是用户在产品中产生某个行为之后，设备或者服务器把这个行为以及有关的一切信息都记录下来。

二、为什么埋点很重要？

先一起设想个常见场景：

今天，你辛苦做的积分商城终于上线和亲爱的用户见面了。出于对自己工作的负责态度，你觉得很有必要看看效果，便决定：先看看今天有多少人用了这个功能吧！于是跑去研发同学那，腆着脸让研发帮你看看，于是……

“今天？你这个今天是怎么定义的？给个具体的时间吧”

“什么算是人？IMEI/IDFA吗？还是user_id？又或者其他标准？你先给个定义”

“这个‘多少’是个啥意思？UV还是PV？”

“大哥，怎么算用？点入口吗？还是进到落地页？又或者领了积分才算？”

“Oh，舍特，开发的时候没埋点”

……

从上面的场景中，我相信大家一定能切实体验到这种被研发灵魂拷问N连击的痛苦。因此，如果我们仅仅知道要采集哪些数据，仅仅掌握一些数据分析的技巧，但却不清楚这些数据是如何收集和统计到的，那么我们对于数据的应用不仅会处处受限，更会丧失对数据的敏感度。

从另一个角度来说，埋点也是数据分析的完整路径中必不可少的第一步。在一些大中型公司，这份工作往往会由独立的数据产品经理负责，但对于市场上的大部分中小型公司，产品经理就要亲自上阵，负责埋点的定义和管理了。

到这里，大家应该就会明白两个点：

1. 什么是“埋点”？“埋点”是互联网产品收集数据的一种基础且被广泛应用的方法。
2. 为什么要“收集数据”？因为我们要获取数据支撑后续的数据分析，并最终驱动业务发展。

三、怎么理清需要的埋点？

完成了对埋点的必要性说明，以及基本概念定义后，下面分两部分详细介绍一下具体的落地实施方法：

• 第一部分：确定并梳理清楚需要哪些埋点
• 第二部分：形成埋点文档记录并同步

第一部分：确定并梳理清楚需要哪些埋点

梳理埋点的思路和梳理产品方案的思路一致，我们首先要做的，是明确你的需求是什么，这是定性的层面；接着是明确能衡量需求的数据指标是什么，这是定量的层面；最后才是确定能通过哪些埋点收集到需要的数据，从而计算指标、衡量需求。逻辑关系如下图：

1.首先是归纳需求。埋点需求一般有两个来源：产品需求的衡量指标+业务部门的分析需求。通过这个步骤，我们可以知道收集数据的目的是什么。

2.接着是选取指标。明确了需求之后，我们就需要选取能够衡量需求效果的数据指标，比如页面转化率、功能留存率、访问人数、访问频次分布等等。

3.最后是梳理埋点。梳理埋点这一步最重要的是想清楚三个关键问题：

• 需要收集哪些数据以能够计算上一步选取的指标
• 触发数据收集的时机是什么时候
• 需要定义埋点的哪些必要属性（即需要收集哪些维度的数据）

归纳需求和选取指标这两步，单独拎出来是很大的一个内容，这里就不做展开了。这里的重点是帮大家搞懂埋点，因此着重说说最后一步的“梳理埋点”：

a.首先是确定收集哪些数据以计算需求指标

这里提一个小思路：把指标按照数学里的加减乘除混酵素果冻营销方案合运算，拆解成不能再拆的单位变量，那这个单位变量，就是我们要通过埋点收集的数据了，比如“访问页面的独立用户数”。

b.其次是数据收集的时机

这里举个小例子抛砖引玉：“访问页面的独立用户数”这个单位变量中，应该在什么时机收集页面的访问数据呢？答案是都可以，你可以定义为“点击页面入口”就算访问并开始收集，也可以定义“页面加载完毕”再收集，更可以定义为“页面加载完毕且停留页面内至少5秒钟”才收集。没有正确答案，只有最能够帮助你衡量需求效果的方案。

c.最后，还要设计出既全面又多维的属性和属性值，来帮助从多个维度描述一个埋点，以支撑后续各种角度的分析需求。

埋点属性是决定分析深度和广度的关键因素，关于如何设计出完善的埋点属性，这里借用最经典的一套思维模型就可以解决：4W1H，包括Who、When、Where、How、What，即：【某个用户在某个时间点、某个地方以某种方式完成了某个具体的事情】

关于埋点里的“事件”、“属性”和“属性值”，这里举个例子帮助大家理解：

比如你想分析“买衣服”这件事，于是决定要收集相关数据来完成分析。

那么，你要分析的“买衣服”就是一个事件；衣服的颜色、大小、款式和价格分别从四个维度描述了这件衣服，这四个维度就是“买衣服”这个事件的四个属性；

拿其中衣服大小的属性来说，有M号、L号、XL号等，这些尺码就是描述“买衣服”这个事件中，衣服大小属性的不同属性值。

大家在进行埋点设计时一定要弄清楚这种层级关系。

关于这几点的概念，大家如果百度一下，也能清晰知道：

事件指的是可以被记录到的操作和行为

属性就是对于一个对象进行刻画的维度

属性值是定义属性的特征或参数

通过以上五个角度对埋点进行拆解和梳理，并结合可能会产生的数据分析需求点，基本就能够设计出比较完善的埋点属性了。

第二部分：形成埋点文档记录并同步

关于数据需求文档（Data Requirements Document，简称DRD），有一种更通俗的叫法：埋点文档。埋点文档存在的意义，本质上和产品需求文档一样，一方面是利用文档本身的时效性和易追溯的特点，另一方面也是作为与研发沟通的工具，充分避免歧义，保证埋点质量。

一旅游与公关危机份合格的埋点文档，不仅详细定义了埋点事件，说明了每个埋点事件的触发时机、属性名称、属性值类型以及属性值来源、埋点方式等内容，也详细记录了录入时间、埋点状态、对应版本和埋点迭代记录、附加备注等便于管理的内容。

这里分享一款Feed流产品的数据采集案例，这里建议大家把这个案例中的埋点文档复原下来，形成自己的“埋点案例库”，以方便以后的学习和应用：

四、【案例分享】如何设计分享功能的埋点？

这里以最常见，也最基础的分享功能，按照前面的方法给大家分享一下我是如何完成一次埋点梳理的。为了方便大家理解，这里拿微信公众号文章的分享功能举例，总体思路如下：

1. 理解数据采集的需求目的，并梳理分享的页面跳转逻辑。以理解分享的具体价值和需求场景，知道要去采集什么数据才能帮助评估。
2. 完成指标的定义，并根据指标算法来梳理埋点事件。比如根据“分享率=分享量 /访问量”，就可以定义出“分享页面”和“浏览页面”两个行为事件。
3. 围绕4W1H完善埋点属性的设计，并撰写埋点文档。除了支撑数据指标的计算需求外，还要能够支撑实际工作中可能出现的分析需求。

第一步：通过梳理页面逻辑理解业务需求

对于微信公众号文章的分享功能，需求目的可以从几个层面去理解：

• 对于公众号的作者，通过了解文章的被分享次数和分享率，可以帮助从侧面评估文章质量以及传播性，从而帮助作者产出更优质更有传播性的文章；
• 对于公众号的读者，通过分享到不同渠道，完成表达自我、树立人设的同时，也能够借助社交推荐，形成基于公众号的社交互动；
• 对于微信平台，通过了解分享率，战略层面上可以通过公众号完成微信生态上的内部闭环和外部延伸，功能层面上可以帮助评估渠道优先级，优化分享体验。

假设通过需求分析，确定了目的是为了帮助评估公众号文章的传播效果。在明确了具体的业务需求后，为了更好地理解需求和指标，为后续埋点设计建立基础，我们就需要梳理一下公众号文章分享功能的页面逻辑，如下图：

第二步：定义具体指标，并梳理埋点事件和其他分析需求

通过梳理完需求目的和主要页面流程之后，我们基本上就能对需求有一个比较深刻的理解了。这个时候再分别对数据指标进行定义时就会比较顺畅，如下表：

从上面对「微信公众号文章的分享率」这个指标的算术定义，可以发现是由两个单位数据指标组成：

• 成功分享「书影音档案」模块的UV
• 访问「书影音档案」模块的UV

因此不难发现，这里涉及到两个埋点事件：“分享页面”、“浏览页面”。但是否意味着，我们只需要记录分享人数和浏览人数这两个数据就够了呢？

事实是远远不够。因为在数据分析中，很多情况下我们会尝试从很多角度去拆解分析数据，产生更多分析需求以找到更多对业务的思考和优化。但这些数据如果没有及时统计到，在我们亡羊补牢前，都无法再获取到这些有价值的数据了。比如针对「分享率」这个指标，可能我们还会想知道：

• 什么时间分享的？分享了几次？
• 分享的是哪篇公众号文章？
• 用户选用的是哪种分享方式或渠道完成的分享？
• 分享是否成功？如果失败，失败的主要原因是什么？

*注：关于是否分享成功这个需求，由于外部渠道的多样性，我们假设成功回传数据并弹出“分享成功”的toast提示就算分享成功。

从上面的例子可以看出，在确定了主干数据指标后，还要有意识地提前思考潜在的数据分析需求点，这样不仅可以更全面地帮助理解“分享率”这个指标，支撑不同角度的数据分析需求，还可以帮助设计一个结构更灵活的埋点事件，避免后续的埋点堆砌甚至重构。

第三步：围绕4W1H标准设计埋点属性，产出埋点文档

通过前面的说明，我想大家都意识到了要收集更多维度的数据。那么问题就来了：既然需要多维度收集数据来支撑可能的分析需求，那我到底应该从哪些维度设计埋点呢？答案就是前面说到的“4W1H标准”。按照这个标准去思考，并试着结合可能的分析需求去设计对应的埋点属性。这里用“分享页面”举个例子：

Who：用户ID、昵称、性别、年龄、来源等

When：分享的时间、是不是首日分享、是不是首次分享等

Where：进行分享时的地理位置

How：设备型号、操作系统、系统版本、APP版本号、网络类型、分享的渠道、是否分享成功等

What：分享的公众号ID、分享的公众号文章ID等

通过以上步骤的梳理，我们基本得到了一个埋点的骨架，最后一步要做的，就是在数据需求文档中，把埋点信息进一步填充起来。这里拿分享页面的事件举个例子：

*注：如果对于所有的埋点事件，都有一部分相同的数据需要记录（比如上面的用户id、时间、ip、设备号、网络等等），就可以采用合并省略的方式，作为默认必埋的预置属性，记录到开发埋点规范里。

对于自有数据管理比较完善的团队，也会有自己统一记录埋点的方式，例如下面这种形式：

当然，其中涉及的一些具体操作方式可能并不适用每一个团队，但其中的核心思维倒可以参考一二，毕竟对于同样结合了理性分析和感性思考的数据分析工作来说，有逻辑结构的思考方式往往才是最有用的借鉴点。

本文由 @鱼头 于，未经作者许可，。

，基于CC0协议。