Primis’ co-CEO Rotem Shaul recently proposed replacing the Ads.txt standard with Ads.json. This proposal attempts to help publishers understand what companies they are authorizing to sell or resell their ad inventory, making it easier for them to keep their files accurate and up to date.
But the proposal comes with some major problems, and its benefits can be largely achieved in a far simpler way – by reformatting existing ads.txt files.
The problem with JSON
Ads.txt is a simple plaintext file that is specifically designed to be easy to manually update. Each entry is a standalone line, so a formatting mistake only affects that line, not the whole file.
In contrast, JSON is a highly brittle format, mostly used to pass data between computer programs. While it is relatively human-readable, it is not reliably human-writable. If a single character is out of place – e.g., an extra trailing comma in a list of company names – the entire file is rendered invalid and unusable.
The difficulty of writing valid JSON is evident with sellers.json files. Of the 1.2K live sellers.json files, dozens are unusable due to JSON syntax errors at any given time – 34 at time of writing. As publishers are often less technically savvy than the supply-side ad tech companies hosting sellers.json files, ads.json is likely to have a significantly higher error rate.
A change to JSON is antithetical to the goal of making it easier for publishers to update these files.
Authorized seller inflation
Ads.json also switches from authorizing specific seller accounts to authorizing selling relationships between ad tech companies. In ads.txt, you might authorize a seller account 123 with ssp-b.com as a reseller. You’d then have to look up that account in ssp-b.com’s sellers.json to find out it’s owned by ssp-a.com.
ssp-b.com, 123, RESELLER
In ads.json, you would simply authorize ssp-a.com to resell to ssp-b.com.
{
“seller_name”: “ssp-a.com”,
“relationship”: “reseller”,
“paths”: [“ssp-b.com”]
}
However, ad tech companies often own dozens or even hundreds of seller accounts with other companies, which they use to resell different subsets of their supply. So while the ads.json version is easier to understand, it is not equivalent to the ads.txt version. It doesn’t just authorize seller account 123. It also authorizes every other seller ssp-a.com owns (or will ever own) with ssp-b.com.
Why is this a problem? The primary purpose of ads.txt is to fight domain and app spoofing fraud by allowing publishers to limit the number of accounts that can sell their ad inventory. It is fundamentally a mechanism to minimize attack surface. The fewer sellers authorized, the lower the risk a fraudster can find a way to route spoofed inventory to an authorized seller. Conversely, the more sellers authorized, the higher the risk.
By forcing publishers to authorize more sellers than necessary, ads.json would directly reduce the spoofing protections provided by ads.txt, undermining its core utility.
A simpler way
The main benefits promised by the ads.json proposal don’t actually derive from the shift to JSON, nor the change in how sellers are authorized. Rather, they come from listing the companies that own the sellers in the file. This can be done without any changes to the ads.txt standard.
Unlike JSON, ads.txt files support comments. A “#” character starts a comment that will be ignored by parsers, allowing publishers to annotate their files.
# This is a comment
ssp-b.com, 123, RESELLER # This is also a comment
By grouping sellers by their owners and providing the ownership information for each group in a comment, we can effectively replicate the structure and benefits of the ads.json proposal.
Here is the example from Primis’ column in ads.txt form, extended slightly to make use of more ads.txt features:
OWNERDOMAIN=example-publisher.com
# Accounts owned by example-publisher.com:
sellerX.com, 123, DIRECT
MANAGERDOMAIN=sellerX.com
# Accounts owned by sellerX.com:
google.com, 456, RESELLER
openx.com, 789, RESELLER
pubmatic.com, abc, RESELLER
rubiconproject.com, def, RESELLER
triplelift.com, ghi, RESELLER
# Accounts owned by triplelift.com:
indexexchange.com, jkl, RESELLER
smartadserver.com, mno, RESELLER
Existing ads.txt files can be reformatted in this way with automated tools, much in the same way tools would be required to migrate ads.txt files to ads.json.
Reformatted files are entirely backwards compatible, so publishers can format their ads.txt files if and when they would like to, and no change is required from anyone else who consumes these files.
Once sellers are grouped in this way, publishers can add and remove sellers from each group much like they would with ads.json. If they’re unsure who owns a particular new seller (and don’t want to look it up manually), they can add it anywhere in their file and simply run it through a formatter again.
To test this idea, I built an ads.txt formatter and made it freely available on Well-Known.dev. If you maintain a large ads.txt file, give it a try and see if you find it useful.
“Data-Driven Thinking” is written by members of the media community and contains fresh ideas on the digital revolution in media.
Follow HUMAN Collective and AdExchanger on LinkedIn.
