Passer au contenu principal
Avec le SDK Go, 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. Pour commencer : Pour obtenir de l’aide pour démarrer, consultez le guide du développeur. Journal des modifications : Dernière version du SDK Go : 3.18.0 Changelog. Méthodes du SDK : Pour la documentation complète de référence du SDK Go, consultez la section référence.

Guide du développeur

Suivez cette section pour installer et configurer le SDK, et découvrir les fonctionnalités avancées.

Pour commencer

Installation du client Go

Pour installer le SDK Go de Kameleoon, utilisez la commande go get et installez notre package directement depuis notre dépôt GitHub. Exécutez simplement la commande ci-dessous :

Configuration supplémentaire

Pour fournir des paramètres supplémentaires au SDK Go, vous pouvez utiliser un fichier de configuration, qui vous permet de personnaliser le comportement du SDK. Vous pouvez télécharger un exemple de fichier de configuration ici. Nous recommandons d’installer ce fichier au chemin par défaut /etc/kameleoon/client-go.yaml, qui sera lu automatiquement. Si vous devez personnaliser ce chemin, vous pouvez fournir un argument supplémentaire à la méthode NewClient(). Spécifiez soit une chaîne indiquant un chemin alternatif vers le fichier de configuration, soit ajoutez un objet JavaScript (map) contenant la configuration. La version actuelle du SDK Go dispose des clés suivantes dans le fichier de configuration :
Pour en savoir plus sur client_id et client_secret, et les instructions pour les obtenir, veuillez consulter cet article. Il convient de noter que notre SDK Go utilise l’API Automation et suit le flux des informations d’identification client OAuth 2.0.

Initialisation du client Kameleoon

Une fois notre SDK installé dans votre application, vous devez initialiser Kameleoon. Toutes les interactions avec le SDK, telles que le déclenchement d’une expérience, s’effectuent via l’objet (le client Kameleoon) créé à l’aide de la méthode NewClient(). Vous pouvez personnaliser le comportement du SDK (par exemple, l’environnement ou les informations d’identification) en fournissant un objet de configuration.

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 (à partir du cookie des en-têtes de la 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 le statut ou la variation d’un feature flag pour un utilisateur spécifique, vous devez utiliser la méthode GetVariation() ou IsFeatureActive() pour récupérer la configuration basée sur le 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 du feature, en assignant la variation et en la renvoyant en fonction du featureKey et du visitorCode. La méthode IsFeatureActive() peut être utilisée si vous souhaitez récupérer la configuration d’un feature flag simple qui a uniquement un é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 au visiteur et l’enregistre dans le stockage. Lorsque GetVariationOptParams.Track=true, le SDK enverra l’événement d’exposition à l’expérience spécifiée lors de la prochaine requête de tracking, qui est déclenchée automatiquement en fonction du tracking_interval 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 tracking est effectué. Si GetVariationOptParams.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 vous appuyer sur le tracking côté client géré par le moteur Kameleoon, par exemple. De plus, définir GetVariationOptParams.Track=false est utile lorsque vous utilisez la méthode GetVariations(), où vous pourriez avoir besoin uniquement des variations pour tous les flags sans déclencher d’événements de tracking. Pour en savoir plus sur le fonctionnement du tracking, consultez cet article
Ajout de points de données pour cibler un utilisateur ou filtrer / segmenter les visites dans les rapports
Pour cibler un utilisateur, assurez-vous d’avoir ajouté des points de données pertinents à son profil avant de récupérer la variation du feature 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 les points de données collectés sur d’autres appareils ou pour accéder aux données passées de l’utilisateur (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 de manière asynchrone à partir des serveurs. 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 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, vous permettant de filtrer et de segmenter 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 segmentation de vos résultats sur la base de ces points de données pré-collectés. Voir la liste complète ici. Si vous devez 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. 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 de l’exposition au flag et des conversions d’objectifs
Lorsqu’un utilisateur effectue une action souhaitée (telle qu’un achat), elle 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 suivi de conversion sera envoyée avec la prochaine requête de tracking planifiée, que le SDK envoie à intervalles réguliers (définis par tracking_interval). Si vous préférez envoyer la requête immédiatement, utilisez la méthode FlushVisitorInstantly().
Envoi d’événements aux solutions d’analyse
Pour suivre les conversions et envoyer les é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 tracking unique nécessaire pour envoyer des événements d’exposition à votre solution d’analyse. L’utilisation de cette méthode vous permet d’enregistrer des événements et de les envoyer à la plateforme d’analyse de votre choix.

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 de visiteur précédemment collectées sur chacun des appareils du visiteur et la réconciliation de leur historique de visites 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 des visiteurs 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 ID utilisateur entre les appareils Si le même ID utilisateur est utilisé de manière cohérente sur tous les appareils, la synchronisation est gérée automatiquement sans synchronisation du 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 serveurs distribués), où le même ID utilisateur est disponible sur tous les serveurs, la synchronisation entre les serveurs (avec GetRemoteVisitorData()) est suffisante sans synchronisation supplémentaire du mapping personnalisé. Les clients qui ont besoin de données supplémentaires peuvent consulter la description de la méthode GetRemoteVisitorData() pour obtenir des conseils supplémentaires. 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 la portée Visitor pour vos custom data.
Device A
Device B

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 différentes sessions de visiteurs en une seule. Pour réconcilier l’historique des visites, utilisez CustomData pour 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, l’appel à 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 seront toujours affichées avec 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 seul visiteur. La configuration du SDK garantit que les sessions associées voient toujours la même variation de l’expérience. Cependant, il existe certaines limites concernant l’allocation des variations cross-device. Ces limites sont décrites ici. Suivez le guide activation de la réconciliation cross-device de l’historique 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 l’ajout de UniqueIdentifier(true) - pour récupérer les données de tous les visiteurs liés.
  • TrackConversion() ou Flush*() avec l’ajout de données UniqueIdentifier(true) - pour suivre certaines données pour un visiteur spécifique associé à un autre visiteur.
Comme les custom data que vous utilisez comme identifiant doivent être définies sur la portée Visitor, vous devez utiliser la synchronisation cross-device des custom data 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.
Dans cet exemple, l’application possède une page de connexion. Étant donné que l’ID utilisateur est inconnu au moment de la connexion, un identifiant de visiteur anonyme généré par la méthode GetVisitorCode() est utilisé. Une fois que l’utilisateur s’est connecté, le visiteur anonyme est associé à l’ID utilisateur et utilisé comme identifiant unique pour le visiteur.

Utilisation d’une clé de bucketing personnalisée

Par défaut, Kameleoon utilise un ID de visiteur anonyme unique (visitorCode) pour assigner 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 le 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 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’attribution de Kameleoon utilise votre clé spécifiée au lieu 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 la précision de vos attributions de feature flag, en particulier dans ces situations :
  • Expériences au niveau du compte ou de l’organisation : Pour les produits B2B ou les scénarios où vous souhaitez assigner 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 cruciales pour les A/B tests de fonctionnalités qui impactent une équipe ou une entreprise entière.
En implémentant une clé de bucketing personnalisée, vous garantissez une plus grande cohérence et précision dans 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 :
  • Fournir la clé personnalisée : Vous fournissez votre identifiant personnalisé au SDK Kameleoon en utilisant la méthode AddData(). Dans cette méthode, vous passerez 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 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 configuration 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 hachage pour l’attribution des 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 attributions cohérentes dans divers contextes où cet identifiant est présent.
  • Suivi des données et analyses : Il est essentiel de noter que, bien que le 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 vos analyses reflètent fidèlement les parcours et 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 originales de visiteur restent intactes pour une production de rapports complète.

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 de feature flag est évaluée pour cet utilisateur ou cette requête.

Conditions de ciblage

Les SDK 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 et problèmes internes.

Niveaux de journalisation

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

Gestion personnalisée des journaux

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

Référence

Voici une documentation de référence complète du SDK Go.

Initialisation

Create()

Appelez cette méthode avant toutes les autres pour initialiser le SDK. Cette méthode se trouve dans KameleoonClientFactory. Cela crée une instance de KameleoonClient pour gérer toutes les interactions entre le SDK et votre application.
Arguments
Valeur de retour

CreateFromFile()

Appelez cette méthode avant toutes les autres pour initialiser le SDK. Cette méthode se trouve dans KameleoonClientFactory. Cela crée une instance de KameleoonClient pour gérer toutes les interactions entre le SDK et votre application.
Arguments
Valeur de retour

Forget()

La méthode Forget supprime une instance KameleoonClient du KameleoonClientFactory avec le siteCode spécifié et libère les ressources utilisées par l’instance KameleoonClient. L’instance KameleoonClient ne doit pas être utilisée après l’appel de la méthode Forget.
Arguments

WaitInit()

L’initialisation du client Kameleoon n’est pas immédiate, car elle nécessite une requête au serveur de notre CDN (Content Delivery Network) pour récupérer la configuration actuelle de toutes les expériences actives et feature flags. La méthode WaitInit de kameleoon.KameleoonClient vous permet d’attendre jusqu’à ce que l’instance KameleoonClient soit prête à être utilisée.
Valeur de retour

Feature flags et variations

IsFeatureActive() / IsFeatureActiveWithTracking()

  • 📨 Envoie des données de tracking à Kameleoon (selon le paramètre track)
Utilisez cette méthode si vous souhaitez récupérer la configuration d’un feature flag simple, qui a uniquement un état ON / OFF, par opposition aux feature flags plus complexes avec plusieurs variations ou options de ciblage. Si votre feature flag a des variations et des variables, vous devriez utiliser la méthode GetVariation. Elle prend un visitorCode et un featureKey comme arguments obligatoires pour vérifier si le feature flag est actif pour un utilisateur donné. Si l’utilisateur n’a pas été associé à votre feature flag auparavant, le SDK renvoie une valeur booléenne aléatoire (true si l’utilisateur doit avoir cette fonctionnalité ou false sinon). Cependant, si l’utilisateur est déjà enregistré pour ce feature flag, le SDK détecte la valeur précédente du feature flag.
Il est important de mettre en place une gestion appropriée des erreurs dans votre code pour capturer toute exception potentielle qui pourrait survenir, comme illustré dans l’exemple de code.
Si vous spécifiez un visitorCode, la méthode IsFeatureActive l’utilise comme identifiant unique de visiteur, ce qui est utile pour l’expérimentation cross-device. Lorsque vous spécifiez un visitorCode et définissez le paramètre isUniqueIdentifier sur true, le SDK lie les données envoyées (flush) au visiteur associé à l’identifiant spécifié.
Le paramètre isUniqueIdentifier est déprécié. Veuillez utiliser UniqueIdentifier à la place.L’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.
Kameleoon utilise le tracking pour compter les sessions et les visiteurs lorsque vous appelez certaines méthodes, telles que IsFeatureActive(), GetVariation() ou GetVariations().Utilisez la valeur par défaut true pour le paramètre GetVariationOptParams.Track lorsque vous exposez les visiteurs à une variation et devez les compter. Définissez le paramètre GetVariationOptParams.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 GetVariationsOptParams.Track sur false. Ce réglage empêche Kameleoon de compter prématurément une session. Vous pouvez ensuite déclencher le tracking ultérieurement 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 en utilisant l’option de configuration de l’intervalle de tracking. Kameleoon regroupe les événements de tracking dans 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 considère les événements comme des sessions distinctes. Une visite apparaît dans vos rapports 30 minutes après le dernier événement enregistré de la session.
La méthode IsFeatureActive() évalue la variante servie, pas l’état du flag maître. 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 feature flag maître est On.
Arguments
Valeur de retour
Exceptions levées

GetVariation()

  • 📨 Envoie des données de tracking à Kameleoon (selon le paramètre GetVariationOptParams.Track)
Récupère la Variation attribuée à un visiteur donné pour un feature flag spécifique. Cette méthode prend un visitorCode et un featureKey comme arguments obligatoires. L’argument GetVariationOptParams.Track est facultatif et vaut true par défaut. Elle renvoie la Variation attribuée au 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 appropriée des erreurs 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 delivery prédéfinie pour un feature flag. En d’autres termes, c’est la variation de repli 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 “Then, for everyone else…” d’une interface de gestion.
Arguments
Valeur de retour
Exceptions levées

GetVariations()

  • 📨 Envoie des données de tracking à Kameleoon (selon le paramètre GetVariationsOptParams.Track)
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 GetVariationsOptParams.OnlyActive et GetVariationsOptParams.Track sont facultatifs.
  • Si GetVariationsOptParams.OnlyActive est défini sur true, la méthode GetVariations() renverra les variations des feature flags à condition que l’utilisateur ne soit pas bucketé avec la variation off.
  • Le paramètre GetVariationsOptParams.Track contrôle si la méthode suivra ou non les attributions de variations. Par défaut, il est défini sur true. S’il est défini sur false, le tracking sera désactivé.
La map renvoyée contient les clés des 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 renvoie la Variation par défaut pour ce flag. Une gestion appropriée des erreurs 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 delivery prédéfinie pour un feature flag. En d’autres termes, c’est la variation de repli 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 “Then, for everyone else…” d’une interface de gestion.
Arguments
Valeur de retour
Exceptions levées
Arguments
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 nécessaire ou doit être ignorée. Cela peut également être utile dans des scénarios tels que le débogage 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. Des 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 SetForcedVariationOptParams.ForceTargeting=false à la place.
Les variations simulées sont toujours prioritaires 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 les analyses et stockée dans le contexte utilisateur comme toute variation évaluée standard, assurant la cohérence dans la production de 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 que votre application reste stable et résiliente.
Il est important de distinguer les variations forcées des variations simulées :
  • Variations forcées : Sont spécifiques à une expérience individuelle.
  • Variations simulées : Affectent le résultat global du feature flag.
Arguments
Exceptions levées

EvaluateAudiences()

  • 📨 Envoie des données de tracking à Kameleoon
Cette méthode évalue les visiteurs par rapport à tous les segments disponibles de l’Audiences Explorer et suit 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 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 récentes disponibles, permettant une attribution précise des audiences en fonction de tous les critères. Après avoir appelé cette méthode, vous pouvez effectuer une analyse détaillée des performances des segments dans l’Audiences Explorer.
Arguments
Exceptions levées

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 du visiteur

GetVisitorCode()

Cette méthode s’appelait auparavant ObtainVisitorCode, qui a été supprimée dans la version 3.0.0 du SDK.
Pour assurer la cohérence de l’identification de l’utilisateur, en particulier lorsque vous utilisez Kameleoon en mode hybride, vous devez appeler la méthode GetVisitorCode() pour obtenir le visitorCode Kameleoon du visiteur actuel. Voici comment cela fonctionne :
  1. Kameleoon vérifie s’il y a un cookie kameleoonVisitorCode associé à la requête HTTP actuelle. S’il est trouvé, Kameleoon utilise ce code comme identifiant du visiteur.
  2. Si aucun cookie n’est trouvé, la méthode générera aléatoirement un nouvel identifiant, ou utilisera l’argument defaultVisitorCode s’il est passé. L’utilisation de vos identifiants comme visitor codes vous permet de faire correspondre les visiteurs Kameleoon avec vos propres utilisateurs sans recherches supplémentaires.
  3. Le cookie côté serveur kameleoonVisitorCode est ensuite défini avec la valeur de l’identifiant via l’en-tête HTTP et la méthode renvoie la valeur de l’identifiant.
Pour plus d’informations, veuillez consulter cet article.
Si vous décidez de fournir votre propre User ID au lieu d’utiliser le visitorCode généré par Kameleoon, il est de votre responsabilité de garantir que le User ID est unique. Le SDK ne vérifie pas l’unicité. Il est important de noter que le User ID que vous fournissez ne doit pas dépasser 255 caractères, car tout caractère excédentaire entraînera la levée d’une exception.
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 à l’aide du Simulation Panel.
  • Manuellement : Définissez manuellement le cookie kameleoonSimulationFFData.
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 suit ce format :
  • kameleoonSimulationFFData={"featureKey":{"expId":10,"varId":20}} : Simule la variation avec varId de l’expérience expId pour le featureKey donné.
  • kameleoonSimulationFFData={"featureKey":{"expId":0}} : Simule la variation par défaut (définie dans la section Then, for everyone else in Production, serve) pour le featureKey donné.
⚠️ Pour garantir un bon fonctionnement, la valeur du cookie doit être encodée comme un composant URI en utilisant une méthode telle que encodeURIComponent.
Arguments
Valeur de retour
Exceptions levées

AddData()

La méthode AddData() ajoute des données de ciblage au stockage pour que d’autres méthodes puissent utiliser les données pour décider de cibler ou non le visiteur actuel. La méthode AddData() ne renvoie 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 à l’aide de 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 déclenché par 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 GetVariation() et GetVariations() 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 est une exception. Les visiteurs peuvent avoir une instance de CustomData associée par index.
Arguments
Exceptions

FlushAll() / FlushVisitor() / FlushVisitorInstantly()

  • 📨 Envoie des données de tracking à Kameleoon
Les méthodes FlushAll()/FlushVisitor()/FlushVisitorInstantly() collectent les données Kameleoon liées au visiteur. Elles envoient ensuite une requête de tracking, avec toutes les données ajoutées à l’aide de la méthode AddData, qui n’ont pas encore été envoyées en utilisant l’une de ces méthodes. Flush*() est non bloquant car l’appel serveur est effectué de manière asynchrone. Flush*() vous permet de contrôler quand les données associées à un visitorCode donné sont envoyées à nos serveurs. Par exemple, si vous appelez AddData() une douzaine de fois, il serait inefficace d’envoyer des données au serveur après chaque appel à AddData(), donc tout ce que vous avez à faire est d’appeler Flush() une fois à la fin. La méthode FlushVisitor()/FlushVisitorInstantly() utilise visitorCode comme identifiant unique du visiteur, ce qui est utile pour l’expérimentation cross-device. Lorsque vous spécifiez un visitorCode et définissez le paramètre isUniqueIdentifier sur true, le SDK lie les données envoyées (flush) au visiteur associé à l’identifiant spécifié.
Le paramètre isUniqueIdentifier est déprécié. Veuillez utiliser UniqueIdentifier à la place.L’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.
Arguments
Exceptions levées

GetRemoteData()

La méthode GetRemoteData() récupère les données externes stockées sur le serveur distant de Kameleoon pour le siteCode spécifié (spécifié dans le constructeur KameleoonClient) selon une clé passée en argument. Cette clé est généralement le Visitor Code Kameleoon ou votre User ID. Vous pouvez utiliser cette méthode pour récupérer les préférences de l’utilisateur, les 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 à l’aide de notre Data API, vous pouvez gérer efficacement de grandes quantités de données et les récupérer pour tous vos visiteurs ou utilisateurs. La valeur de retour de la méthode est un objet JSON qui peut être décodé à l’aide de la fonction json.Unmarshal(). Vous pouvez utiliser ces données pour créer des segments de ciblage avancés pour les feature flags et les expériences, ou pour filtrer les rapports d’expérience et de personnalisation en fonction de toute valeur stockée dans les données récupérées.
Notez que, puisqu’un appel serveur est requis, ce mécanisme est asynchrone.
Nous proposons des intégrations natives avec Mixpanel, Segment et GA4 pour récupérer des cohortes externes et les utiliser dans des feature experiments. La clé utilisée dans ces intégrations est soit notre Visitor code, soit votre User ID. Vous pouvez vous référer à l’exemple de code fourni ci-dessous pour récupérer et utiliser les cohortes Mixpanel :
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 à partir de la Kameleoon Data API. La méthode ajoute les données au stockage pour que d’autres méthodes puissent les utiliser lors des décisions de ciblage. Les données obtenues à l’aide de cette méthode jouent un rôle important 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 de visites passées.
  • utiliser des données qui ne sont accessibles que côté client, comme les variables datalayer et les objectifs qui ne convertissent que sur le front-end.
Lisez cet article pour mieux comprendre les cas d’utilisation 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 avoir besoin d’appeler la méthode AddData(). C’est particulièrement utile pour synchroniser les custom data entre plusieurs appareils.
Le paramètre IsUniqueIdentifier est déprécié. Veuillez utiliser UniqueIdentifier à la place.L’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.
Arguments de GetRemoteVisitorData
Arguments de GetRemoteVisitorDataWithFilter
Arguments de GetRemoteVisitorDataWithOptParams
La méthode GetRemoteVisitorDataWithOptParams est dépréciée. Veuillez utiliser GetRemoteVisitorDataWithFilter et UniqueIdentifier à la place.
Voici la liste des champs de kameleoon.RemoteVisitorDataOptParams :La valeur par défaut de kameleoon.RemoteVisitorDataOptParams qui est types.RemoteVisitorDataFilter{PreviousVisitAmount: 1, CurrentVisit: true, CustomData: true}, peut être obtenue avec la fonction types.DefaultRemoteVisitorDataFilter().
Valeur de retour
Utilisation des paramètres dans GetRemoteVisitorData()
La méthode GetRemoteVisitorData() offre une flexibilité en vous permettant de définir divers paramètres lors de la récupération des 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 souhaitiez récupérer des données sur les visiteurs qui ont atteint un objectif “Order transaction”. Vous pouvez spécifier des paramètres dans la méthode GetRemoteVisitorData() pour affiner votre ciblage. Par exemple, si vous souhaitez 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 sur 5 et Conversions sur true. La flexibilité illustrée dans cet exemple ne se limite pas aux données d’objectif. Vous pouvez utiliser des paramètres dans la méthode GetRemoteVisitorData() pour récupérer des données sur une variété de comportements de visiteurs.
Voici la liste des options types.RemoteVisitorDataFilter disponibles :

GetVisitorWarehouseAudience()

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 ID utilisateur interne. Le paramètre CustomDataIndex correspond aux custom data Kameleoon que Kameleoon utilise pour cibler vos visiteurs. Vous pouvez consulter la documentation sur le ciblage warehouse pour plus de détails. La méthode renvoie un objet CustomData, confirmant que les données ont été ajoutées au visiteur et sont disponibles à des fins de ciblage.
Arguments de GetVisitorWarehouseAudience
Arguments de GetVisitorWarehouseAudienceWithOptParams
Voici la liste des champs de kameleoon.VisitorWarehouseAudienceOptParams :
Pour la méthode GetVisitorWarehouseAudience, les paramètres sont passés à la fonction en tant que params de la structure VisitorWarehouseAudienceParams pour rendre certains d’entre eux facultatifs (WarehouseKey et Timeout).Pour la méthode GetVisitorWarehouseAudienceWithOptParams, seuls les paramètres facultatifs sont passés à la fonction en tant que params de la structure VisitorWarehouseAudienceOptParams.
Valeur de retour

SetLegalConsent()

Vous devez utiliser cette méthode pour spécifier si le visiteur a donné son consentement légal à l’utilisation de ses données personnelles. Définir le paramètre legalConsent sur 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 pouvez trouver plus d’informations sur les données personnelles dans la politique de gestion du consentement.
Arguments
Exceptions levées
Comportement de 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, permettant au cookie de persister jusqu’à son expiration naturelle. Si vos exigences de conformité requièrent la suppression immédiate du fichier de cookie lors de l’opt-out, vous devez le supprimer manuellement en utilisant les méthodes natives de gestion des cookies de votre framework. Le SDK ne supprimera pas le fichier automatiquement.

Objectifs et analyses 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 les arguments facultatifs TrackConversionOptParams.Revenue, TrackConversionOptParams.Negative et TrackConversionOptParams.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.
Le paramètre isUniqueIdentifier est déprécié. Veuillez utiliser UniqueIdentifier à la place.L’isUniqueIdentifier peut également être utile dans d’autres scénarios particuliers, par exemple lorsque vous ne pouvez pas accéder au visitorCode anonyme initialement attribué au visiteur, mais que vous avez accès à un ID interne connecté au visiteur anonyme via les capacités de fusion de sessions.
Arguments
Les valeurs TrackConversionOptParams.Metadata sont accessibles via les exports de données brutes et la page de résultats.Si le paramètre TrackConversionOptParams.Metadata est fourni, Kameleoon utilisera ces valeurs spécifiées pour la conversion actuelle au lieu de ce qui a été précédemment collecté à l’aide de 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 sein de la même visite.Kameleoon ne prendra en compte que les valeurs de métadonnées qui sont explicitement passées en paramètres à la méthode TrackConversion().Dans l’exemple ci-dessous, Kameleoon associera la conversion uniquement à la valeur de custom data explicitement fournie en paramètre (ici : index 5 avec la valeur ‘Amex Credit Card’).
Exceptions

GetEngineTrackingCode()

Kameleoon s’intègre avec plusieurs solutions d’analyse, notamment Mixpanel, Google Analytics 4 et Segment. Pour suivre correctement les expériences côté serveur, appelez la méthode GetEngineTrackingCode() après que le visiteur a déclenché une expérience. Le SDK renvoie des commandes de file d’attente 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’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 Go et Engine.js de Kameleoon. Comme Engine.js n’est utilisé que pour le tracking dans ce flux, vous pouvez installer la balise asynchrone avant la balise de fermeture </body>.
  • Si vous souhaitez uniquement suivre les expériences dans Kameleoon et que vous n’avez pas besoin d’envoyer des événements d’exposition à des outils d’analyse tiers, utilisez le SDK JavaScript / TypeScript. Cette option fonctionne bien pour les plateformes serverless edge compute. Le SDK JavaScript / TypeScript suit automatiquement les variations lorsque vous appelez getVisitorCode, à condition que vous ajoutiez les attributions d’expérience correspondantes à window.kameleoonQueue.
  • 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

Événements

OnUpdateConfiguration()

La méthode OnUpdateConfiguration vous permet de gérer l’événement lorsque la configuration a mis à jour les données. Elle prend un paramètre d’entrée, handler. Le handler qui sera appelé lorsque la configuration est mise à jour à l’aide d’un événement de configuration en temps réel.
Arguments

Types de données

Browser

L’ensemble de données Browser stocké ici peut être utilisé pour filtrer les rapports d’expérience et de personnalisation par n’importe quelle valeur qui lui est associée.

Conversion

L’ensemble 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 lui est associé.
  • Chaque visiteur peut avoir plusieurs objets Conversion.
  • Vous pouvez trouver le goalId dans l’application Kameleoon.
Cookie contient des informations sur le cookie stocké sur l’appareil du visiteur.
Chaque visiteur ne peut avoir qu’un seul Cookie. L’ajout d’un second Cookie écrase le premier.

Geolocation

Geolocation contient les détails de géolocalisation du visiteur.
  • Chaque visiteur ne peut avoir qu’une seule Geolocation. L’ajout d’une seconde Geolocation écrase la première.

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/segmentation dans les rapports d’expérience. Pour en savoir plus sur les custom data, veuillez consulter cet article.
  • Chaque visiteur ne peut avoir qu’une seule CustomData pour chaque index unique. L’ajout d’une autre CustomData avec le même index remplacera l’existante.
  • L’index des custom data se trouve dans le dashboard Custom Data sous la colonne “INDEX”.
  • Pour empêcher le SDK d’envoyer des données avec l’index sélectionné aux serveurs Kameleoon pour des raisons de confidentialité, activez l’option : Use this data only locally for targeting purposes lors de la création des custom data.
  • Ajouter une instance CustomData créée avec un nom lorsque la configuration de l’instance du SDK n’est pas à jour ou que le nom n’est pas enregistré, entraînera l’ignorance des données.

Device

Vous pouvez utiliser les données d’appareil pour filtrer les rapports d’expérience ou de personnalisation par n’importe quelle valeur associée.
NewDevice

OperatingSystem

OperatingSystem contient des informations sur le système d’exploitation de l’appareil du visiteur.
NewOperatingSystem
Chaque visiteur ne peut avoir qu’un seul OperatingSystem. L’ajout d’un second OperatingSystem écrase le premier.

PageView

Vous pouvez utiliser les données de pageview pour filtrer les rapports d’expérience ou de personnalisation par n’importe quelle valeur associée.
L’index ou l’ID du referrer se trouve dans votre compte Kameleoon. Il est important de noter que cet index commence à 0. Cela signifie que le premier canal d’acquisition que vous créez pour un site donné se verra attribuer 0 comme ID, et non 1.
NewPageView
NewPageViewWithTitle

UserAgent

Les expériences côté serveur sont plus susceptibles d’être affectées par le trafic de bots que les expériences côté client. Kameleoon utilise la IAB/ABC International Spiders and Bots List pour aborder 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 passer la valeur curl/8.0 du userAgent pour les exclure de nos analyses.
NewUserAgent

UniqueIdentifier

Si vous n’ajoutez pas UniqueIdentifier pour un visiteur, visitorCode est utilisé comme identifiant unique du visiteur, ce qui est utile pour l’expérimentation cross-device. Lorsque vous ajoutez UniqueIdentifier pour un visiteur, le SDK lie les données envoyées (flush) au visiteur associé à l’identifiant spécifié. L’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.
NewUniqueIdentifier

ApplicationVersion

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

Types renvoyés

DataFile

Le DataFile contient les détails de configuration du SDK. Il peut être étendu avec des informations supplémentaires si les clients le requièrent. 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 statut d’environnement et d’autres détails connexes. Il peut être étendu avec des informations supplémentaires si les clients le requièrent. 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. Elle peut être étendue avec des informations supplémentaires si les clients le requièrent. 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 la variation par défaut, si aucune attribution spécifique n’existe).
  • L’objet Variation fournit des détails sur la variation attribuée et son expérience associée, tandis que l’objet Variable contient des détails spécifiques sur chaque variable d’une variation.
  • Assurez-vous que votre code gère le cas où VariationID ou ExperimentID peut être nil, 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 dépréciées

Ces méthodes sont dépréciées et seront supprimées dans la version 4.0.0 du SDK.

GetFeatureVariationKey()

  • 📨 Envoie des données de tracking à Kameleoon
Utilisez GetVariation() à la place.
Cette méthode récupère la configuration d’une feature experiment avec plusieurs variations de feature. Vous pouvez l’utiliser pour obtenir une clé de variation pour un utilisateur donné en fournissant visitorCode et featureKey comme arguments obligatoires. Si l’utilisateur n’a jamais été associé au feature flag, le SDK renvoie une clé de variation aléatoirement, en suivant les règles du feature flag. Si l’utilisateur est déjà enregistré pour le feature flag, le SDK détecte la valeur précédente de la variation key. Si l’utilisateur ne correspond à aucune des règles, la valeur par défaut définie dans les règles de delivery du feature flag de Kameleoon sera renvoyée. Il est important de noter que la valeur par défaut peut ne pas être une clé de variation, mais une valeur booléenne ou un autre type de données, selon la configuration du feature flag.
N’oubliez pas de gérer les exceptions potentielles avec une gestion appropriée des erreurs dans votre code. Consultez l’exemple de code pour obtenir des conseils.
Si vous spécifiez un visitorCode, la méthode GetFeatureVariationKey l’utilise comme identifiant unique de visiteur, ce qui est utile pour l’expérimentation cross-device. Lorsque vous spécifiez un visitorCode et définissez le paramètre isUniqueIdentifier sur true, le SDK lie les données envoyées (flush) au visiteur associé à l’identifiant spécifié.
Le paramètre isUniqueIdentifier est déprécié. Veuillez utiliser UniqueIdentifier à la place.L’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.
Arguments
Valeur de retour
Exceptions levées

GetActiveFeatureListForVisitor()

Utilisez GetActiveFeatures() à la place.
La méthode GetActiveFeatureListForVisitor() prend un paramètre visitorCode. Lorsque vous appelez cette méthode avec un visitorCode spécifique, la méthode renvoie une liste des clés de feature flag disponibles pour ce visitorCode. N’oubliez pas de gérer les exceptions potentielles avec une gestion appropriée des erreurs dans votre code. Par exemple, consultez le code suivant :
Arguments
Valeur de retour
Exceptions levées

GetActiveFeatures()

Utilisez GetVariations() à la place.
La méthode GetActiveFeatures() récupère des informations sur les feature flags actifs qui sont disponibles pour le visitor code spécifié. N’oubliez pas de gérer les exceptions potentielles avec une gestion appropriée des erreurs dans votre code. Par exemple, consultez le code suivant :
Arguments
Valeur de retour
Exceptions levées

GetFeatureVariable()

  • 📨 Envoie des données de tracking à Kameleoon
Utilisez GetVariation() à la place.
Pour obtenir une variable de feature d’une clé de variation associée à un utilisateur, appelez la méthode GetFeatureVariable() de notre SDK. Cette méthode prend un visitorCode, un featureKey et un variableKey comme arguments obligatoires pour obtenir une variable de la clé de variation pour un utilisateur donné. Si l’utilisateur n’a jamais été associé au feature flag, le SDK renvoie une valeur de variable de la clé de variation aléatoirement, en suivant les règles du feature flag. Si l’utilisateur est déjà enregistré pour le feature flag, le SDK détecte la valeur précédente de la variation key et renvoie la valeur de la variable. Si l’utilisateur ne correspond à aucune des règles, la valeur par défaut sera renvoyée. N’oubliez pas de gérer les exceptions potentielles avec une gestion appropriée des erreurs dans votre code. Consultez l’exemple de code pour obtenir des conseils.
Le paramètre isUniqueIdentifier est déprécié. Veuillez utiliser UniqueIdentifier à la place.L’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.
Arguments
Valeur de retour
Exceptions levées

GetFeatureVariationVariables()

Utilisez GetVariation() à la place.
Pour récupérer toutes les variables associées à un feature flag, vous devez appeler la méthode GetFeatureVariationVariables. Cette méthode nécessite deux arguments obligatoires : featureKey et variationKey. La méthode renvoie les données avec le type d’objet, tel que défini dans la plateforme Kameleoon. N’oubliez pas de gérer les exceptions potentielles avec une gestion appropriée des erreurs dans votre code. Consultez l’exemple de code pour obtenir des conseils.
Arguments
Valeur de retour
Exceptions levées

GetFeatureList()

Renvoie une liste des clés de feature flag actuellement disponibles pour le SDK.
Valeur de retour