数仓埋点体系与归因实践

Posted 2022-12-14 浊酒南街

目录

• 1. 埋点体系建设
• • 1.1 埋点分类
  • 1.2 开发流程&保障
• 2. 数仓建设
• • 2.1 业务架构图
  • 2.2 数仓架构图
  • 2.3 事实表建设
  • 2.4 维表建设
  • 2.5 dws表建设
• 3.uuid和归因建设
• • 3.1 uuid建设
  • 3.2 归因建设
• 4. 数据应用
• 5. 未来展望

导读：当今是流量为王时代，严选作为电商，流量建设就显得尤为重要。流量数据建设比业务数据困难，因为其数据源本身是一些半结构化的数据，没有分析维度的概念，而且流量的数据杂、脏、乱，对数据的检验、整合、治理的难度就会更大，本文将从整个流量链路阐述展开介绍。

1. 埋点体系建设

埋点体系建设是流量数仓建设最核心的一环。流量数据的源头主要是埋点，埋点体系建设的好坏直接决定了流量数据质量的好坏，直接影响了上游应用的数据质量以及业务对数据的可信度。

1.1 埋点分类

在技术上的分类，埋点一般分为前端埋点和后端埋点：
前端埋点
将采集的 SDK 集成在终端上，主要分三种：代码埋点、可视化埋点、无埋点。
优点：较方便、灵活，能方便手机到用户在界面上的行为数据，比如用户点击了哪些资源位。
缺点：依赖客户端环境，一般对采集的数据压缩、暂存，为减少移动端的数据流量，除一些需要实时上报的重要事件不限制网络环境，其它事件一般只在wifi情况下上报，因此数据会有延迟，丢数据等弊端。

	代码埋点	可视化埋点
概念	需要埋点开发同学侵入埋点代码	和无埋点原理差不多，产品或者运营同学可以在管理平台配置需要的埋点，然后SDK定时检测识别埋点的的控件，获取埋点数据，无需埋点开发同学介入。
优点	高度定制、控制精准、采集的数据丰富准确	实施成本低
缺点	实施成本大	场景局限于交互，覆盖面小

后端埋点

将采集的 SDK 集成在服务端，就是我们常说的后端日志，比如登录日志。

优点：由于数据是在内网传输，数据传输的即时性强，丢失数据的风险小

缺点：采集数据少，无法获取用户界面行为数据，爬虫数据较多

严选属于电商业务比较复杂，会面临更多的业务分析场景，需要精细化运营，采用的是代码埋点+基于xpath无埋点技术结合。定义埋点实体（SPM+SCM+ACTION)。SPM就是页面位置信息，SCM是业务参数（比如素材、ab分组数据），ACTION是指一系列的用户行为动作。
SPM语义化
页面位置信息采取统一的英文定义+后置的埋点关联来实现

SCM统一化
后端统一透传json化业务参数

  "extra": 
    "k1": v1,
    "k2": v2,
    "k3": v3
        

ACTION标准化

1.2 开发流程&保障

埋点的大致开发流程：

2. 数仓建设

2.1 业务架构图

2.2 数仓架构图

2.3 事实表建设

事实表建设的大体思路还是：选择业务过程->选择粒度->确定维度->确定事实->冗余维度。
流量事实表建设，很多人认为其没有业务过程，其实不然，只不过不像交易域拆分那么明显，从下单->支付->完结。其业务过程就是用户的一系列行为，并且这这些数据都是掺杂在埋点里面的。
事实表建设相对简单，主要根据业务分析场景，做一些子主题域的拆分，比如活动、搜索等等，每个子主题域的事实表都内聚了相关的埋点数据并且会有一些维度冗余。

2.4 维表建设

维表建设是流量数仓里面很重要的一部分，维表的数据来源主要是两部分，分别来源于业务表数据和埋点明细数据。前者设计逻辑相对简单，基本都是直接从业务表同步过来的，因为业务表的数据量不大，从实现跟维护成本上考虑，现阶段都是做成周期快照表的形式；针对用户或者设备的访问属性，通常会从事实表出，比如设备的首次访问和末次访问时间。

2.5 dws表建设

dws建设主要是做了一些通用粒度和指标的下沉计算，有同学可能会有疑问，为什么要单做uuid粒度的dws模型，不是已经有更细粒的模型了么？不是可以直接从uuid更新粒度的模型汇总吗？
这个主要分两个方面来说，一是减少计算成本、二则是为了保持dws表的可扩展性和降低dws表的使用成本。不同粒度叉乘会含些特有的指标，比如uuid叉乘商品粒度有些指标是商品特有的，比如商品访问。uuid粒度的模型是基于某几个更细粒度的模型汇总来的，所以口径上也是一致的。
在模型设计中，考虑的原则主要还是： 高内聚低耦合 、成本与性能的平衡 、数据一致性。

3.uuid和归因建设

3.1 uuid建设

为了解决账号跟设备的多对多的问题，用户身份判断不唯一的问题，我们做了i_code方案（维度上统称为uuid）。

3.2 归因建设

归因体系建设是流量资产建设中很重要的一部分，目前严选大体上主要分三类：用户触达归因体系、站外渠道归因体系和站内导购归因体系。
我这边负责的是站内导购归因体系，所以重点会说下这方面的归因迭代建设。
用户的路径往往杂乱无序，如何从这杂乱无序的用户行为中抽丝剥茧地去追踪他的行为链路，归属他的交易，那就要说到页面导购体系，页面导购体系通过对用户行为的追踪，变现交易的归属，使我们对用户的判断从“盲人摸象”的状态到交易，路径的有迹可循。

业界归因方式较多，分权，平摊，末次，时间衰退等，此处不对各种类型过多介绍。
结合严选电商业务特性，最终严选采用两种归因方式：
末次单点归因
末次多点归因
原因如下：电商中有的页面天然作为用户必经页面，比如首页或者搜索页，这些页面作为用户在站内导流的入口页，这里引入的入口页概念，其实可以形象的理解成我们商场的大门，商场一般会有多个大门用来导流用户，入口页职能承接了流量在站内分发的作用，此处如果采用多点归因方式，那对于全站来说，大多用户都需要进过这个“大门”，多计导致的问题是销售会被过多的归因到这些所谓的入口页，所以此处针对入口页我们采用末次单点方式的归因，一是解决入口页的合理归因，二是也划清各个入口的交易，一举两得。

为了达到精准归因的目标，站内导购的归因建设主要经历以下了三个阶段：

每个阶段的方案建设都是基于埋点基建：
初期的导购方案需要很大的人工介入，每新增一个页面，都需要人为定义页面层级，维护成本高，行为链路依赖时间序列，准确性完全依赖客户端的时间；
中期的方案解决了初期的遗留问题，依赖客户端埋点的上一步的sequence，但是这种方案只能应用在离线数据；
现阶段的方案能够应用到实时数据中，单个埋点会透传前10步的行为链路，在获取链路的时候就无须通过关联。

4. 数据应用

在通用化工具层面，流量数据主要用在：DSP(广告投放平台)、DMP(用户标签、用户画像）、A/B实验平台、用户总线服务、BI报表、数据产品(包含用户行为分析系统、营销数据运营平台等等）；
在业务上层面，应用场景包含：广告投放、拉新促活、智能营销、流量赛马、搜索推荐等。

5. 未来展望

严选的流量数仓的建设已经趋向于成熟与稳定，未来主要是在三个方向：数仓的自动化构建、dws建设完善、集市层模型的升级。
数仓的自动化构建正在进行中：目前已完成的是ods层会代替原有的mid层，ods只需要在平台进行简单的算子配置即可完成自动化落仓。集市层的自动构建还在进行中；
dws的建设还不够丰富，目前集市层会有一些重复加工的指标逻辑存在，目前正在逐步步下沉到dws；
集市层模型的升级更多的依赖olap引擎的计算能力，后续会引入doris，借助其物化视图的能力 ，减少集市层的模型数量。