美团点评前端无痕埋点实践

标签: 美团 前端 实践 | 发表时间:2017-03-02 19:08 | 作者:美团点评技术团队
出处:http://tech.meituan.com/

构建一个数据平台大体上包括数据采集、数据上报、数据存储、数据计算,以及数据的可视化展示等几个重要的环节。前端数据采集与上报是整个流程中最重要的一环,只有确保前端数据生产的全面、准确、及时,最终产生的数据结果才是可靠的、有价值的。

为了解决前端埋点的准确性、及时性、开发效率等问题,业内各家公司从不同角度,提出了多种技术方案,这些方案大体上可以归为三类:第一类是代码埋点,即在需要埋点的节点调用接口直接上传埋点数据,友盟、百度统计等第三方数据统计服务商大都采用这种方案;第二类是可视化埋点,即通过可视化工具配置采集节点,在前端自动解析配置并上报埋点数据,从而实现所谓的“无痕埋点”, 代表方案是已经开源的Mixpanel;第三类是“无埋点”,它并不是真正的不需要埋点,而是前端自动采集全部事件并上报埋点数据,在后端数据计算时过滤出有用数据,代表方案是国内的GrowingIO。

美团点评对于前端埋点的要求很高,总结起来主要有三点需求:第一是数据的准确性和及时性,数据质量的好坏将直接影响依赖埋点数据的后端策略服务、与合作伙伴结算、以及运营数据报表等等。第二是埋点的效率,埋点的复杂度往往与业务需求相关,埋点效率会影响版本迭代的速度。第三是动态部署与修复埋点的能力,本质上这也是提升埋点效率的一种手段,并且使埋点不再依赖于客户端发版。

公司原有埋点主要采用手动代码埋点的方案,代码埋点虽然使用起来灵活,但是开发成本较高,并且一旦上线就很难修改。如果发生严重的数据问题,我们只能通过发热修复解决。如果直接改进为可视化埋点,开发成本较高,并且也不能解决所有埋点需求;改进为无埋点的话,带来的流量消耗和数据计算成本也是业务不能接受的。因此,我们在原有代码埋点方案的基础上,演化出了一套轻量的、声明式的前端埋点方案,并且在动态埋点、无痕埋点等方向做了进一步的探索和实践。

代码埋点

由于后面要介绍的声明式埋点和无痕埋点方案仍然依赖原有代码埋点的底层逻辑,这里有必要简单介绍下代码埋点。在实现代码埋点时,我们主要关注的是数据结构的规范性、埋点接口的易用性、上报策略的可靠性等问题。整体的模块划分如下图所示,这里就不再详述。

开发者需要手动在需要埋点的节点处(例如:点击事件的回调方法、列表元素的展示回调方法、页面的生命周期函数等等)插入这些埋点代码。

  EventInfo eventInfo = new EventInfo();
eventInfo.nm = EventName.MGE;            // 事件类型为MGE
eventInfo.val_bid = "xxx";                // 事件的唯一标标识
eventInfo.val_lab = new HashMap<>();    // 携带的业务数据
eventInfo.val_lab.put(Constants.Business.xx,"xxx");
Statistics.getChannel("hotel").writeEvent(eventInfo);

可以看出,代码埋点是一种典型的命令式编程,因此埋点代码常常要侵入具体的业务逻辑,这使埋点代码变得很繁琐并且容易出错。因此,最直接的做法就是将埋点代码与业务逻辑解耦,也就是“声明式编程”,从而降低埋点的难度。

声明式埋点

声明式埋点的思路是将埋点代码和具体的交互和业务逻辑解耦,开发者只用关心需要埋点的控件,并且为这些控件声明需要的埋点数据即可,从而减轻开发者埋点的成本。

Android

在Android中,我们自定义了常用的UI控件,例如TextView、LinearLayout、ListView、ViewPager等,重写了事件响应方法,在这些方法内部自动填写埋点代码。重写控件的好处在于可以拦截到更多的事件,执行效率高并且运行稳定。但其弊端也非常明显——移植成本很高!

为了解决这个问题,我们借鉴了Android support v7库的思路,即通过AppCompatDelegate代理自动替换UI控件。

  public class GAAppCompatDelegateV14 extends AppCompatDelegateImplV14 {
    @Override
    View callActivityOnCreateView(View parent, String name, Context context, AttributeSet attrs) {
        switch (name) {
            case "TextView":
                return new NovaTextView(context, attrs);
        }
        return super.callActivityOnCreateView(parent, name, context, attrs);
    }
}

这样,开发者只需要在自己的Activity基类中重写getDelegate方法,将方法的返回值替换为修改过的AppCompatDelegate,就可以实现自动替换UI控件了。

  @Override
public AppCompatDelegate getDelegate() {
    if (mDelegate == null) {
        mDelegate = GAAppCompatUtil.create(this, this);
    }
    return mDelegate;
}

然而,新的问题又出现了。

如果引用的第三方库中重写了UI控件,上述方法是不生效的,也就是说我们需要一种替换UI控件类的父类方法。可是在运行时,我们没有找到可行的替换UI控件类的父类方法。因此,我们尝试在编译时修改父类,并开发了一个gradle插件。事实上,这样做并不存在运行时效率的问题,只是会牺牲一些编译速度。这样开发者只需要运行这个插件,就可以实现自动将UI控件的父类替换为我们重写的UI控件了。

  apply plugin: 'com.meituan.judasplugin'

采用了声明式埋点后,只需要在控件初始化时声明一下需要的埋点就可以了。我们不必再侵入程序的各种响应函数,降低了埋点的难度。

  GAHelper.bindClick(view, bid, lab);

iOS

在iOS中,利用Objective-C关联属性和类别的语法特性,我们无需重写UI控件,就能实现声明式打点。对于UIControl,可以在声明埋点时添加新的action,并在事件发生时自动填写埋点代码。

  - (void)nvja_setAnalyticsParams:(NVJAMGEParameter *)params mgeType:(SAKStatisticsEventMGEType)type
{
    if (self.wmja_clickParams == nil && type == SAKStatisticsEventClick) {
        [self addTarget:self action:@selector(wmja_controlDidTapped:) forControlEvents:UIControlEventTouchUpInside];
    }
    [super nvja_setAnalyticsParams:params mgeType:type];
}

对于UITableView,可以通过重写UITableViewDelegate,利用消息传递机制拦截事件,并在事件回调方法中自动填写埋点代码。

  - (void)forwardInvocation:(NSInvocation *)anInvocation
{
    SEL selector = [anInvocation selector];
    if (self.originalDelegate && [self.originalDelegate respondsToSelector:selector]) {
        [anInvocation invokeWithTarget:self.originalDelegate];
    }
    SEL nvjaSelector = [self nvjaSelector:selector];
    if ([super respondsToSelector:nvjaSelector]) {
        [anInvocation setSelector:nvjaSelector];
        [anInvocation invokeWithTarget:self];
    }
}

同样的,采用了声明式埋点后,埋点代码得到了简化。

  NVJAMGEParameter *parameter = [[NVJAMGEParameter alloc] init];
parameter.bid = @"bid";
parameter.lab = @{@"poi_id":@"1"};
button.nvja_clickParams = parameter;

声明式埋点能够替代所有的代码埋点,并且能解决早期遇到的移植成本高等问题。但是其本质上还是一种代码埋点,只是埋点的代码减少了,并且不再侵入业务逻辑了。如果要满足动态部署与修复埋点的需求,就需要彻底消灭写死在前端的埋点代码。

无痕埋点

我们注意到,之所以声明式埋点还需要写死代码,主要有两个原因:第一是需要声明埋点控件的唯一事件标识,即bid;第二是有的业务字段需要在前端埋点时携带,而这些字段是在运行时才可获知的值。

对于第一点,我们可以尝试在前后端使用一致的规则自动生成事件标识,这样后端就可以配置前端的埋点行为,从而做到自动化埋点。对于第二点,可以尝试通过某种方式将业务数据自动与埋点数据关联,这种关联可以发生在前端,也可以发生在后端。

事件标识

为了自动生成事件标识,我们需要获取每个控件自身的ID、类名以及位于所属父组件的Index等特征信息,并逐级向上遍历找到根节点。根节点一般是手动标记的,如果没有标记则默认是视图层次树的顶层节点。最后,将遍历产生的路径上所有节点的特征信息组合在一起,就是这个事件的标识。考虑到在实际布局中有可能存在一些动态插入的控件,我们允许父组件的Index有一定的误差。

配置后台需要维护自动生成的事件标识和bid的映射关系,并且可以下发给前端一个配置文件。当前端控件事件触发时,自动和配置文件匹配就可以拿到对应的bid了。需要注意的是,配置后台维护事件标识的工作可不是一件轻松的事情,主要的复杂性在于不同版本之间布局变更导致的事件标识变更,这就是为什么还需要手动标记根节点的原因。所以,一般我们会选取不易变更的视图节点。

数据关联

为了实现业务数据与埋点数据的自动关联,我们起初尝试了前后端日志关联的方式。即在前端请求后端API的时机,由后端将业务数据写入日志,最后在数据清洗时将相对应的前后端日志合并。这种方式带来的问题是后端改造成本较高,并且数据清洗的开销较大,因此并不能广泛应用。但是在一些特殊场景下,例如某些业务数据只有后端可以获知,而前端不能获知时,这种关联是必要的。

更常见的数据关联发生在前端数据之间。当页面跳转时,通过传递规范的跳转Uri Scheme,将业务数据传递给下个页面,并且自动填入这个页面的PV事件中。而该页面内产生的所有其他事件,都会携带与PV事件相同的业务数据。

这样,通过自动产生事件标识并进行数据关联,我们就能够实现“无痕埋点”了,并且埋点节点可以通过配置文件动态下发,从而具备了动态部署与修复埋点的能力。但需要注意的是,这种“无痕埋点”并不能解决所有问题,当业务字段无法通过数据关联获取时(这种情况比较常见),仍然需要开发者代码埋点或声明式埋点指定业务字段。就目前实践阶段的数据来看,业务中大约70%左右的埋点需求可以通过无痕埋点解决,而对于另外30%的埋点需求,仍然需要使用声明式埋点和代码埋点。

总结

前端数据采集与上报是构建数据平台过程中最重要的环节,美团点评前端每天上报的数据达到百亿次级别。为了更好的满足公司各业务日益复杂的埋点需求,以及对埋点准确性、及时性、开发效率的要求,我们在代码埋点方案的基础上演化出了一套轻量的、声明式的前端埋点方案,并且在动态埋点、无痕埋点等方向做了进一步的探索和实践。目前声明式埋点已经在部分业务上全量使用,从数据质量和开发者反馈来看,取得了预期的收益。而无痕埋点也正在一些业务上验证和持续优化中,后面也会在公司范围内进一步推广。

在实践中我们认识到,埋点问题不能通过单一一种技术方案来解决,在不同场景下我们需要选择不同的埋点方案。例如对于简单的用户行为类事件,可以使用无痕埋点解决;而对于需要携带大量运行时才可获知的业务字段的埋点需求,就需要声明式埋点来解决。从更高的层面来看,除了前端埋点技术的优化,埋点数据的规范化、前后端协同埋点、数据清洗和关联对于未来构建更加自动化、动态化的埋点体系同样非常重要。

相关 [美团 前端 实践] 推荐:

美团点评前端无痕埋点实践

- - 美团点评技术团队
构建一个数据平台大体上包括数据采集、数据上报、数据存储、数据计算,以及数据的可视化展示等几个重要的环节. 前端数据采集与上报是整个流程中最重要的一环,只有确保前端数据生产的全面、准确、及时,最终产生的数据结果才是可靠的、有价值的. 美团点评对于前端埋点的要求很高,总结起来主要有三点需求:第一是数据的准确性和及时性,数据质量的好坏将直接影响依赖埋点数据的后端策略服务、与合作伙伴结算、以及运营数据报表等等.

Spark在美团的实践

- - 美团点评技术团队
本文已发表在《程序员》杂志2016年4月期. 美团是数据驱动的互联网服务,用户每天在美团上的点击、浏览、下单支付行为都会产生海量的日志,这些日志数据将被汇总处理、分析、挖掘与学习,为美团的各种推荐、搜索系统甚至公司战略目标制定提供数据支持. 大数据处理渗透到了美团各业务线的各种应用场景,选择合适、高效的数据处理引擎能够大大提高数据生产的效率,进而间接或直接提升相关团队的工作效率.

美团前端架构简介

- - 潘魏增
受 一鸣师哥之邀,今天下午去他公司介绍了美团前端架构,顺便和可爱的工程师们交流一下,同行的还有同事 弥城. 根据师哥要求,除了讲前端的部分,还介绍了一些美团的开发流程以及前后端协作开发的两种方式. 分享的内容粗枝大叶,要做的事情还有很多,这里整理一下演示文稿,希望对感兴趣的朋友有用.

Web前端优化最佳实践

- Jimmy - 中文热文榜|最新
还有 Jason, Bixuan, 曦, 推荐,查看全部 8 个推荐. 博评 - Sting的网经发表于2010-08-08 08:41:10. Google的前端优化最佳实践 Yahoo的前端优化最佳实践. Web前端优化最佳实践之Content篇. 尽量减少 HTTP 请求 (Make Fewer HTTP Requests).

前端性能优化最佳实践

- - Web前端 - ITeye博客
如今浏览器能够实现的特性越来越多,并且网络逐渐向移动设备转移,使我们的前端代码更加紧凑,如何优化,就变得越来越重要了. 开发人员普遍会将他们的代码习惯优先于用户体验. 但是很多很小的改变可以让用户体验有个飞跃提升,所以任何一点儿小小的优化都会提升你网站的性能. 前端给力的地方是可以有许多种简单的策略和代码习惯让我们可以保证最理想的前端性能.

前端组件化开发实践

- - 美团技术团队
随着前端开发复杂度的日益提升,组件化开发应运而生,并随着 FIS、React 等优秀框架的出现遍地开花. 这一过程同样发生在美团,面临业务规模的快速发展和工程师团队的不断扩张,我们历经引入组件化解决资源整合问题、逐步增强组件功能促进开发效率、重新打造新一代组件化方案适应全栈开发和共享共建等阶段,努力“controlling complexity”.

Puppeteer前端自动化测试实践

- - SegmentFault 最新的文章
本篇内容将记录并介绍使用Puppeteer进行自动化网页测试,并依靠约定来避免反复修改测试用例的方案. 主要解决页面众多时,修改代码导致的牵连错误无法被发现的运行时问题. 目前我们在持续开发着一个几十个页面,十万+行代码的项目,随着产品的更迭,总会出现这样的问题. 在对某些业务逻辑或者功能进行添加或者修改的时候(尤其是通用逻辑),这些通用的逻辑或者组件往往会牵扯到一些其他地方的问题.

美团推荐算法实践

- - 美团技术团队
推荐系统并不是新鲜的事物,在很久之前就存在,但是推荐系统真正进入人们的视野,并且作为一个重要的模块存在于各个互联网公司,还是近几年的事情. 随着互联网的深入发展,越来越多的信息在互联网上传播,产生了严重的信息过载. 如果不采用一定的手段,用户很难从如此多的信息流中找到对自己有价值的信息. 解决信息过载有几种手段:一种是搜索,当用户有了明确的信息需求意图后,将意图转换为几个简短的词或者短语的组合(即query),然后将这些词或短语组合提交到相应的搜索引擎,再由搜索引擎在海量的信息库中检索出与query相关的信息返回给用户;另外一种是推荐,很多时候用户的意图并不是很明确,或者很难用清晰的语义表达,有时甚至连用户自己都不清楚自己的需求,这种情况下搜索就显得捉襟见肘了.

美团App 插件化实践

- - 美团点评技术团队
在Android开发行业里,插件化已经不是一门新鲜的技术了,在稍大的平台型App上早已是标配. 进入2017年,Atlas、Replugin、VirtualAPK相继开源,标志着插件化技术进入了成熟阶段. 但纵观各大插件框架,都是基于自身App的业务来开发的,目标或多或少都有区别,所以很难有一个插件框架能一统江湖解决所有问题.

美团 HTTP 服务治理实践

- - IT瘾-dev
2019 年 7 月 6 日,OpenResty 社区联合又拍云,举办 OpenResty × Open Talk 全国巡回沙龙·上海站,美团基础架构部技术专家张志桐在活动上做了《美团 HTTP 服务治理实践》的分享. OpenResty x Open Talk 全国巡回沙龙是由 OpenResty 社区、又拍云发起,邀请业内资深的 OpenResty 技术专家,分享 OpenResty 实战经验,增进 OpenResty 使用者的交流与学习,推动 OpenResty 开源项目的发展.