Guide du développeur
Ce guide est conçu pour vous aider à intégrer notre SDK en quelques minutes et à commencer à exécuter des expériences dans vos applications Python. Ce tutoriel expliquera la configuration d’un simple A/B test pour modifier le nombre de produits recommandés en fonction des différentes variations.Pour commencer
Installation du client Python
Vous pouvez installer le SDK à l’aide d’un package pip Python. Notre package est hébergé sur le dépôt pip officiel, il vous suffit donc d’exécuter la commande suivante :Configuration supplémentaire
Vous devez fournir les identifiants pour le SDK Python via un fichier de configuration, que vous pouvez également utiliser pour personnaliser le comportement du SDK. Un exemple de fichier de configuration peut être obtenu ici. Nous suggérons d’installer ce fichier dans le chemin par défaut/etc/kameleoon/client-python.yaml, mais vous pouvez le placer à un autre emplacement et passer le chemin en argument à la méthode constructrice KameleoonClient(). Avec la version actuelle du SDK Python, voici les clés disponibles :
Vous pouvez également utiliser
configuration_object de type KameleoonClientConfig comme paramètre lors de l’initialisation. Il a la même liste d’arguments qu’un fichier de configuration. configuration_object est prioritaire sur le fichier de configuration et écrase ses paramètres.
Initialisation du client Kameleoon
Après avoir installé le SDK dans votre application, configuré les bons identifiants (dans/etc/kameleoon/client-python.yaml) et configuré une expérience côté serveur dans le back-office Kameleoon, l’étape suivante consiste à créer le client Kameleoon dans le code de votre application.
Le code à droite donne un exemple clair. Un KameleoonClient est un objet singleton qui agit comme un pont entre votre application et la plateforme Kameleoon. Il inclut toutes les méthodes et propriétés dont vous aurez besoin pour exécuter une expérience.
Les développeurs sont responsables d’assurer la logique correcte de leur code applicatif lors de la mise en œuvre de l’A/B testing avec Kameleoon. Une bonne pratique consiste à toujours supposer qu’un visiteur peut être exclu de l’expérience si elle n’a pas encore été lancée. Cette pratique est simple à mettre en œuvre, car elle s’aligne sur la logique par défaut ou de référence de variation, qui doit toujours être en place. Les exemples de code de la section suivante illustrent cette approche.
Activation d’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 (à partir du 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, appeler la méthode get_visitor_code() garantit que l’ID unique (visitor code) est partagé entre le fichier d’application engine.js (anciennement nommé kameleoon.js) et le SDK.
Récupération de la configuration d’un flag
Pour implémenter un feature flag dans votre code, vous devez d’abord créer le feature flag dans votre compte Kameleoon. Pour déterminer le statut ou la variation d’un feature flag pour un utilisateur spécifique, vous devez utiliser la mé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 retournant en fonction de la feature_key et du visitor_code.
La méthode is_feature_active() peut être utilisée si vous souhaitez 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 (telles que 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 l’utilisateur est ciblé, trouve la variation attribuée au visiteur et l’enregistre dans le stockage. Lorsque track=True, le SDK enverra l’événement d’exposition à l’expérience spécifiée lors de la prochaine requête de tracking, qui est automatiquement déclenchée en fonction du tracking_interval_millisecond du SDK. Par défaut, cet intervalle est défini à 1000 millisecondes (1 seconde).
La méthode get_variation() vous permet de contrôler si le tracking est effectué. Si track=False, aucun événement d’exposition ne sera envoyé par le SDK. Ceci est utile si vous préférez ne pas suivre les données via le SDK et plutôt vous fier au tracking côté client géré par le moteur Kameleoon, par exemple. De plus, définir track=False est utile lors de l’utilisation de la méthode get_variations(), où vous pourriez avoir besoin des variations pour tous les flags sans déclencher d’événements de tracking. Si vous souhaitez en savoir plus sur le fonctionnement du tracking, consultez cet article
Ajout de data points pour cibler un utilisateur ou filtrer / décomposer les visites dans les rapports
Pour cibler un utilisateur, assurez-vous d’avoir ajouté les data points 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 data points au profil de l’utilisateur.
Pour récupérer des data points 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 de manière asynchrone à partir des serveurs. 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 ces données peuvent être nécessaires pour attribuer un utilisateur à une variation donnée.
Pour en savoir plus sur les conditions de ciblage disponibles, consultez l’article détaillé sur le sujet.
De plus, les data points que vous ajoutez au profil du visiteur seront disponibles lors de l’analyse de vos expériences, vous permettant de filtrer et de décomposer vos résultats par facteurs tels que l’appareil et le navigateur. Le mode hybride de Kameleoon collecte automatiquement une variété de data points côté client, facilitant la décomposition de vos résultats sur la base de ces data points pré-collectés. Voir la liste complète ici.
Si vous avez besoin de suivre des data points supplémentaires au-delà de ce qui est automatiquement collecté, 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 (telle qu’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.
La requête de suivi de conversion sera envoyée avec la prochaine requête de tracking planifiée, que le SDK envoie à intervalles réguliers (définis par tracking_interval_millisecond). Si vous préférez envoyer la requête immédiatement, utilisez la méthode flush() avec le paramètre instant=True.
Envoi d’événements vers des solutions analytics
Pour suivre les conversions et envoyer les événements d’exposition à votre solution d’analytics client, vous devez d’abord implémenter Kameleoon en mode hybride. Ensuite, utilisez la méthodeget_engine_tracking_code().
La méthode get_engine_tracking_code() récupère le code de tracking unique nécessaire pour envoyer des événements d’exposition à votre solution d’analytics. L’utilisation de cette méthode vous permet d’enregistrer des événements et de les envoyer à la plateforme d’analytics de votre choix.
Utilisation du SDK Python Kameleoon dans un environnement Django
Si vous utilisez Django, nous vous recommandons d’initialiser le client Kameleoon au démarrage du serveur, dans le fichierapps.py de votre application Django.
Lorsque vous utilisez python manage.py runserver, Django démarre deux processus : un pour le serveur de développement réel, et l’autre pour recharger votre application lorsque le code change.
Vous pouvez également démarrer le serveur sans l’option de rechargement, et vous ne verrez qu’un seul processus en cours d’exécution. Le processus n’est exécuté qu’une seule fois :
python manage.py runserver --noreload
Vous pouvez également vérifier la variable d’environnement RUN_MAIN dans la méthode ready().
ready() ne sera exécuté qu’une seule fois lors de l’initialisation de l’application.
Un autre avantage de l’utilisation de Django est que le SDK lira et écrira automatiquement le visitor_code sur la requête/réponse HTTP via un cookie. Si vous utilisez un autre framework dans un environnement web où vous souhaiteriez utiliser un mécanisme de cookies pour persister le visitor_code, vous devez fournir des implémentations des méthodes
read_cookies() et write_cookies().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 de leurs appareils et la réconciliation de leur historique de visites entre 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 appareils sont disponibles dans l’article sur l’expérimentation cross-device.Synchronisation des custom data entre appareils
Bien que la synchronisation par mapping personnalisé soit utilisée pour aligner les données des visiteurs entre les appareils, elle n’est pas toujours nécessaire. Voici deux scénarios dans lesquels la synchronisation par mapping personnalisé n’est pas requise : Même user ID sur tous les appareils Si le même user ID est utilisé de manière cohérente sur tous les appareils, la synchronisation est gérée automatiquement sans synchronisation 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 ID cohérents
Dans des configurations complexes impliquant plusieurs serveurs (par exemple, des instances de serveurs distribuées), où le même user ID est disponible entre les serveurs, la synchronisation entre les serveurs (avec get_remote_visitor_data()) est suffisante sans synchronisation par mapping personnalisé supplémentaire.
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, on suppose que le même identifiant unique (dans ce cas, le visitor_code, qui peut également être appelé userId) est utilisé de manière cohérente entre les deux appareils pour une récupération précise des données.
Si vous souhaitez synchroniser les données collectées en temps réel, vous devez choisir la portée Visitor pour votre custom data.
Device A
Device B
Utilisation des custom data pour la fusion de sessions
L’expérimentation cross-device permet de combiner l’historique d’un visiteur sur chacun de ses appareils (réconciliation de l’historique). La réconciliation de l’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.
Une fois la réconciliation cross-device activée, l’appel de 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 verront toujours la même variation dans une expérience. Dans la vue Visitor des pages de résultats de votre expérience, ces sessions apparaîtront comme un 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 limitations concernant l’allocation des variations cross-device. Ces limitations sont décrites ici.
Suivez le guide activation de la réconciliation de l’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()avecUniqueIdentifier(True)ajouté - pour récupérer les données de tous les visiteurs liés.track_conversion()ouflush()avecUniqueIdentifier(True)ajouté - pour suivre certaines données pour un visiteur spécifique qui est associé à un autre visiteur.
get_visitor_code() est utilisé. Une fois l’utilisateur connecté, le visiteur anonyme est associé à l’user ID et utilisé comme identifiant unique pour le visiteur.
Utilisation d’une clé de bucketing personnalisée
Par défaut, Kameleoon utilise un ID de visiteur unique et anonyme (visitor_code) pour attribuer les utilisateurs aux variations de feature flag. Cet ID est généralement généré et stocké sur l’appareil de l’utilisateur (dans un cookie de navigateur pour les SDK côté client et côté serveur — dans un stockage persistant pour les SDK mobiles). Cependant, dans certains scénarios, vous pourriez avoir besoin de vous assurer que tous les utilisateurs d’une même organisation voient la même variante d’un feature flag.
L’option Custom Bucketing Key vous permet de remplacer ce comportement par défaut en fournissant votre propre identifiant personnalisé pour le bucketing. Ce remplacement garantit que la logique d’attribution de Kameleoon utilise votre clé spécifiée au lieu du 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 l’exactitude de vos attributions de feature flag, en particulier dans ces situations :- Expériences au niveau du compte ou de l’organisation : Pour les produits B2B ou les scénarios où vous souhaitez 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 test de fonctionnalités qui impactent une équipe ou une entreprise entière.
Détails techniques
Lorsque vous configurez une clé de bucketing personnalisée pour un feature flag, vous fournissez à Kameleoon un identifiant spécifique provenant des données de votre application :- Fourniture de la clé personnalisée : Vous fournissez votre identifiant personnalisé au SDK Kameleoon en utilisant la méthode
add_data(). Dans cette méthode, vous passerez votre clé de bucketing personnalisée choisie en tant qu’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 qu’une clé de bucketing personnalisée est fournie via la méthode
add_data(), tous les calculs de hash pour attribuer les utilisateurs aux variations utiliseront cenew_visitor_code(votre clé personnalisée) au lieu duvisitor_codepar défaut. L’utilisation dunew_visitor_codesignifie que la décision de bucketing est liée à votre identifiant personnalisé, garantissant des attributions cohérentes dans divers contextes où cet identifiant est présent. - Suivi des données et 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, toutes les données ultérieures (événements de tracking et conversions, par exemple) sont envoyées et associées auvisitor_codeoriginal. Cette séparation garantit que vos analytics reflètent avec précision les parcours individuels des utilisateurs et les interactions dans le contexte plus large de votre expérience, même lorsque le bucketing est effectué à un niveau supérieur (comme un compte) ou sur plusieurs appareils/sessions. Vos données de visiteur d’origine restent intactes pour des rapports complets.
Exigences techniques
Pour utiliser efficacement une clé de bucketing personnalisée :- La clé doit être une
str. - 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ù la décision du feature flag est évaluée pour cet utilisateur ou cette requête.
Conditions de ciblage
Les SDK Kameleoon prennent en charge 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 visites pour cibler les utilisateurs. Vous pouvez également utiliser vos propres données externes pour cibler les utilisateurs.Logging
Le SDK génère des logs pour refléter divers processus internes et problèmes.Niveaux de log
Le SDK prend en charge la configuration de la limitation du logging par un niveau de log.Gestion personnalisée des logs
Le SDK écrit ses logs sur la sortie console par défaut. Ce comportement peut être remplacé.La limitation du logging par un niveau de log est effectuée indépendamment de la logique de gestion des logs.
Référence
Voici la documentation de référence complète du SDK Python.create()
Pour commencer à utiliser le SDK, vous devez compléter l’initialisation. Toutes les interactions avec le SDK se font via un objet appeléKameleoon::KameleoonClient, la première chose à faire est donc de créer cet objet.
Arguments
Exceptions levées
wait_init_async()
wait_init_async attend de manière asynchrone l’initialisation du client Kameleoon. Cette méthode vous permet de vérifier si le client a été initialisé avec succès avant de poursuivre d’autres opérations.
Valeur de retour
wait_init()
wait_init attend de manière synchrone l’initialisation du client Kameleoon. Cette méthode vous permet de vérifier si le client a été initialisé avec succès avant de poursuivre d’autres opérations.
Valeur de retour
Feature flags et variations
is_feature_active()
- 📨 Envoie des données de tracking à Kameleoon (selon le paramètre
track)
Anciennement appelée
activate_feature — dépréciée depuis la version 2.1.0 du SDK et sera supprimée dans une future version.is_feature_active().
Cette méthode prend un visitor_code et une feature_key comme arguments obligatoires pour vérifier si le feature sera actif pour un utilisateur donné.
Si un tel utilisateur n’a jamais été associé à ce feature flag, le SDK retourne une valeur booléenne de manière aléatoire (true si le feature sera actif pour l’utilisateur, ou false sinon). Si un utilisateur avec un visitor_code donné est déjà enregistré avec ce feature flag, il détectera la valeur précédente du feature flag.
Vous devez vous assurer qu’une gestion d’erreurs appropriée est mise en place dans votre code, comme indiqué dans l’exemple à droite, pour intercepter les exceptions potentielles.
Si vous spécifiez un visitor_code, la méthode is_feature_active() utilise le visitor_code comme identifiant unique du visiteur, ce qui est utile pour l’expérimentation cross-device. Lorsque vous spécifiez un visitor_code et définissez le paramètre is_unique_identifier sur true, le SDK lie les données flushées au visiteur associé à l’identifiant spécifié.
Le paramètre
is_unique_identifier est déprécié. Veuillez utiliser UniqueIdentifier à la place.Le is_unique_identifier peut également être utile dans d’autres scénarios particuliers, par exemple lorsque vous ne pouvez pas accéder au visitor_code anonyme initialement attribué au visiteur, mais que vous avez accès à un ID interne qui est connecté au visiteur anonyme via les fonctionnalités de fusion de sessions.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 paramétrage 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’à cinq secondes en utilisant l’option de configuration de l’intervalle de tracking. Kameleoon regroupe les événements de tracking dans une seule session tant que l’intervalle entre les événements est inférieur à 30 minutes. Si plus de 30 minutes s’écoulent entre les événements de tracking, Kameleoon 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.Arguments
Valeur de retour
Exceptions levées
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 optionnel et est True par défaut.
Elle retourne la Variation attribuée au visiteur. Si le visiteur n’est associé à aucune règle de feature flag, la méthode retourne la Variation par défaut pour le feature flag donné.
Assurez-vous qu’une gestion d’erreurs appropriée est implémentée dans votre code pour gérer les exceptions potentielles.
La variation par défaut fait référence à la variation attribuée à un visiteur lorsqu’il ne correspond à aucune règle de livraison prédéfinie pour un feature flag. En d’autres termes, c’est la variation de repli appliquée à tous les utilisateurs qui ne sont pas ciblés par des règles spécifiques. Elle est représentée par la variation dans la section “Then, for everyone else…” de l’interface de gestion.
Arguments
Valeur de retour
Exceptions levées
get_variations()
- 📨 Envoie des données de tracking à Kameleoon (selon le paramètre
track)
Variation attribués à un visiteur donné pour tous les feature flags.
Cette méthode itère sur tous les feature flags disponibles et retourne la Variation attribuée pour chaque flag associé au visiteur spécifié. Elle prend visitor_code comme argument obligatoire, tandis que only_active et track sont optionnels.
- Si
only_activeest défini surTrue, la méthodeget_variations()retournera les variations des feature flags à condition que l’utilisateur ne soit pas bucketé avec la variationoff. - Le paramètre
trackcontrôle si la méthode suivra ou non les attributions de variation. Par défaut, il est défini surTrue. S’il est défini surFalse, le tracking sera désactivé.
Variation correspondante comme valeurs. Si aucune variation n’est attribuée pour un feature flag, la méthode retourne la Variation par défaut pour ce flag.
Une gestion d’erreurs appropriée doit être implémentée pour gérer les exceptions potentielles.
La variation par défaut fait référence à la variation attribuée à un visiteur lorsqu’il ne correspond à aucune règle de livraison prédéfinie pour un feature flag. En d’autres termes, c’est la variation de repli appliquée à tous les utilisateurs qui ne sont pas ciblés par des règles spécifiques. Elle est représentée par la variation dans la section “Then, for everyone else…” de l’interface de gestion.
Arguments
Valeur de retour
Exceptions levées
get_data_file()
Retourne la configuration actuelle du SDK sous forme d’objetDataFile.
Valeur de retour
set_forced_variation()
La méthode vous permet d’attribuer programmatiquement uneVariation spécifique à un utilisateur, en contournant le processus d’évaluation standard. Cela est particulièrement utile pour les expériences contrôlées où la logique d’évaluation habituelle n’est pas nécessaire ou doit être ignorée. Cela peut également être utile dans des scénarios comme le débogage ou les tests personnalisés.
Lorsqu’une variation forcée est définie, elle remplace la logique d’évaluation en temps réel de Kameleoon. Des processus tels que la segmentation, les conditions de ciblage et les calculs algorithmiques sont ignorés. Pour préserver la segmentation et les conditions de ciblage pendant une expérience, définissez force_targeting=False à la place.
Les variations simulées prennent toujours la priorité dans l’ordre d’exécution. Si un calcul de variation simulée est déclenché, il sera entièrement traité et complété en premier.
Arguments
Exceptions levées
Dans la plupart des cas, seule l’erreur de base,
KameleoonError, doit être gérée, comme illustré dans l’exemple. Cependant, si différents types d’erreurs nécessitent une réponse, gérez chacun séparément en fonction des besoins spécifiques. De plus, pour une fiabilité accrue, les erreurs générales du langage peuvent être gérées en incluant Exception.evaluate_audiences()
- 📨 Envoie des données de tracking à Kameleoon
evaluate_audiences() doit être appelée après que toutes les données pertinentes du visiteur aient été définies ou mises à jour, et juste avant d’obtenir une variation de feature ou de vérifier un feature flag. Cette approche garantit que le visiteur est évalué par rapport aux données les plus actuelles disponibles, permettant une attribution d’audience précise basée sur tous les critères.
Après avoir appelé cette méthode, vous pouvez effectuer une analyse détaillée des performances des segments dans Audiences Explorer.
Arguments
Exceptions levées
Dans la plupart des cas, seule l’erreur de base,
KameleoonError, doit être gérée, comme illustré dans l’exemple. Cependant, si différents types d’erreurs nécessitent une réponse, gérez chacun séparément en fonction des besoins spécifiques. De plus, pour une fiabilité accrue, les erreurs générales du langage peuvent être gérées en incluant Exception.Données visiteur
get_visitor_code()
Cette méthode s’appelait auparavant
obtain_visitor_code, qui a été supprimée dans la version 3.0.0 du SDK.get_visitor_code() doit être appelée pour obtenir le visitor_code Kameleoon du visiteur actuel. Cette méthode est particulièrement importante lors de l’utilisation de Kameleoon dans un environnement mixte front-end et back-end, où la cohérence de l’identification de l’utilisateur doit être garantie. La logique d’implémentation est décrite ici :
- Tout d’abord, nous vérifions si un cookie ou paramètre de requête kameleoonVisitorCode associé à la requête HTTP actuelle peut être trouvé. Si oui, nous l’utiliserons comme identifiant du visiteur.
- Si aucun cookie/paramètre n’est trouvé dans la requête actuelle, nous générons soit un nouvel identifiant aléatoirement, soit utilisons l’argument default_visitor_code comme identifiant s’il est passé. Cela permet à nos clients d’utiliser leurs propres identifiants comme visitor codes, s’ils le souhaitent, ce qui présente l’avantage supplémentaire de faire correspondre les visiteurs Kameleoon à leurs propres utilisateurs sans aucune recherche supplémentaire dans une table de correspondance.
- Dans tous les cas, le cookie kameleoonVisitorCode côté serveur (via l’en-tête HTTP) est défini avec la valeur. Ensuite, cette valeur d’identifiant est finalement retournée par la méthode.
Si vous fournissez votre propre
visitor_code, vous devez garantir son unicité. Le SDK ne valide pas la valeur passée en argument. Notez également que la longueur du visitor_code est limitée à 255 caractères. Une exception VisitorCodeInvalid est levée si cette limite est dépassée.La méthode
get_visitor_code() vous permet de définir des variations simulées pour un visiteur. Lorsque les cookies (provenant d’une requête ou d’un document) contiennent la clé kameleoonSimulationFFData, le processus d’évaluation standard est contourné. Au lieu de cela, la méthode retourne directement une Variation basée sur les données fournies.Vous pouvez appliquer des simulations de deux manières :- Automatiquement (recommandé) : Si vous utilisez Kameleoon Web Experimentation ou le SDK en mode hybride, le cookie est créé automatiquement lors de la simulation d’affichage d’une variante via le Simulation Panel.
- 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 suit ce format :kameleoonSimulationFFData={"featureKey":{"expId":10,"varId":20}}: Simule la variation avecvarIdde 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.Arguments
Valeur de retour
Exceptions levées
add_data()
La méthodeadd_data() ajoute des données de ciblage au stockage afin que d’autres méthodes puissent les utiliser pour décider de cibler ou non le visiteur actuel.
La méthode add_data() ne retourne aucune valeur et n’interagit pas avec les serveurs back-end Kameleoon par elle-même. Au lieu de cela, toutes les données déclarées sont sauvegardées pour une transmission ultérieure via la méthode flush(). Cette approche réduit le nombre d’appels serveur effectués, car les données sont généralement regroupées en un seul appel serveur 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.
Arguments
Exceptions
flush()
- 📨 Envoie des données de tracking à Kameleoon
flush() prend les données Kameleoon associées au visiteur et toutes les données qui ont été ajoutées précédemment via la méthode add_data, qui n’ont pas encore été envoyées lors de l’appel de l’une de ces méthodes, et envoie une requête de tracking. flush() est non bloquant, car l’appel serveur est effectué de manière asynchrone.
flush() vous permet de contrôler quand les données associées à un visitor_code donné sont envoyées à nos serveurs. Par exemple, si vous appelez add_data() une douzaine de fois, il serait inefficace d’envoyer des données au serveur à chaque appel de add_data(), vous n’avez donc qu’à appeler flush() une seule fois à la fin.
Si vous spécifiez un visitor_code, la méthode flush() l’utilise comme identifiant unique du visiteur, ce qui est utile pour l’expérimentation cross-device. Lorsque vous spécifiez un visitor_code et définissez le paramètre is_unique_identifier sur true, le SDK lie les données flushées au visiteur associé à l’identifiant spécifié.
Le paramètre
is_unique_identifier est déprécié. Veuillez utiliser UniqueIdentifier à la place.Le is_unique_identifier peut également être utile dans d’autres scénarios particuliers, par exemple lorsque vous ne pouvez pas accéder au visitor_code anonyme initialement attribué au visiteur, mais que vous avez accès à un ID interne qui est connecté au visiteur anonyme via les fonctionnalités de fusion de sessions.Arguments
get_remote_data()
- Anciennement appelée
retrieve_data_from_remote_source, qui a été supprimée dans la version3.0.0du SDK. - Si vous souhaitez récupérer des données de manière asynchrone, utilisez plutôt la méthode
get_remote_data_async(disponible depuis la version 2.3.0).
get_remote_data récupère des données de manière synchrone (selon une clé passée en argument) pour un site_code spécifié (spécifié avec KameleoonClient.__init__) stocké sur un serveur Kameleoon distant. Les données sont généralement stockées sur nos serveurs distants via notre Data API. Cette méthode, associée à la disponibilité de nos serveurs hautement évolutifs à cet effet, fournit une méthode pratique pour stocker des quantités massives de données qui peuvent être récupérées pour chacun de vos visiteurs/utilisateurs.
Arguments
Valeur de retour
get_remote_data_async()
La méthodeget_remote_data_async vous permet de récupérer des données de manière asynchrone (selon une clé passée en argument) pour un site_code spécifié (spécifié avec KameleoonClient.__init__) stocké sur un serveur Kameleoon distant. Les données sont généralement stockées sur nos serveurs distants via notre Data API. Cette méthode, associée à la disponibilité de nos serveurs hautement évolutifs à cet effet, fournit une méthode pratique pour stocker des quantités massives de données qui peuvent être récupérées pour chacun de vos visiteurs/utilisateurs.
Arguments
Valeur de retour
get_remote_visitor_data()
get_remote_visitor_data() est une méthode asynchrone pour récupérer les Kameleoon Visits Data pour le visitor_code depuis l’API Kameleoon Data. La méthode ajoute les données au stockage pour que d’autres méthodes puissent les utiliser lors des décisions de ciblage.
Les données obtenues à l’aide de cette méthode jouent un rôle important lorsque vous souhaitez :
- utiliser des données collectées depuis d’autres appareils.
- accéder à l’historique d’un utilisateur, comme les pages visitées lors de visites passées.
- utiliser des données qui ne sont accessibles que côté client, comme les variables du datalayer et les objectifs qui ne convertissent qu’en front-end.
Le paramètre
is_unique_identifier est déprécié. Veuillez utiliser UniqueIdentifier à la place.Le is_unique_identifier peut également être utile dans d’autres scénarios particuliers, par exemple lorsque vous ne pouvez pas accéder au visitor_code anonyme initialement attribué au visiteur, mais que vous avez accès à un ID interne qui est connecté au visiteur anonyme via les fonctionnalités de fusion de sessions.Arguments
Utilisation des paramètres dans get_remote_visitor_data()
La méthodeget_remote_visitor_data() offre de la flexibilité en vous permettant de définir divers paramètres lors de la récupération de données sur les visiteurs. Que vous cibliez en fonction des objectifs, des expériences ou des variations, la même approche s’applique à tous les types de données.
Par exemple, supposons que vous souhaitiez récupérer des données sur les visiteurs qui ont complété l’objectif “Order transaction”. Vous pouvez spécifier des paramètres dans la méthode get_remote_visitor_data() pour affiner votre ciblage. Par exemple, si vous souhaitez cibler uniquement les utilisateurs qui ont converti sur l’objectif lors de leurs cinq dernières visites, vous pouvez définir le paramètre previous_visit_amount à 5 et conversions à true.
La flexibilité montrée dans cet exemple ne se limite pas aux données d’objectif. Vous pouvez utiliser des paramètres dans la méthode get_remote_visitor_data() pour récupérer des données sur une variété de comportements de visiteurs.
Valeur de retour
Voici la liste des options
Kameleoon::Configuration::RemoteVisitorDataFilter disponibles :get_remote_visitor_data_async()
La méthodeget_remote_visitor_data_async récupère de manière asynchrone les custom data stockées dans les serveurs Kameleoon distants pour un visiteur (spécifié à l’aide de l’argument visitor_code). Si add_data est True, cette méthode ajoute automatiquement les données récupérées à un visiteur sans nécessiter d’appel add_data séparé.
Vous devez avoir préalablement stocké des données sur nos serveurs distants, que vous pouvez ajouter avec l’un des appels de tracking suivants dans le SDK :
flushget_feature_variation_keyget_feature_variableis_feature_active
get_remote_visitor_data associée à la disponibilité de nos serveurs hautement évolutifs fournit une méthode pratique pour accéder et synchroniser de grandes quantités de données sur tous les appareils du visiteur.
Si vous spécifiez un visitor_code, la méthode get_remote_visitor_data_async utilise le visitor_code comme identifiant unique du visiteur, ce qui est utile pour l’expérimentation cross-device. Lorsque vous spécifiez un visitor_code et définissez le paramètre is_unique_identifier sur true, le SDK lie les données flushées au visiteur associé à l’identifiant spécifié.
Le paramètre
is_unique_identifier est déprécié. Veuillez utiliser UniqueIdentifier à la place.Le is_unique_identifier peut également être utile dans d’autres scénarios particuliers, par exemple lorsque vous ne pouvez pas accéder au visitor_code anonyme initialement attribué au visiteur, mais que vous avez accès à un ID interne qui est connecté au visiteur anonyme via les fonctionnalités de fusion de sessions.Arguments
Valeur de retour
Utilisation des paramètres dans get_remote_visitor_data_async()
La méthodeget_remote_visitor_data_async() offre de la flexibilité en vous permettant de définir divers paramètres lors de la récupération de données sur les visiteurs. Que vous cibliez en fonction des objectifs, des expériences ou des variations, la même approche s’applique à tous les types de données.
Par exemple, supposons que vous souhaitiez récupérer des données sur les visiteurs qui ont complété l’objectif “Order transaction”. Vous pouvez spécifier des paramètres dans la méthode get_remote_visitor_data_async() pour affiner votre ciblage. Par exemple, si vous souhaitez cibler uniquement les utilisateurs qui ont converti sur l’objectif lors de leurs cinq dernières visites, vous pouvez définir le paramètre previous_visit_amount à 5 et conversions à true.
La flexibilité montrée dans cet exemple ne se limite pas aux données d’objectif. Vous pouvez utiliser des paramètres dans la méthode get_remote_visitor_data_async() pour récupérer des données sur une variété de comportements de visiteurs.
Voici la liste des options
Kameleoon::Configuration::RemoteVisitorDataFilter disponibles :get_visitor_warehouse_audience()
Récupère de manière synchrone toutes les données d’audience associées au visiteur dans votre data warehouse en utilisant le visitor_code et la warehouse_key spécifiés. La warehouse_key est généralement votre user ID interne. Le paramètre custom_data_index correspond à la custom data Kameleoon que Kameleoon utilise pour cibler vos visiteurs. Vous pouvez vous référer à la documentation de ciblage warehouse pour plus de détails. La méthode retourne un objetCustomData, confirmant que les données ont été ajoutées au visiteur et sont disponibles à des fins de ciblage.
Si vous souhaitez récupérer les données de manière asynchrone, utilisez plutôt la méthode
get_visitor_warehouse_audience_async.Arguments
Valeur de retour
Exceptions levées
get_visitor_warehouse_audience_async()
Récupère de manière asynchrone toutes les données d’audience associées au visiteur dans votre data warehouse en utilisant le visitor_code et la warehouse_key spécifiés. La warehouse_key est généralement votre user ID interne. Le paramètre custom_data_index correspond à la custom data Kameleoon que Kameleoon utilise pour cibler vos visiteurs. Vous pouvez vous référer à la documentation de ciblage warehouse pour plus de détails. La méthode retourne un objetCustomData, confirmant que les données ont été ajoutées au visiteur et sont disponibles à des fins de ciblage.
Arguments
Valeur de retour
Exceptions levées
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éfinir le paramètreconsent sur False limite les types de données que vous pouvez inclure dans les requêtes de tracking. Cette méthode vous aide à respecter les exigences légales et réglementaires tout en gérant de manière responsable les données des visiteurs. Vous pouvez trouver plus d’informations sur les données personnelles dans notre politique de gestion des consentements.
Comportement de révocation 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é exigent la suppression immédiate du fichier cookie lors de l’opt-out, vous devez le supprimer manuellement en utilisant les méthodes natives de gestion des cookies de votre framework. Le SDK ne supprimera pas le fichier automatiquement.
Arguments
Exceptions levées
forget()
La méthodeforget supprime une instance de KameleoonClient du KameleoonClientFactory avec le site_code spécifié et libère les ressources utilisées par l’instance de KameleoonClient. L’instance de KameleoonClient ne doit pas être utilisée après l’appel de la méthode forget.
Si vous spécifiez un visitor_code, la méthode track_conversion utilise le visitor_code comme identifiant unique du visiteur, ce qui est utile pour l’expérimentation cross-device. Lorsque vous spécifiez un visitor_code et définissez le paramètre is_unique_identifier sur true, le SDK lie les données flushées au visiteur associé à l’identifiant spécifié.
Le
is_unique_identifier peut également être utile dans d’autres scénarios particuliers, par exemple lorsque vous ne pouvez pas accéder au visitor_code anonyme initialement attribué au visiteur, mais que vous avez accès à un ID interne qui est connecté au visiteur anonyme via les fonctionnalités de fusion de sessions.Arguments
Objectifs et analytics tiers
get_engine_tracking_code()
Kameleoon s’intègre à plusieurs solutions d’analytics, 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 retourne des commandes de queue JavaScript pour les expériences que le visiteur a déclenchées au cours des cinq dernières secondes. Lorsque vous insérez ce code dans la page, Engine.js traite les commandes et envoie les événements d’exposition via l’intégration analytics 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 Python et Kameleoon Engine.js. Étant donné qu’Engine.js n’est utilisé que pour le tracking dans ce flux, vous pouvez installer le tag asynchrone avant la balise de fermeture
</body>. - Si vous souhaitez uniquement suivre les expériences dans Kameleoon et n’avez pas besoin d’envoyer d’événements d’exposition aux outils d’analytics tiers, utilisez le SDK JavaScript / TypeScript. Cette option fonctionne bien pour les plateformes serverless edge compute. Le SDK JavaScript / TypeScript suit automatiquement les variations lorsque vous appelez
getVisitorCode, tant que vous ajoutez les attributions d’expérience correspondantes àwindow.kameleoonQueue.. - Vous pouvez insérer le code de tracking retourné directement dans une balise HTML
<script>.
123456 et 234567 sont des IDs d’expérience, et 7890 et 8901 sont des IDs de variation. Dans votre implémentation, le SDK génère ces valeurs dans le code de tracking retourné.Arguments
Valeur de retour
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 qui a été utilisé lors du déclenchement de l’expérience.
La méthode track_conversion() ne retourne aucune valeur. Cette méthode est non bloquante car l’appel serveur est effectué de manière asynchrone.
Le paramètre
is_unique_identifier est déprécié. Veuillez utiliser UniqueIdentifier à la place.Le is_unique_identifier peut également être utile dans d’autres scénarios particuliers, par exemple lorsque vous ne pouvez pas accéder au visitor_code anonyme initialement attribué au visiteur, mais que vous avez accès à un ID interne qui est connecté au visiteur anonyme via les fonctionnalités de fusion de sessions.Arguments
Les valeurs metadata sont accessibles via les exports de données brutes et la page de résultats.Si le paramètre
metadata est fourni, Kameleoon utilisera ces valeurs spécifiées pour la conversion actuelle au lieu de ce qui a été précédemment collecté via la méthode add_data(). Si le paramètre est omis, Kameleoon utilisera les dernières valeurs trackées pour ces CustomData avant la conversion et au sein de la même visite.Kameleoon ne prendra en compte que les valeurs metadata qui sont 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 : index 5 avec la valeur ‘Amex Credit Card’).Exceptions
Événements
on_update_configuration()
La méthodeon_update_configuration() vous permet de gérer l’événement lorsque la configuration a mis à jour des données. Elle prend un paramètre d’entrée, handler. Le handler qui sera appelé lorsque la configuration est mise à jour via un événement de configuration en temps réel.
Arguments
Types de données
Browser
Le jeu de donnéesBrowser stocké ici peut être utilisé pour filtrer les rapports d’expérience et de personnalisation par toute valeur qui y est associée.
PageView
L’index (ID) du référent est disponible dans la page de configuration du canal d’acquisition de notre Back-Office. Attention : cet index commence à 0, donc le premier canal d’acquisition que vous créez pour un site donné aura l’ID 0, et non 1.
Conversion
Le jeu de donnéesConversion stocké ici peut être utilisé pour filtrer les rapports d’expérience et de personnalisation par tout objectif qui y est associé.
CustomData
CustomData permet d’associer facilement tout type de données à chaque visiteur. Elles peuvent ensuite être utilisées comme condition de ciblage dans les segments ou comme filtre/décomposition dans les rapports d’expérience.
Pour en savoir plus sur les custom data, veuillez consulter cet article.
- Chaque visiteur ne peut avoir qu’une seule
CustomDatapour chaqueindexunique. Ajouter une autreCustomDataavec le mêmeindexremplacera laCustomDataexistante. - L’
indexde la custom data peut être trouvé dans le dashboard Custom Data sous la colonne “INDEX”. - Pour empêcher le SDK d’envoyer des données avec l’index sélectionné aux serveurs Kameleoon pour des raisons de confidentialité, activez l’option Use this data only locally for targeting purposes lors de la création de la custom data.
- Ajouter une instance
CustomDatacréée avec un nom alors que la configuration de l’instance SDK n’est pas à jour ou que le nom n’est pas enregistré, entraînera l’ignorance des données.
Device
UserAgent
Stocke des informations sur le user-agent du visiteur. Les expériences côté serveur sont plus vulnérables au trafic de bots que les expériences côté client. Pour résoudre ce problème, Kameleoon utilise la liste IAB/ABC International Spiders and Bots List pour identifier les bots et spiders connus. Kameleoon utilise également le champUserAgent pour filtrer les bots et autres trafics indésirables qui pourraient autrement fausser vos métriques de conversion. Pour plus de détails, consultez l’article d’aide sur le filtrage des bots.
Si vous utilisez des bots internes, nous vous suggérons de passer la valeur curl/8.0 du userAgent pour les exclure de nos analytics.
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 pour un visiteur, le SDK lie les données flushées au visiteur associé à l’identifiant spécifié.
L’UniqueIdentifier peut également être utile dans d’autres scénarios particuliers, par exemple lorsque vous ne pouvez pas accéder au visitor_code anonyme initialement attribué au visiteur, mais que vous avez accès à un ID interne qui est connecté au visiteur anonyme via les fonctionnalités de fusion de sessions.
OperatingSystem
OperatingSystem contient des informations sur le système d’exploitation de l’appareil du visiteur.
Cookie
Cookie contient des informations sur les cookies stockés sur l’appareil du visiteur.
Geolocation
Geolocation contient les détails de géolocalisation du visiteur.
ApplicationVersion
ApplicationVersion représente le numéro de version sémantique de votre application.
Types retournés
DataFile
LeDataFile contient les détails de configuration du SDK.
Il peut être étendu avec des informations supplémentaires si les clients le demandent. Si vous avez besoin de plus de détails, veuillez contacter 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, Rules, le statut d’environnement et d’autres détails connexes.
Il peut être étendu avec des informations supplémentaires si les clients le demandent. Si vous avez besoin de plus de détails, veuillez contacter votre Customer Success Manager.
Variation
Variation contient des informations sur la variation attribuée au visiteur (ou la variation par défaut, s’il n’existe pas d’attribution spécifique).
- L’objet
Variationfournit des détails sur la variation attribuée et son expérience associée, tandis que l’objetVariablecontient des détails spécifiques sur chaque variable au sein d’une variation. - Assurez-vous que votre code gère le cas où
id_ouexperiment_idpeut êtreNone, indiquant une variation par défaut. - Le hash
variablespeut être vide si aucune variable n’est associée à la variation.
Variable
Variable contient des informations sur une variable associée à la variation attribuée.
Méthodes dépréciées
get_feature_variation_key()
- 📨 Envoie des données de tracking à Kameleoon
Utilisez
get_variation() à la place.get_feature_variation_key.
Cette méthode prend un visitor_code et une feature_key comme arguments obligatoires pour obtenir une variation key pour un utilisateur donné.
Si un tel utilisateur n’a jamais été associé à ce feature flag, le SDK retourne une variation key de manière aléatoire (selon les règles du feature flag). Si un utilisateur avec un visitor_code donné est déjà enregistré avec ce feature flag, il détectera la valeur précédente de variation key. Si l’utilisateur ne correspond à aucune des règles, la valeur par défaut sera retournée, que nous pouvons définir dans le compte de votre client.
Vous devez vous assurer qu’une gestion d’erreurs appropriée est mise en place dans votre code, comme indiqué dans l’exemple à droite, pour intercepter les exceptions potentielles.
Si vous spécifiez un visitor_code, la méthode get_feature_variation_key utilise le visitor_code comme identifiant unique du visiteur, ce qui est utile pour l’expérimentation cross-device. Lorsque vous spécifiez un visitor_code et définissez le paramètre is_unique_identifier sur true, le SDK lie les données flushées au visiteur associé à l’identifiant spécifié.
Le paramètre
is_unique_identifier est déprécié. Veuillez utiliser UniqueIdentifier à la place.Le is_unique_identifier peut également être utile dans d’autres scénarios particuliers, par exemple lorsque vous ne pouvez pas accéder au visitor_code anonyme initialement attribué au visiteur, mais que vous avez accès à un ID interne qui est connecté au visiteur anonyme via les fonctionnalités de fusion de sessions.Arguments
Valeur de retour
Exceptions levées
get_active_features()
Utilisez
get_variations() à la place.Arguments
Valeur de retour
Exceptions levées
get_active_feature_list_for_visitor()
Utilisez
get_variation() à la place.Arguments
Valeur de retour
get_feature_variable()
- 📨 Envoie des données de tracking à Kameleoon
Utilisez
get_variation() à la place.Anciennement appelée
obtain_feature_variable, qui a été supprimée dans la version 3.0.0 du SDK.get_feature_variable.
Cette méthode prend un visitor_code, une feature_key et une variable_key comme arguments obligatoires.
Si un utilisateur n’a jamais été associé à ce feature flag, le SDK retourne une valeur de variable de manière aléatoire (selon les règles du feature flag). Si un utilisateur avec un visitor_code donné est déjà enregistré avec ce feature flag, il détectera la valeur de la variable pour la variation associée. Si l’utilisateur ne correspond à aucune des règles, la variable par défaut sera retournée.
Vous devez vous assurer qu’une gestion d’erreurs appropriée est mise en place dans votre code, comme indiqué dans l’exemple à droite, pour intercepter les exceptions potentielles.
Si vous spécifiez un visitor_code, la méthode get_feature_variable utilise le visitor_code comme identifiant unique du visiteur, ce qui est utile pour l’expérimentation cross-device. Lorsque vous spécifiez un visitor_code et définissez le paramètre is_unique_identifier sur true, le SDK lie les données flushées au visiteur associé à l’identifiant spécifié.
Le paramètre
is_unique_identifier est déprécié. Veuillez utiliser UniqueIdentifier à la place.Le is_unique_identifier peut également être utile dans d’autres scénarios particuliers, par exemple lorsque vous ne pouvez pas accéder au visitor_code anonyme initialement attribué au visiteur, mais que vous avez accès à un ID interne qui est connecté au visiteur anonyme via les fonctionnalités de fusion de sessions.Arguments
Valeur de retour
Exceptions levées
get_feature_variation_variables()
Utilisez
get_variation() à la place.Anciennement appelée
get_feature_all_variables, qui a été supprimée dans la version 3.0.0 du SDK.get_feature_variation_variables. Une variable de feature peut être modifiée facilement via notre application web.
Cette méthode prend le paramètre d’entrée feature_key. Elle retournera des données de type Dict[str,Any], telles que définies sur l’interface web. Elle lèvera une exception (FeatureNotFound) si le feature demandé n’a pas été trouvé dans la configuration interne du SDK.
Arguments
Valeur de retour
Exceptions levées
get_feature_list()
Anciennement appelée
obtain_feature_list, qui a été supprimée dans la version 3.0.0 du SDK.