Infrastrukturoptionen für Ad-Server (Teil 3)

In diesem Artikel werden die Funktionen und Produkte der Google Cloud Platform (GCP) beschrieben, die Sie beim Erstellen einer Ad-Serving-Plattform verwenden können.

Dieser Artikel ist Teil der folgenden Reihe:

In der Übersicht finden Sie Informationen zu den Begriffen der Anzeigentechnologie, die in dieser Serie verwendet werden.

Ad Serving ist das Verfahren zur Bereitstellung der Anzeige (in der Regel der relevantesten) eines Werbetreibenden für einen Kunden in der Property eines Publishers. Die Property kann eine Website, eine App oder ein Spiel sein.

Die Komplexität eines Ad-Servers hängt von den angebotenen Funktionen ab. In der Branche ist ein Ad-Server ein Tool für Publisher und Werbetreibende, mit dem Kampagnen, Anzeigen und das Anzeigen-Trafficking verwaltet werden. Ein Ad-Server dient nicht nur dazu, eine Anzeige zu präsentieren – wie eine Werbetafel eine statische Anzeige am Straßenrand. Die Präsentation von Anzeigen ist zwar die Kernfunktion, doch Anzeigentechnologie-Plattformen wie Google Ad Manager bieten weit mehr Funktionen und Vorteile als das bloße Darstellen einer bestimmten Anzeige für Kunden.

In diesem Artikel wird beschrieben, wie Sie eine robuste Plattform für die Anzeigenbereitstellung erstellen, die die folgenden Hauptfunktionen umfasst:

  • Verwalten von Kampagnen, Konten, Rechnungen und Berichterstellung
  • Auswählen der relevantesten Anzeige
  • Bereitstellen der Anzeige für den gewünschten Zielnutzer
  • Verwalten von Ereignissen wie Impressionen, Klicks oder Conversions
  • Veröffentlichen relevanter Vorgänge in analytischen Datenspeichern

Ad-Server verarbeiten normalerweise Zehntausende Anzeigenanfragen pro Sekunde, wobei jede Antwort innerhalb weniger Millisekunden gesendet wird. Damit auf so viele Anfragen in so kurzer Zeit reagiert werden kann, sind sowohl Verfügbarkeit als auch Skalierbarkeit und niedrige Latenzen wichtige Anforderungen für eine Ad-Serving-Lösung. Und da keine einzelne Serverlösung alle diese Anforderungen erfüllen kann, wird in diesem Artikel untersucht, welche Konsequenzen die Entwicklung eines verteilten Systems hat.

Es gibt zwei Arten von Ad-Servern:

  • Sell-Side: Mit diesen Servern können Publisher ihren Werbeumsatz durch Verwaltung ihrer Werbetreibenden direkt über die UI des Ad-Servers maximieren. Häufig werden auf einem Sell-Side-Server die Anzeigen gehostet. Ein solcher Server kann aber auch zum Hosten der Anzeigenreferenzen verwendet werden. Einige Ad-Server bieten Käufern außerdem eine Self-Service-UI.
  • Buy-Side: Über solche Server können Werbetreibende, Marketingabteilungen oder Werbeagenturen die Aktualisierung ihrer Anzeigen verwalten. Anstatt den Publishern die eigentlichen Anzeigen zur Verfügung zu stellen, bieten diese Plattformnutzer einen Codeausschnitt, der mit dem Buy-Side-Ad-Server für den Abruf der Anzeige kommuniziert.

Im folgenden Diagramm ist die Architektur eines möglichen Ad-Server-Systems dargestellt.

Mögliche Implementierung eines Ad-Server-Systems

Die Haupteinstiegspunkte in die Ad-Server-Plattform werden durch Cloud Load Balancing bereitgestellt:

  • Anfordern von Anzeigen
  • Abrufen des Creatives; die Anzeigen werden aus dem nächstgelegenen Cloud CDN-Cache abgerufen.
  • Tracking von Ereignissen wie Impressionen oder Aktionen/Klicks einzelner Nutzer

Anfragen an den Load-Balancer werden über Logging und Monitoring für das HTTP(S)-Load-Balancing oder über den benutzerdefinierten Code protokolliert, der auf den Collectors ausgeführt wird. Anschließend werden die Anfragen in Cloud Pub/Sub veröffentlicht und dann zur Analyse und zum Erstellen von Nutzerprofilen mit Cloud Dataflow verarbeitet.

Die Worker, in denen die Anfragen bearbeitet werden, nutzen dazu Folgendes:

  • Budgetinformationen
  • Einzelne Nutzerprofile
  • Kampagnendetails
  • Zähler
  • Trainierte Modelle zur Auswahl

Einige der oben genannten Punkte müssen an Ihre spezifischen Anforderungen angepasst werden:

  • Wenn Sie für die Anzeigenauswahl nicht mehrere unterschiedliche Datenbanken benötigen und der Einfachheit halber auf hierarchische oder relationale Datenbanken verzichten möchten, können Sie Cloud Bigtable oder Cloud Spanner verwenden.
  • Wenn Sie für die Verarbeitung einer Gebotsanfrage Leselatenzen von weniger als einer Millisekunde benötigen und zusätzliche Betriebskosten kein Problem darstellen, können Sie regionale In-Memory-Datenbanken von Drittanbietern mit lokaler Replikation verwenden.
  • Mit Ereignis-Collectors, die auf VMs auf Abruf eingerichtet sind, können Sie Kosten senken. Wenn keine Onlineverarbeitung erforderlich ist, haben Sie die Möglichkeit, Ereignisse mit Stackdriver Logging zu erfassen und mit BigQuery zu analysieren.

Kampagnen verwalten

Zur Verwaltung von Kampagnen benötigen Werbetreibende ein Nutzer-Front-End, das mindestens aus einem Web-Front-End und einer Benutzeroberfläche (UI) besteht. Werbetreibende müssen außerdem Berichtsfunktionen bereitstellen. Empfohlene Optionen finden Sie im Abschnitt Nutzer-Front-End (in Teil 1).

Die gemeinsame Hierarchie der Ressourcen, die über diese UI eingerichtet wird, umfasst Werbetreibende, Kampagnen, Budgets, Creatives und Rechnungen. Beim Erstellen dieser Hierarchie werden Regeln für die Anzeigenauswahl aufgezeichnet. Diese Daten werden im Metadatenverwaltungsspeicher (in Teil 1) gespeichert.

Die meisten Ad-Server verarbeiten Milliarden von Anzeigenanfragen pro Tag. Diese Last sollte nicht direkt auf der Datenbank liegen, in der die Metadaten gespeichert werden, die auf diese Regeln für Werbetreibende angewendet werden (sofern Sie nicht Cloud Spanner nutzen). Stattdessen sollten Sie eine der Optionen verwenden, die im Abschnitt Speicherungsmuster für hohe Lesegeschwindigkeit (in Teil 1) aufgeführt sind.

Relevanteste Anzeige auswählen

Anzeigenanfragen empfangen und parsen

Anfragen werden über ein Anzeigen-Tag gesendet, das in der Property des Publishers platziert wird. Anzeigen-Tags sehen so aus:

<script src="[URL_TO_YOUR_AD_SERVER]?key=value"></script>

Beim Laden des Tags wird eine Anzeigenanfrage an den Ad-Server gesendet. Die Anfrage enthält Informationen wie HTTP-Header, User-Agent, Seitenkontext, IP-Adresse, Targeting-Informationen, möglicherweise eine Nutzerkennung und Anzeigendetails, einschließlich der Anzeigengröße.

Der Ad-Server muss einen HTTP-Endpunkt [URL_TO_YOUR_AD_SERVER] bereitstellen, um diese Anfragen empfangen und verarbeiten zu können. Die empfohlenen Optionen werden im Abschnitt Anfragen verarbeiten (in Teil 1) ausführlich beschrieben.

Nutzerprofil erstellen

Verschiedene Ad-Server haben unterschiedliche Methoden zur Auswahl von Anzeigen. Die Beschreibung der zugrunde liegenden Logik würde den Rahmen dieses Artikels sprengen. Damit Sie relevante Anzeigen bereitstellen können, ist es jedoch entscheidend, den Nutzer zu kennen. In dieser Lösung wird davon ausgegangen, dass eine erweiterte Nutzertaxonomie erforderlich ist.

Ein Ad-Server, der für viele Publisher eingesetzt wird, erkennt einen spezifischen Nutzer wahrscheinlich anhand unterschiedlicher Attribute. Die eindeutige Nutzerkennung kann ein HTTP-Cookie oder eine Mobilgeräte-ID sein, die der Nutzer ersetzen kann.

Der Ad-Server kann die mit der Anzeigenanfrage bereitgestellten Daten (IP, Seiteninformationen) mit dieser Nutzerkennung anreichern, um einen Datenspeicher zu durchsuchen. Dabei muss er in der Lage sein, eine Nutzerkennung in Millionen von Zeilen und Terabyte an Daten zu finden. Der Ad-Server muss innerhalb von Millisekunden eine Antwort zurückgeben und gleichzeitig die Verwaltungskosten senken.

Eine Übersicht finden Sie im Abschnitt (Eindeutiger) Nutzerprofilspeicher (in Teil 1). Sie können alle in diesem Artikel genannten Optionen verwenden. Aus folgenden Gründen empfehlen wir jedoch, Cloud Bigtable für die Anzeigenbereitstellung zu nutzen:

  • Es ist eine spaltenorientierte NoSQL-Datenbank, in der Datenmengen im Petabytebereich gespeichert werden können.
  • Zeilen werden im einstelligen Millisekundenbereich abgerufen.
  • Bigtable unterstützt die regionale Replikation.
  • Es ist eine vollständig verwaltete Lösung.

Kampagnen und Anzeigen auswählen

Zur Anzeigenauswahl sind wenige Schritte erforderlich, wie im Abschnitt Anzeigenauswahl (in Teil 1) gezeigt:

  1. Erstellen Sie anhand des Abschnitts (Eindeutiger) Nutzerprofilspeicher (in Teil 1) ein Profil des Nutzers.
  2. Wählen Sie die entsprechenden Kampagnen und Anzeigen aus und verwenden Sie dazu eine Kopie der Daten aus dem Metadatenverwaltungsspeicher (in Teil 1). Kopien werden mithilfe eines Speicherungsmusters für hohe Lesegeschwindigkeit (in Teil 1) erstellt.
  3. Filtern Sie die relevanten Kampagnen und Anzeigen mithilfe der Kontextspeicher (in Teil 1).
  4. Wählen Sie eine Anzeige aus.

Nachdem der Ad-Server Kampagnen und Anzeigen ausgewählt hat, die den Nutzersegmenten entsprechen, wird die Auswahl mit den Kontextspeicherdatenwerten verglichen, z. B. Frequency Capping, schwarzen Listen oder ausgeschöpften Budgets. Anschließend wählt der Ad-Server aus den übrig gebliebenen Kampagnen und Anzeigen die beste Anzeige aus. Die Logik für diese endgültige Auswahl bestimmen Sie. Sie können zum Beispiel verschiedene Kampagnen gegeneinander abwägen und die Kampagne mit dem höchsten CPM oder dem höchsten verbleibenden Budget auswählen. Sie können auch das CTR-Potenzial der Anzeige berechnen oder Parameter für eine gemischte Gewichtung kombinieren.

Einige fortschrittlichere Auswahlsysteme nutzen maschinelles Lernen für Anzeigenempfehlungen auf Nutzer- oder Segmentbasis. Die Workflows des maschinellen Lernens werden in diesem Artikel nicht erläutert. Weitere Informationen finden Sie im Abschnitt Funktionen für maschinelles Lernen erstellen (in Teil 2).

Ausgewählte Anzeige für Zielnutzer bereitstellen

Bis hierhin könnten die beschriebenen Schritte der Arbeitslast zur Anzeigenbereitstellung auf Publisher-Seite zugeschrieben werden. Nachdem die Anzeige ausgewählt wurde, gibt der Ad-Server jedoch einen Link oder einen HTML-Code zurück, der auf Folgendes verweisen kann:

  • Einen Speicherort auf dem Ad-Server des Publishers.
  • Einen externen Speicherort, der möglicherweise dem Werbetreibenden gehört. Ein solcher Ad-Server gilt als Buy-Side-Ad-Server mit einem Modell, das als Drittanbieter-Ad-Serving (Third Party Ad Serving, 3PAS) bezeichnet wird. Mit einem solchen Speicherort können Werbetreibende ihre Anzeigen aktualisieren, ohne mit dem Ad-Server des Publishers verbunden sein oder mit diesem kommunizieren zu müssen. Dieser Speicherort ermöglicht ihnen außerdem, das eigene Tracking zu verwalten.

Unabhängig davon, ob ein Werbetreibender seine Creatives selbst hostet oder sie auf dem Ad-Server eines Publishers hosten lässt, sind die Prozesse bis zur Bereitstellung der Anzeige gleich.

Creatives speichern

Creatives sind Mediendateien wie Videos oder Bilder. Zum Speichern dieser Elemente benötigen Sie einen Objektspeicher, der skalierbar und hochverfügbar ist.

Der empfohlene Speicher ist Cloud Storage, auf dem Roh- oder unstrukturierte Daten im Petabytebereich gehostet werden können. Außerdem bietet er Optionen zum Sichern und Archivieren von Daten. Sie können den Lebenszyklus Ihrer Creatives ausschließlich mit Cloud Storage verwalten, wenn Sie sie mit den Speicherklassen Nearline und Coldline vom aktiven in den Archivspeicher verschieben, um die Kosten zu senken.

Creatives bereitstellen

Obwohl Objektspeicher wie Cloud Storage weltweit verfügbar ist, kann es aufgrund der Entfernungen zu einer erhöhten Netzwerklatenz kommen. Objektspeicher kann außerdem teurer sein als die Anzeigenbereitstellung über ein Content Delivery Network (CDN).

Da Anzeigenpixel und Creatives häufig öffentliche Inhalte sind, können Sie mit den folgenden GCP-Lösungen Inhalte in Cloud Storage im Cache speichern:

  • Objekte öffentlich machen: Mit der Cachesteuerung kann Cloud Storage die vorhandene Google-Infrastruktur nutzen, um Inhalte im Cache zu speichern. Dabei stehen allerdings nur eingeschränkte CDN-ähnliche Funktionen zur Verfügung und es gibt keine Möglichkeit, den Ablauf eines Creatives global zu erzwingen.

  • Cloud Load Balancing und Cloud Storage koppeln: Für Inhalte, die auf Cloud Storage gehostet werden, können Sie Cloud Load Balancing mit aktiviertem Cloud CDN verwenden. Im Vergleich zum ausgehenden Traffic von Cloud Storage bietet Cloud CDN reduzierte Netzwerkpreise sowie eine Unterstützung für signierte URLs, Cache-Schlüssel und Cache-Entwertung.

    Das folgende Diagramm veranschaulicht diese zweite Lösung.

    Cloud Load Balancing und Cloud Storage koppeln

Leistungsvergleiche mit anderen Anbietern finden Sie in diesen Cedexis-Berichten zu Drittanbietern.

Anzeigenereignisse verwalten

Für das System können verschiedene Arten von Ereignissen nützlich sein, wie in den folgenden Beispielen gezeigt:

  1. Anzeigenanfrage: Nach Erhalt einer Anzeigenanfrage für user_ABC von einer Kochwebsite können die user_ABC-Segmente vom System durch Hinzufügen einer Kategorie wie Kochen > Indische Gerichte oder anderer Informationen optimiert werden, die auf die Interessen des Nutzers abgestimmt sind.
  2. Anzeigenimpression: In einem CPM-Modell wird eine Anzeige für einen Zielnutzer bereitgestellt. Das System zeichnet die Impression auf, damit das verbleibende Budget aktualisiert werden kann.
  3. Anzeigenklick: Ein Nutzer klickt auf eine Anzeige. Diese Aktion kann sich auf die Ergebnisse der Anzeigenoptimierung auswirken, insbesondere wenn mehrere (eindeutige) Nutzer innerhalb eines bestimmten Zeitraums auf die gleiche Anzeige klicken.
  4. Conversion: Ein Nutzer klickt auf eine Anzeige und führt eine erwartete Aktion in der Property des Werbetreibenden aus, z. B. einen Kauf oder eine Anmeldung.

Bei der Verarbeitung von Ereignissen ist es wichtig, bei jedem Schritt des Vorgangs das richtige Verhältnis zwischen Preis, Datenaktualität und operativem Aufwand zu finden. Dies gilt insbesondere bei folgenden Aktionen:

  • Erfassen und Aufnehmen einer Vielzahl von Ereignissen mit hoher Geschwindigkeit, wie es bei Impressionen, Klicks, Conversions und Anzeigenanfragen oft der Fall ist
  • Verarbeiten von Ereignissen in Echtzeit oder offline, um Werte zu extrahieren und Zähler wie Budgets, Obergrenzen und Klickraten zu berechnen
  • Exportieren von Ergebnissen in Echtzeit oder offline an verschiedene Standorte, um die Abrechnung abzugleichen oder ordnungsgemäße Bereitstellungsabläufe zu gewährleisten

Ausführliche Informationen finden Sie im Abschnitt Ereignislebenszyklus (in Teil 2).

Zum Erfassen und Verarbeiten von Echtzeitereignissen empfehlen wir die folgende Architektur:

Architektur zum Erfassen und Verarbeiten von Echtzeitereignissen

Diese Architektur ermöglicht Folgendes:

  • Impressionen und Klicks senden Anfragen an einen HTTP-Endpunkt zu statischem Code, der in Cloud Storage gehostet wird, oder an einen Webserver-Collector in Google Kubernetes Engine (GKE).
  • Anfrageereignisse werden über die HTTP-Logs des Load-Balancer protokolliert. Alternativ können die von den Collectors erfassten Ereignisse in Cloud Pub/Sub veröffentlicht werden.
  • Cloud Dataflow abonniert das Cloud Pub/Sub-Thema und verarbeitet die Ereignisse.
  • Anschließend exportiert Cloud Dataflow die unbearbeiteten und/oder verarbeiteten Ereignisse zur Analyse nach BigQuery und in die Informations-/Kontextdatenbank zur Aktualisierung der verbleibenden Budgets.

Ob statischer Code am besten in Cloud Storage oder in GKE-Collectors gehostet wird, hängt von den Anforderungen ab:

  • Wenn Sie zusätzliche Back-End-Aktionen ausführen müssen, sollten Sie GKE verwenden.
  • Wenn Sie Bedenken hinsichtlich des operativen Aufwands haben, sollten Sie Cloud Storage verwenden
  • Wenn Sie kein Problem damit haben, dass Anfragen gelegentlich wiederholt werden, aber die Betriebskosten für GKE- oder Compute Engine-Collectors senken müssen, sollten Sie VMs auf Abruf verwenden, wie im Abschnitt Computing-Plattform (in Teil 1) beschrieben wird.

Weitere Informationen

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...