移动广告作弊现形：三组实例的探讨与解决方案

在先前的文章中，我们探究了广告作弊的理论知识，以及 Adjust 采取行动之前是如何分析、归纳作弊问题的逻辑。

然而，我们还没有明确讨论究竟该如何在现实中运用这些理论知识，又能从这些理论中提炼出什么样的解决方案？

在本文中，我们将探讨实际生活中可能面临的三种广告作弊手法，以及该如何运用理论模型来对症下药。

点击劫持(Click Injection)

当人们观察到点击次数与归因的安装数量异常接近时，点击劫持开始成为业界关注的问题。

在数据可视化的早期，人们注意到当点击欺诈发生，在“点击到安装时间”( Click-To-Install-Time, CTIT)的图表中活动会出现显著的升高。这样的异象让研究人员心生警惕，怀疑数据集中是否可能存在有“欺诈归因”（Sproofed Attributions）。当时人们还不知道这些点击究竟是如何产生，也不知道它们从何而来。

这时有业内人士提出了想法：何不在类型检测中创建过滤器，拦截那些不可能的“点击到安装时间”？也就是说，利用过滤器拒绝所有点击后几秒钟内所产生的安装。

这个方案在运用上很容易，但遗憾的是，并不能解决所有问题。

Adjust 就此深度挖掘，逆向分析，发展了更加简明易懂的过滤系统。我们在研究中发现了，作弊者在安卓系统中生成“劫持点击”（Click Injection）的运作模式。这个模式的根本作法是，当某应用所在设备收到来自其他应用的安装通知时，作弊者会盗用这些来自其它应用的安装。

这个发现让我们辨识出了更有效的时间戳，也就是在首次打开应用时便开始进行过滤。与其只在用户安装后的弹指间进行过滤“点击劫持”，我们创建了一种可以拦截多达 5 倍的归因数量的方法。这项进一步的研究也促成了我们与 Google 的联合项目，方便我们能够使用明确判定是/非过滤时间戳，也就是点击“下载”按钮的时刻来进行过滤。

在我们看来，当前市场的策略（设置任意独断、强制性的“点击到安装时间”长度）只能治标却不能治本，是试图在不处理造成作弊实际原因的情况下阻止作弊。我们不倾向使用业界采用的单向策略，而要采用更加深入的方法来应对。

点击欺诈(Click Spamming)

当前最常见的移动广告作弊手法之一，是通过大量的点击来获取随机用户归因，以欺诈类似 Adjust 这样的归因供应商。

作弊者可以随机匹配从广告交换和其他推广渠道所获取的设备 ID，又或者随机匹配合法安装的指纹。由于 iOS 设备之间的差异极小，因此指纹匹配容易遭到不肖人士利用。此外，要使市场内可用的 IP 地址（唯一的另一种独特归因）饱和用尽亦非难事。

点击欺诈的形式多变，包括堆叠广告、在设备上进行后台点击，或直接服务器到服务器的点击目录等等。较温和的手法则有以点击方式发送视图，或者所谓的“预缓存”，也就是在广告显示之前点击它们。但归根结底，这些形式都具有一个相同的特征：用户实际上并没有打算与广告进行互动，也没有兴趣下载显示的应用程序。

过滤这些“欺诈归因”的主要困难在于，点击本身并不容易被辨识。欺诈者可以控制任何参数，并且可以轻易地调整请求，让这些请求看起来像真正的广告交互。

正如先前于作弊理论系列所讨论，有效的过滤器应该根基于不受攻击者影响的逻辑事实所建立。庆幸的是，仍有一项变因是攻击者本质上无法控制的，即是：用户实际安装应用程序的时间。

当我们对比欺诈点击与真实点击时，我们也发现：如果是真实点击，用户被转至应用商店的时间与第一次实际打开应用的时间之间存在很强的关联。用户通常在一个小时内会打开应用，平均 80% 都发生在这一时间段内。然而如果是欺诈点击，我们看不到这种关联性，打开应用的用户会随机分布在归因窗口中。

通过过滤器，我们不仅要查看推广活动分类所产生的统计数据分布，同时要查看点击是否能展示与应用安装的关联性。相对地，如果我们使用的欺诈检测工具把劫持点击和欺诈点击放在同一图表中显示，还让用户自行决定哪些是“作弊点击”，不仅无法打击作弊反而会衍生出其他问题。

因此我们主张，把点击劫持从“劫持点击=欺诈点击”的等式中移除，并惩罚高频率的点击欺诈，进而使作弊过滤器有更高的可靠性。

关键在于，我们应该对每种欺诈方法进行逐一识别，而不是试图过滤类型。当我们认识到劫持点击、低频和高频点击欺诈之间的不同后，过滤每种作弊方法就变得容易许多，也不用依赖应用发行商来决定真伪。

设备农场(Device Farms)

当我们检验另一种作弊类型——“欺诈用户”时，我们发现了各种各样伪造应用安装和转化事件的手法。

如果是想通过安卓系统在云中虚拟手机十分简单，因为其有赖于操作系统上来直接完成。相反地，要在 iOS 上虚拟设备则相当困难，因此作弊者一般采用传统方式来创建大规模的应用活动。

让我们想像一下设备农场的场景：一座东南亚的工厂里，数十名工人坐在一排排的 iPhone 前面。

作弊者付出单次安装仅 2 美元的低廉劳力成本，雇用工人们一遍又一遍地点击和安装。

那么问题来了，您要如何区分这些真人在真实设备上的操作，与您实际想要获取的用户操作呢？

许多防作弊系统能够标记出那些不停留并且从不购买的用户。但问题是，大多数真正的用户也是这样，毕竟，多数应用行业别的第 1 天应用留存率很少超过 30％。当设备农场的操作与真实的流量混合在一起，我们很难确切地分辨用户的真假。

当我们仔细观察作弊者的例行活动，我们发现到， 作弊者必须不断重置设备 ID 才得以使假的安装被视为新安装。如果能找到方法在不传输个人可标识信息（PII, Personally Identifiable Information）的情况下来保存作弊者无法删除的信息，这些作弊攻击便很难奏效。例如在 iOS 内，Adjust SDK 需要在设备全面重置后才重新认定设备上的新安装，此重启过程超过 15 分钟，这样一来也就大大增加了周转时间。

另外，我们还可以查看用于发送 SDK 请求的 IP 地址。在没有任何屏蔽或 VPN 的情况下，这些请求通常显示来自越南或泰国等国家，过滤也因此方便许多。这些通过代理或 VPN 转移至美国等利润更丰厚市场的流量，通常会留下已在数据中心注册之 IP 地址足迹。我们通常可以在市场上的列表中找到这些 IP 地址，进而用来拒绝归因。使用当地境内 IP 地址并非不可能，但速度慢得多，成本也要高得多，因此对作弊者而言比较不具吸引力。

上述并不是我们发现的所有欺诈方法示例。事实上，SDK 伪造（最新的广告欺诈方法）也通过类似的方式解决。未来想必会有更大的困难需要应对，而我们也会持续关注发展并优化我们的反作弊解决方案。