Skip to main content
Avec le SDK JavaScript de Kameleoon, vous pouvez exécuter des expériences et activer des feature flags. L’intégration de notre SDK dans votre application web est simple, et son empreinte (utilisation de la mémoire et du réseau) est faible. Premiers pas : pour obtenir de l’aide pour démarrer, consultez le guide du développeur. Changelog : les détails sur la dernière version du SDK JavaScript / TypeScript sont disponibles dans le changelog. Méthodes du SDK : pour la documentation de référence complète du SDK JavaScript, consultez la section référence.

Guide du développeur

Cette section vous aidera à démarrer et vous présentera certains des concepts les plus avancés.

Premiers pas

Installation

L’outil d’installation du SDK Kameleoon est la meilleure méthode pour installer rapidement 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 si nécessaire. Pour utiliser l’outil d’installation du SDK, installez-le et exécutez-le globalement :
Ou exécutez-le directement avec npx :
Vous pouvez également injecter le SDK JavaScript dans votre application sous forme de fichier unique en utilisant la balise <script>. Vous pouvez ensuite accéder à toutes les méthodes du SDK via l’objet global KameleoonSDK.Exemple :
index.html
app.js
Pour toujours utiliser la dernière version d’une version majeure, utilisez le script suivant, où 4 est la version majeure actuelle :
Pour rester sur une version spécifique, indiquez à la place le numéro de version complet. Par exemple, pour la version 4.24.0, qui est la version la plus ancienne disponible sous forme de script statique, utilisez ce qui suit :
Les versions peuvent être référencées sur la page des releases.
Par défaut, le script statique utilise le bundle SDK optimisé, dans lequel les messages de log INFO et DEBUG sont supprimés pour réduire la taille du bundle.Si vous utilisez KameleoonLogger.setLogLevel(LogLevel.DEBUG) ou KameleoonLogger.setLogLevel(LogLevel.INFO), utilisez à la place le script statique full.

Initialiser le client Kameleoon

Voici un guide étape par étape pour configurer le SDK JavaScript pour votre application.
Pour commencer, les développeurs doivent créer un point d’entrée pour le SDK JavaScript en créant une nouvelle instance de Kameleoon Client. Utilisez KameleoonClient pour exécuter des expériences de feature et récupérer l’état des feature flags et de leurs variations. L’initialisation de KameleoonClient est effectuée de manière asynchrone afin de s’assurer que l’appel à l’API Kameleoon a réussi. Pour l’initialisation, utilisez la méthode initialize(). Utilisez async/await, Promise.then() ou toute autre méthode pour gérer l’initialisation asynchrone du client.
Arguments
Paramètres de configuration
Option 1 (recommandée) : utilisez JSON.stringify()
Option 2 : chaîne JSON brute (échapper les caractères spéciaux)
N’utilisez pas plusieurs instances de client dans une même application, car ce n’est pas encore totalement pris en charge. Plusieurs instances de client peuvent entraîner l’écrasement de la configuration du stockage local et provoquer des bugs.

Activation d’un feature flag

Attribution d’un ID unique à un utilisateur
Pour attribuer un ID unique à un utilisateur, vous pouvez utiliser la méthode getVisitorCode(). Si un visitor code n’existe pas (depuis le cookie des en-têtes de requête), la méthode génère un ID unique aléatoire ou utilise un defaultVisitorCode que vous auriez généré. L’ID est ensuite défini dans un cookie des en-têtes de réponse. Si vous utilisez Kameleoon en mode hybride, l’appel à la méthode getVisitorCode() garantit que l’ID unique (visitor code) est partagé entre le fichier d’application engine.js (anciennement 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 l’état ou la variation d’un feature flag pour un utilisateur spécifique, vous devez utiliser la méthode getVariation() ou isFeatureFlagActive() afin de récupérer la configuration basée sur 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 la feature, en attribuant la variation, et en la renvoyant en fonction de la featureKey et du visitorCode. La méthode isFeatureFlagActive() peut être utilisée si vous souhaitez récupérer la configuration d’un feature flag simple n’ayant qu’un état ON ou OFF, par opposition aux feature flags plus complexes avec plusieurs variations ou options de ciblage. If your feature flag has associated variables (such as specific behaviors tied to each variation) getVariation() also enables you to access the Variation object, which provides details about the assigned variation and its associated experiment. This method checks whether the user is targeted, finds the visitor’s assigned variation, and saves it to storage. When track=true, the SDK will send the exposure event to the specified experiment on the next tracking request, which is automatically triggered based on the SDK’s tracking_interval_millisecond. By default, this interval is set to 1000 milliseconds (1 second). The getVariation() method allows you to control whether tracking is done. If track=false, no exposure events will be sent by the SDK. This is useful if you prefer not to track data through the SDK and instead rely on client-side tracking managed by the Kameleoon engine, for example. Additionally, setting track=false is helpful when using the getVariations() method, where you might only need the variations for all flags without triggering any tracking events. If you want to know more about how tracking works, view this article
Ajout de data points pour cibler un utilisateur ou filtrer / décomposer les visites dans les rapports
Pour cibler un utilisateur, assurez-vous d’avoir ajouté à son profil les data points pertinents avant de récupérer la variation de la feature ou de vérifier si le flag est actif. Utilisez la méthode addData() pour ajouter ces data points au profil de l’utilisateur. Pour récupérer les data points collectés sur d’autres appareils ou pour accéder aux données utilisateur passées (collectées côté client lorsque vous utilisez Kameleoon en mode hybride), utilisez la méthode getRemoteVisitorData(). Cette méthode récupère les données depuis les serveurs de manière asynchrone. Il est important d’appeler getRemoteVisitorData() avant de récupérer la variation ou de vérifier si le feature flag est actif, car ces données peuvent être nécessaires pour attribuer 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 data points que vous ajoutez au profil visiteur seront disponibles lors de l’analyse de vos expériences, vous permettant de filtrer et de décomposer vos résultats selon des facteurs tels que l’appareil et le navigateur. Le mode hybride de Kameleoon collecte automatiquement une variété de data points côté client, facilitant ainsi la décomposition de vos résultats sur la base de ces data points pré-collectés. Consultez la liste complète ici. Si vous devez suivre des data points supplémentaires au-delà de ceux collectés automatiquement, vous pouvez utiliser la fonctionnalité Custom Data de Kameleoon. Les Custom Data vous permettent 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 garantir 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 un achat), celle-ci est enregistrée comme une conversion. Pour suivre les conversions, utilisez la méthode trackConversion() et fournissez les paramètres requis visitorCode et goalId. La requête de tracking de conversion sera envoyée avec la prochaine requête de tracking planifiée, que le SDK envoie à intervalles réguliers (défini 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 vers des solutions analytics
Pour suivre les conversions et envoyer les événements d’exposition à votre solution d’analytics 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 tracking unique nécessaire pour envoyer les événements d’exposition à votre solution d’analytics. L’utilisation de cette méthode vous permet d’enregistrer les événements et de les envoyer vers la plateforme d’analytics de votre choix.

Utilisation d’une clé de bucketing personnalisée

Par défaut, Kameleoon utilise un ID visiteur unique et anonyme (visitorCode) pour attribuer les utilisateurs aux variations de feature flag. Cet ID est généralement généré et stocké sur l’appareil de l’utilisateur (dans un cookie de navigateur pour les SDK côté client et côté serveur — dans un stockage persistant pour les SDK mobiles). Cependant, dans certains scénarios, vous pouvez avoir besoin de garantir que tous les utilisateurs d’une même organisation voient la même variante d’un feature flag. L’option clé de bucketing personnalisée 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’attribution de Kameleoon utilise la clé que vous avez spécifiée à la place du visitorCode par défaut.

Cas d’usage

L’utilisation d’une clé de bucketing personnalisée est essentielle pour maintenir la cohérence et l’exactitude de vos attributions de feature flag, en particulier dans les situations suivantes :
  • Expériences au niveau du compte ou organisationnelles : pour les produits B2B ou les scénarios dans lesquels vous souhaitez attribuer tous les utilisateurs d’une même organisation à la même variation, vous pouvez utiliser un identifiant comme un accountId. Les clés de bucketing personnalisées sont essentielles pour les fonctionnalités d’A/B test qui impactent une équipe ou une entreprise entière.
En implémentant une clé de bucketing personnalisée, vous garantissez une meilleure cohérence et exactitude de vos expériences, conduisant à des résultats plus fiables et à une meilleure expérience utilisateur.

Détails techniques

Lorsque 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 :
  • Fourniture de la clé personnalisée : vous fournissez votre identifiant personnalisé au SDK Kameleoon en utilisant la méthode addData(). Dans cette méthode, vous transmettrez votre clé de bucketing personnalisée choisie sous forme d’objet CustomData. Ici, newVisitorCode fait référence à l’identifiant que vous souhaitez utiliser pour votre bucketing (par exemple, le nouvel userId ou accountId).
Pour que la clé de bucketing personnalisée fonctionne correctement, elle doit également être définie et configurée pour le feature flag lors du processus de création ou de modification du flag. Sans cette configuration correspondante, le bucketing du SDK n’appliquera pas votre clé personnalisée. Pour des instructions détaillées sur la façon de configurer cela dans Kameleoon, consultez cet article.
  • Logique de bucketing : une fois qu’une clé de bucketing personnalisée est fournie via la méthode addData(), tous les calculs de hash pour attribuer les utilisateurs aux variations utiliseront ce newVisitorCode (votre clé personnalisée) à la place du visitorCode par défaut. L’utilisation de newVisitorCode signifie que la décision de bucketing est liée à votre identifiant personnalisé, garantissant des attributions cohérentes dans les différents contextes où cet identifiant est présent.
  • Tracking des données et analytics : il est crucial de noter que, bien que newVisitorCode (votre clé personnalisée) soit utilisé pour les décisions de bucketing, toutes les données ultérieures (événements de tracking et conversions, par exemple) sont envoyées et associées au visitorCode original. Cette séparation garantit que votre analytics reflète fidèlement les parcours et les interactions individuels des utilisateurs 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 visiteur d’origine restent intactes pour un reporting complet.

Exigences techniques

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

Conditions de ciblage

Les SDK 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.

Logging

Le SDK génère des logs pour refléter divers processus et problèmes internes.

Niveaux de log

Le SDK permet de configurer la limitation du logging par niveau de log.

Gestion personnalisée des logs

Par défaut, le SDK écrit ses logs vers la sortie console. Ce comportement peut être remplacé.
La limitation du logging par niveau de log est effectuée séparément de la logique de gestion des logs.

Informations sur le domaine

Vous fournissez un domaine comme domain dans la configuration de KameleoonClient, qui est utilisé pour stocker le visitor code Kameleoon dans les cookies. Les domaines sont importants lorsque vous travaillez avec les méthodes getVisitorCode et setLegalConsent. Le domaine que vous fournissez est stocké dans le cookie sous la clé Domain=.

Configuration du domaine

Le domaine que vous fournissez indique si l’adresse URL peut utiliser le cookie. Par exemple, si votre domaine est www.example.com, le cookie n’est disponible que depuis une URL www.example.com. Cela signifie que 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 le domaine avec un point (.). Par exemple, le domaine .example.com permet au cookie de fonctionner à la fois sur app.example.com et 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 des 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 existe deux façons d’éviter ce problème :
  • Ne spécifiez pas le champ domain dans le client SDK pendant les tests.
  • Créez un domaine local pour localhost. Par exemple :
    • Accédez à /etc/hosts sur Linux ou à c:\Windows\System32\Drivers\etc\hosts sur Windows.
    • Ouvrez hosts avec les droits de super utilisateur ou d’administrateur.
    • Ajoutez un domaine au port localhost, par exemple : 127.0.0.1 app.com
    • Vous pouvez maintenant 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 pattern d’injection de dépendances pour vous donner la possibilité de fournir vos propres implémentations pour certaines parties d’un SDK.
Dans le SDK JavaScript, toutes les dépendances externes ont des implémentations par défaut, qui utilisent une API native du navigateur, il n’est donc pas nécessaire de les fournir, sauf si une autre API est requise pour des cas d’usage spécifiques.
Voici la liste des dépendances externes disponibles : L’exemple suivant implémente des dépendances externes. Pour importer une interface depuis un SDK, créez une classe qui implémente l’interface et transmettez la classe instanciée au SDK.

Storage

EventSource

VisitorCodeManager

Requester

Gestion des erreurs

Presque chaque méthode KameleoonClient peut occasionnellement lever une erreur. Ces erreurs sont des KameleoonError délibérément prédéfinies qui étendent la classe native JavaScript Error, fournissant des messages utiles et des champs type spéciaux de type KameleoonException. KameleoonException est un enum contenant tous les types d’erreurs possibles. Pour savoir exactement quel type de KameleoonException la méthode peut lever, consultez la section Throws dans la description de la méthode sur cette page, ou survolez la méthode dans votre IDE pour voir la description jsdocs. La gestion des erreurs rend votre application plus stable et évite les problèmes techniques.

Expérimentation cross-device

Pour prendre en charge les visiteurs qui accèdent à une application depuis plusieurs appareils, Kameleoon permet la synchronisation des données visiteur précédemment collectées sur chacun des appareils du visiteur ainsi que la réconciliation de leur historique de visite entre 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 entre les appareils sont disponibles dans l’article sur l’expérimentation cross-device.

Synchronisation des custom data entre appareils

Bien que la synchronisation du mapping personnalisé soit utilisée pour aligner les données visiteur entre les appareils, elle n’est pas toujours nécessaire. Voici deux scénarios où la synchronisation du mapping personnalisé n’est pas requise : Même user ID sur tous les appareils Si le même user ID est utilisé de manière cohérente sur tous les appareils, la synchronisation est gérée automatiquement sans synchronisation de mapping personnalisé. Il suffit d’appeler la méthode getRemoteVisitorData() lorsque vous souhaitez synchroniser les données collectées entre plusieurs appareils. Instances multi-serveurs avec des ID cohérents Dans des configurations complexes impliquant plusieurs serveurs (par exemple, des instances de serveur distribuées), où le même user ID est disponible sur les serveurs, la synchronisation entre serveurs (avec getRemoteVisitorData()) est suffisante sans synchronisation de mapping personnalisé supplémentaire. Les clients qui ont besoin de données supplémentaires peuvent se reporter à la description de la méthode getRemoteVisitorData() pour plus d’informations. Dans le code ci-dessous, on suppose que le même identifiant unique (dans ce cas, le visitorCode, qui peut également ê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 le scope Visitor pour vos custom data.
Device One
Device Two

Utilisation des custom data pour la fusion de sessions

L’expérimentation cross-device permet de combiner l’historique d’un visiteur sur chacun de ses appareils (réconciliation d’historique). La réconciliation d’historique permet de fusionner les sessions de différents visiteurs en une seule. Pour réconcilier l’historique de visite, utilisez CustomData afin de fournir un identifiant unique pour le visiteur. Pour plus d’informations, consultez la documentation dédiée.Une fois la réconciliation cross-device activée, appeler getRemoteVisitorData() avec le paramètre userId récupère toutes les données connues pour un utilisateur donné.Les sessions avec le même identifiant verront toujours la même variation dans une expérience. Dans la vue Visitor des pages de résultats de votre expérience, ces sessions apparaîtront comme un visiteur unique.La configuration du SDK garantit que les sessions associées voient toujours la même variation de l’expérience. However, there are some limitations regarding cross-device variation allocation. These limitations are outlined here.Suivez le guide activation de la réconciliation d’historique cross-device pour configurer vos custom data sur la plateforme Kameleoon.Ensuite, vous pouvez utiliser le SDK normalement. Les méthodes suivantes peuvent être utiles dans le contexte de la fusion de sessions :
  • getRemoteVisitorData() avec UniqueIdentifier(true) ajouté - pour récupérer les données de tous les visiteurs liés.
  • trackConversion() ou flush() avec une donnée UniqueIdentifier(true) ajoutée - pour tracker des données pour un visiteur spécifique associé à un autre visiteur.
Puisque la custom data que vous utilisez comme identifiant doit être définie sur le scope Visitor, vous devez utiliser la synchronisation des custom data cross-device pour récupérer l’identifiant avec la méthode getRemoteVisitorData() sur chaque appareil.
Voici un exemple d’utilisation des custom data pour la fusion de sessions.
Login Page
Application Page

Utilitaires

Le SDK dispose d’un ensemble de méthodes utilitaires que vous pouvez utiliser pour simplifier votre processus de 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. Cela peut être utile pour les implémentations personnalisées de Requester, lorsqu’un développeur a besoin de simuler une requête réussie (par exemple, pour désactiver le tracking).
Arguments
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 standard (key_1=value_1; key_2=value_2; ...) et obtenir la valeur d’une clé de cookie spécifique. Cette méthode est utile lorsque vous travaillez avec une implémentation personnalisée de VisitorCodeManager.
Arguments
Valeur de retour

Référence

Voici la documentation de référence complète du SDK JavaScript de Kameleoon.

Initialisation

initialize()

Méthode asynchrone pour l’initialisation de KameleoonClient en récupérant les données liées au SDK Kameleoon depuis le serveur ou en récupérant les données depuis une source locale si elles sont à jour ou si l’intervalle de mise à jour n’a pas été atteint.
  • Si la configuration du SDK n’a pas pu être récupérée mais qu’une configuration plus ancienne est disponible dans le stockage du SDK, le SDK utilise la configuration plus ancienne en tant que fallback et initialize ne lève pas d’erreur.
  • Le SDK prend en charge un mode offline.
En mode offline, si les requêtes de tracking de l’une des méthodes suivantes échouent en raison de problèmes de connectivité Internet, le SDK renvoie automatiquement la requête dès qu’il détecte que la connexion Internet a été rétablie :
Valeur de retour
Exceptions levées

Feature flags et variations

getVariation()

  • 📨 Envoie des données de tracking à 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 vaut true par défaut. Elle renvoie la Variation attribuée pour le visiteur. Si le visiteur n’est associé à aucune règle de feature flag, la méthode renvoie la Variation par défaut pour le feature flag donné. Assurez-vous qu’une gestion d’erreurs appropriée est implémentée dans votre code pour gérer les éventuelles exceptions.
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, c’est la variation de fallback appliquée à tous les utilisateurs qui ne sont pas ciblés par des règles spécifiques. Elle est représentée par la variation dans la section “Then, for everyone else…” d’une interface de gestion.
Arguments
Un objet de type GetVariationParamsType avec les propriétés suivantes :
Valeur de retour
Exceptions levées

getVariations()

  • 📨 Envoie des données de tracking à Kameleoon (selon le paramètre track)
  • 🎯 Événements : EventType.Evaluation
Récupère une map 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 renvoie la Variation attribué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 à true, la méthode getVariations() renverra les variations de feature flag à condition que l’utilisateur ne soit pas bucketé avec la variation off.
  • Le paramètre track contrôle si la méthode doit ou non tracker les attributions de variation. Par défaut, il est défini à true. S’il est défini à false, le tracking sera désactivé.
La map renvoyée a pour clés les clés des feature flags et pour valeurs leur Variation correspondante. Si aucune variation n’est attribuée pour un feature flag, la méthode renvoie la Variation par défaut de ce flag. Une gestion d’erreurs appropriée doit être implémentée pour gérer les éventuelles exceptions.
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, c’est la variation de fallback appliquée à tous les utilisateurs qui ne sont pas ciblés par des règles spécifiques. Elle est représentée par la variation dans la section “Then, for everyone else…” d’une interface de gestion.
Arguments
Un objet de type GetVariationParamsType avec les propriétés suivantes :
Valeur de retour
Exceptions levées

isFeatureFlagActive()

  • 📨 Envoie des données de tracking à Kameleoon (selon le paramètre track)
  • 🎯 Événements : EventType.Evaluation
La méthode isFeatureFlagActive() renvoie une valeur booléenne indiquant si le visiteur identifié par visitorCode a la featureKey spécifiée active. Cette méthode vérifie le ciblage, détermine la variation pour le visiteur et enregistre cette information dans le stockage. De plus, elle envoie une requête de tracking. Il existe également une surcharge de cette méthode qui vous permet de passer un paramètre track, que vous pouvez utiliser pour désactiver le tracking de l’évaluation de la feature.
Seuls les visiteurs avec un feature flag actif doivent être ciblés.
Kameleoon utilise le tracking pour comptabiliser 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 lorsque vous exposez des visiteurs à une variation et que vous devez les comptabiliser. 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. Ce réglage empêche Kameleoon de comptabiliser prématurément une session. Vous pouvez alors déclencher le tracking plus tard, lorsque vous exposez explicitement le visiteur.Kameleoon envoie les données de tracking toutes les secondes par défaut. Vous pouvez configurer cet intervalle jusqu’à cinq secondes via l’option de configuration de l’intervalle de tracking. Kameleoon regroupe les événements de tracking 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 tracking, Kameleoon comptabilise les événements comme des sessions distinctes. 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, et non l’état du master flag. Si vous excluez des règles, la méthode utilise l’état par défaut Then, for everyone else serve. Si vous sélectionnez Off pour cet état par défaut, la méthode renvoie toujours false même lorsque le master feature flag est On.
Arguments
Deux surcharges sont disponibles pour cette méthode :
  1. Surcharge à deux paramètres :
Cette surcharge est obsolète et sera supprimée lors de la prochaine mise à jour majeure. Veuillez utiliser la nouvelle surcharge avec un paramètre objet.
  1. Surcharge avec paramètre 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, en contournant le processus d’évaluation standard. Cela est particulièrement utile 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 debug ou les tests personnalisés. Lorsqu’une variation forcée est définie, elle remplace 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 plutôt forceTargeting=false.
Les variations simulées ont 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 terminé en premier.
Une variation forcée est traitée de la même manière qu’une variation évaluée. Elle est trackée dans les analytics et stockée dans le contexte utilisateur comme toute variation évaluée standard, garantissant la cohérence des rapports. La méthode peut lever des exceptions dans certaines conditions (par exemple, paramètres invalides, contexte utilisateur ou problèmes internes). Une gestion appropriée des exceptions est essentielle pour garantir la stabilité et la résilience de votre application.
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.
Arguments
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 le montre l’exemple. Cependant, si différents types d’erreurs nécessitent une réponse, gérez-les séparément en fonction des exigences spécifiques. De plus, pour une fiabilité accrue, les erreurs générales du langage peuvent être gérées en incluant Error.

evaluateAudiences()

  • 📨 Envoie des données de tracking à Kameleoon
Cette méthode évalue les visiteurs par rapport à tous les segments d’Audiences Explorer disponibles et tracke ceux qui correspondent. evaluateAudiences() doit être appelée après que toutes les données pertinentes du visiteur ont été définies ou mises à jour, et juste avant de récupérer 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 récentes disponibles, permettant 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.
Arguments
Exceptions levées
Dans la plupart des cas, seule l’erreur de base, KameleoonException, doit être gérée, comme le montre l’exemple. Cependant, si différents types d’erreurs nécessitent une réponse, gérez-les séparément en fonction des exigences spécifiques. De plus, pour une fiabilité accrue, les erreurs générales du langage 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 de parcourir les flags avec getVariation().
Renvoie la configuration actuelle du SDK sous forme d’objet DataFile.
Valeur de retour

Données visiteur

getVisitorCode()

La méthode getVisitorCode() obtient un visitor code depuis le cookie du navigateur. Si le visitor code n’existe pas, la méthode génère un visitor code aléatoire (ou utilise la valeur defaultVisitorCode si vous en avez fourni une) et définit le nouveau visitor code dans un cookie.
La méthode getVisitorCode() vous permet de définir des variations simulées pour un visiteur. Lorsque les cookies (d’une requête ou d’un document) contiennent la clé kameleoonSimulationFFData, le processus d’évaluation standard est contourné. À la place, 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 via le Simulation Panel.
  • 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.
⚙️ Configuration manuelleVeuillez vous assurer que le cookie kameleoonSimulationFFData respecte ce format :
  • kameleoonSimulationFFData={"featureKey":{"expId":10,"varId":20}} : simule la variation avec varId de l’expérience expId pour la featureKey donnée.
  • kameleoonSimulationFFData={"featureKey":{"expId":0}} : simule la variation par défaut (définie dans la section Then, for everyone else in Production, serve) pour la featureKey donnée.
⚠️ Pour garantir le bon fonctionnement, la valeur du cookie doit être encodée en tant que composant URI à l’aide d’une méthode telle que encodeURIComponent.
Arguments
Si vous ne fournissez pas de defaultVisitorCode et qu’aucun visitor code n’est stocké dans un cookie, le visitor code sera généré aléatoirement.
Valeur de retour
Exceptions levées

addData()

La méthode addData() ajoute des données de ciblage au stockage afin que d’autres méthodes puissent utiliser ces données pour décider de cibler ou non le visiteur actuel. La méthode addData() ne renvoie aucune valeur et n’interagit pas elle-même avec les serveurs back-end de Kameleoon. À la place, toutes les données déclarées sont enregistrées en vue d’une transmission ultérieure via la méthode flush. Cette approche réduit le nombre d’appels serveur effectués, car les données sont généralement regroupées en un seul appel serveur. Notez que la méthode trackConversion envoie également toutes les données précédemment associées, tout comme la méthode flush. Il en va de même pour les méthodes getFeatureFlagVariationKey et getFeatureFlagVariable, si 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 fait exception. Les visiteurs peuvent avoir une instance de CustomData associée par customDataIndex.
  • Les données userAgent ne seront pas stockées comme les autres données, et elles seront envoyées avec chaque requête de tracking pour le filtrage des bots.
  • Pour les types de données que vous pouvez utiliser pour le ciblage, consultez les conditions de ciblage prises en charge.
Arguments
  • kameleoonData est un argument variadique. Il peut être passé en tant qu’un ou plusieurs arguments (voir l’exemple).
  • L’index ou l’ID de la custom data se trouve dans votre compte Kameleoon. Notez que cet index commence à 0, ce qui signifie que la première custom data que vous créez pour un site donné aura 0 comme ID, et non 1.
Exceptions levées
Consultez la référence Types de données pour plus de détails sur la façon de gérer les différents types de données.

flush()

flush() prend les données Kameleoon associées à un visiteur et programme l’envoi de ces données dans la prochaine requête de tracking. Le moment de la prochaine requête de tracking est défini par le paramètre trackingInterval de la configuration du SDK. Les données du visiteur peuvent être ajoutées via les méthodes addData et getRemoteVisitorData.Si vous ne spécifiez pas de visitorCode, le SDK envoie toutes ses données stockées vers les serveurs Kameleoon distants. Si des requêtes de tracking précédemment échouées ont été stockées localement en mode offline, le SDK tente d’envoyer les requêtes stockées avant d’exécuter la dernière requête.
Si vous devez envoyer des requêtes de tracking immédiatement, utilisez flushInstant() — la version asynchrone de flush qui renvoie Promise<void>. Vous pouvez utiliser await lorsque vous avez besoin de garanties de livraison (par exemple, avant la navigation/le déchargement de la page), ou l’appeler sans await en mode fire-and-forget :
  • await client.flushInstant(visitorCode) envoie immédiatement les requêtes de tracking pour un visiteur spécifique et attend la fin
  • await client.flushInstant() envoie immédiatement les requêtes de tracking pour tous les visiteurs et attend la fin
Arguments
Ou un objet de type FlushParamsType contenant :
Exceptions levées

getRemoteData()

La méthode getRemoteData() renvoie les données stockées pour un site code spécifié sur un serveur Kameleoon distant. Vous pouvez utiliser cette méthode pour récupérer les préférences utilisateur, des données historiques ou toute autre donnée pertinente pour la logique de votre application. En stockant ces données sur nos serveurs hautement évolutifs via notre API Data, vous pouvez gérer efficacement de grandes quantités de données et les récupérer pour chacun de vos visiteurs ou utilisateurs.
Arguments
Valeur de retour
Exceptions levées

getRemoteVisitorData()

getRemoteVisitorData() est une méthode asynchrone pour récupérer les données de visites Kameleoon pour le visitorCode depuis l’API Data Kameleoon. La méthode ajoute des données au stockage pour que d’autres méthodes les utilisent lors de la prise de décisions de ciblage.Les données obtenues par cette méthode sont importantes lorsque vous souhaitez :
  • utiliser des données collectées depuis d’autres appareils.
  • accéder à l’historique d’un utilisateur, comme les pages précédemment visitées lors des visites passées.
  • utiliser des données accessibles uniquement côté client, comme les variables du datalayer et les objectifs qui ne convertissent que sur le front-end.
Lisez cet article pour mieux comprendre les cas d’usage possibles.
Par défaut, getRemoteVisitorData() récupère automatiquement les dernières custom data stockées avec scope=Visitor et les attache au visiteur sans qu’il soit nécessaire d’appeler la méthode addData(). C’est particulièrement utile pour synchroniser les custom data entre plusieurs appareils.
Arguments
Un objet de type RemoteVisitorDataParamsType contenant :
Valeur de retour
Exceptions levées
Utilisation des paramètres dans getRemoteVisitorData()
The getRemoteVisitorData() method offers flexibility, allowing you to define various parameters when retrieving data on visitors. Whether you’re targeting based on goals, experiments, or variations, the same approach applies across all data types.Par exemple, si vous souhaitez récupérer les données sur les visiteurs ayant atteint l’objectif “Order transaction”, vous pouvez spécifier des paramètres dans la méthode getRemoteVisitorData() pour affiner votre ciblage. Par exemple, si vous voulez cibler uniquement les utilisateurs qui ont converti sur l’objectif lors de leurs cinq dernières visites, vous pouvez définir le paramètre previousVisitAmount à 5 et conversions à true.La flexibilité illustrée dans cet exemple ne se limite pas aux données d’objectifs. Vous pouvez utiliser les paramètres de la méthode getRemoteVisitorData() pour récupérer des données sur une variété de comportements de visiteurs.
Voici la liste des filtres VisitorDataFiltersType disponibles :

getVisitorWarehouseAudience()

getVisitorWarehouseAudience est une méthode asynchrone qui récupère toutes les données d’audience associées au visiteur dans votre data warehouse en utilisant les visitorCode et warehouseKey spécifiés. Le warehouseKey est généralement votre user ID interne. Le paramètre customDataIndex correspond à la custom data Kameleoon que Kameleoon utilise pour cibler vos visiteurs. Reportez-vous à la documentation sur le ciblage warehouse pour plus de détails.
Arguments
Objet de paramètres composé de :
Valeur de retour
Exceptions levées

setLegalConsent()

Les informations de consentement sont synchronisées entre l’Engine Kameleoon (fichier d’application engine.js) et le SDK JS. Cette synchronisation signifie qu’une fois que le consentement est défini sur l’Engine ou sur le SDK, il est automatiquement défini pour les deux. Cette fonctionnalité élimine le besoin de gestion manuelle du consentement et garantit que les SDK fonctionnent en conformité avec les préférences de l’utilisateur.Si vous utilisez Kameleoon en mode hybride, nous vous recommandons de lire la section sur le consentement dans notre article sur l’expérimentation hybride
Lors de la gestion du consentement légal, il est important d’utiliser la méthode getVisitorCode de KameleoonClient, et non la méthode obsolète de KameleoonUtils. De plus, cette méthode n’accepte pas domain comme argument. À la place, transmettez-le au constructeur de KameleoonClient. Reportez-vous à l’exemple ci-dessus. La méthode setLegalConsent spécifie si le visiteur a donné son consentement légal pour l’utilisation de données personnelles. Définir le paramètre legalConsent à false limite les types de données que vous pouvez inclure dans les requêtes de tracking. Cette méthode vous aide à respecter les exigences légales et réglementaires tout en gérant les données des visiteurs de manière responsable. Vous trouverez plus d’informations sur les données personnelles dans la politique de gestion du consentement.
Arguments
Exceptions levées
Comportement lors de la révocation du consentement
Lorsque vous appelez setLegalConsent() avec consent=false, le SDK ne supprime pas le cookie kameleoonVisitorCode. À la place, il cesse de prolonger la date d’expiration du cookie, laissant le cookie persister jusqu’à son expiration naturelle. Si vos exigences de conformité nécessitent la suppression immédiate du fichier cookie lors de l’opt-out, vous devez le supprimer manuellement en utilisant les méthodes de gestion des cookies natives de votre framework. Le SDK ne supprimera pas le fichier automatiquement.

Objectifs et analytics tierces

trackConversion()

  • 📨 Envoie des données de tracking à Kameleoon
Utilisez cette méthode pour suivre une conversion pour un objectif et un utilisateur spécifiques. Cette méthode nécessite visitorCode et goalId. De plus, cette méthode accepte également des arguments optionnels revenue, negative et metadata. Le visitorCode est généralement identique à celui qui a été utilisé lors du déclenchement de l’expérience.La méthode trackConversion() ne renvoie aucune valeur. Cette méthode est non bloquante car l’appel serveur est effectué de manière asynchrone.
Arguments
Objet de paramètres composé de :
Les valeurs de metadata sont accessibles via les exports de données brutes et la page de résultats.Si le paramètre metadata est fourni, Kameleoon utilisera ces valeurs spécifiées pour la conversion actuelle au lieu de ce qui avait été précédemment collecté via la méthode addData(). Si le paramètre est omis, Kameleoon utilisera les dernières valeurs trackées pour ces CustomData avant la conversion et au cours de la même visite.Kameleoon ne prendra en compte que les valeurs de metadata explicitement transmises comme paramètres à la méthode trackConversion().Dans l’exemple ci-dessous, Kameleoon n’associera la conversion qu’à la valeur de custom data explicitement fournie en paramètre (ici : index 5 avec la valeur ‘Amex Credit Card’).
Exceptions levées

getEngineTrackingCode()

Kameleoon s’intègre à plusieurs solutions d’analytics, notamment Mixpanel, Google Analytics 4 et Segment. Pour tracker correctement les expériences côté serveur, appelez la méthode getEngineTrackingCode() après que le visiteur a déclenché une expérience. Le SDK renvoie des commandes de queue JavaScript pour les expériences que le visiteur a déclenchées au cours des cinq dernières secondes. 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’analytics active. Reportez-vous à l’expérimentation hybride pour plus d’informations sur l’implémentation de cette méthode.
  • Pour utiliser cette fonctionnalité, implémentez à la fois le SDK JavaScript et l’Engine.js de Kameleoon. Étant donné qu’Engine.js n’est utilisé que pour le tracking dans ce flux, vous pouvez installer le tag asynchrone avant la balise </body> de fermeture.
  • Vous pouvez insérer le code de tracking renvoyé directement dans une balise HTML <script>.
Dans cet exemple, 123456 et 234567 sont des IDs d’expérience, et 7890 et 8901 sont des IDs de variation. Dans votre implémentation, le SDK génère ces valeurs dans le code de tracking renvoyé.
Arguments
Valeur de retour
Exceptions levées

Événements

onEvent()

La méthode onEvent() déclenche un callback lorsqu’un événement spécifique est déclenché. La fonction callback peut accéder aux données associées à l’événement. Les méthodes du SDK dans cette documentation indiquent quels types d’événements elles déclenchent, le cas échéant.
Vous ne pouvez attribuer qu’un seul callback à chaque EventType.
Événements
Les événements sont définis dans l’enum EventType. Selon le type d’événement, le paramètre eventData aura un type différent.
Arguments
Exceptions levées

Envoi d’événements d’exposition vers des outils externes
Kameleoon propose des intégrations natives avec diverses solutions d’analytics et de CDP, telles que Mixpanel, Google Analytics 4, Segment…. Pour vous permettre de tracker et d’analyser vos expériences côté serveur, Kameleoon fournit une méthode, getEngineTrackingCode(), qui renvoie le code JavaScript à insérer dans votre page. Le code envoie automatiquement les événements d’exposition à votre solution d’analytics. Le SDK construit un code de tracking pour votre solution d’analytics active à partir des expériences que le visiteur a déclenchées au cours des cinq dernières secondes. Pour plus d’informations sur l’expérimentation hybride, veuillez consulter cet article.La méthode getEngineTrackingCode() renvoie le code de tracking Kameleoon pour le visiteur actuel. Le code de tracking est basé sur les expériences qui ont été déclenchées au cours des cinq dernières secondes.
Pour bénéficier de cette fonctionnalité, vous devrez implémenter à la fois le SDK JavaScript et notre tag JavaScript Kameleoon. Nous vous recommandons d’implémenter le tag asynchrone Kameleoon, que vous pouvez installer avant la balise </body> de fermeture dans votre page HTML, car il ne sera utilisé qu’à des fins de tracking.

Types de données

Les types Kameleoon Data sont des classes utilitaires utilisées pour stocker des données dans le stockage 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 tracking. Les données disponibles dans le SDK ne sont pas disponibles pour le ciblage et le reporting dans l’application Kameleoon tant que vous ne les ajoutez pas (par exemple, en utilisant la méthode addData()). Consultez utiliser l’historique des visites pour cibler les utilisateurs pour plus d’informations.
Si vous utilisez le mode hybride, appelez getRemoteVisitorData() pour remplir automatiquement toutes les données que Kameleoon a précédemment collectées.

Browser

Depuis le SDK JavaScript 4.10.0, Browser est automatiquement détecté à partir de la chaîne User-Agent. Cependant, vous pouvez toujours le remplacer manuellement si nécessaire.
Browser contient des informations sur le navigateur.
Chaque visiteur ne peut avoir qu’un seul Browser. Ajouter un second Browser remplace le premier.

UniqueIdentifier

Les données UniqueIdentifier sont utilisées comme marqueur pour l’identification unique du visiteur. 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. Associer un UniqueIdentifier à un visiteur notifie le SDK que le visiteur est lié à un autre visiteur. isUniqueIdentifier peut être utile dans des situations particulières ; par exemple, si vous ne pouvez pas accéder au visitorCode anonyme attribué à un visiteur, mais que vous pouvez utiliser un ID interne lié à ce visiteur via la fusion de sessions.
Chaque visiteur ne peut avoir qu’un seul UniqueIdentifier. Ajouter un autre UniqueIdentifier remplace le premier.

Conversion

Le jeu de données Conversion stocké ici peut être utilisé pour filtrer les rapports d’expérience et de personnalisation par n’importe quel objectif qui y est associé.
  • 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.
  • En général, le SDK JavaScript tentera d’utiliser un cookie localStorage pour les conditions. Si localStorage n’est pas possible, le SDK peut utiliser les données Cookie comme alternative.
  • Chaque visiteur ne peut avoir qu’un seul Cookie. Ajouter un second Cookie remplace le premier.
Méthodes
Les données Cookie disposent d’une méthode utilitaire statique, fromString, que vous pouvez utiliser pour créer un cookie en analysant une chaîne contenant des données de cookie valides. La méthode accepte une string comme paramètre et renvoie une instance Cookie initialisée.

GeolocationData

GeolocationData contient les détails de géolocalisation du visiteur.
Chaque visiteur ne peut avoir qu’un seul GeolocationData. Ajouter un second GeolocationData remplace le premier.
Un paramètre objet de type GeolocationInfoType contient les champs suivants :

CustomData

CustomData permet d’associer facilement tout type de données à chaque visiteur. Elles peuvent ensuite être utilisées comme condition de ciblage dans les segments ou comme filtre/décomposition dans les rapports d’expérience. Pour en savoir plus sur les custom data, veuillez consulter cet article.
  • Chaque visiteur n’est autorisé à avoir qu’un seul CustomData pour chaque index unique. Ajouter un autre CustomData avec le même index remplacera celui existant.
  • L’index de la custom data se trouve dans le tableau de bord Custom Data sous la colonne « INDEX ».
  • Pour empêcher le SDK d’envoyer les données avec l’index sélectionné aux serveurs Kameleoon pour des raisons de confidentialité, activez l’option : Use this data only locally for targeting purposes lors de la création de la custom data.
  • Ajouter une instance CustomData créée avec un nom alors que l’instance du SDK n’est pas initialisée ou que le nom n’est pas enregistré entraînera l’ignorance de la donnée.

Device

Depuis le SDK JavaScript 4.10.0, Device est automatiquement détecté à partir de la chaîne User-Agent. Cependant, vous pouvez toujours le remplacer manuellement si nécessaire.
Device contient des informations sur votre appareil.
Chaque visiteur ne peut avoir qu’un seul Device. Ajouter un second Device remplace le premier.

OperatingSystem

Depuis le SDK JavaScript 4.10.0, OperatingSystem est automatiquement détecté à partir de la chaîne User-Agent. Cependant, vous pouvez toujours le remplacer manuellement si nécessaire.
OperatingSystem contient des informations sur le système d’exploitation de l’appareil du visiteur.
Chaque visiteur ne peut avoir qu’un seul OperatingSystem. Ajouter un second OperatingSystem remplace le premier.

PageView

Depuis le SDK JavaScript 4.10.0, PageView est automatiquement détecté à partir de window.location?.href et document.title. Cependant, vous pouvez toujours le remplacer manuellement si nécessaire.
PageView contient des informations sur votre page web.
Chaque visiteur peut avoir un PageView par URL unique. Ajouter un second PageView avec la même URL notifie le SDK que le visiteur a revisité la page.
PageViewParametersType pageViewParameters - un objet avec les paramètres de page view décrits ci-dessous
Vous trouverez l’index ou l’ID du referrer 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é aura 0 comme ID, et non 1.

UserAgent

UserAgent vous permet de stocker des informations sur le user-agent du visiteur. Les expériences côté serveur sont plus susceptibles d’être affectées par le trafic des bots que les expériences côté client. Kameleoon utilise l’IAB/ABC International Spiders and Bots List pour résoudre ce problème et reconnaître les bots et spiders connus. Kameleoon utilise également le champ UserAgent pour filtrer les bots et autres trafics indésirables qui pourraient fausser vos métriques de conversion. Pour plus de détails, consultez notre 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 nos analytics.
Un Visitor ne peut avoir qu’un seul UserAgent. Ajouter un second UserAgent remplace le premier.
Si vous exécutez Kameleoon en mode hybride, vos expériences de feature sont automatiquement protégées contre le trafic des bots. Cette protection se produit car Kameleoon collecte automatiquement le user-agent sur le front-end. Vous n’avez donc pas besoin de transmettre le user-agent ou tout autre paramètre pour filtrer les bots et spiders.Si vous utilisez des bots internes, nous vous suggérons de transmettre la valeur curl/8.0 du userAgent pour les exclure de nos analytics.

ApplicationVersion

ApplicationVersion représente le numéro de version sémantique de votre application.
Un visiteur ne peut avoir qu’un seul ApplicationVersion. Ajouter 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 les clients en ont besoin. Si vous avez besoin de plus de détails, veuillez contacter votre Customer Success Manager.

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, son état d’environnement et d’autres détails associés. Il peut être étendu avec des informations supplémentaires si les clients en ont besoin. Si vous avez besoin de plus de détails, veuillez contacter votre Customer Success Manager.

Rule

La 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 les clients en ont besoin. Si vous avez besoin de plus de détails, veuillez contacter votre Customer Success Manager.

Variation

Variation contient des informations sur la variation attribuée au visiteur (ou sur la variation par défaut, si aucune attribution spécifique n’existe).
  • Assurez-vous que votre code gère le cas où id ou experimentId vaut null, indiquant une variation par défaut.
  • La map 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 attribuée.

Méthodes obsolètes

Ces méthodes sont obsolètes et seront supprimées lors de la prochaine mise à jour majeure.

getFeatureFlagVariationKey()

Utilisez plutôt la méthode getVariation
La méthode getFeatureFlagVariationKey() récupère la variation key pour un visiteur identifié par un visitorCode. Cette méthode inclut une vérification de ciblage qui identifie la variation appropriée exposée au visiteur, l’enregistre dans le stockage et envoie une requête de tracking.
Lorsqu’un utilisateur n’est pas associé à un feature flag, le SDK renvoie aléatoirement une variation key selon les règles du feature flag. Si l’utilisateur a déjà été enregistré avec le feature flag, le SDK détectera cette association et renverra la valeur de variation key précédente de l’utilisateur. Cependant, si l’utilisateur ne satisfait aucune des règles définies, le SDK renverra la valeur par défaut spécifiée dans les règles de livraison du feature flag de Kameleoon. Il est important de noter que la valeur par défaut peut être une variation key, une valeur booléenne ou un autre type de données, selon la configuration du feature flag.
Arguments
Valeur de retour
Exceptions levées

getVisitorFeatureFlags()

  • 🚫 N’envoie pas de données de tracking à Kameleoon
  • 🎯 Événements : EventType.Evaluation (for each feature flag)
Utilisez plutôt la méthode getVariations.
La méthode getVisitorFeatureFlags() renvoie une liste de feature flags qui ciblent un visiteur identifié par son visitorCode ainsi que les feature flags actifs pour le visiteur spécifié.
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 attribué à la variation off (par défaut ou de contrôle). Lorsque vous avez besoin de tous les feature flags du visiteur, utilisez plutôt getFeatureFlags.Par exemple :
Pour les cas où vous avez besoin de tous les feature flags du visiteur, utilisez plutôt getFeatureFlags :
Arguments
Valeur de retour
Exceptions levées

getActiveFeatureFlags()

  • 🚫 N’envoie pas de données de tracking à Kameleoon
  • 🎯 Événements : EventType.Evaluation (for each feature flag)
Utilisez plutôt la méthode getVariations.
La méthode getActiveFeatureFlags() renvoie une Map, où la clé est featurekey et la valeur est une information détaillée sur la variation du visiteur et ses variables
Cette méthode ne collecte que les feature flags actifs du visiteur. Cela signifie que le résultat exclut tous les feature flags pour lesquels le visiteur est attribué à la variation off (par défaut ou de contrôle). Lorsque vous avez besoin d’itérer sur tous les feature flags du visiteur, utilisez plutôt getFeatureFlags.Consultez la section CAUTION de la méthode getVisitorFeatureFlags pour plus de détails.
Arguments
Valeur de retour
Exceptions levées

getFeatureFlagVariable()

Utilisez la méthode getVariation.
La méthode getFeatureFlagVariable() renvoie une variable pour un visiteur identifié par un visitorCode. Cette méthode inclut une vérification de ciblage qui identifie la variation appropriée exposée au visiteur, l’enregistre dans le stockage et envoie une requête de tracking.
Arguments
Objet de paramètres de type GetFeatureFlagVariableParamsType contenant les champs suivants :
Valeur de retour
Exceptions levées

getFeatureFlagVariables()

  • 📨 Envoie des données de tracking à Kameleoon
  • 🎯 Événements : EventType.Evaluation (for each feature flag)
Utilisez la méthode getVariation.
La méthode getFeatureFlagVariables() renvoie une variable pour un visiteur identifié par un visitorCode. Cette méthode inclut une vérification de ciblage qui identifie la variation appropriée exposée au visiteur, l’enregistre dans le stockage et envoie une requête de tracking.
Arguments
Valeur de retour
Exceptions levées

onConfigurationUpdate()

Utilisez plutôt la méthode onEvent avec EventType.ConfigurationUpdate.
La méthode onConfigurationUpdate() déclenche un callback lors de la mise à jour de la configuration du client.
Cette méthode ne s’applique qu’aux server-sent events utilisés dans les mises à jour en temps réel.
Arguments
Exceptions levées

getFeatureFlags()

Utilisez plutôt la méthode getDataFile().
🚫 N’envoie pas de données de tracking à Kameleoon La méthode getFeatureFlags() renvoie une liste des feature flags stockés dans la configuration du client.
Valeur de retour
Exceptions levées