Transparence des enchères avec l'objet SupplyChain

L'objet SupplyChain permet aux acheteurs et aux intermédiaires d'identifier toutes les parties qui vendent ou revendent un inventaire publicitaire. Cet objet fonctionne en conjonction avec les fichiers ads.txt/app-ads.txt et sellers.json afin d'apporter de la transparence à l'écosystème publicitaire.

L'éditeur envoie une demande d'enchère.
L'acheteur reçoit la demande d'enchère et les données associées depuis l'objet SupplyChain.
L'acheteur examine les identités de tous les intermédiaires qui revendent l'inventaire.
L'acheteur explore et valide les vendeurs autorisés à vendre l'inventaire.

Google créera automatiquement les objets dans une requête OpenRTB ou via le protocole Google RTB, le cas échéant.

Fonctionnement de l'objet SupplyChain

L'objet SupplyChain, également appelé schain, fait partie d'une demande d'enchère OpenRTB et se compose de "nœuds". Chaque nœud de l'objet schain représente une entité spécifique participant à la demande d'enchère, qui inclut toutes les entités impliquées dans le flux de paiement direct pour l'inventaire.

// Exemple d'objet "schain": { "complete": 1, "nodes": [{ "asi":"google.com", "sid":"pub-1234567891234567", // seller_id identique pour l'éditeur dans sellers.json "hp":1 }], "ver":"1.0" }

Pour en savoir plus, consultez la documentation d'OpenRTB destinée aux développeurs et la documentation de l'IAB.

L'objet SupplyChain prend différentes formes selon la manière dont vous travaillez avec les acheteurs.

Éditeurs qui vendent directement avec Google

Pour les éditeurs qui vendent leur inventaire directement via Ad Manager, AdMob ou AdSense, l'objet schain ne contient qu'un nœud pour "google.com" avec le seller_id figurant dans le fichier sellers.json.

Éditeurs qui utilisent Open Bidding

Pour les éditeurs qui utilisent Open Bidding pour travailler avec des places de marché tierces, l'objet schain compte deux nœuds : un premier pour google.com avec le seller_id figurant dans le fichier sellers.json, et un deuxième pour le partenaire de rendement.

De la même manière que Google crée le nœud pour google.com avant d'envoyer la demande d'enchère, la place de marché tierce doit ajouter son nœud avant de transmettre la demande.

Tous les intermédiaires hors paiement

Les intermédiaires qui ne gèrent pas le paiement, y compris les enchères d'en-tête ("header bidding") côté client, les enchères d'en-tête hors paiement et autre médiation, ne sont pas inclus dans l'objet SupplyChain.

Éditeurs qui utilisent Multiple Customer Management

Multiple Customer Management (MCM) permet aux éditeurs parents de monétiser l'inventaire des éditeurs enfants soit individuellement avec le type de délégation "Gérer le compte", soit à grande échelle avec le type de délégation "Gérer l'inventaire".

Pour les partenaires avec la délégation "Gérer le compte"

Pour les éditeurs parents et enfants qui utilisent Gérer le compte, l'objet schain comportera un nœud avec l'ID de vendeur de l'éditeur enfant, et la chaîne sera marquée comme complète. Pour les éditeurs qui utilisent "Gérer le compte", la monétisation a lieu dans le compte de l'éditeur enfant. L'éditeur enfant est considéré comme l'éditeur final. Les informations sur l'éditeur parent ne sont pas incluses dans l'objet schain.

Pour les partenaires avec la délégation "Gérer l'inventaire"

L'objet SupplyChain est désormais marqué comme complet pour les éditeurs MCM qui utilisent Gérer l'inventaire. Il existe un nœud pour les éditeurs enfants MCM, un nœud pour les éditeurs parents MCM, et la chaîne est marquée comme étant complète.

Cette mise à jour exige que les parents MCM qui utilisent "Gérer l'inventaire" partagent l'ID de vendeur (SID) de leurs éditeurs enfants via l'API ou l'interface Ad Manager.

Exemple d'objet SupplyChain complet

Cet exemple illustre l'objet SupplyChain marqué comme complet pour un enfant et un parent MCM, avec Google comme place de marché.

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

// Nœud pour l'éditeur enfant MCM
{
"asi":"mcm-parent-example.com", // Ceci est un exemple. Veillez à saisir le véritable domaine du parent.
"sid":"52e41fac28963d1e058a106f", // ID de vendeur de l'enfant dans le fichier seller.json du parent
"hp":1,
},

// Nœud pour le parent avec la délégation "Gérer l'inventaire" de l'outil MCM
{
"asi":"google.com",
"sid":"pub-1234567891234567", // Référence éditeur du parent MCM dans le fichier seller.json de Google
"hp":1,
}
]
}

Questions fréquentes

Pourquoi les parents MCM doivent-ils créer un fichier sellers.json ?

Rendre publiques les informations des partenaires en autorisant leur affichage dans le fichier sellers.json est une étape importante pour aider les acheteurs d'annonces à valider leur inventaire.

En savoir plus sur les spécifications du fichier sellers.json de l'IAB

Tous mes éditeurs enfants doivent-ils disposer d'un fichier ads.txt valide ?

Oui. Pour inviter un enfant dans MCM, les éditeurs enfants configurent un fichier ads.txt afin de valider la propriété de chaque site qu'ils détiennent et gèrent.

Si le fichier ads.txt de l'éditeur enfant n'inclut pas de ligne indiquant le parent MCM comme DIRECT (par exemple, MCM-parent-example.com, ID de vendeur pour l'enfant MCM, DIRECT), mais qu'il indique la ligne Google avec la référence éditeur du parent (par exemple, google.com ou référence éditeur pour le parent MCM, REVENDEUR, f08c47fec0942fa0), cela aura-t-il un impact négatif sur les revenus ? La chaîne d'approvisionnement sera-t-elle complète ?

La chaîne d'approvisionnement sera marquée comme complète, mais les acheteurs pourront considérer le trafic comme "non autorisé", car il existe un nœud dans la chaîne d'approvisionnement où le site n'est pas listé comme un vendeur autorisé dans le fichier ads.txt. Mettre à jour le fichier ads.txt afin d'inclure le parent MCM comme DIRECT (par exemple, MCM-parent-example.com, ID de vendeur pour l'enfant MCM, DIRECT) est une étape obligatoire pour éviter ces erreurs.

Ces informations vous-ont elles été utiles ?

Comment pouvons-nous l'améliorer ?