Unterstützung für Mehrfachkundenauktionen mit Protected Audience Mediation

bookmark_border Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Sell-Side-Werbeplattformen diversifizieren in der Regel ihre Quellen für Anzeigennachfrage, um den Werbeumsatz zu optimieren. Bei der Werbenetzwerk-Vermittlung ruft ein Werbenetzwerk oder ein Dienst mehrere Werbenetzwerke auf, um die beste Anzeige für einen bestimmten Anzeigenblock zu ermitteln. In diesem Vorschlag wird beschrieben, wie die Protected Audience API auf Android-Geräten erweitert werden kann, um die Vermittlungsabfolge auf datenschutzfreundliche Weise zu implementieren. Heutzutage bieten Werbenetzwerke App-Entwicklern verschiedene Möglichkeiten, Anzeigenauktionen von mehreren Anzeigenverkäufern zu vermitteln:

1. Abfolgebasierte Vermittlung: App-Entwickler definieren eine sortierte Liste von Werbenetzwerken, die häufig nach bisherigen eCPMs für das jeweilige Netzwerk sortiert wird. Diese Liste wird als Vermittlungsabfolge bezeichnet. Die Vermittlungsplattform des App-Entwicklers ruft anhand dieser Liste Werbenetzwerke in der Reihenfolge auf, in der sie aufgeführt sind, um relevante Anzeigennachfragequellen zu ermitteln.
2. Programmatic Mediation: Der App-Entwickler konfiguriert mehrere Werbenetzwerke, damit sie an Geboten für Anzeigenaufträge teilnehmen können. Diese Netzwerke dürfen in Echtzeit Gebote abgeben, je nachdem, wie sie die jeweilige Gelegenheit bewerten.
3. Hybride Vermittlung: Eine Kombination aus abfolgebasierter und programmatischer Vermittlung.

Vermittlungsabfolge

Bei der abfolgebasierten Vermittlung sendet ein Anzeigen-SDK bei einer Anzeigenbereitstellung eine Anfrage an seinen Back-End-Server. Anstatt auf die Anfrage mit einem ausgewählten Creative zu antworten, antwortet der Server mit einer Vermittlungskette, die eine Liste von Werbenetzwerken enthält, die nach dem bisherigen eCPM sortiert ist.

Abbildung 1. Das abfolgebasierte Vermittlungsmodell.

Beim traditionellen abfolgebasierten Modell ruft ein Anzeigen-SDK jedes Werbenetzwerk (oder sein eigenes Auktions-SDK) in der durch die Vermittlungskette angegebenen Reihenfolge auf. Wenn ein Werbenetzwerk die Anzeigenanfrage erfüllen kann, rendert es die Anzeige. Andernfalls wird die Anfrage an das nächste Netzwerk in der Kette gesendet. Dieser Vorgang wird wiederholt, bis die Anfrage erfüllt ist oder die Kette erschöpft ist.

Die abfolgebasierte Vermittlung wird häufig optimiert, indem die Vermittlungsabfolge regelmäßig neu angeordnet wird. Dabei wird der eCPM aus selbst erhobenen Daten zu Anzeigennachfragequellen neu bewertet.

Programmatische Vermittlung

Programmatic Mediation (auch als „Header Bidding“ bezeichnet) ist eine Alternative dazu, anhand des bisherigen eCPM zu bestimmen, welches Werbenetzwerk die Möglichkeit erhält, eine Anzeigenanfrage zu bedienen. Bei der programmatischen Vermittlung verwenden Anbieter stattdessen Livegebotswerte, um die Anzeige auszuwählen, die ausgeliefert werden soll.

Abbildung 2:Programmatische Vermittlung

Hybride Vermittlung

Einige Lösungen für die programmatische Vermittlung kombinieren Werbenetzwerke in einem Hybridmodus aus Vermittlungsabfolge und Bidding, um mehr Kontrolle über die Anzeigen zu haben und gleichzeitig die Vorteile von Live-eCPMs zu nutzen, um die Einnahmen aus teilnehmenden Werbenetzwerken zu maximieren.

Bei hybriden Vermittlungsmodellen können Anzeigennetzwerke und Vermittlungsanbieter App-Entwicklern mehr Flexibilität bieten, indem sie Elemente der abfolgebasierten Vermittlung und des Echtzeitgebots kombinieren. Mit Hybridmodellen können App-Entwickler Werbenetzwerke basierend auf bisherigen eCPMs konfigurieren. So haben sie die Möglichkeit, eine Anzeige zu schalten, bevor sie Echtzeitgebote mit teilnehmenden Netzwerken ausführen, um Umsatzchancen zu nutzen.

Vermittlungsabfolge für Protected Audience

Die Protected Audience API auf Android unterstützt die abfolgebasierte Vermittlung durch mehrere Auktionen, jeweils für einen einzelnen Knoten in der Vermittlungsgrafik. Wenn es keinen Gewinner einer Auktion gibt, wird der nächste Netzwerk-Auktionsknoten aufgerufen, bis die Kette erschöpft ist. Die abfolgebasierte Vermittlung funktioniert so:

1. Das Vermittlungs-SDK ruft die Vermittlungskette vom Kontext-Ad-Server-Endpunkt ab, der entweder kontextbezogene Anzeigen oder Vermittlungsketten zurückgeben kann.
2. Wenn der Ad-Server-Endpunkt eine Vermittlungskette zurückgibt, durchläuft das Vermittlungs-SDK die einzelnen Elemente der Kette der Reihe nach und ruft das SDK des teilnehmenden Werbenetzwerks auf, um eine kontextbezogene und Remarketing-Anzeigeauswahl auszuführen. Jeder Artikel in der Kette stellt die Anfrage eines Werbenetzwerks dar, Anzeigenfläche zu einem bestimmten Preis für eine bestimmte Anzahl von Impressionen, Klicks oder Anzeigenzeit zu kaufen.
3. Wenn keine der Werbebuchungen in der Vermittlungskette eine Anzeigenauswahl trifft, kann das Vermittlungs-SDK eine Anzeige aus seinem eigenen Werbenetzwerk ausliefern. Dazu wird eine Anzeigenauswahl für geschützte Zielgruppen ausgeführt, bei der sowohl Remarketing- als auch kontextbezogene Anzeigen berücksichtigt werden.

Abbildung 3: abfolgebasierte Vermittlung mit der Protected Audience API

Das obige Diagramm zeigt ein Beispiel für einen abfolgebasierten Vermittlungsalgorithmus, der in einem Vermittlungs-SDK implementiert werden kann, ohne dass das Werbenetzwerk mit selbst erhobenen Daten die Optimierung vornehmen kann. Die Protected Audience API unterstützt die Optimierung von Anzeigennetzwerken mit selbst erhobenen Daten, indem die Verknüpfung von Workflows für die Anzeigenauswahl und die Berichterstellung über erfolgreiche Impressionen ermöglicht wird.

Ergebnis der Anzeigenauswahl

Der Rückgabetyp von selectAds() ist ein AdSelectionOutcome-Objekt. AdSelectionOutcome enthält den Render-URI der ausgewählten Anzeige und eine AdSelectionId, eine nicht transparente Ganzzahl, die das Creative der ausgewählten Werbebuchung identifiziert.

AdSelectionOutcome {
  Uri renderUri;
  Long AdSelectionId;
}

AdSelectionId fungiert als Verweis auf die AdSelectionOutcome. Derzeit wird AdSelectionId als Parameter ReportImpressionInput an die Methode reportResult() übergeben, um die richtigen Anzeigen zu identifizieren, für die die Methoden reportWin() und reportResult() aufgerufen werden.

Vorschlag für die Anzeigenauswahl in einer Kette

Wir schlagen vor, selectAds() mit AdSelectionFromOutcomesConfig zu überladen.

val config = AdSelectionFromOutcomesConfig.Builder()
        .setSeller(seller)
        .setAdSelectionIds(listOf(outcome1pAdSelectionId))
        .setSelectionSignals({"bid_floor": bidFloorOfNextNetworkInline})
        .setSelectionLogicUri(selectionLogicUri)
        .build()
adSelectionClient.selectAds(config)

So kann das Mediation SDK das Gebot der Gewinneranzeige mit dem Mindestgebot des nächsten Inline-Werbenetzwerks vergleichen.

Beispiel 1:

Beispiel 2:

Impressionen mit der höchsten Anzahl von Anzeigen erfassen

Wenn es einen Gewinner aus selectAds(AdSelectionFromOutcomes) gibt, gewinnt diese Anzeige die Vermittlung. Anschließend wird reportImpression mit der Anzeigenauswahl-ID der erfolgreichen Anzeige aus selectAds(AdSelectionFromOutcomes) und der entsprechenden AdSelectionConfig aufgerufen.

Wenn der Gewinner von einem selectAds(AdSelectionConfig) für eines der Netzwerke zurückgegeben wird, wird reportImpression mit der Anzeigenauswahl-ID und der Konfiguration aus diesem Aufruf aufgerufen.

Vermittlungsabfolge ausführen

Hier ist die Reihenfolge der Abläufe für die abfolgebasierte Vermittlung:

1. Verwenden Sie die Anzeigenauswahl auf Grundlage selbst erhobener Daten.
2. Für die Vermittlungskette iterieren. Gehen Sie für jedes Drittanbieternetzwerk so vor:
   1. AdSelectionFromOutcomeConfig erstellen, einschließlich des outcomeId für selbst erhobene Daten und des Gebotsgrenzwerts des Drittanbieter-SDKs
   2. Rufe selectAds() mit config aus dem vorherigen Schritt auf.
   3. Wenn das Ergebnis nicht leer ist, geben Sie die Anzeige zurück.
   4. Rufen Sie die Methode selectAds() des aktuellen SDK-Netzwerkadapters auf. Wenn das Ergebnis nicht leer ist, geben Sie die Anzeige zurück.
3. Wenn in der Kette kein Gewinner gefunden wird, geben Sie die selbst erhobenen Anzeigen zurück.

Best Practices

Kontextbezogene Gebote vor der Optimierung mit selbst erhobenen Daten ausführen

Die Nachfrage nach Remarketing kann hohe Gebote generieren, die in einer Vermittlungskette zu erfolgreichen Ergebnissen führen können. Die Kürzung wird häufig verwendet, um die Optimierung selbst erhobener Daten zu ermöglichen, indem die Remarketing-Zielgruppenliste verfeinert wird.

Die Remarketing-Nachfrage der Protected Audience API ist nur clientseitig und bei Protected Audience-Auktionen verfügbar. Das kann die serverseitige Optimierung selbst erhobener Daten erschweren. Um Probleme mit der Optimierung mit selbst erhobenen Daten zu vermeiden, führen Sie zuerst die kontextbezogene Auktion durch und führen Sie dann die Optimierung mit selbst erhobenen Daten basierend auf dem Gewinner des Anzeigenergebnisses aus, wie oben auf dieser Seite beschrieben.

On-Device-Vermittlungsketten klein halten

Für eine optimale Leistung sollten On-Device-Vermittlungsketten klein gehalten werden. Die Berechnungskosten für die On-Device-Ausführung können linear mit der Anzahl der Auktionen ansteigen, die im Rahmen der Vermittlungskette ausgewertet werden. Mit anderen Worten: Mehr Knoten bedeuten mehr Rechenzyklen und eine höhere Latenz. Berücksichtigen Sie die Auswirkungen der Latenz auf den Umsatz, wenn Sie Knoten an die On-Device-Vermittlungsbewertung weitergeben.

Weitere Überlegungen

Die Protected Audience API bietet keine umfassende Lösung für die Vermittlung mehrerer Anzeigenflächen. Jede Anzeigenfläche muss unabhängig voneinander verarbeitet werden.

Die Protected Audience Mediation API unterstützt die abfolgebasierte Vermittlung und die eingeschränkte programmatische Vermittlung. Weitere Informationen zur Unterstützung zusätzlicher Anwendungsfälle für die programmatische Vermittlung folgen in Zukunft.

Da die Auswahl von Protected Audience-Anzeigen nach dem Abrufen von kontextbezogenen Anzeigen erfolgt, kann die Aufrufung der Protected Audience API die End-to-End-Latenz von Anzeigenanfragen beeinträchtigen.