Siehe auch: Fehlerticket im OpenX Bugtracker OX-5940

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?

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

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

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 …

Wie funktioniert jetzt der SPC?

Zunächst wird im HEAD-Bereich der Seite der Request an den OpenX Ad-Server eingebaut:

<script type='text/javascript' src='http://example.com/delivery/spcjs.php?id=1'></script>

Hiermit wird OpenX angewiesen für alle Zonen des Werbeträgers (die Webseite) mit der ID=1 ein Werbemittel (Banner) auszuliefern. Der Bannercode für die einzelnen Banner wird in einem javascript-Array zwischengespeichert. Anschließend können diese “vorgeladenen” Banner an der jeweiligen Position auf der Webseite ausgegeben werden:

...
foo bar
<script type='text/javascript'><!--// <![CDATA[
OA_show('12');
// ]]> --></script>
...
foo2 bar2
<script type='text/javascript'><!--// <![CDATA[
OA_show('17');
// ]]> --></script>
...

Das obige Beispiel zeigt den Banner für die Zone 12 und Zone 17 auf der Webseite. Kopiert man den obigen Bannercode direkt aus der Admin-Oberfläche von OpenX auf seine Webseite ist eine Verwechselung der Zonen-IDs ausgeschlossen – übernimmt man den SPC-Aufruf von einer bereits existierenden Seite, muß man beachten, das die jeweiligen Zonen-IDs auch zu der Webseiten-ID (Aufruf von spcjs.php, s.o.) passen.

Zusätzliche Optionen

Ähnlich der Option “Werbemittel auf derselben Seite nicht mehrfach anzeigen” des normalen javascript-Bannercode erlaubt auch der SPC diese Einschränkung: hierzu wird der Parameter “&block=1″ an den Aufruf von spcjs.php angehängt:

<script type='text/javascript' src='http://example.com/delivery/spcjs.php?id=1&block=1'></script>

Intern verarbeitet OpenX die Zonen jetzt der Reihe nach und wird dabei keinen bereits ausgewählten Banner erneut auswählen. Für die Option “Kein Werbemittel der gleichen Kampagne mehrfach anzeigen” mit dem Parameter “&blockcampaign=1″ verhält es sich identisch.

Erweiterte Nutzungsmöglichkeit

Kommen wir nun zu der optimierten Anwendung des SPC: Man mag sich fragen, warum man für eine Webseite mit nur 3 Zonen trotzdem für alle Zonen der Webseite in OpenX einen Banner anfordern muß. Dies ist jedoch nur in der Standard-Anwendung des SPCs so, wenn man den Bannercode von OpenX generieren läßt. Durch eine Erweiterung des Aufrufs lassen sich die Zonen explizit auswählen – mehr noch – es können auch Zonen mehrfach für eine Seite ausgewählt werden. Hier ein Beispiel: Für eine Webseite sollen die Zonen 7, 12 und 18 ausgegeben werden, wobei die Zone 7 zweimal auf der Webseite enthalten ist. Hier für fügt man vor dem Aufruf von spcjs.php z.B. den folgenden javascript-Code ein:

<script type='text/javascript'><!--// <![CDATA[
var OA_zones = {
'Kopf' : 7,
'Fuss' : 7,
'Links' : 12,
'Rechts' : 18
}
// ]]> --></script>

Hilfreich ist hierbei, dass man an dieser Stelle eigene Namen für die später auf der Seite auszugebenden Banner verwenden kann (Kopf, Fuss, …). Zur Ausgabe der Banner auf der Webseite verwendet man jetzt die selbst gewählten Namen statt der Zonen-IDs:

...
foo bar
<script type='text/javascript'><!--// <![CDATA[
OA_show('Kopf');
// ]]> --></script>
...
foo2 bar2
<script type='text/javascript'><!--// <![CDATA[
OA_show('Links');
// ]]> --></script>
...

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, …).

Der AdServer (OpenX) zeichnet diese Tracker-Impressions zunächst wie andere Impressions auf und speichert alle (vorher zu diesem Tracker definierten) Variablen mit ab. Während des Wartungslaufes versucht OpenX dann diese Tracker-Impressions gegen Banner-Impressions (=> view-window) oder Banner-Klicks (=>click-window) abzugleichen. Ist eine Zuordnung möglich (OpenX erkennt den Benutzer wieder und die Tracker-Impression liegt innerhalb des vorgegebenen Zeitrahmens (=> …-window), erscheint in der Statistik eine (Pending-) Conversion, je nach Status des Trackers (Pending oder Approved).

Wichtig hierbei: Tracker-Impressions werden gegen die RAW-Impressions/Klicks abgeglichen, d.h. wenn man z.B. ein Zeitrahmen von 5 Tagen wählt, die RAW-Daten aber nach 2 Tagen löschen läßt, können Tracker auch nur gegen die vorhandenen 2 Tage abgeglichen werden.

Der Abgleich von Trackern ist vergleichsweise zeitaufwendig, da ja gegen die RAW-Daten abgeglichen wird.

Sinnvoll wird der Einsatz von Tracker z.B. bei Lead-Kampagnen, d.h. der Werbetreibende bezahlt nicht per Banner-Klick, sondern für jeden erfolgreichen Vertragsabschluß (z.B. Mobilfunkverträge, etc.). Allerdings ist die Vergütung pro Vertragsabschluß dann wesentlich höher.

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.