Skip to main content
Avec le SDK React de Kameleoon, vous pouvez exécuter des expériences de fonctionnalités et activer des feature flags dans vos applications web et mobiles front-end. L’intégration de notre SDK dans votre application 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 React sont disponibles dans le changelog. Méthodes du SDK : pour la documentation de référence complète du SDK React, consultez la section référence. Prérequis : le SDK React nécessite React 16.8.0+

Guide du développeur

Suivez cette section pour intégrer le SDK dans votre application et en apprendre davantage sur son utilisation.

Premiers pas

Cette section vous guide à travers l’installation et la configuration du SDK pour la première fois.

Installation

L’outil d’installation du SDK Kameleoon est la méthode recommandée pour installer le SDK. Cet 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 démarrer l’outil d’installation du SDK, installez-le et exécutez-le globalement :
Ou exécutez-le directement avec npx:

Créer le client Kameleoon

Pour commencer, créez un point d’entrée pour le SDK React en créant le client Kameleoon au niveau supérieur de votre application. Créez une instance de KameleoonClient en utilisant la fonction createClient(), importée du package kameleoon.

Encapsuler l’application dans le Kameleoon Provider

La deuxième étape consiste à connecter le client Kameleoon précédemment créé a KameleoonProvider en passant le client configuré a KameleoonProvider:
KameleoonProvider
Utilisez ce provider au niveau racine en encapsulant votre application pour avoir accès à KameleoonClient. Cela garantit que votre application ne scintille pas en raison des changements de feature flags au démarrage.
Props
KameleoonProviderSSR
Utilisez ce provider au niveau racine en encapsulant votre application pour obtenir un accès à KameleoonClient. KameleoonProviderSSR diffère de KameleoonProvider car elle crée une instance KameleoonClient dans le contexte lors de la première requête du client. Cela empêche le risque de créer le client côté serveur. C’est recommandé pour une utilisation dans les systèmes basés sur le SSR, tel que Next.js avec SSR.
Props

Attendre l’initialisation du client

L’initialisation de KameleoonClient se fait de manière asynchrone pour vous assurer que l’appel à l’API Kameleoon a réussi pour que le hook useInitialize soit utilisé. Vous pouvez utiliser async/await, Promise.then() ou toute autre méthode pour gérer l’initialisation asynchrone du client.

Activation d’une feature flag

Assigner un identifiant unique à un utilisateur
Pour assigner 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 ensuite défini dans le cookie des en-têtes de la 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 d’une configuration de feature flag
Pour implémenter une feature flag dans votre code, vous devez d’abord créer la feature flag dans votre compte Kameleoon. Pour déterminer le statut ou la variation d’une 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 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 son expérience associée. Cette méthode vérifie si l’utilisateur est ciblé, trouve la variation assignée du visiteur et l’enregistre dans le stockage. Lorsque track=true, le SDK enverra l’événement d’exposition à l’expérience spécifiée sur la prochaine demande de suivi, qui est automatiquement déclenchée en fonction de tracking_interval_millisecond du SDK. Par défaut, cet intervalle est défini à 1000 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
Ajouter des points de données pour cibler un utilisateur ou filtrer / ventiler 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 vous assurer que vos résultats sont précis, il est recommandé de filtrer les bots en utilisant le type de données UserAgent.
Suivi objectif conversions
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 demande de suivi de conversion sera envoyée avec la prochaine demande de suivi planifiée, que le SDK envoie à intervalles réguliers (défini par tracking_interval_millisecond). Si vous préférez envoyer la demande 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.

Considérations React Native

React Native sur la plateforme android ne supporte pas la feature Real Time Update.
Bien que le SDK React fonctionne de la même manière dans les contextes React Native et React, il est important de noter que les étapes de configuration diffèrent. En raison de l’absence d’API de navigateur dans React Native, le SDK React doit avoir différentes implémentations de dépendance externe pour fonctionner correctement. Pour cela, Kameleoon fournit plusieurs packages npm dédiés que vous pouvez installer et configurer manuellement ou installer en utilisant l’outil d’installation du SDK Kameleoon (recommandé). Les packages incluent :
  • @kameleoon/react-native-storage - construit en utilisant la bibliothèque react-native-mmkv
  • @kameleoon/react-native-event-source - construit en utilisant la bibliothèque react-native-event-source-ts
  • @kameleoon/react-native-visitor-code-manager - construit sur la base de la bibliothèque react-native-mmkv
  • @kameleoon/react-native-platform-analyzer - construit en utilisant la bibliothèque react-native
  • optionnel @kameleoon/react-native-secure-prng - construit en utilisant la bibliothèque react-native-get-random-values
Si vous ne voulez pas utiliser les packages listés, vous pouvez fournir votre propre implémentation en suivant le guide des dépendances externes. Exemple de configuration du SDK React pour une application React Native :

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

Lorsque vous configurez une clé de bucketing personnalisée pour une 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.

Exigences techniques

Pour utiliser efficacement une clé de bucketing personnalisée :
  • La clé doit être de type 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 une variété de 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 de visite 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 divers processus internes et problèmes.

Niveaux de log

Le SDK prend en charge la limitation des journaux par niveau de log.

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 sur le domaine

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

Définition du domaine

Le domaine que vous fournissez indique l’adresse URL qui 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 être plus flexible autour des sous-domaines, vous pouvez préfixer un domaine avec .. Par exemple, le domaine .example.com permet au cookie de fonctionner 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 sont pas autorisés à être utilisés 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 des droits super utilisateur ou administrateur
    • Ajoutez un domaine au port localhost, 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 votre domaine

Dépendances externes

Les dépendances externes du SDK utilisent le modèle dependency injection pour vous permettre de fournir vos propres implémentations pour certaines parties d’un SDK.
Dans le SDK React, 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 à moins qu’une autre API ne soit requise pour des cas d’usage spécifiques.
Voici la liste des dépendances externes disponibles : 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.

Storage

EvenementSource

VisitorCodeManager

Requester

Générateur de nombres pseudo-aléatoires

Pseudo Random Number Generator (PRNG) est une dépendance qui génère un nombre flottant aléatoire entre 0 et 1 (similaire à Math.random). L’implémentation par défaut de Kameleoon s’appuie sur la fonction crypto du navigateur ou sur Math.random si crypto n’est pas disponible. Ces API sont très sécurisées et fiables. Cependant, dans certains cas limites (en particulier dans certains moteurs React Native), vous pourriez vouloir fournir votre propre implémentation ou utiliser un package Kameleoon dédié pour React Native—@kameleoon/react-native-secure-prng

Gestion des erreurs

Presque chaque rappel React SDK retourné par les hooks peut lancer une erreur à un moment donné. Ces erreurs ne sont pas seulement des mises en garde, mais plutôt des KameleoonErrors prédéfinies délibérément. qui étendent la classe native JavaScript Error en fournissant des messages utiles et un champ type spécial avec un type KameleoonException. KameleoonException est une énumération contenant tous les types d’erreurs possibles. Pour savoir exactement quel type de KameleoonException les rappels peuvent lancer, vous pouvez consulter la section Throws dans la description des hooks sur cette page ou survoler simplement le rappel dans votre IDE pour voir la description jsdocs. Dans l’ensemble, gérer les erreurs est considéré comme une bonne pratique pour rendre votre application plus stable et éviter les problèmes techniques.

Expérimentation multi-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 utilisateur ID across devices Si le même ID utilisateur est utilisé de manière cohérente sur tous les appareils, la synchronisation est traitée automatiquement sans synchronisation de mappage personnalisé. Il suffit d’appeler la méthode getRemoteVisitorData() lorsque vous voulez synchroniser les données collectées entre plusieurs appareils. Instances multi-serveurs avec des ID cohérents 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 voulez synchroniser les données collectées en temps réel, vous devez choisir la portée Visitor pour vos données personnalisées.
Device One
Device Two

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

Expérimentation cross-device vous permet de combiner l’historique d’un visiteur sur chacun de ses appareils (réconciliation d’historique). L’une des fonctionnalités puissantes que la réconciliation d’historique offre est la capacité de fusionner différentes sessions de visiteurs en une seule. Pour réconcilier l’historique de visite, vous pouvez utiliser CustomData pour fournir un identifiant unique pour le visiteur.Suivez le guide activation de la réconciliation d’historique cross-device pour configurer vos données personnalisées sur la plateforme KameleoonLorsque vos données personnalisées sont configurées, vous pouvez les utiliser 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 des pages de résultats de votre expérience.La configuration du SDK garantit que les sessions associées voient toujours la même variation de l’expérience.Avant d’utiliser d’autres méthodes, assurez-vous de laisser le SDK savoir que le visiteur a un identifiant unique en ajoutant des données UniqueIdentifier à un visiteur
Comme les données personnalisées que vous utilisez comme identifiant doivent être définies sur la portée Visitor, vous devez utiliser la synchronisation cross-device des données personnalisées pour récupérer l’identifiant avec la méthode getRemoteVisitorData sur chaque appareil.
Voici un exemple d’utilisation de données personnalisées pour la fusion de sessions. Cet exemple utilise une application avec une page de connexion. Comme l’ID 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. Une fois que l’utilisateur se connecte, vous pouvez associer le visiteur anonyme avec l’ID utilisateur et l’utiliser comme identifiant unique pour le visiteur.
Login Page
Application Page

Utilities

Le SDK a un ensemble de méthodes utilitaires qui peuvent être utilisées pour simplifier le processus de développement. Toutes les méthodes sont représentées en tant que membres statiques de la classe KameleoonUtils.

simulateSuccessRequest

La méthode simulateSuccessRequest est utilisée pour simuler une requête réussie au serveur Kameleoon. Elle peut être utile pour les implémentations Requester personnalisées lorsqu’un développeur a besoin de simuler une requête réussie, par exemple désactiver le suivi.
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

La méthode getCookieValue est utilisée pour analyser une chaîne de cookies commune (key_1=value_1; key_2=value_2; ...) et obtenir la valeur d’une clé de cookie spécifique. C’est utile lorsque vous travaillez 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 React.

Initialisation

Cette section fournit les méthodes que vous utilisez pour créer et initialiser le Client Kameleoon dans votre application.

initialize()

Une fonction asynchrone initialize, associée au hook useInitialize, qui est utilisée pour l’initialisation du Client Kameleoon en récupérant les données liées au SDK Kameleoon du serveur ou en récupérant les données à partir d’une source locale si les données 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 comme solution de secours et initialize ne lève pas d’erreur.
  • Le SDK prend en charge un mode hors ligne.
En mode hors ligne, si les requêtes de suivi 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

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. Collectez la fonction isReady avec le hook useInitialize. Elle est particulièrement utile dans une arborescence de composants profondément imbriquée, car elle vous permet de vérifier la disponibilité du SDK sans gérer un état global ou transmettre le résultat de l’initialisation via des props de composants.
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 jamais à un état non prêt.
Valeur de retour

createClient()

Pour commencer, vous devez créer un point d’entrée pour le SDK React en créant un Client Kameleoon au niveau supérieur de votre application en utilisant la fonction createClient() importée du package kameleoon. Une instance de KameleoonClient est créée en utilisant la fonction createClient().
Paramètres
Un objet de type SDKParameters contenant :
Paramètres de configuration
Option 1 (Recommandé) : Utilisez JSON.stringify()
Option 2 : Chaîne JSON brute (échappez les caractères spéciaux)
Réduire dataFileRefreshInterval augmente la fréquence à laquelle le SDK vérifie une configuration plus récente en arrière-plan, mais le fichier de données en cache d’un visiteur reste utilisable jusqu’à ce qu’il dépasse dataFileCacheTtl (90 minutes par défaut). Réduisez plutôt dataFileCacheTtl pour raccourcir la durée pendant laquelle un visiteur peut continuer à être évalué selon une configuration en cache obsolète. Sinon, le trafic entrant dans une expérience ou un feature flag nouvellement lancé augmente progressivement au lieu d’atteindre immédiatement son volume complet. Consultez Impact sur les expériences et feature flags nouvellement lancés pour plus de détails.
Valeur de retour
Assurez-vous de ne pas utiliser plusieurs instances de client dans une application, car ce n’est pas encore entièrement supporté et peut écraser la configuration du stockage local et causer un comportement involontaire (bugs).

Feature flags et variations

Cette section fournit les méthodes que vous utilisez pour récupérer et gérer les feature flags et variations attribués au visiteur.

getVariation()

  • 📨 Envoie les données de suivi à Kameleoon (en fonction du 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 (en fonction du paramètre track)
  • 🎯 Événements: EventType.Evaluation
La méthode est obtenue en utilisant le hook useFeatureFlag.
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 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 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 ou non les attributions de variation. Par défaut, il est défini sur true. S’il est défini sur 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 (en fonction du paramètre track)
  • 🎯 Événements: EventType.Evaluation
La méthode isFeatureFlagActive(), utilisée avec le hook useFeatureFlag, détermine si un visiteur identifié par visitorCode a le featureKey spécifié actif. Cette méthode vérifie les conditions de ciblage, identifie la variation pour le visiteur et enregistre ces informations dans le stockage. De plus, le hook envoie une requête de suivi. Il existe également une surcharge pour cette méthode qui inclut un paramètre track, vous permettant de désactiver le suivi de l’évaluation du feature flag.
Le visiteur doit être ciblé pour avoir le feature flag actif
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 du paramètre track lorsque vous exposez des visiteurs à une variation et avez besoin de les compter. Définissez le paramètre track sur 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 sur false. Ce paramètre empêche Kameleoon de compter prématurément une session. Vous pouvez ensuite déclencher le suivi plus tard lorsque 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 d’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.
  • Simulated variations: Affectent le résultat général de la feature flag.
Paramètres
Un objet de type SetForcedVariationParametersType ayant 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 des données de suivi à 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.

getDataFichier()

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

Visiteur données

Cette section fournit les méthodes que vous utilisez pour gérer les données de visiteur.

getVisitorCode()

La méthode getVisitorCode collectée à partir du hook useVisitorCode obtient un code visiteur à partir du cookie du navigateur. Si le code visiteur n’existe pas encore, la fonction génère un code visiteur aléatoire (ou utilise la valeur defaultVisitorCode si vous l’avez fournie) et définit le nouveau code visiteur dans un cookie.
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 les simulations de deux façons :
  • 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:
  • Simulated variations: Affectent le résultat général de la 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}} : 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 Ensuite, pour tous les autres en Production, servir) pour la featureKey donnée.
⚠️ Pour assurer le bon fonctionnement du cookie, encodez-le en tant que composant URI en utilisant une méthode telle que encodeURIComponent.
Paramètres
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()

La fonction addData, utilisée avec le hook useData, collecte les données de ciblage à stocker afin que d’autres hooks déterminent si le visiteur actuel est ciblé.
  • La fonction addData() ne retourne aucune valeur et n’interagit pas avec les serveurs back-end de Kameleoon par elle-même. À la place, toutes les données déclarées sont enregistrées pour une transmission future via la méthode flush. Cette approche aide à réduire le nombre d’appels serveur effectués, car les données sont généralement regroupées en un seul appel serveur déclenché par l’exécution de flush.
La méthode trackConversion envoie également toutes les données précédemment associées, tout comme flush. Il en va de même pour les méthodes getFeatureFlagVariationKey et getFeatureVariable si une règle d’expérimentation est déclenchée.
  • les données userAgent ne seront pas stockées en stockage comme d’autres données, et elles seront envoyées avec chaque requête de suivi pour le filtrage des bots.
  • Consultez la liste des conditions prises en charge pour connaître les types de données utilisables pour le ciblage
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. Les visiteurs peuvent avoir une instance de CustomData associée par customDataIndex.
Paramètres
  • kameleoonData est un argument variadique qui 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. Il est important de noter 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, non 1.
Exceptions levées
Voir 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 requête de suivi. L’heure de la prochaine requête de suivi est définie par le paramètre trackingInterval de la configuration du SDK. Les données de visiteur peuvent être ajoutées en utilisant les méthodes addData et getRemoteVisitorData.Si vous ne spécifiez pas de visitorCode, le SDK vide toutes ses données stockées vers les serveurs Kameleoon distants. Si des requêtes de suivi précédemment échouées ont été stockées localement lors du mode hors ligne, 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 suivi immédiatement, utilisez flushInstant() (la version asynchrone de flush qui renvoie Promise<void>). Vous pouvez l’utiliser avec await lorsque vous avez besoin de garanties de livraison (par exemple, avant la navigation/déchargement de la page), ou l’appeler sans await comme une requête sans attendre:
  • await flushInstant(visitorCode) envoie des requêtes de suivi immédiatement pour un visiteur spécifique et attend la completion
  • await flushInstant() envoie des requêtes de suivi immédiatement pour tous les visiteurs et attend la completion
Paramètres
Ou un objet de type FlushParamsType, contenant:
Exceptions levées

getRemoteDonnees()

La méthode asynchrone getRemoteData, collectée avec le hook useData, renvoie les données stockées pour le code de site spécifié sur un serveur Kameleoon distant. Par exemple, vous pouvez utiliser cette fonction pour récupérer les préférences utilisateur, les données historiques ou toute autre donnée pertinente pour 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 grandes quantités de données et les récupérer pour chacun de vos visiteurs ou utilisateurs.
Paramètres
Valeur de retour
Exceptions levées

getRemoteVisiteurDonnees()

getRemoteVisitorData() est une méthode asynchrone pour récupérer les données Kameleoon Visits pour le visitorCode à partir de l’API Kameleoon Data. La méthode ajoute les 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 à l’aide de cette méthode jouent un rôle important lorsque vous voulez :
  • utiliser les données collectées à partir d’autres appareils.
  • accéder à l’historique d’un utilisateur, comme les pages précédemment visitées lors de visites passées.
  • utiliser les données uniquement accessibles côté client, comme les variables de couche de données et les objectifs qui ne se convertissent que côté front-end.
Consultez cet article pour une meilleure compréhension des cas d’utilisation possibles.
Par défaut, getRemoteVisitorData() récupère automatiquement les dernières données personnalisées stockées avec scope=Visitor et les joint au visiteur sans avoir besoin d’appeler la méthode addData(). C’est particulièrement utile pour synchroniser les données personnalisées entre plusieurs appareils.
Paramètres
Un objet avec le type RemoteVisitorDataParamsType contenant :
Valeur de retour
Exceptions levées
Utilisation des paramètres dans getRemoteVisitorData()
La méthode getRemoteVisitorData() offre de la flexibilité en vous permettant de définir divers paramètres lors de la récupération de données sur les visiteurs. Que vous cibliez en fonction d’objectifs, d’expériences ou de variations, la même approche s’applique à tous les types de données.Par exemple, supposons que vous voulez récupérer des données sur les visiteurs qui ont complété un 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é montrée dans cet exemple n’est pas limitée aux données d’objectif. Vous pouvez utiliser des paramètres dans la méthode getRemoteVisitorData() pour récupérer des données sur une variété de comportements de visiteur.
Voici la liste des filtres VisitorDataFiltersType disponibles :

getVisitorWarehouseAudience()

La méthode asynchrone getVisitorWarehouseAudience récupérée avec le hook useData récupère toutes les données d’audience associées au visiteur dans votre entrepôt de données en utilisant le visitorCode et la warehouseKey spécifiés. La warehouseKey est généralement votre ID utilisateur interne. Le paramètre customDataIndex correspond aux données personnalisées Kameleoon que Kameleoon utilise pour cibler vos visiteurs. Consultez la documentation de ciblage d’entrepôt pour plus de détails.
Paramètres
Objet Paramètres composé de :
Valeur de retour
Exceptions levées

setLegalConsent()

La méthode setLegalConsent, récupérée avec le hook useVisitorCode, spécifie si le visiteur a donné son consentement légal pour utiliser les données personnelles. Définir le paramètre legalConsent à false limite les types de données que vous pouvez inclure dans les demandes de suivi. Cela vous aide à respecter les exigences légales et réglementaires tout en gérant de manière responsable les données du visiteur. Vous pouvez trouver plus d’informations sur les données personnelles dans la politique de gestion du consentement.
  • Les informations de consentement sont synchronisées entre le moteur Kameleoon (fichier de l’application engine.js) et le SDK React. Cette synchronisation signifie qu’une fois que le consentement est défini sur le moteur ou 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, lisez la section consentement dans l’article Expérimentation hybride
  • Lors du traitement du consentement légal, il est important d’utiliser la méthode getVisitorCode. De plus, getVisitorCode n’accepte pas domain comme argument. Au lieu de cela, passez-le à la fonction createClient.
Paramètres
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 analytiques tierces

Cette section fournit les méthodes que vous utilisez pour suivre quand une action de visiteur atteint l’un de vos objectifs (une conversion).

trackConversion()

  • 📨 Envoie les données de suivi à Kameleoon
La fonction trackConversion(), utilisée avec le hook useData, crée et ajoute une Conversion aux données du visiteur avec les paramètres spécifiés et exécute flush().Utilisez cette méthode pour suivre une conversion pour un objectif spécifique et un utilisateur. Cette méthode requiert 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 qui a été 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 comportant les paramètres suivants :
Les valeurs de métadonnées sont accessibles via les exports de données brutes et la page de résultats.Si le paramètre metadata est fourni, Kameleoon utilisera les valeurs spécifiées pour la conversion actuelle au lieu de celles précédemment collectées via la méthode addData(). Si le paramètre est omis, Kameleoon utilisera les dernières valeurs suivies pour ces CustomData avant la conversion et au cours de la même visite.Kameleoon ne prendra en compte que les valeurs de métadonnées explicitement passées en paramètres à la méthode trackConversion().Dans l’exemple ci-dessous, Kameleoon associera la conversion uniquement à la valeur de données personnalisées explicitement fournie en paramètre (ici : index 5 avec la valeur ‘Amex Credit Card’).
Exceptions levées

getEngineSuiviCode()

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 les 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. Consultez 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 React et Kameleoon Engine.js. Parce que Engine.js n’est utilisé que pour le suivi dans ce flux, vous pouvez installer la balise asynchrone avant la balise de fermeture </body>.
  • Vous pouvez insérer le code de suivi retourné directement dans une balise <script> HTML.
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

Cette section fournit les méthodes que vous utilisez pour gérer les événements.

setEventHandler()

Utilisez cette méthode pour enregistrer un gestionnaire pour les événements du SDK. Le SDK appelle le gestionnaire lorsque 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é.
Collectez la méthode setEventHandler avec le hook useInitialize.
Pour effacer le gestionnaire actuel d’un type d’événement, passez null comme handler :
DataFileUpdateEventDataType contient des informations sur une mise à jour du fichier de données du SDK.
Paramètres

Envoi d’événements d’exposition à des outils externes
Kameleoon propose des intégrations intégrées avec diverses solutions d’analyse et CDP, telles que Mixpanel, Google Analytics 4, Segment…. Pour garantir que vous pouvez suivre et analyser vos expériences côté serveur, Kameleoon fournit une méthode getEngineTrackingCode() qui renvoie le code JavasScript à insérer dans votre page pour envoyer automatiquement les événements d’exposition à la solution d’analyse que vous utilisez. Le SDK crée un code de suivi pour votre solution d’analyse active en fonction des expériences que le visiteur a déclenchées au cours des 5 dernières secondes. Pour plus d’informations sur l’expérimentation hybride, consultez cette documentation.
Pour bénéficier de cette fonctionnalité, vous devrez implémenter à la fois le SDK React et la balise JavaScript Kameleoon. Implémentez la [balise asynchrone Kameleoon], que vous pouvez installer avant votre balise de fermeture <body> dans votre page HTML, car elle sera utilisée uniquement à des fins de suivi.

Données types

Les types Kameleoon Data sont des classes d’aide utilisées pour stocker les données dans le stockage sous des formes prédéfinies. Pendant l’exécution de flush, le SDK collecte toutes les données et les envoie avec la demande de suivi. Les données disponibles dans le SDK ne sont pas disponibles pour le ciblage et les rapports dans l’application Kameleoon jusqu’à ce que vous ajoutiez 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 le mode hybride, vous pouvez appeler getRemoteVisitorData() pour remplir automatiquement toutes les données que Kameleoon a collectées précédemment.

Browser

Depuis React SDK 10.11.0, Browser est automatiquement détecté en fonction de la chaîne User-Agent. Cependant, vous pouvez toujours le remplacer manuellement si nécessaire.
Browser contains browser informations.
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 comme marqueur pour l’identification unique du visiteur. Si vous ajoutez UniqueIdentifier pour un visiteur, visitorCode est utilisé comme identifiant de visiteur unique, ce qui est utile pour l’expérimentation multi-appareils. L’association d’un UniqueIdentifier à un visiteur notifie le SDK que le visiteur est lié à un autre visiteur. Le UniqueIdentifier peut également être utile dans d’autres scénarios extrêmes, comme lorsque vous ne pouvez pas accéder au visitorCode anonyme qui a été attribué à l’origine au visiteur, mais vous avez accès à un ID interne qui est connecté au visiteur anonyme en utilisant les capacités de fusion de session.
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érience et de personnalisation par tout 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.
  • Généralement, le SDK React tentera d’utiliser un cookie localStorage pour les conditions. Si ce n’est pas possible, le SDK peut utiliser les données Cookie comme alternative.
  • 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 que vous pouvez utiliser pour créer un cookie instantanément en analysant une chaîne qui contient des données de cookie valides. La méthode accepte une string comme paramètre et retourne une instance Cookie initialisée.

GeolocationDonnees

GeolocationData contains du visiteur geolocation détails
Chaque visiteur ne peut avoir qu’une seule GeolocationData. L’ajout d’une deuxième GeolocationData remplace la première.
Un paramètre objet de type GeolocationInfoType contenant les champs suivants :

CustomData

Pour conserver les données personnalisées pour les visites futures, le SDK transmet CustomData avec une portée Visitor lors de la prochaine demande de suivi. Vous pouvez configurer la portée dans les paramètres de données du tableau de bord des données personnalisées. CustomData vous permet d’associer facilement n’importe quel type de données à chaque visiteur. Ces données peuvent ensuite être utilisées comme condition de ciblage dans segments ou comme filtre ou ventilation dans les rapports d’expérience. Pour plus d’informations sur les données personnalisées, reportez-vous à cet article.
  • Chaque visiteur ne peut avoir qu’un seul CustomData pour chaque index unique. Ajouter un autre CustomData avec le même index remplacera celui existant.
  • L’index « données personnalisées » peut être trouvé dans le tableau de bord des 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 à des fins de confidentialité, activez l’option : Use this data only locally for targeting purposes 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’ignoration des données.

Device

Depuis React SDK 10.11.0, Device est automatiquement détecté en fonction de la chaîne User-Agent. Cependant, vous pouvez toujours le remplacer manuellement si nécessaire.React Native : La prise en charge de cette fonction est actuellement expérimentale et peut nécessiter des ajustements pour fonctionner correctement. En React Native, le Device est automatiquement détecté en fonction de la DPI de react-native.Dimensions.
Device contient les informations sur votre appareil.
Chaque visiteur ne peut avoir qu’un seul Device. Ajouter un second Device remplace le premier.

OperatingSystem

Depuis React SDK 10.11.0, OperatingSystem est automatiquement détecté en fonction de la chaîne User-Agent. Cependant, vous pouvez toujours le remplacer manuellement si nécessaire.React Native : La prise en charge de cette fonction est actuellement expérimentale et peut nécessiter des ajustements pour fonctionner correctement. En React Native, le OperatingSystem est automatiquement détecté en fonction de react-native.Platform.
OperatingSystem contient les informations du système d’exploitation du visiteur.
Chaque visiteur ne peut avoir qu’un seul OperatingSystem. Ajouter un second OperatingSystem remplace le précédent.

PageView

Depuis React SDK 10.11.0, PageView est automatiquement détecté en fonction de window.location?.href et document.title. Cependant, vous pouvez toujours le remplacer manuellement si nécessaire.React Native : La prise en charge de cette fonction est actuellement expérimentale et peut nécessiter des ajustements pour fonctionner correctement.
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 qu’une existante notifiera le SDK que le visiteur a revisité la page
PageViewParametersType pageViewParameters - un objet avec les paramètres de l’affichage de la page décrits ci-dessous

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 des araignées et bots internationales IAB/ABC pour identifier les bots et araignées connus. Kameleoon utilise également le champ UserAgent pour filtrer les bots et autres trafic indésirable qui pourrait 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, passez la valeur curl/8.0 de l’userAgent pour les exclure de vos analyses.
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, passez la valeur curl/8.0 de l’userAgent pour les exclure de vos analyses.

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 renvoyés

DonneesFichier

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 d’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 les informations sur une variable associée à la variation assignée.

Méthodes dépréciées

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

isInitialized()

Utilisez la méthode isReady.
La fonction isInitialized, collectée avec le hook useInitialize, est une petite méthode utilitaire qui vérifie si l’initialisation du SDK a été complétée. Par exemple, cela peut être utile lorsque vous travaillez avec une arborescence de composants profondément imbriquée, car cela vous permet de vérifier rapidement la disponibilité du SDK sans avoir à gérer un état global ou transmettre le résultat de l’initialisation à l’aide de props de composants.
Valeur de retour
Une valeur boolean. Renvoie true si le SDK a été initialisé avec succès, sinon renvoie false.

getFeatureFlagVariationKey()

  • 📨 Envoie les données de suivi à Kameleoon
  • 🎯 Événements: EventType.Evaluation
Utilisez la getVariation method.
La méthode getFeatureFlagVariationKey(), utilisée avec le hook useFeatureFlag, récupère la clé de variation pour un visiteur identifié par son visitorCode. Ce processus comprend la vérification des critères de ciblage, l’identification de la variation appropriée assignée au visiteur, le stockage de cette information, et l’envoi d’une demande de suivi.
Si un utilisateur n’a jamais été associé à un feature flag, le SDK retournera aléatoirement une clé de variation selon les règles de ce feature flag. Si l’utilisateur est déjà lié au feature flag, le SDK identifiera la clé de variation précédemment assignée. Si l’utilisateur ne répond à aucune des règles spécifiées, le SDK retournera la valeur par défaut définie dans les règles de livraison des feature flags de Kameleoon. Il est important de noter que la valeur par défaut n’est pas toujours une clé de variation ; elle pourrait également être une valeur booléenne ou un autre type de données, selon la façon dont le feature flag est configuré.
Paramètres
Valeur de retour
Exceptions levées

getVisitorFeatureFlags()

  • 🚫 N’envoie pas les données de suivi à Kameleoon
  • 🎯 Événements : EventType.Evaluation (pour chaque feature flag)
Utilisez la getVariations method.
La méthode getVisitorFeatureFlags, utilisée avec le hook useFeatureFlag, retourne une liste des feature flags actifs qui ciblent le visiteur associé au visitorCode (le visiteur doit avoir une des variations allouées).
Cette méthode collecte uniquement les feature flags qui sont actuellement actifs pour le visiteur. Par conséquent, elle n’inclut pas les feature flags pour lesquels le visiteur est assigné à la variation « off » (par défaut ou contrôle). Si vous avez besoin de récupérer 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 :
Paramètres
Valeur de retour
Exceptions levées

getActiveFeatureFlags()

  • 🚫 N’envoie pas de données de suivi à Kameleoon
  • 🎯 Événements : EventType.Evaluation (pour chaque feature flag)
Utilisez la getVariations method.
La méthode getActiveFeatureFlags, utilisée avec le hook useFeatureFlag, renvoie un Map, où la clé est la clé de la feature flag et la valeur est une information détaillée sur la variation du visiteur et ses variables.
Cette méthode n’interroge que les feature flags actives du visiteur. Cela signifie que le résultat exclut toutes les feature flags auxquelles le visiteur est assigné à la variation off (par défaut ou contrôle). Lorsque vous avez besoin de toutes les feature flags du visiteur pour itérer, utilisez plutôt getFeatureFlags.Consultez la section getVisitorFeatureFlags CAUTION section method pour plus de détails.
Paramètres
Valeur de retour
Exceptions levées

getFeatureFlagVariable()

  • 📨 Envoie les données de suivi à Kameleoon
  • 🎯 Événements: EventType.Evaluation
Utilisez la getVariation method.
La méthode getFeatureFlagVariable, utilisée avec le hook useFeatureFlag, renvoie une variable pour le visiteur sous visitorCode dans la feature flag trouvée, cela inclut la vérification du ciblage, la recherche de la variation correspondante exposée au visiteur et son enregistrement dans le stockage ainsi que l’envoi d’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 à Kameleoon
  • 🎯 Événements : EventType.Evaluation (pour chaque feature flag)
Utilisez la getVariations method.
La méthode getFeatureFlagVariables, utilisée avec le hook useFeatureFlag, renvoie une liste de variables pour le visiteur sous visitorCode dans la feature flag trouvée, cela inclut la vérification du ciblage, la recherche de la variation correspondante exposée au visiteur et son enregistrement dans le stockage ainsi que l’envoi d’une requête de suivi.
Paramètres
Valeur de retour
Exceptions levées

onConfigurationUpdate()

Utilisez la méthode onEvent avec EventType.ConfigurationUpdate à la place.
La méthode onConfigurationUpdate, utilisée avec le hook useInitialize, exécute un callback lors de la mise à jour de la configuration du client.
Ce hook ne fonctionne que pour les événements envoyés par le serveur pour la mise à jour en temps réel.
Paramètres
Exceptions levées

getFeatureFlags()

🚫 N’envoie pas de données de suivi à Kameleoon La méthode getFeatureFlags collectée avec le hook useFeatureFlag retourne une liste de feature flags stockées dans la configuration du client.
Valeur de retour
Exceptions levées

onEvent()

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