Skip to main content
Willkommen in der Entwicklerdokumentation für das Kameleoon C# SDK! Verwenden Sie unser SDK, um Experimente auf Ihrem Back-End .NET-Anwendungsserver auszuführen. Die Integration unseres SDK in Ihre Webanwendung ist einfach, und sein Speicher- und Netzwerkverbrauch ist gering. Erste Schritte: Hilfe zu den ersten Schritten finden Sie im Entwicklerhandbuch. SDK-Methoden: Die vollständige Referenzdokumentation der C# SDK-Methoden finden Sie im Abschnitt Referenz. Changelog: Aktuelle Version des C# SDK: 4.19.0 Changelog.

Entwicklerhandbuch

Erste Schritte

Dieses Handbuch wurde entwickelt, um Ihnen bei der Integration unseres SDK in Ihre C#-Anwendungen zu helfen.

Starter-Kit

Um Ihnen den Einstieg zu erleichtern, stellt Kameleoon ein Starter-Kit und eine Demo-Anwendung zum Testen des SDK bereit. Das Starter-Kit enthält eine vollständig konfigurierte App mit Beispielen, die zeigen, wie SDK-Methoden in einer App verwendet werden können. Das Starter-Kit, die Demo-Anwendung und detaillierte Anweisungen sind unter Starter kit for .NET verfügbar.

C#-Client installieren

Sie können die Paketmanager NuGet, .NET CLI oder Paket verwenden, um den C#-Client zu installieren.

Zusätzliche Konfiguration

Erstellen Sie eine .properties-Konfigurationsdatei, um Anmeldeinformationen bereitzustellen und das Verhalten des SDK anzupassen. Sie können auch eine Beispielkonfiguration herunterladen. Speichern Sie diese Datei im Standardpfad /etc/kameleoon/client-csharp.conf. Wenn Sie die Datei an einem anderen Ort ablegen, müssen Sie den Pfad als Argument an KameleoonClientFactory.Create() übergeben. Mit der aktuellen Version des C# SDK sind dies die verfügbaren Schlüssel:

Den Kameleoon-Client initialisieren

Nachdem Sie das SDK installiert und Ihre Anmeldeinformationen sowie das SDK-Verhalten konfiguriert haben, erstellen Sie den Kameleoon-Client in Ihrem Anwendungscode. Zum Beispiel:
Ein IKameleoonClient ist ein Singleton-Objekt, das Ihre App mit der Kameleoon-Plattform verbindet. Es enthält alle Methoden und Funktionen, die Sie zur Durchführung eines Experiments benötigen. Als Entwickler müssen Sie sicherstellen, dass Ihre App die richtige Logik für A/B-Tests mit Kameleoon verwendet. Es ist am besten, einen Besucher vom Experiment auszuschließen, wenn Sie es noch nicht gestartet haben. Der Ausschluss ist einfach, da dies zur Standardlogik für Variations passt.

Aktivieren eines feature flag

Einem Benutzer eine eindeutige ID zuweisen
Um einem Benutzer eine eindeutige ID zuzuweisen, können Sie die Methode GetVisitorCode() verwenden. Wenn ein visitor code nicht existiert (aus dem Cookie der Request-Header), generiert die Methode eine zufällige eindeutige ID oder verwendet einen defaultVisitorCode, den Sie generiert hätten. Die ID wird dann in einem Cookie der Response-Header festgelegt. Wenn Sie Kameleoon im Hybridmodus verwenden, stellt der Aufruf der Methode GetVisitorCode() sicher, dass die eindeutige ID (visitor code) zwischen der Anwendungsdatei engine.js (früher kameleoon.js) und dem SDK geteilt wird.
Eine Flag-Konfiguration abrufen
Um ein feature flag in Ihrem Code zu implementieren, müssen Sie zunächst das feature flag in Ihrem Kameleoon-Konto erstellen. Um den Status oder die Variation eines feature flag für einen bestimmten Benutzer zu ermitteln, sollten Sie die Methode GetVariation() oder IsFeatureActive() verwenden, um die Konfiguration basierend auf dem featureKey abzurufen. Die Methode GetVariation() verarbeitet sowohl einfache feature flags mit ON/OFF-Zuständen als auch komplexere flags mit mehreren Variations. 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 featureKey und dem visitorCode zurückgibt. Die Methode IsFeatureActive() kann verwendet werden, wenn Sie die Konfiguration eines einfachen feature flag abrufen möchten, das nur einen ON- oder OFF-Zustand hat, im Gegensatz zu komplexeren feature flags mit mehreren Variations oder Targeting-Optionen. Wenn Ihr feature flag zugehörige Variablen hat (wie bestimmte Verhaltensweisen, die an jede Variation gebunden sind), ermöglicht Ihnen GetVariation() auch den Zugriff auf das Variation-Objekt, das Details zur zugewiesenen Variation und dem zugehörigen Experiment liefert. Diese Methode prüft, ob der Benutzer angesprochen wird, findet die dem Besucher zugewiesene Variation und speichert sie im Speicher. Wenn track=true, sendet das SDK das Expositionsereignis bei der nächsten Tracking-Anfrage an das angegebene Experiment, die automatisch basierend auf dem tracking_interval_millisecond des SDK ausgelöst wird. Standardmäßig ist dieses Intervall auf 1000 Millisekunden (1 Sekunde) eingestellt. Die Methode GetVariation() ermöglicht es Ihnen zu steuern, ob das Tracking durchgeführt wird. Wenn track=false, werden vom SDK keine Expositionsereignisse gesendet. Dies ist nützlich, wenn Sie es vorziehen, keine Daten über das SDK zu verfolgen und stattdessen auf clientseitiges Tracking zu setzen, das z. B. vom Kameleoon-Engine verwaltet wird. Darüber hinaus ist die Einstellung track=false hilfreich, wenn Sie die Methode GetVariations() verwenden, bei der Sie möglicherweise nur die Variations 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 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 das Flag aktiv ist. Verwenden Sie die Methode AddData(), 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 GetRemoteVisitorData(). Diese Methode ruft Daten asynchron von den Servern ab. Es ist wichtig, GetRemoteVisitorData() vor dem Abrufen der Variation oder der Prüfung, ob das feature flag aktiv ist, aufzurufen, da diese Daten möglicherweise erforderlich sind, um einen Benutzer einer bestimmten Variation zuzuweisen. Um mehr über verfügbare Targeting-Bedingungen zu erfahren, lesen Sie den ausführlichen Artikel zum Thema. Darüber hinaus sind die Datenpunkte, die Sie dem 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 clientseitig, sodass es einfach ist, Ihre Ergebnisse anhand dieser vorgesammelten Datenpunkte aufzuschlüsseln. Die vollständige Liste finden Sie hier. Wenn Sie zusätzliche Datenpunkte über das hinaus verfolgen müssen, was automatisch gesammelt wird, können Sie die Custom Data-Funktion von Kameleoon verwenden. Custom Data ermöglicht es Ihnen, spezifische Informationen zu erfassen und zu 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 zu gewährleisten, wird empfohlen, Bots herauszufiltern, indem Sie den Datentyp UserAgent verwenden.
Ziel-Conversions verfolgen
Wenn ein Benutzer eine gewünschte Aktion abschließt (z. B. einen Kauf tätigt), wird dies als Conversion aufgezeichnet. Um Conversions zu verfolgen, verwenden Sie die Methode TrackConversion() und geben Sie die erforderlichen Parameter visitorCode und goalId an. Die Conversion-Tracking-Anfrage wird zusammen mit der nächsten geplanten Tracking-Anfrage gesendet, die das SDK in regelmäßigen Abständen sendet (definiert durch tracking_interval_millisecond). Wenn Sie die Anfrage sofort senden möchten, verwenden Sie die Methode Flush() mit dem Parameter instant=true.
Ereignisse an Analyselösungen senden
Um Conversions zu verfolgen und Expositionsereignisse an Ihre Kundenanalyselösung zu senden, müssen Sie zunächst Kameleoon im Hybridmodus implementieren. Verwenden Sie dann die Methode GetEngineTrackingCode(). Die Methode GetEngineTrackingCode() ruft den eindeutigen Tracking-Code ab, der zum Senden von Expositionsereignissen an Ihre Analyselösung erforderlich ist. Mit dieser Methode können Sie Ereignisse aufzeichnen und an die gewünschte Analyseplattform senden.

Cross-Device-Experimente

Um Besucher zu unterstützen, die von mehreren Geräten aus auf eine App zugreifen, ermöglicht Kameleoon die Synchronisierung zuvor gesammelter Besucherdaten über jedes der Geräte des Besuchers hinweg und die Abstimmung ihres Besuchsverlaufs zwischen Geräten durch Cross-Device-Experimente. Fallstudien und detaillierte Informationen darüber, wie Kameleoon Daten geräteübergreifend verarbeitet, finden Sie im Artikel über Cross-Device-Experimente.

Custom Data geräteübergreifend synchronisieren

Obwohl die Synchronisierung benutzerdefinierter Zuordnungen verwendet wird, um Besucherdaten zwischen Geräten abzugleichen, ist sie nicht immer erforderlich. Im Folgenden finden Sie zwei Szenarien, in denen eine Synchronisierung benutzerdefinierter Zuordnungen nicht erforderlich ist: Dieselbe Benutzer-ID auf allen Geräten Wenn dieselbe Benutzer-ID konsistent auf allen Geräten verwendet wird, wird die Synchronisierung automatisch ohne Synchronisierung der benutzerdefinierten Zuordnung gehandhabt. Es genügt, die Methode GetRemoteVisitorData() aufzurufen, wenn Sie die zwischen mehreren Geräten gesammelten Daten synchronisieren möchten. Multi-Server-Instanzen mit konsistenten IDs In komplexen Setups, die mehrere Server umfassen (z. B. verteilte Server-Instanzen), bei denen dieselbe Benutzer-ID serverübergreifend verfügbar ist, ist die Synchronisierung zwischen Servern (mit GetRemoteVisitorData()) ohne zusätzliche Synchronisierung der benutzerdefinierten Zuordnung ausreichend. Kunden, die zusätzliche Daten benötigen, können sich an die Beschreibung der Methode GetRemoteVisitorData() wenden, um weitere Anleitungen zu erhalten. Im folgenden Code wird angenommen, dass derselbe eindeutige Bezeichner (in diesem Fall der visitorCode, der auch als userId bezeichnet werden kann) konsistent zwischen den beiden Geräten für eine genaue Datenabfrage verwendet wird.
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

Custom Data für Sitzungszusammenführung verwenden

Cross-Device-Experimente ermöglichen das Kombinieren des Verlaufs eines Besuchers über jedes seiner Geräte hinweg (Verlaufsabstimmung). Die Verlaufsabstimmung ermöglicht das Zusammenführen verschiedener Besuchersitzungen zu einer. Um den Besuchsverlauf abzugleichen, verwenden Sie CustomData, um eine eindeutige Kennung für den Besucher bereitzustellen. Weitere Informationen finden Sie in der zugehörigen Dokumentation. Nachdem die geräteübergreifende Abstimmung aktiviert wurde, ruft der Aufruf von GetRemoteVisitorData() mit dem Parameter userId alle bekannten Daten für einen bestimmten Benutzer ab. Sitzungen mit derselben Kennung werden in einem Experiment immer dieselbe Variation sehen. In der Besucher-Ansicht der Ergebnisseiten Ihres Experiments erscheinen diese Sitzungen als ein einzelner 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 Variation-Zuweisung. Diese Einschränkungen sind hier beschrieben. Folgen Sie dem Leitfaden activating cross-device history reconciliation, um Ihre Custom Data auf der Kameleoon-Plattform einzurichten. Anschließend können Sie das SDK normal verwenden. Die folgenden Methoden können im Zusammenhang mit der Sitzungszusammenführung hilfreich sein:
  • GetRemoteVisitorData() mit hinzugefügtem UniqueIdentifier(true) - um Daten für alle verknüpften Besucher abzurufen.
  • TrackConversion() oder Flush() mit hinzugefügten UniqueIdentifier(true)-Daten - um einige Daten für einen bestimmten Besucher zu verfolgen, der mit einem anderen Besucher verknüpft ist.
Da die Custom Data, die Sie als Kennung verwenden, auf Visitor scope gesetzt sein muss, müssen Sie die geräteübergreifende Custom Data-Synchronisierung verwenden, um die Kennung mit der Methode GetRemoteVisitorData() auf jedem Gerät abzurufen.
Hier ist ein Beispiel für die Verwendung von Custom Data für die Sitzungszusammenführung.
In diesem Beispiel hat die Anwendung eine Login-Seite. Da die Benutzer-ID zum Zeitpunkt der Anmeldung unbekannt ist, wird eine anonyme Besucherkennung verwendet, die von der Methode GetVisitorCode() generiert wurde. Nachdem sich der Benutzer angemeldet hat, wird der anonyme Besucher mit der Benutzer-ID verknüpft und als eindeutige Kennung für den Besucher verwendet.

Einen benutzerdefinierten Bucketing-Schlüssel verwenden

Standardmäßig verwendet Kameleoon eine eindeutige, anonyme Besucher-ID (visitorCode), um Benutzer feature flag-Variations zuzuweisen. Diese ID wird normalerweise auf dem Gerät des Benutzers generiert und gespeichert (in einem Browser-Cookie für clientseitige und serverseitige SDKs – in dauerhaftem Speicher für mobile SDKs). In bestimmten Szenarien müssen Sie jedoch möglicherweise sicherstellen, dass alle Benutzer derselben Organisation dieselbe Variante eines feature flag sehen. Die Option Custom Bucketing Key ermöglicht es Ihnen, dieses Standardverhalten zu überschreiben, indem Sie Ihre eigene benutzerdefinierte Kennung für das Bucketing bereitstellen. Diese Überschreibung stellt sicher, dass die Zuweisungslogik von Kameleoon Ihren angegebenen Schlüssel anstelle des Standard-visitorCode verwendet.

Anwendungsfälle

Die Verwendung eines benutzerdefinierten Bucketing-Schlüssels ist unerlässlich, um Konsistenz und Genauigkeit Ihrer feature flag-Zuweisungen zu wahren, 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 eine Kennung wie eine accountId verwenden. Benutzerdefinierte Bucketing-Schlüssel sind entscheidend für A/B-Tests von Funktionen, die ein gesamtes Team oder Unternehmen betreffen.
Durch die Implementierung eines benutzerdefinierten Bucketing-Schlüssels gewährleisten Sie eine größere Konsistenz und Genauigkeit in Ihren Experimenten, was zu zuverlässigeren Ergebnissen und einer besseren Benutzererfahrung führt.

Technische Details

Wenn Sie einen benutzerdefinierten Bucketing-Schlüssel für ein feature flag konfigurieren, stellen Sie Kameleoon eine bestimmte Kennung aus den Daten Ihrer Anwendung zur Verfügung:
  • Bereitstellung des benutzerdefinierten Schlüssels: Sie übergeben Ihre benutzerdefinierte Kennung mit der Methode AddData() an das Kameleoon SDK. In dieser Methode übergeben Sie Ihren gewählten benutzerdefinierten Bucketing-Schlüssel als CustomData-Objekt. Hier bezieht sich newVisitorCode auf die Kennung, die Sie für Ihr Bucketing verwenden möchten (z. B. die neue userId oder accountId).
Damit der benutzerdefinierte Bucketing-Schlüssel korrekt funktioniert, muss er auch während des Prozesses der Flag-Erstellung oder -Bearbeitung für das feature flag definiert und konfiguriert werden. Ohne diese entsprechende Konfiguration wendet das Bucketing des SDK Ihren benutzerdefinierten Schlüssel nicht an. Detaillierte Anweisungen zum Einrichten in Kameleoon finden Sie in diesem Artikel.
  • Bucketing-Logik: Sobald ein benutzerdefinierter Bucketing-Schlüssel über die Methode AddData() bereitgestellt wird, verwenden alle Hash-Berechnungen zur Zuweisung von Benutzern zu Variations diesen newVisitorCode (Ihren benutzerdefinierten Schlüssel) anstelle des Standard-visitorCode. Die Verwendung des newVisitorCode bedeutet, dass die Bucketing-Entscheidung an Ihre benutzerdefinierte Kennung gebunden ist, was konsistente Zuweisungen über verschiedene Kontexte hinweg gewährleistet, in denen diese Kennung vorhanden ist.
  • Datenverfolgung und Analyse: Es ist wichtig zu beachten, dass zwar der newVisitorCode (Ihr benutzerdefinierter Schlüssel) für Bucketing-Entscheidungen verwendet wird, alle nachfolgenden Daten (z. B. Tracking-Ereignisse und Conversions) jedoch gesendet und mit dem ursprünglichen visitorCode verknüpft werden. Diese Trennung stellt sicher, dass Ihre Analysen die individuellen Benutzerreisen und Interaktionen im breiteren Kontext Ihres Experiments genau widerspiegeln, auch wenn das Bucketing auf einer höheren Ebene (wie einem Konto) oder über mehrere Geräte/Sitzungen hinweg durchgeführt wird. Ihre ursprünglichen Besucherdaten bleiben für umfassende Berichte unverändert.

Technische Anforderungen

Um einen benutzerdefinierten Bucketing-Schlüssel effektiv zu verwenden:
  • Der Schlüssel muss ein string sein.
  • Er muss für die Entität, die Sie bucketen möchten, eindeutig sein (z. B. wenn Sie eine userId verwenden, sollte die ID jedes Benutzers eindeutig sein).
  • Der Schlüssel muss dem SDK genau zu dem Zeitpunkt zur Verfügung stehen, an 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 zum Targeting von Benutzern in Ihren Kampagnen verwenden können. Die Liste der von diesem SDK unterstützten Bedingungen finden Sie unter use visit history to target users. Sie können auch Ihre eigenen externen Daten zum Targeting von Benutzern verwenden.

Protokollierung

Das SDK generiert Logs, um verschiedene interne Prozesse und Probleme widerzuspiegeln.

Log-Level

Das SDK unterstützt die Konfiguration der Begrenzung der Protokollierung durch ein Log-Level.

Benutzerdefinierte Behandlung von Logs

Das SDK schreibt seine Logs standardmäßig in die Konsolenausgabe. Dieses Verhalten kann überschrieben werden.
Die Begrenzung der Protokollierung durch ein Log-Level erfolgt unabhängig von der Logik der Log-Behandlung.

Referenz

Dies ist die vollständige Referenzdokumentation des C# SDK.

Initialisierung

Create()

Um das SDK zu verwenden, müssen Sie es initialisieren. Ihre App interagiert mit dem SDK über die Klasse KameleoonClient, die in Kameleoon.IKameleoonClient zu finden ist. Sie können dieses Objekt mit der statischen Methode Kameleoon.KameleoonClientFactory Create() erstellen.
Argumente
Rückgabewert
Ausgelöste Ausnahmen

WaitInit()

WaitInit() wartet auf die Initialisierung des Kameleoon-Clients. Mit dieser Methode können Sie überprüfen, ob der Client erfolgreich initialisiert wurde, bevor Sie mit anderen Operationen fortfahren.
Rückgabewert
Ausgelöste Ausnahmen

Feature flags und Variations

IsFeatureActive()

  • 📨 Sendet Tracking-Daten an Kameleoon (abhängig vom Parameter track)
Diese Methode hieß zuvor ActivateFeature, die in der SDK-Version 4.0.0 entfernt wurde.
Um einen Feature-Toggle zu aktivieren, rufen Sie die Methode IsFeatureActive auf. Diese Methode erfordert einen visitorCode und einen featureKey (oder featureID), um zu prüfen, ob ein Benutzer auf eine bestimmte Funktion zugreifen kann. Wenn der Benutzer noch nie mit dieser Funktion verknüpft wurde, entscheidet das SDK zufällig, ob es sie aktiviert, und gibt entweder true (der Benutzer kann auf die Funktion zugreifen) oder false (der Benutzer kann nicht zugreifen) zurück. Wenn der Benutzer mit dem angegebenen visitorCode bereits mit dieser Funktion verknüpft ist, gibt das System den vorherigen Wert des featureFlag zurück. Stellen Sie sicher, dass Sie in Ihrem Code eine angemessene Fehlerbehandlung einbeziehen, wie im Beispiel gezeigt, um potenzielle Fehler abzufangen. Wenn Sie einen visitorCode angeben, verwendet die Methode IsFeatureActive() ihn als eindeutige Besucherkennung, was für Cross-Device-Experimente nützlich ist. Wenn Sie einen visitorCode angeben und den Parameter isUniqueIdentifier auf true setzen, verknüpft das SDK die geleerten Daten mit dem Besucher, der mit der angegebenen Kennung verknüpft ist.
Der Parameter isUniqueIdentifier ist veraltet. Verwenden Sie stattdessen UniqueIdentifier.Der isUniqueIdentifier kann in besonderen Situationen hilfreich sein; zum Beispiel, wenn Sie nicht auf den anonymen visitorCode zugreifen können, der einem Besucher zugewiesen wurde, aber eine interne ID verwenden können, die durch Sitzungszusammenführung mit diesem Besucher verknüpft ist.
Kameleoon verwendet Tracking, um Sitzungen und Besucher zu zählen, wenn Sie bestimmte Methoden aufrufen, z. B. IsFeatureActive(), GetVariation() oder GetVariations().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 dann auf false, wenn Sie diese Methoden aufrufen, bevor Sie Besucher aussetzen.Wenn Sie beispielsweise GetVariations() aufrufen, um alle Variations 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 Tracking-Daten standardmäßig jede Sekunde. Sie können dieses Intervall mit der Tracking-Intervall-Konfigurationsoption auf bis zu fünf Sekunden konfigurieren. Kameleoon gruppiert Tracking-Ereignisse in einer einzigen Sitzung, solange das Intervall zwischen Ereignissen weniger als 30 Minuten beträgt. Wenn mehr als 30 Minuten zwischen Tracking-Ereignissen vergehen, zählt Kameleoon die Ereignisse als separate Sitzungen. Ein Besuch erscheint 30 Minuten nach dem letzten aufgezeichneten Ereignis in der Sitzung in Ihren Berichten.
Die Methode IsFeatureActive() bewertet die ausgelieferte Variante, nicht den Status des Master-Flags. Wenn Sie Regeln ausschließen, verwendet die Methode den Standardzustand Then, for everyone else serve. Wenn Sie für diesen Standardzustand Off auswählen, gibt die Methode immer false zurück, selbst wenn das Master-feature flag On ist.
Argumente
Rückgabewert
Ausgelöste Ausnahmen

GetVariation()

  • 📨 Sendet Tracking-Daten an Kameleoon (abhängig vom Parameter track)
Ruft die Variation ab, die einem bestimmten Besucher für ein bestimmtes feature flag zugewiesen ist. Diese Methode nimmt visitorCode und featureKey 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 mit keinen feature flag-Regeln verknüpft ist, gibt die Methode die Standard-Variation für das angegebene feature flag zurück. Stellen Sie sicher, dass in Ihrem Code eine angemessene Fehlerbehandlung implementiert ist, um potenzielle Ausnahmen zu verwalten.
Die Standard-Variation bezieht sich auf die Variation, die einem Besucher zugewiesen wird, wenn er keine vordefinierten Delivery-Regeln für ein feature flag erfüllt. 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 Verwaltungsoberfläche dargestellt.
Argumente
Rückgabewert
Ausgelöste Ausnahmen

GetVariations()

  • 📨 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 mit dem angegebenen Besucher verknüpft ist. Sie nimmt visitorCode als obligatorisches Argument, während onlyActive und track optional sind.
  • Wenn onlyActive auf true gesetzt ist, gibt die Methode GetVariations() die feature flag-Variations zurück, sofern der Benutzer nicht mit der Variation off gebucketet ist.
  • Der Parameter track steuert, ob die Methode die Variation-Zuweisungen verfolgt. Standardmäßig ist er auf true gesetzt. Wenn er auf false gesetzt ist, wird das Tracking deaktiviert.
Die zurückgegebene Map besteht aus feature flag-Schlüsseln als Schlüssel und ihrer entsprechenden Variation als Werte. Wenn keine Variation für ein feature flag zugewiesen ist, gibt die Methode die Standard-Variation für dieses flag zurück. Eine angemessene Fehlerbehandlung sollte implementiert werden, um potenzielle Ausnahmen zu verwalten.
Die Standard-Variation bezieht sich auf die Variation, die einem Besucher zugewiesen wird, wenn er keine vordefinierten Delivery-Regeln für ein feature flag erfüllt. 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 Verwaltungsoberfläche dargestellt.
Argumente
Rückgabewert
Ausgelöste Ausnahmen

GetFeatureList()

Diese Methode hieß zuvor ObtainFeatureList(), die in der SDK-Version 4.0.0 entfernt wurde.
Gibt eine Liste der feature flag-Schlüssel zurück, die derzeit für das SDK verfügbar sind.
Rückgabewert

SetForcedVariation()

Mit dieser Methode können Sie einem Benutzer programmgesteuert eine bestimmte Variation zuweisen und dabei den Standard-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 forcierte 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 forceTargeting=false.
Simulierte Variations haben in der Ausführungsreihenfolge immer Vorrang. Wenn eine simulierte Variation-Berechnung ausgelöst wird, wird sie zuerst vollständig verarbeitet und abgeschlossen.
Eine forcierte Variation wird genauso behandelt wie eine ausgewertete Variation. Sie wird in Analysen verfolgt und im Benutzerkontext wie jede standardmäßig ausgewertete Variation gespeichert, was die Konsistenz in der Berichterstattung gewährleistet. Die Methode kann unter bestimmten Bedingungen Ausnahmen auslösen (z. B. ungültige Parameter, Benutzerkontext oder interne Probleme). Eine angemessene Ausnahmebehandlung ist unerlässlich, um sicherzustellen, dass Ihre Anwendung stabil und widerstandsfähig bleibt.
Es ist wichtig, forcierte Variations von simulierten Variations zu unterscheiden:
  • Forcierte Variations: Sind spezifisch für ein einzelnes Experiment.
  • Simulierte Variations: Beeinflussen das Gesamtergebnis des feature flag.
Argumente
Ausgelöste Ausnahmen
In den meisten Fällen muss nur der grundlegende Fehler KameleoonException behandelt werden, wie im Beispiel gezeigt. Wenn jedoch unterschiedliche Arten von Fehlern eine Reaktion erfordern, behandeln Sie jeden basierend auf den spezifischen Anforderungen separat. Darüber hinaus können für erhöhte Zuverlässigkeit allgemeine Sprachfehler durch das Einbeziehen von Exception behandelt werden.

EvaluateAudiences()

  • 📨 Sendet Tracking-Daten an Kameleoon
Diese Methode wertet Besucher anhand aller verfügbaren Audiences Explorer-Segmente aus und verfolgt diejenigen, die übereinstimmen. EvaluateAudiences() sollte aufgerufen werden, nachdem alle relevanten Besucherdaten gesetzt oder aktualisiert wurden, und kurz vor dem Abrufen einer Feature-Variation oder dem Prüfen eines feature flag. Dieser Ansatz stellt sicher, dass der Besucher anhand der aktuellsten verfügbaren Daten ausgewertet wird, was eine genaue Zielgruppenzuordnung basierend auf allen Kriterien ermöglicht. Nach dem Aufruf dieser Methode können Sie eine detaillierte Analyse der Segmentleistung im Audiences Explorer durchführen.
Argumente
Ausgelöste Ausnahmen
In den meisten Fällen muss nur der grundlegende Fehler KameleoonException behandelt werden, wie im Beispiel gezeigt. Wenn jedoch unterschiedliche Arten von Fehlern eine Reaktion erfordern, behandeln Sie jeden basierend auf den spezifischen Anforderungen separat. Darüber hinaus können für erhöhte Zuverlässigkeit allgemeine Sprachfehler durch das Einbeziehen von Exception behandelt werden.

GetDataFile()

Rückgabewert

Besucherdaten

GetVisitorCode()

Diese Methode hieß zuvor ObtainVisitorCode, die in der SDK-Version 4.0.0 entfernt wurde.
Um den Kameleoon-visitorCode für den aktuellen Besucher zu erhalten, verwenden Sie die Methode GetVisitorCode(). Diese Methode ist in Umgebungen, in denen Front-End- und Back-End-Systeme Benutzer konsistent identifizieren müssen, von entscheidender Bedeutung. So funktioniert es:
  1. Suchen Sie nach einem kameleoonVisitorCode-Cookie oder Abfrageparameter in der aktuellen HTTP-Anfrage. Wenn Sie eines finden, verwenden Sie dies als Besucherkennung und überspringen Sie den nächsten Schritt.
  2. Wenn Sie kein Cookie oder keinen Parameter finden, erstellen Sie entweder zufällig eine neue Kennung oder verwenden Sie das Argument defaultVisitorCode, falls es bereitgestellt wird. Auf diese Weise können Sie Ihre Kennungen als Visitor-Codes verwenden, was die Verknüpfung von Kameleoon-Besuchern mit Ihren eigenen Benutzern erleichtert, ohne dass zusätzliche Lookups erforderlich sind.
  3. Setzen Sie das serverseitige kameleoonVisitorCode-Cookie mit dem Kennungswert. Die Methode gibt diesen Kennungswert zurück.
Wenn Sie Ihren eigenen visitorCode angeben, stellen Sie sicher, dass er eindeutig ist! Beachten Sie auch, dass die Länge des visitorCode auf 255 Zeichen begrenzt ist. Die Verwendung einer Kennung mit zu vielen Zeichen führt zu einer Ausnahme.
Mit der Methode GetVisitorCode() können Sie simulierte Variations für einen Besucher festlegen. Wenn Cookies (aus einer Anfrage 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): Wenn Sie Kameleoon Web Experimentation oder das SDK im Hybridmodus verwenden, wird das Cookie automatisch erstellt, wenn die Anzeige einer Variante mit dem Simulation Panel simuliert wird.
  • Manuell: Setzen Sie das kameleoonSimulationFFData-Cookie manuell.
Es ist wichtig, simulierte Variations von forcierten Variations zu unterscheiden:
  • Simulierte Variations: Beeinflussen das Gesamtergebnis des feature flag.
  • Forcierte Variations: Sind spezifisch für ein einzelnes Experiment.
⚙️ Manuelles SetupBitte stellen Sie sicher, dass das kameleoonSimulationFFData-Cookie diesem Format folgt:
  • 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 Standard-Variation (definiert im Abschnitt Then, for everyone else in Production, serve) für den angegebenen featureKey.
⚠️ Um die ordnungsgemäße Funktionalität zu gewährleisten, muss der Cookie-Wert als URI-Komponente kodiert werden, indem eine Methode wie encodeURIComponent verwendet wird.
Argumente
Rückgabewert
Ausgelöste Ausnahmen

AddData()

Die Methode AddData() 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. Die Methode AddData() gibt keinen Wert zurück und interagiert allein nicht mit den Kameleoon-Back-End-Servern. Stattdessen werden alle deklarierten Daten für die zukünftige Übertragung mit der Methode Flush() gespeichert. Dieser Ansatz reduziert die Anzahl der getätigten Serveraufrufe, da die Daten in der Regel in einem einzigen Serveraufruf gruppiert werden, der durch Flush() ausgelöst wird. Die Methode TrackConversion() sendet ebenfalls alle zuvor verknüpften Daten, genau wie Flush(). Das Gleiche gilt für die Methoden GetVariation() und GetVariations(), wenn eine Experimentierregel ausgelöst wird.
Jeder Besucher kann für die meisten Datentypen nur eine Instanz von verknüpften Daten haben. CustomData ist jedoch eine Ausnahme. Besucher können eine Instanz von verknüpften CustomData pro Index haben.
Argumente
Ausnahmen

Flush()

  • 📨 Sendet Tracking-Daten an Kameleoon
Die Methode Flush() sammelt die mit dem Besucher verknüpften Kameleoon-Daten. Sie sendet dann eine Tracking-Anfrage zusammen mit allen zuvor mit der Methode AddData hinzugefügten Daten, die noch nicht mit einer dieser Methoden gesendet wurden. Flush() ist nicht blockierend, da der Server-Aufruf asynchron erfolgt. Flush() ermöglicht es Ihnen zu steuern, wann die mit einem bestimmten visitorCode verknüpften Daten an unsere Server gesendet werden. Wenn Sie beispielsweise AddData() ein Dutzend Mal aufrufen, wäre es ineffizient, nach jedem Aufruf von AddData() Daten an den Server zu senden. Sie müssen also Flush() nur einmal am Ende aufrufen. Wenn Sie einen visitorCode angeben, verwendet die Methode Flush() ihn als eindeutige Besucherkennung, was für Cross-Device-Experimente nützlich ist. Wenn Sie einen visitorCode angeben und den Parameter isUniqueIdentifier auf true setzen, verknüpft das SDK die geleerten Daten mit dem Besucher, der mit der angegebenen Kennung verknüpft ist.
Der Parameter isUniqueIdentifier ist veraltet. Verwenden Sie stattdessen UniqueIdentifier.Der isUniqueIdentifier kann in besonderen Situationen hilfreich sein; zum Beispiel, wenn Sie nicht auf den anonymen visitorCode zugreifen können, der einem Besucher zugewiesen wurde, aber eine interne ID verwenden können, die durch Sitzungszusammenführung mit diesem Besucher verknüpft ist.
Argumente

GetRemoteData()

Diese Methode hieß zuvor RetrieveDataFromRemoteSource, die in der SDK-Version 4.0.0 entfernt wurde.
GetRemoteData() ist eine Methode, mit der Sie Daten für einen bestimmten siteCode (festgelegt in KameleoonClientFactory.create()) von einem entfernten Kameleoon-Server mit einem von Ihnen bereitgestellten Schlüssel abrufen können. Unsere Data API speichert diese Daten auf unseren Servern, die für die effiziente Verarbeitung großer Datenmengen ausgelegt sind. Beachten Sie, dass diese Methode aufgrund eines Server-Aufrufs asynchron arbeitet.
Argumente
Rückgabewert
Ausgelöste Ausnahmen

GetRemoteVisitorData()

GetRemoteVisitorData() ist eine Methode, die Kameleoon-Besuchsdaten für einen bestimmten Benutzer mit seinem VisitorCode abruft. Sie arbeitet im Hintergrund und speichert diese Daten, damit andere Methoden Targeting-Entscheidungen treffen können. Diese Daten sind aus mehreren Gründen wichtig:
  • Sie helfen Ihnen, Informationen zu verwenden, die von verschiedenen Geräten gesammelt wurden.
  • Sie ermöglichen Ihnen den Zugriff auf den Verlauf eines Benutzers, z. B. zuvor besuchte Seiten aus früheren Besuchen.
  • Sie ermöglichen Ihnen die Verwendung von Daten, die nur auf der Client-Seite verfügbar sind, wie z. B. Datalayer-Variablen und Ziele, die Conversions nur im Front-End verfolgen.
Lesen Sie diesen Artikel für ein besseres Verständnis möglicher Anwendungsfälle.
Standardmäßig ruft GetRemoteVisitorData() automatisch die neuesten gespeicherten Custom Data mit Scope=Visitor ab und hängt sie an den Besucher an, ohne dass die Methode AddData() aufgerufen werden muss. Dies ist besonders nützlich für die Synchronisierung von Custom Data zwischen mehreren Geräten.
Der Parameter isUniqueIdentifier ist veraltet. Verwenden Sie stattdessen UniqueIdentifier.Der isUniqueIdentifier kann in besonderen Situationen hilfreich sein; zum Beispiel, wenn Sie nicht auf den anonymen visitorCode zugreifen können, der einem Besucher zugewiesen wurde, aber eine interne ID verwenden können, die durch Sitzungszusammenführung mit diesem Besucher verknüpft ist.
Argumente
Rückgabewert
Ausgelöste Ausnahmen
Verwendung von Parametern in GetRemoteVisitorData()
Die Methode GetRemoteVisitorData() bietet Flexibilität, indem sie es Ihnen ermöglicht, verschiedene Parameter beim Abrufen von Besucherdaten zu definieren. Egal, ob Sie auf der Grundlage von Zielen, Experimenten oder Variations zielen, der gleiche Ansatz gilt für alle Datentypen. Angenommen, Sie möchten Daten zu Besuchern abrufen, die ein Ziel “Order transaction” abgeschlossen haben. Sie können Parameter innerhalb der Methode GetRemoteVisitorData() angeben, um Ihr Targeting zu verfeinern. Wenn Sie beispielsweise nur Benutzer ansprechen möchten, die bei ihren letzten fünf Besuchen auf das Ziel konvertiert haben, können Sie den Parameter PreviousVisitAmount auf 5 und Conversions auf true setzen. Die in diesem Beispiel gezeigte Flexibilität ist nicht auf Zieldaten beschränkt. Sie können Parameter innerhalb der Methode GetRemoteVisitorData() verwenden, um Daten zu einer Vielzahl von Besucherverhaltensweisen abzurufen.
Hier ist die Liste der verfügbaren Kameleoon.Types.RemoteVisitorDataFilter-Optionen:

GetVisitorWarehouseAudience()

Diese Methode ruft alle mit dem Besucher in Ihrem Data Warehouse verknüpften Zielgruppendaten unter Verwendung der angegebenen visitorCode und warehouseKey ab. Der warehouseKey ist normalerweise Ihre interne Benutzer-ID. Der Parameter customDataIndex entspricht den Kameleoon-Custom-Data, die Kameleoon zum Targeting Ihrer Besucher verwendet. Weitere Details finden Sie in der Warehouse-Targeting-Dokumentation. Die Methode gibt ein CustomData-Objekt zurück, das bestätigt, dass die Daten zum Besucher hinzugefügt wurden und für Targeting-Zwecke verfügbar sind.
Argumente
Rückgabewert
Ausgelöste Ausnahmen

SetLegalConsent()

Sie müssen diese Methode verwenden, um anzugeben, ob der Besucher seine rechtliche Zustimmung zur Verwendung personenbezogener Daten gegeben hat. Das Setzen des Parameters legalConsent auf false begrenzt die Datentypen, die Sie in Tracking-Anfragen einbeziehen können. Diese Methode hilft Ihnen, gesetzliche und behördliche Anforderungen einzuhalten und gleichzeitig Besucherdaten verantwortungsvoll zu verwalten. Weitere Informationen zu personenbezogenen Daten finden Sie in der Consent-Management-Richtlinie.
Argumente
Ausgelöste Ausnahmen
Verhalten beim Widerruf der Zustimmung
Wenn Sie setLegalConsent() 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 bestehen bleibt, bis es auf natürliche Weise abläuft. Wenn Ihre Compliance-Anforderungen die sofortige Entfernung der Cookie-Datei nach dem Opt-out verlangen, 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

TrackConversion()

  • 📨 Sendet Tracking-Daten an Kameleoon
Verwenden Sie diese Methode, um eine Conversion für ein bestimmtes Ziel und einen bestimmten Benutzer zu verfolgen. Diese Methode erfordert visitorCode und goalId. Darüber hinaus akzeptiert diese Methode auch die optionalen Argumente revenue, negative und metadata. Der visitorCode ist in der Regel identisch mit dem, der beim Auslösen des Experiments verwendet wurde. Die Methode TrackConversion() gibt keinen Wert zurück. Diese Methode ist nicht blockierend, da der Server-Aufruf asynchron erfolgt.
Der Parameter isUniqueIdentifier ist veraltet. Verwenden Sie stattdessen UniqueIdentifier.Der isUniqueIdentifier kann auch in anderen Sonderfällen nützlich sein, z. B. wenn Sie nicht auf den anonymen visitorCode zugreifen können, der dem Besucher ursprünglich zugewiesen wurde, aber Zugriff auf eine interne ID haben, die mit dem anonymen Besucher über Sitzungszusammenführungsfunktionen verbunden ist.
Argumente
Metadata-Werte sind über Rohdaten-Exporte und die Ergebnisseite zugänglich.Wenn der Parameter metadata angegeben wird, verwendet Kameleoon diese angegebenen Werte für die aktuelle Conversion anstelle dessen, was zuvor mit der Methode AddData() gesammelt wurde. Wenn der Parameter weggelassen wird, verwendet Kameleoon die zuletzt verfolgten Werte für diese CustomData vor der Conversion und innerhalb des gleichen Besuchs.Kameleoon berücksichtigt nur die Metadata-Werte, die explizit als Parameter an die Methode TrackConversion() übergeben werden.Im folgenden Beispiel verknüpft Kameleoon die Conversion nur mit dem Custom-Data-Wert, der explizit als Parameter angegeben wurde (hier: Index 5 mit dem Wert ‘Amex Credit Card’).
Ausnahmen

GetEngineTrackingCode()

Kameleoon integriert sich mit mehreren Analyselösungen, darunter Mixpanel, Google Analytics 4 und Segment. Um serverseitige Experimente korrekt zu verfolgen, rufen Sie die Methode GetEngineTrackingCode() auf, nachdem der Besucher ein Experiment ausgelöst hat. Das SDK gibt JavaScript-Queue-Befehle 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 Analyse-Integration. Weitere Informationen zur Implementierung dieser Methode finden Sie unter hybride Experimentierung.
  • Um diese Funktion zu verwenden, implementieren Sie sowohl das C# SDK als auch Kameleoon Engine.js. Da Engine.js in diesem Fluss nur zum Tracking verwendet wird, können Sie das asynchrone Tag vor dem schließenden </body>-Tag installieren.
  • Wenn Sie nur Experimente in Kameleoon verfolgen möchten und keine Expositionsereignisse an Drittanbieter-Analysetools senden müssen, verwenden Sie das JavaScript / TypeScript SDK. Diese Option eignet sich gut für serverlose Edge-Compute-Plattformen. Das JavaScript / TypeScript SDK verfolgt automatisch Variations, wenn Sie getVisitorCode aufrufen, solange Sie die entsprechenden Experiment-Zuweisungen zu window.kameleoonQueue hinzufügen.
  • Sie können den zurückgegebenen Tracking-Code direkt in einen HTML-<script>-Tag einfügen.
In diesem Beispiel sind 123456 und 234567 Experiment-IDs und 7890 und 8901 Variation-IDs. In Ihrer Implementierung generiert das SDK diese Werte im zurückgegebenen Tracking-Code.
Argumente
Rückgabewert

Ereignisse

UpdateConfigurationHandler()

Mit der Methode UpdateConfigurationHandler() können Sie das Ereignis behandeln, wenn die Konfiguration Daten aktualisiert hat. Sie nimmt einen Eingabeparameter, handler. Der Handler, der aufgerufen wird, wenn die Konfiguration mithilfe eines Echtzeit-Konfigurationsereignisses aktualisiert wird.
Argumente

Datentypen

Die im SDK verfügbaren Daten stehen für Targeting und Reporting in der Kameleoon-App nicht zur Verfügung, bis sie hinzugefügt wurden; zum Beispiel mit der Methode addData(). Weitere Informationen finden Sie unter use visit history to target users.
Wenn Sie sich im hybriden Modus befinden, können Sie GetRemoteVisitorData() aufrufen, um automatisch alle Daten zu füllen, die Kameleoon zuvor gesammelt hat.
Die folgenden Datentypen sind in Kameleoon.Data.IData verfügbar.

Browser

Der hier gespeicherte Browser-Datensatz kann verwendet werden, um Experiment- und Personalisierungsberichte nach jedem zugehörigen Wert zu filtern.

PageView

Der Index (ID) des Referrers ist in unserem Back-Office auf der Konfigurationsseite des Akquisitionskanals verfügbar. Vorsicht: Dieser Index beginnt bei 0, sodass der erste Akquisitionskanal, den Sie für eine bestimmte Site erstellen, die ID 0 und nicht 1 hätte.

Conversion

Der hier gespeicherte Conversion-Datensatz kann verwendet werden, um Experiment- und Personalisierungsberichte nach jedem zugeordneten Ziel zu filtern.
  • Jeder Besucher kann mehrere Conversion-Objekte haben.
  • Sie können die goalId in der Kameleoon-App finden.

CustomData

CustomData ermöglicht es, jede Art von Daten einfach mit jedem Besucher zu verknüpfen. Sie kann dann als Targeting-Bedingung in Segmenten oder als Filter/Aufschlüsselung in Experimentberichten verwendet werden. Um mehr über Custom Data zu erfahren, lesen Sie bitte diesen Artikel.
  • Jeder Besucher darf nur eine CustomData für jeden eindeutigen index haben. Das Hinzufügen einer weiteren CustomData mit demselben index ersetzt die vorhandene.
  • Der Index der Custom Data befindet sich im Custom Data dashboard unter 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 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 Konfiguration der SDK-Instanz nicht aktuell ist oder der Name nicht registriert ist, führt dazu, dass die Daten ignoriert werden.

Device

UserAgent

Serverseitige Experimente werden eher von Bot-Traffic beeinflusst als clientseitige Experimente. Kameleoon verwendet die IAB/ABC International Spiders and Bots List, um dieses Problem anzugehen und bekannte Bots und Spider zu erkennen. Kameleoon verwendet auch das Feld UserAgent, um Bots und anderen unerwünschten Traffic herauszufiltern, der Ihre Conversion-Metriken verfälschen könnte. Weitere Details finden Sie in unserem Hilfeartikel zur Bot-Filterung. Wenn Sie interne Bots verwenden, empfehlen wir Ihnen, den Wert curl/8.0 des userAgent zu übergeben, um sie von unseren Analysen auszuschließen.

UniqueIdentifier

Wenn Sie keinen UniqueIdentifier für einen Besucher hinzufügen, wird visitorCode als eindeutige Besucherkennung verwendet, was für Cross-Device-Experimente nützlich ist. Wenn Sie UniqueIdentifier für einen Besucher hinzufügen, verknüpft das SDK die geleerten Daten mit dem Besucher, der mit der angegebenen Kennung verknüpft ist. Der isUniqueIdentifier kann in besonderen Situationen hilfreich sein; zum Beispiel, wenn Sie nicht auf den anonymen visitorCode zugreifen können, der einem Besucher zugewiesen wurde, aber eine interne ID verwenden können, die durch Sitzungszusammenführung mit diesem Besucher verknüpft ist.

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.
Cookie enthält Informationen über das auf dem Gerät des Besuchers gespeicherte Cookie.
Jeder Besucher kann nur ein Cookie haben. Das Hinzufügen eines zweiten Cookie überschreibt das erste.

Geolocation

Geolocation enthält die Geolokalisierungsdetails des Besuchers.
  • Jeder Besucher kann nur eine Geolocation haben. Das Hinzufügen einer zweiten Geolocation überschreibt die erste.

ApplicationVersion

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

Zurückgegebene Typen

DataFile

Die DataFile enthält die SDK-Konfigurationsdetails. 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 Standard-Variation, wenn keine spezifische Zuweisung vorhanden ist).
  • Das Variation-Objekt liefert Details zur zugewiesenen Variation und dem zugehörigen Experiment, während das Variable-Objekt spezifische Details zu jeder Variablen innerhalb einer Variation enthält.
  • Stellen Sie sicher, dass Ihr Code den Fall behandelt, in dem Id oder ExperimentId Variation.UndefinedId sein können, was auf eine Standard-Variation hinweist.
  • Das Variables-Dictionary kann leer sein, wenn keine Variablen mit der Variation verknüpft sind.

Variable

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

Veraltete Methoden

Diese Methoden sind veraltet und werden in der SDK-Version 5.0.0 entfernt.

GetFeatureVariationKey()

  • 📨 Sendet Tracking-Daten an Kameleoon
Um den Feature-Variation-Schlüssel zu erhalten, rufen Sie GetFeatureVariationKey() auf.
Verwenden Sie stattdessen GetVariation().
Diese Methode erfordert einen visitorCode und einen featureKey (oder featureID), um zu prüfen, ob ein Benutzer auf eine bestimmte Funktion zugreifen kann. Wenn der Benutzer noch nie mit dieser Funktion verknüpft wurde, entscheidet das SDK zufällig, ob es sie aktiviert, und gibt entweder true (er kann auf die Funktion zugreifen) oder false (er kann nicht zugreifen) zurück. Wenn der Benutzer mit dem angegebenen visitorCode bereits mit dieser Funktion verknüpft ist, gibt das System den vorherigen Wert des featureFlag zurück. Stellen Sie sicher, dass Sie in Ihrem Code eine angemessene Fehlerbehandlung einbeziehen, wie im Beispiel gezeigt, um potenzielle Fehler abzufangen. Wenn Sie einen visitorCode angeben, verwendet die Methode GetFeatureVariationKey() ihn als eindeutige Besucherkennung, was für Cross-Device-Experimente nützlich ist. Wenn Sie einen visitorCode angeben und den Parameter isUniqueIdentifier auf true setzen, verknüpft das SDK die geleerten Daten mit dem Besucher, der mit der angegebenen Kennung verknüpft ist.
Der Parameter isUniqueIdentifier ist veraltet. Verwenden Sie stattdessen UniqueIdentifier.Der isUniqueIdentifier kann in besonderen Situationen hilfreich sein; zum Beispiel, wenn Sie nicht auf den anonymen visitorCode zugreifen können, der einem Besucher zugewiesen wurde, aber eine interne ID verwenden können, die durch Sitzungszusammenführung mit diesem Besucher verknüpft ist.
Argumente
Rückgabewert
Ausgelöste Ausnahmen

GetActiveFeatureListForVisitor()

  • Verwenden Sie stattdessen GetActiveFeatures.
  • Diese Methode hieß zuvor ObtainFeatureListForVisitorCode(), die in der SDK-Version 4.0.0 entfernt wurde.
Diese Methode nimmt einen einzigen Parameter visitorCode. Gibt nur die aktiven feature flags für den angegebenen Besucher zurück.
Argumente
Rückgabewert

GetFeatureVariable()

  • 📨 Sendet Tracking-Daten an Kameleoon
Verwenden Sie stattdessen GetVariation().
Um die Variable des Variation-Schlüssels zu erhalten, die mit einem Benutzer verknüpft ist, rufen Sie die Methode GetFeatureVariable() unseres SDK auf. Diese Methode erfordert einen visitorCode und einen featureKey (oder featureID), um zu prüfen, ob ein Benutzer auf eine bestimmte Funktion zugreifen kann. Wenn der Benutzer noch nie mit dieser Funktion verknüpft wurde, entscheidet das SDK zufällig, ob es sie aktiviert, und gibt entweder true (er kann auf die Funktion zugreifen) oder false (er kann nicht zugreifen) zurück. Wenn der Benutzer mit dem angegebenen visitorCode bereits mit dieser Funktion verknüpft ist, gibt das System den vorherigen Wert des featureFlag zurück. Stellen Sie sicher, dass Sie in Ihrem Code eine angemessene Fehlerbehandlung einbeziehen, wie im Beispiel gezeigt, um potenzielle Fehler abzufangen. Wenn Sie einen visitorCode angeben, verwendet die Methode GetFeatureVariable() ihn als eindeutige Besucherkennung, was für Cross-Device-Experimente nützlich ist. Wenn Sie einen visitorCode angeben und den Parameter isUniqueIdentifier auf true setzen, verknüpft das SDK die geleerten Daten mit dem Besucher, der mit der angegebenen Kennung verknüpft ist.
Der Parameter isUniqueIdentifier ist veraltet. Verwenden Sie stattdessen UniqueIdentifier.Der isUniqueIdentifier kann in besonderen Situationen hilfreich sein; zum Beispiel, wenn Sie nicht auf den anonymen visitorCode zugreifen können, der einem Besucher zugewiesen wurde, aber eine interne ID verwenden können, die durch Sitzungszusammenführung mit diesem Besucher verknüpft ist.
Argumente
Rückgabewert
Ausgelöste Ausnahmen

GetActiveFeatures()

Verwenden Sie stattdessen GetVariations().
Die Methode GetActiveFeatures ruft Informationen über die aktiven feature flags ab, die für den angegebenen Visitor-Code verfügbar sind.
Die Eigenschaften Kameleoon.Types.Variation.Id und Kameleoon.Types.Variation.ExperimentId der zurückgegebenen Variations sind optional. Wenn sie nicht angegeben sind, ist der Standardwert Kameleoon.Types.Variation.UndefinedId.
Argumente
Rückgabewert
Ausgelöste Ausnahmen

GetFeatureVariationVariables()

  • Verwenden Sie stattdessen GetVariation().
  • Diese Methode hieß zuvor GetFeatureAllVariables(), die in der SDK-Version 4.0.0 entfernt wurde.
Rufen Sie diese Methode auf, um alle Feature-Variablen für ein Feature abzurufen. Sie können Feature-Variablen in der Kameleoon-App ändern. Diese Methode nimmt zwei Eingabeparameter: featureKey und variationKey. Sie gibt die Daten vom Typ Dictionary<string, object> zurück, wie in der Web-Oberfläche definiert. Sie löst eine Ausnahme (KameleoonException.FeatureNotFound) aus, wenn das angeforderte Feature nicht in der internen Konfiguration des SDK gefunden wurde.
Argumente
Rückgabewert
Ausgelöste Ausnahmen