Serverlose Pixel-Tracking-Architektur

Diese Lösung stellt eine Architektur für serverloses Pixel-Tracking für Werbeszenarien vor.

Als Werbetreibender oder Werbeagentur ist Ihr oberstes Ziel, die Bekanntheit Ihrer eigenen Marke oder die Ihres Kunden zu fördern. Zu diesem Zweck bietet sich die Onlinewerbung an. Wenn Sie gute Arbeit leisten, werden Ihre Anzeigen in Anzeigeflächen der Property eines Publishers eingestellt. Hier enden Ihre Aufgaben aber noch nicht.

Ein wichtiger Teil einer Werbearchitektur besteht in der Datensammlung, aus der sich ein besseres Verständnis der Reaktion der Zielgruppe ableiten lässt und dadurch das Budget optimal ausgeschöpft werden kann. Eine hierzu häufig verwendete Methode ist Pixel-Tracking. Die Einrichtung von Pixel-Tracking-Servern ist jedoch oft mit einem gewissen technischen Aufwand verbunden. Sie müssen sich beispielsweise um Kosten, Latenz, Skalierung und hohe Verfügbarkeit kümmern, um nur einige Komponenten zu nennen. In dieser Lösung erfahren Sie, wie Sie eine derartige Plattform mit möglichst geringem technischen Aufwand erstellen.

Sicherheit ist beim Arbeiten mit Werbedaten immer oberstes Gebot. Die Google Cloud Platform (GCP) unterstützt Sie dabei, Ihre Daten auf verschiedene Arten sicherer, geschützter und privater zu halten. So werden beispielsweise alle Daten während der Übertragung und bei Inaktivität verschlüsselt. Außerdem erfüllt die GCP alle Anforderungen von ISO 27001, SOC3, FINRA und PCI.

Weitere Informationen zur Implementierung dieser Lösung erhalten Sie, wenn Sie die Anleitung befolgen.

Konzepte

Der Pixel-Tracking-Vorgang erfolgt in der Regel in diesen Schritten:

  1. Dem Creative-Material oder der Webseite wird Code hinzugefügt, um eine URL aufzurufen, die zum Back-End des Werbenetzwerks verweist. Beispiel:

    <img src=”AD_SERVER_URL?parameters”>
    
  2. Auf dem Back-End empfangen Server diese Anfrage, verarbeiten sie und geben ein unsichtbares 1x1-Pixel zurück. Dieses Pixel wird in der Regel vom Programm erstellt. Durch die Rückgabe eines Pixels anstatt einer HTTP 200- oder 304-Antwort wird sichergestellt, dass im Browser kein fehlendes Bild angezeigt wird.

Durch die Rückgabe eines einzelnen Pixels sind die Netzwerkanforderungen sehr gering. Das 1x1-Pixel kann ganz einfach transparent gemacht werden, hat sehr wenig Auswirkungen auf das Netzwerk und ermöglicht das Protokollieren aller Arten von Daten, wie z. B.:

  • Benutzerdefinierte Parameter, z. B. Name der Seite, auf der es angezeigt wird, oder Nutzer-ID.
  • Nutzerbasierte Umgebung, z. B. Browser, Betriebssystem oder Informationen darüber, ob die Anzeige auf einem mobilen Gerät dargestellt wird.

Anforderungen und Architektur

Auch wenn der Vorgang recht einfach erscheint, müssen doch einige Dinge eingerichtet werden. In diesem Beispiel wird von folgenden Annahmen ausgegangen:

  1. Jede Sekunde gibt es durchschnittlich 100.000 Impressionen, die Impressionsrate kann aber variieren.
  2. Impressionen können auf der ganzen Welt stattfinden.
  3. Alle Impressionen müssen protokolliert werden, was zusammengefasst ein tägliches Volumen im Terabyte-Bereich bedeuten kann.
  4. Alle Logs können täglich analysiert werden.

Diese Annahmen haben einige Implementierungsanforderungen zur Folge:

  1. Eine Aufwärts- und Abwärtsskalierung nach Bedarf muss möglich sein.
  2. Daten müssen weltweit von einer Domain mit einer Latenz im Millisekundenbereich zur Verfügung gestellt werden.
  3. Ein skalierbarer Speicher für Logs mit asynchronen Schreibvorgängen ist erforderlich.
  4. Eine Speicheroption, die einfach abgefragt werden kann, ist erforderlich.

Im folgenden Diagramm sehen Sie die Architektur. Beachten Sie, dass es keine Server zum Schreiben auf der Analyseplattform oder zum Bereitstellen der Pixel gibt.

Architecture for serverless pixel serving

Front-Ends

Ein erstes Konzept, das in der Adtech-Werbetechnologie häufig eingesetzt wird, besteht darin, Front-End-Server wie Google Compute Engine-Instanzgruppen oder einen föderierten Google Kubernetes Engine-Cluster in Kombination mit Autoscaling einzusetzen. Die Server schreiben ihre Logs mithilfe eines fluentd-Agents in einen Objektspeicher. Solche Tools sind zwar üblich, dafür müssten Sie aber Instanzen, Vorlagen, Gruppen, Skalierungsregeln und Bereitstellungsskripts einrichten. Dies kann eine Menge Arbeit bedeuten.

In dieser Lösung lernen Sie eine einfacher zu implementierende Alternative kennen, die einige der vollständig verwalteten Produkte der GCP nutzt:

  • Google Cloud Storage: Ein globaler oder regionaler Objektspeicher, der Optionen wie Standard, Nearline und Coldline zu verschiedenen Preisen und SLAs entsprechend Ihren Anforderungen bietet. In diesem Fall verwenden Sie den Standardspeicher, der eine niedrige Latenz im Millisekundenbereich bietet.
  • Google HTTP(S)-Lastenausgleichsmodul: Ein globaler, auf Anycast basierender IP-Lastenausgleichsdienst, der auf Millionen von Anfragen pro Sekunde skaliert und in Stackdriver Logging eingebunden werden kann. Außerdem kann er von Google Cloud CDN zum Verhindern unnötiger Zugriffe auf Cloud Storage verwendet werden, indem das Pixel näher beim Nutzer in den Google Edge-Caches zwischengespeichert wird.

In der folgenden Abbildung sehen Sie die Konfiguration eines GCP HTTP(S)-Lastenausgleichsmoduls in der GCP Console:

User interface shows configuration for HTTP load balancer.

Logs erfassen

Die nahtlose Integration des Cloud-Lastenausgleichsmoduls in Stackdriver Logging vereinfacht die Protokollierung aller Anfragen an das Lastenausgleichsmodul bei minimaler Einrichtung. Logs werden direkt auf Cloud Platform-Back-Ends gespeichert und können von dort in Cloud Storage, Google Cloud Pub/Sub oder Google BigQuery exportiert werden. Dieser Ansatz bietet folgende Möglichkeiten:

  • Sie können mit Stackdriver Monitoring das Verhalten Ihres Systems überwachen und benutzerdefinierte Messwerte und Warnmeldungen erstellen.
  • Sie können Ihre Logs je nach Anforderungen in verschiedene Produkte exportieren:

    • Sicherung: Export in Cloud Storage oder BigQuery
    • Analyse: Export in BigQuery
    • Streamen für Echtzeitverarbeitung: Export in Cloud Pub/Sub

Ein Log in Stackdriver Logging sollte ähnlich wie die folgende Abbildung aussehen, in der Sie einige Dinge sehen können:

  • Das Pixel wurde vom CDN bereitgestellt: cacheHit: true.
  • Die URL-Parameter, die im HTML-Code eingerichtet wurden, sind sichtbar.

Stackdriver log shows cache hit and parameters.

Diese Lösung exportiert Logs direkt in BigQuery durch Verwendung der Streaming API. Außerdem kann Google Cloud Dataflow genutzt werden. Weitere Informationen finden Sie unter Nächste Schritte.

Ein direkt in BigQuery exportiertes Log sieht wie die folgende Abbildung aus, in der die Spalten mit den Schlüsseln der JSON-ähnlichen Daten übereinstimmen, die in Stackdriver Logging zu finden sind. In der folgenden Abbildung sehen Sie eine Anfrage, die alle Daten für ein bestimmtes Log anzeigt, basierend auf dem von Google erstellten Feld insertID.

Google BigQuery shows all data for one log.

Logs analysieren

Nachdem die Daten in BigQuery geladen wurden, können Sie Ad-hoc-Anfragen an ihnen durchführen. Die folgenden Punkte sollten Sie dabei beachten:

  • Die Verwendung einer Partitionstabelle für jeden Tag bietet einige Vorteile, z. B. reduziert sich dadurch die Anzahl von Bytes, die von all Ihren Anfragen verarbeitet wird.
  • Durch das Aufteilen der Tabellen für jede Gruppe von Werbetreibenden sind die Daten einfacher zu verwalten, selbst wenn dies keine Anforderung ist. Sie können jederzeit einen union-Befehl mithilfe von Tabellenplatzhaltern für diese Tabellen ausführen.
  • BigQuery eignet sich auch hervorragend für grundlegende ETL-Jobs. Indem Sie einer Anfrage eine Ausgabetabelle hinzufügen, können Sie Daten nach Bedarf verarbeiten und in ein besser darstellbares Format umwandeln. Beispielsweise können Sie Ihre täglichen Daten in einer wöchentlichen Tabelle sammeln.

Im folgenden Beispielcode sehen Sie einen Teilsatz von Feldern, die Sie in BigQuery für jede Pixelimpression finden können, wobei der Parameter die Liste der benutzerdefinierten Schlüssel-Wert-Paare ist, die Sie hinzufügen und extrahieren können.

 {
    [...]
    "resource_type": "http_load_balancer",
    "resource_labels_url_map_name": "lb-pixel-tracking",
    "resource_labels_zone": "global",
    "httpRequest_requestMethod": "GET",
    "httpRequest_requestUrl": "YOUR_DOMAIN/pixel.png?YOUR_PARAMETERS",
    "httpRequest_requestSize": "972",
    "httpRequest_status": "200",
    "httpRequest_responseSize": "1320",
    "httpRequest_userAgent": "Go-http-client/1.1",
    "httpRequest_remoteIp": "1.2.3.4",
    "httpRequest_cacheHit": "true",
    [...]
}

Nachdem die Daten in BigQuery gespeichert wurden, können Sie damit beginnen, das Nutzerverhalten zu analysieren. Mithilfe der BigQuery-Benutzeroberfläche können Analysten mit SQL-Kenntnissen innerhalb von Sekunden Ergebnisse aus Giga- bis Terabyte großen Datenvolumen herausfiltern.

BigQuery shows results of pixel-tracking requests

Lasttests

Um sicherzustellen, dass diese Lösung in der Produktion verwendet werden kann, können Sie eine verteilte Lasttestumgebung basierend auf Vegeta einrichten. Weitere Informationen hierzu finden Sie in der Anleitung. Wie Sie an den Ergebnissen unten sehen können, kann diese Architektur leicht 100.000 Anfragen pro Sekunde verwalten.

Load testing results graphs

Nächste Schritte

In dieser Lösung wurde eine High-Level-Architektur für die serverlose Bereitstellung von Pixeln erläutert. Um diese Architektur auszubauen, können Sie weitere Funktionen der Google Cloud Platform nutzen, wie z. B.:

  • DNS: In dieser Lösung wurde die globale IP-Adresse des Lastenausgleichsmoduls direkt verwendet. Sie können jedoch auch Ihren Domainnamen anhängen, beispielsweise über Google Cloud DNS. Ein Lastenausgleichsmodul kann mehrere Back-Ends verschiedener Typen haben, wie z. B. Cloud Storage oder Compute Engine.
  • Benutzerdefinierte Messwerte: Wie bereits weiter oben erwähnt, können Sie mithilfe von Stackdriver Logging benutzerdefinierte Messwerte erstellen, die von Cloud Monitoring für Warnmeldungen oder zur Überwachung verwendet werden können.
  • Google Cloud Bigtable: Wenn Sie Cloud Bigtable zur Cloud Dataflow-Pipeline hinzufügen, erhalten einige Ihrer Werbeserver Zugriff auf aktualisierte Daten nahezu in Echtzeit. Cloud Dataflow kann weiterhin Daten in BigQuery zur Offline-Analyse laden und gleichzeitig in Bigtable schreiben. Dadurch sind bei Verwendung von SSD Lesevorgänge mit einer einstelligen Latenzzeit möglich. Dies bietet beispielsweise eine gute Möglichkeit, um Ihr Nutzerprofil abzurufen.
  • Google Data Studio: BigQuery stellt eine Benutzeroberfläche zum Ausführen von SQL-Abfragen bereit, doch manchmal sagt ein Bild mehr als tausend Worte. Data Studio kann Sie bei der Visualisierung Ihrer Analyse durch Dashboards, die freigegeben werden können, und durch datenquellenübergreifende Analysen unterstützen.
  • Log-Verarbeitung: In dieser Lösung lag der Schwerpunkt auf Stapelanalysen mit einer Architektur, die zu Echtzeitentscheidungen führen kann. Ein guter Ansatz zum Aufbau einer solchen Architektur ist die Verwendung folgender Komponenten:
  • Cloud Pub/Sub: Ein vollständig verwaltetes globales Nachrichtensystem. Publisher können eine riesige Menge von Nachrichten zu einem Thema über verschiedene Clients veröffentlichen. Diese Nachrichten können dann von Workern verarbeitet werden, die Nachrichten mittels Pull- oder Push-Nachrichtenzustellung empfangen können. Das System ist beim Export von Stackdriver Logging als Option verfügbar.
  • Cloud Dataflow: Dies ist die von Google entwickelte Variante von MapReduce, die Stapel- und Streamingfunktionen unter demselben SDK bietet, das unter Apache Beam als Open-Source-Produkt verfügbar ist. Cloud Dataflow vereinfacht das Erstellen von Pipelines mit nur einigen Zeilen Code und bietet Ihnen viele großartige Funktionen zur Verarbeitung von Streams einschließlich Wasserzeichen, Timer und Windowing. Außerdem bietet es verschiedene Senken, z. B. BigQuery (vollständige Ad-hoc-Anfragen) oder Bigtable (Lese- und Schreibvorgänge mit niedriger Latenz).

    Eine solche Architektur würde der im folgenden Diagramm abgebildeten ähnlich sehen:

    Advanced archicture

Siehe Anleitungen

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

Feedback geben zu...