The SupplyChain Object standard is the pinnacle of the IAB Tech Lab’s suite of Supply Chain Transparency standards. It enables (app-)ads.txt protections and sellers.json seller transparency to be extended to the whole supply chain by exposing all the seller accounts a bid request has passed through on the way to the buyer. SupplyChain Objects (schains) can be used to detect unauthorized domain and app spoofing wherever it occurs in the supply chain, attribute fraud schemes to specific actors, and optimize supply paths.
Validating a schain is a complex process, involving a range of comparisons between the schain, other fields in the bid request, and data from (app-)ads.txt and sellers.json files. If one piece of data is missing or slightly wrong, the whole schain is invalid. This requirement for precision across data from a range of sources is a double-edged sword: it makes it more difficult for bad actors to construct fraudulent inventory that will pass muster, but also means any small mistake can make legitimate inventory appear invalid.
With that in mind, let’s look at how SupplyChain Object adoption and compliance is going four years after release.
To start with, HUMAN is only seeing schains on 79% of requests. For web inventory, it’s actually relatively high at 94%, but only 62% of app inventory (mobile apps and CTV) has an schain. That’s a large adoption gap.
But how good are the schains that are provided? The following stats are based on bid requests protected by HUMAN’s MediaGuard, covering requests between October 23rd and 29th where schains were available:
|
% of web bid requests |
% of app and CTV bid requests |
% of all bid requests |
|
|
Schain Declared Complete |
99% |
97% |
98% |
|
Schain Valid |
49% |
31% |
42% |
The vast majority of schains are declared complete, which is a good start. However, it’s unclear if they actually are complete, as the majority of them fail validation. For app inventory, almost 70% of schains are invalid.
We can break down schain validation into three main parts: authorization, transparency, and consistency:
- A schain is authorized if all the sellers listed in it are (app-)ads.txt authorized.
- A schain is transparent if all the sellers have sellers.json entries that include a seller domain.
- A schain is consistent if it describes a valid chain of sellers from the publisher to the current seller.
Note that publishers have to opt-in to (app-)ads.txt, so inventory from publishers that haven’t adopted it are excluded from schain authorization rates.
|
% of web bid requests |
% of app and CTV bid requests |
% of all bid requests |
|
|
(App-)Ads.txt Adopted |
98% |
69% |
87% |
|
Schain Authorized |
93% |
84% |
90% |
|
Schain Transparent |
92% |
87% |
90% |
|
Schain Consistent |
52% |
33% |
44% |
While ads.txt adoption and authorization rates for web inventory are relatively high, the same can’t be said for app inventory. Even excluding the 31% of app inventory that hasn’t adopted app-ads.txt, only 84% of app inventory has schains are fully authorized.
Only 90% of schains are fully transparent. This is relatively consistent across web and app, though web is doing slightly better.
Consistency is by far the lowest metric. Just over 50% of web inventory schains are consistent, and app inventory schains are worse at just over 30% consistent. Note that without complete sellers.json data, a schain can’t be checked for consistency, so a non-transparent schain is considered inconsistent.
We can break this down further into internal and external consistency:
- Internal consistency checks that there are no missing links in the chain - the ad system domain of one seller should match the seller domain of the next. It also checks that intermediary sellers have the correct seller type - i.e. INTERMEDIARY or BOTH.
- External consistency checks the first and last sellers. The first seller of a complete schain should be owned by the publisher, so it should have a PUBLISHER (or BOTH) seller type, and its seller domain should match the site or app’s OWNERDOMAIN. The last seller should match the seller account currently selling the bid request.
|
% of web bid requests |
% of app and CTV bid requests |
% of all bid requests |
|
|
Schain Internally Consistent |
89% |
91% |
90% |
|
Schain Externally Consistent |
59% |
37% |
50% |
Internal consistency is a significant issue at only 90%, but external consistency is the biggest driver of validation failures. Only 59% of web inventory schains and 37% of app inventory schains are externally consistent.
Given it’s unlikely that over 50% of inventory is fraudulent, it’s clear that large amounts of legitimate inventory have gaps or errors in their SupplyChain Object implementations. As with the other Supply Chain Transparency standards, this prevents buyers from being able to trust SupplyChain Validation results, allowing fraud to continue hiding in the noise.
Further, the only way to detect schain tampering is with comprehensive validation (though even a fully valid schain isn’t guaranteed to be accurate). All these invalid schains can't be reliably used for fraud attribution or supply path optimization.
The SupplyChain Object standard promises to be a valuable tool, but we’re currently far from being able to use it to its full potential. While there are a lot of different issues that need to be addressed, here are the most impactful actions publishers and SSPs can take to start closing the gaps:
- Add complete schains to all bid requests,
- Adopt app-ads.txt across all mobile app and CTV inventory,
- Authorize all sellers in the supply chain, not just final sellers,
- Check seller types and domains listed in sellers.json files,
- Add OWNERDOMAINs to (app-)ads.txt files, and ensure they match PUBLISHER seller domains.
