2.3　埋点通用内容设计方案

小白： 听了您的讲解，我对埋点整体流程清晰了很多。您刚才提到，数据人员涉及较多的是埋点方案的设计，那么，什么是埋点方案设计呢？

老姜： 埋点方案设计，目的是将用户在产品中发生的事件行为通过埋点记录下来，设计需要记录事件中的哪些信息，需要一套完整的设计规范，保障埋点内容的可执行性及通用性。

小白： 那我们需要设计哪些内容呢？

老姜： 根据设计内容的方向，可划分为通用内容设计及新页面设计两个方面。前者是在产品上线时，将一些通用性的参数设计全面，并在后期不断完善；后者是针对单次产品上线的新页面，输出埋点方案，完成单次埋点需求。

小白： 明白了，那设计的内容需要以何种方式落地呢？

老姜： 埋点方案设计，一般以“文档+平台”的方式落地。首先，需要将设计的埋点方案填入文档中，并由指定人员负责维护；其次，埋点内容最终往往落地到平台，通过平台进行埋点规范及质量的保障。

小白： 了解了，那本节您先和我讲讲，通用内容的设计需要做哪些事情吧。

老姜： 好的，那我们这就开始。

2.3.1　通用内容设计简介

在新产品上线前，需要对通用埋点参数进行系统性的制订，后续所有新页面埋点设计均会应用到此内容，并且一般通过“文档+平台”的方式进行维护。

通用内容设计主要涵盖四个方面，分别为事件、参数、页面、元素。同时，需要将设计内容维护到事件列表、参数列表、页面字典、元素字典四份文档中，以便于后期查看应用。

下面，详细介绍一下每部分涉及的内容。

2.3.2　事件设计方案

在上面的章节中曾提到，埋点的目的是记录用户在端内的事件行为信息，因此事件的规范至关重要。一个事件模型，主要涵盖事件本身及描述事件的参数。下面，我们一起来看下，事件模型需要涵盖哪些信息以及事件列表的格式。

1．事件是什么

一个简单的事件模型需涵盖三部分内容，分别为时间（When）、人物（Who）、动作（What），例如2023-12-12 11∶11∶11小白访问了某App的首页。

· When： 记录客户端及服务端对应时间。客户端时间，指用户行为发生的真实时间；服务端时间，指数据上报到服务器的时间。由于上报的延迟，一般情况下客户端时间≤服务端时间。

· Who： 记录用户ID及其设备账号信息。

· What： 记录用户的行为动作，如页面访问、页面滑动、元素曝光、元素点击等。

其中，What主要指事件本身，是事件设计中需要规范的内容。事件的设计需要注意颗粒度的粗细，这里来看个实例，大家也思考一下哪种事件设计更为合理。

背景：用户进入某App的首页，看到页面最上方的Banner，然后点击Banner位，如图2-9所示。

以上三种方式，宏观来讲都可以作为行为事件，但如果从规范性及复用性角度来考虑，只有一种方式符合预期。

方式一：粒度过于粗糙，信息量不足。通过事件命名，我们希望识别出用户精准的行为动作，然而此种方式却无法满足。其中，页面访问，无法区分是进入页面还是退出页面；行为动作，无法区分是点击还是滑动。如要区分，仍需配合其他参数字段进行识别，不符合行为事件的制订规范。

方式二：粒度过于细致，信息量过载。此种方式在行为事件的基础上增加了页面、元素等信息，导致内容过于饱满。在实操过程中，事件、页面、元素等信息需要解耦，通过不同的字段参数进行描述，以上内容可以拆解为：

· 首页访问=首页页面+进入页面事件。

· 首页Banner曝光=首页页面+Banner元素+元素曝光。

· 首页Banner点击=首页页面+Banner元素+元素点击。

方式三：粒度合适，符合事件规范。行为事件上报仅用于识别用户的动作，其他信息通过其他的字段参数进行识别。

由此可见，事件粒度的规范是需要在设计阶段进行把控的。下面，我们来详细看看常见的事件有哪些。

2．事件有哪些

事件的种类有很多，一般公司在实际操作过程中，最好将产品的细分事件控制在10～100个。太少会导致事件识别过于粗糙，而太多会导致过于分散。以短视频类App为例，核心事件如图2-10所示。

该类型App事件可粗略划分为四大类，分别为：App类型事件、页面类型事件、元素类型事件、播放类型事件。

· App类型事件： 侧重于App粒度下的事件类型，主要涵盖用户应用事件及后端进程事件。用户应用事件如激活、访问、注册等；后端进程事件如外部软件吊起事件、下载开始事件、下载完成事件等。

· 页面类型事件： 侧重于用户访问页面粒度下的事件类型，如用户进入页面时触发的页面展现事件、用户滑动页面时触发的页面滑动事件、用户退出页面时触发的页面结束展现事件等。

· 元素类型事件： 侧重于页面内元素粒度下的事件类型，如元素曝光、元素结束曝光、元素点击、元素滑动等。针对短视频类App，常见的元素包括点赞、评论、转发、关注、收藏、下拉、表态等一系列按钮内容。

· 播放类型事件： 短视频类App，最核心的功能就是视频播放，因此播放事件是其中非常重要的内容，如视频开始播放事件、视频结束播放事件等。不同类型的App，根据其应用属性，又可延展出其他类型的事件内容。

事件类型的梳理，与指标体系的梳理有异曲同工之妙，均需要通过一定的逻辑从上至下逐级拆解。同时，事件梳理的过程当中，有几点要引起注意。

注意1： 在产品启动阶段，建议将事件类型系统性梳理全面，后续如有增加，需要与整体的颗粒度保持一致，同时，需要根据规范统一维护到指定文档中。

注意2： 事件通常是成对出现的，有开始就有结束，一般会将时长等信息记录在结束事件当中。例如，页面结束展现事件，需带上用户从进入该页面到离开该页面的停留时长，用以计算时长类指标。

3．事件上报时机

在定义事件的过程中，同样需要对事件的上报时机做一个定义，以明确事件的触发逻辑。以页面展现事件为例，当用户打开一个页面时，根据页面的生成周期，可以划分为以下几个步骤。

步骤一：页面创建。 用户对页面发起请求，页面执行吊起。

步骤二：页面框可见。 页面加载前端框架。

步骤三：页面完成渲染。 页面框架及内容渲染完成，完整界面输出用户。

其中，步骤一至步骤三均可作为页面展现事件的上报时机，由此可见，不同的上报时机会影响触发的量级。如果上报时机为步骤一，则在网络延迟的情况下，即便页面没有完全加载，也会触发上报。一般情况下，会以页面完全渲染完成作为页面展现的上报时机，如果定位到更细粒度，还要规定渲染像素的程度。

上报时机的制订，一方面需要考虑客户端的实现流程，另一方面需要考虑对业务的价值。仍以短视频App为例，梳理各类事件对应的上报时机，如图2-11所示。

4．事件列表文档

梳理完核心事件后，需将内容统一维护到事件列表文档中，方便日后新增页面埋点的应用与查看。

事件列表文档需要涵盖事件的核心内容，包括但不限于事件类型、事件名、事件英文名、上报时机、作用、备注等，仍以短视频App为例，如表2-3所示。

2.3.3　参数设计方案

为了更加精细化地描述用户的行为事件，支持下游的业务分析决策，需要在事件的基础上增加参数信息。在广义的参数定义中，事件类型也是参数的一种，但由于其性质比较独特，因此会单独进行说明。关于参数的核心价值，我们来看一个案例。

参数根据通用性，可细分为两种类型：一种为公共参数，指App中所有事件均需携带的内容，如用户ID、事件发生时间等；另一种为业务参数，作为公共参数的补充，不是所有行为均需要记录的内容，如直播类App中的房间ID，仅在进入直播间时记录，非播放页面则无须记录。

1．公共参数

公共参数需要记录在用户端内的每个点位上面，涵盖端粒度、页面粒度、元素粒度等。建议通过4W1H的方式进行梳理，核心内容如下。

· Who： 记录用户自身信息，涵盖用户设备信息、终端信息、网络信息、账号信息等。

· When： 记录用户行为时间信息，涵盖事件上报时间、数据上报时间等。

· Where： 记录用户行为场景及来源信息，涵盖当前位置、来源位置等。

· How： 记录用于以何种方式应用App的信息，涵盖下载渠道、启动渠道、启动方式、App版本、App下载包号等。

· What： 记录用户触发的行为信息，涵盖事件参数等。

2．业务参数

业务参数作为公共参数的补充，记录行为事件中的一些指定内容，一般在页面粒度、元素粒度下出现频次较高。下面我们来看一个案例。

3．参数列表文档

同事件列表文档一样，参数也同样需要在业务上线前进行统一梳理，并在日后产品迭代时不断新增完善，作为数据、研发、产品的参考文档，方便埋点相关人员应用。下面附上公共参数列表文档供你在日常工作中应用，如表2-4所示。

在梳理的过程中，建议按照一定的层次逻辑进行展开，4W1H仅是其中一种方式，根据不同的产品特性，方式会有所差异。

· 参数字段名： 采用小写英文字母进行命名。

· 参数下发方： 涵盖终端及后台，根据参数的来源进行判定。

· 参数类型： 涵盖公参及私参，私参即业务参数。

随着产品页面的不断扩充，参数也会逐渐丰富，需随时将新的参数维护到文档中。

2.3.4　页面设计方案

鉴于产品页面数量很多，因此需要将页面ID和页面名称单独进行维护。一方面，保障命名的规范性；另一方面，防止页面名称出现重复。页面信息同样需要维护到文档中，其中有几点注意事项需要关注下。

注意1： 页面值的命名要符合一定的规范，例如，均以page开头。

注意2： 随着产品内容的不断扩充，页面也会越来越多，因此，页面名称需要好理解，一眼就能识别出描述的是什么页面，例如首页=page_main；详情页=page_detail等。

附上页面文档涵盖的内容，供你参考应用，如表2-5所示。

2.3.5　元素设计方案

元素设计与页面设计有很多相似的地方，不同页面可能存在相同的元素，例如关闭按钮、取消按钮、确认按钮等。因此，同样也需要一个元素列表文档，用以对元素ID、元素名称进行维护，如表2-6所示。

2.3.6　小结

希望本节的学习，可以帮助你了解数据埋点的通用内容都有哪些，并且知道如何去设计。当然，通用内容远远不局限于以上这些，只是这四个方面内容相对比较重要，需要在产品上线前期进行梳理落地。 TbHv77qXw7ww07rs/M53cFpkUSGCUa6GTRollI3gOFOaWj8J7n5RZuii37LbDHvk