Übersicht

A/B-Tests oder Canary-Bereitstellungstechniken ermöglichen es Entwicklern, mit zwei oder mehr Varianten einer Webseite zu experimentieren. Varianten werden Benutzern nach dem Zufallsprinzip angezeigt. Anschließend wird mithilfe statistischer Analysen ermittelt, welche Variante für ein bestimmtes Geschäftsziel besser abschneidet. Beispielsweise kann die UI-Variante einer Produktseite mit dem Ziel getestet werden, den Produktumsatz zu steigern.

Architektur-Entscheidungen

Sie können A/B-Tests je nach Ihren technischen und geschäftlichen Anforderungen auf unterschiedliche Weise implementieren. Eine der wichtigsten technischen Entscheidungen ist, wo die Variantenauswahllogik ausgeführt werden soll: auf der Clientseite, auf der Edge-Serverseite (auf CDN-Ebene) oder auf der Seite des Ursprungsservers.

Variantenauswahl auf Ursprungsserver-Seite. Bei diesem Ansatz wird die A/B-Auswahl direkt auf dem Ursprungsserver ausgeführt, auf dem die Webanwendung gehostet wird. Dieser Ansatz ist zwar CDN-unabhängig, aber nicht mit CDN-Caching oder statischem Datei-Hosting kompatibel. Dies ist eine Option für serverseitig gerenderte Webanwendungen, die vollständig dynamisch sind.

Variantenauswahl auf Edge-Server-Seite. Bei diesem Ansatz wird die Entscheidung zur Variantenauswahl auf CDN-Ebene getroffen. Der Ansatz erfordert minimale bis gar keine Änderungen an der Anwendung und ist mit CDN-Caching kompatibel. In CloudFront können Sie die A/B-Testlogik mithilfe von Edge-Funktionen implementieren. Eine Edge-Funktion kann die Anforderungsattribute (Land, Cookie usw.) zusätzlich zur externen A/B-Test-API verwenden, um eine der Varianten auszuwählen und sie von CloudFront aus dem Cache bereitstellen zu lassen.

Variantenauswahl auf Clientseite. Bei diesem Ansatz stellt Ihr Frontend zunächst eine Anfrage an eine A/B-Test-API, um zu entscheiden, welche Variante bereitgestellt werden soll. Die Variante wird dann abhängig von der Antwort heruntergeladen und im Browser gerendert. Bei diesem Ansatz sind Ihre A/B-Tests CDN-unabhängig, sie sind jedoch eng mit Ihrer Anwendung verknüpft und führen aufgrund zusätzlicher Schritte auf der Clientseite zu zusätzlicher Latenz. Beachten Sie auch, dass diese Option nicht immer verfügbar, z. B. für A/B-Tests statisch generierter Websites (SSG). Zur Implementierung clientseitiger A/B-Tests können Sie CloudWatch Evidently verwenden. Es stellt das Client-SDK und die Benutzeroberfläche zur Steuerung von A/B-Testexperimenten bereit. Ein praktisches Tutorial zu CloudWatch Evidently finden Sie in diesem Workshop.

Konzentrieren wir uns auf Edge-Server-seitige A/B-Tests. Um die für Ihr Unternehmen beste Implementierung zu erreichen, sollten Sie die folgenden zusätzlichen Fragen berücksichtigen:

  • Benötigen Sie Stickiness (z. B. dass derselbe Benutzer immer dieselbe Variante erhält)? Stickiness wird normalerweise mithilfe von Cookies implementiert.
  • Welche Dimensionen werden verwendet, um eine Variante für einen Benutzer auszuwählen? Land, Benutzer-ID usw.
  • Wie oft führen Sie A/B-Tests durch? Der intensive Einsatz von A/B-Tests mit vielen Experimenten, die von verschiedenen Teams parallel ausgeführt werden, erfordert eine aufwändigere Implementierung im Vergleich zu einfacheren, gelegentlichen A/B-Tests.

Wenn Sie mehr über einige der Edge-Service-seitigen Implementierungen von A/B-Tests mithilfe der Edge-Funktionen von CloudFront erfahren möchten, sollten Sie sich diesen Workshop ansehen. Im folgenden Abschnitt werden wir zwei gängige Implementierungen von A/B-Tests mit CloudFront aus dem oben genannten Workshop vorstellen.

Typische Anwendungsfälle für Edge-Server-seitige A/B-Tests

Gelegentliche A/B-Tests

Für gelegentliche A/B-Testanforderungen, wie z. B. vierteljährliche Designverbesserungen einer institutionellen Website, sollten Sie für die Dauer Ihres Experiments eine auf CloudFront Functions basierende Lösung in Betracht ziehen. Die Lösung basiert auf zwei Funktionen, die auf dem Cache-Verhalten konfiguriert sind, das mit der Seite übereinstimmt, für die Sie A/B-Tests ausführen möchten:

  • Eine Viewer-Anfragefunktion, die den Test-Cookie-Wert eingehender Anfragen prüft und basierend darauf die URL in die ausgewählte Seitenvariante umschreibt. Wenn das Cookie nicht vorhanden ist, wählt die Funktion die Variante anhand Ihrer benutzerdefinierten Logik aus, z. B. 60 % für Variante A und 40 % für Variante B, nur für Anfragen aus Frankreich.
  • Eine Viewer-Antwortfunktion, die das Cookie auf dem Client basierend auf der ausgewählten Variante festlegt, sofern das Cookie nicht bereits vorhanden war. Das Experiment-Cookie wird verwendet, um sicherzustellen, dass ein einzelner Benutzer immer die gleiche Variante der Seite erhält, damit dessen Web-Erlebnis nicht beeinträchtigt wird.

Das Ändern der Variantenauswahllogik, beispielsweise um den Prozentsatz von Variante B zu erhöhen, erfordert eine Aktualisierung des Funktionscodes des Viewer-Ereignisses, was im Allgemeinen Sekunden dauert. Wenn Sie mit dem A/B-Test-Experiment fertig sind, können Sie die Edge-Funktionen entfernen, um Kosten zu sparen.

Regelmäßige A/B-Tests

Wenn Sie auf Ihrer Website fortlaufend A/B-Tests vornehmen und täglich Experimente durchführen, können Sie weiterhin die bisherige, auf CloudFront-Funktionen basierende Lösung verwenden. Es wird jedoch empfohlen, die Variantenauswahl-Parameter (z. B. Variantengewichte) vom Funktionscode zu entkoppeln. Sie können einen CloudFront KeyValueStore verwenden, um solche Parameter außerhalb des Funktionscodes zu speichern. Der KeyValueStore eignet sich ideal als globaler (jeder PoP, Point of Presence) Lese- und Schlüsselwert-Datenspeicher
mit niedriger Latenz im großen Maßstab (Millionen von Anfragen pro Sekunde).

Beachten Sie, dass Ihr Anwendungsfall die KeyValueStore-Kontingente berücksichtigen sollte, z. B. die maximale Größe (5 MB) oder die Geschwindigkeitsbegrenzung für wenige API-Aufrufe pro Sekunde.

CapitalOne-Fallstudie: A/B-Tests mit CloudFront-Funktionen und KeyValueStore

Fortgeschrittene A/B-Tests

Ziehen Sie eine Lambda@Edge-basierte Lösung in Betracht, wenn eine auf CloudFront-Funktionen basierende Lösung Ihren A/B-Testbedarf nicht erfüllt, beispielsweise wenn die KeyValueStore-Kontingente für Ihren Anwendungsfall einschränkend sind. Dies kann der Fall sein, wenn Sie eine große E-Commerce-Website betreiben und viele Teams gleichzeitig Experimente an verschiedenen Teilen der Website mit hoher Geschwindigkeit durchführen.  Verwenden Sie in diesem Szenario Lambda@Edge anstelle der CloudFront-Funktion mit einer externen Datenquelle (z. B. DynamoDB Global Tables) zum Speichern der A/B-Testparameter. Feature-Management-Tools wie LaunchDarkly stellen Integrationen mit DynamoDB zur Verfügung, um die A/B-Testparameter beizubehalten.

Ressourcen

War diese Seite hilfreich?

 Feedback