Bid transparency with the SupplyChain object

The SupplyChain object enables buyers and intermediaries to see all parties who are selling or reselling ad inventory. The object works together with ads.txt / app-ads.txt and sellers.json to provide transparency into the ads ecosystem.

  1. Publisher sends a bid request.
  2. Buyer receives bid request and data from the SupplyChain object.
  3. Buyer looks up the identities of all intermediaries who resell inventory.
  4. Buyer crawls and verifies vendors authorized to sell inventory.

Google will automatically create the objects within an OpenRTB request or Google RTB protocol, if applicable.

How the SupplyChain object works

The SupplyChain object, otherwise known as schain, is a part of an OpenRTB bid request and consists of "nodes." Each node in the schain object represents a specific entity participating in the bid request, which includes all entities involved in the direct flow of payment for inventory.

// Example object
"schain": {
    "complete": 1,
    "nodes": [{
         "asi":"google.com",
         "sid":"pub-1234567891234567", // Same seller_id for the publisher in sellers.json
         "hp":1
    }],
    "ver":"1.0"
}

Read OpenRTB's developer documentation and IAB's documentation for further details.

The SupplyChain object looks different depending on the way you work with buyers.

Publishers who sell directly with Google

For publishers who sell inventory directly through Ad Manager, AdMob, or AdSense, the schain object contains only one node for "google.com" with the seller_id found in sellers.json.

Publishers who use Open Bidding

Publishers who use Open Bidding to work with third-party exchanges have two nodes in the schain object: one node for google.com with the seller_id found in sellers.json and one node for the exchange yield partner.

Just as Google creates the node for google.com before sending the bid request, the third-party exchange is responsible for adding their node before passing on the request.

All non-payment intermediaries

Intermediaries that don't handle payment are not included in the SupplyChain object. This includes client-side header bidding, non-payment header bidding, inventory sharing, and other mediation.

Publishers who use payment intermediaries prior to the request

Publishers leveraging payment intermediaries upstream of the request to Google Ad Manager are required to pass the SupplyChain object per the IAB guidelines. The SupplyChain object should only contain intermediaries that are directly involved in the flow of payment for the inventory. Such intermediaries may include third-party ad server technology used by the publisher.  The SupplyChain object can be sent in the ad request using the schain parameter.

Note: Any additional nodes appended to the SupplyChain object should also be represented on a publisher's ads.txt/app-ads.txt file, otherwise buyers might consider the traffic unauthorized.

Publishers who use Multiple Customer Management

Multiple Customer Management (MCM) enables parent publishers to monetize child publishers’ inventory either individually with the Manage Account delegation type, or at scale with the Manage Inventory delegation type.

For Manage Account partners

For parent and child publishers using Manage Account, the schain object will have one node with the child publisher’s seller ID and the chain will be marked complete. For Manage Account publishers, monetization occurs in the child publisher’s account. The child publisher is treated as the end publisher. The parent publisher’s information is not included in the schain object.

For Manage Inventory partners

The SupplyChain Object is now marked complete for MCM Manage Inventory publishers. There is 1 node for MCM child publishers, 1 node for MCM parents, and the chain is marked complete.

This update requires MCM Manage Inventory parents to share the Seller ID (SID) of their child publishers via the Ad Manager frontend or API. 

Example of the complete SupplyChain Object

This example shows the SupplyChain Object marked complete for an MCM child and parent, with Google as the exchange.

"schain" : {
    "ver": "1.0",
    "complete" : 1,
    "nodes" : [

// Node for MCM child publisher
        {
            "asi":"mcm-parent-example.com",  // This is an example. Be sure to enter the parent's actual domain. 
            "sid":"52e41fac28963d1e058a106f", // Child’s seller ID within parent’s seller.json
            "hp":1,
        },

// Node for MCM MI parent
        {
            "asi":"google.com",
            "sid":"pub-1234567891234567", // MCM parent’s publisher ID within Google’s seller.json
            "hp":1,
        }
    ]
}

FAQ

Why do MCM parents need to create a sellers.json file?

Making partners’ information publicly available by allowing their information to be listed in the sellers.json file is an important step in helping ad buyers verify their inventory. 

Learn more about the IAB sellers.json spec.

Do all my child publishers need to have a valid ads.txt file?

Yes. As part of the MCM child invitation process, child publishers set up an ads.txt file to verify the site ownership for every site they own and operate. 

If the child publisher’s ads.txt doesn't include a line listing the MCM Parent as DIRECT (for example MCM-parent-example.com, Seller-ID for the MCM child, DIRECT), but it lists the Google line with the parent’s publisher ID (for example google.com, PUB ID for the MCM parent, RESELLER, f08c47fec0942fa0), will there be any negative impact on revenue? Will the supply chain be complete?

The supply chain will be marked as complete, but buyers may consider the traffic "unauthorized" because there is a node in the SupplyChain where the site has not listed as an authorized seller in ads.txt. Updating the ads.txt file to include the MCM Parent as DIRECT (for example MCM-parent-example.com, Seller-ID for the MCM child, DIRECT) is a required step to avoid these errors.

 

 

 

Was this helpful?

How can we improve it?
Search
Clear search
Close search
Main menu
6042497476087194958
true
Search Help Center
true
true
true
true
true
148
false
false