As a company that represents both advertisers and publishers, fraud is never in TripleLift’s interests. Unfortunately, ad fraud does not come from a single sort of entity, nor is it easy to detect, and has become pervasive enough in the industry that it is casting a pall over the entire digital advertising industry. That said there are several efforts underway in the industry that aim to mitigate many of the primary economic motivations for fraud.
The purpose of ad fraud is to make money for the fraudulent actor. One form of fraud has been to make money as though the seller is selling a legitimate publisher’s traffic when, in fact, it is not. This generally means finding a way to get paid for traffic from an intermediary that it can send fraudulent traffic to, and then faking the traffic. To get paid, fraudulent actors would find counterparties to pay them, such as ad exchanges, ad networks, or the like. In an ad exchange, for example, the malicious party could register a seat and start selling traffic for any domains – historically ad exchanges didn’t control who could sell what. A simple ad exchange might not validate any information about the party that registered the seat, so it could be organized crime, and might also not validate that they rightfully have access to the domains and apps that they’re selling. A DSP or ad network might assume that all parties on the exchange have been verified and buy any impression that says it is nytimes.com. The requests might have components changed – like fake location data could be added to add value given that buyers will pay more for impressions in certain areas, the app or domain could be changed to pretend to be more valuable, or the entire request could be forged. This ultimately steals money that the advertiser would have spent on valuable impressions, and steals money that would have gone to the publisher.
To combat the above forms of fraud, there are several concurrent efforts in the industry. The most discussed at the moment is ads.txt. It directly addresses the form of fraud where a malicious party attempts to sell another party’s inventory by enabling the publisher to explicitly denotes which exchanges – and which sellers on which exchanges – have the right to sell their inventory. While it was originally unclear that ads.txt would be successful, the prevalence of fraud and the incentives for both supply and demand have spurred rapid adoption. Google’s DBM, by far the largest DSP in the industry, has indicated that it will only buy from authorized sellers according to ads.txt, for all sellers that have ads.txt, in the not-too-distant future (important caveat – if a seller doesn’t have ads.txt, as most on AdSense won’t, the won’t be impacted). This will immediately remove economic incentives for sellers that pretend to have authorization to sell publisher’s inventory. Ads.txt is simple and efficient, though there is concern that it will cement the positions of strength of larger players by creating an extra layer of work for new partners.
Another tactic is the supply keys proposed in OpenRTB 3.0. This approach has a per-seller, per-impression encryption that uniquely ties metadata to that impression, along with the authorized seller. This is sent with the impression request to the exchange, and then passes through the OpenRTB request and response protocol. Implementation requires additional complexity generating encrypted values on a per-impression basis. The technology has the theoretical ability to ensure that the complete set of information is accurate with each impression, to the extent that the client that generated the information is also accurate, such as users, geo, and sellers. That said, when a publisher has limited the scope of eligible sellers based on ads.txt, the additional verification afforded by the OpenRTB 3.0 encryption would be against fraud by an approved reseller. Thus this method may not address a large percentage of the fraud that might remain. This does effectively protect against repeated calls just to the ad tag, which do not originate from a client.
Another form of fraud is publishers themselves that may seek to inflate their impression counts through illicit means. An example might be a publisher that creates a website, steals third party content, then creates AdSense tags (or any other self-service exchange) to their page. These publishers get paid when visitors view their sites, so they try to create fake visitors using bots or similar tactics. Neither ads.txt nor the OpenRTB 3.0 encryption are effective in combatting bots. Ads.txt isn’t effective because the publisher would be incentivized to include any reseller in its ads.txt – especially if it’s selling the traffic it worked to fraudulently generate, or simply not use ads.txt. The encryption fails to address this form of fraud because the impressions are likely generated at the publisher level, meaning if the publisher employs this encryption with the request – the encrypted values will be included as the request is likely originating from a client. But the publisher is unlikely to employ this technology.
Bots that create fraudulent traffic are either hosted on servers at data centers, or are part of toolbars or other client-side software that can generate fake requests. In the case of data-center-based requests, part of the TAG fraud requirements are that vendors block all data center IPs – this is also standard for most exchanges in any event. Detecting client-side software, or non-data-center-hosted bots can be more challenging. The easiest way to avoid these, in general, is for buyers to simply use a whitelist of sites that they know aren’t bad actors. Beyond that, vendors like WhiteOps and DoubleVerify have developed software to analyze and detect bots. This includes analysis like detecting whether the IP browses the web 24 hours a day, whether their usage patterns follow expected patterns, whether the browser updates based on expected patterns, etc. There are other vendors like SafeGraph that monitor global location patterns, such as whether users tend to jump around at impossible rates, to detect likely fraudulent location behavior.