Transparente Einblicke in den Gebotsprozess mit dem SupplyChain-Objekt

Mit dem SupplyChain-Objekt können Käufer und Mittler alle Parteien sehen, die Anzeigeninventar verkaufen oder weiterverkaufen. In Kombination mit ads.txt/ads.txt und ads.txt sorgt das Objekt für Transparenz im Werbesystem.

1. Der Publisher sendet eine Gebotsanfrage.
2. Der Käufer erhält die Gebotsanfrage und die zugehörigen Daten über das SupplyChain-Objekt.
3. Der Käufer prüft die Identitäten aller Mittler, die Inventar weiterverkaufen.
4. Der Käufer crawlt und prüft die Anbieter, die für das Verkaufen von Inventar autorisiert sind.

Die Objekte werden von Google automatisch in einer OpenRTB-Anfrage erstellt, sofern relevant.

Funktionsweise des SupplyChain-Objekts

Das SupplyChain-Objekt, das auch als schain bezeichnet wird, ist Teil einer OpenRTB-Gebotsanfrage und besteht aus „Knoten“.Jeder Knoten des schain-Objekts steht für eine bestimmte Partei, die an der Gebotsanfrage teilnimmt. Dazu gehören alle Parteien, die am direkten Zahlungsfluss für Inventar beteiligt sind.

Tipp : Damit Google ein vollständiges SupplyChain-Objekt erstellen kann, müssen übergeordnete Nutzer, die die Option „Inventar verwalten“ im Publisher-Verwaltungstool nutzen, die Verkäufer-ID (sid) der untergeordneten Publisher über Ad Manager oder die API angeben.

 

// 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"
}

Weitere Informationen finden Sie in der Entwicklerdokumentation zu OpenRTB und in der IAB-Dokumentation (beide in englischer Sprache).

Je nach Art Ihrer Zusammenarbeit mit Käufern ist das SupplyChain-Objekt unterschiedlich aufgebaut.

Publisher, die direkt über Google verkaufen

Bei Publishern, die Inventar direkt über Ad Manager, AdMob oder AdSense verkaufen, enthält das schain-Objekt nur einen Knoten für google.com mit der seller_id aus der Datei „sellers.json“.

Publisher, die Open Bidding verwenden

Bei Publishern, die über Open Bidding mit Drittanbieter-Anzeigenplattformen zusammenarbeiten, enthält das schain-Objekt zwei Knoten: einen für google.com mit der seller_id aus der Datei „sellers.json“ und einen für den Ertragspartner der Anzeigenplattform.

So wie Google den Knoten für google.com erstellt, bevor die Gebotsanfrage gesendet wird, ist die Drittanbieter-Anzeigenplattform dafür verantwortlich, ihren Knoten hinzuzufügen, bevor die Anfrage weitergegeben wird.

Alle Mittler, die nicht am Zahlungsprozess beteiligt sind

Mittler, die keine Zahlungen bearbeiten, sind nicht im SupplyChain-Objekt enthalten. Dazu gehören clientseitiges Header Bidding, Header Bidding ohne Zahlung, Inventarfreigabe und andere Vermittlungsformen.

Publisher, die Zahlungsvermittler vor der Anfrage verwenden ^(Beta) 

Diese Funktion befindet sich in der Betaphase
Funktionen in der Betaphase sind in Ihrem Netzwerk möglicherweise nicht verfügbar. In den Versionshinweisen erfahren Sie, wann diese Funktion für alle Nutzer verfügbar wird.

Publisher, die vor der Anfrage an Google Ad Manager Zahlungsvermittler nutzen, müssen gemäß den IAB-Richtlinien das SupplyChain-Objekt übergeben. Das SupplyChain-Objekt sollte nur Vermittler enthalten, die direkt am Zahlungsfluss für das Inventar beteiligt sind. Zu diesen Vermittlern kann auch die Ad-Server-Technologie eines Drittanbieters gehören, die vom Publisher verwendet wird. Das SupplyChain-Objekt kann in der Anzeigenanfrage mit dem Parameter schain gesendet werden.

Weitere Informationen zum Parameter „schain“

Beschreibung

Für den Lieferkettenparameter (schain) kann ein Wert vom Typ Variable verwendet werden, der ein serialisiertes SupplyChain-Objekt sein sollte. Wenn dieser Parameter enthalten ist, hängt Google an alle empfangenen schain-Objekte vor dem Senden an Käufer einen Knoten an.

In der vollständigen IAB-Dokumentation erfahren Sie, wie Sie SupplyChain-Informationen über ein Tag (anstelle von OpenRTB) senden.

Anforderungen für das korrekte Parsing von schain

Basierend auf der IAB-Dokumentation wird die Serialisierung für das SupplyChain-Objekt so definiert:

• {SupplyChainObject}!{SupplyChainNode array}. SupplyChainObject und SupplyChainNode-Properties sind kommagetrennt, sodass optionale Felder weggelassen und Kommatrennzeichen dafür optional ausgeschlossen werden können.
• Die einzelnen SupplyChainNode-Elemente werden durch ein "!" getrennt.
• Wenn der Wert einer Property Zeichen enthält, die eine URL-Codierung erfordern (z. B. "," oder "!"), muss der Wert vor der Serialisierung URL-codiert werden.

Serialisierungsreihenfolge

Die SupplyChainObject-Properties werden in dieser Reihenfolge serialisiert:

ver,complete

Die SupplyChainNode-Properties werden in dieser Reihenfolge serialisiert:

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

Hinweis: Der Inhalt von ext ist für die Anzeigenplattform spezifisch. Diese Property wird in Google Ad Manager nicht geparst.

Beispiele für die Serialisierung des SupplyChain-Objekts

Im Folgenden finden Sie zwei Beispiele für die Serialisierung des oben genannten SupplyChain-Objekts:

Leere optionale Felder mit Kommas serialisieren

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

Leere optionale Felder ohne Kommas serialisieren

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

Weitere Informationen zum SupplyChain-Objekt

Verwendungsbeispiele

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

Wenn asi den Wert exchange,1 hätte, würde die Serialisierung mit Escape-Zeichen so aussehen:

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

Anforderungen und Empfehlungen

Dieser Parameter ist zwar nicht erforderlich, um Anzeigen für eine bestimmte Implementierung oder einen bestimmten Transaktionstyp auszuliefern, aber für Publisher, die vor der Anfrage an Google Ad Manager Zahlungsvermittler nutzen. Dies gilt auch für Publisher, die Ad-Server-Technologien eines Drittanbieters verwenden.

 

Hinweis: Alle zusätzlichen Knoten, die dem SupplyChain-Objekt angehängt werden, müssen auch in der ads.txt-/app-ads.txt-Datei eines Publishers enthalten sein. Andernfalls betrachten Käufer den Traffic möglicherweise als nicht autorisiert.

Publisher, die das Publisher-Verwaltungstool verwenden

Mit dem Publisher-Verwaltungstool können übergeordnete Publisher Einnahmen über das Inventar von untergeordneten Publishern erzielen. Das ist entweder einzeln mit dem Delegationstyp „Konto verwalten“ möglich oder in größerem Umfang mit dem Delegationstyp „Inventar verwalten“.

Für Partner mit dem Delegationstyp „Konto verwalten“

Bei über- und untergeordneten Publishern, die Konto verwalten verwenden, enthält das schain-Objekt einen einzelnen Knoten mit der Verkäufer-ID des untergeordneten Publishers und ist als vollständig markiert. Bei Publishern mit der Berechtigung „Konto verwalten“ erfolgt die Monetarisierung im Konto des untergeordneten Publishers. Der untergeordnete Publisher wird als End-Publisher behandelt. Das schain-Objekt enthält keine Angaben zum übergeordneten Publisher.

Für Partner mit dem Delegationstyp „Inventar verwalten“

Das SupplyChain-Objekt ist jetzt für Publisher, die die Option Inventar verwalten im Publisher-Verwaltungstool nutzen, als vollständig markiert. Im Publisher-Verwaltungstool gibt es 1 Knoten für untergeordnete und 1 Knoten für übergeordnete Nutzer und das SupplyChain-Objekt wird als vollständig markiert.

Im Rahmen dieser Aktualisierung müssen übergeordnete Publisher im Publisher-Verwaltungstool über das Ad Manager-Front-End oder die API die Verkäufer-ID (SID) ihrer untergeordneten Publisher teilen. 

Beispiel für das vollständige SupplyChain-Objekt

In diesem Beispiel sehen Sie das SupplyChain-Objekt für einen untergeordneten und einen übergeordneten Nutzer im Publisher-Verwaltungstool mit Google als Anzeigenplattform.

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

// Knoten für den untergeordneten Publisher im Publisher-Verwaltungstool
        {
            "asi":"mcm-parent-example.com",  // Dies ist ein Beispiel. Geben Sie die tatsächliche Domain des übergeordneten Publishers ein. 
            "sid":"52e41fac28963d1e058a106f", // Verkäufer-ID des untergeordneten Nutzers in der seller.json-Datei des übergeordneten Nutzers
            "hp":1,
        },

// Knoten für den übergeordneten Nutzer im Publisher-Verwaltungstool
        {
            "asi":"google.com",
            "sid":"pub-1234567891234567", // Publisher-ID des übergeordneten Nutzers in der seller.json-Datei von Google
            "hp":1,
        }
    ]
}

Häufig gestellte Fragen

Warum müssen übergeordnete Publisher im Publisher-Verwaltungstool eine sellers.json-Datei erstellen?

Wenn die Informationen der Partner in einer sellers.json-Datei öffentlich zugänglich sind, hilft das Anzeigenkäufern dabei, ihr Inventar zu überprüfen. 

Weitere Informationen zur IAB-Spezifikation für sellers.json

Müssen alle untergeordneten Publisher eine gültige ads.txt-Datei haben?

Ja. Untergeordnete Publisher müssen im Rahmen des Einladungsprozesses im Publisher-Verwaltungstool eine ads.txt-Datei einrichten, um die Inhaberschaft für jede Website zu bestätigen, die ihnen gehört und die sie betreiben. 

Die ads.txt-Datei des untergeordneten Publishers enthält keine Zeile, in der der übergeordnete Nutzer im Publisher-Verwaltungstool als DIRECT angegeben ist (z. B. MCM-parent-example.com, Verkäufer-ID für den untergeordneten Nutzer im Publisher-Verwaltungstool, DIRECT), sondern nur die Google-Zeile mit der Publisher-ID des übergeordneten Publishers (z. B. google.com, PUB ID für den übergeordneten Nutzer im Publisher-Verwaltungstool, RESELLER, f08c47fec0942fa0). Hat das negative Auswirkungen auf den Umsatz? Ist das SupplyChain-Objekt vollständig?

Das SupplyChain-Objekt wird als vollständig markiert, aber Käufer betrachten den Traffic möglicherweise als „nicht autorisiert“, weil ein Knoten enthalten ist, auf dem die Website in der ads.txt-Datei nicht als autorisierter Verkäufer aufgeführt ist. Sie müssen die ads.txt-Datei so konfigurieren, dass der übergeordnete Publisher im Publisher-Verwaltungstool als DIRECT angegeben wird (z. B. MCM-parent-example.com, Verkäufer-ID für den untergeordneten Publisher im Publisher-Verwaltungstool, DIRECT), um diese Fehler zu vermeiden.