Unterstützung für Mehrfachkundenauktionen mit Protected Audience Mediation

Sell-Side-Werbeplattformen diversifizieren in der Regel ihre Anzeigenquellen, um den Werbeumsatz zu optimieren. Bei der Anzeigenvermittlung ruft ein Werbenetzwerk oder ‑dienst mehrere Werbenetzwerke auf, um die beste Anzeige für eine bestimmte Anzeigenfläche zu ermitteln. In diesem Vorschlag wird beschrieben, wie die Protected Audience API für Android erweitert werden kann, um die Wasserfall-Vermittlung datenschutzfreundlich zu implementieren. Werbenetzwerke bieten App-Entwicklern heute verschiedene Möglichkeiten, Anzeigenauktionen von mehreren Anzeigenverkäufern zu vermitteln:

1. Abfolgebasiertes Vermittlungsverfahren: App-Entwickler definieren eine sortierte Liste von Werbenetzwerken, die häufig nach bisherigen eCPMs für das jeweilige Netzwerk sortiert werden. Diese Liste wird als Mediationskette bezeichnet. Die Vermittlungsplattform des App-Entwicklers verwendet diese Liste, um Werbenetzwerke in der angegebenen Reihenfolge aufzurufen und relevante Anzeigenquellen zu ermitteln.
2. Programmatische Vermittlung: Der App-Entwickler konfiguriert mehrere Werbenetzwerke, die an Geboten für Anzeigenmöglichkeiten teilnehmen. Diese Netzwerke dürfen in Echtzeit Gebote abgeben, die auf ihrer Einschätzung der jeweiligen Gelegenheit basieren.
3. Hybrid-Vermittlung: Eine Kombination aus Wasserfall- und programmatischen Vermittlungstechniken.

Abfolgebasierte Vermittlung

Bei der Vermittlung in Wasserfallform wird bei einer Anzeigenmöglichkeit eine Anfrage von einem Anzeigen-SDK an den zugehörigen Back-End-Server gesendet. Anstatt auf die Anfrage mit einem Creative für die Gewinneranzeige zu antworten, antwortet der Server mit einer Vermittlungskette, die eine Liste von Werbenetzwerken enthält, die nach dem bisherigen eCPM sortiert sind.

Abbildung 1. Das Modell der abfolgebasierten Vermittlung.

Im serverseitigen Wasserfallmodell ruft ein Anzeigen-SDK jedes Werbenetzwerk (oder sein eigenes Auktions-SDK) in der Reihenfolge auf, die in der Vermittlungskette angegeben ist. Wenn ein Werbenetzwerk die Anzeigenanfrage erfüllen kann, wird die Anzeige gerendert. Andernfalls wird die Anfrage an das nächste Netzwerk in der Kette gesendet. Dieser Vorgang wird wiederholt, bis die Anfrage erfüllt oder die Kette erschöpft ist.

Die abfolgebasierten Vermittlung wird häufig optimiert, indem die Vermittlungskette regelmäßig neu angeordnet wird. Grundlage dafür ist die erneute Bewertung des eCPM von Anzeigenquellen mit eigener Nachfrage.

Programmatische Vermittlung

Die programmatische Vermittlung (auch als „Header Bidding“ bezeichnet) ist eine Alternative zur Verwendung des bisherigen eCPM, um zu bestimmen, welches Werbenetzwerk eine Anzeigenanfrage bearbeiten darf. Bei der programmatischen Vermittlung verwenden Anbieter stattdessen Live-Gebotswerte, um die Gewinneranzeige zu ermitteln.

Abbildung 2:Das programmatische Vermittlungsmodell

Hybride Vermittlung

Bei einigen programmatischen Vermittlungslösungen werden Werbenetzwerke in einem Hybridmodus aus Vermittlungsabfolge und Bidding kombiniert. So haben Sie mehr Kontrolle über die Anzeige und können gleichzeitig von der Verwendung von Live-eCPMs profitieren, um die Einnahmen aus teilnehmenden Werbenetzwerken zu maximieren.

In hybriden Vermittlungsmodellen können Werbenetzwerke und Vermittlungsanbieter App-Entwicklern mehr Flexibilität bieten, indem sie Elemente von Wasserfall und Echtzeitgebotsverfahren kombinieren. Mit Hybridmodellen können App-Entwickler Werbenetzwerke basierend auf bisherigen eCPMs konfigurieren. So haben sie die Möglichkeit, eine Anzeige zu präsentieren, bevor sie Echtzeitgebote mit teilnehmenden Netzwerken ausführen, um Umsatzchancen zu nutzen.

Vermittlungsabfolge für Protected Audience

Die Protected Audience API unter Android unterstützt die abfolgebasierte Vermittlung durch mehrere Auktionen, jeweils für einen einzelnen Knoten im Vermittlungsdiagramm. Wenn es keinen Gewinner aus einer Auktion gibt, wird der nächste Knoten für die Netzwerkauktion aufgerufen, bis die Kette erschöpft ist. So funktioniert die Wasserfall-Vermittlung:

1. Das Vermittlungs-SDK ruft die Vermittlungskette vom Endpunkt des kontextbezogenen Ad-Servers ab. Dieser kann entweder kontextbezogene Anzeigen oder Vermittlungsketten zurückgeben.
2. Wenn der Ad-Server-Endpunkt eine Vermittlungskette zurückgibt, durchläuft das Vermittlungs-SDK jedes Element der Kette in der Reihenfolge und ruft das SDK des beteiligten Werbenetzwerks auf, um eine kontextbezogene und Remarketing-Anzeigenauswahl durchzuführen. Jedes Element in der Kette steht für die Anfrage eines Werbenetzwerks, Werbefläche zu einem bestimmten Preis für eine bestimmte Anzahl von Impressionen, Klicks oder Anzeigenzeit zu kaufen.
3. Wenn für keine der Werbebuchungen in der Kette eine Gewinneranzeige ausgewählt wird, kann das Vermittlungs-SDK eine Anzeige aus dem eigenen Werbenetzwerk präsentieren. Dazu wird eine Protected Audience-Anzeigenauswahl ausgeführt, bei der sowohl Remarketing- als auch kontextbezogene Anzeigen berücksichtigt werden.

Abbildung 3: Wasserfall-Vermittlung mit der Protected Audience API

Das obige Diagramm zeigt ein Beispiel für einen Wasserfall-Vermittlungsalgorithmus, der von einem Vermittlungs-SDK implementiert werden kann, ohne dass das eigene Werbenetzwerk optimiert werden kann. Die Protected Audience API unterstützt die Optimierung von Erstanbieter-Werbenetzwerken, indem sie die Verkettung von Anzeigenauswahl-Workflows und das Melden von gewonnenen Impressionen ermöglicht.

Ergebnis der Anzeigenbereitstellung

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

AdSelectionOutcome {
  Uri renderUri;
  Long AdSelectionId;
}

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

Vorschlag für die Auswahl von Kettenanzeigen

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 Vermittlungs-SDK das Gebot der Gewinneranzeige mit dem Mindestgebot des nächsten Netzwerks vergleichen.

Beispiel 1:

Beispiel 2:

Gewonnene Impressionen melden

Wenn es einen Gewinner aus selectAds(AdSelectionFromOutcomes) gibt, gewinnt diese Anzeige die Vermittlung. Anschließend wird reportImpression mit der Anzeigen-Auswahl-ID der erfolgreichen Anzeige aus selectAds(AdSelectionFromOutcomes) und dem 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.

Abfolgebasierte Vermittlung ausführen

So gehen Sie bei der Vermittlung mit Wasserfall vor:

1. Eigene Anzeigenauswahl ausführen
2. Vermittlungskette durchlaufen Gehen Sie für jedes Drittanbieternetzwerk so vor:
   1. Erstellen Sie AdSelectionFromOutcomeConfig, einschließlich des Mindestgebots für eigene Daten outcomeId und des Mindestgebots des Drittanbieter-SDK.
   2. Rufen Sie selectAds() mit dem 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 Anzeige des Erstanbieters zurück.

Best Practices

Kontextbezogene Auktionen vor der Optimierung mit eigenen Daten ausführen

Durch Remarketing-Nachfrage können hohe Gebote generiert werden, die in einer Vermittlungskette zu erfolgreichen Ergebnissen führen können. Die Kürzung ist ein Verfahren, das häufig verwendet wird, um die Optimierung von Daten aus erster Hand zu ermöglichen, indem die Remarketing-Zielgruppenliste verfeinert wird.

Die Remarketing-Nachfrage der Protected Audience API ist nur clientseitig mit Protected Audience-Auktionen verfügbar. Das kann es schwierig machen, die Optimierung von Erstanbieterdaten auf der Serverseite zu aktivieren. Um Probleme mit der Optimierung auf Grundlage von eigenen Daten zu vermeiden, führen Sie zuerst die kontextbezogene Auktion aus und optimieren Sie dann auf Grundlage von eigenen Daten, wie weiter oben auf dieser Seite beschrieben.

On-Device-Vermittlungsketten kurz halten

Für eine optimale Leistung sollten On-Device-Vermittlungsketten kurz gehalten werden. Die Rechenkosten für die Ausführung auf dem Gerät können linear in Bezug auf die Anzahl der Auktionen sein, die im Rahmen der Vermittlungskette ausgewertet werden. Mit anderen Worten: Mehr Knoten führen zu mehr Anforderungen an den Rechenzyklus und zu einer erhöhten Latenz. Berücksichtigen Sie die Auswirkungen der Latenz auf den Umsatz, wenn Sie Knoten an die On-Device-Vermittlungsbewertung übergeben.

Weitere Überlegungen

Die Protected Audience API bietet keine umfassende Lösung für die Vermittlung mehrerer Anzeigenflächen. Jede Anzeigenfläche muss unabhängig 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 programmatischer Vermittlungsanwendungsfälle werden in Zukunft bekannt gegeben.

Da die Auswahl von Protected Audience-Anzeigen erfolgt, nachdem kontextbezogene Anzeigen abgerufen wurden, kann sich der Aufruf der Protected Audience API auf die End-to-End-Latenz von Anzeigenanfragen auswirken.