Zum Hauptinhalt springen

​
Konfiguration und Bucketing von Feature Flags​

Wenn eine Feature-Flag-Konfiguration aktualisiert oder ein-/ausgeschaltet wird, koennen SDKs die aktualisierte Konfiguration ueber das Cloudflare Content Delivery Network (CDN) entweder per Polling oder Streaming abrufen. Polling ist die Standardoption, waehrend Streaming eine Premium-Option ist. Kameleoon-SDKs sind so konzipiert, dass sie einer Zero-Latency-Richtlinie entsprechen. Das bedeutet, dass das SDK keine zusaetzlichen Remote-Server-Aufrufe benoetigt, um Benutzer fuer ein Feature Flag zu aktivieren und einzubuchen. Selbst der schnellste Remote-Server-Aufruf wuerde der Anwendung mindestens 20 ms Latenz hinzufuegen, und je nach mehreren Faktoren kann diese Verzoegerung auf Hunderte von Millisekunden ansteigen oder das Laden der Webanwendung fuer den Endbenutzer sogar vollstaendig blockieren. Um diese zusaetzliche Latenz zu vermeiden, weisen Kameleoon-SDKs Besucher lokal zu Experimenten zu.
Bei clientseitigen SDKs, die auf dem Geraet des Benutzers laufen, muss die App zu Beginn der Sitzung die aktiven Feature-Flag-Konfigurationen abrufen. Dies erfordert einen Remote-Aufruf mit einem zugehoerigen Callback, was bedeutet, dass der Anwendungscode, der das SDK verwendet, keine Experimente ausfuehren oder Feature Flags anwenden kann, bevor dieser Callback abgeschlossen ist.

​
Polling (Standard)​

In diesem Modus sendet das SDK in regelmaessigen Abstaenden (standardmaessig alle 60 Minuten) eine Anfrage an das CDN, um die aktuellste Konfiguration abzurufen. Das Intervall kann in der SDK-Konfiguration mit dem Parameter refresh_interval_minute (oder refresh_interval) angepasst werden.
Bei massvoll beabstandeten Intervallen verbraucht die Aktualisierung der Konfiguration nur sehr wenig Speicher- und Netzwerkressourcen.
Fuer clientseitige Web-SDKs umfasst die Polling-Strategie eine lokale Caching-Logik:
  1. Initiales Laden: Wenn eine Webseite geoeffnet wird, versucht das SDK zunaechst, die Konfiguration aus dem Cache zu laden (sofern verfuegbar).
  2. Hintergrundaktualisierung: Wenn das refresh_interval abgelaufen ist, fuehrt das SDK eine Hintergrundanfrage aus, um die Konfiguration zu aktualisieren und den Cache zu erneuern.
  3. Cache-Gueltigkeit: Die gecachte Konfiguration gilt fuer 1,5 Stunden ab der letzten erfolgreichen Aktualisierung als gueltig. Wenn der Besucher innerhalb dieses 1,5-Stunden-Fensters eine Seite oeffnet, wird die gecachte Version verwendet. Andernfalls wird der Cache ignoriert und sofort eine neue Anfrage gestellt.
Diese Caching-Strategie sorgt fuer schnelleres Laden von Seiten und minimale Netzwerknutzung, waehrend die Konfiguration dennoch einigermassen aktuell bleibt.Angenommen, refresh_interval ist auf 15 Minuten eingestellt und ein Benutzer wird einem Feature Flag ausgesetzt. Wenn das Feature Flag 10 Minuten spaeter deaktiviert wird und derselbe Benutzer 20 Minuten spaeter zur Website zurueckkehrt:
  • Das SDK laedt zuerst die Konfiguration aus dem Cache (das Flag wird weiterhin als aktiv angezeigt).
  • Gleichzeitig fuehrt es eine Hintergrundanfrage aus, um die aktualisierte Konfiguration abzurufen und den Cache zu erneuern.
  • Dieses Design priorisiert die Leistung und gewaehrleistet schnelle Seitenladezeiten, waehrend es asynchron mit der neuesten Konfiguration synchronisiert wird.
Auch wenn es ein kurzes Zeitfenster gibt, in dem ein Benutzer eine veraltete Konfiguration sehen kann (abhaengig vom Intervall), aktualisiert das SDK sie schnell im Hintergrund. Die aktualisierte Konfiguration wird beim naechsten Oeffnen einer Seite durch den Besucher angewendet.

​
Streaming (Premium-Option)​

Der Echtzeit-Streaming-Modus ermoeglicht es dem SDK, die neue Konfiguration automatisch ohne Verzoegerung anzuwenden. Wenn Streaming aktiviert ist, wird das Kameleoon-SDK dank Server-Sent Events (SSE) in Echtzeit ueber alle Konfigurationsaenderungen benachrichtigt. Hauptvorteile:
  • Die Konfiguration sofort aktualisieren (kein Warten auf den naechsten Polling-Zyklus).
  • Verbraucht weniger Netzwerkverkehr als Polling in kurzen Intervallen. Streaming sendet keine periodischen Anfragen. Es oeffnet die Verbindung einmal und haelt sie dauerhaft offen, um bereit zu sein, Daten zu empfangen.
Verfuegbarkeit:
  • Dies ist eine Premium-Option, die ein Abonnement erfordert. Um Echtzeit-Streaming fuer ein Kameleoon-Konto zu aktivieren, wenden Sie sich an den Customer Success Manager oder senden Sie eine E-Mail an support@kameleoon.com.
  • Das PHP-SDK unterstuetzt aufgrund technischer Einschraenkungen kein Streaming. Das PHP-SDK kann derzeit nicht nicht-blockierend auf Konfigurationsaktualisierungen warten, da das PHP-SDK nicht zwischen Anfragen bestehen bleibt. Jede Anfrage erstellt eine neue SDK-Instanz, die sich selbst zerstoert, sobald sie eine Antwort erhaelt.
  • Der Echtzeit-Streaming-Modus ist derzeit nicht mit serverlosen Edge-Compute-Plattformen kompatibel.
  • Fuer andere Sprachen siehe die SDK-Kompatibilitaetsmatrix fuer die mindestens unterstuetzte Version in der bevorzugten Sprache.

​
Datenspeicherung​

Die SDKs von Kameleoon sind fuer optimale Leistung und Benutzererfahrung konzipiert. Um dies zu erreichen, verwalten sie Besucherdaten lokal, entweder auf dem Server oder direkt auf dem Geraet, anstatt sie aus einer Remote-Quelle abzurufen. Alle fuer Kameleoon-Experimente und Feature Flags relevanten Besucherdaten werden lokal gespeichert, einschliesslich Experimentzuweisungen, Segmentdaten und aller Custom Data, die mit Methoden wie addData() hinzugefuegt oder mit getRemoteVisitorData() vom Server abgerufen wurden. Die Art und Weise, wie diese Daten gespeichert werden, und ihre Lebensdauer unterscheiden sich je nachdem, ob ein serverseitiges oder clientseitiges SDK verwendet wird.

​
Serverseitige SDKs​

Bei serverseitigen SDKs werden Besucherdaten im fluechtigen Speicher des Servers (RAM) gespeichert, was schnellen Zugriff fuer Experiment- und Feature-Flag-Auswertungen ermoeglicht. Die Daten sind als Map organisiert und verwenden eindeutige visitorCode-Werte als Schluessel.
  • Sitzungsbasierte Speicherung: Daten werden nur fuer die Dauer der aktiven Sitzung eines Benutzers im Speicher gehalten, die standardmaessig nach 30 Minuten Inaktivitaet endet (keine Seitenaufrufe, Klicks usw.). Alle waehrend der Sitzung gesammelten Daten laufen gleichzeitig ab.
    • Parameter session_duration: Die Sitzungsdauer kann mit dem Parameter session_duration in der SDK-Konfiguration angepasst werden. Mit diesem Parameter kann die Kameleoon-Sitzung an die serverseitige Verwaltung der Anwendung angepasst werden.
Eine Erhoehung von session_duration erfordert, dass das SDK mehr RAM zuteilt, um die erhoehten Besucherdaten zu speichern.
  • Datenverlust bei Server-Neustart: Da die Daten im RAM gespeichert werden, gehen sie verloren, wenn der Anwendungsserver neu gestartet wird. In der Regel ist Datenverlust kein Problem, da wichtige Besucherdaten (wie Benutzer-IDs oder Attribute) normalerweise aus einer persistenten Datenbank abgerufen und dem Besucher bei einer neuen Anfrage erneut zugewiesen werden.
  • Daten frueherer Besuche abrufen: Die Methode getRemoteVisitorData() ermoeglicht es Ihnen, Custom Data abzurufen, die waehrend eines frueheren Besuchs eines Besuchers gesammelt wurden. Diese Methode ordnet automatisch den neuesten Dateneintrag fuer einen Besucher zu, sodass addData() nicht erneut aufgerufen werden muss.

​
Clientseitige SDKs​

Im Gegensatz zu serverseitigen SDKs nutzen clientseitige SDKs persistenten lokalen Speicher auf dem Geraet des Benutzers. Dieser Mechanismus stellt sicher, dass Besucherdaten ueber Browsersitzungen, App-Neustarts und sogar Geraete-Neustarts hinweg erhalten bleiben. Der spezifische Speichermechanismus variiert je nach Plattform:
  • iOS: UserDefaults
  • Android: SharedPreferences
  • JavaScript/TypeScript: LocalStorage
    • Hinweis fuer JS-SDK: Der kameleoonVisitorCode wird auch ueber Cookies geteilt, um nahtlose Datenkontinuitaet und Kommunikation mit der Kameleoon-Anwendungsdatei (engine.js) sicherzustellen.
  • React Native: MMKV Storage
Im Gegensatz zu serverseitigen SDKs, die eine globale session_duration verwenden, arbeiten clientseitige SDKs nicht mit einem sitzungsbasierten Ablauf fuer alle Daten. Stattdessen verwenden sie entweder targetingDataCleanupInterval oder data_expiration_interval_minute, um zu steuern, wie lange einzelne Datenelemente gespeichert werden.
  • targetingDataCleanupInterval/data_expiration_interval_minute: Diese Parameter bestimmen die individuelle Lebensdauer jedes spezifischen Dateneintrags. Standardmaessig werden Daten unbegrenzt gespeichert (bis sie explizit geloescht werden), um konsistente Benutzererfahrungen ueber Besuche hinweg zu gewaehrleisten. Sie koennen diesen Parameter auf eine bestimmte Anzahl von Minuten setzen, wenn einzelne Datenpunkte nach einer bestimmten Zeit ablaufen sollen.
  • Datenpersistenz: Dieser grundlegende Unterschied bedeutet, dass die Daten auch dann erhalten bleiben, wenn der Benutzer den Browser-Tab schliesst, von der Site weg navigiert oder die mobile Anwendung schliesst.
  • Begruendung der Namenskonvention: Der Unterschied in der Parameter-Terminologie (session_duration vs. data_expiration_interval_minute) spiegelt direkt die zugrunde liegende Speicherphilosophie wider. session_duration regelt die Gesamtlebensdauer aller Daten innerhalb einer serverseitigen Sitzung. data_expiration_interval_minute ermoeglicht eine granulare Kontrolle ueber die Lebensdauer jedes spezifischen Datenelements, das persistent auf dem Client gespeichert wird.

​
Domainliste​

Die Kameleoon-SDKs benoetigen Zugriff auf eine Reihe von URIs, die spezifische Dienste fuer das SDK bereitstellen. Wenn Sie den Zugriff einschraenken und Domains explizit auf die Whitelist setzen muessen, stellen Sie sicher, dass unsere SDKs die folgenden Domains erreichen koennen:
URLVerwendet von
https://sdk-config.kameleoon.eu/<sitecode>Konfigurationsdatei
https://<sitecode>.kameleoon.io/sdk-config / https://client-config.kameleoon.com/mobileKonfigurationsdatei (veraltet)
https://events.kameleoon.com:8110/sseEchtzeit-Streaming
https://api.kameleoon.com/oauth/tokenAuthentifizierung
https://eu-data.kameleoon.io/ https://na-data.kameleoon.ioTracking
Die Domain fuer Ihre Kameleoon-Skripte kann von Projekt zu Projekt variieren. Ihre Projekte koennen je nach Erstellungsdatum entweder auf kameleoon.eu oder kameleoon.io gehostet sein. Stellen Sie sicher, dass Sie die in Ihrem Projekt in der Kameleoon-App angezeigte Domain verwenden.