Ads.txt: a first step towards transparency in the programmatic world

What’s behind the ads.txt protocol?

Ads.txt is a text file placed in the root of a publisher’s website. This file lists all third-party vendors authorized to sell advertising space on this site.

An ads.txt file requires 3 mandatory pieces of data and a fourth optional field:

• The domain name for the SSP or ad exchange
• The reseller’s business model
• The publisher’s Certification Authority ID (optional)

The following is an example of a form with an ads.txt line: “publisher123.com, 9876, DIRECT, f088dbbfd73d86c8”. The file ads.txt contains as many lines as there are third party vendors authorized to sell advertising space on the publisher’s site. Keeping the file up to date thus requires careful monitoring by publishers to ensure that bid requests are not lost unnecessarily. Without a line corresponding to a third party seller in the ads.txt file, a bid request would be considered invalid (since it is potentially fraudulent) and would therefore be declined.

The aim of ads.txt is to stop domain spoofing. Put simply, as soon as there is a bid request using Open RTB, an ad can be distributed across numerous websites. However, some of these sites may be fakes, posing as either premium or recognized sites. Ads.txt provides assurance to advertisers by certifying that a third party reseller is licensed to sell advertising space on a site’s behalf.

Firstly, DSPs index sites on which bid requests are made, ensuring an ads.txt file is present. This can result in various scenarios:

• No ads.txt file: the DSP can’t go through with the buying process because it’s unable to verify whether the reseller is certified or not.
• The ads.txt file is in place, but the third party seller is not listed on it: the DSP will not go through with the transaction as it is likely to be fraudulent.
• The ads.txt file is present and the third party seller is listed: the DSP goes through with the transaction because the third party seller is listed as certified.

With us so far? Let’s use a simple example. An advertiser believes they are buying an advertising inventory from premiumdomain.com, when in reality, as a result of a fraud they are instead buying from fake-premiumdomain.com. To attract advertisers to bid, fake-premiumdomain.com markets a much lower CPM than domainepremium.com, which has the effect of dragging down prices.

So ads.txt can have an impact on the CPMs of various advertisers, not least those who have been the victims of fraudulent sites! Nevertheless, ads.txt provides advertisers with more transparency and means they can check whether the sellers from whom they are buying inventories are licensed to sell advertising space for the publisher in question. Be warned though, it still doesn’t guarantee the quality of the inventory!

The move to Open RTB 3.0, the future of programmatic advertising

Despite the arrival of ads.txt, an inventory seller certified to re-sell advertising space can still sell it at a much higher CPM, simply by repackaging display inventories as video inventories for example.

With the aim of ensuring further transparency between publishers and advertisers, the IAB will thus launch ads.cert. Working in conjunction with ads.txt files, ads.cert will be introduced with OpenRTB 3.0. Initiated by the IAB, and a significant update to the OpenRTB protocol, ads.cert is designed to improve transparency in RTB deals by using an authenticated impression signature to validate information (ads.cert) and reduce the code’s structure, speeding up the bidding process in real time. While ads.txt targets fraud by verifying a reseller’s identity, ads.cert helps advertisers by guaranteeing the quality of the inventories they are buying from resellers.

Ads.cert works with DKIM (Domain Keys Identified Mail), a double verification system launched in 2004 to tackle email spoofing. Basically, the publisher makes a public key within an ads.cert file available on their site. As soon as bid requests are received, the publisher encrypts information linked to the inventory with a private key. This means that only the public key made available to advertisers via the ads.cert file can decrypt the information transmitted through the bid request and so guarantee the authenticity of the inventory put forward by the reseller.

Using a double verification system combining ads.txt and ads.cert, publishers will be able to guarantee advertisers a traceability chain showing bid requests from the start of the process to the finish in “real time”. By combining these two security protocols, the IAB hopes to end fraudsters ability to use OpenRTB as a sort of Eldorado by exploiting its weaknesses and lack of transparency. These initiatives were put in place to provide advertisers with more transparency while at the same time protecting publishers and ensuring a more honest industry.

Nevertheless, it wouldn’t be surprising to see new initiatives emerge over the next few years using recent technologies such as blockchain in the fight against fraud. Watch this space!