IAB Tech Lab recently released a new version of the ads.txt standard for comment. This 1.1 update defines two new variables — OWNERDOMAIN and MANAGERDOMAIN — that attempt to solve some outstanding issues with how seller relationships are expressed.

While these new variables provide useful extra data points, I’m concerned they won’t achieve the wide adoption necessary to make a meaningful difference, and that some of the additions are moving the standard in the wrong direction.

OwnerDomain

OWNERDOMAIN allows a site to declare who owns it by specifying the owner’s “business domain”. While this can just be the site domain, it’s often different, particularly when a company owns multiple different sites. For example, Gizmodo could add OWNERDOMAIN=g-omedia.com to their ads.txt, indicating they’re owned by G/O Media.

A site’s OWNERDOMAIN can be compared with an ad account’s domain from its sellers.json entry to determine if they have the same owner. This will be helpful in checking if a PUBLISHER account is actually a valid seller for a particular site, for example.

A related use case is determining whether an account labelled BOTH in sellers.json is acting as a PUBLISHER or INTERMEDIARY on a given site. If the site’s OWNERDOMAIN matches the account’s domain, it’s acting as a PUBLISHER; otherwise it’s an INTERMEDIARY.

Intuitively, OWNERDOMAIN should also help in checking if an account is actually DIRECT. However, this isn’t mentioned by the spec (though there is a brief mention in the “Implementation Guide”), and the definition of DIRECT is a fraught topic.

ManagerDomain

MANAGERDOMAIN is similar, but rather than declaring the site’s owner, it declares the company exclusively responsible for managing the site’s ad inventory (if there is one). Different companies can be declared per country if needed.

For example, meetup.com’s ad inventory is managed by Freestar. They could add MANAGERDOMAIN=freestar.com to their ads.txt to indicate this relationship.

A management company’s ad accounts can be identified by comparing account domains to the manager’s domain. As an exclusive manager’s accounts should be the most direct sources of the site’s inventory, this can help with Supply Path Optimisation (SPO).

Note that the spec falls short of saying the manager’s accounts can be labelled DIRECT, however, and they are labelled RESELLER in the implementation guide’s examples.

Adoption and Enforcement

These new variables are only useful in preventing ad fraud if DSPs actually enforce them, e.g. by not buying inventory via PUBLISHER accounts that don’t match a site’s OWNERDOMAIN. But DSPs aren’t going to turn off a large proportion of their supply, so wide adoption is required first.

So what’s the incentive for sites to adopt the new variables if DSPs aren’t using them? DSPs could add validations that only run on sites that provide them, giving some reason for their existence without overly affecting supply. However, this effectively just adds new restrictions to sites that adopt the variables. Sites that are benefiting from the current paucity of validation effectively have an incentive to not add them.

Usually, the ability to say you comply with a spec provides some incentive in itself. However, the spec doesn’t actually require either variable. OWNERDOMAIN is “recommended” and “should” be checked against the domains of PUBLISHER accounts. MANAGERDOMAIN is “optional” and “should” be provided when a manager is used. A site that should provide them can simply not, and still claim they are following the spec. Similarly, a DSP can claim to support the ads.txt spec, but ignore these variables entirely.

Even if a DSP wants to break from the pack and start enforcing them, they aren’t standalone. For example, they need to be compared to account domains, but the account domain field is optional in the sellers.json spec. Currently, more accounts are missing a domain than provide one. Enforcing OWNERDOMAIN and MANAGERDOMAIN requires first enforcing account domains, and that hasn’t happened in the almost 3 years since sellers.json was released.

MANAGERDOMAIN isn’t really enforceable per se — it’s essentially just a SPO hint. The question is more if DSPs will actually meaningful change their buying decisions based on it. SupplyChain objects were released years ago alongside sellers.json, and there’s been little evidence they are being widely used for SPO, or even validated.

It’s also important to note that OWNERDOMAIN and MANAGERDOMAIN are set by sites, and there’s no programmatic way for DSPs to check they’re actually correct. I can think of a few ways this could be exploited by less than virtuous sites (though determining what would work in practice is always difficult).

Owner vs. Site

The definition of OWNERDOMAIN states that it should match the domain of any PUBLISHER accounts — i.e. account domains in sellers.json should be the owner domain, not the site domain. This isn’t a change — it’s essentially what the sellers.json spec already says, though it often isn’t followed currently (see the Gizmodo example above).

However, I’m concerned that this doubles down on the idea that SupplyChain objects should start at the site’s owner, not the site itself. This means that different sites with the same owner can have identical supply chains.

This is a complex issue — see my posts on ads.txt and sellers.json for more details — but the core problem is sites that share supply chains can spoof each other’s ad inventory at will.

When I first wrote about this issue it was just a theoretical possibility, but then I found Gannett doing it (accidentally) in the wild. If they were using SupplyChains that started at the site level, the bug could have been caught by basic SupplyChain validations. Instead, all their sites shared the same supply chains, and no one noticed the issue for 9 months.

Requiring SupplyChains to start at the site level wouldn’t make this kind of authorized domain spoofing impossible — the SupplyChain itself could be spoofed by a malicious actor (or a particularly unfortunate bug) — but that’s a problem with these specs in general, not something specific to this issue.

What makes ads.txt, sellers.json, and SupplyChain objects (potentially) useful is the ability to cross-check data from different sources. A SupplyChain can be checked against other fields provided in the bid request (which are often pulled from different places), the sellers.json entries provided by the ad systems, and the ads.txt file provided by the site.

Not requiring SupplyChains to start at the site level eliminates opportunities to validate the link between the site and the first seller account, and will result in less issues being detected.

Final Thoughts

This ads.txt update only introduces two relatively simple variables, but they slot into a complex web of existing standards, and their often less than stellar implementations. I’ve only touched on what I think are the most important points, but there’s plenty more there to dig into.

One aspect I’ve avoided for brevity (and because I’m not sure how to say it nicely — sorry) is a number of issues that basically boil down to a need for significant copy editing. Key sentences that don’t really make sense, incorrect field names, new terms that seemingly duplicate existing ones, paragraphs that are replicated from elsewhere but with differences, etc. I’ve tried to avoid being pedantic in this post, but if pedantry is ever required it’s when you’re writing specifications.

OWNERDOMAIN patches one of the holes in validating DIRECT PUBLISHER accounts, but others remain. MANAGERDOMAIN helps break the DIRECT/RESELLER binary, if DSPs will use it. Adoption and enforcement will be key, but that’s exactly where the existing specs have faltered. Unfortunately, I don’t see anything in this update that would fundamentally change that.

Finally, ads are displayed on sites. Ad inventory supply chains should start at the site.