Der Ad Exchange im Rahmen von Real-Time Bidding (RTB) ist eine der AdTech-Lösungen, die den Online-Werbemarkt verändern. Seine Hauptfunktion besteht darin, eine große Anzahl von SSPs und DSPs anzudocken, die nicht direkt miteinander integriert sind, und eine Vielzahl von Werbeverkehr zwischen ihnen weiterzuverkaufen.
Dank eines Auftrags für den US-Markt haben wir uns eingehend mit den Einzelheiten des Aufbaus der Ad Exchange-Plattform befasst. Und in diesem Artikel präsentieren wir einige Ideen und Ergebnisse.
Erklärung des Problems
Real-Time Bidding (RTB) bietet den Verkauf von Werbeflächen auf Websites in Echtzeit, um relevante Anzeigen für die Zielgruppe anzuzeigen.
Kurz gesagt lautet das Prozessdiagramm wie folgt:
- Der Endbenutzer fordert eine Webseite oder mobile Anwendung an, auf der ein Platz für ein Banner reserviert ist (der Code für die Plattform zum Verkauf von Werbeinventar ist integriert - SSP, Supply Side Platform).
- Um den maximalen Verkaufspreis für Inventar sicherzustellen, organisiert SSP Ausschreibungen zwischen den verschiedenen DSPs (Demand Side Platform) über Ad Exchange, deren Ziel es ist, Inventar so billig wie möglich zu kaufen.
- Nach der Bekanntgabe des Gewinners der Auktion sendet der gewinnende DSP einen SSP-Bannercode, der dem Benutzer angezeigt wird.
- Eine andere Seite des Prozesses ist DMP, ein Drittanbieter-System, das DSP detaillierte Informationen über den Endbenutzer liefert (über das hinaus, was SSP in Form von Cookies usw. übertragen kann), um die Zweckmäßigkeit des Kaufs und die vorgeschlagenen Kosten zu rechtfertigen.
Es gibt heute einige Ad Exchange-Börsen. Darüber hinaus implementieren viele SSPs ihre eigenen Gebote (wodurch die Funktionalität von Ad Exchange tatsächlich geschlossen wird). Unser Kunde war sich jedoch sicher, dass er aufgrund einiger neuer Ideen schnell auf den Markt kommen und dem Wettbewerb standhalten konnte.
Die Börsen arbeiten nach unterschiedlichen Prinzipien: Jemand bietet eine größere Marge, jemand weniger, jemand verkauft einzigartige Geräte, andere konzentrieren sich auf bedingte Konsumgüter. Der Markt ist noch recht jung und entwickelt sich aktiv. Daher werden hier im Laufe der Jahre keine Geschäftsmodelle getestet: Alles basiert auf kühnen Hypothesen und Experimenten. Die meisten Spieler arbeiten nach einem einfachen Schema: Sie erhalten eine Anfrage von einem von mehreren SSPs, mit denen sie einverstanden waren, und senden sie an alle integrierten DSPs, um eine bessere Wette zu erwarten. Ad Exchange Revenue - Die Differenz zwischen dem Kauf- und Verkaufspreis des Werbeinventars bei SSP und DSP abzüglich der Betriebskosten.
Unser Kunde schlug vor, dieses Schema zu optimieren, indem SSP-Anforderungen korrekt an den DSP verteilt werden. Dabei werden keine absichtlich „verlierenden“ Anforderungen gesendet, wodurch die Betriebskosten gesenkt werden. Aufgrund dessen können Sie die Provision der Börse reduzieren, ohne Einnahmen zu verlieren, und Ihr Angebot vor dem Hintergrund der Konkurrenz von Ad Exchange im Kampf um SSP und DSP attraktiver machen. Durch die Verbindung weiterer Partner erhalten Sie sowohl Einkommen als auch Stabilität auf dem Markt.
Um diese Strategie auf dem US-Markt umzusetzen, hatten wir die Aufgabe, die Anzeigenbörse mit einer cleveren Verteilung von Anfragen zu versehen, die einen guten Rückkaufprozentsatz bieten sollte. Theoretisch können Sie für eine solche Verteilung viele Informationen verwenden, die der Anforderung beiliegen, sogar Daten aus den oben genannten Drittanbietersystemen (DMP). Komplexe Analysen erfordern jedoch Ressourcen, sodass die Aufgabe tatsächlich darin besteht, ein Gleichgewicht zwischen den Kosten der intelligenten Verteilung und dem Gewinn (im Vergleich zu anderen Marktteilnehmern) aus ihrer Implementierung zu finden. In einem relativ neuen unreifen Markt ist es einfach nicht sinnvoll, sehr komplexe Lösungen zu entwickeln, die Zehntel der Optimierung erfordern.
Ein wichtiges Merkmal des Projekts war neben den erwarteten hohen Belastungen die Erfüllung der nicht funktionalen Anforderungen an die Geschwindigkeit der von SSP gestellten Auktion. In diesem Marktsegment ist das Zeitlimit für das Warten auf eine Antwort des SSP auf 300 ms angemessen, das zusammen mit Anrufen an externe Systeme (DSP) erfüllt werden musste.
Das Projekt startete im Herbst 2016. Dank der Erfahrung des Teams in diesem Bereich haben wir nach drei Monaten den ersten Prototyp erstellt und nach drei weiteren MVP (Minimum Viable Product) waren wir bereit, die ersten Analysen zu sammeln, um die intelligente Verteilung von Anfragen in Ad Exchange zu starten.
Der Start von MVP zeigte, dass die Hypothese über den kommerziellen Erfolg des Projekts richtig ist - die Ad Exchange begann, Geld für den Kunden zu verdienen. Die ersten Entwicklungspläne für Ad Exchange beinhalteten eine eingehendere Untersuchung der Daten - die Verknüpfung von Endbenutzerinformationen von externen Systemen mit Analysen. In der MVP-Phase wurde jedoch beschlossen, nur die Daten zu verwenden, über die der SSP verfügt. Dies war genug, um den erwarteten Gewinn zu erzielen.
Lösungsarchitektur
Die Lösung basiert auf der Chain-of-Responsibility-Vorlage, mit der die Route von Anforderungen innerhalb des Systems nicht festgelegt werden kann. Auf einfache Weise können Prozessoren und verschiedene Services von der Auktion selbst bis hin zu Filterwerkzeugen hinzugefügt werden.
Der Kunde hat uns im Stapel der verwendeten Technologien nicht eingeschränkt. Aus diesem Grund haben wir uns um die zukünftige Entwicklung und Unterstützung des Projekts gekümmert und mit Postgres und Hadoop eine horizontal skalierbare Lösung erstellt.
Ad Exchange selbst ist in Java geschrieben. Gleichzeitig haben wir keine Frameworks verwendet, um die Last nicht zu beeinträchtigen (wir haben auf einer niedrigen Ebene gearbeitet).
Um das erwähnte SSP-Zeitlimit einzuhalten, haben wir die Garbage Collector-Parameter ausgewählt (G1 wurde verwendet) und eine synchrone Arbeit mit einer großen Anzahl von Anforderungen ausgearbeitet. Wir haben einen HTTP-Client verwendet, der den Fluss nicht blockiert, sowie eine Erweiterung des Keep-Alive-HTTP-Protokolls, mit dem mehrere Anforderungen innerhalb gesendet werden können eine TCP-Verbindung.
Softwarekomponenten werden auf Hardware bereitgestellt, die vom Host als geleast wurde Die Bedingungen der Aufgabe erlaubten die Verwendung der Cloud aufgrund überlappender Ressourcen virtueller Cloud-Maschinen nicht (die Zuweisung der erforderlichen Ressourcen kann einige Zeit dauern, wir haben sie jedoch nicht). Derzeit verwendet Ad Exchange vier physische Server, von denen einer redundant ist (für nahtlose Updates usw.).
Der Open-Source-Apache Kafka wird als Nachrichtenbroker verwendet - er ist idealerweise in unser Modell „Ein Abonnent - Viele Verlage“ integriert, obwohl er leicht verdreht werden musste, damit keine wiederholten Nachrichten eintrafen.
Jeder der Server bietet im normalen Modus etwa 10.000 Anforderungen pro Sekunde (diese Parameter wurden während der Entwicklung der Lösung festgelegt). Jetzt beträgt die durchschnittliche Auslastung 15 bis 20.000 Anfragen pro Sekunde, und in der Spitze erreichte der Anforderungsfluss mehrere Stunden lang 40.000 pro Sekunde, und Ad Exchange hat dies hervorragend geleistet.
Die Verteilung der Anforderungen zwischen den Servern erfolgt durch den für unsere Aufgabe konfigurierten Nginx-Software-Load-Balancer. Nach unserer Erfahrung können Sie unter nginx bis zu 60-70.000 Anfragen pro Sekunde speichern, ohne einen separaten Hardware-Balancer zuzuweisen. Wenn die Auslastung von Ad Exchange in Zukunft über diesem Schwellenwert liegt, planen wir den Kauf eines Hardware-Balancers, der Anforderungen auf mehrere Nginx desselben Typs verteilt.
Es überwacht, was passiert, ein Überwachungssystem, das Teil des erstellten Anzeigenaustauschs ist, sofern die Last ständig steigt.
Lagerung
Angesichts der Abhängigkeit von Analysen bei der Verteilung von Abfragen ist die Datenbank ein wesentlicher Bestandteil unseres Anzeigenaustauschs. Das System speichert Informationen zu Geboten, Auktionsteilnehmern und Transaktionen.
Es ist nicht sinnvoll, ein solches Datenvolumen für den gesamten Zeitraum von Ad Exchange zu erfassen, sodass der Speicher über eine mehrstufige Architektur verfügt. Alle Auktionsdaten werden pro Woche gespeichert. Darauf aufbauend werden übergeordnete Zwischeneinheiten gebaut, die mehrere Monate gelagert werden. Auf der Grundlage der Zwischenaggregate werden die endgültigen Aggregate verwendet, die in der Langzeitanalyse und für Abstimmungen mit SSP und DSP verwendet werden. Unter anderem gibt es in diesen Einheiten Daten darüber, wie viele Wetten abgeschlossen wurden und wie viel Geld die Börse SSP zahlen wird oder voraussichtlich von DSP erhalten wird.
Endpunkte werden für die gesamte Dauer von Ad Exchange gespeichert.
Die Sammlung von Analysen und die Bildung von Aggregaten bieten separate Dienste.
Damit der Speicher der Geschwindigkeit des Systems selbst entsprach, musste ich auch damit arbeiten. Insbesondere haben wir einige Zeit mit dem Hoster gekämpft, weil Transaktionsdaten hatten einfach keine Zeit, in die Datenbank zu schreiben. Es stellte sich heraus, dass der Fehler ein Hardwareproblem mit dem RAID-Array war. Nach dem Ersetzen konnten wir 90.000 Anfragen pro Sekunde auf Postgres komprimieren (durch Einfügen von Daten in die Datenbank).
Der Rest von Ad Exchange ist zustandslos, was in Zukunft eine einfache horizontale Skalierung ermöglicht. Es werden keine Daten zu Anforderungen gespeichert - die maximal empfangenen Informationen darüber, welcher DSP ausgewählt werden soll. Damit wir neue Server hinzufügen können, um Anforderungen nach Bedarf zu verarbeiten.
Verkehrsfilterung
Ein Schlüsselelement des Systems, mit dem Sie die Last reduzieren und die vom Kunden angegebenen Zeitüberschreitungen einhalten können, ist die Verkehrsfilterung.
Je nach Aufgabenstellung kann jeder Ad Exchange:
- akzeptiert Anfragen von SSP;
- hält eine Auktion ab (sendet Anfragen an mehrere DSPs, vergleicht die angebotenen Preise, identifiziert den Gewinner);
- stimmt dem SSP-Sieg zu (meldet den Preis des Gewinners abzüglich seiner Provision, wartet auf eine Antwort mit dem endgültigen Preis der Show);
- schließt die Transaktion ab (meldet dem erforderlichen DSP über seinen Sieg, führt den Benutzerverkehr durch).
Die intelligente Verteilung von Anfragen in unserer Anzeigenbörse ist in der Anfangsphase der Auktion enthalten.
Wenn wir eine Anfrage von SSP mit bestimmten Informationen (IP, Benutzeragent) erhalten, detaillieren wir diese anhand der im System gesammelten Informationen - bekannte Benutzerinformationen, eine Liste von DSPs, an die ähnliche Anfragen gesendet wurden, deren Antworten usw. Dies ist erforderlich, um für jede Anforderung die vorteilhafteste Kombination von DSP auszuwählen. Dank der Auswahl einer solchen Kombination können Sie mit dem System keine Anforderungen an DSPs senden, die nicht bieten oder dies tun, aber zu niedrig sind. Zu diesem Zweck erstellt ein separater Dienst in Echtzeit eine Karte, wie der DSP auf Anforderungen reagiert (diese Karten werden in Redis gespeichert).
Parallel dazu überprüfen wir den Status des DSP. Wenn der Anteil der Antworten innerhalb des Timeouts sinkt, reduziert das System automatisch die Anzahl der Anforderungen an diesen DSP. Sobald die Belastung des DSP verringert wird (und der Anteil der richtigen Antworten in einer akzeptablen Zeit zunimmt), kehrt die Anzahl der Anforderungen allmählich auf die vorherige Ebene zurück.
Unter den DSPs, die pünktlich geantwortet haben, führen wir eine interne Auktion durch - wählen Sie das beste Angebot aus und senden Sie es an den SSP. Vom Zeitpunkt der Anfrage von SSP bis zu unserer Antwort vergehen gemäß den Branchenanforderungen nicht mehr als 300 ms.
Da wir die Daten an den SSP senden, wo unsere Auktion stattfindet, müssen wir die dort gewonnenen Gebote berücksichtigen. Der Auktionsserver ist bereits in der nächsten Phase der Verarbeitung des Benutzerverkehrs mit der Protokollierung beschäftigt. Dank ihm wird die DSP-Antwortkarte mit neuen Daten (zusammen mit den gesammelten Informationen über den Endbenutzer) angereichert.
Ein Vergleich der in der Auktionsphase erhaltenen Daten und der aus dem Benutzerverkehr bekannten Parameter ermöglicht es uns, Bots (Werbeklicker, Suchbots usw.) herauszufiltern. Dieser Datenverkehr wird von DSP nicht eingelöst und führt in Ermangelung eines eigenen Filtersystems zu Kundenverlusten, die durch Margen gedeckt werden müssen.
Es ist zu beachten, dass die Filterung des Bot-Verkehrs nicht sofort gestartet wurde. Nach Einbeziehung einfacher Sperren betrug der Margengewinn jedoch etwa 50%.
Zusätzlich zu den automatischen Verkehrsfilterungswerkzeugen in unserem System ist es dem Kunden übrigens möglich, die Schwellenwerte einer Reihe von Parametern manuell zu ändern und so die Marge anzupassen.
Der Benutzerverkehr selbst ist für uns von entscheidender Bedeutung, aber wenn er verarbeitet wird, muss er nicht mehr in 300 ms passen. Es wird ein separates Verarbeitungssystem verwendet, das den Benutzer ein wenig halten kann, diese Anforderung jedoch nicht verlieren kann.
Um die Stabilität der Lösung zu gewährleisten, wurde ein Subsystem eingeführt, das nach Kenntnis der aktuellen Ad Exchange-Auslastung Auktionsanforderungen "abschneidet", die es physisch nicht verarbeiten kann. Somit ist das System vor unkontrolliertem Lastwachstum durch den SSP geschützt.
Perspektiven
Bis heute funktioniert der von uns erstellte Ad Exchange und erzielt gute Gewinne. Bei Bedarf unterstützen und integrieren wir neue Partner (DSP / SSP). Insgesamt wurden bereits mehrere Dutzend Systeme integriert. Jede solche Integration beinhaltet nicht nur eine Softwareverbindung, sondern auch ein umfassendes Testen des Dienstes, da die Probleme des verbundenen Dienstes unter hoher Last andere Partner betreffen können.
Im Allgemeinen bewegt sich der Markt in Richtung der Tatsache, dass SSP und DSP direkt miteinander verbunden werden, was einen Austausch unnötig macht. Die Integration beruht jedoch auf den Fähigkeiten von SSP und DSP. Trotz der Existenz der offen beschriebenen API (OpenRTB-Protokoll) ist sie auf dem Markt noch nicht allgemein anerkannt. Beispielsweise hat ein großer Player wie Appnexus kürzlich die Unterstützung für OpenRTB integriert.
Ad Exchange ist im Wesentlichen ein Liquiditätsanbieter. Daher ist es unwahrscheinlich, dass die Entscheidung in naher Zukunft an Relevanz verliert. Darüber hinaus gewinnt das Börsenmodell nur im übrigen Werbemarkt an Beliebtheit.
Artikelautor: Nikolay Eremin
PS Wir veröffentlichen unsere Artikel auf mehreren Websites der Runet. Abonnieren Sie unsere Seiten auf
VK ,
FB oder
Telegramm-Kanal , um mehr über unsere Veröffentlichungen und andere Maxilect-Nachrichten zu erfahren.