Transparența sumelor licitate cu obiectul SupplyChain

Cu ajutorul obiectului SupplyChain, cumpărătorii și intermediarii pot vedea toate părțile implicate care vând sau distribuie inventar publicitar. Obiectul funcționează împreună cu ads.txt / app-ads.txt și sellers.json pentru a oferi transparență în ecosistemul publicitar.

1. Editorul trimite o solicitare de sumă licitată.
2. Cumpărătorul primește solicitări de sumă licitată și date de la obiectul SupplyChain.
3. Cumpărătorul caută identitatea tuturor intermediarilor care distribuie inventarul.
4. Cumpărătorul accesează cu crawlere și verifică furnizorii autorizați să vândă inventarul.

Google va crea automat obiectele într-o solicitare OpenRTB sau într-un protocol LTR Google, dacă este cazul.

Cum funcționează obiectul SupplyChain

Obiectul SupplyChain, cunoscut și ca schain, face parte dintr-o solicitare de sumă licitată OpenRTB și conține „noduri”. Fiecare nod din obiectul schain reprezintă o anumită entitate care participă la solicitarea de sumă licitată, care include toate entitățile implicate în fluxul de plată direct pentru inventar.

Sfat: pentru ca Google să creeze un obiect SupplyChain complet, coordonatorii MCM pentru Gestionarea inventarului trebuie să trimită codul de vânzător (sid) al editorilor secundari prin Ad Manager sau folosind API-ul.

 

// Exemplu de obiect
"schain": {
    "complete": 1,
    "nodes": [{
         "asi":"google.com",
         "sid":"pub-1234567891234567", // Același seller_id pentru editorul din sellers.json
         "hp":1
    }],
    "ver":"1.0"
}

Consultați documentația pentru dezvoltatori OpenRTB și documentația IAB pentru mai multe informații.

Obiectul SupplyChain arată diferit în funcție de modul în care colaborați cu respectivii cumpărători.

Editori care vând direct cu Google

În cazul editorilor care vând inventar direct prin Ad Manager, AdMob sau AdSense, obiectul schain conține un singur nod pentru „google.com” cu seller_id aflat în sellers.json.

Editori care folosesc Open Bidding

Editorii care folosesc Open Bidding pentru a lucra cu servicii terță parte de schimburi publicitare au două noduri în obiectul schain: un nod pentru google.com cu seller_id aflat în sellers.json și un nod pentru partenerul de randament pentru schimburi.

Așa cum Google creează nodul pentru google.com înainte de a trimite solicitarea de sumă licitată, serviciul terță parte este responsabil pentru adăugarea propriului nod înainte de a transmite solicitarea.

Toți intermediarii care nu gestionează plăți

Intermediarii care nu gestionează plăți nu sunt incluși în obiectul SupplyChain. Aici este inclusă licitarea din antet la nivel de client, licitarea din antet fără plăți, trimiterea de inventar și alte tipuri de mediere.

Editorii care folosesc intermediari de plăți înainte de solicitare ^(Beta) 

This feature is in Beta
Features in Beta phase might not be available in your network. Watch the release notes for when this feature becomes generally available.

Editorii care folosesc intermediari de plăți înainte de solicitarea către Google Ad Manager trebuie să transmită obiectul SupplyChain conform regulamentului IAB. Obiectul SupplyChain trebuie să conțină numai intermediari implicați direct în fluxul de plată pentru inventar. Printre astfel de intermediari se poate număra tehnologia terță a serverului de anunțuri folosită de editor. Obiectul SupplyChain poate fi trimis în solicitarea de anunț folosind parametrul schain.

Aflați mai multe despre parametrul schain

Descriere

The supply chain (schain) parameter accepts a variable value which should be serialized SupplyChain object. When this parameter is included, Google appends a node to any received schain objects prior to sending to buyers.

See the full IAB documentation for communicating SupplyChain information via a tag (rather than OpenRTB).

See requirements for schain to be parsed correctly

Based on the IAB documentation, the following defines the serialization for the SupplyChain object:

• {SupplyChainObject}!{SupplyChainNode array}. SupplyChainObject and SupplyChainNode properties are comma delimited such that optional fields can be omitted and comma separators for which can be optionally excluded.
• Each SupplyChainNode element is separated by a "!".
• If the value of any property contains characters that require URL encoding (for example "," or "!"), the value should be URL encoded before serialization.

Serialization order

SupplyChainObject properties are serialized in this order:

ver,complete

SupplyChainNode properties are serialized in this order:

asi,sid,hp,rid,name,domain,ext

Note: The contents of ext are exchange specific. Google Ad Manager does not parse this property.

Examples of how to serialize the SupplyChain object

Below are two examples of ways to serialize the above SupplyChain object:

Serialize with commas for empty optional fields

1.0,1!exchange1,12345,1,bid-request-1,publisher1,publisher1.com!google.com,pub-12345678910,1,,,,

Serialize without commas for empty optional fields

1.0,1!exchange1,12345,1,bid-request-1,publisher1,publisher1.com!google.com,pub-12345678910,1

Learn more about the SupplyChain object.

Usage examples

schain=1.0,1!exchange1,12345,1,bid-request-1,publisher1,publisher1.com!google.com,pub-12345678910,1,,,,

If the value for asi were exchange,1, then the serialization with escaped characters would look like:

1.0,1!exchange%2C1,12345,1,bid-request-1,publisher1,publisher1.com!google.com,pub-12345678910,1

Requirements and recommendations

While this this parameter is not required to serve ads to any specific implementation or transaction type, it is required for publishers leveraging payment intermediaries upstream of the request to Google Ad Manager. This includes publishers who use third-party ad server technology.

 

Notă: nodurile suplimentare adăugate la obiectul SupplyChain trebuie să fie reprezentate și în fișierul ads.txt / app-ads.txt al editorului. În caz contrar, cumpărătorii pot considera traficul neautorizat.

Editori pentru Gestionarea mai multor clienți

Cu ajutorul instrumentului Gestionarea mai multor clienți (MCM), editorii pot să gestioneze conturile AdMob ale clienților cu aceeași vizibilitate și control ca și în cazul editorilor.

În cazul editorilor principali și secundari care folosesc MCM de la AdMob, obiectul schain va avea un nod cu codul de vânzător al editorului secundar și va fi marcat ca fiind complet. În cazul MCM de la AdMob, generarea de bani are loc în contul editorului secundar. Editorul secundar este considerat editorul final. Informațiile editorului principal nu sunt incluse în obiectul schain.