OpenResty 在马蜂窝广告监测中的应用

点击上方“马蜂窝技术”，关注订阅更多优质内容

广告是互联网变现的重要手段之一。

以马蜂窝旅游 App 为例，当用户打开我们的应用时，有可能会在首屏或是信息流、商品列表中看到推送的广告。如果刚好对广告内容感兴趣，用户就可能会点击广告了解更多信息，进而完成这条广告希望完成的后续操作，如下载广告推荐

的 App 等。

广告监测平台的任务就是持续、准确地收集用户在浏览和点击广告这些事件中携带的信息，包括来源、时间、设备、位置信息等，并进行处理和分析，来为广告主提供付费结算以及评估广告投放效果的依据。

因此，一个可靠、准确的监测服务非常重要。为了更好地保障平台和广告主双方的权益，以及为提升马蜂窝旅游网的广告服务效果提供支撑，我们也在不断地探索适合的解决方案，加强广告监测服务的能力。

Part.1

初期形态

初期我们的广告监测并没有形成完整的服务对外开放，因此实现方式及提供的能力也比较简单，主要分为两部分：一是基于客户端打点，针对事件进行上报；另一部分是针对曝光、点击链接做转码存档，当请求到来后解析跳转。

但是很快，这种方式的弊端就暴露出来，主要体现在以下几个方面：

• 收数的准确性：数据转发需要访问中间件才能完成，增加了多段丢包的机率。在和第三方监测服务进行对比验证时，Gap 差异较大；

• 数据的处理能力：收集的数据来自于各个业务系统，缺乏统一的数据标准，数据的多种属性导致解析起来很复杂，增加了综合数据二次利用的难度；

• 突发流量：当流量瞬时升高，就会遇到 Redis 内存消耗高、服务掉线频繁的问题；

• 部署复杂：随着不同设备、不同广告位的变更，打点趋于复杂，甚至可能会覆盖不到；

• 开发效率：初期的广告监测功能单一，例如对实时性条件的计算查询等都需要额外开发，非常影响效率。

Part.2

基于OpenResty的架构实现

在这样的背景下，我们打造了马蜂窝广告数据监测平台 ADMonitor，希望逐步将其实现成一个稳定、可靠、高可用的广告监测服务。

2.1 设计思路

为了解决老系统中的各种问题，我们引入了新的监测流程。主体流程设计为：

1. 在新的监测服务 (ADMonitor) 上生成关于每种广告独有的监测链接，同时附在原有的客户链接上;

2. 所有从服务端下发的曝光链接和点击链接并行依赖 ADMonitor 提供的服务;

3. 客户端针对曝光行为进行并行请求，点击行为会优先跳转到 ADMonitor，由 ADMonitor 来做二段跳转。