Plattformen als Distributionskanäle

VC Fred Wilson (Union Square Ventures, Investor unter anderem in Twitter, Tumblr, Etsy) in seinem viel zitierten Marketing-Artikel über die Bedeutung von Plattformen, bzw. hier im Speziellen APIs:

Developers – I’ve said many times that developers are the new power users. Twitter is the iconic example. By launching with an almost totally open plaform and a dead simple API, Twitter got thousands of developers to build products that had “Twitter inside.” Those developers and their products pulled Twitter into the market. Soundcloud is another great example. There are a ton of apps that people use to create music and other audio experiences that have “soundcoud inside.” Each and every one of those apps is a distribution channel for soundcloud. They are pulling Soundcloud into the market. So build your product as platform from day one. And once you get traction on your product, do things that will cause it to become a platform, Foursquare is doing this well. They first got millions of users and now they are developing a vibrant ecosystem of third party developers. They did a hackday this past weekend that was very successful.

Ich würde nicht empfehlen, von Anfang eine Plattform anzubieten. Das ist in den meisten Fällen nicht notwendig. Aber für die meisten Startups gilt, dass die Evolution zur Plattform in der Roadmap von Anfang an drin sein sollte. Wie Wilson bereits schreibt: Sobald das eigene Produkt eine gewisse Verbreitung hat, wird es Zeit die Plattform zu implementieren.

SCVNGR: International verfügbar dank Googles Places-API

SCVNGR ist die erste App, die Googles neue Places-API nutzt. Dafür hat das fünf Monate alte SCVNGR die eigene Location-Datenbank aufgegeben.

ReadWriteWeb über die Vorteile für das kleine Startup, die durch die Nutzung der API entstehen:

As the company’s founder and “Chief Ninja” Seth Priebatsch told us yesterday, switching to the Google Places API allowed SCVNGR to quickly scale globally, as it can now rely on Google’s extensive location database to power its service. SCVNGR users will now also be able to create challenges and treks – the central gaming elements on the service – at all of these locations. As we noted when Google first announced it, the Places API “could do for check-ins what Google Maps did for maps.” As Priebatsch told us, the fact that Google gave his company access to this comprehensive global database with millions of locations made switching to it a no-brainer.

Das ist der Vorteil, wenn man als Startup auf eine API/Plattform aufsetzt: Man kann auf ressourcenintensive Arbeiten verzichten und sofort in Dimensionen skalieren, die sonst nicht oder nur schwer möglich. In diesem Fall bedeutet das sofortige globale Verfügbarkeit.

Die Nachteile sind auch offensichtlich: Startups wie SCVNGR machen sich abhängig vom API/Plattform-Provider. Gleichzeitig besteht kein Wettbewerbsvorteil in diesem Bereich gegenüber Konkurrenten, wenn alle Marktteilnehmer Zugriff auf die API haben können.

Also selbst bauen oder auf API setzen?

Die Frage ist natürlich, wo in der Wertschöpfungskette in dem jeweiligen Markt Mehrwert entsteht und Differenzierungspotential möglich ist.

Für SCVNGR, das neu im Markt ist und gegen sich just etablierende Dienste wie Foursquare behaupten muss, ist der Einsatz von Googles Places-API zum Beispiel in der Tat ein Nobrainer.

Andere Plattformen wie Facebook-Orte machen diese Ebene der orstbezogenen Dienste bereits zum Gebrauchsgut, was Differenzierungsmöglichkeiten in diesem Bereich für Startups erschwert. Der Fokus muss sich also zwangsläufig verschieben.

Siehe auch meine Übersicht zum Thema zum US-Launch von Facebook Orte/Places:

ReFlattr: Regelmäßige aboähnliche Zahlungen mit Flattr

Mit Flattr werden Klicks zu Zahlungen. Der monatlich bei Flattr eingezahlte Betrag wird auf die mit Flattr getätigten Klicks aufgeteilt. Der Nachteil: Wer eine Publikation jeden Monat konstant unterstützen will, hat keine andere Wahl als immer wieder zu klicken.

Hier kommt ReFlattr ins Spiel. ReFlattr wird über die API das regelmäßige Flattrn ermöglichen:

You can signup, using any name you want, you don’t even need an emailaddress to use ReFlattr (although it might be a good idea to supply one so you can reset your password in case you forget or lose it). After that you can link your Flattr account with your ReFlattr account, without giving out your password! From there on out, you can see on Reflattr what you have flattred this month and select those things that you wish to be flattred again. You have the choice between no ReFlattr (same as now), ReFlattr forever (or until you run out of means/change it in ReFlattr) and ReFlattr X times, where you can enter a number of how many times it sould be ReFlattred. At the beginning of each month, ReFlattr will Flattr in your name the things you chosen.

ReFlattr befindet sich aktuell in der Alpha-Phase und ist noch nicht öffentlich nutzbar. Gebaut wird ReFlattr vom Schweizer Christian Riesen. (via)

Sinnvoll wäre ein solches Feature sicher auch bei Flattr selbst.

Die Flattr-API wird mit Sicherheit auch einige weitere spannende Applikationen hervorbringen, die den Bezahlvorgang im Netz weiter revolutionieren könnten.

Spannend in dem Zusammenhang ist auch, was Tim Pritlove vom Flattr-Team erfahren hat:

Derzeit ist flattr vor allem mit der Implementierung und dem Rollout ihrer API beschäftigt. Auf der Konferenz erfuhr ich dabei noch ein wichtiges Detail, dass mir bislang entgangen war: wer das API auf seiner Website implementiert und Flattr-Klicks für andere entgegennimmt (das könnten z.B. Community-Sites, Archive, Entwicklerplattformen), erhält für die “Vermittlung” des Flattr-Klicks Provision von Flattr. Der Betrag geht allerdings von dem Flattr-Anteil (der derzeit noch bei 10% liegt), so dass also beim eigentlichen Empfänger des Klicks nicht abgezogen wird sondern Flattr quasi sein Geld mit dem “Distributor” (so nennen sie das) teilt.

Das ist genau die richtige Erschaffung von Anreizen, um ein Ökosystem rund um die API und die Flattr-Plattform aufzubauen.

Ein ReFlattr-ähnliches Feature scheint auch geplant zu sein:

Allen voran denkt man an die Verankerung einer regelmäßigen “Beflatterung” von “Things”, so daß man Dinge, die man regelmäßig über Flattr bedenken möchte, quasi ein Klick-Abo einrichten kann. Wie das Feature dann genau funktioniert (ich habe z.B. einen Timeout angeregt, nach dem das Abo automatisch abläuft) und wann es kommt ist aber noch unklar.

Facebook Places, Google Places, Foursquare & co.: Das ortsbasierte Web

Jetzt werden sie Mainstream: Mit dem Einstieg von Facebook in das Geschäft ortsbasierter Dienste geht der Boom jetzt richtig los. Aber Facebook ist nicht der einzige Plattformprovider auf dem Markt ortsbasierter Dienste. APIs und Plattformen ermöglichen bereits unzählige Mashups und innovative Ansätze.

Ein Überblick über das aktuelle Angebot und die Aussichten.

Inhalt:

Facebook Places

facebook-placesFacebook Places ist letzte Nacht in den USA gestartet und wird stückweise weiter ausgerollt. Wahrscheinlich wird Facebook Places in den nächsten zwei Tagen auch in Deutschland ankommen (“a roll out over the next day or two”).

Die wichtigsten Merkmale

  • Auch Facebook Places ist check-in-orientiert.
  • Check-Ins auf Facebook Places sind per default nur für Freunde sichtbar. (Abgesehen von den Check-In-Anzeigen auf den Profilseiten der Orte, die für jeden sichtbar sind.)
  • In der Nähe befindliche Facebook-Nutzer werden anderen Facebook-Nutzern beim Check-In im “People Here Now”-Bereich angezeigt. Diese Anzeige ist zeitlich beschränkt. Außerdem kann man sich aus der Auflistung austragen.
  • Man kann eigene Freunde in Orten einchecken. Das nennt Facebook “taggen”. Eine interessante Funktion, die die Check-In-Häufigkeit erhöhen dürfte, aber auch für einige Irritationen sorgen wird. (Lässt sich ebenfalls deaktivieren.)
  • Orte besitzen eigene Profilseiten. Facebook hat bereits einen How-To-Guide zum Einrichten veröffentlicht.
  • Die neue Funktion steht über die iPhone-App und die Touch-Seite von Facebook zur Verfügung.
  • Facebook setzt bei den Karten auf Bing statt auf Google Maps, das in der Regel von vergleichbaren Diensten genutzt wird.
  • Die Check-Ins werden im Newsfeed der Nutzer mit einem Kartenausschnitt von Bing angezeigt. Die Nutzer können sich dort auch gleich eine Wegbeschreibung über Bing anzeigen lassen.
  • User können auf Facebook nicht vorhandene Orte anlegen. In den USA arbeitet Facebook außerdem mit Localeze für das Verzeichnis von Places-Seiten zusammen.

Facebooks Place-Seiten werden für Geschäfte enorm wichtig werden. Wie TechCrunch ausführt, werden diese Seiten eine enorme Masse an Daten beinhalten:

Many businesses have already been flocking to Facebook as both and advertising and marketing platform, and now they can have their address, map, phone number, PLUS all the public social activity that is going on at a location. A merged Places page will include a considerable amount of information, including the number of check-ins, who checked-in to a place, number of Likes, the Places’ Wall, and more.

Screenshot einer Places-Seite auf Facebook:

Facebook Places Seite

Facebooks Plattform-Ansatz und die Facebook-Places-API

Facebook setzt wie zu erwarten war auch bei seinem ortsbasierten Angebot auf den Plattformansatz.

Die API zu Facebook Places wird vorerst nur lesbar sein. Das heißt, es wird zunächst über die API nur möglich sein, Check-Ins bestimmter Nutzer und für bestimmte Orte auszulesen und die Check-Ins von Freunden eines Nutzers zu erfassen. (Die API wird künftig dreigeteilt sein und read, write und search umfassen.)

Lediglich die Launch-Partner Yelp, Booyah, Foursquare und Gowalla haben vollen Zugriff auf die les- und beschreibbare API. Abgesehen anscheinend von Foursquare, was für einen “Launch-Partner” zumindest eigenartig ist.

Wie dem auch sei, das Ziel von Facebook ist klar: Mit der bald verfügbaren beschreibbaren API will Facebook zu der Plattform für Check-Ins und damit langfristig auch für lokale Informationen werden. Und die Chancen dafür stehen gut.

Interessant für Entwickler in diesem Zusammenhang ist auch, dass Facebook jüngst zu seinem iPhone-SDK die Social Graph API und OAuth 2.0 hinzugefügt hat:

Last week, Facebook brought its technology to iOS by introducing a new version of the Facebook SDK for iPhone, iPod Touch and iPad enhanced with the Graph API and OAuth 2.0 protocol. Together with the already available Facebook SDK for Android, you can now utilize both APIs and build social apps across two major mobile platforms.

Google Places API

Google setzt mit seinem ortsbasierten Dienst Latitude auf das Loggen des Standorts statt auf die Ein-Klick-Geste Check-In. Nichtsdestotrotz hat Google mit seiner Places API eine API für Check-Ins eingeführt; wohl nicht zuletzt als Präventivschlag gegen Facebook Places.

ReadWriteWeb hat zum Launch spekuliert, dass Googles Places API für Check-Ins sein könnte, was Google Maps für Online-Karten war. Google Maps hat Online-Karten nicht nur zu etwas allgemein Verfügbarem gemacht, sondern außerdem unzählige Mashups ermöglicht. (bis dato basieren die meisten Mashups auf Google Maps)

ReadWriteWeb über die API:

Developers building apps that include a “check in at this place” feature can use the Places API to search across all the places users might check in for basic information like business name, address, phone number and other descriptive information. That information will be editable by the businesses listed and no caching of data is allowed, so apps will have to ping Places regularly for real-time data.

Die Aussage von ReadWriteWeb über Googles Places API dürfte meines Erachtens aktuell eher auf Facebook Places zutreffen: Facebook Places wird für Check-Ins sein, was Google Maps für Karten war.

Aktuell hat Google gegen Facebooks Gesamtangebot keine Chance. Deshalb fällt auch Googles Places API gegen Facebook Places ab. Aber wer weiß, wenn Googles Places API clever in Googles kommenden Facebook-Konkurrenten integriert wird, könnte sich das auch wieder ändern.

APIs von Foursquare, Gowalla und co.

Foursquare hat bereits seit längerem eine beschreibbare API und erhält seit längerem auch bereits über 20 Millionen Zugriffe pro Tag auf die API. Seit Anfang August ist auch die API von Gowalla beschreibbar.

Foursquares API hat bereits einige interessante Mashups hervorgebracht und ist ein wichtiger Teil der Strategie von Foursquare .

Neben weiteren APIs mit ortsbasierten Informationen ist ein Dienst noch gesondert zu erwähnen: SimpleGeo, eine Plattform für geographische Daten :

SimpleGeo launched its highly anticipated geographic data platform (our SimpleGeo API profile) and announced a data marketplace. The platform allows developers to store up to 1 million points of their own data for free. Once the data is on SimpleGeo, you can do lookups, such as finding the closest points.

Ein weitere Übersicht über APIs für ortsbasierte Daten hat O’Reilly Radar im April veröffentlicht.

Fazit

Künftig kommt man im ortsbasierten Segment nicht mehr an Facebook mit seinen über 500 Millionen aktiven Nutzern vorbei. Spätestens wenn die API beschreibbar wird, werden bald viele auf die neue Funktion aufsetzende Apps das Licht der Welt erblicken.

Facebook wird mit dem Sog, den seine 500 Millionen Nutzer erzeugen, aller Wahrscheinlichkeit nach das erreichen, was viele, inklusive Google, versuchen aber noch nicht geschafft haben: Ein umfangreiches Verzeichnis lokaler Geschäfte.

Während ich mir vorstellen kann, dass das innovative Foursquare, das unter anderem den Check-In erfunden hat, einen Mehrwert über Facebook hinaus finden wird, wird es für andere Check-In-Dienste schwer. Es ist durchaus wahrscheinlich, dass Dienste wie Gowalla ihre Nische künftig als Client für Facebook Places finden werden. Da Facebook bis dato eine konsequentere Plattform-Strategie als Twitter verfolgt, ist das nicht die schlechteste Aussicht für diese Dienste. Zusätzlich werden ortsbasierte Dienste künftig mehr Richtung Mashup denn selbstständiges Angebot gehen. So wie heute kein Dienst seine eigenen Karten bereitstellt, muss künftig kein Dienst mehr seine eigene Check-In-Infrastruktur bereithalten.

Naturgemäß werden Clients mit integriertem Multihoming für Facebook Places und andere Check-In-Dienste mit beschreibbarer API das Licht der Welt erblicken, sobald Facebooks Places-API beschreibbar wird. Apps wie Future Checkin, das automatisch in Lieblingsorte auf Foursquare eincheckt, drängen sich dafür förmlich auf.

Zusätzlich werden viele Dienste wie die Launch-Partner von haus aus eine Integration in Facebook Places anbieten(dank 500 Millionen Nutzer). Ähnlich wie man es bereits von Twitter und den Status-Updates auf Social Networks von Facebook, über VZ-Netzwerke bis LinkedIn kennt, wird Facebook Places überall integriert werden.

Twitter bietet sich gut als Vergleich an: Facebook Places wird aller Voraussicht nach das Twitter für Check-Ins werden. Überall integriert, wo es sinnvoll um Check-Ins geht.

Alle APIs, die zusätzlich neben Facebook Places noch existieren, decken den Infrastruktur-Markt für ortsbasierte Dienste gut ab. Das ist für neue Anbieter nicht schlecht, im Gegenteil: Jetzt ist ein hervorragender Zeitpunkt, um als Startup die vorhandenen Plattformen zu nutzen und mit geringstem Mittelaufwand zu experimentieren und spannende neue Ansätze (Beispiel: Info über Geschlechterverteilung in der Lieblingsbar via Foursquare) zu finden, was man auf die bestehenden Angebote aufbauen kann.

Das ortsbasierte Web wird nicht lang Brachland bleiben. Das FarmVille der Check-Ins dürfte nicht mehr weit weg sein.

Die Open Bank API

Das Open Data Network berichtet über das Open Bank Projekt und die Open Bank API:

Dazu soll eine offene API entwickelt werden, die es erlaubt Finanzinformationen entweder mit allen oder nur einem bestimmten Personenkreis zu teilen um so für mehr Transparenz zu sorgen.

[..]

So können z.B. Regierungen und öffentliche Verwaltungen diese Schnittstelle Nutzen um Subventionen und andere Staatsausgaben transparenter zu dokumentieren. Empfänger staatlicher Subventionen könnten also verpflichtet werden, direkt Rechenschaft über empfangene Mittel abzulegen.

Eine Disruption in diesem Bereich ist notwendig und wäre sehr spannend. Fraglich bleibt, wie so ein Projekt an den etablierten Stellen vorbeikommen soll, die es teilweise ersetzen oder zumindest in ihrem Wirkungskreis bedrohen würde.

Aktuell such das Projekt noch nach Kooperationspartnern und hat EU-Fördergelder beantragt. Auf der Website des Projekts gibt es noch nichts zu sehen.

Update: Ausführlicher Artikel zur Open Bank API auf netzwertig.com.

Google Buzz bekommt auf offene Standards setzende API

Google hat für Google Buzz die erste vollständige API mit komplettem Lese- und Schreibezugriff vorgestellt.

Die API setzt umfänglich auf offene Standards:

the Google Buzz API aligns itself with the ever-growing family of freely available and community-developed protocols, formats, and standards for sharing and consuming social content on the web, including ActivityStreams, Atom, AtomPub, JSON, OAuth, PubSubHubbub, MediaRSS, PortableContacts, and more.

Zum Start haben sich auch bereits ein paar namhafte Partner finden lassen, die die Google-Buzz-API integrieren:

BuzzAPI-logosall

Mit Seesmic und TweetDeck sind darunter auch bereits zwei Anbieter von Twitter-Clients zu finden. Wenig verwunderlich, dass diese bei der Buzz-API anspringen, müssen sie doch seit April zuschauen, dass sie sich gegen Twitters neue Strategie absichern können.

Es wird spannend zu beobachten sein, wie Google Buzz sich nun entwickeln wird, da mit der API jetzt der eigentliche, dahinterstehende Plattformgedanke in den Vordergrund rücken kann.

Über Googles Langzeit-Strategie mit Google Buzz schrieb ich im März diesen Jahres:

Was Google mit Buzz plant ist, die Verbreitung von offenen Standards voranzubringen, denn nur weit verbreitete offene Standards haben zu diesem Zeitpunkt noch eine Chance gegen Facebook. Google will gleichzeitig mit Buzz dabei zum wichtigsten Hub für die Verknüpfung der einzelnen Angebote werden. Jeder Websitebetreiber, der auf offene Standards setzen will, hat eigentlich erst mit Google Buzz einen gewichtigen Grund gefunden.

Mit der nun vorgestellten Buzz-API beginnt die zweite Phase von Google Buzz.

Es bleibt abzuwarten, ob Googles Plan aufgeht:

Und Google macht das, was es immer macht: Leveling the playing field. Und dabei selbst im Zentrum stehend, das Chaos organisierend.

Die Chancen dafür stehen allerdings gut. Nicht zuletzt, weil Google sich einen langen Atem und eine konsistente Plattformstrategie leisten kann. Beides Voraussetzungen für das notwendige Vertrauen, das Drittanbieter haben müssen, um in eine Plattform zu investieren.

Die API-Dokumentation für Entwickler findet man hier.

Programmierschnittstellen, Facebook und Twitter

Ich habe auf netzwertig.com mal wieder einen Artikel über die Bedeutung von APIs und anderen aktuell wichtigen Konzepten geschrieben, die bei der Betrachtung bezügl. der Bedeutung von Facebook und Twitter oft unterschätzt werden:

 

“Es gibt drei Gründe, warum Facebook, Twitter und co. mit relativ hoher Wahrscheinlichkeit nicht mehr verschwinden und stattdessen noch weiter wachsen werden:

  1. Die Nutzung ist für viele User zu einem Bestandteil ihres Alltags geworden. Die Angebote sind für viele so wenig wegdenkbar wie Mobiltelefone.
  2. Das Follower-Prinzip sorgt für eine Skalierbarkeit der Community, weil die Größe des Angebots keinen oder zumindest keinen direkten Einfluss auf die Wahrnehmung des Dienstes durch den einzelnen Nutzer hat.
  3. Am wichtigsten aber sind die Programmierschnittstellen (APIs), welche sicherstellen, dass die Dienste auf verschiedenste Arten vom Nutzer angesprochen und genutzt werden können und die künftige Bedeutung sicherstellen.”

weiter:
Programmierschnittstellen: Facebook und Twitter sind gekommen, um zu bleiben