Die Fähigkeit, APIs nicht nur in den eigenen Systemen integrieren zu können, ist enorm wichtig geworden, aber ebenso wichtig, eigene APIs bauen zu können. Warum? Eine eigene API zu veröffentlichen, kann schnell zu einem richtigen Growth Hack werden.
Die Publikation beispielsweise der Twitter-API hatte 2007 einen ganz besonderen Effekt: einen epischen Growth Hack. Durch die Öffnung der Twitter-Streams „Livefeed“, „Tweets eines Users“ und „Tweets pro Hashtag“ konnten Hunderte von Websites, Portalen und Blogs kontextbasiert Live-Konversationen von Twitter integrieren. Heute Standard für jede Online-Tageszeitung, damals „Wooow!”: Live-Content, integriert von einer anderen Plattform. Das war wirklich , auch für meine damaligen eigenen Affiliate-Websites.
1. Meine erste eigene API
2. Beispiel Twitter-API
3. Die Integration von APIs
4. APIs als strategischer Growth Hack
5. Payment-Prozess als API
5.1. Beispiel AirBnB
1. Meine erste eigene API
Ich erinnere mich gut, wie ich zu der Zeit als WordPress-SEO sehr viel Traffic mit lustigen Twitter-Content-Spielereien auf meine Websites schaufeln konnte. Der Google-Algorithmus funktionierte allerdings ein bisschen anders als heute, ein paar Jahre vor den Panda- und Pinguin-Updates, die wir heute hinter uns haben. Zu dieser Zeit entstand auch eines meiner ersten eigenen Online-Tools mit dem Titel „Tweet-Rank: Wie gut sind Deine Tweets? Analysiere, warum Du Follower gewinnst oder verlierst“. Allerdings erhöhten sich mit steigender Bekanntheit des Projektes leider auch die Performance-Probleme meines selbstprogrammierten Analytics-Tools exponentiell. Mein Strato-Webserver für 9 Euro monatlich konnte die 4.000 bis 5.000 Besucher am Tag nicht mehr aushalten. Welche Überraschung, wenn man die Twitter-API nicht cacht und die eigenen Datenbank-Zugriffe mit jedem Request immer wieder neu direkt aus der Datenbank abruft. Das habe ich damals beim Skripten auf jeden Fall unterschätzt.
Eine Neuprogrammierung hätte sein müssen, die ich zeitlich wegen anderer Projekte allerdings nicht leisten konnte. Schade eigentlich, denn Social-Media-Monitoring-Tools gab es damals noch überhaupt nicht. Und ich hatte zumindest ein richtig gutes MVP gebaut, das den ganzen Twitter-Newbies eine Rückmeldung geben konnte, was auf Twitter funktioniert und was eben nicht. Zumindest habe ich seitdem ein sehr klares Verständnis davon, wie wichtig von Beginn an die Bereitstellung einer skalierenden IT-Infrastruktur sein kann.
2. Beispiel Twitter-API
Durch die Öffnung der Twitter-APIs entstanden auf diese Art Tausende von Apps und Web-Projekten, die Twitter damals ungeahnte Reichweite bescherten. Das für damalige Verhältnisse Verrückte war, dass die User quasi Twitter nutzten, ohne die Website oder die App von Twitter besuchen zu müssen. Live-Konversationen zu bestimmten Hashtags wie zum Beispiel auf Konferenzen (#seocampixx, …), Fernsehsendungen (#hassmartin, #dsds, #bauersuchtfrau, #sdr, …) oder zum aktuellen Weltgeschehen (#ripmichael, …) verbreiteten sich in Windeseile. Übrigens wurde so auch der Hashtag erfunden. In diesem Zusammenhang werden sich bestimmt viele an das erste Live-Foto zum Flugzeugabsturz im Hudson-River 2009 erinnern.
3. Die Integration von APIs
APIs ermöglichen also Programmierern, Partnern oder aber auch Kunden eine individuelle Verwendung des eigenen Produktes. Möglicherweise fernab der ursprünglichen Idee, die man als Standard-Produkt über die eigene Plattform anbietet. Somit können die Reichweite des eigenen Produkts beziehungsweise das Engagement der eigenen User mit dem Produkt in der Regel deutlich gesteigert werden.
Nebenbei bemerkt, ist die technische Integration einer API in das System der Kunden mit einem entscheidenden weiteren Vorteil behaftet, den man nicht immer sofort erkennt: ein echter Growth Hack zur Reduzierung der Churn Rate. Je tiefer das Produkt technisch in ein Fremdsystem integriert wird, desto geringer ist die Wahrscheinlichkeit, dass der Kunde die Integration wieder rückgängig macht. Schließlich ist für eine technische Integration immer Aufwand der Entwickler angefallen. Diesen gilt es bekanntlich, irgendwie zu vermeiden, zumal für den Ausbau der Lösung aus dem eigenen System vermutlich ebenfalls wieder Aufwände anfallen.
Gerade in größeren Unternehmen gibt es jedoch oftmals Vorbehalte gegenüber der Veröffentlichung von APIs, da schlichtweg die Erfahrung im Umgang damit fehlt. Hinzu kommt die Sorge, dass man die APIs und deren Verwendung nicht kontrollieren könne.
4. APIs als strategischer Growth Hack
Für Produkte, die das Sammeln und Veröffentlichen von User Generated Content als Kernfunktionalität ausspielen – wie Twitter, Facebook, YouTube, eBay und Co. – sind APIs ein strategischer Growth Hack. Denn sowohl das Sammeln des Contents als auch das Erstellen des Contents können problemlos über Drittsysteme angeboten werden. Somit erhöhen sie einerseits die Reichweite ihres Contents und zum anderen auch die Menge des Contents, der quasi ohne Hürden von überall eingestellt werden kann.
Weitere Business-Modelle, die in jüngster Vergangenheit von der Bereitstellung eigener APIs profitiert haben:
- Bereitstellung von Speicherplatz (Dropbox)
- E-Mail-Services (Mailchimp)
- Foto-Services (Flickr)
- Shop-Systeme (Shopify)
- Online-Payment-Services (PayPal)
- Daten-Anreicherung (Google Maps)
- Web-Analytics (Google Analytics)
- Übersetzungsservices (lingo24)
Banken und Versicherungen als Unternehmen mit besonders sensiblen Userdaten sind verständlicherweise noch immer relativ zurückhaltend mit der Bereitstellung von APIs. Die Fintech-Szene schläft allerdings nicht. So organisiert beispielsweise die Deutsche Bank regelmäßig Hackathons, bei denen sie Entwickler einlädt, um sie mit ihren APIs „herumspielen“ zu lassen. Auch die Deutsche Post zieht nach, genau wie die Allianz Versicherung. Willkommen in der Digitalisierung, eine ausgezeichnete Idee.
5. Payment-Prozess als API
Da die meisten meiner Projekte einen E-Commerce-Hintergrund haben, bin ich mir dessen bewusst, wie wichtig ein flüssiger Bezahlprozess für den Erfolg einer E-Commerce-Plattform ist:
- Bietet man die richtigen Zahlungsanbieter für die jeweilige Zielgruppe an?
- Läuft die Bezahlung im System wirklich sehr einfach und ohne Hürden ab?
- Wie sieht es aus mit der Zahlungsabwicklung nach der Bestellung?
- Wie wickelt man wiederkehrende Zahlungen möglichst automatisiert ab?
Ein Großteil der Marketing-Kosten gehen an dieser Stelle leider wieder verloren. Kunden werden teuer eingekauft, in den Bestellprozess gehoben und scheitern dann letztendlich an der Bezahlung.
Bevor es salonfähige APIs und einen eigenen Markt für Payment-Provider gab, hat diesen Prozess nahezu jeder Händler selbst implementieren müssen. Heutzutage ist jedoch dringend davon abzuraten, da es eine Vielzahl von „fertigen“ Payment-Providern gibt, die sich mit Hilfe einer API Integration leicht in den eigenen Bestellprozess integrieren lassen.
Vor allem für international agierende Unternehmen, die im jeweiligen Markt unterschiedliche Zahlungsmodalitäten anbieten müssen, um die Kundenwünsche erfüllen zu können, ist die Integration eines Payment-Providers heutzutage dringend zu empfehlen. Niemand möchte pro Markt unterschiedliche Bestellprozesse selbst implementieren müssen.
5.1. Beispiel AirBnB
AirBnB hatte dies früh erkannt und hat von Beginn an pro Markt unterschiedliche Payment-Solutions integriert, um die User-Needs zu treffen. Nur so wurde es dem Unternehmen möglich, in 190 Ländern unterwegs sein zu können.
Ein tolles Beispiel für die Modularisierung des eigenen Technology-Stacks, in dem man das Payment-Modul komplett abkapselt und durch ein Fremdsystem abwickeln lässt, statt es vollständig selbst zu entwickeln. Natürlich sind Payment-Solutions nicht günstig, da sie an jeder Transaktion mit partizipieren möchten. Aus meiner Sicht allerdings für beide Seiten ein guter Deal, da ich mich mit meinem Produkt weiterhin auf meine Kernprozesse konzentrieren kann.
Beitragsbild by geralt
https://pixabay.com/en/network-rectangle-rings-networking-1989138/
