Cross-device experimentation

Die Customer Journey eines Kunden beschränkt sich selten auf ein einzelnes Gerät. Von Smartphones über Tablets bis hin zu Desktop-Computern wechseln Benutzer regelmässig zwischen Geräten. Cross-Device-Experimentierung adressiert diese Herausforderung. Auch wenn das Überbrücken der Lücke zwischen Geräten eine nuancierte Herausforderung darstellt und keine Lösung perfekt ist, ermöglichen die richtigen Werkzeuge – wie zuverlässige Benutzer-IDs und durchdachte Datenpraktiken – Einblicke in die Erfahrungen der Besucher an allen Touchpoints.

​

Was Kameleoons Cross-Device-Experimentierung leisten kann​

• Konsistenz der Variationen sicherstellen: Angemeldete Benutzer sehen in einem Experiment immer dieselbe Variation, unabhängig vom verwendeten Gerät.
• Einheitliches Targeting ermöglichen: Berücksichtigen Sie alle Besuche und Aktionen eines einzelnen Benutzers, unabhängig vom Gerät.
• Genaues Reporting bereitstellen: Zählen Sie eindeutige Benutzer geräteübergreifend genau, um deren Verhalten besser zu verstehen.

​

Kritische Punkte und praktische Erkenntnisse​

• Das geräteübergreifende Tracking hängt stark von der Identifizierung der Benutzer ab. Bleibt ein Benutzer geräteübergreifend anonym, ist das Zusammenführen seiner Daten unmöglich. Kein System kann diese Einschränkung umgehen.
• Eine zuverlässige Benutzer-ID (zum Beispiel eine, die mit einem Login verknüpft ist) ist unerlässlich, um Daten geräteübergreifend zu verknüpfen. Ohne eine zuverlässige ID ist das Zusammenführen von Browser-Verläufen oder Aktionen nicht möglich.
• In einem anonymen Zustand durchgeführte Aktionen (zum Beispiel das Surfen ohne Anmeldung) können erst dann einem identifizierten Benutzer zugeordnet werden, wenn eine Anmeldung erfolgt. Sobald der Benutzer angemeldet ist, wird sein Verlauf zusammengeführt – aber nur ab diesem Zeitpunkt.
  • Beachten Sie jedoch, dass Kameleoon bei Web Experimentation, sobald die Custom Data bereitgestellt wird, sie für alle nachfolgenden Besuche auf demselben Gerät abrufen kann, auch wenn sich der Benutzer noch nicht angemeldet hat. Dieser Abruf erfolgt, weil die Daten im Local Storage gespeichert sind, was in Feature Experimentation nicht der Fall ist.
• Auch wenn die Cross-Device-Experimentierung für viele Anwendungsfälle funktioniert, ist sie nicht für jedes Experiment geeignet. Cross-Device-Experimentierung hängt von Ihrem Tech-Stack, den Customer Journeys Ihrer Benutzer und Ihren Zielen ab.

​

Identitätsgrenzen verstehen​

Im Kontext der Cross-Device-Experimentierung beziehen sich Identitätsgrenzen darauf, wie Kameleoon Benutzer über verschiedene Sitzungen, Geräte und Identifikationszustände hinweg erkennt und behandelt. Diese Grenzen sind entscheidend dafür, ob Kameleoon Benutzerdaten über Erlebnisse hinweg verknüpfen kann. Kameleoon unterscheidet hauptsächlich zwischen zwei Arten von Benutzeridentitäten:

• Anonyme Benutzer: Dies sind Benutzer, die nicht angemeldet sind und durch eine temporäre, gerätebasierte Kennung (visitorCode) identifiziert werden. Anonyme Kennungen sind eindeutig für das Gerät und den Browser und bleiben nicht geräteübergreifend bestehen.
• Identifizierte Benutzer: Dies sind Benutzer, die sich anmelden und konsistente sowie eindeutige Kennungen (z. B. eine Benutzer-ID) bereitstellen. Diese Kennung ist mit dem einzelnen Benutzer verknüpft und ermöglicht es Kameleoon, dessen Aktionen und Verlauf über Geräte und Sitzungen hinweg zusammenzuführen.

​

Aktivieren der Cross-Device-Verlaufsabgleichung​

Um die Cross-Device-Verlaufsabgleichung zu verwenden, erstellen Sie einen neuen Kameleoon-Eintrag für Custom Data und aktivieren Sie die Option Use this custom data as a unique identifier for cross-device matching. Bei Aktivierung behandelt Kameleoon diese Custom Data als eindeutige Kennung für Besucher, wodurch mehrere Kameleoon-Besuche einem einzigen Benutzer zugeordnet werden. Sie müssen auch den Wert der Custom Data mit einer eindeutigen Kennung wie einer Benutzer-ID festlegen, indem Sie eine der Erfassungsmethoden verwenden, z. B. die SDK-Methode addData() oder die Activation API.

​

Cross-Device-Verlaufsabgleichung für Konsistenz der Variationszuweisung​

Das Ziel der Cross-Device-Verlaufsabgleichung für die Variationszuweisung besteht darin, sicherzustellen, dass den einem Experiment zugewiesenen Besuchern unabhängig vom verwendeten Gerät stets dieselbe Variation angezeigt wird. Es ist jedoch wichtig zu erkennen, dass die Aufrechterhaltung dieser Konsistenz in bestimmten Szenarien eine Herausforderung darstellen kann. Wenn beispielsweise ein Benutzer die Website auf seinem ersten Gerät besucht, sich anmeldet und ein Experiment auslöst, kann Kameleoon die Variation V1 zuweisen. Besucht derselbe Benutzer die Website anschliessend auf einem anderen Gerät und löst dasselbe Experiment vor dem Anmelden aus, kann das System die Variation V2 zuweisen. Diese Inkonsistenz entsteht, weil das System den Benutzer noch nicht geräteübergreifend erkannt hat. Kameleoon überschreibt die Variationszuweisung innerhalb eines einzelnen Besuchs bewusst nicht, um das Benutzererlebnis nicht zu stören. Um dieses Problem zu mindern und Konsistenz sicherzustellen, identifizieren Sie Besucher umgehend während ihrer gesamten Reise auf der Website. Eine frühzeitige Identifizierung der Besucher, wenn sie auf die Website von verschiedenen Geräten aus zugreifen, gewährleistet, dass ihnen konsequent dieselbe Variation zugewiesen wird. Dieser Ansatz ermöglicht es Kameleoon, ein nahtloses und kohärentes Testerlebnis bereitzustellen.

​

Kameleoon Web Experimentation​

Die Lösung Kameleoon Web Experimentation nutzt hauptsächlich clientseitige Speichermechanismen zur Verwaltung der Variationszuweisung (Bucketing). Die Variationszuweisung der Benutzer wird zunächst im Local Storage gespeichert, wenn sie an einem Experiment teilnehmen. Diese Speicherung stellt sicher, dass ein Benutzer auf demselben Gerät konsequent dieselbe Variation sieht, selbst wenn der Kunde die Traffic-Verteilung des Experiments aktualisiert. Falls sich derselbe Benutzer auf einem anderen Gerät anmeldet, ruft Kameleoon die zuvor zugewiesenen Variationsinformationen aus dem Backend ab. Wird dasselbe Experiment nach diesem Schritt ausgelöst, weist Kameleoon dem Benutzer dieselbe Variation zu. Diese Synchronisierung stellt sicher, dass eine Variation geräteübergreifend konsistent angewendet wird, ohne dass eine neue Variation durch Bucketing zugewiesen wird.

​

Cross-Device-Experimentierung für Feature Experimentation​

Feature Experimentation findet in Umgebungen statt, in denen Daten für die Dauer einer Sitzung im Speicher gehalten werden (Standard ist 30 Minuten, was sie zu einem unzuverlässigen Speicher für ablaufende Variationszuweisungen macht). SDKs lösen Variationen dynamisch zur Laufzeit auf, was einzigartige Komplexitäten für die Cross-Device-Konsistenz mit sich bringt.

​

Rolle der SDKs​

SDKs sind für Feature Experimentation unerlässlich, da sie:

• Variationszuweisungen dynamisch basierend auf der Benutzeridentität (visitorCode, der vom SDK zufällig generiert wird, oder Ihre eigene Benutzer-ID) auflösen, wenn das Targeting stattfindet.
• Identitätsauflösung verwenden, um zuvor erfasste Daten geräteübergreifend abzurufen und so eine konsistente Variationszuweisung sicherzustellen, wenn der Benutzer Geräte wechselt.

​

Herausforderungen und Überlegungen​

• Kein Local Storage: Im Gegensatz zu Kameleoon Web Experimentation werden Variationen nicht dauerhaft gespeichert; sie werden zur Laufzeit basierend auf der Benutzeridentität neu berechnet.
• Anonyme Sitzungen: Konsistenz sicherzustellen, wenn Benutzer anfangs anonym sind und sich später anmelden, kann komplex sein.
• Cross-Device-Identitätsauflösung: Die genaue Zuordnung von Experimentvariationen über Geräte hinweg hängt von einer robusten Identitätsauflösung ab.

​

Beispiele für Anwendungsfälle​

Die folgenden Anwendungsfälle stellen die häufigsten Szenarien dar, die bei der Implementierung der Cross-Device-Experimentierung auftreten. Diese Beispiele verdeutlichen typische Herausforderungen und Lösungen, um konsistente Benutzererlebnisse und eine genaue Variationszuordnung über mehrere Geräte hinweg zu gewährleisten.

​

Anwendungsfall 1 (gleiches Gerät)​

In der ersten Sitzung wird ein anonymer Benutzer von einem Experiment angesprochen und meldet sich anschliessend an. In der zweiten Sitzung ist der Besucher angemeldet und wird vom selben Experiment angesprochen.

• Web experimentation: Die Variation bleibt konsistent mit der Variation, die während der ursprünglichen Sitzung zugewiesen wurde, da Kameleoon die zuvor zugewiesene Variation aus dem Local Storage abruft.
• Feature experimentation: Falls Sie die anonyme Besucher-ID mithilfe einer Custom Data der Benutzer-ID zugeordnet haben, wird dieselbe Variation zurückgegeben, wenn getVariation() entweder mit der anonymen ID oder der Benutzer-ID aufgerufen wird. Wird getVariation() jedoch mit der Benutzer-ID aufgerufen und gibt es keine Zuordnung zwischen der Benutzer-ID und der anonymen ID, wird eine neue Variation zugewiesen.

​

Anwendungsfall 2 (gleiches Gerät)​

Ein Benutzer meldet sich an und wird während einer Sitzung von einem Experiment angesprochen. In einer nachfolgenden Sitzung meldet sich der Benutzer ab, wird anonym und wird vom selben Experiment angesprochen.

• Web experimentation: Die Variation bleibt konsistent mit der während der ursprünglichen Sitzung zugewiesenen Variation, da Kameleoon die zuvor zugewiesene Variation aus dem Local Storage abruft und so die Kontinuität zwischen den Sitzungen gewährleistet.
• Feature experimentation:
  • Falls der Benutzer während Sitzung 1 von einem anonymen Zustand (anonymous1) in einen identifizierten Zustand (userId) übergegangen ist und die anonyme ID der Benutzer-ID zugeordnet wurde, verwendet Kameleoon in Sitzung 2 erneut anonymous1, um den Benutzer mit derselben Variation zu bucketen.
  • Wurde jedoch in Sitzung 1 kein anonymer Zustand verwaltet (durch Aufruf der Methode getVisitorCode()), wird für Sitzung 2 ein neuer visitorCode (anonymous2) generiert, was zu einer neuen Variationszuweisung führt.

​

Anwendungsfall 3 (unterschiedliche Geräte)​

Ein anonymer Benutzer meldet sich auf einem Gerät an und wird während derselben Sitzung von einem Experiment angesprochen. In einer späteren Sitzung auf einem anderen Gerät beginnt der Benutzer anonym, wird vom selben Experiment angesprochen und meldet sich anschliessend an.

• Web experimentation: In diesem Szenario erhält der Benutzer möglicherweise zwei unterschiedliche Variationen, da Kameleoon den Benutzer auf dem zweiten Gerät bei der Targeting-Entscheidung nicht erkennt. Die Variationszuweisung auf dem zweiten Gerät erfolgt, bevor sich der Benutzer anmeldet, was zu fehlender Synchronisierung zwischen den Geräten führt.
• Feature experimentation: Wie bei Web Experimentation erhält der Benutzer möglicherweise zwei unterschiedliche Variationen, da Kameleoon den Benutzer auf dem zweiten Gerät bei der Targeting-Entscheidung nicht erkennt. In diesem Fall erfolgt die Variationszuweisung auf dem zweiten Gerät, bevor sich der Benutzer anmeldet, was bedeutet, dass keine Synchronisierung zwischen den Geräten erfolgt.

​

Anwendungsfall 4 (unterschiedliche Geräte)​

Ein anonymer Benutzer meldet sich auf dem ersten Gerät an und wird von einem Experiment angesprochen. Später, auf einem zweiten Gerät, meldet sich der Benutzer an, bevor er vom selben Experiment angesprochen wird.

• Web experimentation: Die Variation bleibt geräteübergreifend konsistent. Da sich der Benutzer anmeldet, bevor das Experiment neu bewertet wird, gleicht das System die Variation mit der auf dem ersten Gerät zugewiesenen Variation ab.
• Feature experimentation: Kameleoon bestimmt die Variationszuweisung anhand der Zuordnung der Benutzer-ID zur zuletzt generierten anonymen ID des Besuchers.
  • Auf Device 1 wird ein anonymer Besucher (anonymous1) für das Experiment bewertet und erhält eine Variation (var1). Bei der Anmeldung erstellt Kameleoon eine Zuordnung zwischen userId und anonymous1.
  • Auf Device 2 kann Kameleoon, falls die Sitzung direkt mit der userId beginnt (ohne Aufruf von getVisitorCode(), der eine anonyme ID erzeugt), durch den Aufruf von getRemoteVisitorData(userId) die Zuordnung zum zuletzt generierten anonymen Besucher (anonymous1) abrufen. Folglich erhält der Benutzer beim Aufruf von getRemoteVisitorData() und getVariation() für das Experiment die anonymous1 zugewiesene Variation (var1). Beginnt die Sitzung jedoch in einem anonymen Zustand, kann eine neue Variation zugewiesen werden, da beim Bucketing der neu generierte Bucketing-Schlüssel verwendet wird.

​

Anwendungsfall 5 (unterschiedliche Geräte)​

Ein anonymer Benutzer wird auf einem Gerät von einem Experiment angesprochen und meldet sich an. Auf einem zweiten Gerät meldet sich der Benutzer an und wird vom selben Experiment angesprochen.

• Web experimentation: Die Variation bleibt geräteübergreifend konsistent. Sobald sich der Benutzer anmeldet, kann das System dem Benutzer dieselbe Variation zuordnen.
• Feature experimentation: Die Variation bleibt nur dann konsistent, wenn Sie getRemoteVisitorData() aufrufen. Ohne diesen Aufruf verknüpft das System die beiden Sitzungen möglicherweise nicht, was zu unterschiedlichen Variationszuweisungen über Geräte hinweg führen kann.

​

Cross-Device-Verlaufsabgleichung für das Targeting​

Kameleoon lädt automatisch eine Liste der Besuche von anderen Geräten herunter und speichert diese Informationen im Speicher des aktuellen Geräts, wenn eine neue Sitzung beginnt und eine Custom Data mit einem Wert festgelegt wird. Falls die Custom Data jedoch leer ist, wird zu Beginn der Sitzung keine Abgleichung durchgeführt. Die Abgleichung wird nur ausgelöst, wenn die Custom Data übergeben wird, und das Targeting wird für alle aktiven Experimente und Personalisierungen neu bewertet. Typischerweise geschieht dies, wenn sich ein Benutzer auf Ihrer Website anmeldet und seine Benutzer-ID, E-Mail oder eine andere eindeutige Kennung angibt. Es ist wichtig zu beachten, dass Kameleoon die Custom Data, sobald sie bereitgestellt wurde, für alle nachfolgenden Besuche auf demselben Gerät abrufen kann, auch wenn sich der Benutzer noch nicht angemeldet hat. Die Abgleichung erfolgt zu Beginn jedes nachfolgenden Besuchs und gewährleistet konsistente Tracking- und Targeting-Funktionen.

​

Daten, die von der Cross-Device-Verlaufsabgleichung betroffen sind​

Die Funktion zur Verlaufsabgleichung fügt die Liste aller vorherigen Besuche hinzu, die dem aktuellen Gerät noch nicht bekannt sind. Dazu gehören typische Informationen wie:

• Anzahl der Besuche und Seitenaufrufe
• Sitzungsdauer
• Akquisitionskanäle und Referrer
• Custom Data (Hinweis: Custom Data, die in anderen Sitzungen mit Besucher-Scope bereitgestellt werden, werden mit der aktuellen Sitzung zusammengeführt).

Sie können Targeting-Segmente wie gewohnt verwenden, und sie funktionieren wie erwartet. Beispielsweise berücksichtigt eine Targeting-Bedingung basierend auf der Anzahl früherer Besuche korrekt alle Besuche, ebenso wie eine Bedingung basierend auf der Dauer des vorherigen Besuchs.

​

Cross-Device-Verlaufsabgleichung für Analytics​

Die Verlaufsabgleichung wirkt sich nur auf die Ansicht Besucher im Kameleoon-Reporting aus; die Ansicht Besuch bleibt unberührt. Im Besuchermodell werden mehrere Sitzungen anstelle einer Gruppierung in einem einzigen Besucherdatensatz anhand des standardmässigen Kameleoon-Werts visitorCode (was nur für wiederkehrende Besucher auf demselben Gerät möglich ist) anhand des Werts der Custom Data zusammengeführt. Falls die Custom Data leer oder nicht bereitgestellt ist, wird stattdessen der Wert visitorCode verwendet. Dieser Ansatz stellt sicher, dass die Metriken eindeutiger Besucher genau bleiben, auch wenn der Benutzer im Kundensystem noch nicht identifiziert ist (diese Logik gilt jedoch nur für wiederkehrende Besucher auf demselben Gerät). Folglich zeigt die Besucheransicht für identifizierte Benutzer Metriken über alle Geräte hinweg korrekt an. Beispielsweise zählt ein einzelner Kunde mit drei Sitzungen auf zwei verschiedenen Geräten als ein einzelner Besucher. Ohne Verlaufsabgleichung würde derselbe Kunde als zwei unterschiedliche Besucher gezählt (einer pro Gerät).

​

Verwendung von Custom Data zur Sitzungszusammenführung​

Die Verwendung von Custom Data als eindeutige Kennung für die Sitzungszusammenführung ist nur für Sitzungen möglich, die gespeichert wurden, nachdem Kameleoon festgelegt hat, welche Custom Data zu verwenden ist. Daher empfiehlt Kameleoon dringend, die Custom Data bereits bei der ersten Installation und Konfiguration auszuwählen, um spätere Änderungen zu vermeiden. Wenn Kameleoon beispielsweise einen Monat lang ohne aktivierte Cross-Device-Verlaufsabgleichung läuft und diese im zweiten Monat aktiviert wird, zählt ein einzelner Benutzer, der zweimal (einmal in jedem Monat) besucht hat, als zwei verschiedene Besucher. Diese Diskrepanz entsteht, weil die Sitzungszusammenführung im ersten Monat den visitorCode als Schlüssel verwendet, während sie im zweiten Monat die Custom Data mit einem anderen Wert verwendet, selbst wenn sich der Benutzer bei beiden Besuchen mit demselben Gerät angemeldet hat. Jede Änderung am Setup der Custom Data, die für die Verlaufsabgleichung verantwortlich ist, beeinträchtigt vorübergehend die Genauigkeit der besucherbasierten Metriken, da sich die Mehrheit der Besucher anmeldet, abhängig davon, wie oft sie zur Website zurückkehren und sich authentifizieren.