Skip to main content
Mit dem NodeJS SDK können Sie Experiments ausführen und feature flags aktivieren. Die Integration unseres SDKs in Ihren Server ist einfach, und sein Footprint (Speicher- und Netzwerknutzung) ist gering. Unser Node SDK unterstützt Node Version 16+ mit der Möglichkeit, eine Herabstufung auf Version 14 und 12 vorzunehmen, indem Sie den Kompatibilitätsmodus. Erste Schritte: Hilfe für den Einstieg finden Sie im Entwicklerhandbuch. SDK-Methoden: Die vollständige Referenzdokumentation des NodeJS SDK finden Sie im Referenz Abschnitt. Changelog: Neueste Version des NodeJS SDK: Changelog. Next.js-Beispiel: Funktionsfähige Beispiele der Integration des NodeJS SDK mit Next.js, einschließlich App Router, Pages Router, Middleware und Server Actions, finden Sie im Next.js-Starter-Kits-Repository.
Bevor Sie mit der Installation unseres NodeJS SDK beginnen, empfehlen wir Ihnen, unseren Artikel zu technischen Überlegungen zu lesen, um die technologischen Konzepte hinter unseren SDKs zu verstehen. Dieser Artikel hilft Ihnen, eine erfolgreiche Integration sicherzustellen.

Entwicklerhandbuch

Folgen Sie diesem Abschnitt, um das SDK zu installieren und zu konfigurieren und mehr über erweiterte Funktionen zu erfahren.

Erste Schritte

Installation

Verwenden Sie das Kameleoon SDK-Installationstool, um das SDK zu installieren. Der SDK-Installer hilft Ihnen, das SDK Ihrer Wahl zu installieren, ein einfaches Codebeispiel zu generieren und externe Abhängigkeiten bei Bedarf zu konfigurieren. Um das SDK-Installationstool zu verwenden, installieren und führen Sie es global aus:
Oder führen Sie es direkt aus mit npx:
Bei Verwendung von Deno stellen Sie die Abhängigkeiten manuell bereit in deno.json:
deno.json

Initialisierung des Kameleoon-Clients

Entwickler müssen einen Einstiegspunkt für das NodeJS SDK erstellen, indem sie eine neue Instanz von KameleoonClient. Es wird empfohlen, KameleoonClient als Singleton zu behandeln, also eine einzige gemeinsame Instanz zu erstellen und sie über die gesamte Serverinstanz hinweg wiederzuverwenden, um Konsistenz zu gewährleisten und unnötige Neuinitialisierungen zu vermeiden. Verwenden Sie KameleoonClient um feature Experiments auszuführen und den Status von feature flags und deren variations abzurufen. KameleoonClient initialisiert asynchron, um sicherzustellen, dass die Kommunikation mit der Kameleoon API erfolgreich ist, unter Verwendung der initialize() Methode. Sie können async/await, Promise.then(), oder ein anderes asynchrones Muster verwenden, um die Client-Initialisierung zu handhaben.
Informationen zum Hinzufügen des NodeJS SDK zu einer Edge-Umgebung finden Sie in diesem Abschnitt.
Parameter
Ausgelöste Ausnahmen
Konfigurationsparameter
Option 1 (Recommended): Verwenden Sie JSON.stringify()
Option 2: JSON-Zeichenkette (Sonderzeichen escapen)
Kompatibilitätsmodus
Verwenden Sie den SDK-Parameter compatibility, um einige Funktionen des SDK zu deaktivieren und die Kompatibilität mit älteren NodeJS-Versionen zu verbessern. Compatibility ist eine Enumeration, die alle möglichen Kompatibilitätsmodi darstellt:
  • Compatibility.Node16—Standardmodus, alle Funktionen sind aktiviert. Dieser Modus wird verwendet, wenn kein Kompatibilitätsmodus angegeben ist. Unterstützt Node Version 16 und höher.
  • Compatibility.Node14—Kompatibilität mit dieser Version macht den Parameter requestTimeout in SDKConfigurationType nicht verfügbar und verhindert, dass das SDK AbortController für die Anforderungsabbruch verwendet, selbst innerhalb des Standard-Timeouts von 10_000 ms. Unterstützt Node Version 14 und höher.
  • Compatibility.Node12—Kompatibilität mit dieser Version impliziert die gleichen Einschränkungen wie der Modus Node14. Zusätzlich können Sie “@kameleoon/nodejs-requester” nicht als Requester-Implementierung in diesem Kompatibilitätsmodus bereitstellen, da es die “node-fetch”-Bibliothek verwendet, die die Node.js-Version 12.x.x nicht unterstützt. Ein Entwickler muss eine benutzerdefinierte Requester-Implementierung seiner Wahl bereitstellen, z. B. eine ältere “node-fetch”-Version oder eine andere HTTP-basierte Implementierung.

Aktivieren eines feature flag

Zuweisen einer eindeutigen ID an einen Benutzer
Um einem Benutzer eine eindeutige ID zuzuweisen, können Sie die Methode getVisitorCode() verwenden. Falls kein Besuchercode vorhanden ist (aus dem Cookie der Anfrage-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 Antwort-Header gespeichert. Wenn Sie Kameleoon im Hybrid-Modus verwenden, stellt der Aufruf der Methode getVisitorCode() sicher, dass die eindeutige ID (Besucher-Code) zwischen der Anwendungsdatei engine.js (zuvor kameleoon.js genannt) und dem SDK gemeinsam genutzt wird.
Abrufen einer Flag-Konfiguration
Um ein Feature Flag in Ihrem Code zu implementieren, müssen Sie zuerst das Feature Flag in Ihrem Kameleoon-Konto erstellen. Um den Status oder die Variation eines Feature Flags für einen bestimmten Benutzer zu bestimmen, sollten Sie die Methode getVariation() oder isFeatureFlagActive() verwenden, um die Konfiguration basierend auf featureKey abzurufen. Die Methode getVariation() handhabt sowohl einfache Feature Flags mit AN/AUS-Zuständen als auch komplexere Flags mit mehreren Variationen. Die Methode ruft die entsprechende Variation für den Benutzer ab, indem sie die Feature-Regeln überprüft, die Variation zuweist und basierend auf featureKey und visitorCode zurückgibt. Die Methode isFeatureFlagActive() kann verwendet werden, wenn Sie die Konfiguration eines einfachen Feature Flags abrufen möchten, das nur einen AN- oder AUS-Status hat, im Gegensatz zu komplexeren Feature Flags mit mehreren Variationen oder Targeting-Optionen. Wenn Ihr Feature Flag zugehörige Variablen hat (z. B. bestimmte Verhaltensweisen, die an jede Variation gebunden sind), ermöglicht getVariation() Ihnen auch den Zugriff auf das Objekt Variation, das Details zur zugewiesenen Variation und ihrem zugehörigen Experiment bietet. Diese Methode prüft, ob der Benutzer als Ziel gilt, findet die dem Besucher zugewiesene Variation und speichert sie. Wenn track=true, sendet das SDK das Exposure-Ereignis zum angegebenen Experiment in der nächsten Tracking-Anfrage, die automatisch basierend auf dem SDK-Parameter tracking_interval_millisecond ausgelöst wird. Standardmäßig ist dieses Intervall auf 1.000 Millisekunden (1 Sekunde) eingestellt. Mit der Methode getVariation() können Sie steuern, ob Tracking durchgeführt wird. Wenn track=false, werden keine Belichtungs-Events vom SDK gesendet. Dies ist nützlich, wenn Sie das Tracking von Daten durch das SDK nicht durchführen möchten und stattdessen auf clientseitiges Tracking verlassen möchten, das von der Kameleoon Engine verwaltet wird. Zusätzlich ist das Setzen von track=false hilfreich bei der Verwendung der Methode getVariations(), bei der Sie möglicherweise nur die Variationen für alle Flags benötigen, ohne beliebige Tracking-Events auszulösen. Wenn Sie mehr über die Funktionsweise von Tracking erfahren möchten, sehen Sie sich diesen Artikel an.
Hinzufügen von Datenpunkten, um einen Benutzer zu targetieren oder Besuche in Berichten zu filtern / aufzuschlüsseln
Um einen Benutzer ins Visier zu nehmen, stellen Sie sicher, dass Sie relevante Datenpunkte zu seinem Profil hinzugefügt haben, bevor Sie die Feature-Variation abrufen oder überprüfen, ob das Flag aktiv ist. Verwenden Sie die Methode addData(), um diese Datenpunkte zum Profil des Benutzers hinzuzufügen. Um auf anderen Geräten erfasste Datenpunkte abzurufen oder auf frühere Benutzerdaten zuzugreifen (erfasst auf der Clientseite bei Verwendung von Kameleoon im Hybrid-Modus), verwenden Sie die Methode getRemoteVisitorData(). Diese Methode ruft Daten asynchron vom Server ab. Es ist wichtig, getRemoteVisitorData() zu vor dem Abrufen der Variation oder dem Überprüfen, ob das Feature Flag aktiv ist, aufzurufen, da diese Daten möglicherweise erforderlich sind, um einen Benutzer einer bestimmten Variation zuzuweisen. Wenn Sie mehr über die verfügbaren Targeting-Bedingungen erfahren möchten, sehen Sie sich den ausführlichen Artikel zu diesem Thema an. Zusätzlich sind die Datenpunkte, die Sie zum Besucher-Profil hinzufügen, beim Analysieren Ihrer Experiments verfügbar, sodass Sie Ihre Ergebnisse nach Faktoren wie Gerät und Browser filtern und aufschlüsseln können. Der Kameleoon Hybrid-Modus erfasst automatisch eine Vielzahl von Datenpunkten clientseitig und macht es einfach, Ihre Ergebnisse basierend auf diesen vorgesammelten Datenpunkten aufzuschlüsseln. Sehen Sie sich die vollständige Liste hier an. Wenn Sie zusätzliche Datenpunkte über das automatisch Erfasste hinaus verfolgen müssen, können Sie die Funktion Custom Data von Kameleoon verwenden. Custom Data ermöglicht es Ihnen, spezifische für Ihre Experimente relevante Informationen zu erfassen und zu analysieren. Vergessen Sie nicht, die Methode flush() aufzurufen, um die erfassten Daten an Kameleoon-Server zur Analyse zu senden.
Um sicherzustellen, dass Ihre Ergebnisse genau sind, wird empfohlen, Bots mithilfe des Datentyps UserAgent herauszufiltern.
Tracking von Ziel-Conversions
Wenn ein Benutzer eine gewünschte Aktion abschließt (z. B. einen Kauf tätigt), wird dies als Konversion erfasst. Um Konversionen zu verfolgen, verwenden Sie die Methode trackConversion() und geben Sie die erforderlichen Parameter visitorCode und goalId an. Die Konversions-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). Falls Sie die Anfrage sofort senden möchten, verwenden Sie die Methode flush() mit dem Parameter instant=true.
Senden von Ereignissen an Analyse-Lösungen
Um Konversionen zu verfolgen und Exposure-Ereignisse an Ihre Customer-Analytics-Lösung zu senden, müssen Sie Kameleoon zunächst im Hybrid-Modus implementieren. Verwenden Sie dann die Methode getEngineTrackingCode(). Die Methode getEngineTrackingCode() ruft den eindeutigen Tracking-Code ab, der erforderlich ist, um Exposure-Ereignisse an Ihre Analytics-Lösung zu senden. Mit dieser Methode können Sie Ereignisse erfassen und an Ihre gewünschte Analytics-Plattform senden.

Fehlerbehandlung

Fast jede Methode von KameleoonClient kann zu irgendeinem Zeitpunkt einen Fehler auslösen. Diese Fehler sind absichtlich vordefinierte KameleoonError , die die native JavaScript-Klasse Error erweitern und nützliche Meldungen sowie ein spezielles Feld type mit einem Typ KameleoonException bereitstellen. KameleoonException ist eine Enumeration mit allen möglichen Fehlertypen. Um genau zu wissen, welcher Typ von KameleoonException die Methode auslösen kann, überprüfen Sie den Abschnitt Throws in der Methodenbeschreibung oder bewegen Sie den Mauszeiger in Ihrer IDE über die Methode, um die JSDoc-Beschreibung anzuzeigen. Die Fehlerbehandlung gilt als bewährte Methode, um Ihre Anwendung stabiler zu machen und technische Probleme zu vermeiden.

Integration mit Edge-Anbietern

Kameleoon bietet die folgenden Starter Packs zur Automatisierung Ihrer Integration mit spezifischen Edge-Anbietern:Verwenden Sie für andere Edge-Anbieter Externe Abhängigkeiten für bessere Kontrolle über das SDK.

Geräteübergreifende Experimentierung

Um Besucher zu unterstützen, die eine App von mehreren Geräten aus aufrufen, ermöglicht Kameleoon die Synchronisierung zuvor erfasster Besucherdaten über alle Geräte des Besuchers hinweg und die Abstimmung des Besuchsverlaufs über Geräte durch Cross-Device-Experimentation. Fallstudien und detaillierte Informationen darüber, wie Kameleoon Daten über Geräte hinweg handhabt, finden Sie im Artikel über Cross-Device-Experimentation.

Synchronisieren von custom data über Geräte hinweg

Obwohl benutzerdefinierte Mapping-Synchronisierung verwendet wird, um Besucherdaten über Geräte hinweg auszurichten, ist dies nicht immer erforderlich. Nachfolgend finden Sie zwei Szenarien, in denen benutzerdefinierte Mapping-Synchronisierung nicht erforderlich ist: Gleiche Benutzer-ID auf allen Geräten Wenn die gleiche Benutzer-ID konsequent auf allen Geräten verwendet wird, wird die Synchronisierung automatisch ohne eine benutzerdefinierte Mapping-Synchronisierung durchgeführt. Es genügt, die Methode getRemoteVisitorData() aufzurufen, wenn Sie die zwischen mehreren Geräten erfassten Daten synchronisieren möchten. Multi-server instances mit consistent IDs Bei komplexen Setups mit mehreren Servern (z. B. verteilten Server-Instanzen), bei denen die gleiche Benutzer-ID auf Servern verfügbar ist, ist die Synchronisierung zwischen Servern (mit getRemoteVisitorData()) ausreichend, ohne dass eine zusätzliche benutzerdefinierte Mapping-Synchronisierung erforderlich ist. Kunden, die zusätzliche Daten benötigen, können sich auf die Beschreibung der Methode getRemoteVisitorData() beziehen, um weitere Anleitung 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 verwendet wird, um einen genauen Datenabruf zu ermöglichen.
Wenn Sie erfasste Daten in Echtzeit synchronisieren möchten, müssen Sie den Bereich Besucher für Ihre benutzerdefinierten Daten wählen.
Device One
Device Two

Verwendung von custom data zur Session-Zusammenführung

Geräteübergreifende Experimentierung ermöglicht es Ihnen, die Verlaufsdaten eines Besuchers über alle seine Geräte hinweg zu kombinieren (Verlaufsabstimmung). Sie können mehrere Besucher-Sessions mit Verlaufsabstimmung in eine zusammenführen. Verwenden Sie CustomData und geben Sie eine eindeutige Kennung für den Besucher an, um die Verlaufsdaten abzustimmen.Folgen Sie dem Leitfaden zum Aktivieren der Cross-Device-Historienabstimmung, um Ihre benutzerdefinierten Daten in Kameleoon einzurichten.Sie können custom data in Ihrem Code verwenden, um die Sitzung eines Besuchers zusammenzuführen. Sitzungen mit derselben Kennung sehen immer die gleiche Experiment-Variation und werden als ein einzelner Besucher in der Ansicht Visitor Ihrer Experiment-Ergebnisseite angezeigt.Die SDK-Konfiguration stellt sicher, dass zugehörige Sessions immer die gleiche Variation des Experiments sehen.Informieren Sie das SDK vor der Verwendung anderer Methoden, dass der Besucher eine eindeutige Kennung ist, indem Sie UniqueIdentifier-Daten zu einem Besucher hinzufügen.
Da die custom data, die Sie als Kennung verwenden, auf den Bereich Visitor gesetzt werden muss, müssen Sie die geräteübergreifende custom data Synchronisierung verwenden, um die Kennung mit der Methode getRemoteVisitorData auf jedem Gerät abzurufen.
Das folgende Beispiel zeigt eine Anwendung mit einer Anmeldeseite. Da die Benutzer-ID zum Zeitpunkt der Anmeldung nicht bekannt ist, verwendet der Code eine anonyme Besucher-Kennung, die durch die Methode getVisitorCode generiert wird. Nach der Anmeldung des Benutzers können Sie den anonymen Besucher mit der Benutzer-ID verknüpfen und als eindeutige Kennung für den Besucher verwenden.
Login Page
Application Page

Verwendung eines benutzerdefinierten Bucketing-Keys

Standardmäßig verwendet Kameleoon eine eindeutige, anonyme Besucher-ID (visitorCode), um Benutzer Variationen von Feature Flags zuzuweisen. Diese ID wird normalerweise auf dem Gerät des Benutzers generiert und gespeichert (in einem Browser-Cookie für Client-seitige und Server-seitige SDKs—im persistenten Speicher für Mobile SDKs). In bestimmten Szenarien müssen Sie jedoch möglicherweise sicherstellen, dass alle Benutzer derselben Organisation die gleiche Variante eines Feature Flags sehen. Die Option Benutzerdefinierter Bucketing-Schlüssel ermöglicht es Ihnen, dieses Standardverhalten zu überschreiben, indem Sie Ihre eigene benutzerdefinierte Kennung für 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 wesentlich für die Aufrechterhaltung von Konsistenz und Genauigkeit in Ihren Feature Flag-Zuweisungen, besonders in diesen Situationen:
  • Kontolevel- oder organisatorische Experiments: Für B2B-Produkte oder Szenarien, in denen Sie alle Benutzer aus der gleichen Organisation der gleichen Variation zuweisen möchten, können Sie einen Bezeichner wie accountId verwenden. Benutzerdefinierte Bucketing-Schlüssel sind entscheidend für A/B-Tests von Funktionen, die ein gesamtes Team oder Unternehmen beeinflussen.
Durch die Implementierung eines benutzerdefinierten Bucketing-Schlüssels stellen Sie eine größere Konsistenz und Genauigkeit in Ihren Experiments sicher, was zu zuverlässigeren Ergebnissen und einem besseren Benutzererlebnis führt.

Technische Details

Wenn Sie einen benutzerdefinierten Bucketing-Schlüssel für ein Feature Flag konfigurieren, stellen Sie Kameleoon eine spezifische Kennung aus Ihren Anwendungsdaten bereit:
  • Bereitstellen des benutzerdefinierten Schlüssels: Sie stellen Ihren benutzerdefinierten Bezeichner dem Kameleoon SDK mit der Methode addData() bereit. In dieser Methode übergeben Sie Ihren gewählten benutzerdefinierten Bucketing-Schlüssel als Objekt CustomData. Hier bezieht sich newVisitorCode auf den Bezeichner, den Sie für Ihr Bucketing verwenden möchten (z. B. die neue userId oder accountId).
Damit der benutzerdefinierte Bucketing-Schlüssel ordnungsgemäß funktioniert, muss er auch für das Feature Flag während des Flag-Erstellungs- oder Bearbeitungsprozesses definiert und konfiguriert werden. Ohne diese entsprechende Konfiguration wendet die Bucketing des SDK Ihren benutzerdefinierten Schlüssel nicht an. Ausführliche Anweisungen zum Einrichten in Kameleoon finden Sie in diesem Artikel.
  • Bucketing-Logik: Sobald ein benutzerdefinieter Bucketing-Schlüssel durch die Methode addData() bereitgestellt wird, verwenden alle Hash-Berechnungen zum Zuweisen von Benutzern zu Variationen diesen newVisitorCode (Ihren benutzerdefinierten Schlüssel) anstelle des Standard-visitorCode. Die Verwendung des newVisitorCode bedeutet, dass die Bucketing-Entscheidung an Ihren benutzerdefinierten Bezeichner gebunden ist und konsistente Zuweisungen in verschiedenen Kontexten sicherstellt, in denen dieser Bezeichner vorhanden ist.
  • Daten-Tracking und Analytics: Es ist wichtig zu beachten, dass der newVisitorCode (Ihr benutzerdefinierter Schlüssel) für Bucketing-Entscheidungen verwendet wird, aber alle nachfolgenden Daten (Tracking-Ereignisse und Konversionen, z. B.) werden gesendet und mit der ursprünglichen visitorCode verknüpft. Diese Trennung stellt sicher, dass Ihre Analytics die individuellen Benutzer-Journeys und Interaktionen im breiteren Kontext Ihres Experiments genau widerspiegeln, auch wenn Bucketing auf einer höheren Ebene (z. B. ein Konto) oder über mehrere Geräte/Sessions durchgeführt wird. Ihre ursprünglichen Besucherdaten bleiben für umfassende Berichte intakt.

Technische Anforderungen

Um einen benutzerdefinierten Bucketing-Schlüssel effektiv zu verwenden:
  • Der Schlüssel muss ein string sein.
  • Es muss eindeutig für die Entität sein, die Sie bucketing möchten (z. B., wenn Sie eine userId verwenden, sollte die ID jedes Benutzers eindeutig sein).
  • Der Schlüssel muss zum SDK zum genauen Zeitpunkt verfügbar sein, 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, mit denen Sie Benutzer in Ihren Kampagnen ansprechen können. Eine Liste der von diesem SDK unterstützten Bedingungen finden Sie unter Verwenden Sie den Besuchsverlauf, um Benutzer anzusprechen. 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 das Konfigurieren der Begrenzung der Protokollierung durch einen Protokollebene.

Benutzerdefinierte Log-Behandlung

Das SDK schreibt seine Logs standardmäßig auf die Konsolenausgabe. Dieses Verhalten kann überschrieben werden.
Die Begrenzung der Protokollierung durch einen Protokollebene wird unabhängig von der Protokollierungsbehandlung durchgeführt.

Domain-Informationen

Sie geben eine Domain als domain in der KameleoonClient-Konfiguration an, die zum Speichern des Kameleoon-Besuchercodes in Cookies verwendet wird. Das Angeben einer Domain ist wichtig bei der Arbeit mit den Methoden getVisitorCode und setLegalConsent. Die bereitgestellte Domain wird im Cookie als Schlüssel Domain= gespeichert.

Festlegen der Domain

Die bereitgestellte Domain ermöglicht der URL-Adresse, das Cookie zu verwenden. Wenn Ihre Domain z. B. www.example.com ist, ist das Cookie nur von einer www.example.com-URL aus verfügbar. Seiten mit der Domain app.example.com können das Cookie nicht verwenden. Für mehr Flexibilität mit Subdomains können Sie eine Domain angeben, die mit einem . beginnt. Beispielsweise ermöglicht die Domain .example.com das Cookie, auf app.example.com und login.example.com zu funktionieren.
Sie können keine regulären Ausdrücke, Sonderzeichen, Protokolle oder Portnummern im domain verwenden. Zusätzlich kann eine spezifische Liste von Subdomains nicht mit dem Präfix . verwendet werden.
Hier ist ein kleines Domain-Spickzettel:

Entwicklung auf localhost

localhost wird immer als ungültige Domain angesehen, was es schwierig macht, die Domain bei der Entwicklung auf localhost zu testen. Es gibt zwei Möglichkeiten, dieses Problem zu vermeiden:
  • Geben Sie das Feld domain im SDK-Client beim Testen nicht an. Dies verhindert localhost-Probleme (das Cookie wird auf jeder Domain gespeichert).
  • Erstellen Sie eine lokale Domain für localhost. Zum Beispiel:
    • Navigieren Sie unter Linux zu /etc/hosts oder unter Windows zu c:\Windows\System32\Drivers\etc\hosts
    • Öffnen Sie hosts mit Datei-Superbenutzer- oder Administratorrechten
    • Fügen Sie hinzu a domain zum localhost port, zum Beispiel: 127.0.0.1 app.com
    • Jetzt können Sie Ihre App lokal auf app.com:{my_port} ausführen und .app.com als Ihre Domain angeben

Externe Abhängigkeiten

Die externen Abhängigkeiten des SDK verwenden das Muster Dependency Injection, das es Ihnen ermöglicht, Ihre eigenen Implementierungen für bestimmte Teile eines SDK bereitzustellen.
Im NodeJS SDK haben einige externe Abhängigkeiten Standard-Implementierungen, während andere vom Benutzer bereitgestellt werden müssen, unabhängig davon, ob dedizierte Kameleoon-Implementierungen oder benutzerdefinierte Implementierungen verwendet werden.
Here’s die Liste of available externe Abhängigkeiten:
Sie können visitorCodeManager auch mit den Schnittstellen IExternalNextJSVisitorCodeManager, IExternalDenoVisitorCodeManager oder IExternalCustomVisitorCodeManager für NextJS, Deno beziehungsweise benutzerdefinierte Besuchercode-Manager-Implementierungen implementieren.
Externe Abhängigkeiten bieten Entwicklern Flexibilität, um das NodeJS SDK an jede Umgebung anzupassen und zu verwenden. Es gibt eine Reihe von npm-Paketen, die Kameleoon für häufig verwendete Umgebungen bereitstellt. Sie können die Pakete manuell installieren oder durch Verwendung des SDK-Installationswerkzeugs (empfohlen). Dies sind die von Kameleoon bereitgestellten externen Abhängigkeiten für das NodeJS SDK:
  • @kameleoon/nodejs-event-source - basierend auf der Bibliothek eventsource (kann für NodeJS/Deno/NextJS SSR verwendet werden)
  • @kameleoon/nodejs-requester - basierend auf der Bibliothek node-fetch (kann für NodeJS/Deno/NextJS SSR verwendet werden)
  • @kameleoon/nodejs-visitor-code-manager - implementiert mit Serverspeicher
  • @kameleoon/deno-visitor-code-manager—implementiert mit Deno-Request/Response-Cookies
  • @kameleoon/nextjs-visitor-code-manager - implementiert mit NextJS SSR headers Cookie oder NextJS SSR Request/Response
Sie können externe Abhängigkeiten optional selbst implementieren. Das folgende Beispiel implementiert externe Abhängigkeiten. Um eine Schnittstelle aus einem SDK zu importieren, erstellen Sie eine Klasse, die sie implementiert, und übergeben Sie die instanziierte Klasse an das SDK.

Storage

EventSource

VisitorCodeManager

Implementierung von visitorCodeManager für NodeJS/NextJS SSR:
Implementierung von visitorCodeManager für Deno:
visitorCodeManager-Implementierung für NextJS-Server-Aktionen:
Benutzerdefinierte visitorCodeManager-Implementierung mit beliebigen Parametern:

Requester

Utilities

Das SDK verfügt über eine Reihe von Utility-Methoden, mit denen Sie die Entwicklung vereinfachen können. Alle Methoden werden als statische Member der Klasse KameleoonUtils dargestellt.

simulateSuccessRequest

Verwenden Sie die Methode simulateSuccessRequest, um eine erfolgreiche Anfrage an den Kameleoon-Server zu simulieren. Diese Methode kann für benutzerdefinierte Requester-Implementierungen nützlich sein, wenn ein Entwickler eine erfolgreiche Anfrage simulieren muss.
Parameter
Der Datentyp SimulateRequestDataType ist wie folgt definiert:
  • RequestType.Tracking - null
  • RequestType.ClientConfiguration - ClientConfigurationDataType
  • RequestType.RemoteData - JSONType
Rückgabewert

getCookieValue

Verwenden Sie die Methode getCookieValue, um eine häufige Cookie-Zeichenkette zu analysieren (key_1=value_1; key_2=value_2; ...), und den Wert eines spezifischen Cookie-Schlüssels zu erhalten. Diese Methode ist nützlich bei der Arbeit mit einer benutzerdefinierten Implementierung von VisitorCodeManager.
Parameter
Rückgabewert

Referenz

Dies ist die vollständige Referenzdokumentation für das Kameleoon JavaScript SDK.

Initialisierung

initialize()

Eine asynchrone Methode zur Initialisierung von KameleoonClient, die Kameleoon-SDK-Daten entweder vom Server oder aus einer lokalen Quelle abruft, wenn die Daten noch aktuell sind oder das Aktualisierungsintervall noch nicht verstrichen ist.
Rückgabewert
Ausgelöste Ausnahmen

isReady()

isReady() prüft, ob das SDK einsatzbereit ist, das heißt, ob seine Konfiguration erfolgreich geladen wurde. Im Gegensatz zu initialize() gibt diese Methode sofort ein Ergebnis zurück, ohne zu blockieren oder eine Ausnahme auszulösen.
Sobald das SDK einsatzbereit ist, bleibt es einsatzbereit. Wenn eine spätere Aktualisierung der Konfiguration fehlschlägt, verwendet das SDK weiterhin die zuvor heruntergeladene Konfiguration und kehrt daher nie in einen nicht bereiten Zustand zurück.
Rückgabewert

Feature flags und variations

getVariation()

  • 📨 Sendet Tracking-Daten an Kameleoon (abhängig vom Parameter track)
Ruft die Variation auf, die einem bestimmten Besucher für ein spezifisches Feature Flag zugewiesen wurde. Diese Methode akzeptiert featureKey als erforderliches Argument und track als optionales Argument. Das Argument track ist optional und wird standardmäßig auf true gesetzt. Sie gibt die der zugewiesene Variation für den Besucher zurück. Wenn der Besucher nicht mit Feature-Flag-Regeln verknüpft ist, gibt die Methode die Standard-Variation für das angegebene Feature Flag zurück. Stellen Sie sicher, dass die ordnungsgemäße Fehlerbehandlung in Ihrem Code implementiert ist, um potenzielle Ausnahmen zu verwalten.
Die Standardvariation bezieht sich auf die Variation, die einem Besucher zugewiesen wird, wenn dieser keine vordefinierten Lieferungsregeln für ein Feature Flag erfüllt. Mit anderen Worten ist es die Fallback-Variation, die auf alle Benutzer angewendet wird, die nicht durch spezifische Regeln gezielt werden. Sie wird als Variation im Bereich „Dann für alle anderen…” in einer Verwaltungsschnittstelle dargestellt.
Parameter
Ein Objekt vom Typ GetVariationParamsType mit den folgenden Eigenschaften:
Rückgabewert
Ausgelöste Ausnahmen

getVariations()

  • 📨 Sendet Tracking-Daten an Kameleoon (abhängig vom track-Parameter)
  • 🎯 Ereignisse: EventType.Evaluation
Ruft eine Zuordnung von Variation-Objekten ab, die einem bestimmten Besucher über alle Feature Flags 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 erforderliches Argument und onlyActive sowie track als optionale Argumente entgegen.
  • Wenn onlyActive auf true gesetzt ist, gibt die Methode getVariations() Feature-Flag-Variationen zurück, sofern der Benutzer nicht mit der off-Variation zugeordnet wurde.
  • Der Parameter track steuert, ob die Methode die Variationszuweisungen verfolgt oder nicht. 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üsseln und ihren entsprechenden Variation-Werten. Wenn keine Variation für ein Feature Flag zugewiesen ist, gibt die Methode die Standard-Variation für dieses Flag zurück. Eine ordnungsgemäße Fehlerbehandlung sollte implementiert werden, um mögliche Ausnahmen zu verwalten.
Die Standardvariation bezieht sich auf die Variation, die einem Besucher zugewiesen wird, wenn dieser keine vordefinierten Lieferungsregeln für ein Feature Flag erfüllt. Mit anderen Worten ist es die Fallback-Variation, die auf alle Benutzer angewendet wird, die nicht durch spezifische Regeln gezielt werden. Sie wird als Variation im Bereich „Dann für alle anderen…” in einer Verwaltungsschnittstelle dargestellt.
Parameter
Ein Objekt vom Typ GetVariationsParamsType mit den folgenden Eigenschaften:
Rückgabewert
Ausgelöste Ausnahmen

isFeatureFlagActive()

  • 📨 Sendet Tracking-Daten an Kameleoon (abhängig vom track-Parameter)
  • 🎯 Ereignisse: EventType.Evaluation
Die Methode isFeatureFlagActive() gibt einen booleschen Wert zurück, der anzeigt, ob der Besucher mit visitorCode ein aktives featureKey hat. Diese Methode überprüft das Targeting, findet die Variation für den Besucher und speichert sie im Speicher. Die Methode sendet auch eine Tracking-Anfrage. Diese Methode hat eine zusätzliche Überladung, die es Ihnen ermöglicht, einen Parameter track zu übergeben, der das Tracking der Feature-Auswertung deaktiviert.
Ein Besucher muss als Ziel definiert werden, damit Feature Flags aktiviert werden können.
Kameleoon verwendet Tracking, um Sitzungen und Besucher zu zählen, wenn Sie bestimmte Methoden aufrufen, wie zum Beispiel isFeatureFlagActive(), getVariation() oder getVariations().Verwenden Sie den Standardwert true für den Parameter track, wenn Sie Besucher einer Variation zuordnen und diese zählen möchten. Setzen Sie den Parameter track auf false nur, wenn Sie diese Methoden aufrufen, bevor Sie Besucher zuordnen.Wenn Sie beispielsweise getVariations() aufrufen, um alle Variationen abzurufen, bevor Sie Besucher zuordnen, 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 zuordnen.Kameleoon sendet Tracking-Daten standardmäßig jede Sekunde. Sie können dieses Intervall auf bis zu fünf Sekunden mithilfe der Konfigurationsoption für das Tracking-Intervall konfigurieren. Kameleoon gruppiert Tracking-Ereignisse in eine einzelne 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 in Ihren Berichten 30 Minuten nach dem letzten aufgezeichneten Ereignis in der Sitzung.
Die Methode isFeatureFlagActive() wertet die bereitgestellte Variante aus, nicht den Zustand des Master-Flags. Wenn Sie Regeln ausschließen, verwendet die Methode den Standard-Zustand Dann für alle anderen. Wenn Sie Off für diesen Standard-Zustand auswählen, gibt die Methode immer false zurück, auch wenn das Master-Feature-Flag On ist.
Parameter
Für diese Methode stehen zwei Überladungen zur Verfügung:
  1. Zwei-Parameter-Überladung:
Diese Überladung ist veraltet und wird in der nächsten Hauptversion entfernt. Bitte verwenden Sie die neue Überladung mit einem Objektparameter.
  1. Objekt-Parameter-Überladung vom Typ IsFeatureFlagActiveParamsType:
Rückgabewert
Ausgelöste Ausnahmen

setForcedVariation()

Die Methode ermöglicht es Ihnen, eine bestimmte Variation einem Benutzer programmgesteuert zuzuweisen und dabei den Standard-Auswertungsprozess zu umgehen. Dies ist besonders wertvoll für kontrollierte Experimente, in denen die übliche Auswertungslogik nicht erforderlich ist oder übersprungen werden muss. Dies kann auch in Szenarien wie Debugging oder benutzerdefinierten Tests nützlich sein. Wenn eine erzwungene Variation festgelegt ist, setzt sie Kameleoons Echtzeit-Evaluierungslogik außer Kraft. Prozesse wie Segmentierung, Targeting-Bedingungen und algorithmische Berechnungen werden übersprungen. Um Segmentierung und Targeting-Bedingungen während eines Experiments zu bewahren, setzen Sie stattdessen forceTargeting=false.
Simulierte Variationen haben immer Vorrang in der Ausführungsreihenfolge. Wenn eine simulierte Variationsberechnung ausgelöst wird, wird sie vollständig verarbeitet und zuerst abgeschlossen.
Eine erzwungene Variation wird gleich wie eine bewertete Variation behandelt. Sie wird in der Analyse verfolgt und im Benutzerkontext wie jede andere standard-bewertete Variation gespeichert, was die Konsistenz der Berichterstellung gewährleistet. Die Methode kann unter bestimmten Bedingungen Ausnahmen auslösen (z. B. ungültige Parameter, Benutzerkontext oder interne Probleme). Eine ordnungsgemäße Ausnahmeverarbeitung ist wichtig, 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: Beeinflussen das Gesamtergebnis des Feature Flags.
Parameter
Ein Objekt vom Typ SetForcedVariationParametersType mit den folgenden Eigenschaften:
Ausgelöste Ausnahmen
In den meisten Fällen muss nur der grundlegende Fehler KameleoonException behandelt werden, wie im Beispiel gezeigt. Falls jedoch verschiedene Fehlertypen eine Antwort erfordern, behandeln Sie diese einzeln basierend auf spezifischen Anforderungen. Darüber hinaus können für erhöhte Zuverlässigkeit allgemeine Sprachfehler durch Einbindung von Error behandelt werden.

evaluateAudiences()

  • 📨 Sendet Tracking-Daten an Kameleoon
Diese Methode wertet Besucher gegen alle verfügbaren Segments des Audiences Explorer aus und verfolgt diejenigen, die dem Ziel entsprechen. evaluateAudiences() sollte nach dem Festlegen oder Aktualisieren aller relevanten Besucherdaten aufgerufen werden und unmittelbar vor dem Abrufen einer Feature-Variation oder dem Überprüfen eines Feature Flags. Dieser Ansatz stellt sicher, dass der Besucher gegen die aktuellsten verfügbaren Daten ausgewertet wird, was eine genaue Zielgruppenbestimmung basierend auf allen Kriterien ermöglicht. Nach dem Aufrufen dieser Methode können Sie eine detaillierte Analyse der Segment-Performance im Audiences Explorer durchführen.
Parameter
Ausgelöste Ausnahmen
In den meisten Fällen muss nur der grundlegende Fehler KameleoonException behandelt werden, wie im Beispiel gezeigt. Falls jedoch verschiedene Fehlertypen eine Antwort erfordern, behandeln Sie diese einzeln basierend auf spezifischen Anforderungen. Darüber hinaus können für erhöhte Zuverlässigkeit allgemeine Sprachfehler durch Einbindung von Error behandelt werden.

getDataFile()

Verwenden Sie getVariations() zum Auswerten aller Feature Flags. Diese Methode ist effizienter als das Aufrufen von DataFile und das Durchlaufen von Flags mit getVariation().
Gibt die aktuelle SDK-Konfiguration als DataFile-Objekt zurück.
Rückgabewert

Besucherdaten

getVisitorCode()

Die Methode getVisitorCode ruft einen Besuchercode aus dem Cookie der Anfrage in den Headern ab. Wenn der Besuchercode nicht vorhanden ist, generiert die Methode einen neuen zufälligen Besuchercode oder verwendet einen bereitgestellten defaultVisitorCode-Wert. Anschließend wird der neue Besuchercode in einem Cookie in den Response-Headern gesetzt. Diese Methode nutzt die nativen Typen von Node.js für request und response, insbesondere IncomingMessage und ServerResponse, die aus dem http-Modul importiert werden. Wenn Sie jedoch das Express-Framework, Deno oder Next.js-Server-Rendering-Methoden wie getServerProps verwenden, unterscheiden sich die Typen für request und response. Sie können dieses Problem mithilfe von Typ-Casting lösen, das zu identischen Ergebnissen führt.
Wenn Sie getVisitorCode() mit Deno, Next.js SSR, Node oder Express verwenden, stellen Sie sicher, dass Sie die richtigen externen Abhängigkeiten implementiert haben.
Die Methode getVisitorCode() ermöglicht es Ihnen, simulierte Variationen für einen Besucher festzulegen. Wenn Cookies (von einer Anfrage oder 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 die Kameleoon-Web-Experimentation verwenden oder das SDK im Hybrid-Modus einsetzen, wird das Cookie automatisch erstellt, wenn Sie die Anzeige einer Variante mithilfe des Simulation Panel simulieren.
  • Manuell: Setzen Sie das Cookie kameleoonSimulationFFData manuell.
Es ist wichtig, simulierte Variationen von erzwungenen Variationen zu unterscheiden:
  • Simulierte Variationen: Beeinflussen das Gesamtergebnis des Feature Flags.
  • Erzwungene Variationen: Sind spezifisch für ein einzelnes Experiment.
⚙️ Manual setupStellen Sie sicher, dass der kameleoonSimulationFFData-Cookie diesem 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 Standard-Variation (definiert im Abschnitt Dann für alle anderen in Produktion) für den angegebenen featureKey.
⚠️ Um sicherzustellen, dass der Cookie-Wert korrekt funktioniert, codieren Sie ihn als URI-Komponente mithilfe einer Methode wie encodeURIComponent.
Parameter
Das Parameters-Objekt ist mit zwei Typen überladbar:
  • Typ GetVisitorCodeParametersType (für NodeJS/Express/NextJS SSR methods), die folgende Felder enthält:
  • Typ GetNextJSVisitorCodeParametersType (für NextJS SSR server actions), die folgende Felder enthält:
  • Typ GetDenoVisitorCodeParametersType (für Deno), die folgende Felder enthält:
  • Typ GetCustomVisitorCodeParametersType (für benutzerdefinierte VisitorCodeManager-Implementierung), die folgende Felder enthält:
Wenn Sie keinen defaultVisitorCode bereitstellen und es keinen Besuchercode in einem Cookie gibt, wird der Besuchercode zufällig generiert.
Rückgabewert
Ausgelöste Ausnahmen

addData()

Verwenden Sie die Methode addData(), um Zielgruppendaten im Speicher hinzuzufügen, damit andere Methoden diese Informationen verwenden können, um zu bestimmen, ob der aktuelle Besucher gezielt werden soll. Die Methode addData() gibt keinen Wert zurück und interagiert nicht direkt mit den Kameleoon-Backend-Servern. Stattdessen werden alle Daten, die die Methode erfasst, für die zukünftige Übertragung mit der Methode flush() gespeichert. Dieser Ansatz minimiert die Anzahl der Server-Aufrufe, da Daten in der Regel in einem einzelnen Server-Aufruf gruppiert werden, der durch die Methode flush() aktiviert wird. Darüber hinaus übermittelt die Methode trackConversion() alle zuvor zugeordneten Daten. Die Methoden getFeatureFlagVariationKey() und getFeatureFlagVariable() übermitteln Daten, wenn eine Experimentialisierungsregel ausgelöst wird.
Jeder Besucher kann nur eine Instanz zugeordneter Daten für die meisten Datentypen haben; CustomData ist jedoch eine Ausnahme, da Besucher eine Instanz zugeordneter CustomData für jeden customDataIndex haben können.
Überprüfen Sie die Liste der unterstützten Bedingungen, um zu sehen, welche Datentypen Sie zum Zielgruppeneinsatz verwenden können.
Parameter
  • kameleoonData ist ein variadisches Argument: Es kann als eine oder mehrere Argumente übergeben werden (siehe Beispiel).
  • Der Index oder die Kennung der benutzerdefinierten Daten finden Sie in Ihrem Kameleoon-Konto. Beachten Sie, dass dieser Index bei 0 beginnt, d. h. die erste benutzerdefinierte Daten, die Sie für einen bestimmten Standort erstellen, wird 0 als Kennung zugewiesen, nicht 1.
Ausgelöste Ausnahmen
Weitere Informationen zum Verwalten verschiedener Datentypen finden Sie in der Referenz Datentypen.

flush()

flush() nimmt die Kameleoon-Daten, die dem Besucher zugeordnet sind, und plant die Daten so, dass sie mit der nächsten Tracking-Anfrage gesendet werden. Der Zeitpunkt der nächsten Tracking-Anfrage wird durch den Parameter trackingInterval in der SDK-Konfiguration definiert. Sie können Besucherdaten mit den Methoden addData() und getRemoteVisitorData() hinzufügen.Das SDK sendet alle seine gespeicherten Daten an die Kameleoon-Remote-Server, wenn Sie keinen visitorCode angeben. Darüber hinaus wird das SDK versuchen, zuvor fehlgeschlagene Tracking-Anfragen zu senden, wenn diese lokal im Offline-Modus gespeichert wurden, bevor es die neueste Anfrage verarbeitet.
Wenn Sie Tracking-Anfragen sofort senden müssen, verwenden Sie flushInstant() – die asynchrone Version von flush, die Promise<void> zurückgibt. Sie können await verwenden, wenn Sie Liefergarantien benötigen (z. B. vor dem Beenden eines Anfrage-/Antwort-Zyklus), oder rufen Sie es ohne await als „Fire-and-Forget”-Anfrage auf:
  • await client.flushInstant(visitorCode) sendet Tracking-Anfragen sofort für einen bestimmten Besucher und wartet auf den Abschluss
  • await client.flushInstant() sendet Tracking-Anfragen sofort für alle Besucher und wartet auf Abschluss
Parameter
Or ein Objekt mit der Typ FlushParamsType, containing:
Ausgelöste Ausnahmen

getRemoteData()

Die Methode getRemoteData() ruft Daten ab, die auf einem Kameleoon-Remote-Server für einen angegebenen Standortcode gespeichert sind. Beispielsweise können Sie diese Methode verwenden, um auf Benutzereinstellungen, historische Daten oder andere für Ihre Anwendungslogik relevante Informationen zuzugreifen. Durch das Speichern dieser Daten auf Kameleoons hochgradig skalierbaren Servern mithilfe der Data API können Sie große Datenmengen effizient verwalten und für jeden Ihrer Besucher oder Benutzer abrufen.
Parameter
Rückgabewert
Ausgelöste Ausnahmen

getRemoteVisitorData()

Die Methode getRemoteVisitorData() ist eine asynchrone Funktion, die Kameleoon Visits Data für einen spezifischen visitorCode aus der Kameleoon Data API abruft. Diese Methode speichert die Daten, sodass sie bei Targeting-Entscheidungen verwendet werden können.Die über diese Methode erhaltenen Daten sind wichtig, wenn Sie Folgendes tun möchten:
  • Auf Daten zugreifen, die von mehreren Geräten erfasst wurden.
  • Überprüfung der Historie eines Benutzers, einschließlich während früherer Sitzungen besuchter Seiten.
  • Benutzerdefinierte Daten nutzen, wie z. B. Data-Layer-Variablen und Ziele, die nur auf der Frontend-Seite gelten.
Lesen Sie zum besseren Verständnis der möglichen Anwendungsfälle diesen Artikel.
Standardmäßig ruft getRemoteVisitorData() die neuesten gespeicherten benutzerdefinierten Daten mit scope=Visitor ab und hängt sie an den Besucher an, ohne dass die Methode addData() aufgerufen werden muss. Diese Funktion ist besonders nützlich für Synchronisieren benutzerdefinierter Daten auf mehreren Geräten.
Parameter
Ein Objekt vom Typ RemoteVisitorDataParamsType mit den folgenden Eigenschaften:
Rückgabewert
Ausgelöste Ausnahmen
Parameter in getRemoteVisitorData() verwenden
Die Methode getRemoteVisitorData() bietet Flexibilität, indem Sie verschiedene Parameter beim Abrufen von Besucherdaten definieren können. Diese Methode kann auf Daten basierend auf Zielen, Experimenten oder Variationen abzielen, und derselbe Ansatz gilt für alle Datentypen.Wenn Sie beispielsweise Daten zu Besuchern abrufen möchten, die das Ziel “Order transaction” abgeschlossen haben, können Sie Parameter in der Methode getRemoteVisitorData() angeben, um Ihr Targeting zu verfeinern. Wenn Sie an Benutzern interessiert sind, die das Ziel in ihren letzten fünf Besuchen konvertiert haben, können Sie den Parameter previousVisitAmount auf 5 und conversions auf true festlegen.Die in diesem Beispiel gezeigte Flexibilität ist nicht auf Zieldaten beschränkt. Sie können Parameter in der Methode getRemoteVisitorData() verwenden, um Daten zu einer Vielzahl von Besucherverhalten abzurufen.
Hier ist die Liste der verfügbaren Filter vom Typ VisitorDataFiltersType:

getVisitorWarehouseAudience()

Die Methode getVisitorWarehouseAudience ist asynchron und ruft alle Zielgruppendaten ab, die sich auf einen Besucher aus Ihrem Data Warehouse beziehen. Um diese Methode zu verwenden, müssen Sie einen visitorCode und einen warehouseKey bereitstellen, die normalerweise Ihrer internen Benutzer-ID entsprechen. Der Parameter customDataIndex bezieht sich auf die benutzerdefinierten Daten, die Kameleoon verwendet, um Ihre Besucher ins Visier zu nehmen. Weitere Details finden Sie in der Dokumentation zum Data Warehouse-Targeting.
Parameter
Parameterobjekt bestehend aus:
Rückgabewert
Ausgelöste Ausnahmen

setLegalConsent()

Bei der Behandlung der rechtlichen Zustimmung ist es wichtig, dass Sie die Methode getVisitorCode aus der Klasse KameleoonClient verwenden, anstelle der veralteten Methode aus KameleoonUtils. Beachten Sie, dass diese Methode nicht domain als Argument benötigt. Stattdessen sollten Sie domain an den Konstruktor KameleoonClient übergeben. Siehe das vorherige Beispiel zur Verdeutlichung.
Die Methode setLegalConsent bestimmt, ob ein Besucher seiner rechtlichen Zustimmung zur Nutzung seiner personenbezogenen Daten zugestimmt hat. Wenn Sie den Parameter legalConsent auf false setzen, werden die Datentypen eingeschränkt, die Sie in Tracking-Anfragen einbeziehen können. Diese Maßnahme stellt sicher, dass Sie rechtliche und gesetzliche Anforderungen einhalten und Besucherdaten verantwortungsvoll verwalten. Weitere Informationen zu personenbezogenen Daten finden Sie unter Einwilligungsverwaltungsrichtlinie.
Parameter
Das Parameter-Objekt ist mit zwei Typen überlastet:
  • Typ SetLegalConsentParametersType (für NodeJS/Express/NextJS SSR methods), mit folgenden Feldern:
  • Typ SetNextJSLegalConsentParametersType (für NextJS SSR server actions), mit folgenden Feldern:
  • Typ SetDenoLegalConsentParametersType (für Deno), mit folgenden Feldern:
  • Typ SetCustomLegalConsentParametersType (für custom VisitorCodeManager implementation), mit folgenden Feldern:
Ausgelöste Ausnahmen
Verhalten bei Widerruf der Einwilligung
Wenn Sie setLegalConsent() mit consent=false aufrufen, löscht das SDK den Cookie kameleoonVisitorCode nicht. Stattdessen stoppt es die Verlängerung des Cookie-Ablaufdatums, wodurch der Cookie bestehen bleibt, bis er natürlich abläuft. Wenn Ihre Compliance-Anforderungen die sofortige Entfernung der Cookie-Datei bei der Abmeldung erfordern, müssen Sie diese manuell mit den nativen Cookie-Verwaltungsmethoden Ihres Frameworks löschen. Das SDK entfernt die Datei nicht automatisch.

Goals und Drittanbieter-Analysen

trackConversion()

  • 📨 Sendet Tracking-Daten an Kameleoon
Verwenden Sie diese Methode, um eine Konversion für ein spezifisches Ziel und einen Benutzer zu verfolgen. Diese Methode erfordert visitorCode und goalId. Darüber hinaus akzeptiert diese Methode auch optionale Argumente revenue, negative und metadata. Der visitorCode ist normalerweise identisch mit dem, der beim Triggern des Experiments verwendet wurde.Die Methode trackConversion() gibt keinen Wert zurück. Diese Methode ist nicht blockierend, da der Serveraufruf asynchron erfolgt.
Parameter
Parameterobjekt bestehend aus:
Metadaten-Werte sind über Raw-Data-Exporte und die Ergebnisseite zugänglich.Wenn der Parameter metadata angegeben ist, verwendet Kameleoon diese angegebenen Werte für die aktuelle Konversion statt dessen, was zuvor über die Methode addData() erfasst wurde. Wenn der Parameter weggelassen wird, verwendet Kameleoon die zuletzt verfolgten Werte für die CustomData vor der Konversion und innerhalb desselben Besuchs.Kameleoon berücksichtigt nur die Metadaten-Werte, die explizit als Parameter an die Methode trackConversion() übergeben werden.Im folgenden Beispiel assoziiert Kameleoon die Konversion nur mit dem Wert der benutzerdefinierten Daten, der explizit als Parameter übergeben wird (hier: Index 5 mit dem Wert ‘Amex Credit Card’).
Ausgelöste Ausnahmen

getEngineTrackingCode()

Kameleoon ist mit mehreren Analyselösungen integriert, 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 während der letzten fünf Sekunden ausgelöst hat. Wenn Sie diesen Code in die Seite einfügen, verarbeitet Engine.js die Befehle und sendet die Exposure-Events über die aktive Analyseintegration. Lesen Sie Hybridexperimentierung für weitere Informationen zur Implementierung dieser Methode.
  • Implementieren Sie sowohl das NodeJS SDK als auch Kameleoon Engine.js. Da Engine.js in diesem Workflow nur zum Tracking verwendet wird, können Sie das asynchrone Tag vor dem Closing-Tag </body> installieren.
  • Sie können den zurückgegebenen Tracking-Code direkt in ein HTML-Tag <script> einfügen.
In diesem Beispiel sind 123456 und 234567 Experiment-IDs, und 7890 und 8901 sind Variations-IDs. In Ihrer Implementierung generiert das SDK diese Werte im zurückgegebenen Tracking-Code.
Parameter
Rückgabewert
Ausgelöste Ausnahmen

Ereignisse

setEventHandler()

Verwenden Sie diese Methode, um einen Handler für SDK-Ereignisse zu registrieren. Das SDK ruft den Handler auf, wenn das ausgewählte Ereignis eintritt. Das Registrieren eines neuen Handlers für denselben Ereignistyp ersetzt den vorherigen Handler.Wenn Sie null als handler übergeben, wird der aktuelle Handler für den ausgewählten Ereignistyp entfernt.
DataFileUpdateEventDataType enthält Informationen über eine Aktualisierung der SDK-Datendatei.
Parameter

Datentypen

Kameleoon-Datentypen sind Hilfsklassen, die zum Speichern von Daten in vordefinierten Formularen verwendet werden. Während der Ausführung von flush() erfasst das SDK alle Daten und sendet sie zusammen mit der Tracking-Anfrage. Daten, die im SDK verfügbar sind, stehen nicht für Targeting und Reporting in der Kameleoon App zur Verfügung, bis Sie die Daten hinzufügen (z. B. durch die Verwendung der Methode addData()). Siehe Besuchsverlauf zum Targeting von Benutzern verwenden für weitere Informationen.
Wenn Sie Kameleoon im Hybrid-Modus verwenden, können Sie getRemoteVisitorData() aufrufen, um automatisch alle Daten auszufüllen, die Kameleoon zuvor erfasst hat.

Browser

Browser enthält browser information.
Jeder Besucher kann nur einen Browser haben. Das Hinzufügen eines zweiten Browser überschreibt den ersten.

UniqueIdentifier

UniqueIdentifier-Daten werden für die eindeutige Besucheridentifikation verwendet. Wenn Sie UniqueIdentifier für einen Besucher hinzufügen, wird visitorCode als eindeutige Besucher-ID verwendet, die nützlich für Geräteübergreifende Experimentierung ist. Das Verknüpfen von UniqueIdentifier mit einem Besucher informiert das SDK, dass dieser Besucher mit einem anderen Besucher verbunden ist. Der UniqueIdentifier-Parameter kann in bestimmten Grenzfällen vorteilhaft sein. Beispielsweise können Sie, wenn Sie nicht auf den anonymen visitorCode zugreifen können, der einem Besucher ursprünglich zugewiesen wurde, aber eine interne ID haben, die durch Session-Merging verknüpft ist, diesen Parameter verwenden.
Jeder Besucher kann nur eine UniqueIdentifier haben. Das Hinzufügen einer anderen UniqueIdentifier überschreibt die erste.

Conversion

Der Conversion-Datensatz, der hier gespeichert ist, kann verwendet werden, um Experiment- und Personalisierungsberichte nach beliebigen zugehörigen Zielen zu filtern.
  • Jeder Besucher kann mehrere Conversion-Objekte haben.
  • Sie finden die goalId in der Kameleoon-App.
ConversionParametersType conversionParameters - ein Objekt mit Konversionsparametern, die unten beschrieben sind
Cookie enthält Informationen zum Cookie, das auf dem Gerät des Besuchers gespeichert ist. Das NodeJS SDK erfordert nicht request oder response, um das Cookie zu extrahieren. Fügen Sie das Cookie stattdessen manuell mit Cookie-Daten hinzu.
Jeder Besucher kann nur ein Cookie haben. Das Hinzufügen eines zweiten Cookie überschreibt das erste.
Methoden
Cookie-Daten haben eine statische Utility-Methode fromString, die Ihnen beim Erstellen eines Cookies durch Parsing eines Strings mit gültigen Cookie-Daten helfen kann. Die Methode akzeptiert einen string als Parameter und gibt eine initialisierte Cookie-Instanz zurück.

GeolocationData

GeolocationData enthält der Besucher’s geolocation details.
Jeder Besucher kann nur eine GeolocationData haben. Das Hinzufügen einer zweiten GeolocationData überschreibt die erste.
Ein Parameterobjekt vom Typ GeolocationInfoType mit den folgenden Feldern:

CustomData

CustomData ermöglicht das einfache Verknüpfen beliebiger Datentypen mit jedem Besucher. Die Daten können dann als Targeting-Bedingung in Segmenten oder als Filter/Unterteilung in Experimentberichten verwendet werden. Weitere Informationen zu benutzerdefinierten Daten finden Sie in diesem Artikel. Um die benutzerdefinierten Daten bei zukünftigen Besuchen zu bewahren, sendet das SDK CustomData mit dem Visitor-Bereich mit der nächsten Tracking-Anfrage. Sie können den Bereich im Custom-Data-Dashboard festlegen.
  • Jeder Besucher darf nur ein CustomData für jeden eindeutigen index haben. Das Hinzufügen eines weiteren CustomData mit dem gleichen index ersetzt das vorhandene.
  • Der benutzerdefinierte Daten-Index finden Sie im Dashboard für benutzerdefinierte Daten in der Spalte “INDEX”.
  • Um zu verhindern, dass das SDK Daten mit dem ausgewählten Index aus Datenschutzgründen an Kameleoon-Server sendet, aktivieren Sie die Option: Diese Daten nur lokal für Targeting-Zwecke verwenden, wenn Sie benutzerdefinierte Daten erstellen.
  • Das Hinzufügen einer CustomData-Instanz, die mit einem Namen erstellt wurde, wenn die SDK-Instanz nicht initialisiert ist oder der Name nicht registriert ist, führt dazu, dass die Daten ignoriert werden.

Device

Device enthält Informationen über Ihr Gerät.
Jeder Besucher kann nur ein Device haben. Das Hinzufügen eines zweiten Device überschreibt das erste.

OperatingSystem

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

PageView

PageView enthält Informationen über Ihre Webseite.
Jeder Besucher kann eine PageView pro eindeutiger URL haben. Das Hinzufügen einer PageView mit der gleichen URL benachrichtigt das SDK, dass der Besucher die Seite erneut besucht hat.
PageViewParametersType pageViewParameters - ein Objekt mit Page-View-Parametern, die unten beschrieben sind
Sie finden den Referrer-Index oder die Referrer-ID in Ihrem Kameleoon-Konto. Beachten Sie, dass dieser Index bei 0 beginnt, d. h. der erste Akquisitionskanal, den Sie für eine bestimmte Website erstellen, wird als ID 0 zugewiesen, nicht 1.

UserAgent

UserAgent speichert Informationen zum User-Agent des Besuchers. Server-seitige Experimente sind anfälliger für Bot-Traffic als Client-seitige Experimente. Um dies zu beheben, verwendet Kameleoon die IAB/ABC International Spiders and Bots List, um bekannte Bots und Spiders zu identifizieren. Kameleoon verwendet auch das UserAgent-Feld, um Bots und anderen unerwünschten Traffic herauszufiltern, der sonst Ihre Konversionsmetriken verfälschen könnte. Weitere Informationen finden Sie im Hilfeartikel zum Bot-Filtern. Wenn Sie interne Bots verwenden, wird empfohlen, den Wert curl/8.0 des userAgent zu übergeben, um diese von Ihren Analysen auszuschließen.
Ein Besucher kann nur einen UserAgent haben. Das Hinzufügen eines zweiten UserAgent überschreibt den ersten.
Server-seitige Experimente sind anfälliger für Bot-Traffic als Client-seitige Experimente. Um dies zu beheben, verwendet Kameleoon die IAB/ABC International Spiders and Bots List, um bekannte Bots und Spiders zu identifizieren. Übergeben Sie den User-Agent, der von Kameleoon gefiltert werden soll, wenn Server-seitige Experimente für jeden Besucher durchgeführt werden, der Ihre Website besucht, um zu vermeiden, dass Bots in Ihren Analysen gezählt werden.Wenn Sie interne Bots verwenden, wird empfohlen, den Wert curl/8.0 des userAgent zu übergeben, um diese von Ihren Analysen auszuschließen.

ApplicationVersion

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

Rückgabetypen

DataFile

Die DataFile enthält die SDK-Konfigurationsdetails. Sie kann erweitert werden mit zusätzlichen Informationen, falls erforderlich. Wenn Sie weitere Informationen benötigen, wenden Sie sich an Ihren Customer Success Manager.

FeatureFlag

Das FeatureFlag stellt eine Reihe von Eigenschaften dar, die ein Feature Flag selbst definieren (beispielsweise dessen Variations, Rules, Umgebungsstatus und weitere zugehörige Details). Sie kann erweitert werden mit zusätzlichen Informationen, falls erforderlich. Wenn Sie weitere Informationen benötigen, wenden Sie sich an Ihren Customer Success Manager.

Rule

Die Rule stellt einen Satz von Eigenschaften dar, die eine Regel selbst definieren (z. B. deren Variations). Sie kann erweitert werden mit zusätzlichen Informationen, falls erforderlich. Wenn Sie weitere Informationen benötigen, wenden Sie sich an Ihren Customer Success Manager.

Variation

Variation enthält Informationen zur zugewiesenen Variation des Besuchers (oder zur Standardvariation, wenn keine spezifische Zuweisung vorhanden ist).
  • Stellen Sie sicher, dass Ihr Code den Fall handhabt, in dem id oder experimentId null sein können, was eine Standardvariation angibt.
  • Die variables-Zuordnung könnte 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.

Edge-Helfer

Diese Helper-Methoden sind hauptsächlich für kurzlebige oder Edge-artige Runtimes gedacht, bei denen das SDK eine explizite Revalidierung zwischen Anfragen benötigen kann.

refreshDataFileIfStale()

Die refreshDataFileIfStale()-Methode löst eine Revalidierung der Datendatei aus, nur wenn die aktuelle Konfiguration veraltet ist. Wenn die Datendatei noch gültig ist und das letzte Update vor weniger als dem konfigurierten updateInterval stattgefunden hat, gibt die Methode false zurück und es wird keine Aktualisierungsanfrage durchgeführt. Wenn die Datendatei veraltet ist, wartet die Methode, bis die Revalidierungsanfrage abgeschlossen ist, und gibt true zurück, wenn die Anfrage gestellt wurde. Die Rückgabe von true bedeutet, dass die Prüfung ausgeführt wurde, aber die Konfiguration selbst kann unverändert bleiben, z. B. wenn der Server meldet, dass die aktuelle Datendatei bereits aktuell ist.
Bei einer typischen langlebigen Node.js-Laufzeit wird die Verwendung dieser Methode im Allgemeinen nicht empfohlen, da das SDK die Datendatei während der Initialisierung und während der normalen Laufzeitausführung automatisch aktuell hält. Es kann in Edge-ähnlichen Umgebungen wie Cloudflare Workers immer noch hilfreich sein, wo sich das Laufzeitverhalten kurzlebiger ist und die Revalidierung möglicherweise explizit ausgelöst werden muss.
Rückgabewert

Veraltete Methoden

Diese Methoden sind veraltet und werden in der nächsten Hauptversion entfernt.

getFeatureFlagVariationKey()

Verwenden Sie stattdessen die Methode getVariation.
Die getFeatureFlagVariationKey()-Methode ruft den Variationsschlüssel für den angegebenen visitorCode in der entsprechenden Feature Flag ab. Diese Methode umfasst eine Targeting-Prüfung, findet die angemessene Variation, die dem Besucher ausgesetzt ist, speichert sie im Speicher und sendet eine Tracking-Anfrage.
Wenn ein Benutzer noch nicht zuvor einem Variationsschlüssel für die Feature Flag zugewiesen wurde, bestimmt das SDK zufällig eine Variation basierend auf den Regeln der Feature Flag. Wenn der Benutzer bereits mit der Feature Flag verknüpft ist, gibt das SDK den zuvor zugewiesenen Variationsschlüssel zurück. Wenn der Benutzer keine der angegebenen Regeln erfüllt, wird der in den Feature-Flag-Bereitstellungsregeln von Kameleoon definierte Standardwert zurückgegeben. Dieser Standardwert ist nicht immer ein Variationsschlüssel – es kann auch ein boolescher Wert oder ein anderer Datentyp sein, je nach der Konfiguration der Feature Flag.
Parameter
Rückgabewert
Ausgelöste Ausnahmen

getVisitorFeatureFlags()

Verwenden Sie stattdessen die Methode getVariations.
Die getVisitorFeatureFlags()-Methode gibt eine Liste von Feature Flags zurück, die für den Besucher mit dem angegebenen visitorCode aktiv sind und stellt sicher, dass dem Besucher eine der Variationen zugewiesen wird.
  • 🚫 Sendet keine Tracking-Daten an Kameleoon
  • 🎯 Ereignisse: EventType.Evaluation (für jedes Feature Flag)
Diese Methode sammelt nur die aktiven Feature Flags des Besuchers, d. h. das Ergebnis schließt alle Feature Flags aus, für die dem Besucher die off-Variation (Standard oder Kontrolle) zugewiesen ist.Zum Beispiel:
Verwenden Sie getFeatureFlags, wenn Sie alle Feature Flags des Besuchers benötigen:
Parameter
Rückgabewert
Ausgelöste Ausnahmen

getActiveFeatureFlags()

  • 🚫 Sendet keine Tracking-Daten an Kameleoon
  • 🎯 Ereignisse: EventType.Evaluation (für jedes Feature Flag)
Verwenden Sie stattdessen die Methode getVariations.
Die getActiveFeatureFlags()-Methode gibt eine Map zurück, wobei der Schlüssel den Feature-Schlüssel darstellt und der Wert detaillierte Informationen zur Variation und ihren Variablen des Besuchers enthält.
Diese Methode sammelt nur die aktiven Feature Flags des Besuchers, d. h. das Ergebnis schließt alle Feature Flags aus, für die dem Besucher die off-Variation (Standard oder Kontrolle) zugewiesen ist.Siehe den Abschnitt CAUTION (Vorsicht) der getVisitorFeatureFlags-Methode für weitere Details.
Parameter
Rückgabewert
Ausgelöste Ausnahmen

getFeatureFlagVariable()

Verwenden Sie stattdessen die Methode getVariation.
Die getFeatureFlagVariable()-Methode ruft eine Variable für den Besucher basierend auf dem visitorCode innerhalb der identifizierten Feature Flag ab. Diese Methode umfasst eine Targeting-Prüfung, bestimmt die angemessene Variation für den Besucher, speichert sie im Speicher und sendet eine Tracking-Anfrage.
Parameter
Parameters-Objekt vom Typ GetFeatureFlagVariableParamsType, das die folgenden Felder enthält:
Rückgabewert
Ausgelöste Ausnahmen

getFeatureFlagVariables()

  • 📨 Sendet Tracking-Daten an Kameleoon
  • 🎯 Ereignisse: EventType.Evaluation (für jedes Feature Flag)
Verwenden Sie stattdessen die Methode getVariation.
Die getFeatureFlagVariables()-Methode ruft eine Liste von Variablenwerten für einen angegebenen Besucher und eine Feature Flag ab. Diese Methode prüft, ob der Benutzer gezielt ist, identifiziert die zugewiesene Variation des Besuchers, speichert sie im Speicher und sendet eine Tracking-Anfrage.
Parameter
Rückgabewert
Ausgelöste Ausnahmen

onConfigurationUpdate()

Verwenden Sie stattdessen die Methode onEvent mit EventType.ConfigurationUpdate.
Die onConfigurationUpdate()-Methode wird bei einer Aktualisierung der Clientkonfiguration ausgelöst.
Diese Methode ist nur auf Server-Sent Events für Echtzeit-Updates anwendbar.
Parameter
Ausgelöste Ausnahmen

getFeatureFlags()

Verwenden Sie stattdessen die Methode getDataFile().
🚫 Sendet keine Tracking-Daten an Kameleoon Die getFeatureFlags()-Methode ruft eine Liste von Feature Flags ab, die in der Client-Konfiguration gespeichert sind.
Rückgabewert
Ausgelöste Ausnahmen

onEvent()

Verwenden Sie stattdessen setEventHandler().
Die Methode onEvent() führt einen Callback aus, wenn ein bestimmtes Ereignis ausgelöst wird. Die Callback-Funktion greift auf die mit dem Ereignis verknüpften Daten zu. Die SDK-Methoden in dieser Dokumentation vermerken, welche Ereignistypen diese auslösen, falls vorhanden.
Sie können jedem EventType nur einen Callback zuweisen.
Ereignisse
Ereignisse sind in der Aufzählung EventType definiert. Der Parameter eventData hat einen anderen Typ, je nach dem Ereignistyp.
Parameter
Ausgelöste Ausnahmen