Skip to main content

​
Konfiguration und Bucketing von Feature Flags

Wenn eine Feature-Flag-Konfiguration aktualisiert oder ein-/ausgeschaltet wird, können SDKs die aktualisierte Konfiguration über das Cloudflare Content Delivery Network (CDN) entweder per Polling oder Streaming abrufen. Polling ist die Standardoption, während Streaming eine Premium-Option ist. Kameleoon-SDKs sind so konzipiert, dass sie einer Zero-Latency-Richtlinie entsprechen. Das bedeutet, dass das SDK keine zusätzlichen Remote-Server-Aufrufe benötigt, um Benutzer für ein Feature Flag zu aktivieren und einzubuchen. Selbst der schnellste Remote-Server-Aufruf würde der Anwendung mindestens 20 ms Latenz hinzufügen, und je nach mehreren Faktoren kann diese Verzögerung auf Hunderte von Millisekunden ansteigen oder das Laden der Webanwendung für den Endbenutzer sogar vollständig blockieren. Um diese zusätzliche Latenz zu vermeiden, weisen Kameleoon-SDKs Besucher lokal zu Experimenten zu.
Bei clientseitigen SDKs, die auf dem Gerät des Benutzers laufen, muss die App zu Beginn der Sitzung die aktiven Feature-Flag-Konfigurationen abrufen. Dies erfordert einen Remote-Aufruf mit einem zugehörigen Callback, was bedeutet, dass der Anwendungscode, der das SDK verwendet, keine Experimente ausführen oder Feature Flags anwenden kann, bevor dieser Callback abgeschlossen ist.

​
Polling (Standard)

In diesem Modus sendet das SDK in regelmäßigen Abständen (standardmäßig 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 maßvoll beabstandeten Intervallen verbraucht die Aktualisierung der Konfiguration nur sehr wenig Speicher- und Netzwerkressourcen.
Für clientseitige Web-SDKs umfasst die Polling-Strategie eine lokale Caching-Logik:
  1. Initiales Laden: Wenn eine Webseite geöffnet wird, versucht das SDK zunächst, die Konfiguration aus dem Cache zu laden (sofern verfügbar).
  2. Hintergrundaktualisierung: Wenn das refresh_interval abgelaufen ist, führt das SDK eine Hintergrundanfrage aus, um die Konfiguration zu aktualisieren und den Cache zu erneuern.
  3. Cache-Gültigkeit: Die gecachte Konfiguration gilt für 1,5 Stunden ab der letzten erfolgreichen Aktualisierung als gültig. Wenn der Besucher innerhalb dieses 1,5-Stunden-Fensters eine Seite öffnet, wird die gecachte Version verwendet. Andernfalls wird der Cache ignoriert und sofort eine neue Anfrage gestellt.
Diese Caching-Strategie sorgt für schnelleres Laden von Seiten und minimale Netzwerknutzung, während 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 später deaktiviert wird und derselbe Benutzer 20 Minuten später zur Website zurückkehrt:
  • Das SDK lädt zuerst die Konfiguration aus dem Cache (das Flag wird weiterhin als aktiv angezeigt).
  • Gleichzeitig führt es eine Hintergrundanfrage aus, um die aktualisierte Konfiguration abzurufen und den Cache zu erneuern.
  • Dieses Design priorisiert die Leistung und gewährleistet schnelle Seitenladezeiten, während es asynchron mit der neuesten Konfiguration synchronisiert wird.
Auch wenn es ein kurzes Zeitfenster gibt, in dem ein Benutzer eine veraltete Konfiguration sehen kann (abhängig vom Intervall), aktualisiert das SDK sie schnell im Hintergrund. Die aktualisierte Konfiguration wird beim nächsten Öffnen 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 ermöglicht es dem SDK, die neue Konfiguration automatisch ohne Verzögerung anzuwenden. Wenn Streaming aktiviert ist, wird das Kameleoon-SDK dank Server-Sent Events (SSE) in Echtzeit über alle Konfigurationsänderungen benachrichtigt. Hauptvorteile:
  • Die Konfiguration sofort aktualisieren (kein Warten auf den nächsten Polling-Zyklus).
  • Verbraucht weniger Netzwerkverkehr als Polling in kurzen Intervallen. Streaming sendet keine periodischen Anfragen. Es öffnet die Verbindung einmal und hält sie dauerhaft offen, um bereit zu sein, Daten zu empfangen.
Verfügbarkeit:
  • Dies ist eine Premium-Option, die ein Abonnement erfordert. Um Echtzeit-Streaming für 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 unterstützt aufgrund technischer Einschränkungen 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 zerstört, sobald sie eine Antwort erhält.
  • Der Echtzeit-Streaming-Modus ist derzeit nicht mit serverlosen Edge-Compute-Plattformen kompatibel.
  • Für andere Sprachen siehe die SDK-Kompatibilitätsmatrix für die mindestens unterstützte Version in der bevorzugten Sprache.

​
Datenspeicherung

Die SDKs von Kameleoon sind für optimale Leistung und Benutzererfahrung konzipiert. Um dies zu erreichen, verwalten sie Besucherdaten lokal, entweder auf dem Server oder direkt auf dem Gerät, anstatt sie aus einer Remote-Quelle abzurufen. Alle für Kameleoon-Experimente und Feature Flags relevanten Besucherdaten werden lokal gespeichert, einschließlich Experimentzuweisungen, Segmentdaten und aller Custom Data, die mit Methoden wie addData() hinzugefügt 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 flüchtigen Speicher des Servers (RAM) gespeichert, was schnellen Zugriff für Experiment- und Feature-Flag-Auswertungen ermöglicht. Die Daten sind als Map organisiert und verwenden eindeutige visitorCode-Werte als Schlüssel.
  • Sitzungsbasierte Speicherung: Daten werden nur für die Dauer der aktiven Sitzung eines Benutzers im Speicher gehalten, die standardmäßig nach 30 Minuten Inaktivität endet (keine Seitenaufrufe, Klicks usw.). Alle während 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 Erhöhung von session_duration erfordert, dass das SDK mehr RAM zuteilt, um die erhöhten 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 früherer Besuche abrufen: Die Methode getRemoteVisitorData() ermöglicht es Ihnen, Custom Data abzurufen, die während eines früheren Besuchs eines Besuchers gesammelt wurden. Diese Methode ordnet automatisch den neuesten Dateneintrag für 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 Gerät des Benutzers. Dieser Mechanismus stellt sicher, dass Besucherdaten über Browsersitzungen, App-Neustarts und sogar Geräte-Neustarts hinweg erhalten bleiben. Der spezifische Speichermechanismus variiert je nach Plattform:
  • iOS: UserDefaults
  • Android: SharedPreferences
  • JavaScript/TypeScript: LocalStorage
    • Hinweis für JS-SDK: Der kameleoonVisitorCode wird auch über Cookies geteilt, um nahtlose Datenkontinuität 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 für 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. Standardmäßig werden Daten unbegrenzt gespeichert (bis sie explizit gelöscht werden), um konsistente Benutzererfahrungen über Besuche hinweg zu gewährleisten. Sie können 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 schließt, von der Site weg navigiert oder die mobile Anwendung schließt.
  • Begründung 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 ermöglicht eine granulare Kontrolle über 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 benötigen Zugriff auf eine Reihe von URIs, die spezifische Dienste für das SDK bereitstellen. Wenn Sie den Zugriff einschränken und Domains explizit auf die Whitelist setzen müssen, stellen Sie sicher, dass unsere SDKs die folgenden Domains erreichen können: Informationen zum Zulassen dieser Domains in einem Content-Security-Policy-Header finden Sie unter Kameleoon-Domains, die Sie zulassen müssen. Dort sind alle Domains aufgeführt, die Kameleoon-Produkte verwenden.
Die Domain für Ihre Kameleoon-Skripte kann von Projekt zu Projekt variieren. Ihre Projekte können 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.

​
FAQ

Kameleoon verwendet während der Initialisierung CDN-Server. Sobald das SDK die Konfiguration empfangen und zwischengespeichert hat, erfolgen Abruf und Aktualisierungen schnell, typischerweise in 50-70 ms, je nach Latenz des Servers zum nächstgelegenen CDN.
Es gibt zwei Methoden, um die Konfiguration abzurufen: Polling und Streaming.
Die Streaming-Methode verwendet das Protokoll server-sent events (SSE oder EventSource).
Kameleoon bereinigt das CDN jedes Mal, wenn Sie eine Feature-Flag-Konfiguration aktualisieren (z. B. Variationen, Traffic-Expositionen und Targeting), oder alle 24 Stunden.
Jede Serverinstanz speichert die von ihr erfassten Besucherdaten in ihrem eigenen Speicher. Leiten Sie Anfragen desselben Besuchers an dieselbe Serverinstanz weiter. Andernfalls fügen Sie die vollständigen Besucherdaten vor jeder Tracking-Anfrage mit addData() hinzu oder laden Sie sie mit der Methode getRemoteVisitorData.Wenn unterschiedliche Serverinstanzen gleichzeitig unterschiedliche SDK-Konfigurationen anwenden, verwenden Sie die Option Streaming, damit jede Instanz Konfigurationsänderungen in Echtzeit erhält.
Alle Auswertungen erfolgen lokal, um Latenz zu vermeiden. Tracking-Anfragen werden anschließend asynchron an die Data-API-Server von Kameleoon gesendet.
Um einen Besucher einer Experiment-Variation zuzuweisen, erstellt Kameleoon zunächst einen Bezeichner aus dem Visitor-Code, der Experiment-ID und gegebenenfalls einem zusätzlichen Element im Fall eines Respoolings. Anschließend berechnet eine synchrone Implementierung der Hash-Funktion SHA-256 einen Hash dieses Bezeichners. Die aus dem Hash gewonnene Ganzzahl wird dann einer Gleitkommazahl zwischen null und eins zugeordnet, um die Experiment-Variation festzulegen. Die Funktion SHA-256 ist deterministisch. Daher erhält derselbe Besucher (mit demselben Visitor-Code) für ein Experiment immer dieselbe Variation, sofern Sie nicht ausdrücklich eine Neuberechnung der Zuweisung anfordern.
Der Artikel Add a new rollout rule erläutert alle möglichen Fälle.
Serverseitige SDKs speichern Besucherdaten während der gesamten Besuchersitzung im Arbeitsspeicher. Standardmäßig beträgt die Dauer der Sitzung 30 Minuten. Clientseitige SDKs speichern die Daten im lokalen Speicher des Geräts, in dem sie bleiben, bis Sie sie löschen oder bis ein konfiguriertes Ablaufintervall verstrichen ist. Details finden Sie unter Datenspeicherung.