Werbeplattformen erstellen (Übersicht)

Dieser Artikel bietet einen Überblick über eine mehrteilige Serie zum Erstellen von Werbeplattformen in Google Cloud. Da diese Plattformen sich aus vielen unterschiedlichen Diensten zusammensetzen und auf viele verschiedene Nutzer ausgelegt sind, werden in dieser Reihe gemeinsam genutzte und spezifische Infrastrukturoptionen behandelt.

Aufbau der Reihe

Die Reihe baut auf zwei Hauptgrundlagen auf:

Terminologie

Die folgenden Begriffe werden in der gesamten Serie und allgemein in der Werbebranche verwendet:

  • Anzeigeninventar: Die Anzeigenflächen, die Käufern angeboten werden.
  • Anzeigenfläche: Der Bereich auf einer Webseite oder mobilen Seite, auf der die Anzeige angezeigt wird.
  • Anzeigen-Tag: Ein kurz gehaltener Code mit den Parametern, die die Anzeigenfläche beschreiben.
  • Ad-Server: Von Ad Serving-Plattformen verwendete Technologie, mit der Creatives für die Anzeigenflächen auf den Properties eines Publishers bereitgestellt werden. Ad-Server umfassen in der Regel Funktionen wie Auswahl, Zählung und Bereitstellung von Creatives.
  • Werbetreibender: Organisationen, die direkt oder über andere Käufer in verschiedenen Medien für ein Produkt werben möchten.
  • Zielgruppe: Die (einzelnen) Nutzer, die die Property eines Publishers nutzen.
  • Zielgruppensegment: Eine Auswahl, die auf einer Teilmenge der Taxonomie beruht und eine Gruppe (einzelner) Nutzer zum Ergebnis hat, auf die Werbetreibende sich konzentrieren können.
  • Käufer: Kauft Anzeigenflächen, um darauf Creatives zu platzieren. Käufer können Netzwerke, Agenturen oder Werbetreibende sein.
  • Conversion: Von einem Werbetreibenden vordefinierte Aktion, die ein Nutzer auf der Property eines Werbetreibenden ausführen kann.
  • CPA (Cost-per-Action): Summe, die ein Käufer pro Aktion bezahlt. Aktionen oder Conversions können für verschiedene Ziele eingesetzt werden, z. B. möglichst viele Nutzer zu gewinnen, besonders gute wichtige Kunden zu behalten oder ausgewählte Nutzer dazu zu bringen, ein Produkt auf der jeweiligen Website zu kaufen. Eine Aktion kann das Herunterladen eines Whitepapers, die Anmeldung für einen Newsletter oder der Kauf eines Produkts auf der Website des Werbetreibenden sein.
  • CPC (Cost-per-Click): Summe, die ein Käufer pro Anzeigenklick bezahlt.
  • CPM (Cost-per-Mile): Summe, die ein Käufer pro tausend Impressionen bezahlt.
  • Creative: Anzeige, die dem Zielnutzer präsentiert wird.
  • CTR (Click-through-Rate): Die Anzahl der Klicks geteilt durch die Anzahl der Impressionen.
  • CVR (Conversion Rate): Die Anzahl der Conversions geteilt durch die Anzahl der Impressionen.
  • DMP (Data Management Platform) mit zusätzlichen Nutzerinformationen für Werbetechnologienutzer. Diese Plattformen können den Zugriff auf einen Datendump ermöglichen. In einigen Fällen werden darüber die Daten auf Ihrer Plattform geladen, wenn Sie ihnen den Zugriff auf Objektspeicher wie Cloud Storage gewähren.
  • Impression: Anzeige, die aus der Quelle abgerufen wird und abrechenbar ist.
  • Publisher: Im Kontext dieser Reihe besitzt ein Publisher eine Reihe von digitalen Properties wie Websites oder mobile Apps, die Anzeigenflächen für das Hosten von Creatives bieten.
  • Property (eines Publishers): Website, App oder Spiel, auf bzw. in der der Publisher eine Anzeigenfläche zur Verfügung stellt.
  • Anbieter: Bietet Anzeigenflächen, die zum Verkauf stehen, für mehrere Publisher an.
  • Zielnutzer: Das Ziel der Anzeige bzw. die Person, die sich die Anzeige ansehen soll.
  • Taxonomie: Die Klassifizierung von Zielgruppenattributen, normalerweise in einer Hierarchie.
  • (Einzelner) Nutzer: Ein Nutzer, der als Ziel dienen kann und als einzelner Nutzer bekannt ist oder eingestuft wird. Die Einstufung als einzelner Nutzer ist schwierig und basiert oft auf Vermutungen, da auch mehrere Personen dasselbe Gerät nutzen können oder eine Person verschiedene Geräte verwendet.

Folgende Begriffe beziehen sich auf Echtzeitgebote:

  • Ad Exchange: Ein Marktplatz für Advertising, der Anzeigenanfragen von SSPs erhält. Nach dem Eingang einer Anfrage erwarten die SSPs Anzeigen von allen DSPs mit zugehörigen Geboten, wählen dann ein Gewinnergebot aus und senden es an die Verkäuferseite zurück. Diese Transaktion muss schnell erfolgen. Google wartet z. B. etwa 120 ms auf die Gebote von Käufern.
  • DSP: Demand-Side-Plattformen erhalten eine Anzeigenanfrage, auf die sie innerhalb einer vom SSP oder der Ad Exchange festgelegten Zeit reagieren müssen. Die zulässige Zeit kann zwischen 100 ms und einigen Sekunden liegen. DSPs entscheiden, ob sie ein Gebot abgeben möchten. Falls ja, müssen sie eine Anzeige auswählen, einen Gebotspreis bestimmen und das Angebot an die Ad Exchange zurücksenden.
  • RTB (Echtzeitgebote): Der Prozess, in dem ein Anzeigeninventar (Anzeigeflächen) über eine Onlineauktion programmatischen Käufern angeboten wird.
  • SSP: Supply-Side-Plattformen oder Sell-Side-Plattformen sind manchmal Teil eines Ad-Servers. Sie können aber auch eigenständige Tools darstellen, die Anzeigenanfragen von Publishern oder Ad-Servern erhalten. SSPs senden normalerweise eine Anzeigenanfrage an Ad Exchanges, manchmal jedoch auch direkt an DSPs. Der SSP kann diese Anfrage um zusätzlichen Kontext zur Zielgruppe erweitern (z. B. zu demografischen Gruppen), um den Wert der Anzeigenfläche zu erhöhen. SSPs erwarten den Eingang der Anzeige, die eine Auktion gewonnen hat, und senden diese dann an den Publisher oder Ad-Server zurück.

Weitere Terminologie, die speziell in dieser Reihe verwendet wird:

  • Back-End: Ein Dienst oder eine Datenbank, der bzw. die vom Front-End genutzt wird, um Daten abzurufen oder Verarbeitungsaufgaben auszulagern, z. B. das Training eines Modells für maschinelles Lernen.
  • Kunde: Ein Plattformnutzer, der die von Ihnen bereitgestellte Plattform verwendet.
  • Front-End: Ein Dienst, der externe Anfragen verarbeitet.
  • Funktion: Eine spezifische Fertigkeit, die von einem auf einer Plattform ausgeführten Dienst angeboten wird.
  • Offline: Beschreibt einen beliebigen Prozess, der nicht in Entscheidungen in Echtzeit eingebunden ist.
  • Online: Beschreibt einen beliebigen Prozess, der als Teil eines Echtzeitprozesses ausgeführt werden muss.
  • Plattform: Eine Reihe von Diensten, die eine der Hauptfunktionen übernehmen, z. B die Bereitstellung von Anzeigen, das Anbieten des Inventars und die Abgabe von Geboten.
  • Plattformnutzer: Ein Publisher, Verkäufer, Käufer, Werbetreibender oder anderer Nutzer, der eine Plattform-UI verwendet.
  • QPS: Abfragen pro Sekunde.
  • Dienst: Eine oder mehrere Funktionen, die gemeinsam angeboten werden, in der Regel als eine Anwendung.
  • Worker: Die Instanz eines Dienstes, der eine Aufgabe ausführt. Normalerweise werden mehrere Worker parallel ausgeführt.

Gemeinsam genutzte Komponenten

Verschiedene Werbeplattformen wie Ad-Server, Demand-Side-Plattformen, Supply-Side-Plattformen und Ad Exchanges haben einige funktionale Komponenten, die ähnlich funktionieren, um die folgenden Prozesse zu ermöglichen:

  • Plattformnutzer (Anbieter, Käufer) kommunizieren über eine Front-End-UI mit der Plattform.
  • Anfragen werden verarbeitet, z. B. für eine Anzeige oder ein Gebot.
  • Ereignisse und der Datenlebenszyklus werden verwaltet, z. B. Impressionen, Klicks, Conversions und potenziell auch gewonnene und verlorene Gebote.

Im folgenden Diagramm wird eine Architektur dargestellt, die auf diesen Komponenten beruht:

Architektur von gemeinsam genutzten Komponenten für Werbeplattformen

Nutzer-Front-Ends

Die meisten Werbeplattformen benötigen ein Kunden-Front-End, das normalerweise aus einer UI in Verbindung mit einer oder mehreren verschiedenen Datenbanken besteht. Das Front-End muss die folgenden Anforderungen erfüllen:

  • Es muss möglich sein, global mit einer für Nutzer angemessenen Latenz darauf zuzugreifen.
  • Es muss hochverfügbar sein, damit Kunden ihre Einstellungen jederzeit verwalten können.
  • Es muss der Nachfrage entsprechend skaliert werden und zulassen, dass Nutzer die Plattform nach Belieben und jederzeit nutzen können. (Plattformnutzer befinden sich in verschiedenen Zeitzonen und nutzen ein globales Plattformangebot.)

Abhängig von der jeweiligen Plattform können diese Front-Ends von Anbietern und/oder Käufern verwendet werden und Bestandteil eines Ad-Servers, DSPs, SSPs oder einer Ad Exchange sein. Ein Front-End umfasst unterschiedliche administrative Funktionen und verarbeitet verschiedene Advertising-Ressourcen (Anzeigen-Creatives, Gebote, Anfragen, demografische Gruppen usw.).

Weitere Informationen zu diesen Konzepten finden Sie unter Nutzer-Front-End (in Teil 1).

Anfragen und Anzeigenauswahl

Die Ad-Auswahl erfolgt durch die Plattform, wenn sie eine Anfrage erhält. Anforderungen können Ad-Anfragen sein, die aus einem Ad-Tag im üblichen Anzeigebereitstellungskontext erstellt werden. Es kann sich dabei aber auch um Gebotsanfragen handeln, die von einem SSP oder einer Ad Exchange in einem RTB-Kontext stammen.

Der Teil, von dem eine Anzeige ausgewählt wird, muss folgende Anforderungen erfüllen:

  • Hohe Skalierbarkeit: Anfragen von Werbetechnologie befinden sich oft im Bereich von mehreren Milliarden Anfragen pro Tag.
  • Hohe Verfügbarkeit: Bei den beschriebenen Dimensionen kann eine einzige Sekunde Nichtverfügbarkeit zu fehlgeschlagenen Anfragen führen, die erhebliche Auswirkungen auf die Geschäftstätigkeit haben.
  • Möglichst geringe Latenz: Anzeigen müssen den Zielnutzern so schnell wie möglich angezeigt werden. Dies wirkt sich darauf aus, wie schnell eine Anzeige ausgewählt werden muss. Im RTB-Bereich stellt die Latenz eine sehr wichtige Anforderung dar, da SSPs oder Ad Exchanges darauf angewiesen sind, dass Gebotsantworten innerhalb einer bestimmten Zeit zurückgegeben werden. Diese kann bei nur 100 ms liegen.

Die folgenden Komponenten sind an der Auswahl von Anzeigen beteiligt:

  • Ein Front-End-Dienst, der Anzeigenanfragen erhält.
  • Mindestens ein Datenspeicher, der von Front-Ends verwendet wird, um Entscheidungen zu treffen.
  • Ein Auswahlalgorithmus für die Auswahl der Anzeige.

Unter Verarbeitung von Anfragen (in Teil 1) finden Sie Informationen dazu, wie Front-Ends implementiert werden, während unter Speicherungsmuster für hohe Lesegeschwindigkeit (in Teil 1) die Einbindung des Speichers erläutert wird. Ausführlichere Informationen zu Ad-Servern und RTB-Gebotsfunktionen finden Sie in den entsprechenden Abschnitten in den Artikeln zu Ad-Servern und Gebotsfunktionen (in Teil 4).

DSPs und Ad-Server nutzen eine Anzeigenauswahllogik, um Profile der (einzelnen) Nutzer zu erstellen, nicht relevante Kampagnen und Anzeigen auszufiltern und dann eine Anzeige auszuwählen. Der Auswahlprozess für Gebotsfunktionen umfasst außerdem eine Entscheidung darüber, ob und zu welchem Gebotspreis geboten wird, sowie ggf. eine Optimierung des Gebots. Unter Infrastrukturoptionen für die Bereitstellung von Werbearbeitslasten (in Teil 1) finden Sie entsprechende Links zu beiden Themen.

Ereignisse und Datenverwaltung

Die meisten Entscheidungen, die in einer Werbeplattform getroffen werden, hängen von Daten aus verschiedenen Quellen ab. Dies sind u. a. folgende:

  • Von Ad-Server-Front-Ends empfangene Anzeigenanfragen.
  • Von DSP-Front-Ends empfangene Gebotsanfragen.
  • Von den DSP-Gewinnendpunkten empfangene Gebotsgewinne und -verluste.
  • Impressionsereignisse, die nach der Bereitstellung einer Anzeige für den Zielnutzer generiert wurden. In den meisten Fällen sind Impressionen abrechenbar. Abrechenbare Impressionen werden gerendert und als sichtbar eingestuft.
  • Klickereignisse, die generiert werden, wenn ein Nutzer auf eine Anzeige klickt. Die Anzahl der Ereignisse ist mit hoher Wahrscheinlichkeit um einiges niedriger als die Anzahl der Impressionen.
  • Conversion-Ereignisse, die generiert werden, wenn ein Zielnutzer die erhoffte Aktion auf der Property eines Werbetreibenden ausführt. Die Anzahl der Ereignisse ist mit hoher Wahrscheinlichkeit niedriger als die Anzahl der Anzeigenklicks.
  • Halbstatische Daten, die von Plattformnutzern verwaltet werden.
  • Offlinedaten, die aus der Analyse historischer Ereignisse stammen.
  • Drittanbieterdaten, z. B. Nutzersegmente und damit verknüpfte Preise, die von externen Quellen wie DMPs bereitgestellt werden.

Im Gegensatz zu regelbasierten Systemen ist maschinelles Lernen eine wichtige Komponente, die Modelle mithilfe von historischen Daten offline und mithilfe von Echtzeitdaten online trainieren kann. Diese Modelle können dann lokal bereitgestellt werden, damit einzelne Komponenten oder Dienste wie Ad-Server online Vorhersagen treffen können. Mit diesen Modellen können auch Caches/Speicher für Schlüssel/Wert-Paare gefüllt werden, die bereits getroffene Vorhersagen bereitstellen.

Die Plattform muss folgende Aktionen ausführen können:

  • Täglich Daten im Terabyte-Bereich verarbeiten, die erfasst, aufgenommen, verarbeitet und gespeichert werden sollen.
  • Bei der Erfassung, Aufnahme, Verarbeitung und Speicherung auf Milliarden Ereignisse täglich skalieren.
  • Optionen für Onlineverarbeitung in Echtzeit und Offlineverarbeitung bereitstellen.
  • Verarbeitungsaufgaben ausführen, z. B. maschinelles Lernen in einer verteilten Umgebung.
  • Relevante Daten automatisch an die Informationsdatenbank zurückgeben, entweder in Echtzeit durch Streaming oder später in Batches.

Weitere Erläuterungen zum Verarbeiten von Joins in Gebotsanfragen, Gebotsergebnissen, Impressionen und Klicks finden Sie unter Ereignisse verarbeiten (in Teil 3).

Ad-Server

Ad-Server bestehen im Allgemeinen aus gemeinsam genutzten Komponenten und Funktionen zur Bereitstellung von Anzeigen, wie im folgenden Diagramm dargestellt.

Architektur von Werbeplattformen mit Anzeigenauslieferung

Da die Anzeigenbereitstellung ein zentraler Bestandteil von Ad-Servern ist, müssen dafür folgende Bedingungen erfüllt sein:

  • Niedrige Latenz: Anzeigen müssen schnell bereitgestellt werden, um sicherzustellen, dass die Zielnutzer sie sehen (wenn Scrollen dies ermöglicht) und Anzeigen problemlos von ihnen aufgerufen werden können.
  • Hohe Verfügbarkeit: Nach der Auswahl einer Anzeige wäre es verschwenderisch und kostenintensiv, sie nicht bereitzustellen, weil die Plattform nicht verfügbar ist.
  • Skalierbarkeit: Bei Milliarden Anzeigenanfragen pro Tag müssen viele Plattformen Milliarden entsprechender Anzeigen bereitstellen.

Einige DSPs oder SPS stellen Anzeigen über ihre Infrastruktur bereit. In diesem Artikel wird jedoch davon ausgegangen, dass sie einen Anzeigenserver in ihre Plattform implementiert haben. Weitere Informationen zum Bereitstellen von Anzeigen finden Sie unter Ausgewählte Anzeige für Zielnutzer bereitstellen (in Teil 3).

Gebotsfunktionen

Der Bietprozess wird unter Infrastrukturoptionen für RTB-Gebotsfunktionen (Teil 4) ausführlich beschrieben.

DSPs bestehen im Allgemeinen aus gemeinsam genutzten Komponenten mit den folgenden Anforderungen:

  • Gebotsantworten müssen innerhalb eines festgelegten Zeitlimits zurückgegeben werden, sodass die Latenz ein kritischer Punkt ist.
  • Gebote werden pro Gebotsanfrage berechnet. Dies führt zu einer komplexen Anzeigenauswahllogik. Die zusätzliche Logik im Algorithmus wird normalerweise von einem speziellen Gebotsdienst verarbeitet. Weitere Informationen finden Sie unter Gebote abgeben (in Teil 4).

Im folgenden Diagramm wird eine allgemeine Übersicht über eine Demand-Side-Plattform dargestellt.

Allgemeine Übersicht über eine Demand-Side-Plattform

Nächste Schritte