Zum Hauptinhalt springen
Koordinieren Sie Kameleoon SDKs ueber Websites, mobile Apps und Backend-Server hinweg, um eine einheitliche Besucher-Identitaet beizubehalten. Diese Koordination gewaehrleistet eine konsistente Experiment-Behandlung und einen einheitlichen Datenfluss ueber alle Plattformen hinweg. Verwenden Sie diese Anleitung, wenn ein Projekt mehrere Kameleoon SDKs implementiert:
  • Das JavaScript SDK oder engine.js fuer Web-Umgebungen.
  • Das mobile SDK fuer Android- oder iOS-Apps.
  • Serverseitige SDKs fuer Backend-Integrationen und Entscheidungslogik.

​
Architekturuebersicht

Eine typische Multi-Umgebungs-Einrichtung umfasst die folgenden Komponenten:
  • Website: Verwendet das JavaScript SDK oder engine.js, um clientseitige Experimente und Personalisierungskampagnen auszufuehren.
  • Mobile App: Verwendet ein mobiles SDK, um Variationen anzuzeigen und Conversions zu verfolgen.
  • Backend-Server: Verwendet ein serverseitiges SDK, um zentrale Variationsentscheidungen zu treffen oder Besucherdaten zu synchronisieren.

​
Daten- und Visitor-Code-Fluss

  • Der Visitor-Code identifiziert Benutzer konsistent ueber alle Umgebungen hinweg.
  • Das serverseitige SDK koordiniert bei Bedarf die Variationsentscheidungen.
  • Jedes SDK sendet Analyse- und Tracking-Daten direkt an die Kameleoon-Plattform.

​
Visitor-Code und geraeteuebergreifende Verwaltung

​
Visitor-Codes generieren und teilen

Jeder eindeutige Besucher muss einen konsistenten Visitor-Code auf allen Plattformen haben. Dieser Code ermoeglicht es Kameleoon, Experiment-Entscheidungen und Tracking zu vereinheitlichen. Folgen Sie diesem plattformuebergreifenden Ablauf:
  1. Die Engine, das Web-SDK, das serverseitige SDK oder die mobile Anwendung generiert den Visitor-Code.
  2. Das Backend ruft den bestehenden Visitor-Code ab, wenn sich der Benutzer auf einer neuen Plattform anmeldet.
  3. Das System uebergibt den Visitor-Code an die mobilen, serverseitigen und Web-SDKs. Dies stellt sicher, dass alle Plattformen denselben Benutzer konsistent bewerten.

​
Visitor-Codes synchronisieren

  • Speichern Sie den Visitor-Code sicher im Backend oder in der Benutzerdatenbank und verknuepfen Sie ihn mit der Benutzer-ID.
  • Folgen Sie diesen Schritten, wenn eine Benutzeranmeldung auf einer anderen Plattform erfolgt:
    • Mobile App: Fordern Sie den Visitor-Code beim Backend an.
    • Serverseitiges SDK: Verwenden Sie denselben Visitor-Code fuer alle Variations- und Tracking-Aufrufe.
    • Web-SDK: Setzen Sie den Visitor-Code mit der JavaScript-API:
kameleoon.API.Visitor.setVisitorCode(visitorCode);
Das Web-SDK und das serverseitige SDK kommunizieren automatisch ueber das Cookie kameleoonVisitorCode. Sie muessen keine zusaetzlichen Schritte ausfuehren, um diese beiden zu verknuepfen.

​
Best Practices

  • Ordnen Sie die bestehende Benutzerkennung (z. B. userId) einem einzigen Kameleoon Visitor-Code auf allen Plattformen zu.
  • Behalten Sie das Backend als verlaessliche Quelle fuer Visitor-Codes bei.
  • Verhindern Sie, dass SDKs vorhandene Visitor-Codes bekannter Benutzer ueberschreiben.
Eine einheitliche Identifikation stellt sicher, dass jede Benutzeraktion, jede Conversion und jede Variationsentscheidung mit demselben Besucher in Kameleoon verknuepft wird.

​
Experiment-Behandlung in verschiedenen Umgebungen

Koordinieren Sie Entscheidungen und Variationsanzeigen fuer Experimente, die mehrere Umgebungen umfassen, etwa Mobile und Backend.

​
Beispielszenario

In diesem Szenario:
  • Die mobile App zeigt die Variation an.
  • Der Backend-Server bestimmt die zugewiesene Variation.

​
Implementierungsoptionen

Option 1: Serverseitige Entscheidungslogik
  1. Die mobile App sendet den Visitor-Code an das Backend.
  2. Das serverseitige SDK ruft getVariation() (oder das Aequivalent) auf, um die zugewiesene Variation abzurufen.
  3. Das Backend gibt die Variations-ID oder den Namen an die mobile App zurueck.
  4. Die mobile App zeigt die Variation an und verfolgt die Exposition.
  5. Sowohl das mobile als auch das Server-SDK verwenden denselben Visitor-Code fuer das Event-Tracking.
Vorteile:
  • Zentralisiert die Variationslogik und gewaehrleistet konsistente Entscheidungen.
  • Unterstuetzt Experimente, die sowohl die Backend-Logik als auch UI-Elemente beeinflussen.
Option 2: Clientseitige (mobile) Entscheidungslogik
  1. Das mobile SDK ruft die Variationszuweisung mithilfe des Visitor-Codes ab.
  2. Die mobile App wendet die Variation lokal an und verfolgt die Exposition direkt.
  3. (Optional) Wenn das Backend ebenfalls am Tracking oder an der Validierung beteiligt ist, verwendet das serverseitige SDK denselben Visitor-Code, um eine konsistente Berichterstattung sicherzustellen.
Vorteile:
  • Liefert eine synchrone Entscheidung ohne Latenz.
  • Reduziert die Latenz, indem ein Server-Roundtrip vermieden wird.
  • Optimiert UI-fokussierte Experimente, die nicht von der Backend-Logik abhaengen.

​
Die richtige Einrichtung waehlen

AnwendungsfallEntscheidungsebeneQuelle des Visitor-CodesHinweise
Mobiles UI-ExperimentMobile SDKBackendVariation wird lokal behandelt
Backend- oder API-gesteuertServerseitiges SDKApp oder WebsiteZentrale Entscheidungslogik
Geraeteuebergreifende KonsistenzBeliebigBackendGewaehrleistet einheitliches Tracking

​
Codebeispiele: Visitor-Code zwischen den Ebenen weitergeben

const visitorCode = kameleoon.API.Visitor.code;
fetch("/api/syncVisitor", {
  method: "POST",
  body: JSON.stringify({ visitorCode }),
});
Um die SDK-Implementierung ueber verschiedene Ebenen hinweg zu handhaben:
  • Weisen Sie jedem Benutzer auf allen Plattformen einen einzigen Visitor-Code zu.
  • Verwalten und verteilen Sie Visitor-Codes vom Backend aus.
  • Waehlen Sie die Variationslogikebene basierend auf dem Experimenttyp aus (Server fuer zentrale Logik, clientseitig fuer App-gesteuerte UI).
  • Behalten Sie konsistente, geraeteuebergreifende Daten bei, indem Sie die gesamte Benutzeraktivitaet mit demselben Visitor-Code verfolgen.