数据埋点设计 数据产品经理教程

数据埋点设计

本内容来自：https://gairuo.com

说明

数据产品经理教程 正在编写中，欢迎大家加微信 gairuo123 （备注：数据产品教程） 提供意见、建议、纠错、催更。应大家要求，作者开办数据产品和数据分析培训班，详情 数据产品经理培训 / 数据分析培训。

本内容来自：https://gairuo.com

埋点设计要解决的是收集什么场景的数据、具体收集哪些信息，如何上报这些信息， 同时保证从需求到实施再到使用的合理性、工程便利性。本文将介绍埋点设计中的一些方法论和工程思路。

设计原则

埋点是收集数据的过程，数据最终是为业务分析和使用来服务的，因此，在埋点设计前需要分析业务对哦数据的需求。一般设计要遵循的埋点设计原则有：

这里要简单介绍下埋点需要关注的信息，这里总结为由“5W2H分析法”简化而来的“4W1H”用户行为模型：

常见问题

以下是一些埋点常见的问题。

什么是埋点？为什么要埋点？

埋点是事件跟踪工作的俗称，埋点是指对用户的行为或者系统的行为，通过技术手段，记录下相关信息，类似于开发打打印系统运行的程序日志。埋点目的是为了了解系统的运行情况，或者用户的行为细节，埋点往往是面向业务的，埋点可以超前、冗余采集数据。

常见的埋点方式是什么？是怎么样的机制？

众所周知，埋点有全埋点、代码埋点、可视化埋点等几种方式，这几种埋点方面各有利弊，较大的公司一般采用的是代码埋点。代码埋点就需要开发依照数据分析需求所需要的数据，在一定的时机下进行埋点开发，采集指定的数据信息，在这个过程中，埋点的最初的动力来自业务分析需求，一般是业务运营人员的诉求，而做埋点设计（什么时机埋，要采集什么数据）是承接这些诉求的产品经理，开发人员再按埋点设计进行埋点开发，埋点功能上线后，数据流向数据分析系统、数据仓库，供数据分析人员进行处理、分析。在这个埋点为源头的数据生产消费链条中，往往有很多角色和人员参与，共同实现了公司业务的数据驱动。

做埋点设计的时候，我们在设计什么？

做埋点设计其实是在创建一个数据表，或者给这个数据表增加数据，这个数据表就是我们未来要查询数据的地方。期间，有两个点需要关注，一个是上报的时机，什么时候上报数据，代表着你的数据是在什么场景下得到这份数据，这与你的分析需求非常相关，你想分析的是用户的点击行为，但这份数据却是用户滑动时上报的，就不能满足你的需求；第二个是需要收集的数据信息，即事件的属性，哪些信息是你关心的，比如，我要分析用户点击的黄色按钮的次数，你就需要计下用户的 ID、按钮的颜色，以便于按按钮颜色进行筛选数据。

埋点设计工作应该由谁来完成？

假定你说的埋点设计是针对直接业务需求而进行的埋点工作，这部分最优的方案是由设计相应功能的产品经理来完成，因为埋点面对的是业务需求，同时也是产品需求的一部分，开发也依赖产品的输出进行开发工作。但是，不同团队的产品在埋点设计上能力可能有相应的差距，这时候建议团队的分析师进行辅助，即使产品有超强的埋点理解和设计能力也建议团队的分析师评审一下埋点设计，这是因为分析师清楚如果要满足业务的数据需求，需要哪些原始数据，而这些数据很可能正是由埋点而来。

我的项目一定会涉及埋点吗？

不一定。我们知道，埋点重点是在收集用户的行为过程和系统的行为，如果你的业务不关注用户的行为过程，以结果分析为主，那么很可能不需要埋点也能完成你的分析工作，解决你的需求的数据可能已经存在你的业务数据库里。例如，我想知道用户平均每月消费多少金额，你的业务库肯定（必然）会存储这些信息，那么你只需要联系数据产品经理，取得这些表在数据仓库的位置，直接进行分析。

公共埋点的优缺点是什么？

我们一般使用的埋点都是自定义时机、自定义属性，这些事件经由APP、H5 端集成SDK提供的能力按需要进行数据上报，但公共埋点对时机、属性进行了托管，在埋点设计时，只需要选择合适时机的公共埋点并按数据模型填充数据进行上报。

简单说，公共埋点的最大做点是时机由平台统一提供，确保数据的准确性，在埋点设计、开发无需关注时机，同时数据模型一致，做到认知统一，提高了效率开发、业务数据建模效率。但缺点是对数据模型需要一定的学习，如果公司无可视化数据探索产品，需要编写 SQL。

埋点设计的交付物是什么？

如果没有埋点管理系统，会按 Excel 模板填写提交，如果公司有埋点管理系统需要填写在埋点管理系统中。

公共埋点事件的优缺点

公共事件旨在解决以下问题：

公共事件基于以上问题的优点有：

公共事件的主要挑战有：

对应挑战的解决方法：

工作机制

埋点工作参与的团队：

下图是关于埋点团队协作流程的最佳实践：

埋点团队协作流程

设计元素

埋点最核心的其实是两点：

以上就是两个重要元素的对象：事件。

我们把所有的数据上报抽象为事件，这些事件不论谁，无论上报什么信息。

埋点设计一般有两种思路，一个是基于时机，一个是基于事件。时机关注埋点发生的源动力、行为本身，事件关注事件的结果，影响。

相对来说，时机更加抽象，事件更加具体。

时机

时机就是事件场景，因什么而发生，发生了什么，由谁来触发。触发者可以是用户、系统、运营人员，本质还是系统，系统是事件发生的代理者。一个时机应该包含以上的隐含信息。

常见的时机有：

事件

事件往往站在结果的角度，对业务的影响，更加业务化。这时，事件不会过于关注埋点的触发场景，更多的聚焦在业务结果上。因此，事件往往有很多的时机，多种时机会产生一个事件。

常见的事件有：

我们发现，上边很多事件其实都是由「点击」而来的。

上报信息

埋点上报的信息一般分为：

此外还有一些额外的通用模型信息：

以下是一个埋点设计表：

埋点设计表

公共信息

埋点信息：

用户信息：

设备信息：

应用信息：

位置信息

互联网产品，特别是面向 C 端的产品，在内容呈现方面往往以区块为主体分隔，在区块中展现具体的业务内容。模块是指在展示界面中展示一批具体内容的区域。这些区域内部来看，往往承载了相同性质的内容，如视频、文章、商品等，或者表达了一种聚合方式，如推荐模块中的内容类型可能是混杂的，但此模块则表示模块中的内容全部来自于推荐。

在模块的外部来看，不同模块代表了不同的内容类型，或是不同的内容维度。

模块的编码：模块的顺序一般是从左到右，从上到下，并对界面中所有的内容全部（包括弹窗、默认隐藏内容等）纳入编码范围。

界面信息：

界面层级：

模块信息：

内容模型

内容是指在模块中展示的业务实体（如视频、文章、商品、用户等）、交互元素（如按钮、输入框、广告位等）。业务实体一般会动态变化，会按业务逻辑更新或者按用户进行随机推荐，交互元素一般为固定的内容，具体内容不会变化。

内容的编码：业务实体从 0 开始编码，交互元素单独起名。

内容：

其他信息

通用事件

为了满足任意场景的需求，可以设计一个通用的埋点模型，时机由上报方自行决定，除了公共信息外用以下属性加以区分：

其余字段均为自定义属性，有几种设计方式，一为（属性名和值成对）：

还有一种方式是（属性值，自己记住不同位的取值意义）：

还有一种是（将数据属性上报为是 json 格式）：

其他

关于视频，统计播放情况，可周期性上报心跳。

参考

< 数据埋点采集 数据产品经理教程 UTM 来源路径跟踪模块 >

更新时间：2022-07-26 11:10:40 标签：埋点 设计 大数据

无「盖若」授权，请勿以任何形式转载，公众号：gairuo
Copyright © 2019 - 2024
Gairuo.com All Rights Reserved v8.8.240502

备案 京公网安备11010502033395号 京ICP备15019454号-4