Grundsätzlich nehmen Adserver uns Programmierern eine Unmenge an Arbeit ab: die Pflege von GeoIP-Datenbanken, implementieren von Filteralgorithmen und neue Funktionen die im Onlinemarketing aktuelle kursieren werden meist von den vielen Anbietern wie OpenX oder DoubleClick von Google umgesetzt und bedürfen keiner weiteren Arbeit.
Damit Applikationen mit den mächtigen Systemen kommunizieren können bieten diese immer eine API. An dieser Stelle möchte ich näher auf meine Erfahrungen mit der DFP-API eingehen.
Zunächst positiv hinsichtlich Nutzbarkeit und Entwicklugnszeit ist anzurechnen, dass Google für die gängigen Programmiersprachen einen Client anbietet, welcher ohne großen Aufwand direkt eingesetzt werden kann und die Applikation somit gewappnet ist für die API. Hinsichtlich des PHP-API-Clients ist anzumerken, dass die Klassen über kein Prefix verfügen, somit kann es unter Umständen zu Namenskonflikten kommen. Auch ist das von Google bereitgestellte Webinterface und die Sandbox-Übersicht für Programmierer bzw. Benutzer sehr schnell, einfach und intuitiv verwendbar.
Ein kleiner Kritikpunkt ist es, dass von Anlegen einer Order bis hin zur Auslieferung und dem zählen der Impressions bzw. Clicks bis zu 30 Minuten vergehen, sprich direkt eine Order anlegen und Starten geht in diesem Falle nicht. Dieses Problem besteht folglich auch in der API, sie liefert zwar sofort korrekte Daten, jedoch dauert der Überganz einer Order von “Bereit” auf “Ausliefernd”. Das stellt gemäß den Anforderungen der Benutzer oft vor Probleme in der Programmierung.
Zusammenfassend jedoch verfügt DFP über eine klar strukturierte und detailliert dokumentierte Schnittstelle. Der größte Kritikpunkt bei DoubleClick besteht darin, dass in meiner vier Monatigen Zeit, in der ich Erfahrungen sammeln durfte, drei mal der Support kontaktiert werden musste, da sich plötzlich ein nicht vorhersehbares verhalten, in Form von Fehlermeldungen, aufzeigte. Diese Fehler wurden bestätigt und innerhalb von 2 Tagen auch behoben, jedoch war mit der API in dieser Zeit stellenweise kein Arbeiten möglich.
Alle großen Onlineshops setzen heut zu Tage auf Affiliate-Programme. Hierzu nutzen sie zumeist einen der zahlreichen Anbieter. Aus meiner Erfahrung möchte ich hier kurz 3 der bekanntesten hinsichtlich ihrer API vergleichen.
Zunächst zu meinem Favouriten: Zanox.
Zanox bietet ein klare und sehr gut benutzbare Programmierschnittstelle als SOAP-Service. Neben der herausragenden Schnelligkeit der API ist auch der Support äußerst zufriedenstellend. Weiterhin ist die API sehr gut und Detailreich, mit Beispielen, dokumentiert.
Anzumerken ist, dass Zanox per Default nicht den letzten Klick mitliefert, dies jedoch kann man auf Anfrage aktivieren lassen. Mein zeitraubendster Punkt in der Entwicklung bestand darin den Auth-Token aus und in den Request-Header der SOAP-Anfrage zu lesen bzw. schreiben. Da PHP hier relativ steif ist in Struktur und Datenherausgabe, komfortabler wäre es die Authorisierung in den Request-Body aufzunehmen.
Platz 2 vergebe ich an Netslave, da die API auch hier recht gut dokumentiert und schnell in der Datenherausgabe war. Schnelligkeit ist für mich bei APIs ein essentieller Punkt, da sich auf Seiten der Partner schnell viele Daten ansammeln können.
Für mich bestand in der Arbeit mit Netslave ein großes Problem darin, dass der Anbieter mit dem Auslesen der einzelnen Transaktionen(Sales/Leads) nicht die zugehörige Provision mitsendet. Diese müsste man sich via Umwege aus den einzelenen Partnern via API herauslesen und berechnen(bei Vergütung auf prozentualer Basis). Weiterhin ist es problematisch, wenn nachträglich die Provision eines Partners geändert wird, somit ist man nachträglich nicht mehr in der Lage sicher festzustellen wie hoch die Provision des einzelnen Transfers war. Diese Limitierung beschränkt sich jedoch nur auf die API, in dem Webfrontend ist diese Angabe natürlich vorhanden.
Last but not least: Affili.net
Affili.net bietet die beste Dokumentation alle 3 Netzwerke und stellt auch von Anfang an direkt alle notwendigen Daten bereit. Die Nutzung ist hier also meiner Meinung nach am einfachsten.
Jedoch musste ich in meiner Arbeit mit der API leider feststellen, dass es hier in 2 Monaten zu 2 Ausfällen über mehr als 1 Stunde kam. Weiterhin ist die Antwort-Geschwindigkeit der API nicht mit der der anderen Podiumsplätze vergleichbar. Für 5 Requests, welche mir rund 25000 Transaktionen liefern dauerte es zwischen 2 und 3 Minuten bis meine Datenbank befüllt war, Affilinet und Zanox waren hier mit unter 40 Sekunden deutlich schneller.
Als großer Pluspunkt für nicht Programmierer ist hier zu erwähnen, dass Affilinet die übersichtlichste und funktionsstärkste Weboberfläche bietet. Sollten die Ausfälle und Geschwindigkeit sich bessern, so hat Affilinet definitiv eine Chance auf Platz 1.
Fast alle modernen Browser haben die Angewohnheit automatisch nach einem Symbol für die Bookmarks zu suchen, das so genannte Favicon. An sich ein nettes Feature, wenn der Webseitenbesitzer den Speicherort dieses nicht im Quelltext seiner Seite angibt.
Problematisch wird dies jedoch, wenn die Webseite mit dem wohl beliebtesten PHP-Framework, dem Zend Framework, geschrieben wurde. Das Zend Framework liefer automatisch eine .htaccess-Datei mit, welche alle Aufrufe der Webseite behandelt und sofern keine physische Datei existiert die Anfrage an das Framework weiterleitet.
Da in der Regel keine “Action” namens favicon.ico existiert wird hier ein 404-Fehler produziert, welcher, wenn ein Logger existiert in den Errorlogs der Applikation landet. Da dies für unnötig große Logs sorgt, hier eine Lösung für das Problem.
In der .htaccess legen wir fest, dass die Anfrage das Framework nur dann erreicht, wenn die Datei nich physisch unterhalb des “public”-Verzeichnisses existiert oder der angefragte Dateiname nicht “favicon.ico” lautet.
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/favicon.ico$ [OR]
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]
