The IAB-approved text file, ads.txt, that aims to prevent unauthorised inventory sales, has been created to increase transparency in the programmatic advertising ecosystem. J. Allen Dove (pictured below), CTO, SpotX, talks about both the limitations and solutions of implementing ads.txt, and the steps being made for inventory assurance in the industry.

The ad tech industry is subject to a variety of fraud and inventory quality problems. Unauthorised reselling of inventory is one of these issues, a practice that sees publishers lose out on profits and buyers fall prey to illegitimate inventory.

A number of players in the ad tech ecosystem have begun taking steps to ensure all inventory available to buyers is sourced directly from owned-and-operated publishers or authorised premium video resellers with the contractual rights to resell the inventory.

Ads.txt is the IAB Tech Lab’s newest mechanism for combating the black market for digital advertising inventory, giving publishers another method of preventing unauthorised or fraudulent resale of their content and reputation. Ads.txt is a protocol designed to prevent the sale of counterfeit and unauthorised impressions in programmatic transactions by providing a preformatted index of authorised sellers that publishers host securely in their own web domains. Programmatic buyers can then use publisher ads.txt files to screen for fake or misrepresented inventory. By caching and regularly updating the content of these ads.txt files, buyers can now buy inventory in real time with confidence.

New tech protocols rarely arrive without pitfalls

Ads.txt v1.0 represents a solid beachhead for inventory assurance, but there are some limitations in the current version that publishers need to be aware of. Specifically, mobile apps, and other non-web environments, allowed ad formats, subdomains, and delegating authority to a third party are not directly addressed. These will be addressed in later versions, and with the momentum behind this protocol in the industry, I bet they’ll come to fruition pretty quickly.

What about distributors?

One other scenario that is a bit gray in v1.0, and that is very applicable to video, is content syndication. Buyers want assurance that an impression opportunity available within syndicated content is absolutely legitimate. ads.txt definitely provides a path forward for the assurance of syndicated content advertising opportunities; but the current version does not clearly define how buyers and sellers should leverage the protocol to validate a seller’s digital rights to that content and its distribution and monetisation.

As it stands now, programmatic buyers will likely look for an ads.txt file located at the root of the BidRequest.Site.domain attribute presented to them in an OpenRTB (ORTB) bid request. This domain is the endpoint where the content is being displayed, not necessarily who it is being syndicated through and/or from. This means an SSP or advertising system would have to be listed in the ads.txt file of every syndication endpoint (e.g., every ORTB BidRequest.Site.domain attribute) even though its publisher is an authorised distributor of the content and they maintain resale rights on that endpoint, not the SSP. The SSP, in this case, has no direct relationship with either the owner of the content or the owner(s) of the syndicating endpoints, but provides the platform used by the publisher for monetisation of its rights.

ads.txt affords a distribution solution

The solution for this scenario is readily available within ORTB today with the help of ads.txt. Buyers should be presented with an ORTB bid request that contains a Site or App object that contains both Publisher and Content objects, the Content object further contains a Producer object. The relationship between these objects when coupled with 'variable declaration records' that will soon be added to ads.txt (which add the concept of simple key-value pairs that can indicate other metadata or relationships of the domain) can provide a buyer with the inventory assurance they desire, a chain of custody, if you will.

Using a typical programmatic buyer ORTB bid request as an example, here is how the process would work:

Producer creates content, which Distributor syndicates so that it can ultimately appear on site.com. When a user lands on site.com, the Distributor sends an ad request to the Ad Server/SSP on behalf of site.com.

The Ad Server/SSP then sends a bid request, which contains the site object (the where), publisher object (the who, the distributor), and the content object containing the producer object (the what), to the DSP.

Both the Producer and the Site work directly with the Distributor to monetise their content. To demonstrate their relationships, the Producer lists the Distributor in its ads.txt file using the 'syndication' action variable while the Site uses the 'resell' action variable. In turn, the Distributor lists the Ad Server/SSP as the ad system, as that is who they directly work with. The buyer can then couple the bid request information with the ads.txt files it garners from crawling the respective sites to establish a chain of custody for the authorisation of a syndicated impression opportunity.

One of the beauties of of this approach is its scalability. While the most direct solution for Buyer validation would be for the Publisher (also referred to as the 'Distributor' in the ads.txt spec) to work with the site owner to make sure that the ad system’s domain is listed with the Publisher’s ID within the Ad System on site.com, it can be very difficult to scale for the Publisher and content Producer.

Likewise, it can be wrought with false negatives, due to human error on the part of Site owners, especially if they have no direct relationship with an ad system. Using this more distributed approach, the Site, Publisher, and Producer only need to list partners they work directly with in their ads.txt files, creating a more scalable solution and streamlined ads.txt file.

J. Allen Dove, CTO, SpotX

One giant leap for inventory assurance

Despite the current 'to do's' of v1.0, which will no doubt be addressed in subsequent iterations, and even the gray areas around syndication, ads.txt is a critical step forward for the industry. Yes, publishers will have to allocate the resources to integrate and manage ads.txt files and monitor those of sites where they have reseller relationships, but it’s a small amount of work for the benefit it will bring. With the formal release of v1.0 of ads.txt, it’s time for publishers to start investing in its deployment. Inventory assurance across the ad tech ecosystem has just taken one giant leap forward. It’s time to end the black market trade and stop the bad players ruining it for the rest.