Ecato gibt API frei
Ich dachte schon es wird nie eine deutsche Website geben die es schafft ihre Inhalte per API freizugeben um positive Synergien nutzen zu können. Ecato zeigt, dass es auch anders geht und gibt Entwicklern und Firmen die Möglichkeit daraus profit zu erzielen.
[ad#co-1]
Ich sage ja schon lange, dass deutsche Internetseiten niemals eine Größe von Twitter, Ebay, Amazon und Co erreichen können, solange sie es nicht lernen ihre Inhalte frei zu geben und mit Hilfe externer Entwickler ihre Seite bekannt machen. Den meisten Betreibern ist es jedoch wichtiger ihr Einkommen durch Abmahungen zu finanzieren. Es gibt jedoch noch ein Licht am Ende des Tunnels und vielleicht ziehen ja endlich auch mal deutsche Seiten nach und lernen aus dem Vorbild Ecato.
Ecato ist ein Marktplatz-Netzwerk bei dem man ohne großen Aufwand, wie bei Max von allblogs.de nachzulesen, seine eigene kleine Shoppingseite integrieren kann und pro Klick 10 Cent verdient.
Am 21.12. hat Ecato nun seine Shopping-Api freigegeben und zeitgleich einen Wettbewerb zur Entwicklung eines WordPress Plugins ins Leben gerufen. Als kleines Leckerbissen erhält der Entwickler eine 5% Lifetimeprovision auf alle Verdienste die mit dem Tool erzeugt wurden.
Ich selbst habe mir gestern und heute die API etwas genauer angesehen und finde sie recht übersichtlich. Ein großer Vorteil ist in meinen Augen, dass man die Responses sowohl als XML, als auch als JSON erhalten kann, weil ich JSON als sehr viel Sinnvoller und vor allen Trafficsparender empfinde, als das Mitschleifen des gleichen Wortes im Start- und Endtag und das diverse Male. Sie ist sehr einfach zu bedienen und wenn man einmal einen API Aufruf getätigt hat, stehen alle möglichen folgenden API Urls in dem Response.
Etwas unglücklich finde ich, dass man sehr viele Aufrufe benötigt bevor man vom ersten Aufruf zum ersten Produkt gelangt weil man erste alle Unterkategorieren bis zur Untersten Ebene durch muss, ich denke das wird den Server stark belasten. Zudem scheint es so, als wäre die Application ID nötig für die Provision, diese könnte man jedoch schnell in den Quellen des WordPress Plugins ändern und so dem eigentlichen Entwickler die Provision streitg machen – aber vielleicht habe ich da auch irgendetwas übersehen und die Provision wird irgendwie anders dem Entwickler zugeordnet. Als dritten Kritikpunkt muss ich noch anfügen, dass man seine Internetseite erst für ein Plugin anmelden muss und die ID der Internetseite nicht identisch mit der ID in der shop_offer_url ist. Wenn man also 2 oder mehr Webseiten hat muss man jedes mal die API Calls wiederholen.
Ich werde die Feiertage auf jeden Fall nutzen und neben der HTTP Klasse in ANSI C noch zwei kleinere Plugins hacken.
Kommentare
3 Kommentare
Danke zunächst für das Lob und konstruktive Feedback!
Gern gehe ich natürlich auch auf die Kritikpunkte ein:
1. Die Kritik am langen Weg zum ersten Produkt kann ich nicht nachvollziehen, da doch schon beim Aufruf der ersten Ebene „top_products“ enthalten sind.
2. Da die Entwicklerprovision nicht vom Verdienst der Publisher abgezogen wird, sehe ich keine Gefahr, dass jemand dem Entwicklter seine Vergütung streitig macht. Zudem werden die Anwendungen von uns geprüft, wodurch uns soetwas auffallen würde. Auch ist der Anwendungsschlüssel nicht das einzige Zuordnungskriterium, denn es muss auch immer eine Zuordnung zur Website über unseren Kundenbereich stattfinden, wodurch wir die volle Kontrolle haben.
3. Es ist richtig, dass die ID im Tracking-Link von der Website-Nummer abweicht. Im Regelfall sollte das aber kein Problem machen. Da wir die API-Inhalte für jede Website individuell aufbereiten (u.a. um doppelte Inhalte aus Suchmaschinen-Perspektive zu vermeiden), ist ein erneuter Aufruf je Website ohnehin zu empfehlen.
Vielen dank für Ihre Reaktion.
zu 1tens : Das „Problem“ ist, dass man für eine Untergruppe z.b. Herrenhosen erst in der 3ten Subkategorie aufs Ergebnis kommt. schöner wäre ne Abfrage aller Gruppen und Untergruppen, damit man eine Auswahlliste ohne Aufwand aktuell darstellen kann.
zu 2tens : Da jeder eine Applikation anlegen kann wäre es kein Problem eine Appliaktion mit rudimentären Funktionen anzulegen, die Domain bei dem eigenen Plugin und bei dem „gut“ programmierten zu aktivieren und bei dem „gekaperten“ Plugin dann die ID zu ändern. Wenn dies aber manuell geprüft wird und noch weitere Sicherheitsmechanismen exisiteren, sollte das wohl ausreichend sein.
zu 3tens : Dass sich der Inhalt der API ändert stand nirgends, wenn dies so ist, macht es natürlich Sinn.
Schön wäre es, nun da ich noch ein bissl weiter mit der API gearbeitet habe, wenn man mittels Abfrage auf mehr als ein Artikel mittels einer Liste von article_ids zugreifen könnte (z.b. für Preisverlaufsanalysen einer Kategorie, einer speziellen Marke oder sonstiges) und man eine API bekommen könnte bei der alle Kategorien und Unterkategorien gelistet werden.
Mir ist selbst noch etwas negativ aufgefallen, dass pro Unterkategorie mit products nur maximal 1000 Artikel bereitgestellt werden.
Die Anregung zu 1. haben wir im Feedbackforum aufgenommen, so werden Sie auch direkt über deren Bearbeitung informiert.
Zu 2.: Solch ein System wird wohl nie ganz ohne Lücken sein, aber wie gesagt sehe ich hier gar keine große Motivation für Dritte. Für die Nutzung einer eigenen Anwendung erhält man nämlich selbstverständlich keine zusätzliche Entwicklerprovision. Insofern wäre der Aufwand, um einem Entwickler seine 5% streitig zu machen schon recht groß. Und wie gesagt, am Ende muss das dann auch noch einer Prüfung durch uns standhalten.
Auch die Anregung hinsichtlich der Übergabe mehrerer Product-IDs habe ich mal stellvertretend im Feedbackforum eingetragen.