An article about certain sites “potentially committing a form of ad-fraud” using ads.txt (Authorized Digital Sellers) files has been making the rounds and we decided to look into the details to see if we could learn from the post to improve our transparency / anti-fraud specifications. We have reached out to the group behind the piece to discuss it (and also had offered to work together prior to the post) and we hope they will engage to dive deeper.
What is discussed in this blog post is nothing new. We have previously discussed and provided guidance (see links later in this post) on the scenarios highlighted in the new post. For now though, the following is an analysis based on what we have been able to assess.
Note that we are certainly not intending to downplay ad fraud or claim that Tech Lab specs are perfect. The evolving nature of fraud perpetrators and of technology itself means we all need to remain vigilant and to continue upgrading anti-fraud standards and tools.
The Purpose of ads.txt
The first thing that struck us in the article that there is clearly a misunderstanding of the purpose of the ads.txt specification. Ad fraud comes in a variety of forms, and ads.txt is not intended to solve for all forms. It has a specific purpose: to allow buyers to verify that they are buying from authorized sellers, i.e, when buyers have a specific publisher they want to buy from, the ads.txt file hosted by the publisher helps them check that they are buying the publisher’s inventory via entities “authorized” to sell by the publisher. What they are talking about in the “Breitbart” story is the exact opposite. Here they are talking about a publisher trying to hide its identity. That is not the focus of ads.txt, and the scenario outlined can be further thwarted by using a more complete set of standards.
ads.txt Is Part of a Toolset
ads.txt is not the only tool in your anti-fraud toolset.
- As mentioned above, populating as much context as possible (keeping user privacy in mind) in the OpenRTB request would help ensure that buyers are able to transact in the manner they desire.
- sellers.json is another important transparency tool, released shortly after and intended to be used alongside ads.txt. It allows a buyer to cross reference and verify the entries made by a publisher in its ads.txt file and can be helpful in validating the relationships proffered in ads.txt files. We checked the example ads.txt lines mentioned in the article and if a buyer required and properly checked them with sellers.json information, almost all of them would be rejected and not bought at all.
- The related (to sellers.json) SupplyChain Object specification in OpenRTB can also be used to check the entities involved at the transaction level. This enables buyers to perform even more interesting and useful supply path validation and optimization.
- It is important to remember the role of the anti-fraud and verification vendors in the mix. For example, they provide technology to check whether the advertisement was shown on the website or the app where it was intended.
ads.txt Uncovers Irregularities, It Doesn’t Mask Them
We also noted the story’s claim that there was a scheme involving so- called “dark pool sales houses”, and that ads.txt somehow facilitates such a scheme. That simply does not make sense. Here’s why:
- Ad transactions do not happen in a vacuum with only ads.txt. The actual OpenRTB bid request is a key part of that transaction, and the request has a host of additional information that is used to transact — chief among them being the website domain (others are the name of the site, the page URL on which the ad will appear, etc).
- The article does not offer any proof that such dark pools are helping siphon a brand’s advertising budget to unintended sites. Regardless, there are two possibilities on how a scheme with “dark pools” could be run:
- An intermediary (SSP/exchange/DSP) is maliciously modifying the domain in the bid request to make requests from Breitbart look like they come from some other publisher (say, cnn.com).
- An intermediary is selling “blind” inventory (meaning no domain or URL included in the bid request), where buyers do not know which publishers they are buying from.
In both scenarios, the fact that Breitbart included entries from other publishers in their ads.txt file does not help Breitbart at all.
- In the first case, the buyer would be checking the ads.txt file of the domain listed in the bid request — which would not be Breitbart. So long as buyers require an ads.txt check to bid, the transaction can only proceed if it is coming from somewhere authorized by CNN’s ads.txt file, not Breitbart’s.
- It is also likely if this happened, that the domain used in the bid request would be the actual domain paid by the SSP (meaning that payment would go to CNN in this example), which seems to be counter to the goal of committing direct domain spoofing fraud.
- In the second case, there is no domain available, so the buyer would not be checking any ads.txt at all! (Side Note: In fact, this is a scenario that would in fact have been prevented if buyers always require ads.txt checks.)
So, it seems entirely pointless for Breitbart to have those entries in their ads.txt file if the goal is to perpetuate either of the “schemes”. They don’t need ads.txt files to participate in “dark pools”.
In fact, ads.txt appears to have helped uncover, not mask, these “dark pools” if the claim is true. (Side Note: In fact, the suggestion that all those IDs should be blocked would only harm the other publishers and not Breitbart.)
Onward!
We have addressed the erroneous claim that ads.txt is complicit in allowing Breitbart to trick brands into buying from them. But we want to go further and provide some useful information to the industry.
We know that our standards and specifications may not always be properly implemented, as in this case, leading to misunderstanding and imperfect conclusions. We have repeatedly provided guidance to limit this, and we do welcome research that highlights incorrect implementations and informs revising specifications, enhancing compliance programs to verify proper implementation, and providing supporting guidance on correct and best practices.
We also know that there are complex relationships in the ecosystem that need to be represented and supported in our standards, and that sales houses have been force-fitting specs to support these relationships. That is something we are already working to fix through a Tech Lab working group.
On the compliance point, we are working with organizations like TAG and IABs globally to incorporate requirements for the use of ads.txt, sellers.json, and SupplyChain Object, into their relevant programs, to further improve transparency in the supply chain. The TAG Certified Against Fraud (CAF) program, for example, identifies parties that have adopted a wide range of relevant standards and practices, including ads.txt and sellers.json. Even companies that earn these certifications need to continue to be diligent in how they use standards on an ongoing basis — and buyers always need to enforce disciplined processes throughout the supply chain.
It is worth pointing out that this specific problem has been discussed in the past by the Tech Lab to ensure buyers understand proper use of the ads.txt and sellers.json specifications.
- This blog post about adopting sellers.json and Supply Chain Object covers some common misconceptions similar to the ones discussed above.
- And this other blog post on “The Three Deadly Sins of ads.txt and How Publishers Can Avoid Them” discusses potential problems and the need for discipline in populating and maintaining ads.txt files.
Tech Lab’s Commitment to Transparency
Meanwhile, Tech Lab is committed to continuing our efforts to improve transparency in the advertising supply chain. We are working on updates to app-ads.txt to better support CTV apps, we are discussing with members a number of “buy-side transparency” proposals, and we are working on adding more tools to our portfolio to help with data validation (across ads.txt, sellers.json, etc.) and facilitate cleaner implementations of ads.txt and sellers.json across the industry. On the whole, it is important to note that these are tools that solve specific problems and that no one of them should be mistaken for a panacea to the world’s problems. We welcome industry collaboration to improve the standards, and increase transparency across the supply chain.
Added 7.30.2020:
Based on some responses to this post, especially on social media, this educational piece may have been viewed as Tech Lab discounting the value of independent research and scrutiny of our specifications. That was not our intent, either through the content or the tone (we do occasionally like to be a bit…informal!). We truly appreciate receiving and learning through feedback from our members, media and specialist researchers, and others. If you are working on stress testing one of our standards or analyzing adoption/practices, we would love to get involved and take it to our working groups to make changes when needed. Please send us a note anytime at support@dev.iabtechlab.com and we will be happy to collaborate.
ABOUT THE AUTHOR
IAB Tech Lab Product Team