“The Sell Sider” is a column written for the sell side of the digital media community.
Today’s column is written by Ian Hewetson, vice president of client services at Eyereturn Marketing.
Forget this summer’s solar eclipse. We’re witnessing something far more unusual right now: the universal endorsement of a single system in the ad tech world, the adoption of Ads.txt.
Ads.txt truly is an elegantly simple, universally accessible solution to a problem that’s bedeviled the industry for far too long. But in the rollout excitement, a few subtle issues are emerging that may have outsize effects on buyers and sellers without the right level of oversight.
Ads.txt solves a single problem: domain spoofing. This is where someone creates a fraudulent site and passes the false domain to the supply-side platform (SSP), which sends the false domain to a demand-side platform (DSP), which bids on it.
Advertisers suffer because they’re not buying New York Times inventory. The New York Times suffers because the fake NYT inventory undercuts its pricing. And the reputation of ad tech suffers for allowing this to continue.
Though this is simple, the devil can be in the details. In the course of an Ads.txt rollout, it became clear that a lack of communication between publishers and SSPs could break the system. Critically, the only party that can really identify these breakdowns is the DSP.
For example, we saw one instance where a publisher had implemented its Ads.txt file for two major sellers. It contacted both sellers to ensure that it was done correctly so that its inventory would be surfaced by those sellers as Ads.txt-verified. Both sellers confirmed that all was good, which the publisher took at face value.
Except all was not good. In both cases, the publisher’s inventory was not being seen by buyers as Ads.txt-compliant.
For the first seller, the Ads.txt protocol was outside the general standard. This seller uses multiple legitimate paths to sale, and the Ads.txt setup is rather convoluted, requiring distinct domains for different types of inventory. Strike 1: The publisher failed to interpret the specs correctly and implemented Ads.txt incorrectly. Strike 2: The seller looked at the implementation and declared it to be valid when it was not.
In the case of the second seller, the Ads.txt setup was very straightforward, and the publisher implemented it correctly. But it appears the seller was not passing the publisher ID on the bid request, resulting in a mismatch, which stops any bidding on this inventory. In this case too, the publisher reached out to the seller, but the last I heard, the issue was still unresolved.
Both issues only came to light during Ads.txt testing of my company’s DSP when we checked Ads.txt compliance on our top 1,000 domains. Having a relationship with this publisher and not seeing its inventory as approved, we contacted it and helped with the investigation.
When we first raised the flag, the publisher initially assured us that its implementation was golden because both of its sellers had verified that it was. It took some actual investigation and collaboration to figure out the issue.
What we’ve taken away from the experience is that Ads.txt is a great solution to the problem of spoofed domains. What we’ve also discovered is that it’s subject to a wide variety of missteps on the implementation side, and these missteps can slip through multiple hands unless verification is done on the demand side.
If you’re a publisher reading this and you’ve noticed any decline in demand since implementing Ads.txt, you should check with your DSP to make sure your implementation is correct. And if you’re on the demand side and not seeing specific inventory sources, give those publishers a call.
We’re all in this together, and while it’s a programmatic world, sometimes it takes some real-world collaboration to get the job done right.
Follow Eyereturn (@EyereturnMktg) and AdExchanger (@adexchanger) on Twitter.
