一、背景说明
1.说明
- 数据化背景下，公司会越来越注重用户的行为数据，以基于用户的行为数据表现进行对应的产品体验优化设计，或进行用户行为洞察后实现精细化的运营。常规的埋点选择都是自有的埋点体系，或购买第三方的服务。采用不同埋点方式的考虑，在我看来，主要是从成本、效率和实际业务场景考虑
2.埋点定义
- 埋点，就是部署在前端，或服务端的一段代码，当用户触发了某种特定的操作，这段代码就会生成一条数据发送到数据库里，这条数据会记录哪个用户在什么时候以什么样的方式做了一件什么样的事
3.数据上报方式
- 事件上报的触发逻辑上面来讲，可分为前端触发上报、前端获取后端汇总结果后上报、后端触发上报、后端获取前端属性汇总结果后上报四个
前端触发上报(前端埋点)：事件所有属性由前端产生，由前端上报
前端获取后端汇总结果后上报(前端埋点)：事件部分属性由前端产生，部分由后端产生，后端产生的信息传到前端，汇总后由前端上报
后端触发上报(后端埋点)：事件所有属性由后端产生，由后端上报
后端获取前端汇总结果后上报(后端埋点)：事件部分属性由后端产生，部分由前端产生，前端产生的信息传到后端，汇总后由后端上报
4.作用
- 通过埋点方式捕捉用户行为，对应从数据层面回推用户行为共性，对应做运营动作调整或相关的数据洞察
5.自有代码埋点说明
- 个性化程度高，根据每次新业务、新活动的需要，对应进行事件设计和属性的采集，活动一上线就能快速基于采集的数据和内部业务数据进行全链路的打通。所以会采用自有代码埋点主要是从效率，以及数据打通的层面考虑。对于运营活动类、购买报名落地页类的埋点，会建议采用自有的代码埋点，然后通过一些关键标识，比如活动的uukey、落地页的distinct_id、user_id、order_id等，实现用户行为数据和内部业务数据的打通。
- 不采用第三方SDK服务的考虑是，一方面是第三方是按数据量收费，另一方面是太多业务数据不会在埋点的时候一起进行上报，因此很多时候需要将业务数据上传到第三方平台（加重数据量收费），或将第三方平台数据拉回内部数仓（总体节奏效率拖慢，不利于运营的快节奏）
6.第三方SDK埋点说明
预置了很多常规的属性，研发侧能够直接进行SDK的调用，开发成本相对于自有代码埋点低很多。比如神策的SDK，对于常见的场景信息埋点都已经在预置属性里面体现，对应埋点设计时只需考虑一些个性化的属性。
第三方SDK具备较完善的用户唯一标识、数据传输机制（数据丢失补传，自有埋点一般没有考虑这个）。最重要的是能够结合第三方的软件特性，能够结合应用其软件服务，进行各种事件行为分析。
对应APP原生的功能埋点，一般会采用第三方的SDK，因为其不涉及太多业务的信息数据，更多的是分析用户的行为路径，对应去优化整个APP的布局和流量的分配。不采用自有埋点的考虑是，自有埋点对于多样的设备产商，很多属性的采集覆盖面不是那么好，而第三方SDK已经将这些问题进行了预处理，并且具备完善的数据管理体系和应用体系
二、用户标识
用户标识是解决如何定位同一个用户的问题，常见的用户标识有用户ID和设备ID，对应非注册用户状态下的用户，一般没有业务定义的用户ID，只会有对应设备的ID（基于IDFA、CAID等进行获取）。而埋点为能够将此两种状态下的同一用户进行关联，会定义规则，给每一个用户生成一个唯一的ID
1.自有代码埋点标识
- 自有埋点体系的唯一标识为distinct_id，基于多种规则，能够对用户进行标识，对于注册用户，同步会采集用户ID（user_id），非注册用户则填默认值0
2.第三方SDK埋点标识
- 第三方SDK，常用的神策埋点SDK，基于多种生成规则，对用户的唯一标识为user_id，而基于用户的注册与非注册状态，对应采集用户ID/设备ID，存储进distinct_id中
- 神策用户标识生成规则可查看神策官网用户标识知识文档
三、埋点规范
埋点数据采集是常见的三大数据来源之一，其数据质量会关系着后续基于数据做出的一系类动作，因此，需要在前期的设计规则之时，就对埋点的质量进行严格的把控。从数据产品层面出发，主要把控埋点的质量主要从三方面：总体的需求流程规范、前期的埋点设计规范限制、埋点文档的审核规范把控、后期的埋点上线验收
1.总体的需求流程规范
2.埋点设计规范-自有埋点
2.1.埋点产品文档-自有埋点
2.2.埋点文档元素说明-自有埋点
2.3.埋点设计规范说明-自有埋点
总体设计原则说明：同属性的模块尽量做成统一事件，通过属性维度进行区分，特别是点击类事件，常可以抽象成单一事件，个性化需进行解耦
- 高复用：设计事件之前，需思考模块的事件是否可通过之前的事件进行增值设计，同样属性的定义也需查看对应的属性列表，实现事件和属性的复用，避免重复造事件和属性
- 高内聚：同属性的模块尽量做成统一事件，通过属性维度和模块维度等进行区分，比如：同一页面的不同元素icon
的点击，可以抽象成一个点击事件，通过icon名称区分用户所点击的元素内容 - 低耦合：模块个性化差异较大，需要上报的页面内容信息有较多差异，建议解耦出来，做成不同事件，便于后期的迭代域扩展，比如首页的画作区与视频区，对于模块的浏览的观察点，一个更关注CTR，另一个更关注有效播放，因此适合解耦成不同的事件
案例说明：
背景：对于同一个页面，存在两个按钮：按钮A和按钮B，点击该页面的任一一个按钮icon，其需要捕捉的相关信息都是：页面名称、页面类型、渠道、活动ID、用户ID等，因此，有如下两种设计方式
方案1：两个按钮的点击做成两个事件
方案2：抽象成一个事件
说明：上述两个埋点都能够满足对用户行为的检测，同步在都能进行对应的数据分析。因此需回到业务层面或最终的指标层面，若对于该页面的这些属性维度，后续会对比分析不同按钮的点击量、或汇总起来一起分析，则建议采用第二种方案。若两个按钮是完全没有关联关系，也不会放在同一业务层面上面进行分析，则建议分开做，采用第一种方案
3.埋点设计规范-神策埋点
3.1.埋点产品文档-神策埋点
- 说明：神策有平台自身提供的固定的埋点产品文档，因神策的埋点文档需要导入神策的数据管理后台，因此进行埋点设计时需严格遵循该文档的格式进行撰写，保证研发侧能够顺利将文档导入神策后台，保证数据能够正确入库，神策的埋点文档和自有埋点的产品文档是基本一致的，主要的区别是神策的埋点是用户-事件模型，因此会区分对应的用户表和事件表
- 预置属性：即默认所有事件都有采集的属性，主要是事件触发场景的一些属性，在设计事件时不需要再重复定义
- 用户表：以用户为维度，对应采集的用户属性值，一般是增量变化，研发会对应做数据初始化。常规是存放一些和内部业务数据相关的用户属性，一般较为稳定，一般产品设计埋点事件时不需要去修改，若需新增用户业务属性，需和数据产品同步沟通
- 全埋点事件表：APP初始化进行的埋点事件，主要是一些用户在APP表层的一些动作检测，一般采集的属性相对简单
- 自定义事件表：一般产品主要修改的是该部分，对应对所新增的功能模块对应进行事件设计，注意事件的设计需要遵循和自有埋点的设计理念，采集的属性也需要对应做扩展性和复用性的考虑
- 公共属性：和预置属性相识，为默认所有事件都会采集的属性，一般存放的是业务强相关的一些属性，一般产品也不需要修改该部分内容，若需要新增，徐鹤数据产品同步沟通
3.2.埋点设计规范说明-神策埋点
- 总体设计原则说明：不管是神策埋点或自有埋点，整体的设计思路都是相同的，都是基于实际的业务场景，尽可能的进行抽象设计，同样遵循高复用、高内聚和低耦合的原则，保证事件的可解释性和可读性。具体的设计原则可参考自有埋点的设计
案例说明：
- 背景：APP存在多种运营活动资源位，需要对整体运营资源位进行对比分析，划分资源位的流量能力，以对活动进行流量划分
- 分析：APP的资源都是运营活动的出口承载，在用户行为层面，所关注的信息点基本都是一致的，对此，我们不需要单独对每一个资源位对应做不同的事件设计，可以采用同自有埋点样例方案二的设计方式，通过相关属性的区分，将运营资源位全部抽象成同一个事件，便于后续的对比分析和使用
4.埋点审核规范
说明：埋点审核规范是在埋点进行开发前，对埋点合理性的把控，主要是对产品所设计的埋点是否遵循设计规范、对应的文档描述、采集属性的必要性等进行把控，保证所采集的数据具备一定的分析价值
4.1.自有埋点审核规范
- 说明：自有埋点的审核主要通过wiki进行标识，提示对应需要修改的点
4.2.神策埋点审核规范
- 说明：神策埋点主要审核是否按神策埋点文档进行撰写，保证埋点文档能够按要求顺利导入神策后台。对应问题会直接进行沟通并对应做调整
5.后期的埋点上线验收
说明：埋点的验收主要包括对事件数量，对应事件采集的属性是否齐全和准备，事件触发的实际是否正确
5.1.自有埋点验收
- 说明：自有埋点的验收方式课通过测试环境的链接、APP等，对应通过进行对应的用户行为，通过查看网页接口请求和返回的文件进行数据查看验收，查看页面是否产生对应的事件数据，同步可在测试库中进行数据查询，保证数据的正确入库，且数据入库是否准确
- 关键验收点：对应埋点体系下的一些细节点的验收，这里就不举具体的示例
5.2神策埋点验收
- 说明：神策埋点验收可在神策的测试环境上进行数据查询，同步也可在网页端或者APP端，通过实际用户行为，通过查看网页接口请求和返回的文件进行数据查看验收。同步验收的细项和自有埋点类型，也是对对应事件的上报属性维度、数据准确性等对应进行采集