SCO validation and verification
The SupplyChain object (SCO) is part of the OpenRTB bid request. It lists every entity involved in selling an ad impression, from the publisher through each seller and reseller. Pixalate checks SCOs in two ways: validation confirms the SCO is well formed, and verification confirms that each seller it declares is authorized. You can run these checks per bid request with the SCO Validation & Verification API, or review them across your traffic in the Analytics SCO reports.
Video (2 min): how SCO validation differs from verification.
What the SupplyChain object is
The SCO is an IAB Tech Lab supply chain transparency standard. It works alongside two other IAB Tech Lab standards, ads.txt (and app-ads.txt for apps) and sellers.json, to show who is involved in selling the inventory in a bid request.
An SCO is made up of a set of nodes. Each node represents one entity that takes part in selling the ad placement. The full chain, from first node to last, represents every entity involved in the direct flow of payment for the inventory.
Each node has two required properties:
asi(advertising system identifier): the domain name of the advertising system.sid(seller ID): identifies the seller of the inventory, that is, who the advertising system pays for it.
The asi and sid should be the same values the publisher lists in its ads.txt or app-ads.txt file. A seller ID must map to only one entity that is paid for inventory sold with that ID. One selling entity can have several seller IDs within an advertising system.
The SCO also carries chain-level fields, including its version (ver) and a complete flag that declares whether the chain is complete.
Validation and verification
Verification checks each node against two sources:
- sellers.json: for each node, the upstream node matches the seller’s sellers.json entry.
- ads.txt or app-ads.txt: for each node, the publisher has authorized that seller. The first seller must be listed as
DIRECT, and the sellers after it asRESELLER.
When a check fails, Pixalate reports a reason or error code. See SCO error and reason codes.
Why verification matters
Ad supply chains involve many sellers and resellers, which makes them hard to understand. The SCO was designed to bring transparency, but it can also be faked, and without verification that goes unnoticed. Verifying SCOs helps you:
- Improve SCO structural quality by finding SCOs that are malformed or incorrect, and fixing them.
- Find unauthorized sellers and resellers, entities attempting unauthorized ad arbitrage, and block them.
- Find inaccurate chain relationships and block those sellers.
- Find potentially spoofed impressions, where an entity sells impressions from one source while claiming they come from a more valuable one.
- Reduce IVT. Pixalate has observed higher invalid traffic (IVT) rates on SCOs that fail validation or verification.
Where to use it
To send the SCO to Pixalate through the Analytics tag, see The Pixalate tag and macros.
Glossary
Supply chain object (SCO)
The OpenRTB SupplyChain object: a set of nodes, each representing an entity that takes part in selling an ad placement. The full chain represents every entity involved in the direct flow of payment for the inventory.
Node
One entity in the SCO. A node has two required properties: the advertising system identifier (asi) and the seller ID (sid).
sellers.json
A published, accessible file that lets buyers discover the entities that are either direct sellers of, or intermediaries in, the sale of its inventory. Verification checks that, for each node, the upstream node matches the sellers.json entry.
ads.txt and app-ads.txt
Files publishers publish to declare which entities are authorized to sell their inventory: ads.txt for websites, app-ads.txt for apps. Verification checks that, for each node, the publisher has authorized that seller.
SCO validation
Confirming the SCO’s structure is correct: it can be parsed and contains all required fields.
SCO verification
Confirming the data in the SCO is accurate and legitimate, by checking each node against the corresponding ads.txt, app-ads.txt and sellers.json entries.
Seller
In the Analytics SCO reports, the numeric ID of the partner you’re buying supply from. It’s passed in a separate macro, not in the SCO, so it’s different from a node’s seller ID (sid).
Seller type
The position an entity holds in the SCO. For example, the developer of an app is shown as PUBLISHER, and a seller or reseller as INTERMEDIARY.
Seller domain
The owner domain of the publisher, seller or reseller listed in the SCO. For example, an app by a developer whose website is example.com has the seller domain example.com.
Valid chain
An SCO in correct OpenRTB format, with all nodes and correct IDs included, that is declared complete. In the Analytics SCO reports, a Valid SCO is a complete chain in which every node passed with the correct seller and advertising system IDs, and each entity has the correct seller type.
Incomplete chain
An SCO with a node missing or not passed correctly. An SCO without the complete flag is also marked incomplete.
Reason and error codes
The codes Pixalate reports when an SCO fails validation or verification, for example when the chain is incomplete or a node is missing. More than one code can apply to the same SCO. See SCO error and reason codes.
Direct seller not authorized
The first seller in the SCO isn’t listed as a DIRECT seller in the publisher’s ads.txt or app-ads.txt.
Related
Questions? Email support@pixalate.com.