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.

1. L'éditeur envoie une demande d'enchère.
2. L'acheteur reçoit la demande d'enchère et les données associées depuis l'objet SupplyChain.
3. L'acheteur examine les identités de tous les intermédiaires qui revendent l'inventaire.
4. 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.

Les éditeurs qui utilisent des intermédiaires de paiement avant la demande

Les éditeurs qui utilisent des intermédiaires de paiement en amont de la demande envoyée à Google Ad Manager doivent transmettre l'objet SupplyChain, conformément aux consignes de l'IAB. L'objet SupplyChain ne doit contenir que les intermédiaires directement impliqués dans le flux de paiement de l'inventaire. Ces intermédiaires peuvent inclure la technologie d'ad server tiers utilisée par l'éditeur.  L'objet SupplyChain peut être envoyé dans la demande d'annonce à l'aide du paramètre "schain".

Remarque : Tout nœud supplémentaire ajouté à l'objet SupplyChain doit également être représenté dans le fichier ads.txt/app-ads.txt d'un éditeur, sinon les acheteurs pourraient considérer le trafic comme non autorisé.

Éditeurs Multiple Customer Management

L'outil MCM (Multiple Customer Management) permet aux éditeurs de gérer les comptes AdMob de leurs clients avec une visibilité optimale et un contrôle maximum.

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