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.
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
cbindgenpour compiler la bibliothèque SDK Core (libkameleoon_ffi.sosous Linux,libkameleoon_ffi.dylibsous macOS,kameleoon_ffi.dllavec sa bibliothèque d’importkameleoon_ffi.dll.libsous Windows).
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_ffiest 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$ORIGINou@loader_path(par exemple,set_target_properties(my_app PROPERTIES INSTALL_RPATH "$ORIGIN")). Sous Windows, copiezkameleoon_ffi.dllà côté de vos binaires.- Lorsque vous créez un client, le SDK vérifie que la bibliothèque
libkameleoon_ffichargée correspond à la version avec laquelle il a été compilé et lève uneKameleoonExceptionavecErrorCode::Internaldans 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. Incluezkameleoon/kameleoon.hpppour 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 unKameleoonClient en utilisant KameleoonClientFactory.
- Config File
- Code
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.KameleoonClient est l’objet principal utilisé pour évaluer les feature flags, ajouter des données de visiteur et envoyer des requêtes de tracking.
Activer un feature flag
Attribution d’un ID unique à un utilisateur
Pour attribuer un ID unique à un utilisateur, vous pouvez utiliser la méthodeget_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éthodeget_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éthodeadd_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éthodetrack_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éthodeget_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 uneKameleoonException, 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 :
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.
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.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.
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 objetCustomData. Ici,new_visitor_codefait référence à l’identifiant que vous souhaitez utiliser pour votre bucketing (par exemple, le nouveauuser_idouaccount_id).
- 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 cenew_visitor_code(votre clé personnalisée) au lieu duvisitor_codepar défaut. L’utilisation dunew_visitor_codesignifie 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 auvisitor_coded’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éthodeget_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, utilisezCustomData 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éeUniqueIdentifier(true)ajoutée - pour récupérer les données de tous les visiteurs liés.track_conversion()ouflush()avec la donnéeUniqueIdentifier(true)ajoutée - pour suivre des données pour un visiteur spécifique associé à un autre visiteur.
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 unKameleoonClient 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.
- create(config struct)
- create(config file)
Paramètres
Valeur de retour
Exceptions
initialize()
Utilisezinitialize() 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.
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.
Valeur de retour
forget()
Supprime le client SDK mis en cache associé ausite_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)
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.Paramètres
Valeur de retour
Exceptions
get_variation()
- 📨 Envoie des données de tracking à Kameleoon (selon le paramètre
track)
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)
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_activesurtrue, la méthodeget_variations()renvoie les variations des feature flags uniquement si le visiteur n’est pas bucketé avec la variationoff. - Le paramètre
trackcontrôle si la méthode effectue le tracking des attributions de variations. Par défaut, il vauttrue. S’il vautfalse, la méthode n’effectue pas le tracking des attributions de variations.
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 uneVariation 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.
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
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()
Renvoie la configuration actuelle du SDK sous la forme d’un objetDataFile.
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()
Utilisezget_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 :
- Le SDK vérifie si un cookie
kameleoonVisitorCodeest déjà disponible via l’accesseur fourni. - Si le cookie est absent, le SDK utilise
default_visitor_codelorsque vous en fournissez un. - Sinon, le SDK génère un nouveau visitor code et le stocke via l’accesseur.
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
kameleoonSimulationFFDatamanuellement.
- Variations simulées : affectent le résultat global du feature flag.
- Variations forcées : sont spécifiques à une expérience individuelle.
kameleoonSimulationFFData respecte ce format :kameleoonSimulationFFData={"featureKey":{"expId":10,"varId":20}}: simule la variation avec levarIdde l’expérienceexpIdpour lafeatureKeydonnée.kameleoonSimulationFFData={"featureKey":{"expId":0}}: simule la variation par défaut (définie dans la section Then, for everyone else in Production, serve) pour lafeatureKeydonnée.
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 viaset()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 deget_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.
- Custom
- Drogon
Paramètres
Valeur de retour
Exceptions
add_data()
La méthodeadd_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.
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
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.
Paramètres
Exceptions
get_remote_data()
La méthodeget_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.
Paramètres
Exceptions
Utilisation des paramètres dans get_remote_visitor_data()
La méthodeget_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 levisitor_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
set_legal_consent()
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éfinirconsent 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 appelezset_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
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.
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éthodeget_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>.
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 constructeurEventHandler 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é.
- datafile_update
- http_request
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 nomskameleoon (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.
Browser
Les donnéesBrowser 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éesConversion stockées ici peuvent être utilisées pour filtrer les rapports d’expérience et de personnalisation par n’importe quel objectif associé.
Cookie
Cookie contient des informations sur les cookies stockés sur l’appareil du visiteur.
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
CustomDatapour chaqueid(name) unique. L’ajout d’une autreCustomDataavec le mêmeid(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
CustomDatacréé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.
OperatingSystem
OperatingSystem contient des informations sur le système d’exploitation de l’appareil du visiteur.
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 pasUniqueIdentifier 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 champUserAgent 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
LeDataFile 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
LeFeatureFlag 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
LaRule 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.
Variationdécrit la variation attribuée ou par défaut, tandis queVariablecontient les détails de chaque variable individuelle.idetexperiment_idpeuvent êtrestd::nullopt, ce qui indique une variation par défaut qui n’est pas liée à une attribution d’expérience spécifique.
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 :