Zum Hauptinhalt springen
Mit dem Kameleoon Elixir SDK können Sie Experimente ausführen und Feature Flags in Ihren Elixir-Diensten und Web-Backends aktivieren. Erste Schritte: Hilfe für den Einstieg finden Sie im Entwicklerhandbuch. Version: Aktuelle Version des Elixir SDK: 0.8.6 Changelog. SDK-Methoden: Die vollständige Referenzdokumentation des Elixir SDK finden Sie im Abschnitt Referenz.

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 Ihrer mix.exs-Datei hinzu:
mix.exs

Zusätzliche Konfiguration

Erstellen Sie eine Konfigurationsdatei client-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.
Ein %Kameleoon.Client\{\} ist das Hauptobjekt zur Auswertung von Feature Flags, zum Hinzufügen von Besucherdaten und zum Senden von Tracking-Anfragen.
  • Es wird empfohlen, %Kameleoon.Client\{\} als Singleton-Objekt zu verwenden, da es die Brücke zwischen Ihrer Anwendung und der Kameleoon-Plattform bildet. Es stellt alle erforderlichen Methoden und Eigenschaften bereit, um Experimente effizient auszuführen.
  • Das Elixir SDK initialisiert sich über den nativen Core. Sie sollten initialize() aufrufen, bevor Sie sich im Produktivcode auf die Feature-Auswertung verlassen.

Aktivieren eines Feature Flags

Einem Benutzer eine eindeutige ID zuweisen
Um einem Benutzer eine eindeutige ID zuzuweisen, können Sie die Methode Client.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 Methode Client.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 Methode Client.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 Methode Client.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 Methode Client.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_id verwenden. Benutzerdefinierte Bucketing-Schlüssel sind entscheidend für A/B-Tests von Funktionen, die ein ganzes Team oder Unternehmen betreffen.
Durch die Implementierung eines benutzerdefinierten Bucketing-Schlüssels gewährleisten Sie eine höhere Konsistenz und Genauigkeit Ihrer Experimente, was zu verlässlicheren Ergebnissen und einer besseren Benutzererfahrung führt.

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 als CustomData-Objekt. Hier bezeichnet new_visitor_code den Bezeichner, den Sie für Ihr Bucketing verwenden möchten (z. B. die neue user_id oder account_id).
Damit der benutzerdefinierte Bucketing-Schlüssel korrekt funktioniert, muss er auch beim Erstellen oder Bearbeiten des Feature Flags definiert und konfiguriert werden. Ohne diese entsprechende Konfiguration wendet das SDK Ihren benutzerdefinierten Schlüssel nicht beim Bucketing an. Detaillierte Anweisungen zur Einrichtung in Kameleoon finden Sie in diesem Artikel.
  • Bucketing-Logik: Sobald ein benutzerdefinierter Bucketing-Schlüssel über die Methode Client.add_data bereitgestellt wurde, verwenden alle Hash-Berechnungen zur Zuweisung von Benutzern zu Variationen diesen new_visitor_code (Ihren benutzerdefinierten Schlüssel) anstelle des standardmäßigen visitor_code. Durch die Verwendung des new_visitor_code ist 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ünglichen visitor_code gesendet 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_id die 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 Methode Client.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 Sie CustomData, 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_data mit hinzugefügtem UniqueIdentifier(true) – um Daten für alle verknüpften Besucher abzurufen.
  • Client.track_conversion oder Client.flush mit hinzugefügtem UniqueIdentifier(true)-Datentyp – um bestimmte Daten für einen Besucher zu tracken, der mit einem anderen Besucher verknüpft ist.
Da die von Ihnen als Bezeichner verwendeten benutzerdefinierten Daten auf den Visitor-Scope gesetzt werden müssen, müssen Sie die geräteübergreifende Synchronisierung benutzerdefinierter Daten verwenden, um den Bezeichner auf jedem Gerät mit der Methode Client.get_remote_visitor_data abzurufen.
Hier ist ein Beispiel für die Verwendung benutzerdefinierter Daten zur Sitzungszusammenführung.
In diesem Beispiel verfügt die Anwendung über eine Anmeldeseite. Da die Benutzer-ID zum Zeitpunkt der Anmeldung unbekannt ist, wird ein anonymer Besucher-Bezeichner verwendet, der von der Methode 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.
Argumente
Rückgabewert
Fehler

initialize()

Wartet auf die Initialisierung des Kameleoon-Clients, entweder mit dem konfigurierten default_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 angegebenen site_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)
Bestimmt, ob ein Feature Flag für einen bestimmten Benutzer aktiv ist. Wenn der Besucher für dieses Feature Flag noch nicht ausgewertet wurde, wertet das SDK die Targeting-Regeln aus und gibt das Ergebnis zurück. Wenn der Besucher bereits über eine gespeicherte Auswertung für das Feature verfügt, verwendet das SDK das vorhandene Ergebnis erneut, um die Konsistenz zu gewährleisten.
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.
Die Methode Client.is_feature_active? wertet die ausgelieferte Variante aus, nicht den Master-Flag-Status. Wenn Sie Regeln ausschließen, verwendet die Methode den Standardstatus Dann allen anderen ausliefern. Wenn Sie für diesen Standardstatus Off auswählen, gibt die Methode immer false zurück, selbst wenn das Master-Feature-Flag On ist.
Argumente
Rückgabewert
Fehler

get_variation()

  • 📨 Sendet Tracking-Daten an Kameleoon (abhängig vom Parameter track)
Ruft die einem bestimmten Besucher für ein bestimmtes Feature Flag zugewiesene 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)
Ruft eine Map von 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_active auf true gesetzt ist, gibt die Methode Client.get_variations die Feature-Flag-Variationen zurück, sofern der Benutzer nicht der off-Variation zugeordnet ist.
  • Der Parameter track steuert, ob die Methode die Variationszuweisungen trackt. Standardmäßig ist er auf true gesetzt. Bei false wird das Tracking deaktiviert.
Die zurückgegebene Map enthält Feature-Flag-Schlüssel als Schlüssel und ihre entsprechenden 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 bestimmte Variation 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.
Eine erzwungene Variation wird genauso behandelt wie eine ausgewertete Variation. Sie wird in Analysen getrackt und im Benutzerkontext wie jede standardmäßig ausgewertete Variation gespeichert, um Konsistenz in den Berichten zu gewährleisten. Die Methode kann unter bestimmten Bedingungen Ausnahmen auslösen (z. B. ungültige Parameter, Benutzerkontext oder interne Probleme). Eine ordnungsgemäße Ausnahmebehandlung ist unerlässlich, um sicherzustellen, dass Ihre Anwendung stabil und widerstandsfähig bleibt.
Es ist wichtig, erzwungene Variationen von simulierten Variationen zu unterscheiden:
  • Erzwungene Variationen: Sind spezifisch für ein einzelnes Experiment.
  • Simulierte Variationen: Wirken sich auf das Gesamtergebnis des Feature Flags aus.
Argumente
Rückgabewert
Fehler

evaluate_audiences()

  • 📨 Sendet Tracking-Daten an Kameleoon
Diese Methode wertet Besucher gegen alle verfügbaren Audiences-Explorer-Segmente aus und trackt diejenigen, die übereinstimmen. 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()

Um alle Feature Flags auszuwerten, verwenden Sie Client.get_variations. Diese Methode ist effizienter als der Aufruf von DataFile und das Iterieren durch die Flags mit Client.get_variation.
Gibt die aktuelle SDK-Konfiguration als DataFile-Objekt zurück.
Rückgabewert
Fehler

Besucherdaten

get_visitor_code()

Verwenden Sie get_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:
  1. Das SDK prüft, ob über den bereitgestellten Accessor bereits ein kameleoonVisitorCode-Cookie verfügbar ist.
  2. Wenn das Cookie nicht vorhanden ist, verwendet das SDK den default_visitor_code, sofern Sie einen bereitstellen.
  3. Andernfalls generiert das SDK einen neuen Visitor Code und speichert ihn über den Accessor.
Weitere Informationen finden Sie unter Hybride Experimente.
Wenn Sie Ihren eigenen visitor_code angeben, muss dessen Eindeutigkeit auf Ihrer Seite gewährleistet sein. Beachten Sie außerdem, dass die Länge des visitor_code auf 255 Zeichen begrenzt ist.
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 kameleoonSimulationFFData manuell.
Es ist wichtig, simulierte Variationen von erzwungenen Variationen zu unterscheiden:
  • Simulierte Variationen: Wirken sich auf das Gesamtergebnis des Feature Flags aus.
  • Erzwungene Variationen: Sind spezifisch für ein einzelnes Experiment.
⚙️ Manuelle EinrichtungStellen Sie sicher, dass das Cookie kameleoonSimulationFFData dem folgenden Format entspricht:
  • kameleoonSimulationFFData={"featureKey":{"expId":10,"varId":20}}: Simuliert die Variation mit varId des Experiments expId für den angegebenen featureKey.
  • kameleoonSimulationFFData={"featureKey":{"expId":0}}: Simuliert die Standardvariation (definiert im Abschnitt Dann allen anderen in Production ausliefern) für den angegebenen featureKey.
⚠️ Um die ordnungsgemäße Funktionalität sicherzustellen, muss der Cookie-Wert als URI-Komponente kodiert werden, beispielsweise mit einer Methode wie encodeURIComponent.
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 Methode Client.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.
Jeder Besucher kann für die meisten Datentypen nur eine Instanz zugeordneter Daten haben. CustomData bildet jedoch eine Ausnahme. Besucher können pro Index eine Instanz von CustomData zugeordnet haben.
Argumente
Rückgabewert
Fehler

flush()

  • 📨 Sendet Tracking-Daten an Kameleoon
Die Methode 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.
  • flush() – Stellt einen Flush-Vorgang gemäß dem konfigurierten Tracking-Intervall in die Warteschlange.
  • flush_instant() – Sendet Tracking-Daten sofort, ohne auf das Intervall zu warten.
Argumente
Rückgabewert
Fehler

get_remote_data()

Mit der Methode get_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.
Lesen Sie diesen Artikel, um mögliche Anwendungsfälle besser zu verstehen.
Standardmäßig ruft get_remote_visitor_data() automatisch die zuletzt gespeicherten benutzerdefinierten Daten mit scope=Visitor ab und ordnet sie dem Besucher zu, ohne dass add_data() aufgerufen werden muss. Dies ist besonders nützlich für die Synchronisierung benutzerdefinierter Daten über mehrere Geräte hinweg.
Argumente
Rückgabewert
Fehler
Verwenden von Parametern in get_remote_visitor_data()
Mit der Methode get_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 angegebenen visitor_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
Sie müssen diese Methode verwenden, um anzugeben, ob der Besucher seine rechtliche Einwilligung zur Verwendung personenbezogener Daten gegeben hat. Wenn legal_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 Sie Client.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
Verwenden Sie diese Methode, um eine Konvertierung für ein bestimmtes Ziel und einen Benutzer zu tracken. Diese Methode erfordert 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.
Diese Methode ist nicht blockierend, da der Server-Aufruf asynchron erfolgt.
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 Methode Client.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 getVisitorCode aufrufen, sofern Sie die entsprechenden Experimentzuweisungen zu window.kameleoonQueue hinzufügen.
  • Sie können den zurückgegebenen Tracking-Code direkt in ein HTML-<script>-Tag einfügen.
In diesem Beispiel sind 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 Methode Client.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 unter Kameleoon.Data verfügbaren Elixir-Datentypen auf.

ApplicationVersion

ApplicationVersion stellt die semantische Versionsnummer Ihrer Anwendung dar.
Ein Besucher kann nur eine ApplicationVersion haben. Das Hinzufügen einer zweiten Instanz überschreibt die erste.

Browser

Der hier gespeicherte Datensatz Browser kann verwendet werden, um Experiment- und Personalisierungsberichte nach jedem damit verknüpften Wert zu filtern.

Conversion

Der hier gespeicherte Datensatz Conversion kann verwendet werden, um Experiment- und Personalisierungsberichte nach jedem damit verknüpften Ziel zu filtern.
  • Jeder Besucher kann mehrere Conversion-Objekte haben.
  • Sie finden die goal_id in der Kameleoon-App.
Cookie enthält Informationen über die auf dem Gerät des Besuchers gespeicherten Cookies.
Jeder Besucher kann nur ein Cookie haben. Das Hinzufügen eines zweiten Cookie überschreibt das erste.

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 CustomData für jeden eindeutigen index(name) erlaubt. Das Hinzufügen einer weiteren CustomData mit demselben index(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.
  • Jeder Besucher kann nur eine Geolocation haben. Das Hinzufügen einer zweiten Geolocation überschreibt die erste.

OperatingSystem

OperatingSystem enthält Informationen über das Betriebssystem auf dem Gerät des Besuchers.
Jeder Besucher kann nur ein OperatingSystem haben. Das Hinzufügen eines zweiten OperatingSystem überschreibt das erste.

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 keinen UniqueIdentifier 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 Feld UserAgent, 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

Das DataFile 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

Das FeatureFlag 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

Die Rule 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.
  • Variation beschreibt die zugewiesene oder Standardvariation, während Variable die Details jeder einzelnen Variable enthält.
  • id und experiment_id können nil sein, was eine Standardvariation kennzeichnet, die nicht an eine bestimmte Experimentzuweisung gebunden ist.
Zusätzliche Hilfsmethoden:

Variable

Variable enthält Informationen über eine Variable, die mit der zugewiesenen Variation verknüpft ist.