Grundlagengedanken zur Auslieferungspriorität von OpenX

Nach stundenlangen „Studieren“ der Auslieferungs-Engine und Prioritäten-Berechnung hier mal ein paar Gedanken dazu. Der Grund für die Untersuchung ist die in letzter Zeit häufiger vorkommende Überlieferung von Kampagnen. Eine Ursache hierfür könnte das „gelegentliche“ Ändern der Kampagnen-Priorität durch den OpenX-Anwender sein. In einem konkreten Fall ändern die Nutzer die Priorität täglich.

Gestern habe ich kurz mit Chris Nutting gesprochen (OpenX-Entwickler), zwar wird bei der Berechnung des internen Prioritätsfaktors (im folgenden PF => Wert zwischen 0 … 1 =  interner Wahrscheinlichkeitswert für die Auslieferung) nicht die aktuell eingestellte Priorität in der Kampagne (im folgenden CP => 1 .. 10)  gespeichert – also kennt OpenX bei Berechnen des nächsten PF nicht den alten CP-Wert, falls der Anwender diesen in der Zwischenzeit verändert hat. Seiner Meinung nach hat ein zwischenzeitlich geänderter CP-Wert aber keinen Einfluß auf die Berechnung des PF’s. Ein Problem gibt es seiner Meinung nach erst, wenn eine Zone überbucht ist, d.h. von den Kampagnen mehr Impressions von der Zone gefordert werden als die Zone „liefern“ kann. Das leuchtet auch ein, Kampagnen mit einem niedrigen CP würde dann keine Zonen-Impressionen mehr übrig beleiben.

Meiner Meinung nach sehe ich hier eher ein kurzfristiges Problem, ob dies nicht doch auch langfristig Auswirkungen hat, kann ich im Moment nicht nicht abschätzen: Beispiel:

Nehmen wir an, wir hätten eine Zone mit 200.000 Impressions/Tag.

Eine neue Kampagne (K1) mit CP=1 wird auf eine Zone gebucht, Laufzeit 10 Tage, 1.000.000 Impressions. Das macht 100.000 pro Tag, also 50% der verfügbaren Zone-Impressionen. Ein (funktionierender) Wartungslauf würde jetzt einen PF von 0.5 ausrechnen, d.h. jede zweite Zonen-Impression müßte an K1 vergeben werden.

Jetzt erweitern wir das Beispiel um eine Kampagne K2 mit CP=5, Laufzeit auch 10 Tage mit 100.000 Impressions, was passiert jetzt in OpenX? Hierzu noch einmal kurz einen Exkurs wie OpenX die Banner bei einem Request auswählt:

– zuerst werden alle exklusiven Banner geprüft, dann die mit CP=10, dann die mit CP=9, usw. (siehe auch http://xclose.de/wordpress/86/auswahl-eines-banner-wie-geht-der-adserver-eigentlich-vor)

Hieraus folgt, das K2 einen PF von 0.05 erhält (200.000 Zonen-Impressions/Tag * 0.05 => 10.000 Imps/Tag). Im gleichen Zug muß aber der PF von K1 erhöht werden, da ja beim Prüfen der CP=1-Kampagnen bereits 0.05/1.00 der Zonen-Impressions „weg“ sind, d.h. von den 200.000 Zonen-Impressions werden ja bereits 10.000 an die K2 ausgeliefert, bleiben 190.000, hiervon benötigt K1 100.000, d.h. OpenX müßte einen PF von 0.5263 errechnen.

Soo, wenn das Prinzip bis hierher noch verständlich war, komme ich zurück zu dem „kurzfristigen“ Problem oben: wenn jetzt der Anwender von OpenX die Kampagne mit dem PF von 0.5263 von CP=1 auf CP=10 verschiebt, liefert OpenX nicht mehr 100.000, sondern bereits 105.260 Impressions/Tag aus. Allerdings nur so lange, bis der PF korrekt neu berechnet wird.

Was passiert, wenn wir obiges Beispiel umdrehen, also wir buchen zuerst K2 mit 10.000/Tag und CP=1, OpenX errechnet einen PF von 0.05

Jetzt buchen wir K1 mit 100.000/Tag und CP=5. OpenX errechnet einen PF von 0.5, und muß dann für K2 den PF auf 0.1 ändern (200.000 Zonen-Impressions, hiervon gehen 100.000 an K1, bleiben noch 100.000, hiervon will K2 10.000, also 0.1).

Ändert der Anwender jetzt K2 von CP=1 auf CP=10, liefert OpenX statt 10.000 pro Tag 20.000 – also schon das dopplete des gewünschten.

Hier wird auch klar, warum OpenX eigentlich bei Änderungen in der UI sofort die Prioritäten neu berechnen wollte – um diesen kurzfristigen Nebeneffekt zu verhindern. (Fatal auch, wenn der Wartungslauf von OpenX ausfällt oder nicht korrekt läuft – dann ändert sich der PF nicht.) Gut, für die noch verbleibende „Laufzeit“ des Auslieferungs-Cache kann man es nicht vorhersagen, je nach Erzeugungszeit des Caches sind die verschiedenen Banneranfragen auch noch unterschiedlich gültig. Hieraus folgere ich eigentlich, daß das Abschalten der sofortigen Neuberechnung der PF bei Änderungen in der UI das Problem eigentlich sogar noch verschlimmern müßte … da OpenX ja länger mit einem falschen Faktor rechnet … dem könnte man theoretisch damit begegnen, das man Änderungen des CP’s nicht in die Kampagne schreibt, sondern in eine temporäre Tabelle, und erst kurz vor der Berechnung der neuen PFs in die Kampagne übernimmt. Neu angelegte Kampagnen dto.

Ein langfristiges Problem könnte sich ergeben, wenn OpenX nicht in der Lage ist, bei der nächsten Berechnung des PF auf den geänderten CP zu reagieren, bzw. um Sprünge in der Auslieferung zu vermeiden eine „Glättung“ (oder nur sanfte Änderungen) vorsieht.

Sprünge in der Auslieferung erklärt obiges Beispiel allerdings schon, man müßte also mal ein Kampagnen-„Logbuch“ führen (z.B. Kampagne XYZ 23.04.09, 10:45 Uhr, CP von 4 auf 8), dann könnte man die Stunden-Schwankungen anhand des Logbuchs mal untersuchen.

Alles klar? Oder nur Fragezeichen?

Auswahl eines Banner – wie geht der AdServer eigentlich vor?

Intern errechnet OpenX im Wartungslauf für jede Banner/Zone Kombination einen Prioritätsfaktor (PF) im Bereich 0 .. 1, dieser Wert errechnet sich aus den gebuchten Impressionen im Verhältnis zu den zur Verfügung stehenden Zonen-Impressionen (und vielen weiteren Faktoren).

Nachdem jetzt jeder Banner einer Zone so einen Wert erhalten hat, können wir einen „Request“ eines Banner durchführen:

OpenX selektiert zunächst alle exklusiven Banner einer Zone, prüft deren Auslieferungsbedingungen und wählt dann per Zufallszahl einen der verbleibenden Banner aus. Gibt es keine exklusiven Banner (oder die Auslieferungsbedingungen verhindern eine Anzeige), beginnt OpenX in einer Schleife die Banner von bezahlten Kampagnen zu prüfen. Also:

  • selektieren aller Banner mit Priorität 10
  • prüfen der Auslieferungsbedingungen
  • Auswahl eines Banner per Zufallszahl
  • falls kein Banner gewählt wurde:
  • selektieren aller Banner mit Priorität 9
  • selektieren aller Banner mit Priorität 1
  • prüfen der Auslieferungsbedingungen
  • Auswahl eines Banner per Zufallszahl
  • falls kein Banner gewählt wurde:
  • selektieren aller Banner ohne Priorität (unbezahlte)

Im Unterschied zu den exklusiven Bannern werden bei den bezahlten Bannern die „Wahrscheinlichkeitslücken“ nicht aufgefüllt, nur so kommen auch Banner mit niedriger Priorität mal zu Zuge.

Hierzu ein etwas vereinfachtes Beispiel:

  • Zone mit 200.000 Impressionen/Tag
  • exklusive Kampagne A und B
  • bezahlte Kampagne C (10.000 Impressionen/Tag) und D (20.000 Impressionen/Tag)
  • Hauskampagne E (keine Priorität)
  • (jeweils nur 1 Banner/Kampagne)

Intern würde OpenX jetzt für die Kampagne A und B einen PF von jeweils 0.5 errechnen, C, D und E kommen nur zum Zuge wenn die Auslieferungsbedingungen (Frequency Capping, etc.) eine Anzeige verhindern. Nehmen wir also an, C erhält einen PF von 0.05 (10.000 / 200.000), D einen PF von 0.1 (20.000 / 200.000) und E einen PF von 1.0

Bei der Auswahl eines Banners startet OpenX mit den exklusiven und wählt A und B. Nach Prüfen der Auslieferungsbedingungen addiert OpenX die PF der verbleibenden Banner und wählt eine Zufallszahl zwischen 0 und dem aufaddierten Wert. Für das obige Beispiel gibt es 4 Möglichkeiten – je nachdem welche Banner die Auslieferungsbedingungen überstehen:

Fall 1: beide Banner stehen zur Auswahl

Banner A und B verbleiben
Banner A und B verbleiben

Fall 2: nur ein Banner bleibt übrig:

jeweils nur Banner A oder Banner B verbleiben
jeweils nur Banner A oder Banner B verbleiben

Es wird also in jedem Fall einer dieser Banner ausgewählt. Erst wenn nach der Prüfung kein Banner übrig bleibt, folgt als Fall 4 die Auswahl bezahlter Kampagnen:

Bei den bezahlten Kampagnen wird allerdings immer eine Zufallszahl zwischen 0 .. 1 erzeugt, und diese dient zur Auswahl des Banner: im Bereich von 0 … 0.05 fällt die Wahl auf Banner C, von 0.05 … 0.15 auf Banner D und der Rest verbleibt für Banner mit niedriger Kampagnen-Priorität (Schleife von 10 .. 1) oder die unbezahlten Kampagnen.

Auswahl von bezahlten Bannern:

bezahlte Banner, C und D verbleiben
Auswahl von bezahlten Bannern, C und D verbleiben

Wird in diesem Fall die „Lücke“ ausgewählt, erfolgt die Anzeige von Banner E.

OpenX 2.8 erschienen

Lang‘ ist es her da ich hier mal etwas geschrieben habe … Anfang der Woche ist jetzt die nächste Version von OpenX veröffentlicht worden: OpenX 2.8

Enthalten sind (endlich)
– verbesserte PlugIn Architektur
– Verwaltung der PlugIns über die Oberfläche
– Anbindung an den Marketplace
– Neues Layout der Oberfläche
– Abschied von PHP 4 (läuft nur noch auf PHP5)
– …

Man darf gespannt sein, wie die Version von der Community aufgenommen wird.