Marketplace-Plugin liefert trotz Deaktivierung in der Zone

In den aktuellen OpenX-Versionen 2.8.* wird automatisch bei der Installation das neue „Marketplace-Plugin“ installiert. Durch einen bisher noch nicht offiziell bestätigten Fehler kann das Plugin auch dann Werbung des Marketplace ausliefern wenn weder in der Kampagne noch in der Zone dies erlaubt wurde. Anwender die das Plugin installiert haben, sollten daher regelmäßig die Auslieferungszahlen des Plugins im Auge behalten und das Plugin ggf. deaktivieren, bis die Ursache des Fehlers geklärt ist.

Siehe auch: Fehlerticket im OpenX Bugtracker OX-5940

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?

Auslieferungs­beschränkungen auf eigene Variablen

Seit OpenX 2.6 ist es sehr leicht in den Auslieferungsbeschränkungen eines Werbemittels (Banner) auf eigene Werte zu prüfen. Hierzu ein kurzes Beispiel:

Bei der Erstellung der Webseite, auf der das Werbemittel später erscheint, liegen Ihnen bestimmte Informationen über den „Betrachter“ vor, z.B. in einem Forum wenn der Leser bereits eingeloggt ist. Einige dieser Informationen können für eine feiner Auswahl des Webemittels nützlich sein (z.B. das Alter, Geschlecht, PLZ, …).

Um diese Information jetzt mit in den Aufruf (Bannercode) des Werbemittels zu reichen, können einfach zusätzliche Parameter hinzugefügt werden. Betrachten wir z.B. den javascript-Bannercode:

   ...
   document.write ("<scr"+"ipt type='text/javascript' src='"+m3_u);
   document.write ("?zoneid=67");
   document.write ('&amp;cb=' + m3_r);
   ...

so könnten wir den Aufruf wie folgt abändern:

   ...
   document.write ("<scr"+"ipt type='text/javascript' src='"+m3_u);
   document.write ("?zoneid=67");
   document.write ("&amp;geschlecht=M&amp;alter=37");
   document.write ('&amp;cb=' + m3_r);
   ...

Natürlich muß diese Zeile dynamisch aus den Nutzerdaten erzeugt werden.

Diese an den OpenX-AdServer gereichte Zusatzinformationen kann jetzt in den Auslieferungsbeschränkungen eines Banners überprüft werden. Hierzu wechselt man auf den 2. Tab der Banner-Details und fügt dort eine neue Auslieferungsbeschränkung ein:

Auslieferungsbeschränkung Webseite:Variable
Auslieferungsbeschränkung Webseite:Variable

Nach dem Klick auf „Hinzufügen“ könnte man z.B. die Regeln festlegen: nur weibliche Besucher im Alter von 20-28 Jahren. Bei der Verwendung der obigen Parameter „geschlecht“ und „alter“ sieht das dann wie folgt aus:

Regeln für Alter und Geschlecht
Regeln für Alter und Geschlecht

In der Praxis sollte man allerdings für die Parameternamen allerdings kürzer wählen um die Länge der entstehenden Url nicht zu groß werden zu lassen. Zusätzlich könnte man die Werte der Variablen ebenfalls „verschleiern“, um die Nutzerprofile nicht im Klartext durchs Netz zu reichen …

Viele Werbemittel schnell anzeigen

Der Single-Page-Call (SPC) von OpenX ermöglicht das effiziente „befüllen“ einer Webseite mit Werbemitteln – und dies in nur einem einzigen Ad-Request, also eine deutliche Reduzierung der Serverlast auf Seiten des Ad-Servers. Als „nützlicher“ Nebeneffekt wird auch die Webseite deutlich schneller aufgebaut, da sich ja auch für den Webbrowser der Netzwerktraffik erheblich verringert. „Viele Werbemittel schnell anzeigen“ weiterlesen

Was ist ein Tracker

Mit einem Tracker kann man den Erfolg einer Bannerkampagne überprüfen. Normalerweise ist ja nach dem Klick-Tracking für einen AdServer die „Sache“ beendet, d.h. niemand kann nachvollziehen, ob der Nutzer auf der Zielseite nach dem Banner-Klick etwas gekauft hat (was auch immer dort beworben wird).

Bei einem Tracker wird auf der Website des Werbetreibenden ein Tracking-Code installiert, und zwar auf der „Confirmation-Page“ (bei einem Shop-System z.B. nach dem Bezahlvorgang). Dies kann ein einfacher Tracker sein, der keine weiteren Informationen als „erfolgreicher Abschluß“ übermittelt, oder aber auch zusätzliche Variablen übermittelt (user_id, orderID, Datum/Uhrzeit, Höhe des Warenkorbs, …). „Was ist ein Tracker“ weiterlesen

Click-Tracking bei Flash-Bannern

Ich habe die Erfahrung gemacht, das OpenX 2.6 bei Flash-Bannern im Format Flash9 beim Umsetzen der hartcodierten URLs gelegentlich noch Probleme hat, man sollte also nach Möglichkeit den Grafiker bitten, den Banner als Flash6,7 oder 8 exportieren.

OpenX kann 2 verschiedene Flash-Click-URL umsetzen:
– hartcodierte Links: der Grafiker schreibt direkt in den Banner

on (release) {
getUrl(„http://www.example.com“, „_blank“);
}

Beim Hochladen in OpenX wird der Banner „durchsucht“ und es wird versucht die URL zu ersetzen. Anschließend funktioniert es genau wie in Möglichkeit 2:

– statt des hartcodierten Links schreibt der Grafiker einen Platzhalter in den Banner:

on (release) {
getUrl(clickTAG, clickTARGET);
}

hierbei MUSS die Groß- und Kleinschreibung exakt wie oben geschrieben erfolgen, sonst klappt es nicht, da Flash ab Version 6 case-sensitive ist. Beim Ausliefern des Banners werden die beiden Parameter „clickTAG“ und „clickTARGET“ an den Flash-Player sozusagen als Laufzeit-Variablen übergeben.

Zusätzlich scheint OpenX 2.6 mit einem Target-Window „_top“ oder „_self“ ebenfalls nicht klar zu kommen, nach Änderung in „_blank“ hat der Klick (und das Tracking) wieder funktioniert.