Skip to main content
Vous pouvez exécuter des expériences et activer des feature flags avec le SDK NodeJS. L’intégration de notre SDK dans votre serveur est simple, et son empreinte (utilisation de la mémoire et du réseau) est faible. Notre SDK Node prend en charge Node version 16+ avec la possibilité de le rétrograder aux versions 14 et 12 en utilisant le mode de compatibilité. Premiers pas : pour obtenir de l’aide pour démarrer, consultez le guide du développeur. Méthodes du SDK : pour la documentation de référence complète du SDK NodeJS, consultez la référence section. Changelog : dernière version du SDK NodeJS : Changelog. Exemple Next.js : Pour des exemples d’intégration du SDK NodeJS avec Next.js, notamment App Router, Pages Router, middleware et server actions, consultez le dépôt de starter kits Next.js.
Avant de commencer l’installation de notre SDK NodeJS, nous vous recommandons de lire notre article sur les considérations techniques pour comprendre les concepts technologiques derrière nos SDK. Cet article vous aidera à assurer une intégration réussie.

Guide du développeur

Suivez cette section pour installer et configurer le SDK et en apprendre davantage sur les fonctionnalités avancées.

Premiers pas

Installation

Utilisez l’outil d’installation du SDK Kameleoon pour installer le SDK. L’installateur de SDK vous aide à installer le SDK de votre choix, à générer un exemple de code de base et à configurer les dépendances externes if needed. Pour utiliser l’outil d’installation du SDK, installez-le et exécutez-le globalement :
Ou exécutez-le directement avec npx:
Lors de l’utilisation de Deno, fournissez les dépendances manuellement dans deno.json:
deno.json

Initialisation du client Kameleoon

Les développeurs doivent créer un point d’entrée pour le SDK NodeJS en instanciant un nouveau KameleoonClient. Il est recommandé de traiter KameleoonClient comme un singleton, en créant une seule instance partagée et en la réutilisant dans toute l’instance du serveur pour garantir la cohérence et éviter une réinitialisation inutile. Utilisez KameleoonClient pour exécuter des expériences de feature flags et récupérer le statut des feature flags et leurs variations. KameleoonClient s’initialise de manière asynchrone pour s’assurer que la communication avec l’API Kameleoon réussit, en utilisant la initialize() méthode. Vous pouvez utiliser async/await, Promise.then(), ou tout autre modèle asynchrone pour gérer l’initialisation du client.
Pour ajouter le SDK NodeJS à un environnement Edge, veuillez consulter cette section.
Paramètres
Exceptions levées
Paramètres de configuration
Option 1 (Recommended): Utilisez JSON.stringify()
Option 2 : Chaîne JSON brute (échappez les caractères spéciaux)
Mode de compatibilité
Utilisez le paramètre SDK compatibility pour désactiver certaines fonctionnalités du SDK afin d’améliorer la compatibilité avec les anciennes versions de NodeJS. Compatibility est une énumération représentant tous les modes de compatibilité possibles :
  • Compatibility.Node16 - mode par défaut, toutes les fonctionnalités sont activées. Ce mode sera utilisé si aucun mode de compatibilité n’est fourni. Supporte la version 16 de Node et supérieures.
  • Compatibility.Node14 - la compatibilité avec cette version rendra le paramètre requestTimeout dans SDKConfigurationType indisponible et empêchera le SDK d’utiliser AbortController pour l’annulation de requêtes, même dans le délai par défaut de 10_000 ms. Supporte la version 14 de Node et supérieures.
  • Compatibility.Node12 - la compatibilité avec cette version implique les mêmes limitations que le mode de compatibilité Node14. De plus, vous ne pouvez pas fournir “@kameleoon/nodejs-requester” comme implémentation de demandeur dans ce mode de compatibilité, car il utilise la bibliothèque “node-fetch”, qui ne supporte pas la version Node.js 12.x.x. Un développeur doit fournir une implémentation de demandeur personnalisée de son choix, telle qu’une ancienne version de “node-fetch” ou une autre implémentation basée sur HTTP.

Activation d’un feature flag

Attribution d’un identifiant unique à un utilisateur
Pour attribuer un identifiant unique à un utilisateur, vous pouvez utiliser la méthode getVisitorCode(). Si un code visiteur n’existe pas (depuis le cookie des en-têtes de la requête), la méthode génère un identifiant unique aléatoire ou utilise un defaultVisitorCode que vous auriez généré. L’identifiant est alors défini dans un cookie des en-têtes de réponse. Si vous utilisez Kameleoon en mode hybride, appeler la méthode getVisitorCode() garantit que l’identifiant unique (code visiteur) est partagé entre le fichier d’application engine.js (précédemment nommé kameleoon.js) et le SDK.
Récupération de la configuration d’un flag
Pour implémenter un feature flag dans votre code, vous devez d’abord créer le feature flag dans votre compte Kameleoon. Pour déterminer le statut ou la variation d’un feature flag pour un utilisateur spécifique, vous devriez utiliser la méthode getVariation() ou isFeatureFlagActive() pour récupérer la configuration en fonction de la featureKey. La méthode getVariation() gère à la fois les feature flags simples avec des états ON/OFF et les flags plus complexes avec plusieurs variations. La méthode récupère la variation appropriée pour l’utilisateur en vérifiant les règles de feature, en assignant la variation et en la retournant en fonction de featureKey et visitorCode. La méthode isFeatureFlagActive() peut être utilisée si vous souhaitez récupérer la configuration d’une simple feature flag qui n’a que l’état ON ou OFF, par opposition aux feature flags plus complexes avec plusieurs variations ou options de ciblage. Si votre feature flag a des variables associées (telles que des comportements spécifiques liés à chaque variation), getVariation() vous permet également d’accéder à l’objet Variation, qui fournit des détails sur la variation assignée et l’expérience associée. Cette méthode vérifie si l’utilisateur est ciblé, trouve la variation assignée au visiteur et la sauvegarde dans le stockage. Quand track=true, le SDK enverra l’événement d’exposition à l’expérience spécifiée lors de la prochaine requête de suivi, qui est automatiquement déclenchée en fonction du tracking_interval_millisecond du SDK. Par défaut, cet intervalle est défini à 1 000 millisecondes (1 seconde). La méthode getVariation() vous permet de contrôler si le suivi est effectué. Si track=false, aucun événement d’exposition ne sera envoyé par le SDK. Cela est utile si vous préférez ne pas suivre les données via le SDK et préférez plutôt vous fier au suivi côté client géré par le moteur Kameleoon, par exemple. De plus, la définition de track=false est utile lorsque vous utilisez la méthode getVariations(), où vous pourriez ne besoin que des variations pour tous les flags sans déclencher d’événements de suivi. Si vous voulez en savoir plus sur le fonctionnement du suivi, consultez cet article
Ajout de points de données pour cibler un utilisateur ou filtrer/segmenter les visites dans les rapports
Pour cibler un utilisateur, assurez-vous d’avoir ajouté des points de données pertinents à son profil avant de récupérer la variation de feature flag ou de vérifier si le flag est actif. Utilisez la méthode addData() pour ajouter ces points de données au profil de l’utilisateur. Pour récupérer des points de données collectés sur d’autres appareils ou accéder aux données utilisateur passées (collectées côté client lors de l’utilisation de Kameleoon en mode Hybrid), utilisez la méthode getRemoteVisitorData(). Cette méthode récupère les données des serveurs de manière asynchrone. Il est important d’appeler getRemoteVisitorData() avant de récupérer la variation ou de vérifier si la feature flag est active, car cette donnée pourrait être nécessaire pour assigner un utilisateur à une variation donnée. Pour en savoir plus sur les conditions de ciblage disponibles, consultez l’article détaillé sur le sujet. De plus, les points de données que vous ajoutez au profil du visiteur seront disponibles lors de l’analyse de vos expériences, ce qui vous permet de filtrer et de ventiler vos résultats par des facteurs tels que l’appareil et le navigateur. Le mode hybride de Kameleoon collecte automatiquement une variété de points de données côté client, ce qui facilite la ventilation de vos résultats en fonction de ces points de données pré-collectés. Consultez la liste complète ici. Si vous avez besoin de suivre des points de données supplémentaires au-delà de ce qui est collecté automatiquement, vous pouvez utiliser la fonctionnalité Custom Data de Kameleoon. Custom Data vous permet de capturer et d’analyser des informations spécifiques pertinentes pour vos expériences. N’oubliez pas d’appeler la méthode flush() pour envoyer les données collectées aux serveurs Kameleoon pour analyse.
Pour assurer l’exactitude de vos résultats, il est recommandé de filtrer les bots en utilisant le type de données UserAgent.
Suivi des conversions d’objectifs
Lorsqu’un utilisateur effectue une action souhaitée (comme faire un achat), elle est enregistrée en tant que conversion. Pour suivre les conversions, utilisez la méthode trackConversion() et fournissez les paramètres visitorCode et goalId requis. La requête de suivi de conversion sera envoyée avec la prochaine requête de suivi planifiée, que le SDK envoie à intervalles réguliers (définis par tracking_interval_millisecond). Si vous préférez envoyer la requête immédiatement, utilisez la méthode flush() avec le paramètre instant=true.
Envoi d’événements aux solutions d’analyse
Pour suivre les conversions et envoyer des événements d’exposition à votre solution d’analyse client, vous devez d’abord implémenter Kameleoon en mode hybride. Ensuite, utilisez la méthode getEngineTrackingCode(). La méthode getEngineTrackingCode() récupère le code de suivi unique requis pour envoyer des événements d’exposition à votre solution d’analyse. Utiliser cette méthode vous permet d’enregistrer les événements et de les envoyer à votre plateforme d’analyse souhaitée.

Gestion des erreurs

Presque chaque méthode KameleoonClient peut lever une erreur à un moment donné. Ces erreurs sont des KameleoonError délibérément prédéfinies qui étendent la classe native JavaScript Error, fournissant des messages utiles et un champ type spécial de type KameleoonException. KameleoonException est une énumération contenant tous les types d’erreurs possibles. Pour savoir exactement quel type de KameleoonException la méthode peut lever, consultez la section Throws de la description de la méthode, ou survolez la méthode dans votre IDE pour voir la description jsdocs. La gestion des erreurs est considérée comme une bonne pratique pour rendre votre application plus stable et éviter les problèmes techniques.

Intégration avec les fournisseurs Edge

Kameleoon fournit les starter packs suivants pour automatiser votre intégration avec des fournisseurs edge spécifiques :Pour les autres fournisseurs edge, utilisez Dépendances externes pour un plus grand contrôle sur le SDK.

Expérimentation inter-appareils

Pour soutenir les visiteurs qui accèdent à une application depuis plusieurs appareils, Kameleoon permet la synchronisation des données de visiteur précédemment collectées sur chacun de ses appareils et la réconciliation de leur historique de visite sur les appareils grâce à l’expérimentation cross-device. Des études de cas et des informations détaillées sur la façon dont Kameleoon gère les données sur les appareils sont disponibles dans l’article sur l’expérimentation cross-device.

Synchronisation des données personnalisées entre appareils

Bien que la synchronisation de mappage personnalisé soit utilisée pour aligner les données du visiteur sur les appareils, ce n’est pas toujours nécessaire. Voici deux scénarios où la synchronisation de mappage personnalisé n’est pas requise : Same user ID across devices Si le même identifiant d’utilisateur est utilisé de façon cohérente sur tous les appareils, la synchronisation est gérée automatiquement sans synchronisation personnalisée. Il suffit d’appeler la méthode getRemoteVisitorData() quand vous souhaitez synchroniser les données collectées entre plusieurs appareils. Multi-server instances avec consistent IDs Dans les configurations complexes impliquant plusieurs serveurs (par exemple, des instances de serveur distribuées), où le même ID utilisateur est disponible sur les serveurs, la synchronisation entre les serveurs (avec getRemoteVisitorData()) est suffisante sans synchronisation de mappage personnalisé supplémentaire. Les clients qui ont besoin de données supplémentaires peuvent consulter la description de la méthode getRemoteVisitorData() pour des conseils supplémentaires. Dans le code ci-dessous, il est supposé que le même identifiant unique (dans ce cas, visitorCode, qui peut aussi être appelé userId) est utilisé de manière cohérente entre les deux appareils pour une récupération précise des données.
Si vous souhaitez synchroniser les données collectées en temps réel, vous devez choisir la portée Visiteur pour vos données personnalisées.
Device One
Device Two

Utilisation des données personnalisées pour la fusion de sessions

L’expérimentation cross-device vous permet de combiner l’historique d’un visiteur sur chacun de ses appareils (réconciliation d’historique). Vous pouvez fusionner plusieurs sessions de visiteur en une seule avec la réconciliation d’historique. Utilisez CustomData et fournissez un identifiant unique pour le visiteur afin de réconcilier l’historique de visite.Suivez le guide pour activer la réconciliation d’historique cross-device pour configurer vos données personnalisées dans Kameleoon.Vous pouvez utiliser les données personnalisées dans votre code pour fusionner la session d’un visiteur. Les sessions avec le même identifiant verront toujours la même variation d’expérience et seront affichées comme un seul visiteur dans la vue Visitor de la page de résultats de votre expérience.La configuration du SDK assure que les sessions associées voient toujours la même variation de l’expérience.Avant d’utiliser d’autres méthodes, informez le SDK que le visiteur est un identifiant unique en ajoutant les données UniqueIdentifier à un visiteur.
Puisque les données personnalisées que vous utilisez comme identifiant doivent être définies à la portée Visitor, vous devez utiliser la synchronisation des données personnalisées cross-device pour récupérer l’identifiant avec la méthode getRemoteVisitorData sur chaque appareil.
L’exemple suivant montre une application avec une page de connexion. Puisque l’identifiant utilisateur n’est pas connu au moment de la connexion, le code utilise un identifiant de visiteur anonyme généré par la méthode getVisitorCode. Après que l’utilisateur se connecte, vous pouvez associer le visiteur anonyme à l’identifiant utilisateur et l’utiliser comme identifiant unique pour le visiteur.
Login Page
Application Page

Utilisation d’une clé de bucketing personnalisée

Par défaut, Kameleoon utilise un identifiant de visiteur unique et anonyme (visitorCode) pour assigner les utilisateurs aux variations de feature flags. Cet identifiant est généralement généré et stocké sur l’appareil de l’utilisateur (dans un cookie de navigateur pour les SDKs côté client et côté serveur—dans le stockage persistant pour les SDKs mobiles). Cependant, dans certains scénarios vous pourriez avoir besoin de vous assurer que tous les utilisateurs de la même organisation voient la même variante d’une feature flag. L’option Custom Bucketing Key vous permet de remplacer ce comportement par défaut en fournissant votre propre identifiant personnalisé pour le bucketing. Ce remplacement garantit que la logique d’assignation de Kameleoon utilise votre clé spécifiée au lieu du visitorCode par défaut.

Cas d’utilisation

Utiliser une clé de bucketing personnalisée est essentiel pour maintenir la cohérence et la précision dans vos assignations de feature flags, particulièrement dans ces situations :
  • Expériences au niveau compte ou organisationnelles : Pour les produits B2B ou les scénarios où vous souhaitez assigner tous les utilisateurs de la même organisation à la même variation, vous pouvez utiliser un identifiant comme accountId. Les clés de bucketing personnalisées sont cruciales pour les tests A/B des fonctionnalités qui impactent une équipe entière ou une entreprise.
En implémentant une clé de bucketing personnalisée, vous assurez une plus grande cohérence et précision dans vos expériences, ce qui conduit à des résultats plus fiables et à une meilleure expérience utilisateur.

Détails techniques

Quand vous configurez une clé de bucketing personnalisée pour un feature flag, vous fournissez à Kameleoon un identifiant spécifique provenant des données de votre application :
  • Fournir la clé personnalisée : Vous fournissez votre identifiant personnalisé au SDK Kameleoon en utilisant la méthode addData(). Dans cette méthode, vous allez passer votre clé de bucketing personnalisée choisie en tant qu’objet CustomData. Ici, newVisitorCode fait référence à l’identifiant que vous souhaitez utiliser pour votre bucketing (par exemple, le nouveau userId ou accountId).
Pour que la clé de bucketing personnalisée fonctionne correctement, elle doit également être définie et configurée pour la feature flag lors du processus de création ou d’édition du flag. Sans cette configuration correspondante, le bucketing du SDK n’appliquera pas votre clé personnalisée. Pour des instructions détaillées sur comment configurer cela dans Kameleoon, consultez cet article.
  • Logique de bucketing : Une fois qu’une clé de bucketing personnalisée est fournie par la méthode addData(), tous les calculs de hash pour assigner les utilisateurs aux variations utiliseront ce newVisitorCode (votre clé personnalisée) au lieu du visitorCode par défaut. L’utilisation du newVisitorCode signifie que la décision de bucketing est liée à votre identifiant personnalisé, garantissant des assignations cohérentes dans divers contextes où cet identifiant est présent.
  • Suivi des données et analyse : Il est crucial de noter que tandis que le newVisitorCode (votre clé personnalisée) est utilisé pour les décisions de bucketing, toutes les données suivantes (événements de suivi et conversions, par exemple) sont envoyées et associées au visitorCode original. Cette séparation garantit que votre analyse reflète exactement les parcours utilisateur individuels et les interactions dans le contexte plus large de votre expérience, même lorsque le bucketing est effectué à un niveau supérieur (comme un compte) ou sur plusieurs appareils/sessions. Vos données de visiteur originales restent intactes pour un rapport complet.

Prérequis techniques

Pour utiliser efficacement une clé de bucketing personnalisée :
  • La clé doit être un string.
  • Elle doit être unique pour l’entité que vous avez l’intention de bucketer (par exemple, si vous utilisez un userId, chaque ID d’utilisateur devrait être unique).
  • La clé doit être disponible pour le SDK au moment exact où la décision de feature flag est évaluée pour cet utilisateur ou cette requête.

Conditions de ciblage

Les SDKs Kameleoon prennent en charge diverses conditions de ciblage prédéfinies que vous pouvez utiliser pour cibler les utilisateurs dans vos campagnes. Pour la liste des conditions prises en charge par ce SDK, consultez utiliser l’historique des visites pour cibler les utilisateurs. Vous pouvez également utiliser vos propres données externes pour cibler les utilisateurs.

Journalisation

Le SDK génère des journaux pour refléter les différents processus internes et problèmes.

Niveaux de journal

Le SDK prend en charge la configuration de la limitation de la journalisation par niveau de journal.

Gestion personnalisée des journaux

Le SDK écrit ses journaux dans la sortie console par défaut. Ce comportement peut être remplacé.
La limitation des journaux par un niveau de log est effectuée en dehors de la logique de gestion des journaux.

Informations de domaine

Vous fournissez un domaine comme domain dans la configuration de KameleoonClient, qui est utilisé pour stocker le code visiteur Kameleoon dans les cookies. Fournir un domaine est important lors du travail avec les méthodes getVisitorCode et setLegalConsent. Le domaine que vous fournissez est stocké dans le cookie comme clé Domain=.

Définition du domaine

Le domaine que vous fournissez permet à l’adresse URL d’utiliser le cookie. Par exemple, si votre domaine est www.example.com, le cookie n’est disponible que depuis une URL www.example.com. Les pages avec le domaine app.example.com ne peuvent pas utiliser le cookie. Pour plus de flexibilité avec les sous-domaines, vous pouvez spécifier un domaine commençant par un .. Par exemple, le domaine .example.com permet au cookie de fonctionner à la fois sur app.example.com et sur login.example.com.
Vous ne pouvez pas utiliser d’expressions régulières, de symboles spéciaux, de protocole ou de numéros de port dans le domain. De plus, une liste spécifique de sous-domaines ne peut pas être utilisée avec le préfixe ..
Voici un petit aide-mémoire sur les domaines :

Développement sur localhost

localhost est toujours considéré comme un mauvais domaine, ce qui rend difficile le test du domaine lors du développement sur localhost. Il y a deux façons d’éviter ce problème :
  • Ne spécifiez pas le champ domain dans le client SDK lors des tests. Cela empêche les problèmes de localhost (le cookie sera défini sur n’importe quel domaine).
  • Créez un domaine local pour localhost. Par exemple :
  • Naviguez vers /etc/hosts sur Linux ou vers c:\Windows\System32\Drivers\etc\hosts sur Windows
    • Ouvrez hosts avec les droits de super utilisateur ou administrateur de fichier
    • Ajoutez a domain vers le localhost port, par exemple: 127.0.0.1 app.com
    • Maintenant, vous pouvez exécuter votre application localement sur app.com:{my_port} et spécifier .app.com comme domaine

Dépendances externes

Les dépendances externes du SDK utilisent le modèle injection de dépendances, ce qui vous permet de fournir vos propres implémentations pour certaines parties d’un SDK.
Dans le SDK NodeJS, certaines dépendances externes ont des implémentations par défaut, tandis que d’autres doivent être fournies par l’utilisateur, qu’elles utilisent des implémentations Kameleoon dédiées ou des implémentations personnalisées.
Voici la liste des dépendances externes disponibles :
Vous pouvez également implémenter visitorCodeManager en utilisant the IExternalNextJSVisitorCodeManager, IExternalDenoVisitorCodeManager, ou IExternalCustomVisitorCodeManager interfaces for NextJS, Deno, ou custom visitor code manager implementations, respectively.
Les dépendances externes fournissent aux développeurs la flexibilité d’adapter et d’utiliser le SDK NodeJS dans n’importe quel environnement. Il y a un certain nombre de packages npm que Kameleoon fournit pour les environnements fréquemment utilisés. Vous pouvez installer les packages manuellement ou en utilisant l’outil d’installation du SDK (recommandé). Voici les dépendances externes fournies par Kameleoon pour le SDK NodeJS :
  • @kameleoon/nodejs-event-source - basé sur la bibliothèque eventsource (peut être utilisé pour NodeJS/Deno/NextJS SSR)
  • @kameleoon/nodejs-requester - basé sur la bibliothèque node-fetch (peut être utilisé pour NodeJS/Deno/NextJS SSR)
  • @kameleoon/nodejs-visitor-code-manager - implémenté avec un stockage en mémoire du serveur
  • @kameleoon/deno-visitor-code-manager - implémenté en utilisant Deno request/response cookies
  • @kameleoon/nextjs-visitor-code-manager - implémenté en utilisant NextJS SSR headers cookie ou NextJS SSR request/response
Vous pouvez éventuellement implémenter vous-même les dépendances externes. L’exemple suivant implémente les dépendances externes. Pour importer une interface d’un SDK, créez une classe qui l’implémente et transmettez la classe instanciée au SDK.

Stockage

EventSource

VisitorCodeManager

Implémentation de visitorCodeManager pour NodeJS/NextJS SSR :
Implémentation de visitorCodeManager pour Deno :
visitorCodeManager implémentation pour les actions serveur NextJS :
Implémentation personnalisée de visitorCodeManager avec des paramètres arbitraires :

Requester

Utilitaires

Le SDK a un ensemble de méthodes utilitaires que vous pouvez utiliser pour simplifier le développement. Toutes les méthodes sont représentées en tant que membres statiques de la classe KameleoonUtils.

simulateSuccessRequest

Utilisez la méthode simulateSuccessRequest pour simuler une requête réussie vers le serveur Kameleoon. Cette méthode peut être utile pour les implémentations personnalisées Requester quand un développeur doit simuler une requête réussie.
Paramètres
Le type de données SimulateRequestDataType est défini comme suit :
  • RequestType.Tracking - null
  • RequestType.ClientConfiguration - ClientConfigurationDataType
  • RequestType.RemoteData - JSONType
Valeur de retour

getCookieValue

Utilisez la méthode getCookieValue pour analyser une chaîne de cookie courante (key_1=value_1; key_2=value_2; ...) et obtenir la valeur d’une clé de cookie spécifique. Cette méthode est utile lors du travail avec une implémentation personnalisée de VisitorCodeManager.
Paramètres
Valeur de retour

Référence

Ceci est la documentation de référence complète pour le SDK JavaScript Kameleoon.

Initialisation

initialize()

Une méthode asynchrone pour initialiser KameleoonClient qui récupère les données du SDK Kameleoon soit depuis le serveur soit d’une source locale si les données sont toujours à jour ou l’intervalle de mise à jour n’a pas encore écoulé.
Valeur de retour
Exceptions levées

isReady()

isReady() vérifie si le SDK est prêt à être utilisé, c’est-à-dire que sa configuration a été chargée avec succès. Contrairement à initialize(), cette méthode renvoie immédiatement sans bloquer ni lever d’exception.
Une fois que le SDK est prêt, il le reste. Si un rafraîchissement ultérieur de la configuration échoue, le SDK continue d’utiliser la configuration précédemment téléchargée et ne revient pas à un état non prêt.
Valeur de retour

Feature flags et variations

getVariation()

  • 📨 Envoie les données de suivi à Kameleoon (selon le paramètre track)
Récupère la Variation attribuée à un visiteur donné pour un feature flag spécifique. Cette méthode prend featureKey comme argument obligatoire et track comme argument optionnel. L’argument track est optionnel et par défaut à true. Elle retourne la Variation attribuée pour le visiteur. Si le visiteur n’est pas associé à des règles de feature flag, la méthode retourne la Variation par défaut pour le feature flag donné. Assurez-vous qu’une gestion d’erreur appropriée est implémentée dans votre code pour gérer les exceptions potentielles.
La variation par défaut fait référence à la variation attribuée à un visiteur lorsqu’il ne correspond à aucune règle de livraison prédéfinie pour un feature flag. En d’autres termes, il s’agit de la variation de secours appliquée à tous les utilisateurs qui ne sont pas ciblés par des règles spécifiques. Elle est représentée comme la variation dans la section « Ensuite, pour tous les autres… » dans une interface de gestion.
Paramètres
Un objet de type GetVariationParamsType avec les propriétés suivantes :
Valeur de retour
Exceptions levées

getVariations()

  • 📨 Envoie les données de suivi à Kameleoon (selon le paramètre track)
  • 🎯 Événements : EventType.Evaluation
Récupère une carte d’objets Variation attribués à un visiteur donné pour tous les feature flags. Cette méthode itère sur tous les feature flags disponibles et retourne la Variation assignée pour chaque flag associé au visiteur spécifié. Elle prend visitorCode comme argument obligatoire, tandis que onlyActive et track sont optionnels.
  • Si onlyActive est défini sur true, la méthode getVariations() retournera les variations de feature flags à condition que l’utilisateur ne soit pas associé à la variation off.
  • Le paramètre track contrôle si la méthode suivra les assignations de variation. Par défaut, il est défini à true. S’il est défini à false, le suivi sera désactivé.
La carte retournée se compose des clés de feature flags comme clés et leurs Variation correspondantes comme valeurs. Si aucune variation n’est attribuée pour un feature flag, la méthode retourne la Variation par défaut pour ce flag. Une gestion d’erreur appropriée doit être implémentée pour gérer les exceptions potentielles.
La variation par défaut fait référence à la variation attribuée à un visiteur lorsqu’il ne correspond à aucune règle de livraison prédéfinie pour un feature flag. En d’autres termes, il s’agit de la variation de secours appliquée à tous les utilisateurs qui ne sont pas ciblés par des règles spécifiques. Elle est représentée comme la variation dans la section « Ensuite, pour tous les autres… » dans une interface de gestion.
Paramètres
Un objet de type GetVariationsParamsType avec les propriétés suivantes :
Valeur de retour
Exceptions levées

isFeatureFlagActive()

  • 📨 Envoie les données de suivi à Kameleoon (selon le paramètre track)
  • 🎯 Événements : EventType.Evaluation
La méthode isFeatureFlagActive() retourne un booléen indiquant si le visiteur avec visitorCode a un featureKey actif. Cette méthode vérifie le ciblage, trouve la variation pour le visiteur et la sauvegarde dans le stockage. La méthode envoie également une requête de suivi. Cette méthode a une surcharge supplémentaire qui vous permet de passer un paramètre track, qui désactive le suivi de l’évaluation de la fonctionnalité.
Un visiteur doit être ciblé pour que les feature flags s’activent.
Kameleoon utilise le suivi pour compter les sessions et les visiteurs lorsque vous appelez certaines méthodes, telles que isFeatureFlagActive(), getVariation() ou getVariations().Utilisez la valeur par défaut true pour le paramètre track quand vous exposez les visiteurs à une variation et avez besoin de les compter. Définissez le paramètre track à false uniquement si vous appelez ces méthodes avant d’exposer les visiteurs.Par exemple, si vous appelez getVariations() pour récupérer toutes les variations avant d’exposer les visiteurs, définissez le paramètre track à false. Cette configuration empêche Kameleoon de compter prématurément une session. Vous pouvez ensuite déclencher le suivi plus tard quand vous exposez explicitement le visiteur.Kameleoon envoie les données de suivi chaque seconde par défaut. Vous pouvez configurer cet intervalle jusqu’à 5 secondes en utilisant l’option de configuration de l’intervalle de suivi. Kameleoon regroupe les événements de suivi en une seule session tant que l’intervalle entre les événements est inférieur à 30 minutes. Si plus de 30 minutes s’écoulent entre les événements de suivi, Kameleoon compte les événements comme des sessions séparées. Une visite apparaît dans vos rapports 30 minutes après le dernier événement enregistré dans la session.
La méthode isFeatureFlagActive() évalue la variante servie, non l’état du flag maître. Si vous excluez les règles, la méthode utilise l’état par défaut Ensuite, pour tous les autres, servir. Si vous sélectionnez Désactivé pour cet état par défaut, la méthode retourne toujours false même lorsque le feature flag maître est Activé.
Paramètres
Il existe deux surcharges disponibles pour cette méthode :
  1. Surcharge de deux paramètres :
Cette surcharge est dépréciée et sera supprimée dans la prochaine version majeure. Utilisez la nouvelle surcharge avec un paramètre objet.
  1. Surcharge avec paramètre d’objet de type IsFeatureFlagActiveParamsType :
Valeur de retour
Exceptions levées

setForcedVariation()

La méthode vous permet d’attribuer programmatiquement une Variation spécifique à un utilisateur, contournant le processus d’évaluation standard. C’est particulièrement précieux pour les expériences contrôlées où la logique d’évaluation habituelle n’est pas requise ou doit être ignorée. Cela peut également être utile dans des scénarios comme le débogage ou les tests personnalisés. Lorsqu’une variation forcée est définie, elle annule la logique d’évaluation en temps réel de Kameleoon. Les processus tels que la segmentation, les conditions de ciblage et les calculs algorithmiques sont ignorés. Pour préserver la segmentation et les conditions de ciblage pendant une expérience, définissez forceTargeting=false à la place.
Les variations simulées prennent toujours la priorité dans l’ordre d’exécution. Si un calcul de variation simulée est déclenché, il sera entièrement traité et complété en premier.
Une variation forcée est traitée de la même manière qu’une variation évaluée. Elle est suivie dans l’analytique et stockée dans le contexte de l’utilisateur comme toute variation évaluée standard, garantissant la cohérence dans les rapports. La méthode peut lever des exceptions dans certaines conditions (par exemple, paramètres invalides, contexte utilisateur ou problèmes internes). La gestion appropriée des exceptions est essentielle pour garantir que votre application reste stable et résiliente.
Il est important de distinguer les variations forcées des variations simulées :
  • Variations forcées : sont spécifiques à une expérience individuelle.
  • Variations simulées : affectent le résultat global du feature flag.
Paramètres
Un objet de type SetForcedVariationParametersType avec les propriétés suivantes :
Exceptions levées
Dans la plupart des cas, seule l’erreur de base, KameleoonException, doit être gérée, comme démontré dans l’exemple. Cependant, si différents types d’erreurs nécessitent une réponse, gérez chacun séparément en fonction des exigences spécifiques. De plus, pour une fiabilité accrue, les erreurs de langage générales peuvent être gérées en incluant Error.

evaluateAudiences()

  • 📨 Envoie les données de suivi vers Kameleoon
Cette méthode évalue les visiteurs par rapport à tous les segments Audiences Explorer disponibles et suit ceux qui correspondent. evaluateAudiences() devrait être appelée après que toutes les données de visiteur pertinentes ont été définies ou mises à jour, et juste avant d’obtenir une variation de feature ou de vérifier un feature flag. Cette approche garantit que le visiteur est évalué par rapport aux données les plus actuelles disponibles, ce qui permet une attribution d’audience précise basée sur tous les critères. Après avoir appelé cette méthode, vous pouvez effectuer une analyse détaillée des performances des segments dans Audiences Explorer.
Paramètres
Exceptions levées
Dans la plupart des cas, seule l’erreur de base, KameleoonException, doit être gérée, comme démontré dans l’exemple. Cependant, si différents types d’erreurs nécessitent une réponse, gérez chacun séparément en fonction des exigences spécifiques. De plus, pour une fiabilité accrue, les erreurs de langage générales peuvent être gérées en incluant Error.

getDataFile()

Pour évaluer tous les feature flags, utilisez getVariations(). Cette méthode est plus efficace que d’appeler DataFile et d’itérer à travers les flags avec getVariation().
Retourne la configuration actuelle du SDK sous forme d’un objet DataFile.
Valeur de retour

Données du visiteur

getVisitorCode()

La méthode getVisitorCode récupère un code visiteur du cookie de la requête dans les en-têtes. Si le code visiteur n’existe pas, la méthode génère un nouveau code visiteur aléatoire ou utilise une valeur defaultVisitorCode fournie. Elle définit alors le nouveau code visiteur dans un cookie dans les en-têtes de réponse. Cette méthode utilise les types natifs de Node.js pour request et response, spécifiquement IncomingMessage et ServerResponse, importés du module http. Cependant, si vous utilisez le framework Express, Deno ou les méthodes de rendu côté serveur Next.js, comme getServerProps, les types pour request et response seront différents. Vous pouvez résoudre ce problème en utilisant le transtypage, qui produira des résultats identiques.
Lors de l’utilisation de getVisitorCode() avec Deno, Next.js SSR, Node ou Express, assurez-vous d’avoir implémenté les dépendances externes correctes.
La méthode getVisitorCode() vous permet de définir des variations simulées pour un visiteur. Lorsque les cookies (provenant d’une requête ou d’un document) contiennent la clé kameleoonSimulationFFData, le processus d’évaluation standard est contourné. Au lieu de cela, la méthode renvoie directement une Variation basée sur les données fournies.Vous pouvez appliquer des simulations de deux manières :
  • Automatiquement (recommandé): Si vous utilisez Kameleoon Web Experimentation ou le SDK en mode Hybride, le cookie est créé automatiquement lors de la simulation de l’affichage d’une variante en utilisant le Panneau de simulation.
  • Manuellement : Définissez le cookie kameleoonSimulationFFData manuellement.
Il est important de distinguer les variations simulées des variations forcées :
  • Variations simulées : affectent le résultat global du feature flag.
  • Variations forcées : sont spécifiques à une expérience individuelle.
⚙️ Manual setupAssurez-vous que le cookie kameleoonSimulationFFData suit ce format :
  • kameleoonSimulationFFData={"featureKey":{"expId":10,"varId":20}}: Simulates la variation avec varId of expérience expId pour le given featureKey.
  • kameleoonSimulationFFData={"featureKey":{"expId":0}}: Simule la variation par défaut (définie dans la section Ensuite, pour tous les autres en Production, servez) pour la featureKey donnée.
⚠️ Pour assurer le bon fonctionnement, le cookie doit être encodé en tant que composant URI en utilisant une méthode telle que encodeURIComponent.
Paramètres
L’objet des paramètres est surchargé avec deux types :
  • Type GetVisitorCodeParametersType (pour NodeJS/Express/NextJS SSR methods), contenant les champs suivants :
  • Type GetNextJSVisitorCodeParametersType (pour NextJS SSR server actions), contenant les champs suivants :
  • Type GetDenoVisitorCodeParametersType (pour Deno), contenant les champs suivants :
  • Type GetCustomVisitorCodeParametersType (pour l’implémentation personnalisée de VisitorCodeManager), contenant les champs suivants :
Si vous ne fournissez pas de defaultVisitorCode et qu’il n’y a pas de code visiteur stocké dans un cookie, le code visiteur sera généré aléatoirement.
Valeur de retour
Exceptions levées

addData()

Utilisez la méthode addData() pour ajouter les données de ciblage au stockage afin que d’autres méthodes puissent utiliser ces informations pour déterminer s’il faut cibler le visiteur actuel. La méthode addData() ne retourne aucune valeur et n’interagit pas directement avec les serveurs back-end de Kameleoon. À la place, toutes les données que la méthode collecte sont enregistrées pour une transmission future en utilisant la méthode flush(). Cette approche minimise le nombre d’appels serveur, car les données sont généralement groupées dans un seul appel serveur qui est activé par la méthode flush(). De plus, la méthode trackConversion() transmet toutes les données précédemment associées. Les méthodes getFeatureFlagVariationKey() et getFeatureFlagVariable() transmettent les données quand une règle d’expérimentation est déclenchée.
Chaque visiteur ne peut avoir qu’une seule instance de données associées pour la plupart des types de données ; cependant, CustomData est une exception, car les visiteurs peuvent avoir une instance de CustomData associée pour chaque customDataIndex.
Vérifiez la liste des conditions supportées pour voir les types de données que vous pouvez utiliser pour le ciblage.
Paramètres
  • kameleoonData est un argument variadique : il peut être passé comme un ou plusieurs arguments (voir l’exemple).
  • L’index ou l’ID des données personnalisées peut être trouvé dans votre compte Kameleoon. Notez que cet index commence à 0, ce qui signifie que les premières données personnalisées que vous créez pour un site donné se voient attribuer 0 comme ID, plutôt que 1.
Exceptions levées
Vérifiez la référence types de données pour plus de détails sur la façon de gérer différents types de données.

flush()

flush() prend les données Kameleoon associées au visiteur et planifie l’envoi des données avec la prochaine demande de suivi. Le moment de la prochaine demande de suivi est défini dans le paramètre trackingInterval de la configuration du SDK. Vous pouvez ajouter des données de visiteur en utilisant les méthodes addData() et getRemoteVisitorData().Le SDK enverra toutes les données stockées vers les serveurs Kameleoon distants si vous ne spécifiez pas de visitorCode. De plus, s’il y avait des demandes de suivi qui ont précédemment échoué et ont été stockées localement en mode hors ligne, le SDK tentera d’envoyer ces demandes stockées avant de traiter la dernière demande.
Si vous avez besoin d’envoyer immédiatement des demandes de suivi, utilisez flushInstant()—la version asynchrone de flush qui retourne Promise<void>. Vous pouvez utiliser await lorsque vous avez besoin de garanties de livraison (par exemple, avant de terminer un cycle requête/réponse), ou l’appeler sans await comme une demande de type fire-and-forget :
  • await client.flushInstant(visitorCode) envoie les demandes de suivi immédiatement pour un visiteur spécifique et attend la fin de l’exécution
  • await client.flushInstant() envoie les demandes de suivi immédiatement pour tous les visiteurs et attend la fin de l’exécution
Paramètres
Or un objet avec le type FlushParamsType, containing:
Exceptions levées

getRemoteData()

La méthode getRemoteData() récupère les données stockées sur un serveur Kameleoon distant pour un code de site spécifié. Par exemple, vous pouvez utiliser cette méthode pour accéder aux préférences de l’utilisateur, aux données historiques, ou à toute autre information pertinente à la logique de votre application. En stockant ces données sur les serveurs hautement scalables de Kameleoon en utilisant l’API de données, vous pouvez gérer efficacement de grands volumes de données et les récupérer pour chacun de vos visiteurs ou utilisateurs.
Paramètres
Valeur de retour
Exceptions levées

getRemoteVisitorData()

La méthode getRemoteVisitorData() est une fonction asynchrone qui récupère les données de visite Kameleoon pour un visitorCode spécifique à partir de l’API de données Kameleoon. Cette méthode stocke les données afin qu’elles puissent être accessibles lors de la prise de décisions de ciblage.Les données obtenues à travers cette méthode sont cruciales quand vous voulez :
  • Accéder aux données collectées à partir de plusieurs appareils.
  • Examiner l’historique d’un utilisateur, y compris les pages visitées lors des sessions précédentes.
  • Utiliser les données côté client, telles que les variables de couche de données et les objectifs qui sont uniquement applicables sur le front-end.
Pour une meilleure compréhension des cas d’utilisation potentiels, lisez cet article.
Par défaut, getRemoteVisitorData() récupère les dernières données personnalisées stockées avec scope=Visitor et les attache au visiteur sans avoir besoin d’appeler la méthode addData(). Cette fonctionnalité est particulièrement utile pour synchroniser les données personnalisées sur plusieurs appareils.
Paramètres
Un objet de type RemoteVisitorDataParamsType contenant :
Valeur de retour
Exceptions levées
Utilisation des paramètres dans getRemoteVisitorData()
La méthode getRemoteVisitorData() fournit de la flexibilité en vous permettant de définir différents paramètres lors de la récupération des données de visiteur. Cette méthode peut cibler les données en fonction des objectifs, des expériences ou des variations, et la même approche s’applique à tous les types de données.Par exemple, si vous souhaitez récupérer les données sur les visiteurs qui ont atteint l’objectif « Order transaction », vous pouvez spécifier des paramètres dans la méthode getRemoteVisitorData() pour affiner votre ciblage. Si vous êtes intéressé par les utilisateurs qui se sont convertis sur l’objectif au cours de leurs cinq dernières visites, vous pouvez définir le paramètre previousVisitAmount à 5 et conversions à true.La flexibilité affichée dans cet exemple ne se limite pas aux données d’objectif. Vous pouvez utiliser des paramètres dans la méthode getRemoteVisitorData() pour récupérer les données sur une variété de comportements des visiteurs.
Voici la liste des filtres VisitorDataFiltersType disponibles :

getVisitorWarehouseAudience()

La méthode getVisitorWarehouseAudience est asynchrone et récupère toutes les données d’audience relatives à un visiteur depuis votre entrepôt de données. Pour utiliser cette méthode, vous devrez fournir un visitorCode et une warehouseKey, qui correspondent généralement à votre ID utilisateur interne. Le paramètre customDataIndex fait référence aux données personnalisées que Kameleoon utilise pour cibler vos visiteurs. Pour plus de détails, reportez-vous à la documentation du ciblage d’entrepôt.
Paramètres
Objet Paramètres constitué de :
Valeur de retour
Exceptions levées

setLegalConsent()

Lors de la gestion du consentement légal, il est important d’utiliser la méthode getVisitorCode de la classe KameleoonClient, plutôt que la méthode dépréciée de KameleoonUtils. Notez que cette méthode n’exige pas le domain comme argument. À la place, vous devez transmettre le domain au constructeur KameleoonClient. Reportez-vous à l’exemple précédent pour clarification.
La méthode setLegalConsent détermine si un visiteur a donné son consentement légal pour l’utilisation de ses données personnelles. Si vous définissez le paramètre legalConsent sur false, cela restreint les types de données que vous pouvez inclure dans les demandes de suivi. Cette mesure garantit que vous respectez les exigences légales et réglementaires tout en gérant de manière responsable les données des visiteurs. Pour plus d’informations sur les données personnelles, reportez-vous à la politique de gestion du consentement.
Paramètres
Le parameters object is overloaded avec les types suivants:
  • Type SetLegalConsentParametersType (pour NodeJS/Express/NextJS SSR methods), contenant les champs suivants :
  • Type SetNextJSLegalConsentParametersType (pour NextJS SSR server actions), contenant les champs suivants :
  • Type SetDenoLegalConsentParametersType (pour Deno), contenant les champs suivants :
  • Type SetCustomLegalConsentParametersType (pour une implémentation VisitorCodeManager personnalisée), contenant les champs suivants :
Exceptions levées
Comportement de révocation du consentement
Lorsque vous appelez setLegalConsent() avec consent=false, le SDK ne supprime pas le cookie kameleoonVisitorCode. Au lieu de cela, il cesse d’étendre la date d’expiration du cookie, permettant au cookie de persister jusqu’à son expiration naturelle. Si vos exigences de conformité exigent la suppression immédiate du fichier de cookie lors du refus, vous devez le supprimer manuellement à l’aide des méthodes natives de gestion des cookies de votre framework. Le SDK ne supprimera pas le fichier automatiquement.

Objectifs et analyses tierces

trackConversion()

  • 📨 Envoie les données de suivi vers Kameleoon
Utilisez cette méthode pour suivre une conversion pour un objectif spécifique et un utilisateur. Cette méthode nécessite visitorCode et goalId. De plus, cette méthode accepte également les arguments optionnels revenue, negative et metadata. Le visitorCode est généralement identique à celui utilisé lors du déclenchement de l’expérience.La méthode trackConversion() ne retourne aucune valeur. Cette méthode n’est pas bloquante car l’appel au serveur est effectué de manière asynchrone.
Paramètres
Objet de paramètres constitué de :
metadatune valeurs are accessible à travers exports de données brutes et le résultats page.Si le paramètre metadata est fourni, Kameleoon utilisera ces valeurs spécifiées pour la conversion actuelle à la place de ce qui a été collecté précédemment en utilisant la méthode addData(). Si le paramètre est omis, Kameleoon utilisera les dernières valeurs suivies pour ces CustomData avant la conversion et dans la même visite.Kameleoon ne considérera que les valeurs de métadonnées qui sont explicitement transmises en tant que paramètres à la méthode trackConversion().Dans l’exemple ci-dessous, Kameleoon associera la conversion uniquement à la valeur de donnée personnalisée explicitement fournie en tant que paramètre (ici : index 5 avec la valeur « Amex Credit Card »).
Exceptions levées

getEngineTrackingCode()

Kameleoon s’intègre avec plusieurs solutions d’analyse, notamment Mixpanel, Google Analytics 4 et Segment. Pour suivre correctement les expériences côté serveur, appelez la méthode getEngineTrackingCode() après que le visiteur déclenche une expérience. Le SDK retourne des commandes de file d’attente JavaScript pour les expériences que le visiteur a déclenchées au cours des cinq secondes précédentes. Lorsque vous insérez ce code dans la page, Engine.js traite les commandes et envoie les événements d’exposition via l’intégration d’analyse active. Reportez-vous à l’expérimentation hybride pour plus d’informations sur la mise en œuvre de cette méthode.
  • Pour utiliser cette fonctionnalité, implémentez à la fois le SDK NodeJS et Kameleoon Engine.js. Comme Engine.js est utilisé uniquement pour le suivi dans ce flux, vous pouvez installer la balise asynchrone avant la balise de fermeture </body>.
  • Vous pouvez insérer directement le code de suivi retourné dans une balise HTML <script>.
Dans cet exemple, 123456 et 234567 sont les ID d’expérience, et 7890 et 8901 sont les ID de variation. Dans votre implémentation, le SDK génère ces valeurs dans le code de suivi retourné.
Paramètres
Valeur de retour
Exceptions levées

Événements

setEventHandler()

Utilisez cette méthode pour enregistrer un gestionnaire pour les événements du SDK. Le SDK appelle le gestionnaire quand l’événement sélectionné se produit. Enregistrer un nouveau gestionnaire pour le même type d’événement remplace le gestionnaire précédent.Passer null comme handler supprime le gestionnaire actuel pour le type d’événement sélectionné.
DataFileUpdateEventDataType contient des informations sur une mise à jour du fichier de données du SDK.
Paramètres

Types de données

Les types de données Kameleoon sont des classes d’aide utilisées pour stocker les données sous des formes prédéfinies. Lors de l’exécution de flush(), le SDK collecte toutes les données et les envoie avec la requête de suivi. Les données disponibles dans le SDK ne sont pas disponibles pour le ciblage et les rapports dans l’application Kameleoon tant que vous n’avez pas ajouté les données (par exemple, en utilisant la méthode addData()). Voir utiliser l’historique des visites pour cibler les utilisateurs pour plus d’informations.
Si vous utilisez Kameleoon en mode hybride, vous pouvez appeler getRemoteVisitorData() pour remplir automatiquement toutes les données que Kameleoon a précédemment collectées.

Browser

Browser contient browser information.
Chaque visiteur ne peut avoir qu’un seul Browser. L’ajout d’un deuxième Browser remplace le premier.

UniqueIdentifier

Les données UniqueIdentifier sont utilisées pour l’identification unique des visiteurs. Si vous ajoutez UniqueIdentifier pour un visiteur, visitorCode est utilisé comme identifiant unique du visiteur, ce qui est utile pour l’expérimentation cross-device. Lier un UniqueIdentifier à un visiteur informe le SDK que ce visiteur est associé à un autre visiteur. Le paramètre UniqueIdentifier peut être utile dans certains cas particuliers. Par exemple, si vous ne pouvez pas accéder au visitorCode anonyme initialement attribué à un visiteur, mais que vous disposez d’un ID interne lié via la fusion de sessions, ce paramètre est utile.
Chaque visiteur ne peut avoir qu’un seul UniqueIdentifier. L’ajout d’un autre UniqueIdentifier remplace le premier.

Conversion

L’ensemble de données Conversion stocké ici peut être utilisé pour filtrer les rapports d’expériences et de personnalisation par tout objectif associé à celui-ci.
  • Chaque visiteur peut avoir plusieurs objets Conversion.
  • Vous pouvez trouver le goalId dans l’application Kameleoon.
ConversionParametersType conversionParameters - un objet avec les paramètres de conversion décrits ci-dessous
Cookie contient des informations sur le cookie stocké sur l’appareil du visiteur. Le SDK NodeJS ne nécessite pas une request ou une response pour extraire le cookie. À la place, ajoutez le cookie manuellement en utilisant les données Cookie.
Chaque visiteur ne peut avoir qu’un seul Cookie. L’ajout d’un deuxième Cookie remplace le premier.
Méthodes
Les données Cookie ont une méthode utilitaire statique, fromString, qui peut vous aider à créer un cookie en analysant une chaîne qui contient des données de cookie valides. La méthode accepte string comme paramètre et retourne une instance Cookie initialisée.

GeolocationData

GeolocationData contient le visiteur’s geolocation details.
Chaque visiteur ne peut avoir qu’une seule GeolocationData. L’ajout d’une deuxième GeolocationData remplace la première.
Un paramètre objet avec le type GeolocationInfoType contient les champs suivants :

CustomData

CustomData permet à tout type de données d’être facilement associé à chaque visiteur. Il peut ensuite être utilisé comme condition de ciblage dans segments ou comme filtre/ventilation dans les rapports d’expériences. Pour en savoir plus sur les données personnalisées, reportez-vous à cet article. Pour maintenir les données personnalisées lors des visites futures, le SDK envoie CustomData avec la portée Visitor avec la prochaine requête de suivi. Vous pouvez définir la portée dans le tableau de bord des données personnalisées.
  • Chaque visiteur n’est autorisé à avoir qu’une seule CustomData pour chaque index unique. L’ajout d’une autre CustomData avec le même index remplacera celle existante.
  • L’« index » des données personnalisées se trouve dans le tableau de bord Données personnalisées sous la colonne « INDEX ».
  • Pour empêcher le SDK d’envoyer des données avec l’index sélectionné aux serveurs Kameleoon pour des raisons de confidentialité, activez l’option : Utiliser ces données uniquement localement à des fins de ciblage lors de la création de données personnalisées.
  • L’ajout d’une instance CustomData créée avec un nom lorsque l’instance SDK n’est pas initialisée ou que le nom n’est pas enregistré entraînera l’ignorance des données.

Device

Device contient les informations sur votre appareil.
Chaque visiteur ne peut avoir qu’un seul Device. Ajouter un second Device remplace le premier.

OperatingSystem

OperatingSystem contient des informations sur le système d’exploitation du visiteur.
Chaque visiteur ne peut avoir qu’un seul OperatingSystem. L’ajout d’un deuxième OperatingSystem remplace le premier.

PageView

PageView contient les informations sur votre page Web.
Chaque visiteur peut avoir une PageView par URL unique. L’ajout d’une PageView avec la même URL notifie le SDK que le visiteur a revisité la page.
PageViewParametersType pageViewParamètres—un objet avec les paramètres d’affichage de page décrits ci-dessous
Vous pouvez trouver l’index ou l’ID du référent dans votre compte Kameleoon. Notez que cet index commence à 0, ce qui signifie que le premier canal d’acquisition que vous créez pour un site donné se verra attribuer 0 comme ID, et non 1.

UserAgent

UserAgent stocke les informations sur l’agent utilisateur du visiteur. Les expériences côté serveur sont plus vulnérables au trafic de bots que les expériences côté client. Pour résoudre ce problème, Kameleoon utilise la liste internationale des araignées et bots IAB/ABC pour identifier les bots et araignées connus. Kameleoon utilise également le champ UserAgent pour filtrer les bots et autres trafics indésirables qui pourraient autrement fausser vos métriques de conversion. Pour plus de détails, consultez l’article d’aide sur le filtrage des bots. Si vous utilisez des bots internes, nous vous suggérons de transmettre la valeur curl/8.0 du userAgent pour les exclure de votre analyse.
Un visiteur ne peut avoir qu’un seul UserAgent. L’ajout d’un second UserAgent remplace le premier.
Les expériences côté serveur sont plus vulnérables au trafic de bots que les expériences côté client. Pour résoudre ce problème, Kameleoon utilise la liste des araignées et bots internationales IAB/ABC pour identifier les bots et araignées connus. Nous recommandons de transmettre l’agent utilisateur à filtrer par Kameleoon lors de l’exécution d’expériences côté serveur pour chaque visiteur naviguant sur votre site Web, afin d’éviter de compter les bots dans vos analyses.Si vous utilisez des bots internes, nous vous suggérons de transmettre la valeur curl/8.0 du userAgent pour les exclure de votre analyse.

ApplicationVersion

ApplicationVersion représente le numéro de version sémantique de votre application.
Un visiteur ne peut avoir qu’un seul ApplicationVersion. L’ajout d’une seconde instance remplacera la première.

Types retournés

DataFile

Le DataFile contient les détails de la configuration du SDK. Il peut être étendu avec des informations supplémentaires si nécessaire par les clients. Si vous avez besoin de plus de détails, contactez votre responsable du succès client.

FeatureFlag

Le FeatureFlag représente un ensemble de propriétés qui définissent un feature flag lui-même (par exemple, ses Variations, Rules, statut de l’environnement et autres détails connexes). Il peut être étendu avec des informations supplémentaires si nécessaire par les clients. Si vous avez besoin de plus de détails, contactez votre responsable du succès client.

Rule

Le Rule représente un ensemble de propriétés qui définissent une règle elle-même (par exemple, ses Variations). Il peut être étendu avec des informations supplémentaires si nécessaire par les clients. Si vous avez besoin de plus de détails, contactez votre responsable du succès client.

Variation

Variation contient les informations sur la variation assignée au visiteur (ou la variation par défaut, si aucune affectation spécifique n’existe).
  • Assurez-vous que votre code gère le cas où id ou experimentId peut être null, indiquant une variation par défaut.
  • Le mappage variables peut être vide si aucune variable n’est associée à la variation.

Variable

Variable contient des informations sur une variable associée à la variation assignée.

Aides Edge

Ces méthodes d’aide sont principalement destinées aux runtimes de courte durée ou de type edge où le SDK peut nécessiter une revalidation explicite entre les requêtes.

refreshDataFileIfStale()

La méthode refreshDataFileIfStale() déclenche une revalidation du fichier de données uniquement lorsque la configuration actuelle est obsolète. Si le fichier de données est toujours valide et que la dernière mise à jour s’est produite il y a moins que updateInterval, la méthode retourne false et aucune requête n’est effectuée. Si le fichier de données est obsolète, la méthode attend la fin de la requête de revalidation et retourne true lorsque la requête a été effectuée. Retourner true signifie que la vérification a été exécutée, mais la configuration elle-même peut encore rester inchangée, par exemple lorsque le serveur signale que le fichier de données actuel est déjà à jour.
Dans un runtime Node.js typique de longue durée, l’utilisation de cette méthode n’est généralement pas recommandée, car le SDK maintient déjà le fichier de données à jour automatiquement lors de l’initialisation et de l’exécution normale. Elle peut toujours être utile dans les environnements de type edge tels que Cloudflare Workers, où le comportement du runtime est plus éphémère et la revalidation peut avoir besoin d’être déclenchée explicitement.
Valeur de retour

Méthodes obsolètes

Ces méthodes sont dépréciées et seront supprimées dans la prochaine mise à jour majeure.

getFeatureFlagVariationKey()

Utilisez plutôt la méthode getVariation.
La méthode getFeatureFlagVariationKey() récupère la clé de variation pour le visitorCode spécifié dans le feature flag correspondant. Cette méthode comprend une vérification de ciblage, la recherche de la variation appropriée exposée au visiteur, son enregistrement dans le stockage et l’envoi d’une requête de suivi.
Si un utilisateur n’a pas été précédemment assigné à une clé de variation pour le feature flag, le SDK déterminera aléatoirement une variation basée sur les règles du feature flag. Si l’utilisateur est déjà lié au feature flag, le SDK retournera sa clé de variation précédemment assignée. Si l’utilisateur ne répond à aucune des règles spécifiées, la valeur par défaut définie dans les règles de livraison du feature flag de Kameleoon sera retournée. Cette valeur par défaut n’est pas toujours une clé de variation—elle peut également être un booléen ou un autre type de données, selon la configuration du feature flag.
Paramètres
Valeur de retour
Exceptions levées

getVisitorFeatureFlags()

Utilisez plutôt la méthode getVariations.
La méthode getVisitorFeatureFlags() retourne une liste de feature flags actifs pour le visiteur avec le visitorCode spécifié, en veillant à ce que le visiteur soit alloué à l’une des variations.
  • 🚫 N’envoie pas de données de suivi vers Kameleoon
  • 🎯 Événements : EventType.Evaluation (pour chaque feature flag)
Cette méthode ne collecte que les feature flags actifs du visiteur, ce qui signifie que le résultat exclut tous les feature flags pour lesquels le visiteur est assigné à la variation off (par défaut ou contrôle).Par exemple :
Utilisez getFeatureFlags lorsque vous avez besoin de tous les feature flags du visiteur :
Paramètres
Valeur de retour
Exceptions levées

getActiveFeatureFlags()

  • 🚫 N’envoie pas de données de suivi vers Kameleoon
  • 🎯 Événements : EventType.Evaluation (pour chaque feature flag)
Utilisez plutôt la méthode getVariations.
La méthode getActiveFeatureFlags() retourne une Map, où la clé représente la clé du feature, et la valeur contient des informations détaillées sur la variation du visiteur et ses variables.
Cette méthode ne collecte que les feature flags actifs du visiteur, ce qui signifie que le résultat exclut tous les feature flags pour lesquels le visiteur est assigné à la variation off (par défaut ou contrôle).Consultez la section CAUTION de la méthode getVisitorFeatureFlags pour plus de détails.
Paramètres
Valeur de retour
Exceptions levées

getFeatureFlagVariable()

Utilisez plutôt la méthode getVariation.
La méthode getFeatureFlagVariable() récupère une variable pour le visiteur basée sur le visitorCode dans le feature flag identifié. Cette méthode comprend une vérification de ciblage, détermine la variation appropriée pour le visiteur, l’enregistre dans le stockage et envoie une requête de suivi.
Paramètres
Objet Parameters de type GetFeatureFlagVariableParamsType contenant les champs suivants :
Valeur de retour
Exceptions levées

getFeatureFlagVariables()

  • 📨 Envoie les données de suivi vers Kameleoon
  • 🎯 Événements : EventType.Evaluation (pour chaque feature flag)
Utilisez plutôt la méthode getVariation.
La méthode getFeatureFlagVariables() récupère une liste de valeurs de variables pour un visiteur spécifié et un feature flag. Cette méthode vérifie si l’utilisateur est ciblé, identifie la variation assignée du visiteur, l’enregistre et envoie une requête de suivi.
Paramètres
Valeur de retour
Exceptions levées

onConfigurationUpdate()

Utilisez le onEvent method avec EventType.ConfigurationUpdate instead.
La méthode onConfigurationUpdate() déclenche un callback lors de la mise à jour de la configuration du client.
Cette méthode n’est applicable que pour les événements envoyés par le serveur pour les mises à jour en temps réel.
Paramètres
Exceptions levées

getFeatureFlags()

Utilisez le getDataFile() method instead.
🚫 N’envoie pas les données de suivi à Kameleoon La méthode getFeatureFlags() récupère une liste de feature flags qui sont stockés dans la configuration du client.
Valeur de retour
Exceptions levées

onEvent()

Utilisez setEventHandler() à la place.
La méthode onEvent() déclenche un rappel quand un événement spécifique est déclenché. La fonction de rappel accède aux données associées à l’événement. Les méthodes du SDK dans cette documentation indiquent les types d’événement qu’elles déclenchent, le cas échéant.
Vous ne pouvez assigner qu’un seul rappel à chaque EventType.
Événements
Les événements sont définis dans l’énumération EventType. Le paramètre eventData aura un type différent selon le type d’événement.
Paramètres
Exceptions levées