Skip to main content

​
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.

​
Auswirkung auf neu gestartete Experimente und Feature Flags

dataFileCacheTtl und dataFileRefreshInterval bestimmen gemeinsam, wie schnell Besucher anhand der Konfiguration eines neu gestarteten Experiments oder Feature Flags ausgewertet werden. Besucher, deren zwischengespeicherte Datendatei bereits älter als dataFileCacheTtl ist, oder die noch keine haben, erhalten die neue Konfiguration sofort, weil initialize() wartet, bis eine aktuelle Datendatei eintrifft. Besucher, deren zwischengespeicherte Datendatei noch innerhalb von dataFileCacheTtl liegt, werden weiterhin anhand der vorherigen Konfiguration ausgewertet, bis dieser Cache älter als dataFileCacheTtl wird oder bis eine Hintergrundaktualisierung abgeschlossen ist und sie eine weitere Seite laden. Dadurch steigt mit dem Standardwert von dataFileCacheTtl von 90 Minuten der Traffic in ein neu gestartetes Experiment schrittweise an, statt sofort das volle Volumen zu erreichen. Ein neu gestartetes Experiment könnte beispielsweise in der ersten Stunde nach dem Start etwa 40% seiner endgültigen Zielgruppe erreichen, in der zweiten Stunde etwa 57% und in der dritten Stunde mehr als 95%, sobald genügend zwischengespeicherte Datendateien der Besucher dieses 90-Minuten-Fenster durchlaufen haben. Kein Besucher wird dauerhaft vom Experiment ausgeschlossen; jeder tritt bei, sobald sein Gerät die aktualisierte Konfiguration abruft.
Wenn Sie die Kameleoon-Expositionszahlen direkt nach dem Start einer Kampagne mit einem anderen Analysetool vergleichen, rechnen Sie mit einer Hochlaufphase von etwa dataFileCacheTtl Minuten (standardmäßig 90), bevor sich die Expositionszahlen stabilisieren und der Zielgruppe entsprechen. Eine niedrigere Anzahl exponierter Besucher während dieses Zeitraums bedeutet nicht, dass Besucher verloren gehen oder falsch zugeordnet werden. Wenn Ihr Anwendungsfall einen schnelleren Start erfordert, verringern Sie dataFileCacheTtl (halten Sie ihn höher als dataFileRefreshInterval, um unnötige blockierende Anfragen beim Seitenaufbau zu vermeiden), oder besprechen Sie den Streaming-Modus mit dem Kameleoon-Support, der dieses Cache-Modell für die SDK-Datendatei vollständig umgeht.
Eine Konfiguration, die ein serverseitiges oder Edge-SDK mit getEngineTrackingCode() und dem Tracking-Skript Engine.js kombiniert, kann in den getrackten Ergebnissen dennoch einen ähnlichen Hochlauf zeigen, verursacht durch den separaten Browser-Cache von Engine.js selbst. Weitere Details finden Sie unter Caching-Verhalten von Engine.js.

​
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.

​
Edge-SDKs

Edge-SDKs, die über Serverless Edge Compute Starter Kits bereitgestellt werden, behalten Besucherdaten nicht auf die gleiche Weise zwischen Anfragen bei wie serverseitige oder clientseitige SDKs. Eine Edge-Plattform kann eine Worker-Instanz jederzeit zerstören und neu erstellen, sodass eine session_duration-Einstellung keinen dauerhaften Speicher hat, auf den sie angewendet werden könnte, und ein Edge Worker keine Garantie hat, eine spätere Anfrage desselben Besuchers zu sehen. Aus diesem Grund ist Ihre Integration dafür verantwortlich, Besucherdaten bei jeder Anfrage für den Edge Worker verfügbar zu machen, typischerweise durch Übergabe als Cookie und den Aufruf von addData(), bevor ein Feature Flag oder Experiment ausgewertet wird. Siehe Targeting-Einschränkungen am Edge für die vollständige Erklärung und ein Codebeispiel.

​
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:
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.