Ads.txt landed in the digital media world circled by a lot more confusion than you’d expect from a text file. Although the goals of rendering domain spoofing worthless and cutting down on arbitrage were quite noble, the approach was almost too simple for an industry that revels in complexity.
Fortunately, the folks at Ad Reform came to the rescue with an ads.txt validator that was the talk of the Nashville Publisher Forum. I caught up with Ad Reform Cofounder Landon Bennett to talk about the development of the validator; the future of the tool and ads.txt itself; and some of the other interesting services Ad Reform bring to the table.
GAVIN DUNAWAY: What inspired you to create the Ads.txt validator?
LANDON BENNETT: We try to stay in the loop on discussions on the ad ops subreddit/Slack group and all the ad operations blogs/publications. We heard that folks were having issues trying to make sense of the IAB spec as they implemented their ads.txt file. Honestly, this was probably one of the reasons ads.txt didn’t gain much adoption at first.
We felt that this was a perfect job for technology, so we built AdstxtValidator.com as a side project to enable ad ops and engineering teams test their file against the IAB spec. Our background is in building web/browser-testing software, so this was a perfect fit.
GD: What’s been most difficult in developing and maintaining the tool?
LB: The most difficult thing about developing/maintaining the product, is that any IAB project/standard is a moving target. The spec is constantly changing (e.g. the canonical domains of ad partners), and will likely continue to change in the future, similar to RTB, VAST, and other initiatives. As a publisher, your time is not best spent keeping up with all of these changes as you update your ads.txt files. That’s where we come in.
GD: What’s been the strangest part? (I bet you’ve seen some weird entries…)
LB: Around 50% of the files tested through our tool have at least one warning or error. A text file isn’t complicated, but as with anything done manually, mistakes are easily made. On top of that, one of the biggest things we see is that ad partners that are being included in these files have not reached out or responded to the IAB working group to confirm their preferred domain name.
I won’t namedrop, but we saw an ads.txt file with over 700 records (over 70 ad systems). That’s insane, but unfortunately, not surprising.
GD: Next up is the Ads.txt validator PRO—Lose your amateur status! Some interesting features are included like validation through an API and slack integration. But why will a pub really want to upgrade? Does having a more complex header setup or a heavy amount of demand partners make such a tool more worthwhile?
LB: Our free tool has a lot of value, but you’re testing your file manually, after it’s already pushed to production. Right now DSPs are pushing/recommending publishers to implement the ads.txt initiative, but in 2018 it’s likely that they will require it.
At that point, ads.txt issues could mean lost revenue, so it will be incredibly important to test your ads.txt early and often to ensure compliance as you make changes. With the validation API, publishers can build ads.txt validation into their CI/deployment process so they automatically catch issues before they go live. We’ve talked to CTOs/VPs of ad ops of multiple publishers that have expressed a need for such an API.
Publishers that have a lot of ad partners and are constantly adding/dropping partners are more susceptible to errors. Any time there are many moving parts, there’s a higher chance of someone dropping the ball somewhere. Adding automation to your testing/deploy process will protect you from human error.
We’ve also built a Slack integration to tie directly into company workflows. A team can include the appropriate people in a channel to receive all alerts/reports on ads.txt. You can run slash commands to test files straight from Slack as well, complete with GIFs.
GD: Ad Reform is trying to build an “intelligent ad operations assistant.” What do you think is essential in that platform?
LB: We became interested in the ad operations role during our time building website performance monitoring products for publishers (at our last company). As we started digging into the role of ad ops in the organization and their daily activities, we found that a number of those were incredibly manual, repetitive tasks.
These types of tasks are usually better suited for technology/automation so that ad ops pros can spend their time on more impactful work. Let smart people work on hard problems, and let tech take the wheel on everything else.
Our mission is to enable ad operations individuals to be seen as “can’t lose” people in their company by releasing them of all this extra weight. Some of the most brilliant people I’ve talked to in ad tech are in ad ops. Giving them (and engineers) a seat at table could improve the financial outlooks for many publishers.
Ad ops is underserved when it comes to technology. Our platform will be capable of tasks such as: ad screenshots, ads.txt testing, ad tag QA/troubleshooting (we’re working on another freemium product here), programmatic testing (in the wild), and a Slack bot tied directly to ad ops platforms (e.g. DFP).
From a company perspective, we’re bootstrapped and profitable, but in the process of raising an angel round to accelerate product development and continue supporting our growing customer base. We’re also hiring at our HQ in Atlanta (had to plug that)!
GD: Automating screenshots may seem straightforward, but it can actually be quite the technical challenge. Why is this such an important tool for the moment?
LB: Our first product (ad screenshots) solves a problem that has gotten more challenging with the rise of programmatic and deeper targeting parameters. Finding an ad in the wild for a certain campaign, on a certain device, is nearly impossible these days. We simplify this.
Screenshots are a requirement from many agencies/brands, but it’s an activity that provides little to no ROI for the publisher, DSP or trade desk. Spending time on something that has little ROI is not the best use of your time. Take back your time and let us do the screenshots.
GD: Even though DSPs are just starting to crawl the ads.txt files, there’s some chatter about what’s next—do you think the following iteration will embrace an ID system? What would be the upsides and downsides?
LB: We spent a lot of time reading about ads.txt as we built out AdstxtValidator.com, and we can certainly see opportunities for improvement. A more structured, standard transport format (e.g. JSON) would greatly improve the flexibility of the ads.txt format. The lightweight nature of text files is great, but this approach makes parsing, adding/removing fields, and other common changes trickier.
Extending the system to incorporate IDs would certainly help as well. It could be tough to rally everyone around a more centralized approach, but it would be useful to be able to identify partners and publishers across systems. Another approach might be to provide a standard for ad systems to share their system expectations. With this in place, validators could ensure that an ads.txt record for a given ad system is valid.