Entwicklerhandbuch
Dieses Handbuch soll Ihnen helfen, das Elixir SDK schnell zu integrieren und mit der Auswertung von Feature Flags in Ihrer Elixir-Anwendung zu beginnen.Erste Schritte
Den Elixir-Client installieren
Fügen Sie das SDK als Abhängigkeit in Ihrermix.exs-Datei hinzu:
mix.exs
Zusätzliche Konfiguration
Erstellen Sie eine Konfigurationsdateiclient-elixir.conf, um Anmeldedaten bereitzustellen und das Verhalten des SDK anzupassen.
Wir empfehlen, diese Datei im Standardpfad /etc/kameleoon/client-elixir.conf zu speichern. Kameleoon.ClientFactory.create verwendet diesen Pfad automatisch, wenn Sie keine Konfigurationsoptionen übergeben. Wenn Sie die Datei an einem anderen Ort ablegen, übergeben Sie den Pfad beim Erstellen des Clients über die Option config_path:.
Das Elixir SDK kann entweder über eine Konfigurationsdatei konfiguriert werden, die von Kameleoon.ClientFactory.create verwendet wird, oder durch Übergabe einer %Kameleoon.ClientConfig\{\}-Struktur über die Option config:.
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 einen%Kameleoon.Client\{\} mithilfe von Kameleoon.ClientFactory.
- Config File
- Code
%Kameleoon.Client\{\} ist das Hauptobjekt zur Auswertung von Feature Flags, zum Hinzufügen von Besucherdaten und zum Senden von Tracking-Anfragen.
Aktivieren eines Feature Flags
Einem Benutzer eine eindeutige ID zuweisen
Um einem Benutzer eine eindeutige ID zuzuweisen, können Sie die MethodeClient.get_visitor_code verwenden. Wenn kein Visitor Code (aus dem Cookie der Request-Header) vorhanden ist, generiert die Methode eine zufällige eindeutige ID oder verwendet einen von Ihnen erzeugten default_visitor_code. Die ID wird anschließend in einem Cookie in den Response-Headern gesetzt.
Wenn Sie Kameleoon im Hybridmodus verwenden, stellt der Aufruf der Methode Client.get_visitor_code sicher, dass die eindeutige ID (Visitor Code) zwischen der Anwendungsdatei engine.js (zuvor kameleoon.js genannt) und dem SDK geteilt wird.
Eine Flag-Konfiguration abrufen
Um ein Feature Flag in Ihrem Code zu implementieren, müssen Sie das 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 MethodeClient.get_variation oder Client.is_feature_active? verwenden, um die Konfiguration anhand des feature_key abzurufen.
Die Methode Client.get_variation verarbeitet sowohl einfache Feature Flags mit ON/OFF-Zuständen als auch komplexere Flags mit mehreren Variationen. Die Methode ruft die passende Variation für den Benutzer ab, indem sie die Feature-Regeln prüft, die Variation zuweist und sie anhand des feature_key und visitor_code zurückgibt.
Die Methode Client.is_feature_active? kann verwendet werden, wenn Sie die Konfiguration eines einfachen Feature Flags abrufen möchten, das nur einen ON- oder OFF-Zustand hat – im Gegensatz zu komplexeren Feature Flags mit mehreren Variationen oder Targeting-Optionen.
Wenn Ihrem Feature Flag Variablen zugeordnet sind (z. B. spezifische Verhaltensweisen, die mit den einzelnen Variationen verbunden sind), ermöglicht Client.get_variation auch den Zugriff auf das Variation-Objekt, das Details zur zugewiesenen Variation und zum zugehörigen Experiment bereitstellt. Diese Methode prüft, ob der Benutzer als Zielgruppe definiert ist, ermittelt die dem Besucher zugewiesene Variation und speichert sie. Wenn track=true, sendet das SDK das Expositionsereignis bei der nächsten Tracking-Anfrage an das angegebene Experiment. Diese wird automatisch basierend auf dem tracking_interval_millis des SDK ausgelöst. Standardmäßig ist dieses Intervall auf 1000 Millisekunden (1 Sekunde) eingestellt.
Mit der Methode Client.get_variation können Sie steuern, ob Tracking erfolgen soll. Bei track=false werden vom SDK keine Expositionsereignisse gesendet. Das ist nützlich, wenn Sie Daten nicht über das SDK tracken möchten und stattdessen z. B. clientseitiges Tracking durch die Kameleoon Engine verwenden. Außerdem ist track=false hilfreich bei der Verwendung der Methode Client.get_variations, wenn Sie nur die Variationen für alle Flags benötigen, ohne Tracking-Ereignisse auszulösen. Wenn Sie mehr darüber erfahren möchten, wie Tracking funktioniert, lesen Sie diesen Artikel.
Datenpunkte hinzufügen, um Benutzer anzusprechen oder Besuche in Berichten zu filtern/aufzuschlüsseln
Um einen Benutzer anzusprechen, stellen Sie sicher, dass Sie seinem Profil relevante Datenpunkte hinzugefügt haben, bevor Sie die Feature-Variation abrufen oder prüfen, ob das Flag aktiv ist. Verwenden Sie die MethodeClient.add_data, um diese Datenpunkte zum Profil des Benutzers hinzuzufügen.
Um Datenpunkte abzurufen, die auf anderen Geräten erfasst wurden, oder auf vergangene Benutzerdaten zuzugreifen (clientseitig erfasst bei Verwendung von Kameleoon im Hybridmodus), verwenden Sie die Methode Client.get_remote_visitor_data. Diese Methode ruft Daten asynchron von den Servern ab. Es ist wichtig, Client.get_remote_visitor_data vor dem Abrufen der Variation oder der Prüfung, ob das Feature Flag aktiv ist, aufzurufen, da diese Daten möglicherweise erforderlich sind, um einem Benutzer eine bestimmte Variation zuzuweisen.
Weitere Informationen zu den verfügbaren Targeting-Bedingungen finden Sie im ausführlichen Artikel zu diesem Thema.
Außerdem stehen Ihnen die zum Besucherprofil hinzugefügten Datenpunkte bei der Analyse Ihrer Experimente zur Verfügung, sodass Sie Ihre Ergebnisse nach Faktoren wie Gerät und Browser filtern und aufschlüsseln können. Der Kameleoon-Hybridmodus erfasst clientseitig automatisch eine Vielzahl von Datenpunkten, was es einfach macht, Ihre Ergebnisse anhand dieser vorab erfassten Datenpunkte aufzuschlüsseln. Die vollständige Liste finden Sie hier.
Wenn Sie zusätzliche Datenpunkte über die automatisch erfassten hinaus verfolgen möchten, können Sie die Funktion Custom Data von Kameleoon verwenden. Mit Custom Data können Sie spezifische, für Ihre Experimente relevante Informationen erfassen und analysieren. Vergessen Sie nicht, die Methode Client.flush aufzurufen, um die gesammelten Daten zur Analyse an die Kameleoon-Server zu senden.
Um die Genauigkeit Ihrer Ergebnisse zu gewährleisten, wird empfohlen, Bots mithilfe des Datentyps
UserAgent herauszufiltern.Tracking von Zielkonvertierungen
Wenn ein Benutzer eine gewünschte Aktion ausführt (z. B. einen Kauf tätigt), wird dies als Konvertierung erfasst. Verwenden Sie die MethodeClient.track_conversion und geben Sie die erforderlichen Parameter visitor_code und goal_id an, um Konvertierungen zu tracken.
Die Anfrage zum Tracken der Konvertierung wird zusammen mit der nächsten geplanten Tracking-Anfrage gesendet, die das SDK in regelmäßigen Abständen (definiert durch tracking_interval_millis) sendet. Wenn Sie die Anfrage sofort senden möchten, verwenden Sie die Methode Client.flush_instant.
Ereignisse an Analyselösungen senden
Um Konvertierungen zu tracken und Expositionsereignisse an Ihre Kundenanalyselösung zu senden, müssen Sie Kameleoon zunächst im Hybridmodus implementieren. Verwenden Sie anschließend die MethodeClient.get_engine_tracking_code.
Die Methode Client.get_engine_tracking_code ruft den eindeutigen Tracking-Code ab, der erforderlich ist, um Expositionsereignisse an Ihre Analyselösung zu senden. Mit dieser Methode können Sie Ereignisse aufzeichnen und an die gewünschte Analyseplattform senden.
Verwendung eines benutzerdefinierten Bucketing-Schlüssels
Standardmäßig verwendet Kameleoon eine eindeutige, anonyme Besucher-ID (visitor_code), um Benutzer den Variationen von Feature Flags zuzuweisen. Diese ID wird typischerweise auf dem Gerät des Benutzers generiert und gespeichert (in einem Browser-Cookie bei client- und serverseitigen SDKs – im persistenten Speicher bei mobilen SDKs). In bestimmten Szenarien müssen Sie jedoch möglicherweise sicherstellen, dass alle Benutzer derselben Organisation dieselbe Variante eines Feature Flags sehen.
Die Option benutzerdefinierter Bucketing-Schlüssel ermöglicht es Ihnen, dieses Standardverhalten zu überschreiben, indem Sie Ihren eigenen benutzerdefinierten Bezeichner für das Bucketing angeben. Diese Überschreibung stellt sicher, dass die Zuweisungslogik von Kameleoon den von Ihnen angegebenen Schlüssel anstelle des standardmäßigen visitor_code verwendet.
Anwendungsfälle
Die Verwendung eines benutzerdefinierten Bucketing-Schlüssels ist entscheidend für die Aufrechterhaltung von Konsistenz und Genauigkeit bei Ihren Feature-Flag-Zuweisungen, insbesondere in folgenden Situationen:- Experimente auf Konto- oder Organisationsebene: Bei B2B-Produkten 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 ein Feature Flag konfigurieren, übergeben Sie Kameleoon einen spezifischen Bezeichner aus den Daten Ihrer Anwendung:- Bereitstellung des benutzerdefinierten Schlüssels: Sie übergeben Ihren benutzerdefinierten Bezeichner an das Kameleoon SDK mithilfe der Methode
Client.add_data. Bei dieser Methode übergeben Sie den von Ihnen gewählten benutzerdefinierten Bucketing-Schlüssel alsCustomData-Objekt. Hier bezeichnetnew_visitor_codeden Bezeichner, den Sie für Ihr Bucketing verwenden möchten (z. B. die neueuser_idoderaccount_id).
- Bucketing-Logik: Sobald ein benutzerdefinierter Bucketing-Schlüssel über die Methode
Client.add_databereitgestellt wurde, verwenden alle Hash-Berechnungen zur Zuweisung von Benutzern zu Variationen diesennew_visitor_code(Ihren benutzerdefinierten Schlüssel) anstelle des standardmäßigenvisitor_code. Durch die Verwendung desnew_visitor_codeist die Bucketing-Entscheidung an Ihren benutzerdefinierten Bezeichner gebunden, was konsistente Zuweisungen in verschiedenen Kontexten gewährleistet, in denen dieser Bezeichner vorhanden ist. - Datenverfolgung und Analyse: Es ist wichtig zu beachten, dass zwar der
new_visitor_code(Ihr benutzerdefinierter Schlüssel) für Bucketing-Entscheidungen verwendet wird, aber alle nachfolgenden Daten (z. B. Tracking-Ereignisse und Konvertierungen) mit dem ursprünglichenvisitor_codegesendet und verknüpft werden. Diese Trennung stellt sicher, dass Ihre Analysen die individuellen Benutzerreisen und Interaktionen im breiteren Kontext Ihres Experiments korrekt widerspiegeln, selbst wenn das Bucketing auf einer höheren Ebene (z. B. einem Konto) oder über mehrere Geräte/Sitzungen hinweg erfolgt. Ihre ursprünglichen Besucherdaten bleiben für umfassende Berichte erhalten.
Technische Anforderungen
Um einen benutzerdefinierten Bucketing-Schlüssel effektiv zu verwenden:- Der Schlüssel muss ein
String.t()sein. - Er muss für die Entität, für die Sie das Bucketing durchführen möchten, eindeutig sein (z. B. sollte bei Verwendung einer
user_iddie ID jedes Benutzers eindeutig sein). - Der Schlüssel muss dem SDK genau in dem Moment zur Verfügung stehen, in dem die Feature-Flag-Entscheidung für diesen Benutzer oder diese Anfrage ausgewertet wird.
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 Besuchshistorie zum Targeting von Benutzern verwenden. Sie können auch Ihre eigenen externen Daten zum Targeting von Benutzern verwenden.Geräteübergreifende Experimente
Um Besucher zu unterstützen, die von mehreren Geräten aus auf eine App zugreifen, ermöglicht Kameleoon die Synchronisierung zuvor erfasster Besucherdaten zwischen allen Geräten eines Besuchers und die Zusammenführung seiner Besuchshistorie geräteübergreifend mithilfe geräteübergreifender Experimente. Fallstudien und detaillierte Informationen darüber, wie Kameleoon Daten geräteübergreifend handhabt, finden Sie im Artikel zu geräteübergreifenden Experimenten.Synchronisieren von benutzerdefinierten Daten geräteübergreifend
Obwohl benutzerdefinierte Mapping-Synchronisierung verwendet wird, um Besucherdaten geräteübergreifend abzugleichen, ist sie nicht immer erforderlich. Im Folgenden werden zwei Szenarien beschrieben, in denen eine benutzerdefinierte Mapping-Synchronisierung nicht notwendig ist: Gleiche Benutzer-ID auf allen Geräten Wenn dieselbe Benutzer-ID auf allen Geräten konsistent verwendet wird, erfolgt die Synchronisierung automatisch ohne benutzerdefinierte Mapping-Synchronisierung. Es genügt, die MethodeClient.get_remote_visitor_data aufzurufen, wenn Sie die zwischen mehreren Geräten erfassten Daten synchronisieren möchten.
Multi-Server-Instanzen mit konsistenten IDs
In komplexen Setups mit mehreren Servern (z. B. verteilten Serverinstanzen), bei denen dieselbe Benutzer-ID auf allen Servern verfügbar ist, ist die Synchronisierung zwischen Servern (mit Client.get_remote_visitor_data) ausreichend, ohne dass eine zusätzliche benutzerdefinierte Mapping-Synchronisierung erforderlich ist.
Kunden, die zusätzliche Daten benötigen, finden weitere Hinweise in der Beschreibung der Methode Client.get_remote_visitor_data. Im untenstehenden Code wird davon ausgegangen, dass derselbe eindeutige Bezeichner (in diesem Fall der visitor_code, der auch als userId bezeichnet werden kann) auf den beiden Geräten für einen genauen Datenabruf konsistent verwendet wird.
Wenn Sie erfasste Daten in Echtzeit synchronisieren möchten, müssen Sie den Scope Visitor für Ihre benutzerdefinierten Daten wählen.
Device A
Device B
Verwendung von benutzerdefinierten Daten zur Sitzungszusammenführung
Geräteübergreifende Experimente ermöglichen es, die Historie eines Besuchers über alle seine Geräte hinweg zu kombinieren (Historien-Zusammenführung). Die Historien-Zusammenführung ermöglicht das Zusammenführen verschiedener Besuchersitzungen zu einer einzigen. Verwenden SieCustomData, um einen eindeutigen Bezeichner für den Besucher bereitzustellen und die Besuchshistorie zusammenzuführen. Weitere Informationen finden Sie in der entsprechenden Dokumentation.
Nachdem die geräteübergreifende Zusammenführung aktiviert ist, ruft der Aufruf von Client.get_remote_visitor_data mit dem Parameter userId alle bekannten Daten für einen bestimmten Benutzer ab.
Sitzungen mit demselben Bezeichner werden in einem Experiment immer derselben Variation zugeordnet. In der Besucheransicht Ihrer Experimentergebnisseiten erscheinen diese Sitzungen als ein einziger Besucher.
Die SDK-Konfiguration stellt sicher, dass zugeordnete Sitzungen immer dieselbe Variation des Experiments sehen. Es gibt jedoch einige Einschränkungen hinsichtlich der geräteübergreifenden Variationszuweisung. Diese Einschränkungen sind hier beschrieben.
Folgen Sie der Anleitung Aktivieren der geräteübergreifenden Historien-Zusammenführung, um Ihre benutzerdefinierten Daten 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:
Client.get_remote_visitor_datamit hinzugefügtemUniqueIdentifier(true)– um Daten für alle verknüpften Besucher abzurufen.Client.track_conversionoderClient.flushmit hinzugefügtemUniqueIdentifier(true)-Datentyp – um bestimmte Daten für einen Besucher zu tracken, der mit einem anderen Besucher verknüpft ist.
Client.get_visitor_code generiert wurde. Nachdem sich der Benutzer angemeldet hat, wird der anonyme Besucher mit der Benutzer-ID verknüpft und als eindeutiger Bezeichner für den Besucher verwendet.
Logging
Das SDK generiert Logs, um verschiedene interne Prozesse und Probleme abzubilden.Log-Level
Das SDK unterstützt die Konfiguration der Logging-Begrenzung durch ein Log-Level.Benutzerdefinierte Verarbeitung von Logs
Das SDK schreibt seine Logs standardmäßig in die Konsolenausgabe. Dieses Verhalten kann überschrieben werden.Die Begrenzung des Loggings nach Log-Level erfolgt unabhängig von der Logik der Logverarbeitung.
Referenz
Dies ist die vollständige Referenzdokumentation für das Elixir SDK.Initialisierung
create()
Um das SDK zu verwenden, erstellen Sie einen%Kameleoon.Client\{\} mit Kameleoon.ClientFactory.create. Standardmäßig liest create die Datei /etc/kameleoon/client-elixir.conf. Sie können auch entweder eine %Kameleoon.ClientConfig\{\}-Struktur über config: oder einen benutzerdefinierten Konfigurationsdateipfad über config_path: angeben.
- config:
- config_path:
Argumente
Rückgabewert
Fehler
initialize()
Wartet auf die Initialisierung des Kameleoon-Clients, entweder mit dem konfiguriertendefault_timeout_millis oder mit einem bereitgestellten timeout. Diese Methode stellt sicher, dass der Client vollständig initialisiert ist, bevor weitere Operationen ausgeführt werden.
Argumente
Rückgabewert
Fehler
is_ready()
Prüft, ob der Client initialisiert wurde.Rückgabewert
forget()
Entfernt den zwischengespeicherten SDK-Client, der mit dem angegebenensite_code verknüpft ist.
Argumente
Rückgabewert
Feature Flags und Variationen
is_feature_active()
- 📨 Sendet Tracking-Daten an Kameleoon (abhängig von der
track-Option)
Kameleoon verwendet Tracking, um Sitzungen und Besucher zu zählen, wenn Sie bestimmte Methoden aufrufen, z. B.
Client.is_feature_active?, Client.get_variation oder Client.get_variations.Verwenden Sie den Standardwert true für den Parameter track, wenn Sie Besucher einer Variation aussetzen und sie zählen möchten. Setzen Sie den Parameter track nur dann auf false, wenn Sie diese Methoden aufrufen, bevor Sie die Besucher aussetzen.Wenn Sie beispielsweise Client.get_variations aufrufen, um vor der Aussetzung der Besucher alle Variationen abzurufen, setzen Sie den Parameter track auf false. Diese Einstellung verhindert, dass Kameleoon eine Sitzung vorzeitig zählt. Sie können das Tracking später auslösen, wenn Sie den Besucher explizit aussetzen.Kameleoon sendet Tracking-Daten standardmäßig jede Sekunde. Sie können dieses Intervall über die Konfigurationsoption Tracking-Intervall auf bis zu fünf Sekunden konfigurieren. Kameleoon gruppiert Tracking-Ereignisse in einer einzigen Sitzung, solange das Intervall zwischen den Ereignissen weniger als 30 Minuten beträgt. Wenn zwischen den Tracking-Ereignissen mehr als 30 Minuten vergehen, zählt Kameleoon die Ereignisse als separate Sitzungen. Ein Besuch erscheint 30 Minuten nach dem zuletzt aufgezeichneten Ereignis der Sitzung in Ihren Berichten.Argumente
Rückgabewert
Fehler
get_variation()
- 📨 Sendet Tracking-Daten an Kameleoon (abhängig vom Parameter
track)
Variation ab.
Diese Methode akzeptiert visitor_code und feature_key als obligatorische Argumente. Das Argument track ist optional und standardmäßig auf true gesetzt.
Sie gibt die zugewiesene Variation für den Besucher zurück. Wenn der Besucher keinen Feature-Flag-Regeln zugeordnet ist, gibt die Methode die standardmäßige Variation für das angegebene 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 der vordefinierten Auslieferungsregeln eines Feature Flags entspricht. Mit anderen Worten ist es die Fallback-Variation, die auf alle Benutzer angewendet wird, die nicht durch spezifische Regeln angesprochen werden. Sie wird durch die Variation im Abschnitt „Dann für alle anderen …“ in einer Verwaltungsoberfläche dargestellt.
Argumente
Rückgabewert
Fehler
get_variations()
- 📨 Sendet Tracking-Daten an Kameleoon (abhängig vom Parameter
track)
Variation-Objekten ab, die einem bestimmten Besucher über alle Feature Flags hinweg zugewiesen sind.
Diese Methode iteriert über alle verfügbaren Feature Flags und gibt die zugewiesene Variation für jedes Flag zurück, das dem angegebenen Besucher zugeordnet ist. Sie akzeptiert visitor_code als obligatorisches Argument, während only_active und track optional sind.
- Wenn
only_activeauftruegesetzt ist, gibt die MethodeClient.get_variationsdie Feature-Flag-Variationen zurück, sofern der Benutzer nicht deroff-Variation zugeordnet ist. - Der Parameter
tracksteuert, ob die Methode die Variationszuweisungen trackt. Standardmäßig ist er auftruegesetzt. Beifalsewird das Tracking deaktiviert.
Variation als Werte. Wenn einem Feature Flag keine Variation zugewiesen ist, gibt die Methode die Standard-Variation für dieses Flag zurück.
Eine ordnungsgemäße Fehlerbehandlung sollte implementiert werden, um potenzielle Ausnahmen zu verwalten.
Die Standardvariation bezieht sich auf die Variation, die einem Besucher zugewiesen wird, wenn er keiner der vordefinierten Auslieferungsregeln eines Feature Flags entspricht. Mit anderen Worten ist es die Fallback-Variation, die auf alle Benutzer angewendet wird, die nicht durch spezifische Regeln angesprochen werden. Sie wird durch die Variation im Abschnitt „Dann für alle anderen …“ in einer Verwaltungsoberfläche dargestellt.
Argumente
Rückgabewert
Fehler
set_forced_variation()
Mit dieser Methode können Sie einem Benutzer programmgesteuert eine bestimmteVariation zuweisen und so den üblichen Auswertungsprozess umgehen. Dies ist besonders wertvoll für kontrollierte Experimente, bei denen die übliche Auswertungslogik nicht erforderlich ist oder übersprungen werden muss. Es kann auch in Szenarien wie Debugging oder benutzerdefinierten Tests hilfreich sein.
Wenn eine erzwungene Variation gesetzt wird, überschreibt sie die Echtzeit-Auswertungslogik von Kameleoon. Prozesse wie Segmentierung, Targeting-Bedingungen und algorithmische Berechnungen werden übersprungen. Um Segmentierung 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 Berechnung einer simulierten Variation ausgelöst wird, wird sie zuerst vollständig verarbeitet und abgeschlossen.
Argumente
Rückgabewert
Fehler
evaluate_audiences()
- 📨 Sendet Tracking-Daten an Kameleoon
Client.evaluate_audiences sollte aufgerufen werden, nachdem alle relevanten Besucherdaten gesetzt oder aktualisiert wurden, und kurz bevor eine Feature-Variation abgerufen oder ein Feature Flag geprüft wird. Dieser Ansatz stellt sicher, dass der Besucher anhand der aktuellsten verfügbaren Daten ausgewertet wird und ermöglicht eine genaue Audience-Zuweisung anhand aller Kriterien.
Nach dem Aufruf dieser Methode können Sie eine detaillierte Analyse der Segmentleistung im Audiences Explorer durchführen.
Argumente
Rückgabewert
Fehler
get_datafile()
Gibt die aktuelle SDK-Konfiguration alsDataFile-Objekt zurück.
Rückgabewert
Fehler
Besucherdaten
get_visitor_code()
Verwenden Sieget_visitor_code(), um den Kameleoon visitor_code des aktuellen Besuchers zu erhalten. Die Methode funktioniert mit jedem Cookie-Speicher, der das Behaviour Kameleoon.CookieAccessor implementiert.
Die Implementierungslogik lautet 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 den
default_visitor_code, sofern Sie einen bereitstellen. - Andernfalls generiert das SDK einen neuen Visitor Code und speichert ihn über den Accessor.
Mit der Methode
Client.get_visitor_code können Sie simulierte Variationen für einen Besucher festlegen. Wenn Cookies (aus einer Request oder einem Dokument) den Schlüssel kameleoonSimulationFFData enthalten, wird der Standard-Auswertungsprozess umgangen. Stattdessen gibt die Methode direkt eine 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 wird das Cookie beim Simulieren der Anzeige einer Variante über das Simulations-Panel automatisch erstellt.
- Manuell: Setzen Sie das Cookie
kameleoonSimulationFFDatamanuell.
- Simulierte Variationen: Wirken sich auf das Gesamtergebnis des Feature Flags aus.
- Erzwungene Variationen: Sind spezifisch für ein einzelnes Experiment.
kameleoonSimulationFFData dem folgenden Format entspricht:kameleoonSimulationFFData={"featureKey":{"expId":10,"varId":20}}: Simuliert die Variation mitvarIddes ExperimentsexpIdfür den angegebenenfeatureKey.kameleoonSimulationFFData={"featureKey":{"expId":0}}: Simuliert die Standardvariation (definiert im Abschnitt Dann allen anderen in Production ausliefern) für den angegebenenfeatureKey.
encodeURIComponent.- Map
- Plug.Conn
Argumente
Das Accessor-Modul muss
get und set implementieren. get liest einen Cookie-Wert aus dem Accessor-Zustand, und set gibt den aktualisierten Zustand zurück, nachdem es key, value, max_age und top_level_domain erhalten hat.
Rückgabewert
add_data()
Die MethodeClient.add_data fügt Targeting-Daten zum Speicher hinzu, sodass andere Methoden anhand dieser Daten entscheiden können, ob der aktuelle Besucher angesprochen werden soll oder nicht.
Die Methode Client.add_data gibt keinen Wert zurück und interagiert nicht eigenständig mit den Kameleoon-Backend-Servern. Stattdessen werden alle deklarierten Daten für eine spätere Übertragung mit der Methode Client.flush gespeichert. Dieser Ansatz reduziert die Anzahl der Server-Aufrufe, da die Daten typischerweise in einem einzigen Server-Aufruf gebündelt werden, der durch Client.flush ausgelöst wird.
Die Methode Client.track_conversion sendet ebenfalls alle zuvor zugeordneten Daten, genau wie Client.flush. Dasselbe gilt für die Methoden Client.get_variation und Client.get_variations, wenn eine Experiment-Regel ausgelöst wird.
Argumente
Rückgabewert
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 enthält 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 Server-Aufruf asynchron durchgeführt wird.
Diese Methode bietet Kontrolle darüber, wann Daten, die mit einem bestimmten visitor_code verknüpft sind, übertragen werden. Wenn z. B. add_data() 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 eindeutigen Besucher-Bezeichner.
Argumente
Rückgabewert
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 Elixir-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 speichern und von Ihrem Backend aus wiederverwenden möchten, ohne einen separaten Abrufmechanismus zu pflegen.
Argumente
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, sodass andere SDK-Methoden sie für Targeting-Entscheidungen verwenden können.
Mit dieser Methode abgerufene Daten sind besonders nützlich, wenn Sie:
- Daten verwenden möchten, die von anderen Geräten erfasst wurden.
- auf die Historie eines Besuchers zugreifen möchten, z. B. zuvor angesehene Seiten aus früheren Besuchen.
- Daten verwenden möchten, die nur clientseitig verfügbar sind, z. B. Datalayer-Variablen und Front-End-Zielkonvertierungen.
Argumente
Rückgabewert
Fehler
Verwenden 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 z. B. Benutzer ansprechen möchten, die in ihren letzten fünf Besuchen auf 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 Besucherverhaltensweisen abzurufen und sie in der Targeting- und Berichtslogik Ihrer Elixir-Anwendung verfügbar zu machen.
Felder von RemoteVisitorDataFilter
get_visitor_warehouse_audience()
Diese Methode ruft die mit einem Besucher in Ihrer Warehouse-Integration verknüpften Audience-Daten ab, 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 benutzerdefinierten Kameleoon-Daten, die Kameleoon zum Ansprechen Ihrer Besucher verwendet.
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 Dokumentation zum Warehouse-Targeting.
Argumente
Rückgabewert
Fehler
set_legal_consent()
Sie müssen diese Methode verwenden, um anzugeben, ob der Besucher seine rechtliche Einwilligung zur Verwendung personenbezogener Daten gegeben hat. Wennlegal_consent auf false gesetzt wird, werden die Datentypen, die in Tracking-Anfragen enthalten sein können, eingeschränkt. Dies hilft Ihnen, gesetzliche und regulatorische Anforderungen einzuhalten und gleichzeitig die Besucherdaten verantwortungsvoll zu verwalten. Weitere Informationen finden Sie in der Richtlinie zur Einwilligungsverwaltung.
Das Elixir SDK aktualisiert Besucher-Cookies über den erforderlichen Kameleoon.CookieAccessor-Adapter und gibt den aktualisierten Adapterzustand zurück.
Argumente
Rückgabewert
Fehler
Verhalten beim Widerruf der Einwilligung
Wenn SieClient.set_legal_consent mit legal_consent=false aufrufen, löscht das SDK das Cookie kameleoonVisitorCode nicht. Stattdessen wird das Ablaufdatum des Cookies nicht mehr verlängert, sodass das Cookie bestehen bleibt, bis es auf natürliche Weise abläuft.
Wenn Ihre Compliance-Anforderungen das sofortige Entfernen 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-Analysen
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 normalerweise identisch mit dem, der beim Auslösen des Experiments verwendet wurde.
Argumente
Metadatenwerte sind über Rohdatenexporte und die Ergebnisseite zugänglich.Wenn der Parameter
metadata angegeben wird, verwendet Kameleoon diese angegebenen Werte für die aktuelle Konvertierung anstelle der zuvor mit der Methode Client.add_data erfassten Werte. Wenn der Parameter weggelassen wird, verwendet Kameleoon die zuletzt getrackten Werte für diese CustomData vor der Konvertierung und innerhalb desselben Besuchs.Kameleoon berücksichtigt nur die Metadatenwerte, die explizit als Parameter an die Methode Client.track_conversion übergeben werden.Im folgenden Beispiel verknüpft Kameleoon die Konvertierung nur mit dem benutzerdefinierten Datenwert, der explizit als Parameter angegeben wurde (hier: Index 5 mit dem Wert „Amex Credit Card“).Rückgabewert
Fehler
get_engine_tracking_code()
Kameleoon ist mit mehreren Analyselösungen integriert, darunter Mixpanel, Google Analytics 4 und Segment. Um serverseitige Experimente korrekt zu tracken, rufen Sie die MethodeClient.get_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 Expositionsereignisse über die aktive Analyseintegration.
Weitere Informationen zur Implementierung dieser Methode finden Sie unter Hybride Experimente.
- Um diese Funktion zu nutzen, implementieren Sie sowohl das Elixir SDK als auch Kameleoon Engine.js. Da Engine.js in diesem Ablauf nur für das Tracking verwendet wird, können Sie das asynchrone Tag vor dem schließenden
</body>-Tag einbinden. - Wenn Sie nur Experimente in Kameleoon tracken möchten und keine Expositionsereignisse 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 trackt Variationen automatisch, wenn Sie
getVisitorCodeaufrufen, sofern 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 sowie 8901 Variations-IDs. In Ihrer Implementierung generiert das SDK diese Werte im zurückgegebenen Tracking-Code.Argumente
Rückgabewert
Fehler
Ereignisse
on_datafile_update()
Mit der MethodeClient.on_datafile_update können Sie das Ereignis behandeln, wenn die Konfiguration Daten aktualisiert hat. Sie akzeptiert einen Eingabeparameter, handler. Der Handler wird aufgerufen, wenn die Konfiguration über ein Echtzeit-Konfigurationsereignis aktualisiert wird.
Argumente
Datentypen
Dieser Abschnitt listet die unterKameleoon.Data verfügbaren Elixir-Datentypen auf.
ApplicationVersion
ApplicationVersion stellt die semantische Versionsnummer Ihrer Anwendung dar.
Browser
Der hier gespeicherte DatensatzBrowser kann verwendet werden, um Experiment- und Personalisierungsberichte nach jedem damit verknüpften Wert zu filtern.
Conversion
Der hier gespeicherte DatensatzConversion 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 jeglicher Art von Daten zu jedem Besucher und ist damit ein wirksames Werkzeug für Targeting-Bedingungen in Segmenten. Außerdem kann es als Filter oder Aufschlüsselung in Experimentberichten verwendet werden. Weitere Informationen zu benutzerdefinierten Daten finden Sie in diesem Artikel.
Definieren Sie benutzerdefinierte Datentypen in der Kameleoon-App oder über die Data API und verwenden Sie sie aus dem SDK heraus.
-
Jeder Besucher ist nur eine
CustomDatafür jeden eindeutigenindex(name) erlaubt. Das Hinzufügen einer weiterenCustomDatamit demselbenindex(name) ersetzt die bestehende. - Den ‚Index‘ der benutzerdefinierten Daten finden Sie im Dashboard für benutzerdefinierte Daten in der Spalte „INDEX“.
- Um zu verhindern, dass das SDK aus Datenschutzgründen Daten mit dem ausgewählten Index an die Kameleoon-Server sendet, aktivieren Sie beim Erstellen der benutzerdefinierten Daten die Option: Diese Daten nur lokal für Targeting-Zwecke verwenden.
-
Das Hinzufügen einer
CustomData-Instanz, die mit einem Namen erstellt wurde, 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 Geolokalisierungsdaten des Besuchers.
OperatingSystem
OperatingSystem enthält Informationen über das Betriebssystem auf dem Gerät des Besuchers.
PageView
Speichert Seitenaufruf-Ereignisse.Der Referrer-Index ist in der Kameleoon-App auf der Seite Konfiguration des Akquisitionskanals verfügbar. Vorsicht: Der Index beginnt bei
0, sodass der erste von Ihnen erstellte Akquisitionskanal die ID 0 und nicht 1 hat.UniqueIdentifier
Wenn Sie für einen Besucher keinenUniqueIdentifier hinzufügen, wird der visitor_code als eindeutiger Besucher-Bezeichner verwendet, was für geräteübergreifende Experimente nützlich ist. Wenn Sie UniqueIdentifier(true) hinzufügen, verknüpft das SDK die geflushten Daten mit dem Besucher, der dem angegebenen Bezeichner 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 einen internen Bezeichner haben, der über die Sitzungszusammenführung mit diesem Besucher verknüpft 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 nutzt außerdem das FeldUserAgent, um anderen unerwünschten Traffic herauszufiltern, der Ihre Konvertierungsmetriken verfälschen könnte. Weitere Informationen finden Sie im Hilfeartikel zur Bot-Filterung.
Wenn Sie interne Bots verwenden, empfehlen wir, den User-Agent-Wert curl/8.0 zu senden, um sie aus den Analysen auszuschließen.
Rückgabetypen
DataFile
DasDataFile enthält die SDK-Konfigurationsdetails.
Es kann bei Bedarf um zusätzliche Informationen für Kunden erweitert werden. Wenn Sie weitere Details benötigen, wenden Sie sich bitte an Ihren Customer Success Manager.
FeatureFlag
DasFeatureFlag stellt eine Reihe von Eigenschaften dar, die ein Feature Flag selbst definieren – z. B. seine Variationen, Regeln, den Umgebungsstatus und weitere zugehörige Details.
Es kann bei Bedarf um zusätzliche Informationen für Kunden 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 – z. B. ihre Variationen.
Sie kann bei Bedarf um zusätzliche Informationen für Kunden 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 existiert.
Variationbeschreibt die zugewiesene oder Standardvariation, währendVariabledie Details jeder einzelnen Variable enthält.idundexperiment_idkönnennilsein, was eine Standardvariation kennzeichnet, die nicht an eine bestimmte Experimentzuweisung gebunden ist.
Variable
Variable enthält Informationen über eine Variable, die mit der zugewiesenen Variation verknüpft ist.