Announcement: Plugin wecosCategory for OpenX AdServer

A new plugin for the OpenX AdServer is almost finished: automatically link Campaigns and Zones by Category. The administrator defines a list of categories, to which zones or campaigns are able to subscribe. After the subscription has been saved, the campaign / zone linking is automatically applied to match the specified categories.
Please contact me for futher details.

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

Security-Update veröffentlicht: OpenX 2.8.3

Nach bekanntwerden eines „Sicherheitslochs“ in älterne OpenX-Versionen wurde soeben das Release 2.8.3 freigegeben. Alle Anwender sollten schnellstmöglich ein Update durchführen, da bereits erste „Exploits“ dieses Sicherheitsloch ausnutzen.

Nach meinen bisherigen Erkenntnissen (Vergleich 2.8.2 / 2.8.3) reicht vermutlich das Löschen der Datei /www/admin/install.php (die nach der Installation nicht mehr benötigt wird) aus.

OpenX Country Stats into the UI

Recently I finished a new module to add informations about country (where does my users come from) into the statistics. Althrough OpenX 2.8 has a plugin openXDeliveryLogCountry which collects the country statistics, the part to integrate this data into the UI is still missing.

The Impressions column gets a new details link
The Impressions column gets a new details link

My new country-stats module fills the missing gap. With a simple click to the impressions column you get the country details of the current row – this works within all levels of the statistics.

Country statistics in detail
Country statistics in detail

The modul is available for OpenX 2.8 and 2.6 – unfortunately it require still some patching of codebase.

To get the files and instructions for OpenX 2.8 please download here: stats_country_2.8.zip For OpenX 2.6 please contact me.

Changelog:
Oct/04.2010: fixed column sorting (you only need to update stats-country.php)
Oct/28.2009: fixed missing path in Admin_DA_patch.txt
Aug/24. 2009: improved column sorting.

Plugin Zone mit allen aktiven Campagnen verlinken

Das folgende Plugin für OpenX ist wohl nur für Werbenetzwerke interessant, es fügt zu den Zonendetails einen neuen Tab hinzu, dort hat man die Möglichkeit die aktuelle Zone mit allen Kampagnen zu verlinken – oder die Verlinkung der Kampagnen komplett aufzuheben.

Changelog: 2010-03-17: Plugin-Settings um einige „exclude-rules“ erweitert.

Die neue Version befindet sich hier: wecosZoneLink.zip

Plugin BannerPreview

Changelog:

2009-05-08/0.0.3-dev: allow an advertiser to use the campaign-level menu-item „Banner Preview“
2009-04-28/0.0.2-dev: adding a campaign-level menu-item „Banner Preview“

English: please see below …

Leider fehlt in der neuen Version 2.8 von OpenX eine Möglichkeit alle Banner einer Kampagne „auf einen Klick“ optisch zu kontrollieren – dies war in früheren Versionen in den Kampagnendetails möglich – gerade für externe Banner ist dies sehr hilfreich. Leider ist man zur optischen Kontrolle in 2.8 jetzt gezwunden, jeden Banner einzelnd anzuklicken um die Darstellung in den Eigenschaften ansehen.

Ich habe mich daher mal an einem kleinen Plugin versucht, eine erste Version steht hier zum Download bereit: http://www.wecos.de/openx/files/wecosBannerPreview.zip.

Anmerkungen oder Kommentare sind ausdrücklich erwünscht.

English: As a result of a „self study“ I announce a small adserver plugin „BannerPreview“. It adds a menu-item „Preview“ and allow the manager to preview all banner of a campaign at once. Since openx 2.8 the „preview“ of banners at campaign-level is gone, so I thought it might be a „nice to have“ feature.

Download the ZIP (~13kB) here: http://www.wecos.de/openx/files/wecosBannerPreview.zip.

Feedback is welcome.

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?