13. Apr. 2010 Lesezeit: 4 Min.

Zweiseitige Märkte: Multihoming bei Internetplattformen

Dieser Artikel ist Teil einer Serie über zweiseitige Märkte. Auf zweiseitigen Märkten treffen zwei unterscheidbare Gruppen aufeinander, deren jeweiliger Nutzen steigt, wenn die Marktteilnahme der anderen Gruppe größer wird.

Nachdem wir im vorhergehenden Artikel Multihoming , also die parallele Nutzung von Plattformen, und ihre Auswirkungen auf zweiseitige Märkte kennengelernt haben, werden wir uns nun Multihoming konkret bei Internetplattformen anschauen.

Inhalt:

Multihoming bei Internet-Plattformen

Die Möglichkeiten der Vernetzung über das Internet erlauben bei API-gestützten Internet-Plattformen verschiedene Arten von Multihoming. Plattformen können über APIs an andere Plattformen andocken. Applikationen, vor allem Clients, können Multihoming anbieten. Client-Anbieter finden darin ein zunehmend starkes Differenzierungspotential. Wenn eine Plattform in einem Bereich den Markt dominiert und damit zum Quasi-Standard wird, bietet es sich unter Umständen an über einen Adapter, also eine API, an diese Plattform, anzudocken.

Freiwilliges Multihoming der Plattformseite

Außerhalb des Internets ist Folgendes eher ungewöhnlich: Alle großen Netzwerkplattformen wie  Facebook, MySpace, LinkedIn u.s.w. haben im Laufe des Jahres 2009 die Funktionalität implementiert, auf Twitter veröffentlichte Nachrichten auf ihren Angeboten automatisch ebenfalls zu veröffentlichen. Die Plattform-Provider haben sich dabei nicht auf Applikationen verlassen und diese Integration stattdessen selbst umgesetzt. Zumindest bei Facebook gab es bis zur Einführung der eigenen Implementation auch Applikationen, die diese Funktion übernommen haben.

Multihoming allüberall

Die Blogplattform Tumblr erlaubt mit Hilfe einer Facebook-Applikation das zusätzliche Veröffentlichen von Beiträgen auf Facebook, die ursprünglich auf Tumblr erschienen sind. Damit wird ebenfalls Multihoming auf Seiten des Endkonsumenten möglich.

Der Einsatz von standardisierten APIs beinhaltet bereits die Multihoming-Möglichkeit auf Applikationsanbieterseite. Google Buzz setzt unter anderem zum Beispiel durch die in offenen Standards immanente Multihoming-Möglichkeit auf den insgesamt geringeren Ressourcenaufwand auf Applikationentwickler-Seite als Wettbewerbsvorteil der Plattform .

Plattform-Provider die zum Beispiel Open Social integrieren, können theoretisch alle mit den gleichen technischen Spezifikationen von Applikationen angesprochen werden. In der Praxis versuchen Plattform-Provider allerdings zusätzliche proprietäre Bestandteile zur Implementation hinzuzufügen, um sich so von anderen Plattformen zu differenzieren und einen Lock-in-Effekt für das eigene Angebot zu erzeugen. Die Vorteile einer verteilten Plattform (hier im Sinne des Standards) werden damit negiert.

Bei verteilten Plattformen ist die Fragmentierung durch unterschiedliche Implementierungen immer eine Gefahr. Auch das Mobiltelefon-Betriebssystem Android, ebenfalls eine verteilte Plattform, kämpft zum Beispiel mit diesem Problem. Die andere Seite der Medaille ist natürlich, dass auf der gleichen Grundlage bei Erfolg eine wesentlich größere Masse an Endnutzern erreicht werden kann.

Multihoming und Twitter

Ob Multihoming ein Problem für eine auf Vernetzung setzende Plattform wie Twitter ist, wird sich erst mit der Zeit zeigen. Aktuell deutet einiges daraufhin, dass Multihoming Twitter zumindest mittelfristig hilft, die eigenen Nutzer auf der Plattform zu halten. Nur bei Twitter finden sie, zumindest heute, eine hohe Zahl an Clients für Desktop und Mobiltelefon. Sie können wahlweise über Clients oder über die Twitter-Integration Multihoming betreiben und mehrere Plattformen gleichzeitig befüllen. Gleichzeitig wird die Sichtbarkeit ihrer Aktivitäten über Mashups und Dienste wie zum Beispiel Favstar verbessert. Da die Nutzung dieser Dienste weitestgehend kostenfrei für den Endnutzer ist, weil sie entweder auf Freemium und/oder Werbung als Geschäftsmodell setzen, ist der Einsatz von mehreren Angeboten kein Nullsummenspiel. Bis vor wenigen Tagen sah es so aus, als bewegte Twitter sich in eine Richtung, ein rein datengetriebenes Angebot zu werden. Multihoming in beide Richtungen führt zu einer stärkeren Gewichtung der grafischen Oberflächen. Die für diese Strategie notwendige Generativität innerhalb des Twitterkosmos schränkt Twitter allerdings auch in den Handlungsmöglichkeiten ein, etwaige Restriktionen durchzusetzen.

Applikationen integrieren Applikationen: Multihoming am Beispiel Instapaper

Auch auf Applikationenseite gibt es vertikale Integration. So ist es etwa möglich, dass ein Client einen anderen Dienst integriert. Dieser Dienst kann ebenfalls auf die Plattform aufsetzen, auf die der Client aufsetzt, muss das aber nicht.

Erreicht ein Client einen entsprechend hohen Marktanteil, kann er selbst zu einem zweiseitigen Markt werden. Durch die Integration von anderen Diensten bringt er diese und die den Client einsetzenden Endnutzer zusammen. Der Entwickler des Twitter-Clients Tweetdeck, der einen  Marktanteil von 20 Prozent bei den Twitter-Clients innehat, zog for geraumer Zeit bereits ein kostenpflichtiges Integrationsangebot in seinen Client in Erwägung .

Integriert ein Client den Zugang zu mehreren Plattformen, kann er damit die Multihoming-Kosten absenken. Das kann die Nutzung der Plattformen intensivieren. Es sorgt aber auch dafür, dass der Zwang, Alleinstellungsmerkmale zu finden, für die Plattformen ansteigt.

Instapaper ist einfaches Werkzeug, um Artikel für späteres Lesen über ein Bookmarklet online abzuspeichern. Die Bookmarklet-Funktion „Speichern des Textes“ wird in anderen textanzeigenden Applikationen implementiert. So hat man die Möglichkeit, Texte auf Instapaper direkt in den Applikationen zu speichern.

Die Integration dieser Funktion führt zu einem zweiseitigen Markt: Je mehr Webdienste und lokale Applikationen, für die diese Funktion sinnvoll ist, sie integrieren, desto nützlicher wird die eigentliche Applikation für den Endnutzer (weil er sie überall vorfindet). Daraus resultiert, dass mehr Menschen Instapaper einsetzen, was wiederum den Anreiz für Anbieter von anderen Applikationen erhöht, diese Verbindung zu integrieren. Denn je weitverbreiteter die Nutzung von Instapaper  und damit die Integration in Applikationen, desto eher kommt der Punkt, an dem das Fehlen der Integration ein Ausschlusskriterium für einige Endnutzer wird.

Auch hier zeigt sich wieder, wie die potentiell mögliche Verknüpfung über das Internet mit einfachen Mitteln Zusatznutzen stiften kann. Die Betreiber der jeweiligen Applikationen, hier Instapaper und die Funktionalität des Textspeicherns integrierende Applikationen, müssen für diese lose Kooperation nicht in direkten Kontakt treten. Eine so einfache Integrationsmöglichkeit fördert Multihoming auf beiden Seiten. Instapaper ist in vielen Clients vertreten. Die Hersteller der Clients können viele so einfach integrierbare Dienste unterstützen. Allerdings wird jeder künftige Konkurrent von Instapaper es schwerer haben, eine vergleichbare Marktpenetration zu erreichen, je später er den Markt betritt. Die Client-Anbieter integrieren nur eine begrenzte Zahl an auswählbaren Diensten mit vergleichbarer Funktionalität. Clients die dagegen selbst eine Schnittstelle für solche Fälle anbieten, verlagern die Integration auf die Seite des Integrationswilligen. (Ein Beispiel dafür wäre die Addon-Schnittstelle von Firefox.)

--
Dieser Artikel ist Teil der Serie "Zweiseitige Märkte: Die ökonomische Theorie hinter Facebook, Twitter und co."

Alle Artikel findet man hier:

  1. Zweiseitige Märkte: Die Grundlagen
  2. Wie Multihoming zweiseitige Märkte beeinflußt
Marcel Weiß
Unabhängiger Analyst, Publizist & Speaker ~ freier Autor bei FAZ, Podcaster auf neunetz.fm, Co-Host des Onlinehandels-Podcasts Exchanges
Großartig! Du hast Dich erfolgreich angemeldet.
Willkommen zurück! Du hast Dich erfolgreich eingeloggt.
Du hast neunetz.com erfolgreich abonniert.
Dein Link ist abgelaufen.
Erfolg! Suche Dein in Deiner E-Mail nach einem magischen Link zur Anmeldung.
Erfolg! Deine Zahlungsinformationen wurden aktualisiert.
Deine Abrechnung wurde nicht aktualisiert.