In May 2017, the IAB Tech Lab introduced Ads.txt, a small piece of code that lives on publisher websites, for the purpose of creating more transparency in the programmatic buying ecosystem. Ads.txt stands for Authorized Digital Sellers and declares which suppliers can sell their inventory on that website. Prior to this effort, counterfeit inventory and spoofed domains often surfaced from some of the largest and most reputable publishers. As fraudsters continue to become more and more sophisticated in their operation to steal advertising dollars from premium publishers, it’s imperative that agencies work with publishers and supply partners that implement Ads.txt in order to create greater transparency into the auction process between the buy and sell side.
How will Ads.txt Help?
One of the major defects of the current programmatic process is that there is no validation of the end domain from which the impression is bought, or if the impression is being sold by an authenticated seller. For instance, if you bought an impression from CNN.com, there is no way to verify it was actually sold by CNN.com. As a result, counterfeit inventory (including domain spoofing) and general non-nefarious but mislabeled inventory persist. This is like winning a bid on a designer bag on eBay, but then later realizing it’s counterfeit.
With the implementation of Ads.txt though, buyers can see and eventually bid on authorized sellers only, which helps eliminate the possibility of inauthentic, misrepresented, and counterfeit middle men. Ads.txt is similar to robot.txt which is placed on every page that represents the following:
- Publishers who sell on intended exchanges
- Networks who sell on behalf of publishers
- Content syndication partnerships that publishers utilize to sell their inventory
With Ads.txt buyers will have access to a public ledger when they’re purchasing inventory that verifies the SellerAccountID (ex: 4254 in the 1st line item above) matches the authorized sellers in the supply chain. This ID is the one buyers would be able to authenticate by checking that it matches the authorized seller list on the publishers’ ads.txt file. Once you have all of the seller and publisher IDs you need, you can use this to create a whitelist of specific authorized publisher IDs and exchange IDs and filter out those that do not correspond.
Sellers, on the other hand, will be able to track and prevent against counterfeit and misrepresented inventory from their site. Generally counterfeit inventory is priced cheaper than the real thing. As a result, buyers may end up directing more of their spend to counterfeit inventory than to the actual publishers, which harms the sell side’s (SSPs, exchanges, and publishers) bottom line.
What Buyers & Clients Need to Know
As of early November, the adoption of ads.txt had almost reached 50% of the top 10,000 domains, 44% within digital advertising. In large part what drove adoption was Google’s announcement that DoubleClick Bid Manager would automatically filter out unauthorized inventory (from a publisher’s ads.txt tag). Called a “prebid”, this process is based on technology like DoubleClick that crawls pages to see if publishers have implemented the ads.txt code. In the case with DBM, this is done on an automatic basis and there is no added charge to marketers or agencies. Meanwhile, third party verification providers like White Ops, DoubleVerify, and Integral Ad Science have yet to build this into their capabilities, which would usually come at an incremental CPM charge.
Prior to DBM adopting the change, the sell side cited a few issues that hindered their adoption of ads.text and continues to prevent global adoption. These include but are not limited to:
- The ads.txt file had to be hardcoded onto the domains of each publisher and for a massive company that owns hundreds of global domains, it can be cumbersome to implement.
- Page load and latency issues. The additional line of code could cause for slower page load times. However, the announcement and move from Google has pushed things forward as other DSPs like The Trade Desk, AppNexus, and MediaMath have also adopted it across their supply.
- Manual implementation. Publishers are manually implementing the ads.txt code, which means they are subject to making technical mistakes like listing the wrong codes and IDs, listing them more than once or making spelling errors.
- Ads.txt does not provide every possible permutation of ad space, it’s inventory details are limited.
While valid, the benefits of implementing ads.txt far outweigh the cons cited by the sell side. Not to mention if the buy side is demanding adoption, everyone in the ecosystem will have to follow suit eventually.
How will Ads.cert Help?
To combat lack of inventory detail in ads.txt, the IAB rolled-out ads.cert, an initiative that authenticates (or certifies) the available inventory represented. The important difference between ads.cert and ads.txt is that the former allows for the validation of claims made by ads.txt that a publisher allows an exchange or network to buy. Ads.cert uses cryptographically signed bid requests, similar to blockchain, to validate the information between buyer and seller which ensures that information like domain, location, IP address, device, position on the page, and impression type cannot be misrepresented. To implement ads.cert, publishers must update to the OpenRTB 3.0 protocol. Simply put, OpenRTB is the technical framework that supports programmatic buying and ads.cert is only compliant on the 3.0 version. Released by the IAB in Sept 2017, OpenRTB 3.0 represents the largest overhaul of the OpenRTB protocol since its inception in 2010 and will likely be more of a solution in 2018.
It is important to note that just because a publisher implements both ads.txt and ads.cert in their code, buying premium content is still not a guarantee. Lower-tier publishers like Daily Natural Remedies or Celebrity Life Journal may implement ads.txt, just as The New York Times or Huffington Post would, but the two inventories are very different. Limiting your advertising to just publishers with ads.txt and ads.cert is still premature at this point.
However, the move for ads.txt and ads.cert is in the right direction especially since multiple DSPs and SSPs have adopted filtering at least for ads.txt validated domains. 360i PBG, for one, will only continue to work with ad platforms that prioritize the selection of ads.txt filtered sites and continue to push the marketplace towards better development and better supply side optimization practices. As more DSPs make ads.txt filtering innate to their reporting platforms in Q1 2018, we can begin to see the impact on performance and determine the best path forward. Ideally, this would involve a closer monitoring of all exchange and premium marketplace buys, and opting out of unauthorized sellers.
While the marketplace moves to address concerns with inventory quality, there are five distinct questions that 360i PBG recommends marketers ask their supply partners to ensure that they are moving along with the industry and doing all they can to reduce fraud:
- Have you implemented ads.txt on your site? If not, what is the timing?
- How granular does your implementation of ads.txt entail? Does the implementation of ads.txt include all placement formats (inclusive of video, display, native, outstream video, etc), mobile in-app vs. web, and types of relationships (Direct, reseller)?
- Is the adoption at a global scale or just domestic only?
- Have you adopted the OpenRTB 3.0 protocol yet? Ads.cert? If not, what is the timing?
- What additional measures do you take to protect the quality of your inventory?
Photo credit: StrataBlue