Ads.txt: A Web 1.0 Solution To A Web 3.0 Problem

“The Sell Sider” is a column written by the sell side of the digital media community.

Today’s column is written by Manny Puentes, founder and CEO at Rebel AI.

A certified letter might make its way through a number of post offices as it travels from Point A to Point B, but neither the sender nor recipient care how the letter arrives as long as it arrives in the right place. The same should be true in programmatic advertising.

But in ads.txt, the IAB’s latest tech initiative, the burden is put on the recipient to list all the possible post offices en route so the sender can feel more confident it ended up in the right place. While this might increase the feeling of transparency, it doesn’t solve the core objective and certainly doesn’t simplify it.

The specification sets out to solves a very real problem in the industry – preventing bad actors from making a profit from selling misrepresented or potentially fraudulent inventory – but the implementation in its current form isn’t sufficient to address the complexity of the current supply chain and still leaves channels open for fraud.

Many major technology providers have already voiced their support for the initiative. While it’s a positive development to see the industry coalesce around solving big problems, it’s also important to recognize what the new specification does and doesn’t solve for the industry and the long-term implications it might have.

The False Negative

The ads.txt specification is simple in concept: A publisher must list the companies authorized to directly sell and resell its ad inventory in a publicly available, crawlable text file. Advertising systems, such as demand-side platforms (DSPs), will host a crawler that will cross-reference the ads.txt file to ensure that they are buying inventory from a legitimate source.

As a fraud prevention model, ads.txt collapses when an “authorized reseller” works with a network or supply-side platform (SSP) trafficking illegitimate inventory, either intentionally or inadvertently. As long as the reseller is listed in the ads.txt file, the DSPs will then see the reseller as “authorized” to sell that publisher ID, regardless of where the inventory actually came from. This puts the burden back on the reselling platforms, where it already exists today.

Ads.txt is actually more likely to eliminate other ad companies that are legitimately being called by the publisher page. This is simply a result of an increasingly complex ecosystem where any given ad call travels from publisher to DoubleClick for Publishers (DFP) to any number of platforms (as seen here).

Ads.txt is a tempting way to simplify this complex path by pushing publishers to publicly list their partners, but the existing implementation of ads.txt illustrates that the reality is more complicated.

As an example, here are the current business relationships listed by a real publisher in its Ads.txt file:

The advertising calls on this publisher’s page include calls to different platforms, such as DFP, which calls AppNexus. This is seen as legitimate because AppNexus is declared in the ads.txt file.

However, a typical ad call rarely stops there. AppNexus in turn calls AdForm (as seen below). AdForm isn’t declared within ads.txt as having a relationship with this publisher.

AppNexus is using AdForm as a demand partner, but AdForm could potentially call another DSP to purchase the inventory. If that DSP or even one of its direct advertisers crawls the ads.txt file and determines that AdForm doesn’t have a publically listed relationship with this publisher, they may demand a clawback or take other adverse actions against the platform, even if AdForm legitimately sold the inventory.

The Inevitable Side Effects

Some might argue that this is how the specification is intended to work by putting pressure on unlisted platforms and eventually eliminating them. But these platforms might also be providing better data, higher conversions or other data layers that contribute to the supply chain’s overall value by providing a high yield for publishers and higher conversions for advertisers.

Ads.txt files can also be cached by the DSP for up to seven days. Supply chain partners that may appear to have been invalid at the DSP caching time might be valid at the time of the ad call and vice-versa. Since there’s no historical ledger or versioning, disputes are likely inevitable.

This ends up hurting publishers, which will be the potential victims of clawbacks from ads that were legitimately run on their domain, but through platforms that weren’t listed in the file at the time of caching, through no fault of their own.

If buyers start strictly adhering to the specification as they say they will, this will absolutely drive companies out of business, an effect some are praising. But this will stifle innovation and the opportunity for new companies to compete against giants like Google. And still, nothing is stopping fraud from entering the ecosystem via an authorized reseller or platform.

Net Neutrality For Advertising?

Though the stated initiative of ads.txt is to stop inventory resale, it achieves this by establishing “preferred” channels, which naturally favors the industry’s most influential companies – sort of like a net neutrality for advertising. While it might be tempting to push for simplicity through consolidation, that consolidation will come at the expense of innovation, choice and the open market.

There’s no doubt we need to continue to work together as an industry on these types of initiatives, but we must also make sure the solutions are the right ones for the long-term health of digital advertising.

Follow Manny Puentes (@epuentes), Rebel AI (@Rebel_AI_) and AdExchanger (@adexchanger) on Twitter.

This post was syndicated from Ad Exchanger.