With adoption of ads.txt ramping up among publishers, this is as good a time as any to look toward whatever is next in the battle against ad fraud. The good news (that is, it’s good unless you were hoping for a bit of a breather) is that the IAB Tech Lab has already been on it, and it’s part of OpenRTB 3.0. It’s called ads.cert, and in the simplest terms, it’s a digital signature on a piece of ad inventory, which can be verified against a shared key.
To reiterate, ads.txt is a text file posted to the publisher’s site, listing every partner authorized to sell the publisher’s inventory and providing a distinct ID for each seller partner. In the open exchange, if the seller’s ID matches the ID in the file, the DSP can say, “Yep, this looks legit,” and make a bid if it chooses.
Ads.txt is an important step in reducing fraud, but it’s not the last step. It provides some clarity that the seller is doing something they’re supposed to be doing, but not necessarily that the inventory is what it’s supposed to be. It’s debatable how much impact a counterfeit/crap site could have by copying a legit site’s ads.txt file, but it’s at least possible that DSPs could be gamed that way. And as Digiday pointed out, ads.txt is no great deterrent to the dreaded practice of selling standard display inventory as video inventory (the old in-banner video trick).
Rakuten Marketing CTO and IAB Tech Lab’s OpenRTB working group member Neal Richter has been explaining this to other trade pubs lately: It’s like if you’re buying a Rolex, and you want to verify not only that you’re buying from an authorized Rolex retailer, but also that you’re getting a certifiably real Rolex from them. Alternately, it’s like what email providers did years ago to eradicate email fraud, by implementing signature confirmations on its servers.
There’s an IAB Tech Lab document out for comment and review right now, and it describes ads.cert as a “move to standardize cryptographically signed bid requests.” That still sounds confusing, so fortunately the doc goes into greater detail.
Unlike ads.txt, ads.cert isn’t a file, per se. It can work one of two ways. The publisher may create a signature and a message, and send those to all the partners in its ads.txt file. Alternatively, the publisher may allow one single partner to create the signature and message, and to send it to all of the other authorized partners. If an authorized party makes a modification to the inventory, they can add their own signature to it.
In the ad marketplace, the DSP will be able to validate domains by checking the ads.txt file and validate signatures by checking ads.cert. The signature is verified against a public key that can be read by outside systems. There’s no guidance just yet about what happens to older versions of the key, if the key is changed for any reason.
One catch is that ads.cert only works with OpenRTB 3.0-compliant systems. That’s preventing it from becoming widespread at the moment. But as we saw with ads.txt, sometimes all it takes is a firm stand by one influential company to get the ball rolling on a new initiative. In the meantime, check out the IAB document up for public comment and start putting together questions you want answered.
AdMonsters resources:
Ad Ops Decoder: What Is Ads.txt?
The End of Arbitrage? A Look at Ads.txt
Feeling Validated: AdReform Talks Ads.txt