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

为了解决前端埋点的准确性、及时性、开发效率等问题，业内各家公司从不同角度，提出了多种技术方案，这些方案大体上可以归为三类：

1. 第一类是代码埋点，即在需要埋点的节点调用接口直接上传埋点数据，友盟、百度统计等第三方数据统计服务商大都采用这种方案；

2. 第二类是可视化埋点，即通过可视化工具配置采集节点，在前端自动解析配置并上报埋点数据，从而实现所谓的“无痕埋点”， 代表方案是已经开源的Mixpanel；

3. 第三类是“无埋点”，它并不是真正的不需要埋点，而是前端自动采集全部事件并上报埋点数据，在后端数据计算时过滤出有用数据，代表方案是国内的GrowingIO。

美团点评对于前端埋点的要求很高，总结起来主要有三点需求：

1. 数据的准确性和及时性，数据质量的好坏将直接影响依赖埋点数据的后端策略服务、与合作伙伴结算、以及运营数据报表等等。

2. 埋点的效率，埋点的复杂度往往与业务需求相关，埋点效率会影响版本迭代的速度。

3. 动态部署与修复埋点的能力，本质上这也是提升埋点效率的一种手段，并且使埋点不再依赖于客户端发版。

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

代码埋点

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

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

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 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%的埋点需求，仍然需要使用声明式埋点和代码埋点。

总结

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

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