A/B-Tests sind ist ein Mechanismus, der Besucher in Gruppen aufteilt, um unterschiedliche Erlebnisse zu ermöglichen. A/B-Tests helfen Ihnen, die Auswirkungen von Änderungen an der AI Agent-Erfahrung auf Ihre wichtigsten CX-KPIs zu verstehen, bevor Sie eine vorherige Version entfernen – und somit datengestützte Iterationen zu ermöglichen.
Das Add-on „AI Agents – Advanced“ bietet mehrere Möglichkeiten für die Durchführung von A/B-Tests.
API-/Labelbasierte Aufteilung
Basierend auf einem Feld, das von einer API stammt oder ein Label im Dialogfluss festlegt, können Sie dann innerhalb eines konditionalen Blocks verschiedene Pfade für Ihre Besucher festlegen.
Mögliche Beispiele für Trennkriterien:
Unabhängig davon, ob jemand einen Standardauslöser aktiviert, erhält dieser anschließend verschiedene Antworten.
Werden nach der Willkommensnachricht Schaltflächen statt der Absichtserkennung genutzt, erscheinen andere Nachrichten.
Im CRM können Sie jedes beliebige Feld verwenden, um die Gruppe zu unterteilen. Es könnte sich um eine angepasste Auswahl wie den Kundenstatus handeln oder um etwas Zufälligeres wie den Standort.
AI Agent und Kanal
Schon heute empfehlen wir, unterschiedliche Kundenerlebnisse nach Kanal zu differenzieren. Der Kommunikationsstil kann jedoch über verschiedene soziale Kanäle A/B-getestet werden, entweder durch den Einsatz unterschiedlicher AI Agents oder durch die Trennung nach der Messaging-Quelle, beispielsweise Facebook oder WhatsApp.
API-Aufteilung nach Traffic
Hinweis: Wenn Sie diese Funktion nutzen möchten, wenden Sie sich an Ihren CSM, um sie zu aktivieren.
Diese Integration wird mithilfe einer Integration namens TrafficSplit ausgeführt, die keine tatsächlichen Daten übertragen wird, da die Logik in unserem Dashboard gehostet wird. Diese Integration dient zur Kompilierung von inhaltsbasierten A/B-Tests. Die fiktive Integration ist notwendig, um die Randomisierung der Kontrollgruppenzuordnung zu unterstützen.
Gruppeneinteilung festlegen
Diese fiktive Integration verwendet einen Parameter mit der Bezeichnung split.
Der Parameter [split] verteilt Ihre Benutzer dynamisch auf die Anzahl und den Anteil der von Ihnen gewählten Kontrollgruppen – Sie müssen die Anteile nicht selbst auf 100 aufsummieren, sondern nur sicherstellen, dass sie proportional sind. Nachstehend finden Sie einige Beispiele für aufgeteilte Proportionen.
1 = 1 Kontrollgruppe mit 100 %
1,1 = 2 Kontrollgruppen mit einem gleichen Anteil von je 50 %
1,1,1 = 3 Kontrollgruppen mit einem gleichen Anteil von je 33,333333333333 %
1,2,1 = 3 Kontrollgruppen, eine mit einem Anteil von je 50 %, die anderen zwei mit je 25 % – die Kontrollgruppe und eine Variante werden jeweils 25 % haben.
Sie können sie auch als Prozentsätze (z. B. 50,50) einstellen; wichtig ist nur das Verhältnis zueinander.
Die Gruppen werden immer wie folgt benannt: Die erste Gruppe ist [control], die zweite [variant_1], die dritte [variant_2] und so weiter.
Die erste Gruppe ist immer die [control]-Gruppe.
Dialog einrichten
Dieser Parameter kann spätestens beim simulierten Integrationsaufruf festgelegt werden; für eine gleichmäßige und unverzerrte Verteilung Ihrer Benutzerbasis wird jedoch empfohlen, ihn zu Ihrer Willkommensantwort hinzuzufügen. Sofern vom CRM unterstützt, kann der Parameter auch für spezifische Antworten gesetzt werden, die Sie testen möchten.
- Legen Sie den Parameter „split“ als Zeichenfolge in den Konversationsdaten und ein Label fest, um die Konversationen zu identifizieren, die in die Besucheraufteilung einfließen.
- Fügen Sie einen API-Integrationsblock hinzu und wählen Sie trafficSplit als Integrationsquelle aus
-
Parameteraufteilung erfassen: Wenn Sie diesen Parameter noch nicht festgelegt haben, wählen Sie ihn spätestens im Zweig „Parameter erfassen“ aus. Bei Bedarf können Sie diese Verzweigung ausblenden, indem Sie die Nachricht des AI Agents löschen und die Sammlung einklappen.
Szenarioergebnisse: Verwenden Sie sie ganz nach Belieben. Bei diesem Szenario wird nur eines bewirkt: die Konversation wird einer Kontrollgruppe zugewiesen.
apiError-Szenario: Es ist äußerst unwahrscheinlich, dass dieser Auslöser aktiviert wird, da es keine reale API ist. Achten Sie jedoch darauf, einen Fallback hinzuzufügen, damit das Kundenerlebnis nahtlos bleibt und der AI Agent auch dann weiter funktionieren kann, wenn die gefälschte Integration blockiert wird. Sie können eine Willkommensantwort wie jede andere geben, stellen Sie aber sicher, dass Sie alle erforderlichen Parameter festlegen, die für das Fortschreiten in späteren Dialogen benötigt werden könnten. - Speichern Sie Ihren Parameter in den Konversationsdaten, indem Sie eine Beschriftung für den Wert hinzufügen {{variant}}.
Innerhalb des Szenario-Erfolgspfads wird auch empfohlen, ein Konversations-Dokumentenlabel hinzuzufügen, um den gesamten Batch von Konversationen zu identifizieren, die während Ihres A/B-Tests einer Kontrollgruppe zugewiesen wurden.
Verwenden von TrafficSplit-Varianten
Im Prinzip können Sie sofort nach Anwendung der fingierten Integrationsergebnisse fortfahren, müssen es aber nicht. Jetzt haben Sie einen Parameter [split] mit den einzelnen [variant] Ergebnissen von [control], [variant_1], [variant_2] usw. Sie können diesen jederzeit über konditionale Blöcke verzweigen.
Bei diesem TrafficSplit geben wir dem Kunden drei verschiedene Lösungen an die Hand: zwei verschiedene Self-Service-Links und eine in der AI Agent-API. Alle Benutzer werden einem konditionalen Block basierend auf ihrem zufällig zugewiesenen {{variant}}{{variant}} Ergebnis zugewiesen. Der Fallback unterstützt einen speziellen ApiError-Fall. Entwickeln Sie ihn so, dass er sich nahtlos in die Kundenerfahrung einfügt, und versehen Sie ihn mit Stichwörtern in den Konversationsprotokollen, um ihn später leicht auffinden und Probleme beheben zu können.
Jetzt müssen Sie nur noch eine Erfolgsmetrik zu definieren, z. B. CSAT oder „AI Agent-Handled“, und Ihre [variante] Ergebnisse mit einem Label in den Variantenpfaden vergleichen. Alternativ auch per Tableau.