Ads.txt version 1.1 solves this one very important problem
In a previous post, we presented some best practices related to the use of ads.txt, a standard launched by the IAB Tech Lab in 2017 to reduce domain spoofing in digital advertising.
To recap, domain spoofing is a type of inventory fraud where low-value inventory is misrepresented and sold at a premium. By allowing publishers to publicly declare the intermediaries that are authorized to re-sell their inventory, ads.txt is an important step towards ensuring that buyers can verify the provenance of ad inventory before allocating spends.
However, ads.txt is not perfect.
Earlier this month, Mark Stenberg of Adweek reported how ads.txt mislabelling is flagrant and costly, based on a report published by sellers.guide, a tool for helping publishers maintain compliance with ads.txt and Sellers.json standards.
In August this year, the IAB Tech Lab released version 1.1 of the ads.txt—its fourth iteration—based on feedback received from the community to address challenges associated with older versions.
This guide will delve into what’s new in ads.txt v1.1 and why it matters.
What’s new in ads.txt v1.1?
Before we discuss what’s new in v1.1, let’s quickly address one of the most common mislabelling issues with the older ads.txt versions that we referred to earlier.
It is known that buyers tend to pay more for direct inventory. As a result, many industry intermediaries have started mislabeling themselves as “direct” in publishers’ ads.txt file. This is something that can ultimately hurt publishers by cannibalizing their direct budgets. In some cases, buyers may block the publishers’ tracking in response to the misrepresentation.
That is just one specific example of mislabeling that was found to occur at a large scale.
The worst offenders were found to be doing this on upwards of 70,000 distinct domains. Mislabeling may be intentional, or could simply be mistakes in parsing and implementing the file syntax. Either way, they reveal the flaw in the older ads.txt versions that created the conditions for such problems to exist.
In order to fix this, ads.txt v1.1 has introduced two new directives: OWNERDOMAIN and MANAGERDOMAIN. This is a simple update that hopes to have a big impact.
- OWNERDOMAIN is the primary domain of the parent company that owns the website.
- MANAGERDOMAIN is the company that manages inventory for the publisher.
As is evident, the new directives provide answers to two important questions at the beginning of the ads.txt file, i.e., (1) Who owns this website? and (2) Who monetizes this website? By making that distinction crystal clear, ads.txt v1.1 allows buyers to verify this information quickly and easily, thereby improving trust and transparency in the ad tech ecosystem.
Syntax for new directives
The usage syntax for the new directives allow a wide range of use cases for publishers including in-house monetization, managed monetization, country-specific managed monetization, and a few other more complex monetization scenarios.
Let’s consider these directives with an example. Publisher Acme Corp in-houses monetization for its primary site (acmecorp.com) and a child site (acmechild.com), but uses a monetization vendor (vendor1.com) for managing a third site within its owned network (acmechild2.com).
Here’s how the ads.txt v1.1 entries for the three sites will look like:
Case 1: acmecorp.com
Case 2: acmechild.com
Case 3: acmechild2.com
Let’s expand this example to include country-specific monetization. Acme Corp has a fourth site (acmechild3.com) managed by vendor2.com and vendor3.com, in US and France respectively. In this case, the ads.txt file will be as follows:
Case 4: acmechild3.com
(Basically, the two-letter country codes are used for demarcation.)
The new directives are intended to go at the top of the ads.txt file after any opening comments or version information from the publisher or monetization vendor managing the file. Also note that for clarity, IAB Tech Lab recommends that publishers declare the OWNERDOMAIN on every ads.txt file, even if it does not differ from the domain where the ads.txt file is hosted (as in case 1 above).
For more implementation information, see the official IAB Tech Lab guide.
Why should publishers switch to ads.txt v1.1?
It hurts publishers when their inventory is misrepresented on the open exchange.
With ads.txt v1.1, it has become easier to declare, at the very top of the ads.txt file, both the ownership status of domains as well as third-party vendors who are authorized to monetize them. The update will especially benefit small- and medium-size publishers who work with exclusive monetization vendors.
Here’s why: Publishers who outsource yield management often end up transacting under their manager’s Seller IDs—making them appear to have multiple hops to access their inventory. The trading algorithms that modern DSPs use are programmed to find the shortest path to the publishers’ inventory, keeping with the drive for supply-path optimization. An ads.txt file with the MANAGERDOMAIN directive declared can inform buyers that even with one extra hop, this may otherwise be the shortest route to transacting on the publishers’ inventory.
Overall these two new publisher declarations help to bring more transparency to the supply chain by enabling advertisers to better identify and control who their spend is going to. This helps to further combat fraud, minimize the loss of revenue for advertisers, and helps to ensure spend is being directed to the right places, all of which is essential for the sustainability of our industry.— Shailley Singh, Senior Vice President of Product, IAB Tech Lab.
Ads.txt v1.1 is the IAB Tech Lab’s latest iteration of the ads.txt file used across the ad tech ecosystem.
By creating an OWNERDOMAIN and MANAGERDOMAIN directive, buyers can easily tell who owns a particular website, and who monetizes it. As a result, buyers can now verify who actually owns the ad inventory they are looking to bid on, which improves the trust and transparency between buyers and sellers.
Given the upside and the minimal lift required to comply, we recommend that publishers work with the monetization partners to roll out the update for their existing ads.txt file.
In addition, following a few best practices will ensure that you’re getting the most out of the standard.