导读美团商品数据采集:本文介绍了美团外卖流量数据采集、流量数仓的建设以及典型的流量数据应用,其中重点介绍了流量数仓建设过程、在建设过程中需要关注的问题以及对应的解决方案。01流量数据采集

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

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

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

到了 2017 年,我们的数据采集使用集团的流量体系,这套体系是客户端日志,主要有下述三个部分:

埋点管理:按照业务通道隔离,埋点统一注册、管理,业务字段管理,需求管理等开发者平台:主要是面向RD,包括:客户端&前端 RD 使用的埋点 SDK 手册,QA 使用的埋点验证工具,数据 RD 使用的埋点数据表、数据服务接口等事件分析工具:主要是一些分析工具提供基本数据分析能力,可以支持事件和页面的埋点数据分析

下面简单介绍下埋点在技术上的分类,一般埋点分为前端埋点和后端埋点两种。

前端埋点:

将采集的 SDK 集成在终端上,主要有三种:代码埋点美团商品数据采集;可视化埋点美团商品数据采集;无埋点。美团使用的是代码埋点,它比较明显的优点是:

高度定制、控制精准、采集的数据丰富准确比较方便、灵活,能方便手机到用户在界面上的行为数据

可视化埋点和无埋点原理差不多,PM和运营同学可以在管理平台配置需要的埋点,然后SDK定时检测识别埋点的的控件,获取埋点数据。相比而言可视化埋点实施成本很低,但是埋点质量上我们觉得代码埋点远高于可视化埋点,如果场景简单或者业务处在初期阶段,建议使用可视化埋点或者无埋点这种成本较低的方案美团商品数据采集;如果业务比较复杂,公司研发规模比较大,而且对数据建设有比较高的要求,代码埋点是最好的选择。目前业界内,神策数据这几种方案都支持,GrowingIO主要是支持无埋点。

后端埋点:

现在很少单独使用,基本是和前端埋点搭配使用。它的优点是内网传输,即时性强,丢失风险小 。

2. 埋点信息与事件介


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

环境信息:环境信息包括一些常见的地理、设备信息,应用的信息,还有 SDK、事件生产信息等。业务信息:业务信息主要是和当前用户行为有直接关系,比如说:操作的模块中业务字段,用户操作的页面的信息,还有唤起的信息等。


美团商品数据采集_采集美团商家数据采集大师 第1张



埋点事件分类主要分为三大类:

PV:页面事件或者叫做页面曝光事件,就是当用户打开美团 APP,每次进入一个页面的时候,就会立即上报一条页面的 PV 日志,每个页面都有自己的唯一标识 page_idMC:模块点击事件。点击比较好理解,就是用户每次点击都立即上报一条 MC 日志,每个模块都有唯一标识MV:模块曝光事件。曝光指用户浏览某个模块,就是用户看到某模块就会上报一条日志,在 APP 页面上,某个模块只要显示(只有一个像素出现在屏幕上)就会上报一条日志,同样每条 MV 日志都会记录模块的唯一标识

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

在 APP 页面的顶部,我们用绿色框圈中的部分是一个 banner,上报这个 banner 日志的时候会携带 page_id ,和首页 pv 日志的 page_id 值相同,上报曝光、点击日志的时候都会有一个自己的唯一标识。中间是频道区,同上面的 banner 一样上报时都会携带 page_id,每次点击都会上报模块唯一标识 click_id,这 15 个频道会分别上报15条曝光日志,它们的 page_id、view_id 相同,通过位置字段(从 0 位到 14 位)来区分。再下面这个的 banner 位置日志上报规则同顶部 banner 相同。

在这样的事件分类下,我们把一个用户行为按照时间排序得到图中右下角所示的序列:用户首先进入一个页面上报PV日志,会看到很多模块上报MV日志,然后点击某个模块上报MC日志,接着发生跳转跳到新的页面,然后接着浏览、点击、跳转、浏览 ......

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

3. 埋点规范与协作流程


美团商品数据采集_采集美团商家数据采集大师 第2张



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

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

埋点规范:主要是约束一些字段的上报方法,包括字段名称、上报时机等。

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

埋点 SLA:我们专门制定了一套埋点 SLA ( Service Level Agreement - 服务级别协议 ) 机制,目前这块主要由客户端 RD 和 QA 来保证 SLA,业务 PM 根据埋点重要性提供需要保证的 SLA 列表,数据组提供监控工具。


美团商品数据采集_采集美团商家数据采集大师 第3张



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

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

4. 埋点注意事项


美团商品数据采集_采集美团商家数据采集大师 第4张



前面介绍了埋点的基本信息与规范流程,这里给大家介绍一些埋点的注意事项。个人觉得做埋点还是非常需要经验的,甚至是需要更多的试错,这里给大家列了一些注意事项以供参考:

同质参数的名称和类型保持一致:主要就是体现在通用参数、业务参数、行为标识的统一,尽量做到事前治理,给整个的数据加工、数仓建设减轻工作量,当然在数仓加工过程中也一定要做一些容错;

通用复用:尽量少的创建新的事件,而是想办法复用原来的事件,方便后续的埋点管理;比如某弹窗在很多页面都出现过,弹窗模块曝光标识需要是唯一的,当它出现在不同的页面的时候,我们可以通过页面标识 page_id 来区分,而不是每出现一个新的页面就重新定义一个模块标识;

最小粒度:埋点定义到模块内的最小元素,可以避免重复上报;

合并上报:相同模块的 MV 事件可以合并上报;某一页面中一定出现的元素可以不用上报 ( 这里是指 MV 曝光事件 ),或者和 PV 时间合并上报,在 PV 中加一个字段标识即可;

历史兼容:不能改变已有事件标识的含义,不能改变属性标识的含义,不能改变参数值的含义;一般只做新增,不做修改,可以废弃;

追踪回溯:埋点设计文档可以回退到历史版本,便于排查问题。

02流量数据加工

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

1. 流量数仓模型架构


美团商品数据采集_采集美团商家数据采集大师 第5张