0.8.5. Versionshinweise finden Sie im Changelog des C++ SDK oder im SDK-Changelog-Index für alle SDKs.
SDK-Methoden: Die vollständige Referenzdokumentation des C++ SDK finden Sie im Abschnitt Referenz.
Entwicklerhandbuch
Dieses Handbuch soll Ihnen helfen, das C++ SDK schnell zu integrieren und mit der Auswertung von Feature Flags in Ihrer C++-Anwendung zu beginnen.Erste Schritte
Den C++-Client installieren
Das C++ SDK ist eine C++17-Bibliothek, die auf dem Kameleoon SDK Core aufbaut, einer nativen Shared Library (libkameleoon_ffi), die in Rust geschrieben ist und das SDK-Verhalten implementiert. Ihre Anwendung linkt die C++-Bibliothek statisch und lädt die Core-Bibliothek zur Laufzeit.
Anforderungen:
- Ein C++17-Compiler (GCC, Clang oder MSVC) und CMake 3.16 oder höher.
- Rust 1.91 oder höher, Cargo und
cbindgen, um die SDK-Core-Bibliothek zu bauen (libkameleoon_ffi.sounter Linux,libkameleoon_ffi.dylibunter macOS,kameleoon_ffi.dllmit ihrer Importbibliothekkameleoon_ffi.dll.libunter Windows).
cpp/client mit add_subdirectory() hinzu und linken Sie das Target Kameleoon::CppClient. Verweisen Sie KAMELEOON_FFI_LIBRARY auf die von Ihnen gebaute Core-Bibliothek; der C-Header wird mit cbindgen generiert, oder Sie können einen vorhandenen mit KAMELEOON_FFI_HEADER übergeben:
CMakeLists.txt
libkameleoon_ffiwird zur Laufzeit geladen: Installieren Sie die Bibliothek an einem Standard-Bibliotheksspeicherort oder liefern Sie sie neben Ihrer ausführbaren Datei aus. Unter Linux und macOS erfordert das Ausliefern neben der ausführbaren Datei einen RPATH von$ORIGINoder@loader_path(zum Beispielset_target_properties(my_app PROPERTIES INSTALL_RPATH "$ORIGIN")). Unter Windows kopieren Siekameleoon_ffi.dllneben Ihre Binärdateien.- Wenn Sie einen Client erstellen, prüft das SDK, ob die geladene
libkameleoon_ffimit der Version übereinstimmt, gegen die es gebaut wurde, und wirft andernfalls eineKameleoonExceptionmitErrorCode::Internal. Aktualisieren Sie die C++-Bibliothek und die Core-Bibliothek immer gemeinsam. - Alle öffentlichen SDK-Typen befinden sich im Namespace
kameleoon. Inkludieren Siekameleoon/kameleoon.hpp, um die gesamte öffentliche API zu erhalten.
Zusätzliche Konfiguration
Erstellen Sie eine JSON-Konfigurationsdatei (zum Beispielclient-cpp.json), um Anmeldedaten bereitzustellen und das SDK-Verhalten anzupassen. Sie können auch eine Beispielkonfigurationsdatei herunterladen.
Das C++ SDK kann entweder mit einer JSON-Datei konfiguriert werden, deren Pfad Sie an KameleoonClientFactory::create() übergeben, oder indem Sie eine KameleoonClientConfig-Struktur direkt im Code befüllen.
Die folgende Tabelle zeigt die verfügbaren Eigenschaften, die Sie festlegen können:
Den Kameleoon-Client initialisieren
Nachdem Sie das SDK installiert und Ihre Anmeldedaten konfiguriert haben, erstellen Sie einenKameleoonClient mithilfe der KameleoonClientFactory.
- Config File
- Code
Die Beispiele auf dieser Seite verwenden C++20 Designated Initializers (
GetVariationOptions{.track = false}), um die Konfigurations-, Options- und Datenstrukturen des SDK zu befüllen. Mit einem C++17-Compiler deklarieren Sie stattdessen die Struktur und setzen ihre Felder einzeln.KameleoonClient ist das Hauptobjekt, das zum Auswerten von Feature Flags, zum Hinzufügen von Besucherdaten und zum Senden von Tracking-Anfragen verwendet wird.
Einen Feature Flag aktivieren
Einem Benutzer eine eindeutige ID zuweisen
Um einem Benutzer eine eindeutige ID zuzuweisen, können Sie die Methodeget_visitor_code() verwenden. Wenn ein Besuchercode nicht existiert (aus dem Cookie der Request-Header), generiert die Methode eine zufällige eindeutige ID oder verwendet einen default_visitor_code, den Sie selbst generiert haben. Die ID wird dann in einem Cookie der Response-Header gesetzt.
Wenn Sie Kameleoon im Hybridmodus verwenden, stellt der Aufruf der Methode get_visitor_code() sicher, dass die eindeutige ID (Besuchercode) zwischen der Anwendungsdatei engine.js (zuvor kameleoon.js genannt) und dem SDK geteilt wird.
Eine Flag-Konfiguration abrufen
Um einen Feature Flag in Ihrem Code zu implementieren, müssen Sie den Feature Flag zunächst in Ihrem Kameleoon-Konto erstellen. Um den Status oder die Variation eines Feature Flags für einen bestimmten Benutzer zu ermitteln, sollten Sie die Methodeget_variation() oder is_feature_active() verwenden, um die Konfiguration basierend auf dem feature_key abzurufen.
Die Methode get_variation() verarbeitet sowohl einfache Feature Flags mit ON/OFF-Zuständen als auch komplexere Flags mit mehreren Variationen. Die Methode ruft die entsprechende Variation für den Benutzer ab, indem sie die Feature-Regeln überprüft, die Variation zuweist und sie basierend auf dem feature_key und dem visitor_code zurückgibt.
Die Methode is_feature_active() kann verwendet werden, wenn Sie die Konfiguration eines einfachen Feature Flags abrufen möchten, der nur einen ON- oder OFF-Zustand hat, im Gegensatz zu komplexeren Feature Flags mit mehreren Variationen oder Targeting-Optionen.
Wenn Ihr Feature Flag zugehörige Variablen hat (wie spezifische Verhaltensweisen, die mit jeder Variation verbunden sind), ermöglicht Ihnen get_variation() auch den Zugriff auf das Variation-Objekt, das Details zur zugewiesenen Variation und ihrem zugehörigen Experiment bereitstellt. Diese Methode prüft, ob der Feature Flag den Benutzer anspricht, findet die dem Besucher zugewiesene Variation und speichert sie. Wenn track=true, sendet das SDK das Expositions-Event bei der nächsten Tracking-Anfrage an das angegebene Experiment, das automatisch basierend auf dem tracking_interval_millis des SDK ausgelöst wird. Standardmäßig ist dieses Intervall auf 1000 Millisekunden (1 Sekunde) eingestellt.
Mit der Methode get_variation() können Sie steuern, ob das SDK den Besucher verfolgt. Wenn track=false, werden vom SDK keine Expositions-Events gesendet. Dies ist nützlich, wenn Sie es vorziehen, Daten nicht über das SDK zu verfolgen und sich stattdessen auf clientseitiges Tracking zu verlassen, das z. B. von der Kameleoon-Engine verwaltet wird. Darüber hinaus ist die Einstellung track=false hilfreich bei der Verwendung der Methode get_variations(), bei der Sie möglicherweise nur die Variationen für alle Flags benötigen, ohne Tracking-Events auszulösen. Wenn Sie mehr darüber erfahren möchten, wie Tracking funktioniert, lesen Sie diesen Artikel
Datenpunkte hinzufügen, um einen Benutzer anzusprechen oder Besuche in Berichten zu filtern / aufzuschlüsseln
Um einen Benutzer anzusprechen, stellen Sie sicher, dass Sie relevante Datenpunkte zu seinem Profil hinzugefügt haben, bevor Sie die Feature-Variation abrufen oder prüfen, ob der Flag aktiv ist. Verwenden Sie die Methodeadd_data(), um diese Datenpunkte zum Profil des Benutzers hinzuzufügen.
Um Datenpunkte abzurufen, die auf anderen Geräten gesammelt wurden, oder um auf vergangene Benutzerdaten zuzugreifen (clientseitig gesammelt bei Verwendung von Kameleoon im Hybridmodus), verwenden Sie die Methode get_remote_visitor_data(). Diese Methode ruft Daten asynchron von den Servern ab. Es ist wichtig, get_remote_visitor_data() vor dem Abrufen der Variation oder der Überprüfung, ob der Feature Flag aktiv ist, aufzurufen, da das SDK diese Daten benötigen könnte, um einen Benutzer einer bestimmten Variation zuzuweisen.
Um mehr über die verfügbaren Targeting-Bedingungen zu erfahren, lesen Sie den ausführlichen Artikel zu diesem Thema.
Darüber hinaus sind die Datenpunkte, die Sie zum Besucherprofil hinzufügen, bei der Analyse Ihrer Experimente verfügbar, sodass Sie Ihre Ergebnisse nach Faktoren wie Gerät und Browser filtern und aufschlüsseln können. Der Kameleoon-Hybridmodus sammelt automatisch eine Vielzahl von Datenpunkten auf der Clientseite, was die Aufschlüsselung Ihrer Ergebnisse anhand dieser vorgesammelten Datenpunkte erleichtert. Die vollständige Liste finden Sie hier.
Wenn Sie zusätzliche Datenpunkte über das hinaus erfassen müssen, was automatisch gesammelt wird, können Sie die Custom Data-Funktion von Kameleoon verwenden. Mit Custom Data können Sie spezifische Informationen erfassen und analysieren, die für Ihre Experimente relevant sind. Vergessen Sie nicht, die Methode flush() aufzurufen, um die gesammelten Daten zur Analyse an die Kameleoon-Server zu senden.
Um die Genauigkeit Ihrer Ergebnisse sicherzustellen, wird empfohlen, Bots mithilfe des Datentyps
UserAgent herauszufiltern.Ziel-Conversions verfolgen
Wenn ein Benutzer eine gewünschte Aktion (z. B. einen Kauf) ausführt, wird dies als Conversion erfasst. Um Conversions zu verfolgen, verwenden Sie die Methodetrack_conversion() und geben Sie die erforderlichen Parameter visitor_code und goal_id an.
Das SDK sendet die Anfrage zur Conversion-Verfolgung zusammen mit der nächsten geplanten Tracking-Anfrage, die in regelmäßigen Intervallen (definiert durch tracking_interval_millis) erfolgt. Wenn Sie die Anfrage sofort senden möchten, verwenden Sie die Methode flush_instant().
Events an Analyselösungen senden
Um Conversions zu verfolgen und Expositions-Events an Ihre Kundenanalyselösung zu senden, müssen Sie Kameleoon zunächst im Hybridmodus implementieren. Verwenden Sie dann die Methodeget_engine_tracking_code().
Die Methode get_engine_tracking_code() ruft den eindeutigen Tracking-Code ab, der zum Senden von Expositions-Events an Ihre Analyselösung erforderlich ist. Mit dieser Methode können Sie Events aufzeichnen und an die gewünschte Analyseplattform senden.
Fehlerbehandlung
Jeder vom SDK ausgelöste Fehler ist eineKameleoonException, sodass ein einziger Handler für diesen Typ jeden SDK-Fehler abfängt. Behandeln Sie einen spezifischen Fehlertyp, wenn Ihre Anwendung auf einen bestimmten Fehler reagieren muss, zum Beispiel um auf Ihr Standardverhalten zurückzufallen, wenn ein Feature Flag nicht in der Konfiguration enthalten oder das SDK noch nicht initialisiert ist. Der Referenzabschnitt jeder Methode listet die Fehler auf, die sie auslösen kann.
KameleoonException ist von std::runtime_error abgeleitet. Rufen Sie code() auf, um den ErrorCode zu erhalten, der die Fehler unterscheidet, und what(), um die Meldung zu erhalten.
An das SDK übergebene Zeichenketten müssen gültiges UTF-8 sein. Callbacks, die Sie dem SDK bereitstellen (
CookieAccessor-Overrides, Event-Handler und Logger), dürfen keine Ausnahmen werfen: Jede Ausnahme, die ihnen entkommt, wird an der SDK-Grenze abgefangen und verworfen.SDK-Fehler sind erwartetes Verhalten, keine Abstürze: Ein noch nicht aktivierter Feature Flag, ein SDK, das seine Konfiguration noch lädt, oder ein Netzwerkfehler sind alles normale Zustände. Wenn die Feature-Auswertung fehlschlägt, protokollieren Sie den Fehler und greifen Sie auf Ihr Standardverhalten zurück, damit der Besucher weiterhin ein funktionierendes Erlebnis erhält.
Asynchrone Operationen
Die netzwerkgebundenen Operationen (initialize(), flush_instant(), get_remote_data(), get_remote_visitor_data() und get_visitor_warehouse_audience()) laufen auf dem eigenen Worker-Thread des SDK. Jede gibt es in drei Formen, sodass Sie die wählen können, die zum aufrufenden Thread passt:
Completion<void> (std::function<void(std::exception_ptr)>) oder eine Completion<T> (std::function<void(std::exception_ptr, T)>) für Operationen, die einen Wert zurückgeben. Das SDK ruft sie genau einmal auf. Sie können die Completion weglassen, um die Operation im Fire-and-forget-Modus auszuführen: Fehler erscheinen dann nur im SDK-Protokoll.
C++20 hat keinen eingebauten Coroutine-Task-Typ, daher funktioniert
co_await nur innerhalb einer Coroutine, deren Promise-Typ das Awaitable<T> des SDK akzeptiert (KAMELEOON_HAS_COROUTINES wird von kameleoon/async.hpp definiert, wenn Coroutinen verfügbar sind). Standardmäßig wird die Coroutine auf dem SDK-Worker-Thread fortgesetzt; rufen Sie .via(executor) auf dem Awaitable auf, um stattdessen auf Ihrer eigenen Ereignisschleife fortzufahren. Frameworks mit eigenen Coroutine-Typen, wie Boost.Asio, benötigen einen kleinen Adapter um die Completion-Form; siehe das mit dem SDK ausgelieferte Server-Beispiel.get_visitor_code(), get_variation(), get_variations(), is_feature_active(), add_data(), track_conversion() und flush()) sind synchrone In-Memory-Aufrufe und benötigen nichts davon.
Verwenden eines benutzerdefinierten Bucketing-Schlüssels
Standardmäßig verwendet Kameleoon eine eindeutige, anonyme Besucher-ID (visitor_code), um Benutzer Feature-Flag-Variationen zuzuweisen. Diese ID wird in der Regel auf dem Gerät des Benutzers generiert und gespeichert (in einem Browser-Cookie für client- und serverseitige SDKs und im persistenten Speicher für mobile SDKs). In bestimmten Szenarien müssen Sie jedoch möglicherweise sicherstellen, dass alle Benutzer derselben Organisation dieselbe Variante eines Feature Flags sehen.
Die Option Custom Bucketing Key ermöglicht es Ihnen, dieses Standardverhalten zu überschreiben, indem Sie Ihren eigenen benutzerdefinierten Bezeichner für das Bucketing bereitstellen. Diese Überschreibung stellt sicher, dass die Zuweisungslogik von Kameleoon Ihren angegebenen Schlüssel anstelle des Standard-visitor_code verwendet.
Anwendungsfälle
Die Verwendung eines benutzerdefinierten Bucketing-Schlüssels ist unerlässlich, um Konsistenz und Genauigkeit bei Ihren Feature-Flag-Zuweisungen aufrechtzuerhalten, insbesondere in diesen Situationen:- Experimente auf Konto- oder Organisationsebene: Für B2B-Produkte oder Szenarien, in denen Sie alle Benutzer derselben Organisation derselben Variation zuweisen möchten, können Sie einen Bezeichner wie eine
account_idverwenden. Benutzerdefinierte Bucketing-Schlüssel sind entscheidend für A/B-Tests von Funktionen, die ein ganzes Team oder Unternehmen betreffen.
Technische Details
Wenn Sie einen benutzerdefinierten Bucketing-Schlüssel für einen Feature Flag konfigurieren, stellen Sie Kameleoon einen bestimmten Bezeichner aus den Daten Ihrer Anwendung zur Verfügung:- Bereitstellung des benutzerdefinierten Schlüssels: Sie stellen Ihren benutzerdefinierten Bezeichner dem Kameleoon SDK über die Methode
add_data()zur Verfügung. In dieser Methode übergeben Sie Ihren gewählten benutzerdefinierten Bucketing-Schlüssel alsCustomData-Objekt. Hier bezieht sichnew_visitor_codeauf den Bezeichner, den Sie für Ihr Bucketing verwenden möchten (zum Beispiel die neueuser_idoderaccount_id).
- Bucketing-Logik: Sobald Sie einen benutzerdefinierten Bucketing-Schlüssel über die Methode
add_data()bereitstellen, verwenden alle Hash-Berechnungen zur Zuweisung von Benutzern zu Variationen diesennew_visitor_code(Ihren benutzerdefinierten Schlüssel) anstelle des Standard-visitor_code. Die Verwendung desnew_visitor_codebedeutet, dass die Bucketing-Entscheidung von Ihrem benutzerdefinierten Bezeichner abhängt, was konsistente Zuweisungen in verschiedenen Kontexten gewährleistet, in denen dieser Bezeichner vorhanden ist. - Datentracking und Analysen: Es ist wichtig zu beachten, dass, während der
new_visitor_code(Ihr benutzerdefinierter Schlüssel) für Bucketing-Entscheidungen verwendet wird, das SDK alle nachfolgenden Daten (zum Beispiel Tracking-Events und Conversions) sendet und mit dem ursprünglichenvisitor_codeverknüpft. Diese Trennung stellt sicher, dass Ihre Analysen die einzelnen Benutzerreisen und -interaktionen im breiteren Kontext Ihres Experiments genau widerspiegeln, selbst wenn Sie das Bucketing auf einer höheren Ebene (zum Beispiel einem Konto) oder über mehrere Geräte/Sitzungen hinweg durchführen. Ihre ursprünglichen Besucherdaten bleiben für eine umfassende Berichterstattung intakt.
Technische Anforderungen
Um einen benutzerdefinierten Bucketing-Schlüssel effektiv zu verwenden:- Der Schlüssel muss ein
std::stringsein. - Er muss für die Entität, die Sie bucketen möchten, eindeutig sein (wenn Sie zum Beispiel eine
user_idverwenden, sollte die ID jedes Benutzers eindeutig sein). - Der Schlüssel muss dem SDK genau zu dem Zeitpunkt zur Verfügung stehen, an dem es die Feature-Flag-Entscheidung für diesen Benutzer oder diese Anfrage auswertet.
Targeting-Bedingungen
Die Kameleoon SDKs unterstützen eine Vielzahl vordefinierter Targeting-Bedingungen, die Sie verwenden können, um Benutzer in Ihren Kampagnen anzusprechen. Eine Liste der von diesem SDK unterstützten Bedingungen finden Sie unter Besuchsverlauf verwenden, um Benutzer anzusprechen. Sie können auch Ihre eigenen externen Daten verwenden, um Benutzer anzusprechen.Cross-Device-Experimente
Um Besucher zu unterstützen, die auf eine App von mehreren Geräten zugreifen, ermöglicht Kameleoon die Synchronisierung zuvor gesammelter Besucherdaten über jedes Gerät des Besuchers und die Abstimmung des Besuchsverlaufs zwischen Geräten durch Cross-Device-Experimente. Fallstudien und detaillierte Informationen darüber, wie Kameleoon Daten zwischen Geräten verarbeitet, finden Sie im Artikel zu Cross-Device-Experimenten.Synchronisieren von Custom Data zwischen Geräten
Obwohl die Synchronisierung des benutzerdefinierten Mappings Besucherdaten zwischen Geräten abgleicht, ist sie nicht immer erforderlich. Im Folgenden sind zwei Szenarien aufgeführt, in denen die Synchronisierung des benutzerdefinierten Mappings nicht erforderlich ist: Gleiche Benutzer-ID auf verschiedenen Geräten Wenn Sie dieselbe Benutzer-ID konsistent auf allen Geräten verwenden, handhabt das SDK die Synchronisierung automatisch ohne benutzerdefinierte Mapping-Synchronisierung. Es reicht aus, die Methodeget_remote_visitor_data() aufzurufen, wenn Sie die zwischen mehreren Geräten gesammelten Daten synchronisieren möchten.
Multi-Server-Instanzen mit konsistenten IDs
In komplexen Konfigurationen mit mehreren Servern (zum Beispiel verteilten Serverinstanzen), bei denen dieselbe Benutzer-ID auf allen Servern verfügbar ist, ist die Synchronisierung zwischen Servern (mit get_remote_visitor_data()) ohne zusätzliche benutzerdefinierte Mapping-Synchronisierung ausreichend.
Kunden, die zusätzliche Daten benötigen, können in der Beschreibung der Methode get_remote_visitor_data() weitere Anleitungen finden. Im folgenden Code wird angenommen, dass Sie denselben eindeutigen Bezeichner (in diesem Fall den visitor_code, auch bekannt als userId) konsistent zwischen den beiden Geräten für eine genaue Datenabfrage verwenden.
Wenn Sie gesammelte Daten in Echtzeit synchronisieren möchten, müssen Sie den Geltungsbereich Visitor für Ihre Custom Data wählen.
Device A
Device B
Verwenden von Custom Data für die Sitzungszusammenführung
Cross-Device-Experimente ermöglichen die Kombination des Verlaufs eines Besuchers über alle seine Geräte hinweg (Verlaufsabstimmung). Die Verlaufsabstimmung ermöglicht das Zusammenführen verschiedener Besuchersitzungen in eine. Um den Besuchsverlauf abzugleichen, verwenden SieCustomData, um einen eindeutigen Bezeichner für den Besucher bereitzustellen. Weitere Informationen finden Sie in der speziellen Dokumentation.
Nachdem Sie die Cross-Device-Abstimmung aktiviert haben, ruft der Aufruf von get_remote_visitor_data() mit dem Parameter userId alle bekannten Daten für einen bestimmten Benutzer ab.
Sitzungen mit demselben Bezeichner sehen in einem Experiment immer dieselbe Variation. In der Visitor-Ansicht der Ergebnisseiten Ihres Experiments erscheinen diese Sitzungen als ein einziger Besucher.
Die SDK-Konfiguration stellt sicher, dass zugehörige Sitzungen immer dieselbe Variation des Experiments sehen. Es gibt jedoch einige Einschränkungen hinsichtlich der Cross-Device-Variationszuweisung. Die Dokumentation zu Cross-Device-Experimenten beschreibt diese Einschränkungen.
Folgen Sie der Anleitung Cross-Device-Verlaufsabstimmung aktivieren, um Ihre Custom Data auf der Kameleoon-Plattform einzurichten.
Anschließend können Sie das SDK normal verwenden. Die folgenden Methoden können im Kontext der Sitzungszusammenführung hilfreich sein:
get_remote_visitor_data()mit hinzugefügtemUniqueIdentifier(true)- um Daten für alle verknüpften Besucher abzurufen.track_conversion()oderflush()mit hinzugefügtenUniqueIdentifier(true)-Daten - um einige Daten für einen bestimmten Besucher zu verfolgen, der mit einem anderen Besucher verknüpft ist.
get_visitor_code() generiert wird. Nachdem sich der Benutzer angemeldet hat, verknüpft die App den anonymen Besucher mit der Benutzer-ID und verwendet sie als eindeutigen Bezeichner für den Besucher.
Protokollierung
Das SDK generiert Protokolle, um verschiedene interne Prozesse und Probleme widerzuspiegeln.Protokollierungsstufen
Das SDK unterstützt die Konfiguration der Begrenzung der Protokollierung durch eine Protokollierungsstufe.Benutzerdefinierte Verarbeitung von Protokollen
Das SDK schreibt seine Protokolle standardmäßig in die Konsolenausgabe. Dieses Verhalten kann überschrieben werden.Das SDK begrenzt die Protokollierung nach Protokollierungsstufe getrennt von der Logik zur Protokollverarbeitung.
Referenz
Dies ist die vollständige Referenzdokumentation für das C++ SDK.Initialisierung
create()
Um das SDK zu verwenden, erstellen Sie einenKameleoonClient mit KameleoonClientFactory::create(), entweder aus einer KameleoonClientConfig-Struktur oder aus einer JSON-Konfigurationsdatei.
Clients werden pro Site-Code und Umgebung zwischengespeichert: Wiederholte create()-Aufrufe mit demselben Site-Code und derselben Umgebung geben Clients über dieselbe zugrunde liegende SDK-Instanz zurück, und die Konfiguration des ersten Aufrufs hat Vorrang.
- create(config struct)
- create(config file)
Parameter
Rückgabewert
Fehler
initialize()
Verwenden Sieinitialize(), wenn Ihre App warten soll, bis der Kameleoon-Client die Initialisierung abgeschlossen hat, bevor sie Feature Flags auswertet.
Der Aufruf gibt das Ergebnis des Konfigurationsabrufs zurück: Er wird erfolgreich abgeschlossen, wenn der Client die Initialisierung beendet, und schlägt fehl, wenn der initiale Konfigurationsabruf fehlschlägt, bevor der Client bereit wird. Hintergrund-Wiederholungen werden nach diesem ersten Fehlschlag fortgesetzt. Sobald eine Wiederholung erfolgreich ist, geben nachfolgende Aufrufe ein erfolgreiches Ergebnis zurück. Wenn vor Ablauf des Timeouts kein Initialisierungsergebnis verfügbar ist, schlägt der Aufruf fehl. Wenn Sie keinen timeout-Wert angeben, verwendet das SDK den Standard-Timeout aus default_timeout_millis.
Parameter
Rückgabewert
Fehler
is_ready()
is_ready() prüft, ob das SDK einsatzbereit ist, was bedeutet, dass seine Konfiguration erfolgreich geladen wurde. Im Gegensatz zu initialize() kehrt diese Methode sofort zurück, ohne zu blockieren oder Fehler auszulösen.
Rückgabewert
forget()
Entfernt den zwischengespeicherten SDK-Client, der dem angegebenensite_code zugeordnet ist, sodass der nächste create()-Aufruf mit demselben Site-Code und derselben Umgebung einen neuen erstellt.
forget() gibt nur die Referenz der Factory frei. Jeder für diesen Site-Code erstellte KameleoonClient hält die zugrunde liegende SDK-Instanz (und ihren Worker-Thread, das Polling und das Tracking) am Leben, bis er zerstört wird, und ausstehende asynchrone Operationen halten sie am Leben, bis ihre Completions abgeschlossen sind. Um die Hintergrundressourcen freizugeben, rufen Sie forget() auf und zerstören Sie alle KameleoonClient-Instanzen dieses Site-Codes.
Parameter
Feature Flags und Variationen
is_feature_active()
- 📨 Sendet Tracking-Daten an Kameleoon (abhängig von der Option
track)
Kameleoon verwendet Tracking, um Sitzungen und Besucher zu zählen, wenn Sie bestimmte Methoden aufrufen, wie z. B.
is_feature_active(), get_variation() oder get_variations().Verwenden Sie den Standardwert true für den Parameter track, wenn Sie Besucher einer Variation aussetzen und sie zählen müssen. Setzen Sie den Parameter track nur auf false, wenn Sie diese Methoden aufrufen, bevor Sie Besucher aussetzen.Wenn Sie beispielsweise get_variations() aufrufen, um alle Variationen abzurufen, bevor Sie Besucher aussetzen, setzen Sie den Parameter track auf false. Diese Einstellung verhindert, dass Kameleoon eine Sitzung vorzeitig zählt. Sie können das Tracking dann später auslösen, wenn Sie den Besucher explizit aussetzen.Kameleoon sendet standardmäßig jede Sekunde Tracking-Daten. Sie können dieses Intervall über die Konfigurationsoption für das Tracking-Intervall auf bis zu fünf Sekunden konfigurieren. Kameleoon gruppiert Tracking-Events zu einer einzigen Sitzung, solange das Intervall zwischen den Events weniger als 30 Minuten beträgt. Wenn zwischen den Tracking-Events mehr als 30 Minuten vergehen, zählt Kameleoon die Events als separate Sitzungen. Ein Besuch erscheint in Ihren Berichten 30 Minuten nach dem letzten aufgezeichneten Event in der Sitzung.Parameter
Rückgabewert
Fehler
get_variation()
- 📨 Sendet Tracking-Daten an Kameleoon (abhängig vom Parameter
track)
Variation ab.
Diese Methode nimmt visitor_code und feature_key als obligatorische Argumente entgegen. Das Argument track ist optional und standardmäßig true.
Sie gibt die dem Besucher zugewiesene Variation zurück. Wenn der Besucher mit keinen Feature-Flag-Regeln verknüpft ist, gibt die Methode die Standard-Variation für den angegebenen Feature Flag zurück.
Stellen Sie sicher, dass in Ihrem Code eine ordnungsgemäße Fehlerbehandlung implementiert ist, um potenzielle Ausnahmen zu verwalten.
Die Standardvariation bezieht sich auf die Variation, die einem Besucher zugewiesen wird, wenn er keiner vordefinierten Delivery-Regel für einen Feature Flag entspricht. Mit anderen Worten, es ist die Fallback-Variation, die auf alle Benutzer angewendet wird, die nicht durch spezifische Regeln angesprochen werden. Sie wird als Variation im Abschnitt „Then, for everyone else…” in einer Management-Oberfläche dargestellt.
Parameter
Der optionale Parameter
track wird als Feld track einer GetVariationOptions-Struktur übergeben.Rückgabewert
Fehler
get_variations()
- 📨 Sendet Tracking-Daten an Kameleoon (abhängig vom Parameter
track)
Variation-Objekten ab, die einem bestimmten Besucher für alle Feature Flags zugewiesen sind.
Diese Methode iteriert über alle verfügbaren Feature Flags und gibt die zugewiesene Variation für jeden mit dem angegebenen Besucher verknüpften Flag zurück. Sie nimmt visitor_code als obligatorisches Argument entgegen, während only_active und track optional sind.
- Wenn Sie
only_activeauftruesetzen, gibt die Methodeget_variations()Feature-Flag-Variationen nur zurück, wenn der Besucher nicht mit deroff-Variation gebucketet ist. - Der Parameter
tracksteuert, ob die Methode die Variationszuweisungen verfolgt. Standardmäßig ist er auftruegesetzt. Wenn er auffalsegesetzt ist, verfolgt die Methode keine Variationszuweisungen.
Variations als Werten. Wenn das SDK für einen Feature Flag keine Variation zuweist, gibt die Methode die Standard-Variation für diesen Flag zurück.
Implementieren Sie eine ordnungsgemäße Fehlerbehandlung, um potenzielle Ausnahmen zu verwalten.
Die Standardvariation bezieht sich auf die Variation, die einem Besucher zugewiesen wird, wenn er keiner vordefinierten Delivery-Regel für einen Feature Flag entspricht. Mit anderen Worten, es ist die Fallback-Variation, die auf alle Benutzer angewendet wird, die nicht durch spezifische Regeln angesprochen werden. Sie wird als Variation im Abschnitt „Then, for everyone else…” in einer Management-Oberfläche dargestellt.
Parameter
Die optionalen Parameter
only_active und track werden als Felder einer GetVariationsOptions-Struktur übergeben.Rückgabewert
Fehler
set_forced_variation()
Die Methode ermöglicht es Ihnen, einem Benutzer programmgesteuert eine bestimmteVariation zuzuweisen und den Standardauswertungsprozess zu umgehen. Die Methode ist besonders wertvoll für kontrollierte Experimente, bei denen die übliche Auswertungslogik nicht erforderlich ist oder übersprungen werden muss. Sie kann auch in Szenarien wie Debugging oder benutzerdefinierten Tests hilfreich sein.
Wenn Sie eine erzwungene Variation festlegen, überschreibt sie die Echtzeit-Auswertungslogik von Kameleoon. Das SDK überspringt Prozesse wie Segmentierung, Targeting-Bedingungen und algorithmische Berechnungen. Um Segmentierungs- und Targeting-Bedingungen während eines Experiments beizubehalten, setzen Sie stattdessen force_targeting=false.
Simulierte Variationen haben in der Ausführungsreihenfolge immer Vorrang. Wenn eine simulierte Variationsberechnung beginnt, verarbeitet das SDK sie zuerst vollständig und schließt sie ab.
Parameter
Der optionale Parameter
force_targeting wird als Feld force_targeting einer SetForcedVariationOptions-Struktur übergeben.Fehler
evaluate_audiences()
- 📨 Sendet Tracking-Daten an Kameleoon
evaluate_audiences() nach dem Festlegen oder Aktualisieren aller relevanten Besucherdaten und kurz vor dem Abrufen einer Feature-Variation oder dem Überprüfen eines Feature Flags auf. Dieser Ansatz stellt sicher, dass Kameleoon den Besucher anhand der aktuellsten verfügbaren Daten auswertet, was eine genaue Audience-Zuweisung basierend auf allen Kriterien ermöglicht.
Nach dem Aufruf dieser Methode können Sie eine detaillierte Analyse der Segmentleistung in Audiences Explorer durchführen.
Parameter
Fehler
In den meisten Fällen müssen Sie nur den Basisfehler
KameleoonException behandeln, wie das Beispiel zeigt. Wenn jedoch verschiedene Fehlertypen eine Reaktion erfordern, behandeln Sie jeden einzeln basierend auf den spezifischen Anforderungen. Für eine höhere Zuverlässigkeit können Sie zusätzlich allgemeine Sprachfehler behandeln, indem Sie std::exception einbeziehen.get_datafile()
Gibt die aktuelle SDK-Konfiguration alsDataFile-Objekt zurück.
Das zurückgegebene DataFile ist eine Kopie der aktuellen Konfiguration: Es ändert sich nicht, wenn das SDK seine Konfiguration aktualisiert.
Rückgabewert
Fehler
Besucherdaten
get_visitor_code()
Verwenden Sieget_visitor_code(), um den aktuellen Kameleoon-visitor_code des Besuchers zu erhalten. Die Methode funktioniert mit jedem Cookie-Speicher, der das CookieAccessor-Interface implementiert.
Die Implementierungslogik ist wie folgt:
- Das SDK prüft, ob über den bereitgestellten Accessor bereits ein
kameleoonVisitorCode-Cookie verfügbar ist. - Wenn das Cookie nicht vorhanden ist, verwendet das SDK
default_visitor_code, wenn Sie einen bereitstellen. - Andernfalls generiert das SDK einen neuen Besuchercode und speichert ihn über den Accessor.
Mit der Methode
get_visitor_code() können Sie simulierte Variationen für einen Besucher festlegen. Wenn Cookies (aus einer Anfrage oder einem Dokument) den Schlüssel kameleoonSimulationFFData enthalten, liest die Methode das Cookie und speichert die simulierten Variationen für diesen Besucher; ihr Rückgabewert ändert sich nicht. Nachfolgende Feature-Auswertungen für den Besucher, wie get_variation() und is_feature_active(), umgehen dann den Standardauswertungsprozess und geben die simulierte Variation basierend auf den bereitgestellten Daten zurück.Sie können Simulationen auf zwei Arten anwenden:- Automatisch (empfohlen): Bei Verwendung von Kameleoon Web Experimentation oder dem SDK im Hybridmodus erstellt Kameleoon das Cookie automatisch, wenn Sie die Anzeige einer Variante mithilfe des Simulationspanels simulieren.
- Manuell: Setzen Sie das Cookie
kameleoonSimulationFFDatamanuell.
- Simulierte Variationen: Beeinflussen das Gesamtergebnis des Feature Flags.
- Erzwungene Variationen: Sind spezifisch für ein einzelnes Experiment.
kameleoonSimulationFFData diesem Format folgt:kameleoonSimulationFFData={"featureKey":{"expId":10,"varId":20}}: Simuliert die Variation mitvarIddes ExperimentsexpIdfür den angegebenenfeatureKey.kameleoonSimulationFFData={"featureKey":{"expId":0}}: Simuliert die Standardvariation (definiert im Abschnitt Then, for everyone else in Production, serve) für den angegebenenfeatureKey.
encodeURIComponent als URI-Komponente codiert werden.CookieAccessor-Interface
Implementieren Sie kameleoon::CookieAccessor, um Cookie-Lese- und -Schreibvorgänge des SDK an Ihr HTTP-Framework anzubinden:
get()muss ein bereits überset()in die Antwort geschriebenes Cookie bevorzugt gegenüber dem gleichnamigen Request-Cookie zurückgeben. Das SDK behält zwischen den Aufrufen keinen Cookie-Zustand, daher sorgt dies dafür, dass ein zweiterget_visitor_code()-Aufruf innerhalb derselben Anfrage den vom ersten Aufruf geschriebenen Code zurückgibt, anstatt einen neuen zu generieren.- Die Overrides werden aus dem SDK heraus aufgerufen und dürfen keine Ausnahmen werfen. Eine Ausnahme, die
get()entkommt, wird als nicht vorhandenes Cookie behandelt. Cookie-Werte müssen gültiges UTF-8 sein.
- Custom
- Drogon
Parameter
Rückgabewert
Fehler
add_data()
Die Methodeadd_data() fügt dem Speicher Targeting-Daten hinzu, damit andere Methoden die Daten verwenden können, um zu entscheiden, ob der aktuelle Besucher angesprochen werden soll oder nicht.
Die Methode add_data() gibt keinen Wert zurück und interagiert nicht selbstständig mit den Kameleoon-Backend-Servern. Stattdessen speichert das SDK alle deklarierten Daten für die zukünftige Übertragung mit der Methode flush(). Dieser Ansatz reduziert die Anzahl der Serveraufrufe, da die Daten in der Regel zu einem einzigen Serveraufruf zusammengefasst werden, der durch flush() ausgelöst wird.
Die Methode track_conversion() sendet ebenfalls alle zuvor verknüpften Daten, genau wie flush(). Dasselbe gilt für die Methoden get_variation() und get_variations(), wenn eine Experimentierungsregel ausgelöst wird.
Der Parameter data ist ein std::vector<Data>, wobei Data ein std::variant aller Datentypen ist. Jeder Datentyp wird implizit in Data konvertiert, sodass Sie eine geschweifte Liste von Datenobjekten übergeben können.
Parameter
Fehler
flush()
- 📨 Sendet Tracking-Daten an Kameleoon
flush() aggregiert alle einem Besucher zugeordneten Kameleoon-Daten und sendet eine Tracking-Anfrage an den Server. Diese Anfrage umfasst alle zuvor über die Methode add_data hinzugefügten Daten, die noch nicht über andere Tracking-Mechanismen übertragen wurden (siehe die referenzierten Methoden für Details). Die flush()-Operation ist nicht blockierend, da der Serveraufruf asynchron erfolgt.
Diese Methode bietet Kontrolle darüber, wann die mit einem bestimmten visitor_code verknüpften Daten übertragen werden. Wenn add_data() beispielsweise mehrmals aufgerufen wird, wäre das Senden einer Anfrage nach jedem Aufruf ineffizient. Stattdessen können Sie diese Aktualisierungen bündeln und flush() einmal aufrufen, um alle gesammelten Daten in einer einzigen Anfrage zu senden.
Die Methode flush() verwendet den bereitgestellten visitor_code als eindeutige Besucherkennung.
Parameter
Fehler
get_remote_data()
Mit der Methodeget_remote_data() können Sie Remote-Daten abrufen, die auf Kameleoon-Servern für den angegebenen key gespeichert sind. In den meisten Setups werden diese Daten über die Kameleoon Data API geschrieben und können später von Ihrem C++-Dienst abgerufen werden, wann immer Sie zusätzlichen Anwendungskontext benötigen.
Diese Methode ist nützlich, wenn Sie strukturierte Informationen auf der Remote-Infrastruktur von Kameleoon aufbewahren und von Ihrem Backend aus wiederverwenden möchten, ohne einen separaten Abrufmechanismus zu pflegen.
Parameter
Rückgabewert
Fehler
get_remote_visitor_data()
get_remote_visitor_data() ruft Kameleoon-Besuchsdaten für den angegebenen visitor_code ab. Die Methode fügt die Daten dem lokalen Besucherspeicher hinzu, damit andere SDK-Methoden sie für Targeting-Entscheidungen verwenden können.
Mit dieser Methode erhaltene Daten sind besonders nützlich, wenn Sie:
- von anderen Geräten gesammelte Daten verwenden möchten.
- auf den Verlauf eines Besuchers zugreifen möchten, z. B. zuvor angesehene Seiten aus vergangenen Besuchen.
- Daten verwenden möchten, die nur auf der Clientseite verfügbar sind, wie z. B. Datalayer-Variablen und Frontend-Ziel-Conversions.
Parameter
Fehler
Verwendung von Parametern in get_remote_visitor_data()
Mit der Methodeget_remote_visitor_data() können Sie steuern, welche Daten für einen Besucher abgerufen werden. Derselbe Filteransatz funktioniert für Ziele, Experimente, Variationen und andere Besucherdaten.
Wenn Sie beispielsweise Benutzer ansprechen möchten, die bei ihren letzten fünf Besuchen für ein Ziel konvertiert haben, können Sie previous_visit_amount auf 5 und conversions auf true setzen.
Die in diesem Beispiel gezeigte Flexibilität ist nicht auf Zieldaten beschränkt. Sie können den Filter verwenden, um viele verschiedene Besucherverhalten abzurufen und sie der Targeting- und Reporting-Logik in Ihrer C++-Anwendung zur Verfügung zu stellen.
RemoteVisitorDataFilter-Felder
get_visitor_warehouse_audience()
Diese Methode ruft Audience-Daten ab, die einem Besucher in Ihrer Warehouse-Integration zugeordnet sind, indem sie den angegebenenvisitor_code und optional einen warehouse_key verwendet. Der warehouse_key ist normalerweise Ihre interne Benutzer-ID. Der Parameter custom_data_index entspricht den Kameleoon-Custom-Data, die Kameleoon verwendet, um Ihre Besucher anzusprechen.
Wenn der Aufruf erfolgreich ist, konvertiert das SDK die zurückgegebene Audience-Liste in CustomData, fügt sie dem Besucher lokal hinzu und macht sie für Targeting-Zwecke verfügbar. Weitere Hintergrundinformationen finden Sie in der Warehouse-Targeting-Dokumentation.
Parameter
Fehler
set_legal_consent()
Sie müssen diese Methode verwenden, um anzugeben, ob der Besucher seine rechtliche Einwilligung zur Verwendung personenbezogener Daten gegeben hat. Das Setzen vonconsent auf false schränkt die Datentypen ein, die in Tracking-Anfragen aufgenommen werden können. Dies hilft Ihnen, rechtliche und regulatorische Anforderungen einzuhalten und gleichzeitig Besucherdaten verantwortungsbewusst zu verwalten. Weitere Informationen finden Sie in der Richtlinie zur Einwilligungsverwaltung.
Wenn Sie einen CookieAccessor übergeben, aktualisiert das SDK auch die Besucher-Cookies entsprechend dem Einwilligungsstatus.
Parameter
Fehler
Verhalten beim Widerruf der Einwilligung
Wenn Sieset_legal_consent() mit consent=false aufrufen, löscht das SDK das kameleoonVisitorCode-Cookie nicht. Stattdessen verlängert es das Ablaufdatum des Cookies nicht mehr, sodass das Cookie bis zu seinem natürlichen Ablauf bestehen bleibt.
Wenn Ihre Compliance-Anforderungen die sofortige Entfernung der Cookie-Datei beim Opt-out vorschreiben, müssen Sie sie manuell mit den nativen Cookie-Verwaltungsmethoden Ihres Frameworks löschen. Das SDK entfernt die Datei nicht automatisch.
Ziele und Drittanbieter-Analytik
track_conversion()
- 📨 Sendet Tracking-Daten an Kameleoon
visitor_code und goal_id. Darüber hinaus akzeptiert diese Methode auch die optionalen Argumente revenue, negative und metadata. Der visitor_code ist in der Regel identisch mit dem, der beim Auslösen des Experiments verwendet wurde.
Parameter
Die optionalen Parameter
revenue, negative und metadata werden als Felder einer TrackConversionOptions-Struktur übergeben.Die Metadaten-Werte sind über Rohdaten-Exporte und die Ergebnisseite zugänglich.Wenn Sie den Parameter
metadata angeben, verwendet Kameleoon diese angegebenen Werte für die aktuelle Conversion anstelle dessen, was Sie zuvor mit der Methode add_data() gesammelt haben. Wenn Sie den Parameter weglassen, verwendet Kameleoon die zuletzt verfolgten Werte für diese CustomData vor der Conversion und innerhalb desselben Besuchs.Kameleoon berücksichtigt nur die Metadaten-Werte, die explizit als Parameter an die Methode track_conversion() übergeben werden.Im folgenden Beispiel verknüpft Kameleoon die Conversion nur mit dem Custom-Data-Wert, der explizit als Parameter angegeben wird (hier: Index 5 mit dem Wert ‘Amex Credit Card’).Fehler
get_engine_tracking_code()
Kameleoon lässt sich in mehrere Analyselösungen integrieren, darunter Mixpanel, Google Analytics 4 und Segment. Um serverseitige Experimente korrekt zu verfolgen, rufen Sie die Methodeget_engine_tracking_code() auf, nachdem der Besucher ein Experiment ausgelöst hat. Das SDK gibt JavaScript-Warteschlangenbefehle für die Experimente zurück, die der Besucher in den letzten fünf Sekunden ausgelöst hat. Wenn Sie diesen Code in die Seite einfügen, verarbeitet Engine.js die Befehle und sendet die Expositions-Events über die aktive Analyseintegration.
Weitere Informationen zur Implementierung dieser Methode finden Sie unter Hybrid-Experimentierung.
- Um diese Funktion zu nutzen, implementieren Sie sowohl das C++ SDK als auch Engine.js von Kameleoon. Da Engine.js in diesem Flow nur für das Tracking verwendet wird, können Sie das asynchrone Tag vor dem schließenden
</body>-Tag installieren. - Wenn Sie Experimente nur in Kameleoon verfolgen möchten und keine Expositions-Events an Drittanbieter-Analysetools senden müssen, verwenden Sie das JavaScript / TypeScript SDK. Diese Option eignet sich gut für Serverless-Edge-Compute-Plattformen. Das JavaScript / TypeScript SDK verfolgt Variationen automatisch, wenn Sie
getVisitorCodeaufrufen, solange Sie die entsprechenden Experimentzuweisungen zuwindow.kameleoonQueuehinzufügen. - Sie können den zurückgegebenen Tracking-Code direkt in ein HTML-
<script>-Tag einfügen.
123456 und 234567 Experiment-IDs und 7890 und 8901 Variations-IDs. In Ihrer Implementierung generiert das SDK diese Werte im zurückgegebenen Tracking-Code.Parameter
Rückgabewert
Fehler
Ereignisse
set_event_handler()
Verwenden Sie diese Methode, um einen Handler für SDK-Ereignisse zu registrieren. Das SDK ruft den Handler auf, wenn das ausgewählte Ereignis eintritt. Der Client behält höchstens einen Handler pro Ereignistyp: Die Registrierung eines neuen Handlers für denselben Ereignistyp ersetzt den vorherigen Handler. Der verwendeteEventHandler-Konstruktor (EventHandler::datafile_update() oder EventHandler::http_request()) wählt den Ereignistyp aus, sodass ein Handler und die Ereignisse, die er empfängt, nicht aus dem Takt geraten können. Die Übergabe einer leeren std::function ({}) entfernt den aktuellen Handler für den ausgewählten Ereignistyp.
- datafile_update
- http_request
Handler werden synchron auf dem einzelnen Worker-Thread des SDK aufgerufen, daher dürfen sie nicht blockieren: Die in einem Handler verbrachte Zeit verzögert das Datendatei-Polling und das Senden von Tracking-Daten. Sie müssen thread-sicher sein und dürfen keine Ausnahmen werfen: Eine Ausnahme, die einem Handler entkommt, wird abgefangen und verworfen und beeinflusst das SDK-Verhalten nie. Rufen Sie keine blockierenden SDK-Operationen aus einem Handler auf; verwenden Sie stattdessen die
*_async-Formen und schließen Sie die Arbeit auf einem Anwendungs-Thread ab.Ein bereits laufender Aufruf kann abgeschlossen werden, nachdem Sie den Handler entfernt oder den Client zerstört haben, und der Handler (mit seinen Captures) wird auf einem SDK-Thread zerstört, sobald er nicht mehr verwendet wird. Halten Sie erfasste Objekte entsprechend am Leben und thread-sicher. Ein Handler kann sich selbst entfernen oder ersetzen.Alle KameleoonClient-Instanzen, die für denselben Site-Code und dieselbe Umgebung erstellt wurden, teilen sich einen Handler pro Ereignistyp: Der zuletzt gesetzte Handler gewinnt, und das Zerstören einer dieser Instanzen entfernt ihn. Behalten Sie eine einzige Client-Instanz pro Site-Code und Umgebung.Parameter
Datentypen
Dieser Abschnitt listet die vom SDK im Namespacekameleoon deklarierten C++-Datentypen auf (kameleoon/data/*.hpp). Alle davon sind einfache Strukturen, die Sie an add_data() übergeben.
ApplicationVersion
ApplicationVersion stellt die semantische Versionsnummer Ihrer Anwendung dar.
Browser
Der hier gespeicherteBrowser-Datensatz kann verwendet werden, um Experiment- und Personalisierungsberichte nach jedem damit verknüpften Wert zu filtern.
Conversion
Der hier gespeicherteConversion-Datensatz kann verwendet werden, um Experiment- und Personalisierungsberichte nach jedem damit verknüpften Ziel zu filtern.
Cookie
Cookie enthält Informationen über die auf dem Gerät des Besuchers gespeicherten Cookies.
CustomData
CustomData ermöglicht die Zuordnung beliebiger Datentypen zu jedem Besucher und ist somit ein effektives Werkzeug für Targeting-Bedingungen in Segmenten. Darüber hinaus kann es als Filter oder Aufschlüsselung in Experimentberichten verwendet werden. Weitere Informationen zu Custom Data finden Sie in diesem Artikel.
Definieren Sie Custom-Data-Typen in der Kameleoon-App oder in der Data API und verwenden Sie sie aus dem SDK.
CustomData hat zwei Konstruktoren: Einer identifiziert die Custom Data über ihre id (Index), der andere über ihren name.
-
Jeder Besucher darf nur ein
CustomDatafür jede eindeutigeid(name) haben. Das Hinzufügen eines weiterenCustomDatamit derselbenid(name) ersetzt das vorhandene. - Den „Index” der Custom Data finden Sie im Custom Data-Dashboard unter der Spalte „INDEX”.
- Um zu verhindern, dass das SDK Daten mit dem ausgewählten Index aus Datenschutzgründen an die Kameleoon-Server sendet, aktivieren Sie die Option: Use this data only locally for targeting purposes beim Erstellen von Custom Data.
-
Das Hinzufügen einer mit einem Namen erstellten
CustomData-Instanz, wenn die SDK-Instanz nicht initialisiert oder der Name nicht registriert ist, führt dazu, dass die Daten ignoriert werden.
Device
Sie können Gerätedaten verwenden, um Experiment- und Personalisierungsberichte nach jedem zugeordneten Wert zu filtern.Geolocation
Geolocation enthält die Geolokalisierungsdetails des Besuchers.
OperatingSystem
OperatingSystem enthält Informationen über das Betriebssystem auf dem Gerät des Besuchers.
PageView
Speichert Seitenaufruf-Events.Der Referrer-Index ist in der Kameleoon-App auf der Seite Konfiguration des Akquisitionskanals verfügbar. Achtung: Der Index beginnt bei
0, sodass der erste von Ihnen erstellte Akquisitionskanal die ID 0 hat, nicht 1.UniqueIdentifier
Wenn Sie keinenUniqueIdentifier für einen Besucher hinzufügen, wird visitor_code als eindeutige Besucherkennung verwendet, was für die Cross-Device-Experimentierung nützlich ist. Wenn Sie UniqueIdentifier{true} hinzufügen, verknüpft das SDK die geflushten Daten mit dem Besucher, der der angegebenen Kennung zugeordnet ist.
Dies kann in Situationen nützlich sein, in denen Sie nicht auf den anonymen visitor_code zugreifen können, der einem Besucher ursprünglich zugewiesen wurde, aber Zugriff auf eine interne Kennung haben, die diesem Besucher durch Sitzungszusammenführung zugeordnet ist.
UserAgent
Serverseitige Experimente sind häufiger von Bot-Traffic betroffen als clientseitige Experimente. Kameleoon verwendet die IAB/ABC International Spiders and Bots List, um bekannte Bots und Spider zu erkennen, und verwendet auch das FeldUserAgent, um anderen unerwünschten Traffic herauszufiltern, der Ihre Conversion-Metriken verzerren könnte. Weitere Informationen finden Sie im Hilfeartikel zum Bot-Filtering.
Wenn Sie interne Bots verwenden, senden Sie den User-Agent-Wert curl/8.0, um sie von der Analytik auszuschließen.
Zurückgegebene Typen
DataFile
DasDataFile enthält die SDK-Konfigurationsdetails.
Es kann bei Bedarf mit zusätzlichen Informationen erweitert werden. Wenn Sie weitere Details benötigen, wenden Sie sich bitte an Ihren Customer Success Manager.
FeatureFlag
DerFeatureFlag stellt eine Reihe von Eigenschaften dar, die einen Feature Flag selbst definieren (zum Beispiel seine Variations, Rules, den Umgebungsstatus und andere zugehörige Details).
Er kann bei Bedarf mit zusätzlichen Informationen erweitert werden. Wenn Sie weitere Details benötigen, wenden Sie sich bitte an Ihren Customer Success Manager.
Rule
DieRule stellt eine Reihe von Eigenschaften dar, die eine Regel selbst definieren (zum Beispiel ihre Variations).
Sie kann bei Bedarf mit zusätzlichen Informationen erweitert werden. Wenn Sie weitere Details benötigen, wenden Sie sich bitte an Ihren Customer Success Manager.
Variation
Variation enthält Informationen über die dem Besucher zugewiesene Variation oder die Standardvariation, wenn keine spezifische Zuweisung vorhanden ist.
Variationbeschreibt die zugewiesene oder Standardvariation, währendVariabledie Details jeder einzelnen Variable enthält.idundexperiment_idkönnenstd::nulloptsein, was eine Standardvariation anzeigt, die nicht an eine bestimmte Experimentzuweisung gebunden ist.
Variable
Variable enthält Informationen über eine Variable, die der zugewiesenen Variation zugeordnet ist.
JsonValue
JsonValue stellt den Wert einer Variationsvariable in C++ dar. Das Feld kind unterscheidet die zeichenkettentragenden Arten; value ist ein std::variant<bool, double, std::string>.
Typisierte Accessoren geben
std::nullopt zurück, wenn der Wert von einer anderen Art ist: