Skip to main content
L’intégration du SDK dans votre application est simple, et son empreinte (mémoire et utilisation réseau) est faible. Pour commencer : pour vous aider à démarrer, consultez le guide du développeur. Dernière version : 0.8.5. Consultez le changelog du SDK C++ pour les notes de version, ou l’index des changelogs des SDK pour tous les SDK. Méthodes du SDK : pour la documentation de référence complète du SDK C++, consultez la section référence.

Guide du développeur

Ce guide est conçu pour vous aider à intégrer rapidement le SDK C++ et à commencer à évaluer des feature flags dans votre application C++.

Pour commencer

Installer le client C++

Le SDK C++ est une bibliothèque C++17 construite au-dessus du Kameleoon SDK Core, une bibliothèque partagée native (libkameleoon_ffi) écrite en Rust qui implémente le comportement du SDK. Votre application lie la bibliothèque C++ statiquement et charge la bibliothèque core à l’exécution.
Le Kameleoon SDK Core est compilé depuis les sources pour votre plateforme et votre architecture cibles. Assurez-vous que Rust et Cargo sont installés et disponibles dans le PATH de votre système, et installez cbindgen, qui génère l’en-tête C de la bibliothèque core :
Installer Rust et Cargo : https://rust-lang.org/tools/installLes versions futures fourniront des bibliothèques core précompilées pour les plateformes courantes afin de simplifier l’installation. La compilation locale restera disponible pour les utilisateurs qui préfèrent compiler depuis les sources.
Prérequis :
  • Un compilateur C++17 (GCC, Clang ou MSVC) et CMake 3.16 ou version ultérieure.
  • Rust 1.91 ou version ultérieure, Cargo et cbindgen pour compiler la bibliothèque SDK Core (libkameleoon_ffi.so sous Linux, libkameleoon_ffi.dylib sous macOS, kameleoon_ffi.dll avec sa bibliothèque d’import kameleoon_ffi.dll.lib sous Windows).
Clonez le dépôt du SDK C++ et compilez la bibliothèque core, puis compilez la bibliothèque C++ en la liant à celle-ci :
Pour intégrer le SDK dans votre propre projet CMake, ajoutez le répertoire cpp/client avec add_subdirectory() et liez la cible Kameleoon::CppClient. Faites pointer KAMELEOON_FFI_LIBRARY vers la bibliothèque core que vous avez compilée ; l’en-tête C est généré avec cbindgen, ou vous pouvez en fournir un existant avec KAMELEOON_FFI_HEADER :
CMakeLists.txt
  • libkameleoon_ffi est chargée à l’exécution : installez-la dans un emplacement de bibliothèques standard, ou livrez-la à côté de votre exécutable. Sous Linux et macOS, la livrer à côté de l’exécutable nécessite un RPATH de $ORIGIN ou @loader_path (par exemple, set_target_properties(my_app PROPERTIES INSTALL_RPATH "$ORIGIN")). Sous Windows, copiez kameleoon_ffi.dll à côté de vos binaires.
  • Lorsque vous créez un client, le SDK vérifie que la bibliothèque libkameleoon_ffi chargée correspond à la version avec laquelle il a été compilé et lève une KameleoonException avec ErrorCode::Internal dans le cas contraire. Mettez toujours à niveau la bibliothèque C++ et la bibliothèque core ensemble.
  • Tous les types publics du SDK se trouvent dans l’espace de noms kameleoon. Incluez kameleoon/kameleoon.hpp pour obtenir l’ensemble de l’API publique.

Configuration supplémentaire

Créez un fichier de configuration JSON (par exemple, client-cpp.json) pour fournir les identifiants et personnaliser le comportement du SDK. Vous pouvez également télécharger notre fichier de configuration d’exemple. Le SDK C++ peut être configuré soit avec un fichier JSON dont vous passez le chemin à KameleoonClientFactory::create(), soit en remplissant une structure KameleoonClientConfig directement dans le code. Le tableau suivant présente les propriétés disponibles que vous pouvez définir :

Initialiser le client Kameleoon

Après avoir installé le SDK et configuré vos identifiants, créez un KameleoonClient en utilisant KameleoonClientFactory.
Les exemples de cette page utilisent les designated initializers de C++20 (GetVariationOptions{.track = false}) pour remplir les structures de configuration, d’options et de données du SDK. Avec un compilateur C++17, déclarez la structure et définissez ses champs un par un à la place.
Un KameleoonClient est l’objet principal utilisé pour évaluer les feature flags, ajouter des données de visiteur et envoyer des requêtes de tracking.
  • Il est recommandé d’utiliser KameleoonClient comme un objet singleton, car il sert de pont entre votre application et la plateforme Kameleoon. Il expose toutes les méthodes et propriétés requises pour exécuter des expériences efficacement. KameleoonClient est move-only : conservez-le à un seul endroit et passez-le par référence.
  • Le SDK C++ s’initialise de manière asynchrone. Vous devez appeler initialize() avant de vous appuyer sur l’évaluation des fonctionnalités dans le code de production.
  • Chaque échec du SDK est signalé sous la forme d’une KameleoonException. Entourez les appels au SDK de blocs try/catch.

Activer un feature flag

Attribution d’un ID unique à un utilisateur
Pour attribuer un ID unique à un utilisateur, vous pouvez utiliser la méthode get_visitor_code(). Si un visitor code n’existe pas (dans le cookie des en-têtes de requête), la méthode génère un ID unique aléatoire ou utilise un default_visitor_code 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 get_visitor_code() garantit que le fichier d’application engine.js (anciennement nommé kameleoon.js) et le SDK partagent l’ID unique (visitor code).
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 get_variation() ou is_feature_active() pour récupérer la configuration en fonction de la feature_key. La méthode get_variation() 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 attribuant la variation et en la renvoyant en fonction de la feature_key et du visitor_code. Vous pouvez utiliser la méthode is_feature_active() pour récupérer la configuration d’un feature flag simple qui n’a qu’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 (comme des comportements spécifiques liés à chaque variation), get_variation() vous permet également d’accéder à l’objet Variation, qui fournit des détails sur la variation attribuée et son expérience associée. Cette méthode vérifie si le feature flag cible l’utilisateur, trouve la variation attribuée au visiteur et l’enregistre dans le stockage. Lorsque track=true, le SDK envoie l’événement d’exposition à l’expérience spécifiée lors de la prochaine requête de tracking, qu’il déclenche automatiquement en fonction du tracking_interval_millis du SDK. L’intervalle par défaut est de 1000 millisecondes (1 seconde). La méthode get_variation() vous permet de contrôler si le SDK suit le visiteur. Si track=false, le SDK n’envoie aucun événement d’exposition. Cette option est utile si vous préférez ne pas suivre les données via le SDK et vous appuyer plutôt sur le tracking côté client géré par le moteur Kameleoon, par exemple. De plus, définir track=false est utile lorsque vous utilisez la méthode get_variations(), où vous pourriez n’avoir besoin que 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é les 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 add_data() 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 lors de l’utilisation de Kameleoon en mode hybride), utilisez la méthode get_remote_visitor_data(). Cette méthode récupère les données depuis les serveurs de manière asynchrone. Il est important d’appeler get_remote_visitor_data() avant de récupérer la variation ou de vérifier si le feature flag est actif, car le SDK peut avoir besoin de ces données pour attribuer un utilisateur à une variation donnée. Pour en savoir plus sur les conditions de ciblage disponibles, consultez l’article détaillé sur le sujet. De plus, les 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 des conversions d’objectifs
Lorsqu’un utilisateur effectue une action souhaitée (comme un achat), elle est enregistrée comme une conversion. Pour suivre les conversions, utilisez la méthode track_conversion() et fournissez les paramètres requis visitor_code et goal_id. Le SDK envoie la requête de tracking de conversion avec la prochaine requête de tracking planifiée, qui a lieu à intervalles réguliers (définis par tracking_interval_millis). Si vous préférez envoyer la requête immédiatement, utilisez la méthode flush_instant().
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 get_engine_tracking_code(). La méthode get_engine_tracking_code() récupère le code de tracking unique requis pour envoyer les é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.

Gestion des erreurs

Chaque erreur levée par le SDK est une KameleoonException, donc un seul gestionnaire pour ce type intercepte tous les échecs du SDK. Gérez un type d’erreur spécifique lorsque votre application doit réagir à un échec particulier, par exemple pour revenir à votre comportement par défaut lorsqu’un feature flag n’est pas dans la configuration ou que le SDK n’est pas encore initialisé. La section de référence de chaque méthode liste les erreurs qu’elle peut lever. KameleoonException dérive de std::runtime_error. Appelez code() pour obtenir le ErrorCode qui distingue les erreurs, et what() pour obtenir le message.
Les chaînes passées au SDK doivent être de l’UTF-8 valide. Les callbacks que vous fournissez au SDK (surcharges de CookieAccessor, gestionnaires d’événements et loggers) ne doivent pas lever d’exception : toute exception qui s’en échappe est interceptée à la frontière du SDK et ignorée.
Les erreurs du SDK sont un comportement attendu, pas des plantages : un feature flag qui n’est pas encore activé, un SDK qui charge encore sa configuration ou une défaillance réseau sont toutes des conditions normales. Lorsque l’évaluation d’un feature échoue, journalisez l’erreur et revenez à votre comportement par défaut afin que le visiteur bénéficie toujours d’une expérience fonctionnelle.

Opérations asynchrones

Les opérations liées au réseau (initialize(), flush_instant(), get_remote_data(), get_remote_visitor_data() et get_visitor_warehouse_audience()) s’exécutent sur le thread de travail propre au SDK. Chacune existe sous trois formes, afin que vous puissiez choisir celle qui convient au thread appelant :
Une completion est une Completion<void> (std::function<void(std::exception_ptr)>), ou une Completion<T> (std::function<void(std::exception_ptr, T)>) pour les opérations qui renvoient une valeur. Le SDK l’invoque exactement une fois. Vous pouvez omettre la completion pour exécuter l’opération en mode fire-and-forget : les échecs n’apparaissent alors que dans le journal du SDK.
Les completions et les gestionnaires d’événements s’exécutent généralement sur le thread de travail du SDK, mais une completion peut aussi s’exécuter sur le thread appelant, avant que l’appel *_async ne retourne : par exemple, lorsque le SDK échoue immédiatement (le client n’est pas prêt, le visitor code est invalide) ou lorsque initialize_async() est appelé sur un client déjà initialisé. Ne supposez pas qu’une completion s’exécute sur un thread particulier ou après le retour de l’appel, et ne conservez pas un verrou pendant l’appel si la completion prend le même verrou. Les completions et les gestionnaires d’événements ne doivent pas bloquer, ne doivent pas lever d’exception et ne doivent pas appeler la forme bloquante d’une opération du SDK : elle attend le même thread de travail et provoque un interblocage. Transmettez le résultat à votre propre boucle d’événements et terminez-y le travail.
C++20 n’a pas de type de tâche de coroutine intégré, donc co_await ne fonctionne qu’à l’intérieur d’une coroutine dont le type de promesse accepte l’Awaitable<T> du SDK (KAMELEOON_HAS_COROUTINES est défini par kameleoon/async.hpp lorsque les coroutines sont disponibles). Par défaut, la coroutine reprend sur le thread de travail du SDK ; appelez .via(executor) sur l’awaitable pour reprendre sur votre propre boucle d’événements à la place. Les frameworks avec leurs propres types de coroutines, comme Boost.Asio, nécessitent un petit adaptateur autour de la forme completion ; consultez l’exemple de serveur fourni avec le SDK.
Les méthodes d’évaluation (get_visitor_code(), get_variation(), get_variations(), is_feature_active(), add_data(), track_conversion() et flush()) sont des appels synchrones en mémoire et n’ont besoin de rien de tout cela.

Utiliser une clé de bucketing personnalisée

Par défaut, Kameleoon utilise un identifiant visiteur unique et anonyme (visitor_code) pour attribuer les utilisateurs aux variations des 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 SDK côté client et côté serveur, et 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 le même variant 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 la clé que vous spécifiez au lieu du visitor_code 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 flags, en particulier dans ces situations :
  • Expériences au niveau d’un compte ou d’une organisation : pour les produits B2B ou les scénarios où vous souhaitez attribuer tous les utilisateurs d’une même organisation à la même variation, vous pouvez utiliser un identifiant comme un account_id. Les clés de bucketing personnalisées sont cruciales pour l’A/B testing de fonctionnalités qui impactent toute une équipe ou une entreprise.
En implémentant une clé de bucketing personnalisée, vous garantissez 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 un feature flag, vous fournissez à Kameleoon un identifiant spécifique issu des données de votre application :
  • Fournir la clé personnalisée : vous fournissez votre identifiant personnalisé au SDK Kameleoon en utilisant la méthode add_data(). Dans cette méthode, vous passez la clé de bucketing personnalisée de votre choix sous la forme d’un objet CustomData. Ici, new_visitor_code fait référence à l’identifiant que vous souhaitez utiliser pour votre bucketing (par exemple, le nouveau user_id ou account_id).
Pour que la clé de bucketing personnalisée fonctionne correctement, vous devez également la définir et la configurer 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 que vous fournissez une clé de bucketing personnalisée via la méthode add_data(), tous les calculs de hachage pour attribuer les utilisateurs aux variations utilisent ce new_visitor_code (votre clé personnalisée) au lieu du visitor_code par défaut. L’utilisation du new_visitor_code signifie que la décision de bucketing dépend de votre identifiant personnalisé, garantissant des attributions cohérentes dans les différents contextes où cet identifiant est présent.
  • Tracking des données et analytics : il est crucial de noter que, bien que le new_visitor_code (votre clé personnalisée) soit utilisé pour les décisions de bucketing, le SDK envoie toutes les données ultérieures (événements de tracking et conversions, par exemple) en les associant au visitor_code d’origine. Cette séparation garantit que vos analytics reflètent fidèlement les parcours et interactions individuels des utilisateurs dans le contexte plus large de votre expérience, même lorsque vous effectuez le bucketing à un niveau supérieur (comme un compte) ou sur plusieurs appareils/sessions. Vos données de visiteur d’origine restent intactes pour des rapports complets.

Exigences techniques

Pour utiliser efficacement une clé de bucketing personnalisée :
  • La clé doit être une std::string.
  • Elle doit être unique pour l’entité que vous souhaitez bucketer (par exemple, si vous utilisez un user_id, l’ID de chaque utilisateur doit être unique).
  • La clé doit être disponible pour le SDK au moment exact où il évalue la décision du feature flag 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.

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 les appareils

Bien que la synchronisation par mapping personnalisé aligne les données de visiteur entre les appareils, elle n’est pas toujours nécessaire. Voici deux scénarios où la synchronisation par mapping personnalisé n’est pas requise : Même ID utilisateur sur tous les appareils Si vous utilisez le même ID utilisateur de manière cohérente sur tous les appareils, le SDK gère la synchronisation automatiquement sans synchronisation par mapping personnalisé. Il suffit d’appeler la méthode get_remote_visitor_data() lorsque vous souhaitez 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 serveurs distribuées), où le même ID utilisateur est disponible sur tous les serveurs, la synchronisation entre serveurs (avec get_remote_visitor_data()) est suffisante sans synchronisation supplémentaire par mapping personnalisé. Les clients qui ont besoin de données supplémentaires peuvent se référer à la description de la méthode get_remote_visitor_data() pour plus d’informations. Dans le code ci-dessous, il est supposé que vous utilisez le même identifiant unique (dans ce cas, le visitor_code, également appelé userId) 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

Utiliser les 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. Après avoir activé la réconciliation cross-device, l’appel à get_remote_visitor_data() avec le paramètre userId récupère toutes les données connues pour un utilisateur donné. Les sessions avec le même identifiant voient toujours la même variation dans une expérience. Dans la vue Visiteur 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. La documentation sur l’expérimentation cross-device décrit ces limites. Suivez le guide activer la réconciliation d’historique cross-device pour configurer vos custom data sur la plateforme Kameleoon. Ensuite, vous pouvez utiliser le SDK normalement. Les méthodes suivantes peuvent être utiles dans le contexte de la fusion de sessions :
  • get_remote_visitor_data() avec la donnée UniqueIdentifier(true) ajoutée - pour récupérer les données de tous les visiteurs liés.
  • track_conversion() ou flush() avec la donnée UniqueIdentifier(true) ajoutée - pour suivre des données pour un visiteur spécifique associé à un autre visiteur.
Comme les custom data que vous utilisez comme identifiant nécessitent la portée Visitor, vous devez utiliser la synchronisation cross-device des custom data pour récupérer l’identifiant avec la méthode get_remote_visitor_data() sur chaque appareil.
Voici un exemple d’utilisation des custom data pour la fusion de sessions.
Dans cet exemple, l’application a une page de connexion. Comme l’ID utilisateur est inconnu au moment de la connexion, l’application utilise un identifiant visiteur anonyme généré par la méthode get_visitor_code(). Après la connexion de l’utilisateur, l’application associe le visiteur anonyme à l’ID utilisateur et l’utilise comme identifiant unique pour le visiteur.

Journalisation

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

Niveaux de journalisation

Le SDK permet de limiter la journalisation par niveau de journalisation.

Gestion personnalisée des journaux

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

Référence

Ceci est la documentation de référence complète du SDK C++.

Initialisation

create()

Pour utiliser le SDK, créez un KameleoonClient avec KameleoonClientFactory::create(), soit à partir d’une structure KameleoonClientConfig, soit à partir d’un fichier de configuration JSON. Les clients sont mis en cache par site code et environnement : des appels répétés à create() avec le même site code et le même environnement renvoient des clients reposant sur la même instance SDK sous-jacente, et la configuration du premier appel prévaut.
Paramètres
Valeur de retour
Exceptions

initialize()

Utilisez initialize() lorsque votre application doit attendre que le client Kameleoon ait terminé son initialisation avant d’évaluer des feature flags. L’appel renvoie le résultat de la récupération de la configuration : il se termine avec succès lorsque le client finit de s’initialiser, et échoue si la récupération initiale de la configuration échoue avant que le client ne soit prêt. Les nouvelles tentatives en arrière-plan continuent après ce premier échec. Une fois qu’une nouvelle tentative réussit, les appels suivants renvoient un résultat positif. Si aucun résultat d’initialisation n’est disponible avant l’expiration du délai d’attente, l’appel échoue. Si vous ne fournissez pas de valeur timeout, le SDK utilise le délai d’attente par défaut défini par default_timeout_millis.
Appelez initialize() une seule fois au démarrage de l’application pour attendre que le SDK ait chargé sa configuration ou que le délai d’attente expire. À chaque requête entrante, utilisez is_ready() comme garde non bloquante avant d’évaluer des feature flags. Même si initialize() échoue, le SDK continue de retenter la récupération de la configuration en arrière-plan, de sorte que is_ready() commence à renvoyer true dès qu’une nouvelle tentative réussit.
Paramètres
Valeur de retour
Exceptions

is_ready()

is_ready() 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 retourne immédiatement sans bloquer ni lever d’exception.
  • Une fois que le SDK est prêt, il le reste. Si un rafraîchissement ultérieur de la configuration échoue, le SDK continue d’utiliser la configuration précédemment téléchargée et ne repasse pas à un état non prêt.
  • Appelez initialize() une seule fois au démarrage de l’application pour attendre que le SDK ait chargé sa configuration ou que le délai d’attente expire. À chaque requête entrante, utilisez is_ready() comme garde non bloquante avant d’évaluer des feature flags. Même si initialize() échoue, le SDK continue de retenter la récupération de la configuration en arrière-plan, de sorte que is_ready() commence à renvoyer true dès qu’une nouvelle tentative réussit.
Valeur de retour

forget()

Supprime le client SDK mis en cache associé au site_code spécifié, de sorte que le prochain appel à create() avec le même site code et le même environnement en crée un nouveau. forget() ne supprime que la référence de la factory. Chaque KameleoonClient créé pour ce site code maintient l’instance SDK sous-jacente (ainsi que son thread de travail, son polling et son tracking) en vie jusqu’à sa destruction, et les opérations asynchrones en cours la maintiennent en vie jusqu’à ce que leurs completions se terminent. Pour libérer les ressources d’arrière-plan, appelez forget() et détruisez toutes les instances KameleoonClient de ce site code.
Paramètres

Feature flags et variations

is_feature_active()

  • 📨 Envoie des données de tracking à Kameleoon (selon l’option track)
Détermine si un feature flag est actif pour un utilisateur donné. Si le visiteur n’a pas encore été évalué pour ce feature flag, le SDK évalue les règles de ciblage et renvoie le résultat. Si le visiteur a déjà une évaluation stockée pour le feature, le SDK réutilise le résultat existant pour assurer la cohérence.
Kameleoon utilise le tracking pour compter les sessions et les visiteurs lorsque vous appelez certaines méthodes, telles que is_feature_active(), get_variation() ou get_variations().Utilisez la valeur par défaut true pour le paramètre track lorsque vous exposez les visiteurs à une variation et devez 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 get_variations() pour récupérer toutes les variations avant d’exposer les visiteurs, définissez le paramètre track sur false. Ce réglage empêche Kameleoon de compter prématurément une session. Vous pouvez ensuite déclencher le tracking plus tard, lorsque vous exposez explicitement le visiteur.Kameleoon envoie les données de tracking toutes les secondes par défaut. Vous pouvez configurer cet intervalle jusqu’à 5 secondes à l’aide de l’option de configuration de l’intervalle de tracking. Kameleoon regroupe les événements de tracking en une seule session tant que l’intervalle entre les événements est inférieur à 30 minutes. Si plus de 30 minutes s’écoulent entre les événements de tracking, Kameleoon compte les événements comme des sessions distinctes. Une visite apparaît dans vos rapports 30 minutes après le dernier événement enregistré dans la session.
La méthode is_feature_active() évalue le variant servi, pas l’état du flag principal. 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 principal est On.
Paramètres
Valeur de retour
Exceptions

get_variation()

  • 📨 Envoie des données de tracking à Kameleoon (selon le paramètre track)
Récupère la Variation attribuée à un visiteur donné pour un feature flag spécifique. Cette méthode prend un visitor_code et une feature_key comme arguments obligatoires. L’argument 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 du feature flag, la méthode renvoie la Variation par défaut du feature flag donné. Assurez-vous que votre code inclut une gestion d’erreurs approprié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 diffusion prédéfinie pour un feature flag. En d’autres termes, il s’agit de 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 par la variation de la section “Then, for everyone else…” dans l’interface de gestion.
Paramètres
Le paramètre facultatif track est passé comme champ track d’une structure GetVariationOptions.
Valeur de retour
Exceptions

get_variations()

  • 📨 Envoie des données de tracking à Kameleoon (selon le paramètre track)
Récupère une map d’objets Variation attribués à un visiteur donné pour l’ensemble des feature flags. Cette méthode parcourt tous les feature flags disponibles et renvoie la Variation attribuée pour chaque flag associé au visiteur spécifié. Elle prend visitor_code comme argument obligatoire, tandis que only_active et track sont facultatifs.
  • Si vous définissez only_active sur true, la méthode get_variations() renvoie les variations des feature flags uniquement si le visiteur n’est pas bucketé avec la variation off.
  • Le paramètre track contrôle si la méthode effectue le tracking des attributions de variations. Par défaut, il vaut true. S’il vaut false, la méthode n’effectue pas le tracking des attributions de variations.
La map renvoyée est constituée des clés des feature flags comme clés et de leur Variation correspondante comme valeurs. Si le SDK n’attribue aucune variation pour un feature flag, la méthode renvoie la Variation par défaut de ce flag. Implémentez une gestion d’erreurs approprié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 diffusion prédéfinie pour un feature flag. En d’autres termes, il s’agit de 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 par la variation de la section “Then, for everyone else…” dans l’interface de gestion.
Paramètres
Les paramètres facultatifs only_active et track sont passés comme champs d’une structure GetVariationsOptions.
Valeur de retour
Exceptions

set_forced_variation()

Cette méthode vous permet d’attribuer de manière programmatique une Variation spécifique à un utilisateur, en contournant le processus d’évaluation standard. La méthode est particulièrement utile pour les expériences contrôlées où la logique d’évaluation habituelle n’est pas requise ou doit être ignorée. Elle peut également être utile dans des scénarios comme le débogage ou les tests personnalisés. Lorsque vous définissez une variation forcée, elle remplace la logique d’évaluation en temps réel de Kameleoon. Le SDK ignore des processus comme la segmentation, les conditions de ciblage et les calculs algorithmiques. Pour préserver la segmentation et les conditions de ciblage pendant une expérience, définissez plutôt force_targeting=false.
Les variations simulées ont toujours la priorité dans l’ordre d’exécution. Si un calcul de variation simulée démarre, le SDK le traite et le termine entièrement en premier.
Kameleoon traite une variation forcée de la même manière qu’une variation évaluée. Elle est suivie dans les analytics et stockée dans le contexte utilisateur comme toute variation évaluée standard, garantissant la cohérence des rapports. La méthode peut lever des exceptions dans certaines conditions (par exemple, paramètres invalides, contexte utilisateur ou problèmes internes). Une gestion appropriée des exceptions est essentielle pour garantir que votre application reste stable et résiliente.
Il est important de distinguer les variations forcées des variations simulées :
  • Variations forcées : sont spécifiques à une expérience individuelle.
  • Variations simulées : affectent le résultat global du feature flag.
Paramètres
Le paramètre facultatif force_targeting est passé comme champ force_targeting d’une structure SetForcedVariationOptions.
Exceptions

evaluate_audiences()

  • 📨 Envoie des données de tracking à Kameleoon
Cette méthode évalue les visiteurs par rapport à tous les segments Audiences Explorer disponibles et effectue le tracking de ceux qui correspondent. Appelez evaluate_audiences() après avoir défini ou mis à jour toutes les données de visiteur pertinentes, et juste avant de récupérer une variation de feature ou de vérifier un feature flag. Cette approche garantit que Kameleoon évalue le visiteur sur la base des données les plus récentes disponibles, permettant une attribution d’audience précise basée sur tous les critères. Après avoir appelé cette méthode, vous pouvez effectuer une analyse détaillée des performances des segments dans Audiences Explorer.
Paramètres
Exceptions
Dans la plupart des cas, vous n’avez besoin de gérer que l’erreur de base, KameleoonException, comme le montre 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, vous pouvez gérer les erreurs générales du langage en incluant std::exception.

get_datafile()

Pour évaluer tous les feature flags, utilisez get_variations(). Cette méthode est plus efficace que d’appeler DataFile et d’itérer sur les flags avec get_variation().
Renvoie la configuration actuelle du SDK sous la forme d’un objet DataFile. Le DataFile renvoyé est une copie de la configuration actuelle : il ne change pas lorsque le SDK rafraîchit sa configuration.
Valeur de retour
Exceptions

Données de visiteur

get_visitor_code()

Utilisez get_visitor_code() pour obtenir le visitor_code Kameleoon du visiteur actuel. La méthode fonctionne avec tout stockage de cookies qui implémente l’interface CookieAccessor. La logique d’implémentation est la suivante :
  1. Le SDK vérifie si un cookie kameleoonVisitorCode est déjà disponible via l’accesseur fourni.
  2. Si le cookie est absent, le SDK utilise default_visitor_code lorsque vous en fournissez un.
  3. Sinon, le SDK génère un nouveau visitor code et le stocke via l’accesseur.
Pour plus d’informations, consultez l’expérimentation hybride.
Si vous fournissez votre propre visitor_code, son unicité doit être garantie de votre côté. Notez également que la longueur du visitor_code est limitée à 255 caractères.
La méthode get_visitor_code() 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, la méthode lit le cookie et stocke les variations simulées pour ce visiteur ; sa valeur de retour ne change pas. Les évaluations de features ultérieures pour le visiteur, telles que get_variation() et is_feature_active(), contournent alors le processus d’évaluation standard et renvoient la Variation simulée en fonction des données fournies.Vous pouvez appliquer les simulations de deux manières :
  • Automatiquement (recommandé) : si vous utilisez Kameleoon Web Experimentation ou le SDK en mode hybride, Kameleoon crée le cookie automatiquement lorsque vous simulez l’affichage d’un variant à l’aide du panneau de simulation.
  • Manuellement : définissez le cookie kameleoonSimulationFFData manuellement.
Il est important de distinguer les variations simulées des variations forcées :
  • Variations simulées : affectent le résultat global du feature flag.
  • Variations forcées : sont spécifiques à une expérience individuelle.
⚙️ Configuration manuelleAssurez-vous que le cookie kameleoonSimulationFFData respecte ce format :
  • kameleoonSimulationFFData={"featureKey":{"expId":10,"varId":20}} : simule la variation avec le varId de l’expérience expId pour la featureKey donnée.
  • kameleoonSimulationFFData={"featureKey":{"expId":0}} : simule la variation par défaut (définie dans la section Then, for everyone else in Production, serve) pour la featureKey donnée.
⚠️ Pour garantir que la valeur du cookie fonctionne correctement, encodez-la en tant que composant URI à l’aide d’une méthode telle que encodeURIComponent.
Interface CookieAccessor
Implémentez kameleoon::CookieAccessor pour relier les lectures et écritures de cookies du SDK à votre framework HTTP :
  • get() doit renvoyer un cookie déjà écrit via set() dans la réponse en priorité par rapport au cookie de requête du même nom. Le SDK ne conserve aucun état de cookie entre les appels, c’est donc ce qui permet à un second appel de get_visitor_code() au sein de la même requête de renvoyer le code écrit par le premier au lieu d’en générer un nouveau.
  • Les surcharges sont invoquées depuis l’intérieur du SDK et ne doivent pas lever d’exception. Une exception s’échappant de get() est traitée comme un cookie absent. Les valeurs des cookies doivent être de l’UTF-8 valide.
Paramètres
Valeur de retour
Exceptions

add_data()

La méthode add_data() ajoute des données de ciblage au stockage afin que d’autres méthodes puissent utiliser ces données pour décider de cibler ou non le visiteur actuel. La méthode add_data() ne renvoie aucune valeur et n’interagit pas d’elle-même avec les serveurs back-end de Kameleoon. Au lieu de cela, le SDK enregistre toutes les données déclarées pour une transmission future via la méthode flush(). Cette approche réduit le nombre d’appels serveur effectués, car les données sont généralement regroupées en un seul appel serveur déclenché par le flush(). La méthode track_conversion() envoie également toutes les données précédemment associées, tout comme le flush(). Il en va de même pour les méthodes get_variation() et get_variations() 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.
Le paramètre data est un std::vector<Data>, où Data est un std::variant de tous les types de données. Chaque type de données se convertit implicitement en Data, vous pouvez donc passer une liste entre accolades d’objets de données.
Paramètres
Exceptions

flush()

  • 📨 Envoie des données de tracking à Kameleoon
La méthode flush() agrège toutes les données Kameleoon associées à un visiteur et envoie une requête de tracking au serveur. Cette requête inclut toutes les données précédemment ajoutées via la méthode add_data qui n’ont pas encore été transmises par d’autres mécanismes de tracking (consultez les méthodes référencées pour plus de détails). L’opération flush() est non bloquante, car l’appel serveur est effectué de manière asynchrone. Cette méthode permet de contrôler le moment où les données liées à un visitor_code spécifique sont transmises. Par exemple, si add_data() est appelée plusieurs fois, envoyer une requête après chaque invocation serait inefficace. Au lieu de cela, vous pouvez regrouper ces mises à jour et appeler flush() une seule fois pour envoyer toutes les données accumulées en une seule requête. La méthode flush() utilise le visitor_code fourni comme identifiant unique du visiteur.
  • flush() : met en file d’attente une opération de flush selon l’intervalle de tracking configuré.
  • flush_instant() : envoie les données de tracking immédiatement sans attendre l’intervalle.
Paramètres
Exceptions

get_remote_data()

La méthode get_remote_data() vous permet de récupérer des données distantes stockées sur les serveurs Kameleoon pour la key spécifiée. Dans la plupart des configurations, ces données sont écrites via la Data API de Kameleoon et peuvent ensuite être récupérées par votre service C++ chaque fois que vous avez besoin de contexte applicatif supplémentaire. Cette méthode est utile lorsque vous souhaitez conserver des informations structurées sur l’infrastructure distante de Kameleoon et les réutiliser depuis votre back-end sans maintenir un mécanisme de récupération distinct.
Paramètres
Valeur de retour
Exceptions

get_remote_visitor_data()

get_remote_visitor_data() récupère les données de visite Kameleoon pour le visitor_code fourni. La méthode ajoute les données au stockage local des visiteurs afin que les autres méthodes du SDK puissent les utiliser pour les décisions de ciblage. Les données obtenues avec cette méthode sont particulièrement utiles lorsque vous souhaitez :
  • utiliser des données collectées depuis d’autres appareils.
  • accéder à l’historique d’un visiteur, comme les pages précédemment consultées lors de visites passées.
  • utiliser des données qui ne sont disponibles que côté client, telles que les variables du datalayer et les conversions d’objectifs front-end.
Lisez cet article pour une meilleure compréhension des cas d’usage possibles.
Par défaut, get_remote_visitor_data() récupère automatiquement les dernières custom data stockées avec scope=Visitor et les associe au visiteur sans qu’il soit nécessaire d’appeler add_data(). Cela est particulièrement utile pour synchroniser les custom data entre plusieurs appareils.
Paramètres
Exceptions
Utilisation des paramètres dans get_remote_visitor_data()
La méthode get_remote_visitor_data() vous permet de contrôler quelles données sont récupérées pour un visiteur. La même approche de filtrage fonctionne pour les objectifs, les expériences, les variations et les autres données de visiteur. Par exemple, si vous souhaitez cibler les utilisateurs qui ont converti sur un objectif lors de leurs cinq dernières visites, vous pouvez définir previous_visit_amount sur 5 et conversions sur true. La flexibilité illustrée dans cet exemple ne se limite pas aux données d’objectifs. Vous pouvez utiliser le filtre pour récupérer de nombreux comportements de visiteurs différents et les rendre disponibles pour la logique de ciblage et de reporting de votre application C++.
Champs de RemoteVisitorDataFilter

get_visitor_warehouse_audience()

Cette méthode récupère les données d’audience associées à un visiteur dans votre intégration warehouse en utilisant le visitor_code spécifié et, éventuellement, une warehouse_key. La warehouse_key est généralement votre ID utilisateur interne. Le paramètre custom_data_index correspond à la custom data Kameleoon que Kameleoon utilise pour cibler vos visiteurs. Lorsque l’appel réussit, le SDK convertit la liste d’audiences renvoyée en CustomData, l’ajoute localement au visiteur et la rend disponible à des fins de ciblage. Pour plus de contexte, consultez la documentation sur le ciblage warehouse.
Paramètres
Exceptions
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 consent sur false limite les types de données pouvant être inclus dans les requêtes de tracking. Cela vous aide à respecter les exigences légales et réglementaires tout en gérant de manière responsable les données des visiteurs. Pour plus d’informations, consultez la politique de gestion du consentement. Si vous passez un CookieAccessor, le SDK met également à jour les cookies du visiteur en fonction du statut de consentement.
Paramètres
Exceptions
Comportement en cas de retrait du consentement
Lorsque vous appelez set_legal_consent() avec consent=false, le SDK ne supprime pas le cookie kameleoonVisitorCode. Au lieu de cela, il cesse de prolonger la date d’expiration du cookie, permettant au cookie de persister jusqu’à son expiration naturelle. Si vos exigences de conformité imposent la suppression immédiate du fichier cookie lors de l’opt-out, 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 analytics tiers

track_conversion()

  • 📨 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 visitor_code et goal_id. De plus, cette méthode accepte également des arguments optionnels revenue, negative et metadata. Le visitor_code est généralement identique à celui utilisé lors du déclenchement de l’expérience.
Cette méthode est non bloquante car le SDK effectue l’appel serveur de manière asynchrone.
Paramètres
Les paramètres facultatifs revenue, negative et metadata sont passés comme champs d’une structure TrackConversionOptions.
Les valeurs de metadata sont accessibles via les exports de données brutes et la page de résultats.Si vous fournissez le paramètre metadata, Kameleoon utilise ces valeurs spécifiées pour la conversion actuelle au lieu de ce que vous avez précédemment collecté avec la méthode add_data(). Si vous omettez le paramètre, Kameleoon utilise 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 metadata explicitement passées en paramètres à la méthode track_conversion().Dans l’exemple ci-dessous, Kameleoon associera la conversion uniquement à la valeur de custom data explicitement fournie en paramètre (ici : l’index 5 avec la valeur ‘Amex Credit Card’).
Exceptions

get_engine_tracking_code()

Kameleoon s’intègre à plusieurs solutions d’analyse, notamment Mixpanel, Google Analytics 4 et Segment. Pour suivre correctement les expériences côté serveur, appelez la méthode get_engine_tracking_code() 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 5 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 C++ et Engine.js de Kameleoon. Comme ce flux n’utilise Engine.js que pour le tracking, vous pouvez installer le tag asynchrone avant la balise fermante </body>.
  • Si vous souhaitez uniquement suivre les expériences dans Kameleoon et 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 de calcul edge serverless. Le SDK JavaScript / TypeScript suit automatiquement les variations lorsque vous appelez getVisitorCode, à condition d’ajouter les attributions d’expériences 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 ID d’expériences, et 7890 et 8901 sont des ID de variations. Dans votre implémentation, le SDK génère ces valeurs dans le code de tracking renvoyé.
Paramètres
Valeur de retour
Exceptions

Événements

set_event_handler()

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. Le client conserve au plus un gestionnaire par type d’événement : l’enregistrement d’un nouveau gestionnaire pour le même type d’événement remplace le gestionnaire précédent. Le constructeur EventHandler que vous utilisez (EventHandler::datafile_update() ou EventHandler::http_request()) sélectionne le type d’événement, de sorte qu’un gestionnaire et les événements qu’il reçoit ne peuvent pas se désynchroniser. Passer une std::function vide ({}) supprime le gestionnaire actuel pour le type d’événement sélectionné.
DataFileUpdateEvent contient des informations sur une mise à jour du fichier de données du SDK.
Les gestionnaires sont appelés de manière synchrone sur le thread de travail unique du SDK, ils ne doivent donc pas bloquer : le temps passé dans un gestionnaire retarde le polling du fichier de données et les envois de tracking. Ils doivent être thread-safe et ne doivent pas lever d’exception : une exception s’échappant d’un gestionnaire est interceptée et ignorée, et n’affecte jamais le comportement du SDK. N’appelez pas d’opérations SDK bloquantes depuis un gestionnaire ; utilisez les formes *_async et terminez le travail sur un thread applicatif.Une invocation déjà en cours peut se terminer après que vous avez supprimé le gestionnaire ou détruit le client, et le gestionnaire (avec ses captures) est détruit sur un thread du SDK une fois qu’il n’est plus utilisé. Maintenez les objets capturés en vie et thread-safe en conséquence. Un gestionnaire peut se supprimer ou se remplacer lui-même.Toutes les instances KameleoonClient créées pour le même site code et le même environnement partagent un gestionnaire par type d’événement : le dernier gestionnaire défini prévaut, et la destruction de l’une de ces instances le supprime. Conservez une seule instance de client par site code et environnement.
Paramètres

Types de données

Cette section liste les types de données C++ déclarés par le SDK dans l’espace de noms kameleoon (kameleoon/data/*.hpp). Ce sont tous des structures simples que vous passez à add_data().

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.

Browser

Les données Browser stockées ici peuvent être utilisées pour filtrer les rapports d’expérience et de personnalisation par n’importe quelle valeur associée.

Conversion

Les données Conversion stockées ici peuvent être utilisées pour filtrer les rapports d’expérience et de personnalisation par n’importe quel objectif associé.
  • Chaque visiteur peut avoir plusieurs objets Conversion.
  • Vous pouvez trouver le goal_id dans l’application Kameleoon.
Cookie contient des informations sur les cookies stockés sur l’appareil du visiteur.
Chaque visiteur ne peut avoir qu’un seul Cookie. L’ajout d’un second Cookie écrase le premier.

CustomData

CustomData permet d’associer tout type de données à chaque visiteur, ce qui en fait un outil efficace pour les conditions de ciblage dans les segments. De plus, elles peuvent être utilisées comme filtre ou segmentation dans les rapports d’expérience. Pour plus d’informations sur les custom data, consultez cet article. Définissez les types de custom data dans l’application Kameleoon ou la Data API et utilisez-les depuis le SDK. CustomData a deux constructeurs : l’un identifie la custom data par son id (index), l’autre par son name.
  • Chaque visiteur ne peut avoir qu’une seule CustomData pour chaque id (name) unique. L’ajout d’une autre CustomData avec le même id (name) remplacera l’existante.
  • L’« index » de la custom data se trouve dans le tableau de bord Custom Data sous la colonne « INDEX ».
  • Pour empêcher le SDK d’envoyer les données avec l’index sélectionné aux serveurs Kameleoon pour des raisons de confidentialité, activez l’option : Use this data only locally for targeting purposes lors de la création de la custom data.
  • L’ajout d’une instance CustomData créée avec un nom alors que l’instance du SDK n’est pas initialisée ou que le nom n’est pas enregistré entraînera l’ignorance de la donnée.

Device

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

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.

OperatingSystem

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

PageView

Stocke les événements de pages vues.
L’index du référent est disponible dans l’application Kameleoon sur la page de configuration des canaux d’acquisition. Attention : l’index commence à 0, donc le premier canal d’acquisition que vous créez a l’ID 0, et non 1.

UniqueIdentifier

Si vous n’ajoutez pas UniqueIdentifier pour un visiteur, le visitor_code est utilisé comme identifiant unique du visiteur, ce qui est utile pour l’expérimentation cross-device. Lorsque vous ajoutez UniqueIdentifier{true}, le SDK lie les données envoyées (flush) au visiteur associé à l’identifiant spécifié. Cela peut être utile dans les situations où vous ne pouvez pas accéder au visitor_code anonyme initialement attribué à un visiteur, mais où vous avez accès à un identifiant interne lié à ce visiteur via la fusion de sessions.

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 liste internationale des spiders et bots IAB/ABC pour reconnaître les bots et spiders connus, et utilise également le champ UserAgent pour filtrer tout autre trafic indésirable qui pourrait fausser vos métriques de conversion. Pour plus d’informations, consultez l’article d’aide sur le filtrage des bots. Si vous utilisez des bots internes, envoyez la valeur de user-agent curl/8.0 pour les exclure des analytics.

Types renvoyés

DataFile

Le DataFile contient les détails de la configuration du SDK. Il peut être étendu avec des informations supplémentaires si les clients en ont besoin. Si vous avez besoin de plus de détails, contactez 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, ses Rules, le statut de l’environnement et d’autres détails associés). Il peut être étendu avec des informations supplémentaires si les clients en ont besoin. Si vous avez besoin de plus de détails, contactez 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 en ont besoin. Si vous avez besoin de plus de détails, contactez votre Customer Success Manager.

Variation

Variation contient des informations sur la variation attribuée au visiteur, ou la variation par défaut lorsqu’aucune attribution spécifique n’existe.
  • Variation décrit la variation attribuée ou par défaut, tandis que Variable contient les détails de chaque variable individuelle.
  • id et experiment_id peuvent être std::nullopt, ce qui indique une variation par défaut qui n’est pas liée à une attribution d’expérience spécifique.
Méthodes utilitaires supplémentaires :

Variable

Variable contient des informations sur une variable associée à la variation attribuée.
JsonValue
JsonValue représente la valeur d’une variable de variation en C++. Le champ kind distingue les types portant une chaîne ; value est un std::variant<bool, double, std::string>. Les accesseurs typés renvoient std::nullopt lorsque la valeur est d’un autre type :