Veröffentlicht am 03-05-2019

Ein neues Entwicklerprogramm von außen erstellen

Von Laura Klemme, Su Kyeong Ku, Manoj Gaddam, Anand Komarraju und David Timby

Haben Sie sich jemals gefragt, wie es wäre, ein riesiges Frachtschiff zu einem Schnellboot zu machen? Nun, wir können es Ihnen sagen (im übertragenen Sinn).

Bei StubHub haben wir gerade unser brandneues Entwicklerprogramm vorgestellt. Das Herzstück des Programms ist ein Online-Portal, das unseren Geschäftspartnern, Systemintegratoren und Drittanbieter-Entwicklern eine völlig neue Reihe von Anwendungsprogrammierschnittstellen (APIs) zur Verfügung stellt, mit denen Fans aller Bereiche innovative Ticketing-Lösungen erhalten.

Die APIs bieten etwas, das heutzutage sehr gefragt ist: Einfachheit.

Wir haben es Entwicklern und Verkäufern leicht gemacht, sich schnell in unsere Plattform zu integrieren - und dies geschah, indem wir die Entwicklererfahrung von Grund auf neu entwickelten. Dieses neue Programm, das wir im Laufe eines Jahres entwickelt haben, hat unseren Partnern bereits eine völlig neue Reihe von APIs zur Verfügung gestellt, die sich auf wichtige Geschäftsprozesse wie das Katalogisieren von Ereignissen, das Bestandsmanagement und das Auftragsmanagement beziehen.

Die vier wichtigsten Funktionen des neuen StubHub-Entwicklerprogramms sind:

  • API-Erfahrung, die unsere Kundenreise widerspiegelt und von Grund auf mit einem Outside-In-Ansatz aufgebaut wurde.
    • Self-Service: Entwickler können jetzt schneller als zuvor vorankommen. Sie können Apps mit Produkten erstellen, die sie verwenden möchten, und sie direkt im Portal ausprobieren.
    • Schnelleres Onboarding: StubHub bietet jetzt einen neuen nahtlosen Registrierungsprozess - das Erstellen von API-Token, -Schichten und -Abonnements - und beschleunigt den Onboarding-Prozess eines Partners von etwa einem Monat auf weniger als 24 Stunden.
    • API-Zugriff aus einer Hand: Der API-Produktkatalog von StubHub enthält jetzt alle APIs an einem zentralen Ort mit der neuesten Dokumentation, Beispielcode und Berichtsmetriken.
    • Wir wussten von Anfang an, dass die Neuerstellung unserer APIs ein schwieriges Konstruktionsproblem sein wird, insbesondere wenn wir Milliarden von Dollar im Ticketbestand auf unserer Plattform zum Verkauf haben.

      Schnell wurde uns klar, dass der intelligenteste Weg, dieses Problem anzugehen, darin bestand, einen Outside-in-Ansatz zu verfolgen.

      Das Problem verstehen

      Wir wollten ein One-Stop-Shop-Portal für alle Arten von Partnern. Dies war eine Plattform der Wahl für Anbieter und Entwickler von Drittanbieter-Tools, die auf einem erstklassigen API-Portfolio basiert, das eine schnelle Integration in den Self-Service und erstklassigen Support ermöglicht.

      Um zu wissen, wie man das erstellt, mussten wir zunächst die Einschränkungen des alten Systems verstehen.

      Professionelle Verkäufer und Handelspartner verlassen sich bei mehreren E-Commerce-Transaktionen auf StubHub auf unsere APIs. Diese APIs haben einen enormen Wert - ein erheblicher Prozentsatz des Ticketangebots bei StubHub stammt von Verkäufern, die diese APIs verwenden.

      Bis vor kurzem war die Integration dieser APIs sowohl für unsere Partner als auch für uns schmerzhaft. Die größte Herausforderung bestand im Fehlen einer Self-Service-Funktionalität. Bei unseren Partnern gab es auch andere schmerzhafte Probleme, wie Point of Sale (POS), Drittanbieter von Werkzeugen und große Broker.

      Unter ihnen fehlte die Governance für API-Abonnements. Wir haben von einigen unserer größten Partner gehört, dass ihr Inventar nicht auf unsere Website gelangt.

      Umso komplizierter war die Tatsache, dass wir nicht nur ein, sondern vier Entwicklerportale für verschiedene Arten von Partnern pflegen mussten. Wir hatten anfangs ein kleines Team zusammengestellt, um die regelmäßig auftretenden Probleme zu „bekämpfen“. Dieses Team führte unsere Partner durch die Fehler und Eskalationen, auf die sie aufmerksam gemacht wurden. Je mehr wir dies taten, desto mehr sank es, als die Feuerwehr allein auf lange Sicht nicht nachhaltig war.

      Die Antwortqualität unseres API-Supportteams wurde durch die zahlreichen eingehenden Supportanrufe von Partnern beeinträchtigt. Die Zufriedenheit der Partner war aufgrund der langen Bearbeitungszeiten für die Unterstützung gering. Trotz unserer Brandbekämpfung haben wir tatsächlich 2% unseres Inventars pro Monat verloren. Die übermäßige Nutzung unserer Systemressourcen aufgrund ineffizienter Integrationen führte zu Systemausfällen mit hoher Priorität.

      Es war unnötig zu erwähnen, dass wir große Probleme zu lösen hatten, und wir erkannten, dass ein kundenorientierter Outside-In-Ansatz bei der Gestaltung der neuen API-Produktlinien das beste Funktionsprinzip war.

      Sie sehen es aus dem POV eines Outsiders

      Wir haben diese Philosophie in Bewegung gesetzt, indem wir zunächst einige unserer 100 Partner interviewt haben. In der Vergangenheit haben wir uns hauptsächlich mit technischen Fragen und Herausforderungen auseinandergesetzt. Dies ist eindeutig nicht die beste Grundlage für eine starke Beziehung. Stattdessen wollten wir regelmäßig kommunizieren, um sicherzustellen, dass unsere Partner angehört werden.

      Was wir von ihnen gelernt haben, war von unschätzbarem Wert: Der Onboarding-Prozess war verwirrend und zeitraubend (die durchschnittliche Zeit betrug 30 Tage). Im Durchschnitt gab es 20 Serviceanfragen, bis der Verkäufer erfolgreich eingesetzt wurde. Wir haben gelernt, dass wir das Kundenerlebnis einfacher gestalten und unseren Partnern mehr Autonomie geben müssen. Beim Aufbau unseres neuen Entwicklerprogramms wollten wir Folgendes erreichen:

      • 24 Stunden bis zur Integration an Bord.
        • Stellen Sie nützliche Analysen und Diagnosen für unsere Benutzer im Portal bereit.
        • Ein standardisierter und nahtloser Prozess zur Genehmigung von Quoten- und API-Anforderungen innerhalb von 24 Stunden
        • Teilen Sie APIs basierend auf Anwendungsfällen in Produktlinien auf.
        • Ein Schlüsselelement bei diesem Übergang war die Partnerschaft mit Googles Apigee, um das Programm auf den Weg zu bringen. Insbesondere haben wir mit ihrem Day 0 Engagement-Team das SPRINT-Framework verwendet - eine Strategie, die in der Regel große Probleme lösen und neue Ideen innerhalb einer Woche testen soll.

          In dieser ersten Woche konnten wir diese wichtigen Schritte erreichen:

          • Mehrere Hauptschwierigkeiten innerhalb des Partner-Onboarding-Pfads festgestellt.
            • Definiert unser MVP & MVBO.
            • Definierte einen Pfad, der voranschreitet, um ein neues Self-Service-Entwicklerportal zu erstellen.
            • Definierte Gruppe von API-Produkten, die die in Sprint 0 definierten Schmerzpunkte direkt ansprechen.
            • Definierte Registrierung und Anmeldung (Backend und Frontend).
            • Definierte Architektur- und Sicherheitsprobleme.
            • Wir haben dies im Verlauf von sieben Wochen mit drei „Sprints“ der Arbeit verfolgt, die schließlich zu diesen Leistungen führten:

            • End-to-End-Architektur definiert
              • Die Zulassungen von Infosec und Security Enterprise Team haben begonnen
              • Eine durchgängige API-Funktion
              • Integration von Unternehmen / Konten, benutzerdefinierte Genehmigungsabläufe, interaktive API-Dokumentation und vollständige StubHub-Markenführung
              • Kontoebenen neu definiert
              • Anpassung an bewährte Verfahren der Industrie
              • Der Tag 0-Ansatz und die nachfolgenden Sprints verbesserten letztendlich die Integration von Unternehmen und Konten. Diese Sprints haben uns dabei geholfen, benutzerdefinierte Genehmigungsabläufe zu optimieren und eine interaktive API-Dokumentation bereitzustellen.

                Die neue Architektur

                Bei der Strukturierung dieses neuen Portals haben wir folgende Anpassungen vorgenommen:

                … Dazu:

                Wie im obigen Diagramm gezeigt, haben wir eine Reihe wichtiger Änderungen vorgenommen, die die Rückmeldungen unserer Partner einbeziehen, um eine neue Architektur zu schaffen, die die Benutzererfahrung insgesamt verbessert:

                • Dezentrales Gateway, mit dem wir uns unabhängig von anderen internen API-Konsumenten auf die Erfahrung der Partner konzentrieren können. Dies ermöglichte es uns auch, auf die Bedürfnisse unserer Partner abzustimmen / zu optimieren, und reduzierte die Anzahl der 270 APIs auf 40 bis 50 APIs in sechs Produktlinien. APIs sind jetzt leicht zu entdecken, intuitiver und zielen auf die unterschiedlichen Bedürfnisse dieser Partner im Ticketing-Ökosystem ab.
                • Eingeführte BFF-Muster zur Minimierung der Abhängigkeiten zwischen Teams; Jede Erfahrung bietet die Möglichkeit, Schwimmbahnen vor anderen Teams zu erhalten.
                • MVP-Fassadenschicht in unserem Rechenzentrum mit dem Ziel, sie in der nächsten Phase in die Cloud zu bringen - ohne Auswirkungen auf den Kunden.
                  • StubHub Identity-Plattform mit der Fähigkeit, alle von unseren Partnern verwendeten Open ID-Lösungen zu unterstützen (Zukunft)
                  • Isolierter Partnerverkehr, um sicherzustellen, dass andere StubHub-Erfahrungen nicht beeinträchtigt werden
                  • Ein Entwicklerportal, das APIs und deren Dokumentation, Widgets, SDKs und Analysen hostet, um Einblick in die Integration unserer Partner in StubHub zu erhalten.
                  • Wir haben Entwickler von 1Ticket und Ticket Attendant zu Beginn des Entwicklungsprozesses als Beta-Benutzer ausgewählt und konnten erfolgreich auf die neuen StubHub-Listing- und Pre-Delivery-APIs migrieren. Sie fanden die Integration effizienter und die Erfahrung weniger schmerzhaft.

                    Die Tatsache, dass wir an diesem Punkt angelangt sind, ist ein Beweis für unsere Fähigkeit, mehrere Schmerzpunkte zu lösen, die speziellen Bedürfnisse der Partner zu berücksichtigen und eine effizientere Integration zu gewährleisten. Diese Effizienz führt zu einer verbesserten und verbesserten Erfahrung für unsere Kunden. Denn wenn sich Partner nahtlos integrieren können, bietet der StubHub-Marktplatz ein stabileres Inventar für unsere Fans.

                    Dies haben wir durch Experimente und durch neue Arbeitsweisen erreicht. Am wichtigsten war jedoch, dass wir die Modernisierungsreise von StubHub nicht verlangsamen mussten.

                    Erfahren Sie in diesem Artikel mehr über die vielen talentierten Mitarbeiter: Laura Klemme, Technical Program Manager; Su Kyeong Ku, User Experience Designer, Unternehmen; Manoj Gaddam, Produktmanager; Anand Komarraju, Engineering Lead, und David Timby, Senior Manager für Supply Business Operations

                    Interessiert an Projekten wie unserem neuen Entwicklerprogramm? Komm, schließe dich uns an.