Programmatische Werbung in Echtzeit mit TensorFlow

Grundsätzlich funktioniert die SSP/DSP Lösung wie in Abbildung 1 schematisch dargestellt. Bid Requests für Ad Slots (auch Placement genannt) werden über openRTB bzw. einen prebid.js Adapter an die SSP übermittelt. Von dort werden sie aufbereitet an die DSP weitergeleitet. In der DSP erfolgt die Gebotsermittlung, auf Basis der von einem Data Science Team bereitgestellten Modelle. Das errechnete Gebot wird zurückgegeben und für eine Auktion verwendet. Sollte diese gewonnen werden, wird anschließend ein Werbemittel angezeigt.

Abbildung 1: Grundsätzlicher Aufbau SSP/DSP

Abbildung 2: User Assignment

Was passiert nun, wenn ein Nutzer auf otto.de zum Beispiel auf eine Angebotsseite mit Tablets oder Smartphones kommt?

Abbildung 3: Problem 1

Im Beispiel 1 landet User 1 auf der Seite für Multimedia. Obwohl ihm die Kampagne „Technik“ zugewiesen wurde, passt der Scope in diesem Fall nicht. Hintergrund ist, dass für diesen Kunden die optimale Klickwahrscheinlichkeit auf externen Seiten liegt. Somit würde diesem Kunden kein Banner auf otto.de angezeigt werden. Im Beispiel 2 ruft User 3 die Seite auf. Für ihn wurde zwar ein Onsite Scope berechnet, aber er befindet sich im falschen Kontext, eben Technik und nicht wie berechnet Fashion. Also: wieder keine Ausspielung.

Abbildung 4: Problem 2

Ein Bid Request umfasst üblicherweise immer alle Placements / Ad Slots auf einer Webseite. Gebote werden nun zwar für alle Placements einzeln abgegeben, allerdings erfolgt das bisherige Assignment auf Basis von Batch Prozessen. Dadurch ist ein User immer für 2 Stunden nur genau einer Kampagne zugeordnet. Wenn nun auf einer Webseite 3 Placements zur Verfügung stehen und es werden 2 Placements gewonnen, dann wird auf beiden Placements die gleiche Kampagne und damit auch das gleiche Werbemittel ausgespielt.
In unserem Beispiel wurde für User 1 eine Technik Kampagne berechnet, die auch den richtigen Scope hat. Es fallen also alle Werbeplätze auf der Seite der gleichen Kampagne zu, was dann in der Ausspielung ähnlicher Werbemittel auf allen Placements resultiert.

Wie löst man nun diese Probleme? – Zunächst einmal mit Diskussionen.
In gemeinsamen Runden zwischen den Entwicklern beider Teams wurden die Kernanforderungen zusammengefasst:

• Berechnung des User Assignments je Ad Slot/ Placement, d.h. nicht mehr nur eine Kampagne je User
• Berücksichtigung des aktuellen Umfelds (Onsite, Offsite, App, Url) des Users
• Unabhängigkeit in der Data Science Entwicklung

• Die Bidfunktion darf nicht zu kompliziert werden, damit der CPM noch im low latency Bereich berechnet werden kann
• Viele Daten müssen kurzfristig im Zugriff sein, dadurch würden sich die Zugriffe auf unsere Datenbank um circa das 1000x erhöhen
• Datenmenge und Datengröße (z.B.: Features) würden sehr wachsen
• Die Data Science Teams wären bei Änderungen stark limitiert

Wie schafft man es nun in Echtzeit die optimale Gebotshöhe und Kampagne zu berechnen? Diverse Faktoren wie Budget, relevante Kampagnen und verschiedenste User Features müssen in Millisekunden zur Verfügung stehen und schließlich über eine von den Data Scientisten zur Verfügung gestellte Formel in Relation zueinander gebracht werden. Und das alles mit einer sehr niedrigen Latenz.
Da eins unserer Ziele auch die Unabhängigkeit der Data Scientisten war, wollten wir die Implementierung einer aufwändigen und statischen Funktion direkt in einem Service vermeiden. Das Lesen und Schreiben großer Datenmengen in eine Datenbank scheiterte an der Geschwindigkeit und einzelne Schritte vorberechnen, war wiederum nicht flexibel genug, um den Problemstellungen gerecht zu werden.

Abbildung 5: TensorFlow Logo

Nach einiger Überlegung und Diskussion zeigte sich, dass die beste Möglichkeit die Nutzung eines Maschine Learning Frameworks wäre, was den Export eines kompletten, trainierten Models inkl. den zugehörigen Daten ermöglicht. Dieses exportierte Model müsste dann in einen Service integriert und über eine Schnittstelle aufgerufen werden.

 
So entstand der Ansatz TensorFlow und TensorFlow Serving zu verwenden, welches von Google entwickelt wurde, um genau diese Art des Use Cases zu vereinfachen. TensorFlow ist ein Framework, mit dem sich Aufgaben des maschinellen Lernens und der künstlichen Intelligenz umsetzen lassen. Durch TensorFlow können die Data Scientisten Modelle und Daten in einem exportierbaren Format kapseln, so die Kontrolle über die Algorithmen behalten und diese unabhängig verändern ohne das in der SSP oder DSP weiterer Entwicklungsaufwand notwendig ist. TensorFlow Serving bietet dabei eine einfache und hoch performante Möglichkeit die Modelle, nach dem Training, operativ zu betreiben. Im Wesentlichen können so die angereicherten Bid Requests per API an TensorFlow Serving geschickt und die Response, bestehend aus dem Gebot und der Kampagne, ausgelesen werden.

Für die Berechnung wurde ein Großteil der Daten bzw. Features schon in die TensorFlow Modelle hinein implementiert und dann als ‚saved model‘ exportiert, wodurch die Modelle mit + 15 GB sehr groß sind. Die Modelle werden durch den Model Server von TensorFlow Serving komplett in den ORBIDDER geladen. Dies ermöglicht eine sehr schnelle Ausführung des Modelcodes und Antwortzeiten im 10 – 20 Millisekunden Bereich.

Für die Berechnung der Gebote und der Kampagnen fehlen dann nur noch die angereicherten Bid Requests. Darin enthalten sind neben der UserId, auch Informationen zu Kampagnen, Kontext und Budget. Der Model Server von TensorFlow Serving stellt out-of-the-box Schnittstellen für gRPC und REST zur Verfügung, über die dann das Model angesprochen werden kann.
Die Response wird dann in der SSP weiterverarbeitet und es wird ein Gebot für ein Placement abgegeben, was dann eventuell zu einer Impression und im allerbesten Fall auch zu einem Klick führt.

Zu den genaueren Inhalten der Gebotsberechnung gibt es von den Data Science Kolleg*innen hier einen Blog Artikel.

In dem anschließenden, vereinfachten Architekturbild ist die SSP/DSP Landschaft einmal aufgezeichnet. Anhand dieser lässt sich auch der Weg des Bid Requests durch die SSP/DSP ablesen. Weiterhin zeigt es einige kritische Komponenten, die im Anschluss kurz erläutert sind.

Abbildung 6: Architecture flow map

Kubernetes
Der Kubernetes Cluster besteht aus einzelnen Node Pools in unterschiedlichen Zonen, um den unterschiedlichen Anforderungen der Services gerecht zu werden (CPU vs. RAM).

Redis
Unser Applikationscache hält die Daten zwischen 1 und 60 Sekunden vor, danach aktualisiert er sich durch die Daten aus der Redis.

Cloud Storage
Für einfachen Dateiaustausch und zur Ablage und Archivierung von Daten, kommt Cloud Storage zum Einsatz.

PubSub
Ein Message Broker für die Übertragung der Bids, Impression und Klickevents, sowie von Kampagnenänderungen.

BigQuery
Data Warehouse zur dauerhaften Speicherung von Daten zur Verbesserung der Modelle und Algorithmen, sowie zur Abrechnung von Erlösen und Kosten.

Filestore
Da in GKE ein Storage nicht gleichzeitig lesend und schreibend in einen Pod gemounted werden kann, nutzen wir Filestore (NFS) um dies zu ermöglichen. Notwendig wird dies um TensorFlow Modelle ohne Downtime zu tauschen.

Prometheus / Grafana 
Aus unseren Services werden in Echtzeit Metriken generiert, die in Prometheus gespeichert und mit Grafana visualisiert werden.

TensorFlow Serving
Um die Modelle der Data Scientisten operativ laufen zu lassen, werden diese mit allen notwendigen Daten exportiert und anschließend mit TensorFlow Serving via REST mit Bid Requests angefragt.

• 71 Milliarden Requests wurden von der Orbidder SSP im Oktober 2022 gehandelt
• Im Schnitt verarbeitet der Orbidder zwischen 25.000 und 30.000 Requests pro Sekunde
• 100.000 Request pro Sekunde ist der maximale registrierte Durchsatz der Requests an die Orbidder SSP
• 15 Millisekunden ist die durchschnittliche Latenz bei der Verarbeitung eines Requests
• Etwa 1000 ist die Anzahl der Service Instanzen (Pods) im GCP Kubernetes-Cluster vom Orbidder tagsüber