Experimentieren + KPIs: Wie Product Manager die richtigen Funktionen schneller einführen

Optimizelys Full Stack ermöglicht es Produktteams, das Erlebnis ihrer Besucher schneller, einfacher und sicherer zu verbessern als der typische Produktentwicklungsprozess, indem sie die Tools zum Experimentieren, Optimieren und Rollout neuer Funktionen bereitstellen, um sicherzustellen, dass Ihren Kunden ein Mehrwert geboten wird. Unabhängig davon, welchen Teil von Full Stack Sie verwenden, müssen Sie einen Messplan haben, um festzustellen, ob die Verbesserungen, die Sie vornehmen, für Ihre Besucher tatsächlich nützlich und angenehm sind.

In den letzten Jahren als Lead Strategy Consultant bei Optimizely habe ich gesehen, dass die besten Produktteams bei der Verwendung von Full Stack eine Entscheidungsrichtlinie für die Analyse befolgen, die ich im Folgenden erläutern werde. Da die Durchführung von Full Stack-Tests in der Regel ein breiteres Spektrum an Metriken umfasst, erhöht sich die Zeit bis zur Entscheidungsfindung und damit auch die Geschwindigkeit (die Anzahl der durchgeführten Experimente), wenn Sie im Voraus wissen, was der Erfolg unter diesen Metriken sein wird. Außerdem können Sie so sicherstellen, dass Sie den Erfolg Ihrer Experimente konsequenter messen und auf Ihre Hauptziele abstimmen.

Zu Beginn ist es wichtig, die Tools in Ihrem Produktentwicklungs-Toolkit zu verstehen, die mit Full Stack verwendet werden können. Diese Unterschiede im Voraus zu kennen, hat den Teams geholfen, einzigartige Messpläne zu erstellen.

• A/B-Testing - A/B-Testing ist eine Methode, bei der zwei (oder mehr) Versionen einer Seite oder eines App-Bildschirms miteinander verglichen werden, um festzustellen, welche Version besser abschneidet. Sie können Metriken wie im Web-Produkt von Optimizely zuweisen und die Vorteile der Stats Engine voll ausschöpfen.
• Feature-Test - Ein Feature-Test wird ähnlich wie ein A/B-Test durchgeführt, basiert jedoch auf einem Feature in Optimizely und nutzt die Vorteile von Feature-Variablen. Wie bei einem A/B-Test haben Sie die Möglichkeit, Metriken wie Click-Through-Rates, Käufe und Einnahmen zuzuweisen und dabei die Stats Engine für Ihre Entscheidungen zu nutzen.
• Feature Flag / Rollout - Feature Flags ermöglichen es Ihnen, bedingte Feature Branches in den Code einzubauen, um die Logik jeweils nur für bestimmte Benutzergruppen verfügbar zu machen. Der Rollout ermöglicht es Ihnen, ein Feature Flag für eine Gruppe von Benutzern zu setzen: einen Prozentsatz der Benutzer, eine bestimmte Zielgruppe oder beides. Sie haben nicht die Möglichkeit, Metriken zuzuweisen. Rollouts werden zum Starten von Funktionen verwendet, so dass keine Impressionen gesendet werden und kein zusätzlicher Netzwerkverkehr entsteht.
• Mehrarmiger Bandit - Ein mehrarmiger Bandit ist ein Optimierungsverfahren für einen A/B-Test, bei dem Machine Learning Algorithmen verwendet werden, um den Traffic dynamisch den Varianten zuzuweisen, die gut abschneiden, während den Varianten, die nicht so gut abschneiden, weniger Traffic zugewiesen wird. Sie können wie bei einem A/B-Test oder einem Feature-Test beliebige Metriken zuweisen. Anstelle der statistischen Signifikanz konzentriert sich die Ergebnisseite des Mehrarmigen Bandits jedoch auf die Verbesserung gegenüber einer gleichmäßigen Zuweisung als primäre Zusammenfassung der Leistung Ihrer Optimierung. Diese können nur für einen der beiden Testtypen verwendet werden, nicht aber für einen Feature-Rollout.

Als Product Owner werden Sie diese nacheinander und oft ziemlich schnell hintereinander verwenden. Vielleicht bauen Sie ein neues interaktives Formular-Feature, das Sie mit einem Feature Flag kontrollieren und nur Ihrer Beta-Benutzergruppe zur Verfügung stellen. Wenn die ersten Signale stark sind, können Sie die Funktion über Ihre Betagruppe hinaus auf eine größere Gruppe von Benutzern ausweiten, um die Auswirkungen auf die Leistung zu überprüfen. Wenn keine Auswirkungen auf die Leistung festgestellt werden, können Sie nun zu einem echten Experimentieren in einem Feature-Test mit verschiedenen Feldtypen, Präsentationen usw. übergehen. Und mit der Zeit können Sie Mehrarmige Banditen einsetzen, um die Leadgenerierung während einer Marketingkampagne zu optimieren. Überlegen Sie, wie sich Ihre Richtlinien für die Entscheidungsfindung in einem Szenario wie diesem verändern können!

Die meisten Unternehmen haben eine "einzige Quelle der Wahrheit", wenn es um die Messung ihrer Produkte und Erlebnisse geht. Optimizely ist da nicht anders. Wir empfehlen Teams, Optimizely in Verbindung mit einer Plattform wie Amplitude oder einem internen Data Warehouse zu nutzen. Wichtig ist, dass Sie einen Erfolgsplan für die Messung aufstellen, bevor Sie einen Test oder eine Funktion zwischen Ihren verschiedenen Analyseplattformen einführen.

Nachfolgend finden Sie ein Beispiel (Vorlage zum Herunterladen) dafür, wie Sie dies für alles, was Sie in Optimizelys Full Stack tun, im Gleichgewicht mit Ihrem internen Data Warehouse ("Quelle der Wahrheit") angehen könnten. Beachten Sie, dass Sie Tests nur dann als Gewinner bezeichnen, wenn es statistisch signifikante Gewinne bei der Nordstern-Metrik und einen positiven Anstieg bei der primären Metrik (und umgekehrt) gibt.

Einige Unternehmen haben einen festen Standard, z.B. eine bestimmte Key Performance Metric (KPI), die positiv beeinflusst werden muss, und zwar für alles, was sie in Optimizely One tun (wie oben).

Oft wird der KPI jedoch pro Test oder Feature-Einführung festgelegt. Für einen Test kann das so aussehen:

Hypothese: Wenn wir die Suchergebnisse auf der Site nach den am häufigsten angeklickten Ergebnissen (als "Beliebteste") und nicht nach den neuesten Ergebnissen sortieren, erhöhen wir die Produktbetrachtungsrate und damit die Kaufabschlussrate.

Wir empfehlen Ihnen auch, eine Plattform für digitale Erlebnisanalytik wie FullStory zu nutzen, um Ihre Entscheidungsfindung zu unterstützen, wenn die von Ihnen verfolgten Metriken keinen statistischen Wert erreicht haben oder nicht schlüssig sind. Diese Art von Tool gibt Ihnen einen tieferen Einblick in die Art und Weise, wie die Nutzer mit einer Variante umgehen, und hilft Ihnen, Ihre Ergebnisse weiter zu validieren. Wie Sie in den obigen Bildern sehen können, verlassen wir uns unter bestimmten vordefinierten Umständen auf FullStory-Analysen.

Wenn Sie ein Feature mit Hilfe eines Optimizely-Rollouts einführen, werden Sie wahrscheinlich andere Metriken messen als bei einem Test, der die Auswirkungen auf das Produkt über die reine Optimierung hinaus berücksichtigt (z. B. die Leistung). Einige dieser Metriken für Leistungstests könnten Dinge wie die Ausfallrate von Änderungen und die Zeit bis zur Wiederherstellung des Dienstes sein. Diese Arten von Kennzahlen werden vielleicht nicht in Ihre Richtlinien für die Entscheidung über den Erfolg der Funktion aufgenommen, aber das sollten sie! Sind Sie z.B. bereit, eine signifikante Erhöhung der Anzahl der ausgefüllten Formulare in Kauf zu nehmen, wenn Sie dafür eine nicht signifikante Erhöhung der Fehlerquote in Kauf nehmen müssen. Das sind die Szenarien, die Sie im Blick haben sollten, bevor Sie mit Ihrem Experiment beginnen.

Warum sollten Sie sich dafür entscheiden, Ihren KPI auf Programmebene und nicht für jeden einzelnen Start in Optimizely festzulegen? Sie können dies auf Programmebene tun, wenn Sie zunächst nur einen einzigen Teil von Optimizely Full Stack nutzen (z.B. Rollouts). Vielleicht verwenden Sie auch nur die A/B-Testing-Funktion von Optimizely, damit das Unternehmen eine einheitliche Ansicht für alle erstellen kann. Oder das Unternehmen hat bereits eine festgelegte Vorgehensweise für die Analyse mit Technik-Partnern und es gibt bereits eine klare Linie.

In den meisten Fällen (sei es auf Programmebene oder von Fall zu Fall) neigen Unternehmen dazu, die Grenze dort zu ziehen, wo die Analyse in Optimizely One bei ihren wichtigsten Kennzahlen aufhört. Das können Metriken wie Umsatz, Lifetime Value, Buchungen, Lead Score usw. sein. Das Serviceteam von Optimizely verfügt über umfangreiche Erfahrungen bei der Erstellung dieser Datenpipelines und Messverfahren, wo immer diese Grenze gezogen wird. Und die Bewertung, welche anderen Metriken in Optimizely gemessen werden, erfolgt von Fall zu Fall. Was sind einige Entscheidungspunkte?

• Welche Metriken sind am wichtigsten, wenn man sich auf sie verlassen kann, anstatt eine eher explorative Analyse durchzuführen?
• Welche Datendefinitionen sind unseren Teammitgliedern/Führungskräften vertraut, wenn wir uns zusammensetzen, um Entscheidungen über diese Art von Veränderungen zu treffen?
• Sind wir überhaupt in der Lage, diese Metriken rechtzeitig zur Einführung von Full Stack in unseren anderen Analyseplattformen zu implementieren?

Letztendlich wollen wir den Teams die Analyse von Experimenten und Funktionen erleichtern, indem wir sie schneller und relevanter für ihr Geschäft machen. Data Lab wird dies möglich machen.