Best practices to ensure error-free ads.txt
4 steps to make sure ads.txt errors don’t slip through the cracks when making changes to your files
Since launching our free Ads.txt Validator at the end of 2017, one thing we’ve noticed is how many files have IAB spec issues. We’ve seen data showing that anywhere from 15–30% of ads.txt files from the Alexa top 30,000 have spec issues. Of the thousands of sites that have been run through our tool, we’ve actually seen that number closer to 50% (of the urls tested). Clearly, publishers are having problems staying compliant as they make constant partner changes, and we’ve documented some of those common compliant issues in the past. As a follow up post, we wanted to lay out some best practices for building a process around ads.txt changes.
1. Name an owner
As with any project or team, you need someone to own ads.txt. This is a perfect opportunity to give more responsibilities to an up and comer, as it will help them develop additional leadership/project management skills.
2. Build a cross-departmental team
Now that you have an ads.txt owner/team lead it, a good next step would be to create a cross departmental team. The two teams that will be dealing with ads.txt files are engineering/dev and ad operations. There will likely be lots of handoffs between the two groups. As with any sort of cross functional team, it would be wise to organize docs, files, communication in one place. Creating a Slack channel or Trello board is always a good first step.
3. Test early and often
My co-founder and I came from the wonderful world of DevOps, where we built tools to monitor the performance (user experience) of websites and applications. We worked with many DevOps teams who built testing processes (many of which were automated, using tools like ours, Speedcurve, Selenium, and New Relic). Any DevOps team would tell you that the key to maintaining optimal performance, and lowering the the chance of issues leaking into production (live site), is by testing early and often. This means automating testing before you deploy to production so that you can resolve the inevitable issues before your users experience them. The same goes for ads.txt files because you’re constantly making changes to the files. See an example from the trends we show you in our validator:
This publisher added 32 new ad partners to their file, and in doing so, introduced 4 new errors →
Who knows how long they’ve had these issues on the site, or how much revenue this could be costing them. If they would have tested before deploying these changes live to the site they would have identified these issues much quicker. At Ad Reform we offer an API to allow engineers to build validation into their deploy/CI process. We also offer weekly monitoring and the ability to upload/test an ads.txt file before it’s live on the site.
4. Document changes
As with any project/initiative/testing, it’s important to document everything. Keep track of changes you make to your file in a spreadsheet, and organize by date. Do the same with your ads.txt validations. We automatically save every validation for our users (ordered by date/time), including the source (API, file upload, Slackbot) and status (valid ✅, has warnings🤔, or has errors😭):
Again, make sure every member of your team has easy access to this documentation.
One size never fit’s all, but this is a good starting point. With so many ads.txt files with errors, publishers would do well to implement some sort of process around something that will continue to be more important to your revenue. What else? What other processes are your teams employing?
