The Problem behind Ads.txt or perhaps we need to talk about 2 problems behind Ads.txt: the first is the domain arbitrage and the second problem is domain spoofing. When domain arbitrage happens, the publisher still gets some money. When Domain Spoofing happens the money never arrives at the publisher. But let’s try to understand how these ad frauds work.
Starting with the first. Domain Arbitrage. In the advertising industry, there are resellers that are not authorized by the publishers to arbitrage their inventory. The resellers sell the inventory on programmatic, buying it cheaper from the publishers and taking then a percentage. Resellers are considered middleman’s, reselling the inventory on the exchanges, with URL transparency or in a semi-transparent way. This makes the inventory expensive to buy, and at the end, the money is not going to the publishers. This is called Inventory Arbitrage.
Domain Spoofing is another issue on Programmatic. Since is the publisher that is passing the url on the bid request, it is easy to show a premium domain on the bid requests. Advertisers think they are buying premium inventory, when in fact they are buying advertising on another website. Will give you an example. The advertiser is buying on Spiegel Online when in fact is buying ads on fakenews.com. Domain Spoofing should be detected and avoided by the SSP’s or DSP’s, but with more and more players in the RTB ecosystem, this is difficult to detect. IAS (Integral Ad Science) says that up to 12% of the display impressions were fraudulent in 2017, and on Video this number of fraud increases to 16%.
Let’s talk about one example: Methbot. Methbot is the most famous case of ad fraud, detected by White Ops. Russian hackers did almost 5 Millions per day using bots and masking 6000 premium domains and more than 250000 URLs. The domains were from premium publishers like Vogue, and the ad type was video, due to the higher CPM’s. The hackers also register IP addresses in US, so they look American homes.
Here are 2 examples of ad fraud, domain spoofing, and unauthorized inventory arbitrage, that the implementation of Ads.txt can help to solve.
What is Ads.txt?
If you know robots.txt, from SEO, this explanation will be easier, as Ads.txt is inspired on the robots.txt from SEO / Google. Ads.txt is a txt file named ads.txt that is inserted on the main domain of a website. This file will inform the RTB players about the Authorised Digital Sellers of the domain. According to IAB, the Interactive Advertising Bureau, this makes hard for bad actors to profit from selling counterfeit inventory across the ecosystem.
Ads.txt works in advertising as Robots.txt works in Search. On Robots.txt the domain says which folders authorises to the search engines to be index publicly. On Ads.txt the domain informs which RTB sellers can sell ads there.
So how does Ads.txt works?
The content owner creates a Ads.txt file and uploads on the main directory of the domain. Example: ppc.land/ads.txt. On the file Ads.txt the content owner informs the supply chain authorised to sell advertising, for example google.com. The DSP’s crawl the domains and looks for the Ads.txt. When Advertisers are buy ads targeting domain, through a DSP that supports Ads.txt, Advertisers have the guarantee that this DSP is only buying on ads of a domain through the authorised sellers.
Not only the DSP’s and the Publishers can benefit with Ads.txt. The Exchanges can also have filters to avoid Domain Spoofing and Inventory Arbitrage, as now they will be able to know the authorised sellers for each domain.
On the Ads.txt, the content owners can specify the authorised exchanges and specific accounts, networks and sales houses that sell programmatically their inventory, and content syndication partnerships.
On the first version of Ads.txt there are 4 fields. The first field is the SSP/Exchange Domain where the domain owner can specify the SSP (example smartadserver.com). The second field is the SellerAccountID, where is possible to specify the id of the account on the SSP, the third is the PaymentsType, where the publisher can specify the relation of the payment (if it is Direct or a Reseller). The last and forth field is optional and is the TAGID. This field is an ID that uniquely identifies the advertising system within a certification authority (this ID maps to the entity listed in field number 1). A current certification authority is the Trustworthy Accountability Group (TAG), and the TAGID would be included here. Google share the same id for all Publishers. Appnexus also.
Is important to say that at this moment, Ads.txt was only created for web. This solution only works on web and not on mobile apps. Ads.txt also don’t work with blind/anonymous inventory.
IAB recommended different approaches to the ad tech players: 1 Do nothing (wait and see); 2 Buy authorised + non-participating; 3 Start shifting authorised as adoption increases; 4 Let advertisers choose (provide option for the buyers); 5 Adjust bidding according to risk/reward tradeoffs; 6 Only buy authorised. If advertisers reach the option 6, publishers and exchanges will not have an option to not participate on ads.txt
Who Supports Ads.txt on the Buy Side?
On the buy side we are in the approach, or let’s say, phase 1, on most DSP’s. This phase is don’t do nothing, and wait for the Ads.txt adoption. Appnexus says that will begin to use Ads.txt information to strengthen their existing inventory quality programs, but without giving extra options to advertisers using their platform.
So seems that for now, advertisers using ad tech, do not have any control on how to use Ads.txt, since DSP’s are not providing any options to use as targeting or on bidding.
The most popular DSP – Doubleclick Bid Manager – went already to the Approach/Phase 6, doing a big push for the Ads.txt, announcing that by the end of October, “DoubleClick Bid Manager will only buy a publisher’s inventory from sources identified as authorised sellers in its ads.txt file when a file is available.”
For many DSP’s, a massive implementation of Ads.txt could potentially affect their billings. As of now, advertisers using whitelists, can buy via multiple exchanges via resellers doing Inventory Arbitrage. With Ads.txt this will be impossible, at least the non-authorised arbitrage. As most of the DSP’s have a fee based on percentage, this can possible affect their billings.
Who is already using Ads.txt on the Sell Side?
According to Google, around 6000 domains have already the file Ads.txt implemented. See the evolution of the Ads.txt here on PPC Land. The adoption is growing fast.
Do you want to see an example? I checked multiple Adx.txt files and the biggest I’ve found was hosted on the British Daily Mail, with more than 20 supply chain suppliers, for native, video, display and resellers.
But surprise or not, the Ads.txt is mainly announced as supported by the Exchanges. They are not enforcing it on exchange level, letting the DSP’s do that filtering.
The blog Adops Insider crawled 10.000 popular domains and found out that 12% of the publishers had already a Ads.txt file.