（干货）美团外卖流量数据采集历史——美团-欢乐点，智慧门店服务商

（干货）美团外卖流量数据采集历史——美团

2023-10-22 12:01:17 欢乐点

流量数据采集

1.美团外卖流量数据采集历史

先介绍下我们团队做流量数据的历史演变过程，我们是从2015年开始做流量数据建设，初期的需求比较简单，主要是剖析一些用户行为的PV/UV。对此我们定义了一些code埋点，它是一种顾客端和服务端联合的日志，同时在顾客端实现了链路追踪，整体实现还是比较简单的。

2016年开始，我们业务整体发展迅速，须要深入剖析用户行为，所以我们在服务端定义了一套完整的日志采集规范，定义了page（页面）、block（模块）、item（元素）、（来源）、（目标）等采集内容，但是在数仓层面完成了归因统计的数据建设。

到了2017年，我们的数据采集使用集团的流量体系，这套体系是顾客端日志，主要有下列三个部份：

下边简单介绍下埋点在技术上的分类，通常埋点分为后端埋点和前端埋点两种。

后端埋点：

将采集的SDK集成在终端上，主要有三种：代码埋点；可视化埋点；无埋点。美团使用的是代码埋点，它比较显著的优点是：

可视化埋点和无埋点原理差不多，PM和营运朋友可以在管理平台配置须要的埋点，之后SDK定时检查辨识埋点的的控件，获取埋点数据。相比而言可视化埋点施行成本很低，而且埋点质量上我们认为代码埋点远低于可视化埋点，假如场景简单或则业务处在早期阶段，建议使用可视化埋点或则无埋点这些成本较低的方案；假如业务比较复杂，公司研制规模比较大，但是对数据建设有比较高的要求，代码埋点是最好的选择。目前业界内，神策数据这几种方案都支持，主要是支持无埋点。

前端埋点：

如今极少单独使用，基本是和后端埋点搭配使用。它的优点是外网传输，即时性强，遗失风险小。

2.埋点信息与风波介绍

埋点采集的信息可以分为环境信息和业务信息两大类。

埋点风波分类主要分为三大类：

如上图中左下角是个实例：

在APP页面的底部，我们用红色框圈中的部份是一个，上报这个日志的时侯会携带，和首页pv日志的值相同，上报爆光、点击日志的时侯就会有一个自己的惟一标示。中间是频道区，同前面的一样上报时就会携带，每次点击就会上报模块惟一标示，这15个频道会分别上报15条爆光日志，它们的、相同，通过位置数组（从0位到14位）来分辨。再下边这个的位置日志上报规则同底部相同。

在这样的风波分类下，我们把一个用户行为依照时间排序得到图中右下角所示的序列：用户首先步入一个页面上报PV日志，会看见好多模块上报MV日志，之后点击某个模块上报MC日志，接着发生跳转跳到新的页面，之后接着浏览、点击、跳转、浏览......

从这样一个序列中可以看出在整个上报日志中，数据量最大就是MV风波。

3.埋点规范与协作流程

接出来介绍埋点规范与协作流程以及一些问题点。埋点这个事情是一个多团队协作的事情，须要你们一起协同，所以流程、规范很重要，不然会发生何必要的分歧。

协作流程：我们的流程是这样的，先由需求方提出需求交给业务PM，业务PM在埋点平台做埋点配置，埋点平台依照配置生成代码给到顾客端RD，顾客端RD使用埋点SDK做埋点施行，施行以后由顾客端QA来测试校准之后上线，接着数据组RD使用日志数据表加工数据将数据结果交付给数据组PM，最后将结果交付给需求方。这儿简单说下埋点配置环节，在美团外卖是由业务PM来统一负责，同时数据团队做规范的指导、定期出席一些埋点评审。

埋点规范：主要是约束一些数组的上报方式，包括数组名称、上报时机等。

问题排查：在问题排查方面，我们有一套比较完整埋点问题追踪流程，也是便捷后续做埋点问题的复盘。

埋点SLA：我们专门拟定了一套埋点SLA(Level-服务级别合同)机制，目前这块主要由顾客端RD和QA来保证SLA，业务PM按照埋点重要性提供须要保证的SLA列表，数据组提供监控工具。

数据生产链路主要有以下几个阶段：需求、配置、埋点、验证、上报、日志表。

流程是：在需求确定以后会做埋点的配置，顾客端进行测试上线。以后顾客端会依据用户行为将日志上报（这儿分为实时上报和延后上报两种）到nginx服务器，通过flume将日志搜集传输到kafka里，之后做实时处理，包括数据校准、过滤、字段分拆等比较简单的数据处理，然后将数据落地到离线的log表，在离线阶段的会进行比较重的数据处理操作，例如去重、关联、标记等，最后产出公司级别数据表，提供公司各个业务部门使用。

4.埋点注意事项

后面介绍了埋点的基本信息与规范流程，这儿给你们介绍一些埋点的注意事项。个人认为做埋点还是十分须要经验的，甚至是须要更多的试错，这儿给你们列了一些注意事项以供参考：

同质参数的名称和类型保持一致：主要就是彰显在通用参数、业务参数、行为标示的统一，尽量做到事前整治，给整个的数据加工、数仓建设减少工作量，其实在数仓加工过程中也一定要做一些容错；

通用复用：尽量少的创建新的风波，而是想办法复用原先的风波，便捷后续的埋点管理；例如某弹窗在好多页面都出现过，弹窗模块爆光标示须要是惟一的，当它出现在不同的页面的时侯，我们可以通过页面标示来分辨，而不是每出现一个新的页面就重新定义一个模块标示；

最小细度：埋点定义到模块内的最小元素，可以防止重复上报；

合并上报：相同模块的MV风波可以合并上报；某一页面中一定出现的元素可以不用上报(这儿是指MV爆光风波)，或则和PV时间合并上报，在PV中加一个数组标示即可；

历史兼容：不能改变已有风波标示的含意，不能改变属性标示的含意，不能改变参数值的含意；通常只做新增，不做更改，可以废弃；

追踪回溯：埋点设计文档可以回挪到历史版本，以便排查问题。

流量数据加工

介绍完了埋点信息，接出来重点讲解流量数仓建设和归因建设，首先介绍流量数仓构架。

1.流量数仓模型构架

外卖开发app要多少钱_外卖app开发_外卖开发票包括配送费吗

在整个流量数仓建设过程中还是面对好多挑战的，例如：

整个流量数仓构架如图中所示，与之前惠明老师介绍的基本相同，具体细节可参考原文，这儿稍为讲下：

ODL：DataLayer，操作型数据层，这一层主要对采集到的数据进行无损着陆、基础数组清洗加工。ODL是原始日志明细宽表，完成了日志数据清洗过滤、归因建设、公共维度建设等。全链路归因建设在这一层实现。公共维度建设诸如地理位置维度生成、常用维度代理键生成等，下沉到ODL来进行，减少了运维和下游使用成本，须要依赖于DIM层的环境维度表。

IDL：DataLayer外卖app开发，集成数据层，这一层在ODL之上，主要完成领域数据建模，描述业务对象属性、业务对象间的关系、业务行为属性、业务行为与业务对象的关系等。IDL层是明细宽表层，按照数据域和业务过程进行主题界定，在主题内描述业务对象和业务行为，非常是对主题内常用的扩充维度数组进行提取，而且进一步使用维度退化手段，增强明细宽表的易用性、降低使用成本。比如搜索主题筛选了用户搜索行为相关的日志，并将描述搜索业务的扩充字段进行提取。

CDL：DataLayer，器件数据层，这一层在IDL之上，主要完成剖析实体辨识，在主题界定基础上，产生剖析实体/实体关系特点模型，对模型的指标进行加工，分为明细数据视图和聚合数据表两类。

MDL：MartDataLayer，集市数据层，这一层在CDL之上，构建在主题界定基础上，通过维度层级汇总产生汇总表，通过维度字段关联产生宽表，给数据应用提供便利应用的半成品数据集，比如，常见的店家流量宽表（店家的点击、曝光、进店统计）。

ADL：AppDataLayer，应用数据层，不属于内统一建设，这一层在MDL之上，直接面对数据应用，优先使用MDL的数据，当MDL不满足时，可以向上使用CDL、IDL的数据。ADL作为数据应用的个性化数据通常不对外提供数据服务。

DIM：公共维度层，包括了流量数仓建设过程中使用的流量维表，分成主题维度表和环境维度表。其中主题维度表将埋点标示（用户行为标示）映射成主题维度，是IDL、CDL进行主题界定的核心维度表。环境维度表包括了流量静态属性中常见的维度，比如app名称、启动渠道、设备类型等，主要应用于ODL层的公共维度建设。

2.流量数仓建设原则

在数仓建设中有好多原则，这儿掏出其中三个在流量数仓中比较重要的原则跟你们分享下：

①高内聚和低耦合

将业务相仿或相关、粒度相同、高机率同时访问的数据放到一起。具体在流量数仓建设过程中，合理的主题界定显然就是遵照高内聚低耦合的原则。不合理的主题界定会造成数据使用成本、运维成本减小。主题界定是和业务强相关的事情，须要你们定期自己的主题界定是否合理，一定要紧随业务需求。

②公共处理逻辑下沉且单一

越是底层公用的处理逻辑，越要置于数据底层封装与实现，不要让公共逻辑多处存在且曝露给下层的表。流量底层数据的公共处理逻辑主要是环境维度建设和归因建设。

③成本与性能平衡

适当的进行数据冗余来换取查询和刷新性能，但不要过度冗余与数据复制。这是最浅显易懂的原则，但在流量数仓建设过程中，须要综合考虑各类使用场景，实践上去很难。美团外卖每晚的数据量几百亿条，这样一份数据，假如在多处出现复制，对储存资源就是很大的浪费。成本与性能平衡确实须要多思索，在做数仓规划时就须要把这个事情考虑到。具体实践如下：

3.维度建设

为何常说流量数据在做数仓建设时比业务数据困难，个人认为是由于流量数据的数据源本身是一些半结构化的数据，没有剖析维度的概念，所以在数仓的建设时我们要做好多的维度建设工作。因而维度建设是整个流量数仓工作中最核心工作，同时也是最大的难点。

我们维度建设分为两种，环境维度和主题维度。

环境维度：

环境维度是指用户行为所处的环境描述，比如用户的定位城市、用户的设备类型、用户使用的app名称等，这种维度是在主题界定基础上，剖析实体维度模型中最主要的维度，即用户在选取业务过程后最主要的剖析视角。环境维度建设主要遵循公共处理逻辑下沉且单一这个原则，在ODL完成建设。环境维度建设过程中，假如剖析的维度在日志中早已存在明晰数组，且该数组具有业务含意并是自然字段，这么都会直接使用这个自然键和相对应的维度属性表。假如剖析的维度须要日志中的多个数组联合，这时我们会对这多个数组生成一个代理键，并建立以这个代理键为字段的维度属性表。

举例来说，终端维度须要由日志中的操作系统类型、app名称、启动渠道这三个数组联合生成。如下表所示，我们使用这三个数组生成了一个代理键终端id。非常说明的是，终端id的映射维表并不是简单的可以通过操作系统、app名称、启动渠道这三个数组关联得到。例如，终端id=3的这一行，操作系统数组可以为任意值（对上报日志不做要求）。这就要求我们在生成代理键的时侯须要采取一种愈发灵活的形式，以应对上游数据的不确定性冲击。所以我们使用了UDF来实现：

UDF(操作系统，app名称，启动渠道)=终端id

主题维度：

原始日志在采集上来以后，是不具备业务过程分类的，仅仅能通过埋点标示来做分辨。所以我们须要对日志进行主题界定，也就是业务过程界定。举例来说，我们想晓得一个用户在外卖搜索页的全部行为，我们就须要先找到外卖搜索页的全部埋点标示，之后从原始日志中过滤下来。主题界定就是，将原始日志进行根据埋点标示界定到不同的主题表中。

我们将外卖整体的业务过程根据实体加行为进行具象。外卖业务中，常见的实体包括用户、商家、菜品、订单。实体和实体之间通过行为来联接。例如，用户和店家之间的行为可以有搜索、使用智能助手、使用购物车、点击店家资源位等。

我们将这个埋点标示与主题表中的业务标示建立成主题维度表，用于管理埋点标示与业务标示的关系。在主题维表中，业务标示使用代理键，并在IDL中通过主题维表关联出代理键。主题界定过程中，我们还须要将主题内常用的扩充维度数组进行提取，对于不同的埋点提取这种数组的形式不太一样，我们也将埋点标示与主题扩充维度提取方法的对应关系维护在主题维度表中。

以资源位主题为例讲解一下建设的过程：

业务过程描述：在做主题建设时我们首先要确定业务过程，这儿的业务过程就是从外卖的资源位点击开始，用户在点击以后会步入店家页，之后步入水单页递交订单，最后下单。

业务过程提取：描述清楚业务过程以后，要对业务过程进行提取，即从ODL日志中找出所有浏览和点击的日志，具体做法是：

维度管理：

在维度建设那边，最后再聊下维度管理的事情，从昨晚的内容你们应当也可以感遭到，在流量数仓中维度建设是最核心的内容，它决定流量数仓的剖析视角以及流量数仓的运维成本，在做流量数仓建设时建议认真做下维度管理。

我们是专门做了一个工具来做维度管理。所有维度信息在管理平台统一录入、校验、更新，最后同步到数仓的DIM层，给数仓的生产使用。这样增加了数仓的运维成本。

4.归因建设

归因需求介绍：

外卖app开发_外卖开发app要多少钱_外卖开发票包括配送费吗

后面内容我们讲了数仓整体构架以及维度建设方面内容细节，接出来我们介绍流量数据最核心的、也是你们会时常遇见的归因建设。在流量数据剖析场景中，有一类需求是基于单一埋点或埋点集合的且不须要进行日志关联的剖析，例如某种用户行为的人数、次数等；另一类需求是须要将日志进行关联而且对日志的先后次序有要求的剖析，例如常见的统计经过外卖首页店家列表点击后的成单行为人数、次数。第二类需求似乎就是我们说的流量数据归因。

流量数据归因建设在外卖业务场景下是十分难的，难点有二：数据量大，在几百亿条的日志中，将须要的日志进行关联是十分历时、耗资源的；需求不固定，一般我们难以预知需求方想将什么日志做归因剖析。

为此，流量数据归因建设要重点解决这两个难点问题，非常是难点二，因为需求的不固定，我们要实现全链路的归因建设，而不是只针对个别行为的日志做归因建设。

首先，我们要将需求简化而且标准化，我们将所有的归因统计具象成如下问题描述：

统计经过A行为的B行为的次(人)数

应对这样的问题，给出的伪SQL：

select count(1) from 日志 where 行为 = B and 链路信息 包含 A

经过这样具象后，我们发觉问题显得清晰一些，这个伪SQL就是所有归因剖析场景的标准化查询。问题聚焦在"链路信息"的建设。我们要为每一个用户行为构建一个链路信息数组。

哪些是链路信息呢？在外卖业务场景下，链路信息是：某一行为的时间前序行为集合，集合中不包含相同页面之间的行为。

链路信息建设：

在目标表中，为每一行数据新增一列链路信息，使用链表格式来储存当前行的行为的链路信息。链表中每一个元素即代表一个时间前序行为（排除了MV风波），其中包含的数组会选定一些业务奇特的、与当前行为不同的数组（不包括通用环境数组），这是因为一个行为的时间前序行为中，通用环境数组通常是相同的（例如设备号、操作系统等），且通用环境数组早已作为了分组排序的条件。这样设计表结构的用处是：目标表的行数没有变多；对所有的用户点击行为和用户步入某一页面行为加工了链路信息数组。

可能会有朋友指责这个数组会不会非常长，非常是当用户行为链路非常长的时侯，旁边的行为日志这个数组值会很长。这些场景下我们就须要考虑究竟什么行为应当置于这个数组里，这儿我们使用因果关系来判定那个行为是这行日志的诱因行为。

我们将因果关系定义为为与相同页面之间的事情无关。如上图中风波序列记录某用户从P1点击步入P2再点击步入P3，之后又回到P2接着回到了P1又点击了其它模块。在这段用户行为中P3的链路信息如图中所示彩色部份只包含第一次抵达P3时经过的路径；M5模块的链路信息如图中彩色模块所示，我们觉得图中所示的两个P2之间的链路与M5链路信息无关；M7的链路信息同理。

这样我们屏蔽掉用户操作过程中的回退操作，最终记录的链路信息数组值不会很大，其实这些因果关系一定要契合业务情况。

定义好链路信息和目标表结构以后，我们进行数据加工，链路信息数组使用udf（自定义函数）来加工得到，伪SQL代码如下：

insert into target table select log表中的字段，udf(归因处理输入字段) as 原因行为 from 分组排序后的log表

归因处理输入数组选定了部份通用环境数组和业务主键，通用环境数组拿来判定当前行数据中的环境参数是否发生变化（比如是否换了一个设备），业务主键主要用于udf的输出结果。具体数据处理流程如下：

1.对日志进行分组排序，使用by根据通用环境数组进行分组，使用sortby根据时间戳次序排序，这样保证了相同分组的数据分配到同一个当中进行处理，但是是根据时间戳排序然后进行有序处理；

2.在日志分组排序然后，进行链路信息数组加工，使用hiveudf来实现。在udf中，通过栈来储存链路信息，一次udf执行过程阐述如右图所示：udf输入参数的通用环境数组拿来判定是否更换了设备或app，假如通用参数发生变化，说明上一个分组内的数据全部处理完，清空栈内的数据，把当前行为入栈。假如通用参数没有发生变化，说明一直在处理相同组内的数据。须要判定当前行为的加入是否发生页面回退，倘若发生页面回退，则需按将相同页面之间的行为出栈，最终将当前行为入栈。

3.结果数据输出过程中，会首先进行行为标记，例如将每位页面的最后一次点击行为进行特殊标记，之后再将栈中所有的元素装入链表中，作为最终的链路信息数组。

链路信息数组加工过后，我们要使用这个数组来解决流量归因统计需求。我们回过头来看一下之前提到的流量数据归因建设两个难点。虽然，把问题标准化成统计经过A行为的B行为的次（人）数，而且加工出链路信息数组，就早已解决了上述的两个难点问题：链路信息数组是经过分组排序加工下来的，等同于提早做好了日志关联；对所有的用户点击行为和用户步入某一页面行为都加工了链路信息数组，实现了全链路归因。链路信息数组加工过程是与业务需求前馈的，即不依照业务需求多样化开发，这就促使我们的方案具有很强的灵活性和拓展性。在IDL层可以依照主题的须要取出任何主题所须要的归因数据。

其中，链路信息包含某行为须要通过udf来实现，因而我们开发了一系列的udf、udtf来使用链路信息主键。

后面介绍了在归因建设中我们使用的链路信息追加的方案，可能在业界其他团队使用的是其它的方案，例如撤单，这儿给出不同方案的简单对比：

仔细对比我们会发觉这两种方案是对称的，链路信息追加储存的是当前行为之前发生的行为，撤单储存的是当前行为以后发生的行为。

勾稽关系：

接出来介绍一个流量数据校准方案，勾稽关系校准。勾稽关系在流量数据加工过程中可以很便捷的做监控、校验。例如一个简单场景就是落地页流量要等于来源流量，搜索点击的人数一定是跟搜索页面浏览人数相差不大的。这儿将勾稽关系单独列举，也是希望你们在做流量数仓过程中可以灵活使用它。

5.埋点整治

介绍完数据加工内容以后，我们讲解下数据整治方案，整个的数据整治或则数据资产管理包含好多工作，细节可以参考，这儿简单介绍下埋点整治方案。埋点数据的特征是数据量级很大，因而在做埋点整治时一定要做ROI评估，目前的办法就是做血缘溯源，溯源埋点在ETL任务中的使用情况。

我们将埋点使用情况分成了三类：

将全部使用流量数据的ETL任务标记完以后，我们就可以给每位埋点进行评分，分数较低的埋点会进行有计划的删节和整治，对于分数较高的埋点会进行更好的监控及跟踪。

流量数据应用

最后简单说下外卖流量数据的应用，目前主要有三类：

在OLAP引擎方面外卖app开发，你们都很了解，不做过多介绍，美团外卖对Doris、Kylin、Druid都有使用，对几种OLAP引擎对比以及在美团外卖的使用场景如右图所示：