Skip to main content

​
Uebersicht

Kameleoon-SDKs ermoeglichen es Ihnen, Experimente durchzufuehren, um die Benutzererfahrung in Web- und Mobilanwendungen zu verbessern. Basierend auf dem unten gezeigten Diagramm umfasst die Implementierung eines Experiments mit einem Kameleoon-SDK drei Phasen: Initialisierung, Benutzeridentifikation und Attributzuweisung sowie Variationszuweisung und Tracking. Dieser Artikel erlaeutert detailliert jede dieser Phasen.
SDK Flow
Die in jedem Schritt unten beschriebenen Methoden (und ihre Namen) haben unterschiedliche Syntaxen, basierend auf der Konvention der jeweiligen Sprache des SDKs.

​
1. Initialisierung

Bei der Initialisierung ruft das SDK alle aktualisierten Feature-Flag-Konfigurationen ueber das Content Delivery Network von Cloudflare ab, und zwar mit zwei Methoden: Polling, eine Standardoption, bei der das SDK in regelmaessigen Abstaenden (standardmaessig alle 60 Minuten) eine Anfrage an das CDN sendet, um die aktuellste Konfiguration zu erhalten, und Streaming, eine Premium-Option, bei der das Kameleoon-SDK ueber Server-Sent Events (SSE) in Echtzeit ueber jede Aenderung der Konfiguration benachrichtigt wird. Sobald die Konfigurationen abgerufen sind, beginnt das SDK mit der Zuweisung des Visitor-Codes sowie mit den Variationen und dem Targeting-Prozess. Weitere Informationen finden Sie in den technischen Ueberlegungen.
Wie im Diagramm gezeigt, ermoeglicht die Methode on_configuration_update waehrend des Streamings (denken Sie daran, dass der Name je nach SDK variiert), das Ereignis zu behandeln, wenn die Konfiguration aktualisierte Daten enthaelt. Sie benoetigt einen Eingabeparameter-Handler. Der Handler wird aufgerufen, wenn die Konfiguration ueber ein Echtzeit-Konfigurationsereignis aktualisiert wird. Weitere Informationen finden Sie in den einzelnen Web- und Mobile-SDKs.

​
2. Benutzeridentifikation und Attributzuweisung

In dieser Phase werden zur Berechnung der Variation der Visitor-Code zugewiesen und Benutzerattribute eingebunden:
  • 1. Visitor-Code zuweisen: Die Initialisierung bietet die Moeglichkeit, einem Besucher eine eindeutige ID zuzuweisen. Bei Web-SDKs ruft die Methode getVisitorCode() einen Visitor-Code aus dem Cookie der Request-Header ab. Wenn der Visitor-Code nicht existiert, generiert die Methode einen zufaelligen Visitor-Code und speichert ihn in einem Response-Header-Cookie. Bei mobilen SDKs wird der Visitor-Code aus dem Speicher des mobilen Geraets abgerufen.
  • 2. Benutzerattribute fuer Targeting-Zwecke hinzufuegen: Die Targeting-Bedingungen von Kameleoon ermoeglichen die Aktivierung von Feature Flags basierend auf Benutzerattributen. Um diese Bedingungen effektiv zu nutzen, setzen Sie die Werte mit der Methode addData() und/oder getRemoteVisitorData(), um spezifische Kriterien abzurufen und zu verwenden. Benutzerattribute werden dann im Serverspeicher fuer serverseitige SDKs, im Local Storage des Browsers fuer clientseitige SDKs oder im Geraetespeicher fuer mobile SDKs gespeichert. Weitere Details finden Sie im Artikel zur Datenspeicherung.
  • 3. Externe Daten fuer Targeting-Zwecke hinzufuegen: Externe Daten, wie Benutzerpraeferenzen oder CRM-Daten, koennen mit der Data API (einer REST-API) ueber den POST-Endpoint gespeichert werden. Diese Daten werden dann im SDK mit der Methode getRemoteData() abgerufen.

​
3. Variationszuweisung und Tracking

In den Kameleoon-SDKs ruft die Methode getVariation() (isFeatureFlagActive() / getVariations()) die Konfiguration eines Feature-Experiments ab, das mehrere Variationen enthaelt. Sie kann verwendet werden, um den/die einem bestimmten Benutzer zugewiesenen Variationsschluessel zu erhalten. Wenn ein Besucher alle Targeting-Bedingungen und Expositionsregeln fuer das Feature Flag erfuellt, verwendet Kameleoon eine Hash-Funktion, um den Besucher einer Variation zuzuweisen, und sendet dann ein Experiment-Event an den Tracking-Dienst. Wenn der Besucher die Bedingungen nicht erfuellt, wird ein Aktivitaets-Event gesendet, um anzuzeigen, dass der Benutzer in der Web- oder Mobilanwendung aktiv ist. Darueber hinaus kann die Methode flush() verwendet werden, um alle anderen gespeicherten Daten an den Tracking-Dienst zu senden.

​
4. Hilfreiche Dokumente

Fuer sprachspezifische Integrationen lesen Sie bitte die Artikel Web-SDK und Mobile-SDK: Web-SDKs Mobile-SDKs Zusaetzliche Ressourcen

​
FAQ

Im Allgemeinen müssen Sie die Methode flush nicht manuell aufrufen: Andere Aufrufe von SDK-Methoden senden die Daten gleich mit. Wenn Sie Daten an die Data API senden müssen, ohne das Feature Flag des Besuchers auszulösen, verwenden Sie die Methode flush.
Standardmäßig fasst das SDK mehrere Ereignisse zusammen und sendet sie für Analytics-Zwecke in einem konfigurierbaren Intervall als Tracking-Anfrage an die Kameleoon-Server. Dieser Ansatz verbessert die Effizienz und reduziert die Serverlast.Das SDK sendet eine Tracking-Anfrage:
  • Periodisch: Standardmäßig sendet das SDK alle 1.000 ms (1 Sekunde) eine Anfrage. Sie können dieses Intervall ändern, indem Sie den Wert tracking interval festlegen.
  • Auf Anforderung: Sofort, wenn Ihr Code eine Methode wie flush(instant=true) aufruft.
Konkret löst jeder der folgenden Methodenaufrufe vor Ablauf des Intervalls eine Tracking-Anfrage aus:
  • getVariation (wenn track auf true gesetzt ist).
  • getVariations (wenn track auf true gesetzt ist).
  • isFeatureFlagActive (wenn track auf true gesetzt ist).
  • trackConversion
  • flush (mit oder ohne instant=true)
Clientseitige SDKs senden standardmäßig außerdem alle 60 Sekunden eine Tracking-Anfrage, wenn keine andere Aktivität stattgefunden hat, damit die Besuchersitzung erhalten bleibt. Sie können diesen Standardwert ändern, indem Sie den Parameter activityTrackingIntervalMillisecond (oder activity_tracking_interval_millisecond) in Ihrer SDK-Konfiguration setzen.Bei serverseitigen SDKs ist das Event-Batching besonders nützlich, da jede Tracking-Anfrage die Daten mehrerer Besucher in einer einzigen Anfrage bündeln kann. Dieses Verfahren fasst die Informationen zu allen betroffenen Besuchern zusammen und sendet sie einmal pro Intervall. Dadurch verbessert sich die Effizienz, und die Serverlast sinkt.
Tracking-Anfragen unterliegen den Ratenbegrenzungen der Data API.Bei clientseitigen SDKs kann es in Umgebungen, in denen mehrere Besucher dasselbe Netzwerk nutzen (etwa in einem Büro), so aussehen, als stammten die Anfragen von derselben IP-Adresse. Das Ratenlimit kann dann überschritten werden und einen Fehler 429 - Too Many Requests verursachen.
Verschiedene SDKs können diese Methoden aufgrund sprachlicher Besonderheiten unterschiedlich benennen.
Im Folgenden finden Sie eine Liste der SDK-Methoden, die HTTP-Anfragen senden:
  • isFeatureFlagActive / getVariation / trackConversion / flush
    • Diese Methoden senden asynchrone Anfragen an die Data API, um alle Informationen über den Besucher zu speichern (einschließlich der Variationen, die der Besucher erhalten hat). Kameleoon verwendet diese Informationen, um Statistiken in app.kameleoon.com anzuzeigen.
  • getRemoteData / getRemoteVisitorData / getVisitorWarehouseAudience
    • Diese Methoden senden Anfragen an die Data API, um Informationen über den Besucher abzurufen. Im JavaScript-SDK sind sie asynchron, daher müssen Sie das Ergebnis mit await abwarten, bevor Sie es verwenden.
  • Zusätzlich sendet das SDK asynchrone Anfragen, um die Konfiguration abzurufen, die es für die interne Arbeit benötigt.
Rufen Sie isFeatureFlagActive auf, wenn Sie wissen müssen, ob das Flag aktiv ist, aber nicht, welche genaue Variation der Besucher erhalten hat. Bei Experiment rules ist es besser, getVariation aufzurufen, wenn Sie zwei oder mehr Variationen außer off haben.