Warum Server-seitig experimentieren?
Bevor ich zu Optimizely kam, habe ich sechs Jahre bei Google im Search Quality Team gearbeitet.

Experimentieren war ein zentraler Bestandteil unseres Entwicklungsprozesses: Jede Änderung an den Google-Suchergebnissen wurde an einem kleinen Teil der Nutzer A/B-Testing unterzogen, bevor sie für alle eingeführt wurde. Während meiner Zeit dort haben wir Tausende von Verbesserungen an den Google-Suchergebnissen vorgenommen, die alle wissenschaftlich getestet wurden und messbare Auswirkungen auf unsere wichtigsten Leistungskennzahlen hatten.
Wie wirkt sich eine Änderung des Rankings der ersten beiden Suchergebnisse von Google aus? Auf die Durchklickrate? Auf die Werbeeinnahmen?
Das Experimentieren bot uns die Möglichkeit, Fragen wie diese schnell und einfach zu beantworten. Nicht alle unsere Experimente betrafen Ranking-Algorithmen - auch einfache Änderungen wie die Abstände zwischen den Suchergebnissen konnten erhebliche Auswirkungen haben.
Mein erstes Projekt bei Google war die Mitarbeit am Aufbau unserer internen Plattform, mit der wir Live-Experimente auf unserer Suchergebnisseite durchführen konnten. Eine zentralisierte Plattform war unerlässlich, um Hunderte von Experimenten zu unterstützen, die in einem großen Team gleichzeitig liefen. Die Plattform lieferte auch eine Reihe gemeinsamer Leistungskennzahlen, die in jede Startentscheidung einflossen. Jede Woche sahen wir uns in der Besprechung zur Suchqualität die Ergebnisse von Experimenten mit Live-Datenverkehr an, bevor wir eine Entscheidung darüber trafen, was den Nutzern zur Verfügung gestellt werden sollte. Hier sehen Sie ein Video von einem unserer Meetings.
Einer der wichtigsten Grundsätze unseres Experimentierens war, dass die Experimente serverseitig durchgeführt wurden. Wir experimentierten, indem wir den Code auf den Google-Servern änderten, anstatt den Inhalt im Browser oder auf dem Gerät des Endnutzers zu modifizieren. Die serverseitige Ausführung von Experimenten war in unserem Fall unerlässlich, da wir mit Algorithmen experimentierten, die auf unseren Servern liefen. Aber noch wichtiger ist, dass die serverseitige Ausführung von Experimenten bedeutete, dass sie tief in unseren Produktentwicklungsprozess integriert waren.
In diesem Beitrag spreche ich über die Vorteile von Experimenten auf der Serverseite und einige Erfolgsmethoden, die wir aus Gesprächen mit Produktentwicklungsteams gelernt haben.
Sollten Sie Experimente clientseitig oder serverseitig durchführen?
Das folgende Diagramm veranschaulicht den grundlegenden Unterschied zwischen einer clientseitigen und einer serverseitigen Architektur für das Experimentieren. Beim clientseitigen Experimentieren wird direkt im Webbrowser, in der Mobile App oder einem anderen Client-Gerät des Endbenutzers experimentiert, d.h. die Behandlung wird bestimmt, während der Inhalt für den Benutzer dargestellt wird. Beim serverseitigen Experimentieren wird im Code auf den Servern des Unternehmens experimentiert, d.h. die Behandlung wird festgelegt, bevor der Inhalt an den Kunden zurückgegeben wird.
Optimizely wurde 2010 unter der Prämisse gegründet, das Experimentieren auf einer Website so einfach wie möglich zu machen: Mit nur einer Zeile JavaScript konnten Sie jedes Team in die Lage versetzen, Experimente in einem visuellen Editor einzurichten und sie sofort auf ihrer Website einzusetzen. Heute hat sich das Experimentieren mit clientseitigem JavaScript in fast allen Branchen etabliert, und es gibt Hunderte von Anbietern, darunter Adobe und Google.
Doch während sich der Client-seitige Ansatz immer mehr durchsetzt, wird auch immer deutlicher, dass er keine Universallösung für das Experimentieren ist und auch nie sein kann.
Produktentwicklungsteams, die neue Funktionen entwickeln, wie z.B. die Algorithmen für die Google-Suchergebnisse oder die Backend-Logik einer Site für den Einzelhandel oder die Reisebranche, können mit diesen Funktionen nicht client-seitig experimentieren. Immer mehr Websites verwenden einseitige App-Frameworks mit serverseitigem Rendering (d.h. isomorphe Anwendungen), was die clientseitige Implementierung erschwert. Da sich die digitalen Kanäle für Verbraucher immer weiter ausbreiten, konsolidieren viele Unternehmen ihre Technik mit einer einheitlichen Datenschicht für mehrere Kanäle. Aus diesen und weiteren Gründen hat die Nachfrage nach serverseitigem Experimentieren zugenommen und ist eine der von Optimizely-Kunden am häufigsten nachgefragten Funktionen.
Sowohl das clientseitige als auch das serverseitige Experimentieren bieten je nach den Bedürfnissen Ihres Unternehmens deutliche Vorteile. Im Folgenden finden Sie eine Zusammenfassung einiger der wichtigsten Unterschiede, die wir im Gespräch mit Kunden erfahren haben:
Discover Why Forrester Recognized Optimizely as a Leader
Einfach ausgedrückt:
- Wenn Sie ein Marketing- oder Wachstumsteam sind und jedem in Ihrem Team die Möglichkeit geben möchten, Experimente mit einem visuellen Editor zu erstellen, ohne dass Sie Code freigeben müssen, sollten Sie die clientseitige Ausführung von Experimenten in Betracht ziehen.
- Wenn Sie ein Produktentwicklungsteam sind und tief in Ihrem Produkt experimentieren möchten, mit minimalen Auswirkungen auf die Leistung und über mehrere Kanäle hinweg, sollten Sie Experimente serverseitig ausführen.
Natürlich haben viele Unternehmen Bedarf an beidem. Die meisten der anspruchsvolleren Unternehmen, mit denen wir sprechen, führen eine Kombination aus clientseitigem und serverseitigem Experimentieren durch, an dem sowohl Marketing- oder Wachstumsteams als auch Produktentwicklungsteams beteiligt sind.
Wir haben auch einen großen Unterschied in den Abläufen zwischen Teams, die Experimente auf dem Client durchführen, und denen, die Experimente auf dem Server durchführen, festgestellt. Betrachten Sie den Lebenszyklus eines Experiments, von der ersten Hypothese bis zum Start:
Der client-seitige Ansatz hat den klaren Vorteil, dass Experimente nicht von vornherein auf dem Server erstellt werden müssen. Wenn das Experiment nicht erfolgreich ist, was bei den meisten Experimenten der Fall ist, ist keine Freigabe des Servercodes erforderlich. Das Experimentieren kann also als eigenständiges Verfahren durchgeführt werden, für das kein Entwicklungsteam erforderlich ist. Viele Unternehmen, mit denen wir sprechen, die ein clientseitiges Programm in großem Maßstab betreiben, haben ein eigenes Team für das Experimentieren mit einer Roadmap für die durchzuführenden Experimente.
Der serverseitige Ansatz erfordert ein anderes Organisationsmodell. Jedes Experiment kann eine Codefreigabe erfordern und verlangt daher die Beteiligung des Produktentwicklungsteams bei jedem Schritt. Anstatt eine zentralisierte Roadmap für das Experimentieren zu erstellen, sollte jedes Produktentwicklungsteam einfach jedes Feature auf seiner Roadmap als A/B-Test ausrollen. In den erfahreneren Unternehmen, mit denen wir gesprochen haben, bezieht jedes Mitglied des Entwicklungsteams das Experimentieren in seinen Rollout-Prozess ein, anstatt Experimente isoliert durchzuführen. Dies ist die Praxis, die wir im Google Search Quality Team eingeführt hatten und die unerlässlich war, um sicherzustellen, dass jede Änderung an unseren Suchergebnissen eine positive Auswirkung auf die Nutzer hat.
Wenn Sie zu einem Produktentwicklungsteam gehören und sich fragen, "womit sollen wir experimentieren?", dann ist die Antwort einfach: Ihre Produkt-Roadmap ist Ihre Roadmap zum Experimentieren.
Optimizely X Full Stack
Letztes Jahr haben wir Optimizely X Full Stack auf den Markt gebracht, um unseren Kunden die Möglichkeit zu geben, Experimente serverseitig oder in einem beliebigen Teil ihres Technik-Stacks durchzuführen. Außerdem haben wir aktualisierte Mobile SDKs sowie neue OTT SDKs für das Experimentieren mit Connected TV-Anwendungen eingeführt.
Unsere Vision ist es, Produktentwicklungsteams in die Lage zu versetzen, mit allem zu experimentieren, was sie entwickeln, und dabei eine einheitliche Experimentierplattform zu nutzen. Wir haben mit SDKs in Java, Ruby, Python, PHP, Node, JavaScript, iOS, tvOS und Android begonnen. Der folgende Code zeigt ein Beispiel für die Verwendung unseres SDKs in Python:
from optimizely import optimizely # Initialisieren eines Optimizely-Clients optimizely_client = optimizely.Optimizely(datafile) # Benutzer in einem Experiment aktivieren variation = optimizely_client.activate('mein_experiment', user_id) if variation == 'control': # Code für Variante A ausführen elif variation == 'treatment': # Code für Variante B ausführen else: # Standardcode ausführen # Conversion-Ereignis verfolgen optimizely_client.track('meine_conversion', user_id)
In den letzten Jahren haben wir viel von Produktentwicklungsteams gehört, die nach einer besseren Möglichkeit zum Experimentieren und zur Einführung von Funktionen in ihren Anwendungen suchen. Das Experimentieren in großem Maßstab ist schwierig - wir wollen es einfach machen. Und wir fangen gerade erst an.
In den kommenden Monaten werden wir ein C# SDK für das Experimentieren in .NET-Anwendungen einführen und weitere Optionen für die Ausführung von Experimenten in jeder Serversprache und kompatibel mit jedem CDN-Anbieter. Wir werden neue Workflows einführen, mit denen Sie neue Funktionen einfach umschalten oder einführen können. Außerdem werden wir eine Reihe von Funktionen veröffentlichen, die für die Skalierung auf große Unternehmen ausgelegt sind, mit mehr Kontrollmöglichkeiten für Berechtigungen, Audit-Protokollierung, Programmverwaltung und mehr.
Dies sind nur einige der Bereiche, von denen wir glauben, dass sie eine umfassende Plattform für das Experimentieren darstellen, die für jedes Produktentwicklungsteam geeignet ist. Wir freuen uns darauf, weiterhin in diesen Bereich zu investieren und unsere Kunden beim Experimentieren zu unterstützen.