Facebook hat letztes Jahr mit dem Start der Entwicklerplattform ein Zeichen gesetzt. Nein, es ist in der Tat nicht so, dass Facebook der Vater der Grundidee von Webservices bzw. Programmschnittstellen wäre. Seitdem es Computer und Software gibt, sind Schnittstellen das A und O. Interessanterweise aber bieten zahlreiche Webunternehmen nicht eine offene Schnittstelle an. Ganz so, als hätte man sich nie mit der Geschichte der IT beschäftigt oder man irgendwie blind sein muss. Obwohl gerade Twitter, Google, YouTube, Facebook und neuerdings Google mit Open Social aufzeigen, dass dies keine dumme Idee sein muss, dass APIs im Netz ebenso unverzichtbar sind. Facebook hat „lediglich“ als ein sehr prominentes Unternehmen eine umfangreiche API auf die Beine gestellt. Und profitiert davon ungemein, angebliche Usermüdigkeit hin oder her. API? Application programming interface = Schnittstelle zur Anwendungsprogrammierung.
Schnappen wir uns als Beispiel doch einmal die vielen Affiliate-Netzwerke wie Zanox oder Affili.net. Soweit ich weiß, bieten beide Importschnittstellen für Produktdaten an. Import, nix Programmierung. An sich sind beide Anbieter ziemlich langweilig, ertragreich ja, aber langweilig: Man sucht sich einen Werbeanbieter, kramt in deren verfügbaren Bannern, wählt sich was davon aus und schmeißt diese auf seine Seite. Gähn. Alleine schon das Thema Bannerformate und Interaktivität (lol, was?) ist unterirdisch. Wenn man die so weitermachen lässt, wird es noch in 500 Jahren den gleichen Mist geben. Ok, welchen Ausweg hat man aus diesem Innovationsdilemma? Wenn schon die Macher zu fantasielos sind, könnte man den Interessenten eine API anbieten. Die es den Publishern letztlich ermöglich, smartere Banner und Formate, intelligentere Formen und interaktivere Werbebotschaften zu platzieren. Das bedingt natürlich auch einen Zugriff nicht nur auf Bannerformen und Auswertungsmethodiken, es bedingt auch einen anonymisierten Zugriff auf weitgehende Trafficdatenpools, die auch demografische Daten enthalten. Wäre es denn so ein dummer Gedanke, dass der Developer die bestehenden Banner in einen eigenen Rahmen presst, der weitaus mehr bietet? Warum sollte sich der Publisher nicht in diesem Pool umschauen und passende Angebote auswählen dürfen? Und der Developer bekommt dann eine Schnitte von den Provis ab? Denkbar, nicht undenkbar.
Beispiel: Schon mal Versicherungsbanner gesehen? Poah, gibt kaum was Langweiligeres. Wir in Hessen sagen Scheißendreck dazu. Versicherungen mögen Konsumenten als ein nerviges Übel erscheinen. Im Grunde ist aber das Versicherungsgeschäft ungemein spannend. Es geht um das Handling von Risiken. Dazu greift man auf immense Datenpools zu, um Wahrscheinlichkeiten zu kalkulieren, woraus sich dann die Prämie ergibt. Versicherungen beschäftigen hierzu Mathematiker, die in den Daten wühlen und nach Korrelationen suchen. Um daraus abzuleiten, wo es möglicherweise Ansatzpunkte gibt. Die Unfallwahrscheinlichkeit einer PKW-Halterin steigt ab dem fünfzigsten Lebensjahr? Klaro. Das Kind wird 18 und fährt mit Mamas Kiste herum. Darauf muss man erstmal anhand der Schadensverläufe kommen. Wenn die Versicherungen nicht so konservativ wären, würden sie ihre Datenpools anonymisiert zusammenlegen, über Schnittstellen den Affiliates zur Verfügung stellen und darauf können dann externe Developer von außen zugreifen. Der Konsument wiederum kann bspw. in einem simplen Banner-Formular bestimmte Eckdaten eingeben, bekommt daraus eine von mir wegen witzig aufbereitete Risikochart dargestellt und kann passende Produkte auswählen. Die Konsumenten können sich hierzu im Rahmen einer eigenständigen „Social-Application“ vom Risikomuster her mit anderen Konsumenten vergleichen. Gewicht, Blutdruck, Alter, Zigarettenkonsum? Viel Spaß. Mashups? Wo ist das Problem?
Neue Stellenangebote
Growth Marketing Manager:in – Social Media GOhiring GmbH in Homeoffice |
||
Senior Online Marketing Manager (w/m/d) – Schwerpunkt Social Media Oldenburgische Landesbank AG in Oldenburg, Frankfurt am Main |
||
(Senior) Paid Social Media Manager (m/w/d) Content Fleet GmbH in bundesweit |
Das o.g. Beispiel habe ich bewußt gewählt, da es hierzu drei „Lieferanten“ gibt: Den Werbenden, die Werbevermittler und die externen Developer. Und das ist nicht mal so schwer vorzustellen, dass gerade Werbende und Werbevermittler ihren Boppes bewegen, weil die Tasks imho nicht allzu schwer zu lösen sind. Das Dumme: Sie sind allesamt mehr als lahm. Karamba!
Geht nicht? Gibts nicht! Such einfach nach Fabeook Beacon. Das ist genau so ein interaktives Werbemodell mit drei Lieferanten (noch können externe Developer nicht auf den Beacon-Pool zurückgreifen, aber auch das wird noch kommen, be sure). Beacon ist zwar ins Gerede gekommen, da Facebook Mist beim anfänglichen Opt-Out Modell gebaut hat (was jetzt ein Opt-In Modell ist), das soll aber vom grundsätzlich Gedanken nicht ablenken, dass sich die Welt vernetzt. Und ich finds ziemlich dumm, wenn man nicht auf die brainpower da draußen zruückgreift.
Zur Info: Commission Junction bietet ein Bannerbuilder fuer Merchants an. Genaue Name habe ich vergessen.
Ist jedoch ein grosser Aufwand fuer den Merchant weshalb wohl viele davon Abstand nehmen. Banner sind zudem schlicht und einfach tot. Auf die Form kommt es da nicht mehr so viel an.
Deine Ideen sind recht interessant. Setze es doch um wenn alle anderen zu faul sind 🙂
Da Affilinet nur die CSV-Daten anbietet, programmiere ich mir zur Zeit ein Tool in C#/.NET mit dem ich die Daten flexibler handhaben kann. Ich habe vor mir Zusatzinformationen zu den einzelnen Produkten zu crawlen und möglichst intelligent zusammenzustellen und angemessen zu platzieren. Moderierte, intelligente Automation von Werbung wird meines Erachtens viel zu wenig im Netz praktiziert.
Adsense und Co sind sicherlich ein richtiger Ansatz. Bei Affiliate-Partnerprogrammen wird den Publishern aber viel zu wenig Flexibilität geboten.
Werbung muss im übrigen nicht immer nervend, sondern kann auch informativ sein!
Also nix für ungut, aber die Versichungswirtschaft ist ein denkbar ungünstiges Beispiel dafür. Ich arbeite als Entwickler und Berater in einem Softwarehaus, das SW für Versicherungsdienstleister herstellt.
Die Versicherungen sind teilweise mit den EDV Anlagen noch im Mittelalter. Manche sind froh, dass da ne AS 400 steht. Da gibt es Standards zum Datenaustausch, an welche sich kaum ein Datenlieferant hält; so nach dem Motto: Hier gehört der Nettobeitrag hin, wir schreiben aber hier Brutto hin und damit basta.
Und Inkompetenzen sowie hausinterne Inkompatiblität sind an der Tagesordnung: Wir können die Daten nicht laut Standard liefern, da ein Teil aus München kommt, der andere Teil aus Köln und die beiden Systeme nicht kompatibel sind (O-Ton EDV Techniker)
Wie soll das dann hausübergreifend gehen?
ist leicht offtopic, aber die Versicherungswirtschaft war schon immer Vorreiter bei der EDV-Nutzung, täuscht Dich imho. D
Hi Robert,
affilinet bietet ebenso eine XML-API, mit der man sich Produktdaten von derzeit 377 Shops holen kann. Dafür hab ich eigens ein Plugin für WordPress geschrieben, mit welchem man ein Produkt mit einem Beitrag verknüpfen kann. Somit kann man seinen eigenen Content + Produktdaten nutzen.
Nähere Infos dazu: swabian.info
Ich setze mittlerweile auf „offline“-Lösungen. Zuerst lade ich sämtliche Daten (vollständig automatisiert) auf meinen Rechner und kann mit diesen dann wesentlich flexibler und schneller(!) entsprechende Produkte und Werbepartner auswählen.
Ich bin mittlerweile von meiner „Offline“-Lösung recht begeistert, weil ich damit wesentlich flexibler bin als wenn ich zB php benutze.
Die dadurch entstehenden Rechnerkapazitäten, die in der Regel auf einem Webserver nicht existieren und die komfortablere Programmierung inkl. Debugging ermöglichen Dinge auf die ich bei Verwendung von Php nie gekommen wäre.
Gruß
[…] interessantes Plugin für WordPress habe ich zufällig in den Kommentaren von (via Robert ) entdeckt. Mit diesem Plugin kann man veröffentlichte Beiträge in WordPress mit […]
Zanox bietet seit einiger Zeit auch eine einfach zu bedienende API an (SOAP/REST-XMl/REST-JSON). Schaut doch mal hier http://wiki.zanox.com/en/Web_Services. Und als Beispiel was möglich ist wird unter http://zac.zanox.com/ kurz dargestellt also seit kreativ.
Viel Spass noch dabei
@#8: (zanox werber) „auch eine einfach zu bedienende API“ von wegen.
eher umständlich zu bedienende API wäre korrekt. Allein diese Authentifizierung …ein graus. da ist die von SOAP-Schnittstelle von Affilinit schon deutlich besser und tatsächlich etwas einfacher zu bedienen. allerdings dafür etwas unzuverlässig…
Ich muss mich meinungsmäßig Daniels offline-Lösung anschließen, ich bastle auch lieber eine schöne Anwendung mit Java und lasse sie lokal laufen anstatt mit diesen „einfachen apis“ und schnittstellen in php rumzufummeln…
Da sind tatsächlich Dinge möglich, an die man sonst wegen den unkonfortablen Art der PHP-Entwicklung gar nicht denken kann…
lokal programmiert es sich einfach „einfacher“