Adtributor: Revenue Debugging in Advertising Systems 微软论文翻译

前言

毕设在做异常点检测与根因分析,就拿微软14年的文章作为主要参考文献了,这里把中文的翻译以及一些整理一起放在博客里,以作分享交流。

Adtributor: 广告系统中的收入调试

作者:Ranjita Bhagwan, Rahul Kumar, Ramachandran Ramjee, George Varghese, Surjyakanta Mohapatra, Hemanth Manoharan, and Piyush Shah Microsoft

原文地址:https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-bhagwan.pdf

名词对应

revenue debugging:收入调试

measure:指标

surprise:惊奇性

摘要

广告收入在支持免费网站方面起着至关重要的作用。当收入急剧下降或增加时,广告系统运营商必须找到并解决根本原因,例如通过优化基础设施的性能。这种收入调试类似于系统的文献中的诊断和根因分析,但更为普遍。基础设施元素的故障只是一个潜在的原因;其他一系列的因素(如广告商、设备类型)都可能是潜在的原因来源。此外,问题还因衍生的指标而变得复杂,如每次点击的成本,这些成本也与收入一起被追踪。
我们的论文首次系统地研究了收入调试问题。利用解释力、简洁性和惊奇性的概念,我们为广告系统的基本和衍生指标提出了一个新的多维根源算法,以确定最可能受到指责的部分。此外,我们在一个名为Adtributor的工具中实现了归因算法和可视化界面,以帮助故障排除者快速识别潜在的原因。基于对一个非常大的广告系统的几个案例研究和广泛的评估,我们证明了Adtributor的准确率超过95%,并可以帮助将系统故障排除时间减少一个数量级。

1 介绍

今天,许多免费网站都是通过广告(adds)产生的收入来支持的。网站广告有两种类型,搜索和展示。在搜索广告的情况下,终端用户进入一个发布者网站,如bing.com,并输入一个查询短语。对查询的回应是一个搜索结果页面,其中可能包含一个或多个广告。如果用户点击其中一个广告,出版商就能获得收入。在显示广告的情况下,最终用户可能会访问一个出版商的网站,如cnn.com,她可能会在页面的顶部或两侧看到广告,这些广告的展示为出版商赚取了收入。

广告系统促进了每天数以百万计的此类搜索和展示广告的产生和核算。除了上面提到的用户和出版商之外,还有两个与广告系统互动的关键成员,分别为广告商和欺诈经营者。显示给用户的广告是各个广告商之间的广告拍卖的结果,这些广告商通过投标来竞争将其广告显示给用户。在这中间,还有各种欺诈经营者[8],他们试图侵占广告收入的一部分。

广告系统管理着用户、出版商、广告商和欺诈经营者之间的互动。广告系统实施各种与广告有关的算法,在广告商之间进行实时的广告拍卖,将获胜的广告返回给出版商,监控用户的点击,检测和清除潜在的欺诈活动,计算每个显示或点击的广告的收入,向广告商收取适当的投标金额,并向出版商付款。广告系统的核心是一个大规模的分布式系统,由分布在几个数据中心的数千台服务器组成,执行广告算法并管理广告的服务和核算。

本文的重点是对广告系统的调试。通常情况下,广告系统监控器会在某一关注指标被确认为异常时发出警报(例如,收入或搜索次数急剧下降)。我们的目标是自动识别这种异常现象的潜在根源。我们称我们的方法为收入调试,尽管它适用于广告系统运营商的几个衡量标准,以承认收入指标的重要性。在本文中,我们描述了一种新的收入调试算法,该算法可以分析广告系统记录的大量数据,并将异常的潜在根源范围缩小到广告系统的一个子组件,以便由故障排除人员进一步调查。

根源识别和诊断是系统中一个古老的问题。过去已经提出了各种根因分析工具[1, 2, 3, 10, 14, 15]。但所有这些解决方案都集中在性能/故障调试上。在这里,我们解决一个类似但更普遍的问题:广告系统的诊断。虽然基础设施系统组件的性能/故障可能是异常指标的一个根本原因,但可能还有其他各种根本原因,例如与广告系统互动的其他组件。考虑到以下的例子:

  1. 教皇选举。我们注意到,教皇选举导致收入下降,因为许多搜索都是针对非货币化的查询词,如教皇或教皇选举,而广告商通常不会为其出价。显示的广告总数下降会导致收入的异常下降。虽然确定教皇选举的根本原因是不可操作的,但根本原因的识别仍然很重要,因为它消除了一个可操作的根本原因,如下面的例子。
  2. 浏览器广告失败。我们发现收入下降可能是由更新配置文件时的人工错误造成的,该文件的副作用是在某些浏览器版本上不显示广告。在这种情况下,快速识别可以帮助更正配置错误,从而恢复广告收入。表1中描述了更多的例子,并在第2.1节中讨论。

广告系统调试的第一个挑战是庞大的数据规模。每天有数以亿计的搜索和点击;在一个搜索或一个点击的层面上进行诊断是不可扩展的(想象一下,运行Mag- pie[3]或通过每一次点击会需要数百个系统组件跟踪一串系统调用)。因此,由于可扩展性的原因,广告系统调试是通过各种指标的集合来进行的。这些指标通常是在某些时间间隔内聚集的计数器(例如,在过去1小时内产生的收入)。根源识别只能由这些聚合计数器的异常行为触发。

与典型的系统故障排除相比,广告系统的第二个显著特点是出现了多个维度,需要首先对解释异常的维度进行等效。诸如收入等指标可以沿着不同的维度进行分解或预测,如广告商、浏览器或数据中心。例如,在例2中,如果收入是按照浏览器的维度来预测的,我们可以观察到一些浏览器版本没有产生其 "典型 "的收入份额。然而,如果同样的收入是按照广告商的维度来划分的,也许收入的分布就不会有明显的变化。

典型的系统根源算法,如SCORE[11],使用简洁性(奥卡姆剃刀)和解释力(根因能否解释变化?)作为他们的主要优化参数,不必考虑多个维度。为了对异常维度进行等效处理,我们引入了惊奇性的概念,通过量化每个维度上测量值的分布变化来体现。例如,在例2中,沿浏览器维度的收入分布的变化比沿广告商维度的收入分布的变化更令人惊讶。因此,我们在本文中的第一个贡献是第3节中描述的根因分析算法,该算法除了使用简洁性和解释力之外,还使用了惊奇性来识别广告系统中异常产生的根本原因。

广告系统的第三个独特特征是衍生指标的普遍性。考虑两个基本的衡量标准:每小时收入和每小时点击数。从这两个衡量标准中,我们可以定义一个衍生的衡量标准,即每点击成本,它只是收入除以点击次数。广告系统运营商监控和跟踪许多这样的衍生指标,它们是各种基本指标的函数(见图1)。例如,点击次数的变化和收入的变化本身可能很小,并不异常(例如,小于10%)。然而,相关的变化(例如,收入下降,同时点击量增加,各占10%)是异常的,并被派生的每次点击成本指标所捕获(20%的变化)。正如我们在第4节中所讨论的,将根本原因归因于衍生指标是具有挑战性的。为了解决这个问题,我们提出了一个新颖的部分衍生指标的归因解决方案,这是我们在本文中的第二个贡献。

我们的根本原因识别算法的结果是一组有可能解释异常现象的候选者。然而,这只是诊断过程中的第一步,如果合适的话,故障排除人员可以采取行动来解决这个问题。为了帮助故障排除人员快速识别潜在的根本原因,我们在一个叫做Adtributor的工具中实施了我们的根本原因识别算法和图形化的可视化工具,这是我们在本文中的第三个贡献。通过在生产系统中试点部署的经验,我们改进了Adtributor的可视化界面和数据表示技术,以进一步减少故障排除者的周转时间。

最后,我们对我们的根本原因算法进行了广泛的评估。首先,我们以表格形式列出并讨论了一组具有代表性的案例研究,这些案例研究强调了我们的根因分析工具的价值。其次,我们对2周内真实广告系统数据的128个异常警报进行了评估,发现我们的算法达到了95%以上的准确率。事实上,Adtributor甚至发现了一些被人工搜索遗漏的异常现象的根本原因。此外,该工具还将故障排除过程的速度提高了一个数量级。

2 问题陈述

在提供了系统概述之后,这一节中我们展示了真实问题的例子和它们的根本原因。接下来,我们将更准确地说明问题,并阐述我们的解决方案。

2.1 系统概述

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AfgpIu7E-1622188259069)(/Users/lizhihan/Library/Application Support/typora-user-images/image-20210528130930842.png)]

图1显示了一个广告系统,并展示了诸如用户、欺诈操作者、出版商和广告商等直接与广告系统互动的实体。广告系统本身有不同的子组件,我们展示了其中的一些。

虽然日志基础设施确实跟踪了每个搜索请求或广告点击,但由于规模庞大,很难在单个请求层面上跟踪问题。取而代之的是,该系统监测一套综合指标,如图1所示。从原始日志中,它首先计算出每个时间间隔内收到的总搜索量、显示的总广告量、收到的总广告点击量以及这些点击量的总收入。这些指标都是相加的,并且可以沿着不同的维度进行切分。例如,总收入是使用该系统的每个广告商的收入之和。总收入也是来自广告系统活跃的不同地理区域的收入之和。我们称这种加法指标为基本指标。

此外,该系统还监测一组非加法派生指标,这些指标是基本指标的函数,如每搜索广告(广告/搜索)、每广告点击(点击/广告)、每点击成本(收入/点击)和每搜索收入(收入/搜索)。

这些指标中的任何一项出现异常的上升或下降,都表明这个指标出现了问题。因此,诊断系统需要首先检测出异常情况,然后进行根本原因分析。在本文中,我们专注于后期的根本原因分析,同时依靠著名的基于ARMA模型的方法[4]进行异常检测。异常检测器根据8周的历史数据生成

  • 1
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值