Wir haben 2 Feeds eingebaut, wobei der Artikelfeed noch schöner werden wird.
Für Empfehlungen: http://shoppero.com/feed/empfehlung/atom
Für Artikel: http://shoppero.com/feed/produkte/atom
Sollten wir eigentlich auch Feeds im RSS-Format einbauen? Oder reicht das Atom-Format?
Hier im Weblog war es die letzten Tage eher still, was daran liegt, dass es nichts zu berichten gab. Es gibt sie also noch, die einfachen Wahrheiten…
Das Team unter der Leitung von Malte bastelt gerade ziemlich eifrig an den Innereien von Shoppero rum, damit etliche der Themen, die in den letzten Wochen bemängelt wurden und auch die vielen Vorschläge unserer User zügigst auf Shoppero sichtbar werden. Wir haben natürlich zu allererst angefangen, die Sicherheitslücken zu stopfen, da würde ich mal nonchalant von einem “ongoing process” reden, bei dem wir ein gutes Stück der Wegstrecke hinter uns gebracht haben, aber da gibt es sicherlich immer wieder “room for improvement”. Dann haben wir die Datenbankstruktur noch einmal angepackt und einige Sachen durchaus cleverer gelöst, was aber sicherlich für den Aussenstehenden eher verborgen bleiben wird. Vernünftige URLs stehen derzeit ganz oben auf der Tagesordnung, aber eben auch mehr und bessere Adget-Formate. Für bekennende Freunde von Microformats tun wir gerade auch einiges und ganz nebenbei wollen wir noch die Usability verbessern. Und und und.
Es gibt gerade enorm viel zu tun, aber dafür ist Shoppero eben auch ein frisches Startup und da soll es so sein, dass die Entwickler das Produkt stetig vorantreiben.
Letzte Woche durfte ich Holgi beim Trackback zum Konsum einige Sätze ins Mikro sagen, die dann im Rahmen der Sendung noch einmal aufgegriffen und mit Kosmar und Xsized diskutiert wurden. PaulinePauline hat dann noch das Thema Social Shopping näher beleuchtet.
“Die Sicherheitslücken waren unschön” nimmt Alexander bei deutsche-startups.de als Aufhänger für ein Interview über Shoppero und die ersten beiden rasanten Wochen.
Wir machen gerade unsere Hausaufgaben, arbeiten also das umfangreiche Feedback nach unserem Start in den Code ein. Ersteinmal reift vieles unter der Haube, sichtbare Änderungen wird es dann auch zügig geben.
Guten Tag zusammen, ich heisse Malte Diedrich, blogge seit einigen Jahren unter Treehuggin’ Pussy und arbeite mit Nico zusammen seit einigen Wochen bei Shoppero. Zuständig bin ich für die Technik und beschäftige mich zur Zeit vor allem mit der Koordinierung der Programmierer. Durch den sehr schnellen Aufbau und die damit verbundene Arbeit komme ich erst jetzt dazu, etwas zur Technik zu schreiben, bedanken möchte ich mich an dieser Stelle auch für die zahlreichen Hinweise auf Fehler und Verbesserungsmöglichkeiten, die wir zur Zeit abarbeiten. Sowohl die Mails an improvements@shoppero.com als auch die zahlreichen höflichen und wohlwollenden Anregungen aus der Blogosphäre werden gerne gelesen und umgesetzt (auch wenn wir vielleicht nicht immer jedem antworten können). Ich möchte hier besonders Björn Schotte und Fukami hervorheben, die uns in den letzten Tagen sehr geholfen haben.
Wie bereits erwähnt, läuft Shoppero auf einem Webdienst von Amazon, Electronic Cloud Computing (EC2). Amazon stellt hierbei virtuelle Server zur Verfügung, die man nach Belieben zu- und abschalten kann.
Wir ersparen uns damit den tatsächlichen Umgang mit Hardware und vertrauen darauf, dass die Ingenieure bei Amazon ein Rechenzentrum besser betreiben können als wir.
Um einen Server bei Amazon zu starten, sucht man sich ein Image aus und startet dieses Image über eine Verwaltungsoberfläche oder eine Kommandozeile. Nach ein 2-3 Minuten steht die Maschine dann zur Verfügung, man fragt die IP ab, schaltet bei Bedarf bestimmte Ports frei und kann loslegen. Ab diesem Moment zahlt man auch. Wenn man das Image durchgespielt hat, fährt man es wieder runter und braucht auch nichts mehr zahlen. Nach Amazons Angaben hat man ein Xeon 1,7 GHz Equivalent mit 1 GByte RAM und 160 GByte Speicherplatz zur Verfügung.
Technisch gesehen sind die virtuellen Server Xen-Images. Diese werden entweder von Amazon zur Verfügung gestellt oder von uns selbst hergestellt, wobei man dies praktischerweise gleich auf den Servern von Amazon machen kann und nach dem Bootstrapping mithilfe der Amazon EC2-Tools nach S3 hochgeladen werden. Dort stehen sie dann zur eigenen oder allgemeinen Benutzung zur Verfügung. Es ist auch möglich, eigene Images wieder einzupacken und zurück bei S3 zur Speicherung abzulegen, wodurch wir inzwischen für die Datenbankserver und die Webserver fertige Vorlagen haben, die wir beim Start nur noch kurz aktualisieren müssen und so in kurzer Zeit die Leistung vervielfachen können. Auch wenn wir dies zur Zeit noch per Hand machen, grundsätzlich kann man den gesamten Vorgang auch soweit automatisieren, dass das Gesamtsystem je nach Last quasi mitwächst und wieder kleiner wird. Auch können wir schnell einen Testserver hochziehen, bestimmte Dinge ausprobieren und die Kiste danach wieder wegwerfen.
Wirtschaftlich gesehen ersparen wir uns durch den EC2 Service eine Menge Ausgaben am Anfang des Unternehmens und können die Technik parallel mit dem Wachstum der Seite wachsen lassen. Es wird spannend zu beobachten, ob sich der anfängliche Kostenvorteil später verstärkt oder es zu einem Zeitpunkt günstiger werden wird, eigene Server zu betreiben.
Und um die häufigste Nachfrage gleich zu beantworten: Ich weiss auch nicht, nach welchem System Amazon Leute zu EC2 einlädt und wie man diesen Vorgang beschleunigen kann.
“Die Grundidee hinter Shoppero ist die, dass User anteilig am Erfolg der Plattform partizipieren sollen.” sage ich im Interview mit dem Interview-Blog und versuche damit, den Kern von Shoppero kurz und knackig wiederzugeben. Desweiteren gehe ich kurz auf die Resonanz zu Shoppero innerhalb der Blogosphäre ein und verrate, wie ich mir den Ausblick für Shoppero in 5 Jahren vorstelle.
In einigen Blogs wurde aufgeregt über Shoppero und das Urheberrecht sowie eine Abmahnmascherine geschrieben, die in Zusammenhang mit unseren AGB entstehen soll. Inbesondere wird bemängelt, dass unsere AGB die Haftung für die Verletzung von Rechten Dritter auf die Nutzer überträgt.
Mal abgesehen, dass sich ein solcher Passus in den AGB einer jeden Plattform wiederfindet, bei der User selber Inhalte einstellen dürfen, möchte ich an dieser Stelle auf zwei Sachen hinweisen:
1. Die Verantwortung für eine Verletzung Rechte Dritter durch unsere User trägt natürlich der User selber. Wie sollte es anders gehen?
2. Es handelt sich bei Shoppero überwiegend um Produktfotos, die von den Herstellern zur Nutzung verfügbar gemacht worden sind.
Zusammengefasst lässt sich sagen, dass bei diesem Thema viel Lärm um nichts entfacht wurde. Die Nutzung einer Plattform bedeutet keinen Freifahrtsschein für mögliche Rechtsbrüche, das ist nichts Neues. Im Normalfall allerdings meldet sich ein betroffender Dritter bei dem Betreiber der Plattform, schildert sein Anliegen, setzt evtl. eine Frist und dann gehen wir los, prüfen den Sachverhalt und nehmen dann ggf. das beanstandete Bild runter.
Kosmar diskutiert gerade das von ihm so bezeichnete 80% Mißverständnis von Shoppero und Robert Basic widmet sich auch der Frage nach der Einnahmeverteilung bei Shoppero, während Jochen Krisch allgemeiner auf Widgets und Werbung eingeht. Ich bin sehr dankbar, dass nun auch der Kern von Shoppero einmal etwas breiter diskutiert wird, denn in der Tat ist unser Erlösmodell nicht auf den ersten Blick zu greifen und zieht ein paar Fragen nach sich.
Ich hole einfach mal etwas weiter aus und erläutere das Modell noch einmal im Detail und gehe dann auf unsere Ideen ein, die zu dem Modell geführt haben.
Wie werden die User bei shoppero an den Einnahmen beteiligt?
Unser User können über zwei Komponenten an den Einnahmen beteiligt werden, die Shoppero aus der zentralen Vermarktung und aus möglichen Affiliate-Links erzielt - einerseits durch die Artikel, die sie schreiben, und andererseits durch die Besucher, die sie auf shoppero schicken.
Wenn beispielsweise über mein Adget einer meiner Leser auf shoppero geht und dort 10 Seiten aufruft, dann bekomme ich 60% der Einnahmen, die shoppero auf diesen 10 Seiten erzielt. Genauer gesagt wird der Anteil dieser 10 Seitenaufrufe gemessen am gesamten Traffic-Aufkommen auf den von Usern erstellten Produktseiten genommen und davon wiederum die 60%.
Und:
Die Autoren werden mit 20% an allen Einnahmen beteiligt, die auf den Produktseiten entstehen. Wovon ich 20% bekomme, berechnet sich daraus, wie hoch der Anteil meiner Produktseiten am Traffic auf allen Produktseiten ist: Wenn auf meinen Produktseiten 1% des Traffics aller Produktseiten entsteht, bekomme ich 20% von 1% der gesamten Einnahmen, die shoppero auf Produktseiten erzielt hat.
Warum machen wir das so?
Ausgangspunkt für die Idee hinter Shoppero war die Frage nach der Beteiligung der User an den Einnahmen, die durch sog. User-generated Content erzielt werden und die Frage nach User-Generated Advertising. Wir sehen derzeit jede Woche wieder eine Fülle von neuen Plattformen, die den User auf irgendeine Art und Weise einbeziehen und deren Geschäftsmodell so aussieht, dass sie einen Rahmen bieten für User, damit die sich austoben, sprich: Inhalte erstellen, damit dann die Plattformen diese Inhalte vermarkten und damit Geld verdienen. Das ist ein redliches Vorgehen, keine Frage, aber wir wollen mehr, wir wollen die User zusätzlich auch an den Werbe-Einnahmen beteiligen. Dabei entsteht natürlich immer ein Problem, nämlich eine mögliche tendenziöse Schreibe, denn oftmals wird der User nur erfolgsabhängig an den Einnahmen aus seinen Inhalten beteiligt. Das Stichwort hier ist Affliate und da dürfte jedem klar sein, dass da die Provison nur bei einem Abverkauf fällig ist, die Schreibe eher darauf hinauslaufen wird, ein Produkt anzupreisen. Wir wollen aber nicht, dass User etwas schreiben, nur damit gekauft wird. Wir wollen, dass die User generell an den Einnahmen beteiligt werden, egal ob sie ein Produkt gut finden oder nicht. Also haben wir den Weg gewählt, dass die User an allen Einnahmen, die auf ihren Produktseiten entstehen, mit 20% beteiligt werden. Warum “nur” 20%? Weil das immerhin ein Fünftel ist und wir nicht wollen, dass Inhalte nur deshalb geschrieben werden, weil dafür entsprechendes Geld kommen wird. Wir wollen eine gesunde Mischung erreichen, von Incentivierung durch Geld und eigenem Antrieb.
Der andere Aspekt war die User-generierte Werbung. Da haben wir uns überlegt, dass das Bauen eines eigenen Adget genannten Widgets mit einer Verlinkung zu einem oder mehreren Produkten sicherlich eine gute Idee ist. Damit können User Präferenzen ausdrücken, können gestalterisch tätig werden, können ein passendes Format wählen und können vor allem selber entscheiden, wie penetrant oder zurückhaltend die Werbung sein soll. An der Werbung soll der User dann wiederum finanziell beteiligt werden, das ist ja auch üblich.
Wenn wir uns jetzt das Erlösmodell angucken, dann wird hoffentlich klarer, was wir bezwecken wollen:
1. Wir entkoppeln die möglichen Erlöse etwas vom Inhalt, in dem wir a) den Trafficanteil an den gesamten Seitenaufrufen auf den von den Nutzern erstellten Inhalten zu Grunde legen und von den daraus resultierenden Einnahmen 20% ausschütten, was b) zur Folge hat, dass man zwar weiss, wieviele Seitenaufrufe kamen, aber nicht weiss, genau welcher Text wieviel Anteil an der Gesamtsumme hat, was c) verhindert, dass alle beispielsweise nur über Apple Ipods oder HDTV-Fernseher schreiben, weil sie dort das meiste Geld wittern.
2. Wir zahlen 60% der Werbe-Erlöse, die entstehen, wenn Seitenaufrufe über ein Click auf ein Adget entstehen, anteilig an den von Usern mit Inhalten erstellten Seiten. Wir zahlen also keinen Clickpreis, sondern für alles, was nach dem Click entsteht. Wir gehen davon aus, dass hier der Effekt entsteht, dass User, die ein Adget platzieren auch mit den dahinter zu findenen selber geschriebenen Inhalten in Verbindung gebracht werden wollen und daher auf Qualität achten, da ansonsten weniger Leute auf die Adgets clicken und noch viel schlimmer, gleich danach mit dem Lesen aufhören und die Seite verlassen.
3. Die 20% und die 60% sind also ein Workaround, damit eines nicht passiert: gekaufte Einträge, um es mal auf den Punkt zu bringen. Diese Art des Splits ist auf den ersten Blick kompliziert, wird aber dafür sorgen, dass die finanzielle Beteiligung der User nicht zu Lasten der Inhalte gehen wird.
4. Die finanzielle Beteiligung findet sicherlich im Bereich der Mikro-Monetarisierung statt, d.h. eher ein paar EUR als ein paar tausend EUR. Wir sollten uns aber auch vor Augen führen, wie die Inhalte aussehen, an denen die User finanziell beteiligt werden. Da geht es weder um aufwändige Filme, noch selbstkomponierte Songs oder abgeschlossene Romane, sondern um kurze und knackige Produktbesprechungen.
Nun sollte m.E. das Erlösmodell besser verständlich sein. Es geht um 20% der Werbe-Einnahmen anteilig am Gesamttraffic auf den von Usern mit Inhalten erstellten Seiten und um 60% der Werbe-Einnahmen, die über die Seitenaufrufe über ein Adget entstehen, aber eben auch anteilig an den gesamten von Usern mit Inhalten erstellten Seiten.
Guy Kawasaki schriebt in How to Change the World: The Art of Bootstrapping:
Ship, then test. I can feel the comments coming in already: How can you recommend shipping stuff that isn’t perfect? Blah blah blah. ”Perfect“ is the enemy of ”good enough.“ When your product or service is ”good enough,“ get it out because cash flows when you start shipping. Besides perfection doesn’t necessarily come with time–more unwanted features do. By shipping, you’ll also learn what your customers truly want you to fix. It’s definitely a tradeoff: your reputation versus cash flow, so you can’t ship pure crap. But you can’t wait for perfection either.
Ohne zu wissen, dass Guy Kawasaki dies postuliert hatte (dies wurde von Martin Oetting irgendwo kommentiert), haben wir uns dann doch daran gehalten.
Warum? Weil ich es wichtig fand, mit dem, was wir hatten, zu launchen. So ist Shoppero zwar noch lange nicht perfekt, aber das bislang gesammelte Feedback zeigt uns deutlich, was noch alles geändert werden muß und wo Erläuterungen fehlen.
Bei der Planung von Shoppero kam natürlich irgendwann das übliche Thema Serverfarm auf. Ein riesiger Kostenblock, denn man will ja Redundanz und möglichst auch eine stete Erreichbarkeit gewährleisten, aber auch eine ordentliche Performance, damit die User zufrieden sind, und Skalieren soll das Ganze auch noch. Dazu kommt dann immer das Thema Hands-On Service, der auch teuer ist, es sei denn, man macht ihn selber, aber dann können murksige Netzwerkkarten oder kaputte Festplatten durchaus die Freizeit in Mitleidenschaft ziehen. Ich habe schon einige Serverfarmen geplant und aufgesetzt und irgendwie wollte ich bei diesem Startup auf dieses Nervpotential verzichten.
Zusammen mit Malte habe ich mir dann mal die Amazon Web Services angeguckt, genauer gesagt die Dienste Elastic Computing Cloud (EC2) und Simple Storage Service (S3). Auf den ersten Blick fanden wir das ziemlich ansprechend, auf den zweiten auch. Also haben wir uns für die Nutzung von EC2 und S3 für Shoppero entschieden.
EC2 bietet beliebig viele virtuelle Server-Instanzen an. S3 bietet endlosen Festplattenplatz inklusive Auslieferungsmöglichkeit. In der Kombination haben wir jetzt eine virtuelle Serverfarm mit etlichen virtuellen Servern, die nach Bedarf gestartet oder heruntergefahren werden und schier unendlichen Plattenplatz für die Daten. Praktischerweise werden die Bilder dann auch direkt von S3 ausgeliefert, so dass wir uns hier gar keine Sorgen um eine Skalierung machen müssen, das macht S3 von ganz alleine. Dadurch haben unsere Images derzeit alle einen URL a la s3.amazonaws.com, was wir allerdings nicht weiter tragisch finden. Abgerechnet wird pro Stunde bei EC2 und dann noch pro gehostetes GB und pro transferiertes GB. Für die letzten 4 Wochen haben wir für Setup und Testing unserer virtuellen Serverfarm ca. 80 EUR ausgegeben, was uns durchaus erfreut.
Sicherlich gibt es auch beim Betrieb einer virtuellen Serverlandschaft bei EC2 einige Aspekte, die man beachten muß. Beispielsweise kann man CPU, RAM und Plattenplatz der virtuellen Instanz nicht selber frei bestimmen, sondern nimmt das, was EC2 anbietet. Noch dazu kommt der interessante Begeleitumstand, dass man zwar beim Crash einer Instanz nur knapp 4 Minuten benötigt, um eine neue Instanz zu starten, aber dass dabei sämtliche Daten auf dem virtuellen Plattenplatz der Instanz, immerhin 160 Gb, unweigerlich flöten gehen. Also müssen die Daten für den Fall der Fälle ausgelagert werden, beispielsweise auf S3, weil interner Traffic zwischen EC2 und S3 nichts kostet, oder z.B. durch MySQL Master-Slave-Konfigurationen.
Konzeptionell ist die Kombination von EC2 und S3 höchst interessant und hat uns in der Entwicklungsphase einiges an Arbeit und Aufwand erspart. Und wir hatten bislang keine kaputte Festplatte, jedenfalls haben wir nichts bemerkt.
Der Artikel Geld verdienen in Zeiten der Weblogs von Thomas Knüwer beschreibt recht gut, warum wir Shoppero gestartet haben und was einige der Ideen dahinter sind.
Die Suche nach kreativer Vermarktung von Online-Inhalten geht weiter. Der Online-Dienst Shoppero ist ein weiterer Versuch, mit Inhalten, die in Weblogs und Sozialnetzwerken entstehen, Geld zu verdienen – und gleichzeitig die Nutzer als Autoren zu beteiligen.
Wir haben viel Resonanz auf diesen Artikel erhalten und freuen uns, dass das Thema finanzielle Beteiligung der User auch im Handelsblatt Beachtung gefunden hat, denn es wird ein Thema sein, das in Zukunft immer wichtiger sein wird.
