Passer au contenu principal
Avec le SDK Ruby, vous pouvez exécuter des expériences et activer des feature flags sur votre serveur back-end Ruby. L’intégration de notre SDK dans votre application web est simple, et son empreinte (mémoire et utilisation réseau) est faible. Pour commencer : Pour obtenir de l’aide pour démarrer, consultez le guide du développeur. Changelog : Dernière version du SDK Ruby : 3.20.0 Changelog. Méthodes du SDK : Pour la documentation de référence complète du SDK Ruby, consultez la section référence.

Guide du développeur

Cette section vous explique comment intégrer notre SDK et commencer à exécuter des expériences dans vos applications Ruby. Suivez ce tutoriel pour mettre en place un simple A/B test afin de modifier le nombre de produits recommandés en fonction des différentes variations.

Pour commencer

Installer le SDK

Installez le SDK à l’aide d’un package gem standard, hébergé sur le référentiel officiel RubyGems. Pour l’installer, exécutez la commande suivante :

Configurer le client

Vous fournissez les identifiants pour le SDK Ruby à l’aide d’un fichier de configuration, que vous pouvez également utiliser pour personnaliser le comportement du SDK. Vous pouvez commencer par notre exemple de fichier de configuration. Nous recommandons d’ajouter ce fichier au chemin par défaut /etc/kameleoon/client-ruby.yaml. Si vous utilisez un autre emplacement, vous devez transmettre le chemin en argument à la méthode Kameleoon::KameleoonClientFactory.Create() lors de l’initialisation. Voici les clés disponibles dans la dernière version du SDK :
Le SDK Ruby de Kameleoon utilise l’API Automation et suit le flow d’identifiants client OAuth 2.0.

Initialiser le client

Après avoir installé le SDK dans votre application et configuré les identifiants corrects (dans /etc/kameleoon/client-ruby.yaml ou Kameleoon::KameleoonClientConfig), vous devez configurer une expérience côté serveur dans l’application Kameleoon. L’étape suivante consiste à créer le client Kameleoon dans le code de votre application. Le code suivant fournit un exemple de création du client Kameleoon. Un Kameleoon::KameleoonClient est un objet singleton qui agit comme un pont entre votre application et Kameleoon. Il inclut toutes les méthodes et propriétés dont vous avez besoin pour exécuter une expérience.
Les développeurs sont responsables d’assurer la logique correcte du code de leur application lors de l’implémentation de l’A/B test avec Kameleoon. Une bonne pratique consiste à toujours supposer qu’un visiteur peut être exclu de l’expérience si celle-ci n’a pas encore été lancée. Cette pratique est simple à implémenter, car elle s’aligne sur la logique de la variation par défaut ou de référence, qui doit toujours être en place. Les exemples de code de la section suivante illustrent cette approche.
Si vous utilisez Ruby on Rails, nous vous recommandons d’initialiser le client Kameleoon au démarrage du serveur dans le fichier application.rb.
Vous pouvez ensuite accéder au client Kameleoon dans vos contrôleurs :

Activer un feature flag

Attribution d’un ID unique à un utilisateur
Pour attribuer un ID unique à un utilisateur, vous pouvez utiliser la méthode get_visitor_code(). Si un visitor code n’existe pas (dans le cookie des en-têtes de requête), la méthode génère un ID unique aléatoire ou utilise un default_visitor_code que vous auriez généré. L’ID est ensuite défini dans un cookie des en-têtes de réponse. Si vous utilisez Kameleoon en mode hybride, appeler la méthode get_visitor_code() garantit que l’ID unique (visitor code) est partagé entre le fichier d’application engine.js (précédemment nommé kameleoon.js) et le SDK.
Récupérer 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, utilisez la méthode get_variation() ou 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. La méthode 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 targeting. 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 la sauvegarde 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. Cela est utile si vous préférez ne pas suivre les données via le SDK et plutôt vous appuyer 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. Si vous voulez en savoir plus sur le fonctionnement du tracking, consultez cet article
Ajouter des points de données pour cibler un utilisateur ou filtrer / décomposer les visites dans les rapports
Pour cibler un utilisateur, assurez-vous d’avoir ajouté les points de données pertinents à son profil avant de récupérer la variation du feature ou de vérifier si le flag est actif. Utilisez la méthode add_data() pour ajouter ces points de données au profil de l’utilisateur. Pour récupérer les points de données collectés sur d’autres appareils ou pour accéder aux données passées de l’utilisateur (collectées côté client lors de l’utilisation de Kameleoon en mode hybride), utilisez la méthode get_remote_visitor_data(). Cette méthode récupère les données des 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 ces données peuvent être nécessaires pour attribuer un utilisateur à une variation donnée. Pour en savoir plus sur les conditions de targeting 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 décomposer vos résultats par facteurs comme 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 décomposition de vos résultats en fonction de ces points de données précollectés. Consultez 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. Custom Data vous permet de capturer et d’analyser des informations spécifiques pertinentes pour vos expériences. N’oubliez pas d’appeler la méthode flush() pour envoyer les données collectées aux serveurs Kameleoon pour analyse.
Pour vous assurer que vos résultats sont exacts, il est recommandé de filtrer les bots en utilisant le type de données UserAgent.
Suivre les conversions des objectifs
Lorsqu’un utilisateur effectue une action souhaitée (comme faire un achat), elle est enregistrée comme une conversion. Pour suivre les conversions, utilisez la méthode track_conversion() et fournissez les paramètres requis visitor_code et goal_id. La requête de tracking 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 aux solutions d’analytics
Pour suivre les conversions et envoyer des événements d’exposition à votre solution d’analytics client, vous devez d’abord implémenter Kameleoon en mode hybride. Ensuite, utilisez la méthode get_engine_tracking_code(). La méthode get_engine_tracking_code() récupère le code de tracking unique requis pour envoyer 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 à votre plateforme d’analytics choisie.

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 visite entre les appareils grâce à l’expérimentation cross-device. Des études de cas et des informations détaillées sur la manière dont Kameleoon gère les données entre les appareils sont disponibles dans l’article sur l’expérimentation cross-device.

Synchroniser les custom data entre les appareils

Bien que la synchronisation du mapping personnalisé soit utilisée pour aligner les données du visiteur entre les appareils, elle n’est pas toujours nécessaire. Voici deux scénarios où la synchronisation du mapping personnalisé n’est pas requise : Même ID utilisateur sur tous les appareils Si le même ID utilisateur est utilisé de manière cohérente sur tous les appareils, la synchronisation est gérée automatiquement sans synchronisation de mapping personnalisé. Il suffit d’appeler la méthode get_remote_visitor_data() lorsque vous voulez synchroniser les données collectées entre plusieurs appareils. Instances multi-serveurs avec des ID cohérents Dans les configurations complexes impliquant plusieurs serveurs (par exemple, des instances de serveurs distribuées), où le même ID utilisateur est disponible sur tous les serveurs, la synchronisation entre les serveurs (avec get_remote_visitor_data()) est suffisante sans synchronisation supplémentaire du 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, 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 voulez synchroniser les données collectées en temps réel, vous devez choisir le scope 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 visiteur en une seule. Pour réconcilier l’historique de visite, utilisez CustomData pour fournir un identifiant unique pour le visiteur. Pour plus d’informations, consultez la documentation dédiée. Une fois la réconciliation cross-device activée, appeler 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 de la page 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 activating cross-device history reconciliation 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 UniqueIdentifier(true) ajouté - pour récupérer les données de tous les visiteurs liés.
  • track_conversion() ou flush() avec les données UniqueIdentifier(true) ajoutées - pour suivre certaines données pour un visiteur spécifique associé à un autre visiteur.
Comme la custom data que vous utilisez comme identifiant doit être définie sur le Visitor scope, vous devez utiliser la synchronisation des custom data cross-device pour récupérer l’identifiant avec la méthode get_remote_visitor_data() sur chaque appareil.
Voici un exemple d’utilisation des custom data pour la fusion de sessions.
Dans cet exemple, l’application possède une page de connexion. Étant donné que l’ID utilisateur est inconnu au moment de la connexion, un identifiant de visiteur anonyme généré par la méthode get_visitor_code() est utilisé. Après la connexion de l’utilisateur, le visiteur anonyme est associé à l’ID utilisateur et utilisé comme identifiant unique pour le visiteur.

Utilisation d’une clé de bucketing personnalisée

Par défaut, Kameleoon utilise un ID de visiteur unique et anonyme (visitor_code) pour attribuer des 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 du 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 garantir que tous les utilisateurs d’une même organisation voient la même variante d’un feature flag. L’option Custom Bucketing Key vous permet de remplacer ce comportement par défaut en fournissant votre propre identifiant personnalisé pour le bucketing. Ce remplacement garantit que la logique d’attribution de Kameleoon utilise votre clé spécifiée au lieu du visitor_code par défaut.

Cas d’utilisation

L’utilisation d’une clé de bucketing personnalisée est essentielle pour maintenir la cohérence et la précision dans vos attributions de feature flag, en particulier dans les situations suivantes :
  • Expériences au niveau du compte ou de l’organisation : Pour les produits B2B ou les scénarios où vous voulez attribuer tous les utilisateurs d’une même organisation à la même variation, vous pouvez utiliser un identifiant comme un accountId. Les clés de bucketing personnalisées sont cruciales pour l’A/B test de fonctionnalités qui impactent une équipe ou une entreprise entière.
En implémentant une clé de bucketing personnalisée, vous garantissez une plus grande cohérence et précision dans vos expériences, conduisant à des résultats plus fiables et à une meilleure expérience utilisateur.

Détails techniques

Lorsque vous configurez une clé de bucketing personnalisée pour un feature flag, vous fournissez à Kameleoon un identifiant spécifique provenant des données de votre application :
  • Fournir la clé personnalisée : Vous fournissez votre identifiant personnalisé au SDK Kameleoon en utilisant la méthode add_data(). Dans cette méthode, vous passerez la clé de bucketing personnalisée choisie en tant qu’objet CustomData. Ici, newVisitorCode fait référence à l’identifiant que vous souhaitez utiliser pour votre bucketing (par exemple, le nouvel userId ou accountId).
Pour que la clé de bucketing personnalisée fonctionne correctement, elle doit également être définie et configurée pour le feature flag lors de la création ou de la modification du flag. Sans cette configuration correspondante, le bucketing du SDK n’appliquera pas votre clé personnalisée. Pour des instructions détaillées sur la configuration dans Kameleoon, consultez cet article.
  • Logique de bucketing : Une fois qu’une clé de bucketing personnalisée est fournie via la méthode add_data(), tous les calculs de hash pour attribuer les utilisateurs aux variations utiliseront ce newVisitorCode (votre clé personnalisée) au lieu du visitor_code par défaut. L’utilisation du newVisitorCode signifie que la décision de bucketing est liée à votre identifiant personnalisé, garantissant des attributions cohérentes dans divers contextes où cet identifiant est présent.
  • Suivi des données et analytics : Il est crucial de noter que bien que le newVisitorCode (votre clé personnalisée) soit utilisé pour les décisions de bucketing, toutes les données ultérieures (événements de tracking et conversions, par exemple) sont envoyées et associées au visitor_code d’origine. Cette séparation garantit que vos analytics reflètent avec précision les parcours et interactions individuels des utilisateurs dans le contexte plus large de votre expérience, même lorsque le bucketing est effectué à un niveau supérieur (comme un compte) ou sur plusieurs appareils/sessions. Vos données 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 String.
  • Elle doit être unique pour l’entité que vous souhaitez bucket (par exemple, si vous utilisez un userId, l’ID de chaque utilisateur doit être unique).
  • La clé doit être disponible pour le SDK au moment exact où la décision du feature flag est évaluée pour cet utilisateur ou cette requête.

Conditions de targeting

Les SDK de Kameleoon prennent en charge une variété de conditions de targeting prédéfinies que vous pouvez utiliser pour cibler des utilisateurs dans vos campagnes. Pour la liste des conditions prises en charge par ce SDK, consultez use visit history to target users. Vous pouvez également utiliser vos propres données externes pour cibler les utilisateurs.

Journalisation

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

Niveaux de log

Le SDK prend en charge la configuration de la limitation de la journalisation 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 de la journalisation 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 Ruby.

Initialisation

create()

Le point de départ pour utiliser le SDK est l’étape d’initialisation. Toutes les interactions avec le SDK se font via un objet nommé Kameleoon::KameleoonClient, vous devez donc créer cet objet.
Arguments
Exceptions levées

wait_init()

wait_init attend l’initialisation du client Kameleoon. Cette méthode vous permet de vérifier si le client a été initialisé avec succès avant de procéder à d’autres opérations. Une fois le client initialisé, wait_init renvoie immédiatement. Si la récupération initiale de la configuration échoue, le client continue de réessayer en arrière-plan, de sorte que wait_init renvoie dès qu’une récupération aboutit. L’attente est toujours bornée par un délai d’expiration, elle ne bloque donc jamais indéfiniment : si le délai s’écoule avant le chargement de la configuration, wait_init renvoie false.
Arguments
Valeur de retour

Feature flags et variations

feature_active?()

  • 📨 Envoie des données de tracking à Kameleoon (selon le paramètre track)
Précédemment appelé activate_feature - supprimé depuis la version 3.0.0 du SDK.
Cette méthode prend un visitor_code et une feature_key comme arguments obligatoires pour vérifier si le feature spécifié sera actif pour un utilisateur. Si un tel utilisateur n’a jamais été associé à ce feature flag, le SDK renvoie une valeur booléenne de manière aléatoire (true si l’utilisateur doit avoir ce feature ou false s’il ne doit pas l’avoir). 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 FeatureFlag. Vous devez vous assurer qu’une gestion appropriée des erreurs 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 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 vidées au visiteur associé à l’identifiant spécifié.
Le paramètre is_unique_identifier est obsolète. 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 visitorCode anonyme qui a été initialement attribué au visiteur, mais vous avez accès à un ID interne qui est connecté au visiteur anonyme grâce aux capacités de fusion de sessions.
La méthode feature_active?() évalue la variante servie, et non l’état maître du flag. Si vous excluez des règles, la méthode utilise l’état par défaut Then, for everyone else serve. Si vous sélectionnez Off pour cet état par défaut, la méthode renvoie toujours false, même lorsque le feature flag maître est sur On.
Arguments
Valeur de retour
Exceptions levées

get_variation()

  • 📨 Envoie des données de tracking à Kameleoon (selon le paramètre track)
Récupère la Variation attribuée à un visiteur donné pour un feature flag spécifique. Cette méthode prend un visitor_code et une feature_key comme arguments obligatoires. L’argument track est optionnel et défini par défaut sur true. Elle renvoie la Variation attribuée pour le visiteur. Si le visiteur n’est associé à aucune règle de feature flag, la méthode renvoie la Variation par défaut pour le feature flag donné. Assurez-vous qu’une gestion appropriée des erreurs est implémentée dans votre code pour gérer les exceptions potentielles.
La variation par défaut fait référence à la variation attribuée à un visiteur lorsqu’il ne correspond à aucune règle de 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…” dans une interface de gestion.
Arguments
Valeur de retour
Exceptions levées

get_variations()

  • 📨 Envoie des données de tracking à Kameleoon (selon le paramètre track)
Récupère une map d’objets Variation attribués à un visiteur donné pour tous les feature flags. Cette méthode itère sur tous les feature flags disponibles et renvoie la Variation attribuée pour chaque flag associé au visiteur spécifié. Elle prend visitor_code comme argument obligatoire, tandis que only_active et track sont optionnels.
  • Si only_active est défini sur true, la méthode get_variations() renverra les variations des feature flags à condition que l’utilisateur ne soit pas bucketé avec la variation off.
  • Le paramètre track contrôle si la méthode suit ou non les attributions de variation. Par défaut, il est défini sur true. S’il est défini sur false, le suivi sera désactivé.
La map renvoyée est composée de clés de feature flag comme clés et de leur Variation correspondante comme valeurs. Si aucune variation n’est attribuée pour un feature flag, la méthode renvoie la Variation par défaut pour ce flag. Une gestion appropriée des erreurs doit être implémentée pour gérer les exceptions potentielles.
La variation par défaut fait référence à la variation attribuée à un visiteur lorsqu’il ne correspond à aucune règle de 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…” dans une interface de gestion.
Arguments
Valeur de retour
Exceptions levées

set_forced_variation()

La méthode vous permet d’attribuer par programmation une Variation spécifique à un utilisateur, contournant le processus d’évaluation standard. Ceci 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. 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. Les processus tels que la segmentation, les conditions de targeting et les calculs algorithmiques sont ignorés. Pour préserver les conditions de segmentation et de targeting 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 est déclenché, il sera entièrement traité et complété en premier.
Une variation forcée est traitée de la même manière qu’une variation évaluée. Elle est suivie dans les analytics et stockée dans le contexte utilisateur comme toute variation évaluée standard, garantissant la cohérence des rapports. La méthode peut lever des exceptions dans certaines conditions (par exemple, paramètres invalides, contexte utilisateur ou problèmes internes). Une gestion appropriée des exceptions est essentielle pour s’assurer que votre application reste stable et résiliente.
Il est important de distinguer les variations forcées des variations simulées :
  • Variations forcées : Sont spécifiques à une expérience individuelle.
  • Variations simulées : Affectent le résultat global du feature flag.
Arguments
Exceptions levées
Dans la plupart des cas, seule l’erreur de base, KameleoonError, doit être gérée, comme démontré dans l’exemple. Cependant, si différents types d’erreurs nécessitent une réponse, gérez chacun séparément en fonction des exigences spécifiques. De plus, pour une fiabilité accrue, les erreurs générales du langage peuvent être gérées en incluant StandardError.

evaluate_audiences()

  • 📨 Envoie des données de tracking à Kameleoon
Cette méthode évalue les visiteurs par rapport à tous les segments d’Audiences Explorer disponibles et suit ceux qui correspondent. evaluate_audiences() doit être appelée après que toutes les données pertinentes du visiteur ont été définies ou mises à jour, et juste avant d’obtenir une variation de feature ou de vérifier un feature flag. Cette approche garantit que le visiteur est évalué par rapport aux données les plus récentes disponibles, permettant une attribution 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 démontré dans l’exemple. Cependant, si différents types d’erreurs nécessitent une réponse, gérez chacun séparément en fonction des exigences spécifiques. De plus, pour une fiabilité accrue, les erreurs générales du langage peuvent être gérées en incluant StandardError.

get_data_file()

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

Données visiteur

get_visitor_code()

Précédemment appelé obtain_visitor_code - supprimé depuis la version 3.0.0 du SDK.
Appelez la méthode d’assistance get_visitor_code pour obtenir le visitor_code Kameleoon pour le visiteur actuel. Cette méthode est importante lors de l’utilisation de Kameleoon dans un environnement mixte front-end et back-end, où la précision de l’identification de l’utilisateur doit être garantie. La logique d’implémentation est la suivante :
  1. Vérifier la présence d’un cookie kameleoonVisitorCode ou d’un paramètre de requête associé à la requête HTTP actuelle. S’il est trouvé, l’utiliser comme identifiant de visiteur.
  2. Si aucun cookie ou paramètre n’est trouvé, vérifier l’argument default_visitor_code. S’il est trouvé, l’utiliser comme identifiant. default_visitor_code_ permet à nos clients d’utiliser leurs propres identifiants comme visitor codes s’ils le souhaitent, ce qui peut avoir l’avantage supplémentaire de faire correspondre les visiteurs Kameleoon avec leurs propres utilisateurs sans aucune consultation supplémentaire dans une table de correspondance.
  3. Si aucun cookie, paramètre ou argument n’est trouvé, générer aléatoirement un identifiant unique.
Dans tous les cas, le cookie kameleoonVisitorCode côté serveur (via en-tête HTTP) est défini avec la valeur. Lors des visites ultérieures, l’identifiant que vous définissez est la valeur renvoyée par la méthode. Pour plus d’informations, consultez cet article.
Si vous fournissez votre propre visitor_code, vous devez en garantir l’unicité - le SDK ne peut pas la vérifier. Notez également que la longueur du visitor_code est limitée à 255 caractères. Tout caractère excédentaire entraînera une exception.
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, le processus d’évaluation standard est contourné. Au lieu de cela, la méthode renvoie directement une Variation basée sur les données fournies.Vous pouvez appliquer des simulations de deux manières :
  • Automatiquement (recommandé) : Si vous utilisez Kameleoon Web Experimentation ou le SDK en mode hybride, le cookie est créé automatiquement lors de la simulation de l’affichage d’une variante à l’aide du Simulation Panel.
  • Manuellement : Définissez manuellement le cookie kameleoonSimulationFFData.
Il est important de distinguer les variations simulées des variations forcées :
  • Variations simulées : Affectent le résultat global du feature flag.
  • Variations forcées : Sont spécifiques à une expérience individuelle.
⚙️ Configuration manuelleVeuillez vous assurer que le cookie kameleoonSimulationFFData suit ce format :
  • kameleoonSimulationFFData={"featureKey":{"expId":10,"varId":20}} : Simule la variation avec varId de l’expérience expId pour la featureKey donnée.
  • kameleoonSimulationFFData={"featureKey":{"expId":0}} : Simule la variation par défaut (définie dans la section Then, for everyone else in Production, serve) pour la featureKey donnée.
⚠️ Pour garantir un fonctionnement correct, la valeur du cookie doit être encodée comme un composant URI à l’aide d’une méthode telle que encodeURIComponent.
Arguments
Valeur de retour

add_data()

La méthode add_data() ajoute des données de targeting au stockage afin que les 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 avec les serveurs back-end Kameleoon par elle-même. Au lieu de cela, toutes les données déclarées sont enregistré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 flush(). La méthode track_conversion() envoie également toutes les données précédemment associées, tout comme flush(). Il en va de même pour les méthodes get_variation() et get_variations() si une règle d’expérimentation est déclenchée.
Chaque visiteur ne peut avoir qu’une seule instance de données associées pour la plupart des types de données. Cependant, CustomData est une exception. Les visiteurs peuvent avoir une instance de CustomData associée par index.
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 bloquante, 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 fois que add_data() est invoqué, 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 vidées au visiteur associé à l’identifiant spécifié.
Le paramètre is_unique_identifier est obsolète. 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 visitorCode anonyme qui a été initialement attribué au visiteur, mais vous avez accès à un ID interne qui est connecté au visiteur anonyme grâce aux capacités de fusion de sessions.
Arguments

get_remote_data()

Précédemment nommé : retrieve_data_from_remote_source - supprimé depuis la version 3.0.0 du SDK.
La méthode get_remote_data() vous permet de récupérer des données (selon une clé transmise en argument) pour un siteCode spécifié (spécifié dans Kameleoon::KameleoonClientFactory.create()) stockées sur un serveur distant Kameleoon. Habituellement, les données sont stockées sur nos serveurs distants à l’aide de notre API Data. Cette méthode, ainsi que la disponibilité de nos serveurs hautement évolutifs à cet effet, offre un moyen pratique de 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
Exceptions levées

get_remote_visitor_data()

get_remote_visitor_data() est une méthode asynchrone pour récupérer les données de visite Kameleoon pour le visitor_code depuis l’API Kameleoon Data. La méthode stocke les données pour que d’autres méthodes puissent les utiliser lors de la prise de décisions de targeting. Les données obtenues à l’aide de cette méthode jouent un rôle important lorsque vous souhaitez :
  • utiliser des données collectées sur d’autres appareils.
  • accéder à l’historique d’un utilisateur, telles que les pages précédemment visitées lors de visites passées.
  • utiliser des données qui ne sont accessibles que côté client, comme les variables de datalayer et les objectifs qui ne convertissent que côté front-end.
Lisez cet article pour une meilleure compréhension des cas d’utilisation possibles.
Par défaut, get_remote_visitor_data() récupère automatiquement les dernières custom data stockées avec scope=Visitor et les attache au visiteur sans avoir à appeler la méthode add_data(). C’est particulièrement utile pour synchroniser les custom data entre plusieurs appareils.
Le paramètre is_unique_identifier est obsolète. 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 visitorCode anonyme qui a été initialement attribué au visiteur, mais vous avez accès à un ID interne qui est connecté au visiteur anonyme grâce aux capacités de fusion de sessions.
Arguments
Valeur de retour
Utilisation des paramètres dans get_remote_visitor_data()
La méthode get_remote_visitor_data() offre une flexibilité en vous permettant de définir divers paramètres lors de la récupération des données du visiteur. Que vous cibliez en fonction d’objectifs, d’expériences ou de variations, la même approche s’applique à tous les types de données. Par exemple, supposons que vous souhaitiez récupérer des données sur les visiteurs qui ont complété un objectif “Order transaction”. Vous pouvez spécifier des paramètres dans la méthode get_remote_visitor_data() pour affiner votre targeting. Par exemple, si vous voulez cibler uniquement les utilisateurs qui ont converti sur l’objectif lors de leurs cinq dernières visites, vous pouvez définir le paramètre previous_visit_amount sur 5 et conversions sur true. La flexibilité illustrée dans cet exemple n’est pas limitée 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.
Voici la liste des options Kameleoon::Types::RemoteVisitorDataFilter disponibles :

get_visitor_warehouse_audience()

Récupère toutes les données d’audience associées au visiteur dans votre data warehouse en utilisant le visitor_code et le warehouse_key spécifiés. Le 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. Vous pouvez vous référer à la documentation de warehouse targeting pour plus de détails. La méthode renvoie un objet CustomData, confirmant que les données ont été ajoutées au visiteur et sont disponibles à des fins de targeting.
Arguments
Valeur de retour
Exceptions levées
Vous devez utiliser cette méthode pour spécifier si le visiteur a donné son consentement légal pour l’utilisation de données personnelles. Définir le paramètre consent 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 trouverez plus d’informations sur les données personnelles dans la politique de gestion du consentement.
Arguments
Exceptions levées
Comportement de révocation du consentement
Lorsque vous appelez set_legal_consent() avec consent=false, le SDK ne supprime pas le cookie kameleoonVisitorCode. Au lieu de cela, il cesse de prolonger la date d’expiration du cookie, permettant au cookie de persister jusqu’à son expiration naturelle. Si vos exigences de conformité exigent la suppression immédiate du fichier cookie lors de l’opt-out, vous devez le supprimer manuellement à l’aide des méthodes natives de gestion des cookies de votre framework. Le SDK ne supprimera pas le fichier automatiquement.

Objectifs et analytics tiers

track_conversion()

  • 📨 Envoie des données de tracking à Kameleoon
Utilisez cette méthode pour suivre une conversion pour un objectif et un utilisateur spécifiques. Cette méthode nécessite visitor_code et goal_id. De plus, cette méthode accepte également des arguments optionnels revenue, negative et metadata. Le visitor_code est généralement identique à celui utilisé lors du déclenchement de l’expérience. La méthode track_conversion() ne renvoie aucune valeur. Cette méthode est non bloquante car l’appel serveur est effectué de manière asynchrone.
Le paramètre isUniqueIdentifier est obsolète. Veuillez utiliser UniqueIdentifier à la place.Le isUniqueIdentifier peut également être utile dans d’autres scénarios particuliers, par exemple lorsque vous ne pouvez pas accéder au visitor_code anonyme qui a été initialement attribué au visiteur, mais vous avez accès à un ID interne qui est connecté au visiteur anonyme grâce aux capacités de fusion de sessions.
Arguments
Les valeurs de 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 suivies pour ces CustomData avant la conversion et au cours de la même visite.Kameleoon ne prendra en compte que les valeurs de métadonnées qui sont explicitement transmises en paramètres à la méthode track_conversion().Dans l’exemple ci-dessous, Kameleoon n’associera la conversion qu’à la valeur de custom data explicitement fournie en paramètre (ici : index 5 avec la valeur ‘Amex Credit Card’).
Exceptions

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éthode get_engine_tracking_code() après que le visiteur a déclenché une expérience. Le SDK renvoie des commandes de file d’attente JavaScript pour les expériences que le visiteur a déclenchées au cours des cinq dernières secondes. Lorsque vous insérez ce code dans la page, Engine.js traite les commandes et envoie les événements d’exposition via l’intégration d’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 Ruby et Kameleoon Engine.js. Comme Engine.js n’est utilisé que pour le tracking dans ce flow, vous pouvez installer le tag asynchrone avant la balise de fermeture </body>.
  • Si vous voulez uniquement suivre les expériences dans Kameleoon et n’avez pas besoin d’envoyer des événements d’exposition à des 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 renvoyé directement dans une balise HTML <script>.
Dans cet exemple, 123456 et 234567 sont les IDs d’expérience, et 7890 et 8901 sont les IDs de variation. Dans votre implémentation, le SDK génère ces valeurs dans le code de tracking renvoyé.
Arguments
Valeur de retour

Événements

on_update_configuration()

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

Types de données

Browser

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

PageView

L’index (ID) du référent est disponible dans la page de configuration des canaux d’acquisition de notre Back-Office. Attention : cet index commence à 0, donc le premier canal d’acquisition que vous créez pour un site aura l’ID 0, et non 1.

Conversion

L’ensemble de données Conversion stocké ici peut être utilisé pour filtrer les rapports d’expérience et de personnalisation par tout objectif qui lui est associé.
  • Chaque visiteur peut avoir plusieurs objets Conversion.
  • Vous pouvez trouver le goal_id dans l’application Kameleoon.

CustomData

CustomData permet d’associer facilement n’importe quel type de données à un visiteur. Vous pouvez ensuite l’utiliser comme condition de targeting 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 CustomData pour chaque index unique. Ajouter une autre CustomData avec le même index remplacera la CustomData existante.
  • L’index de 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 custom data.
  • Ajouter une instance de CustomData créée avec un nom alors que la configuration de l’instance du SDK n’est pas à jour ou que le nom n’est pas enregistré, entraînera l’ignorance des données.

Device

UserAgent

Stocke les informations sur l’user-agent du visiteur. Les expériences côté serveur sont plus vulnérables au trafic bot que les expériences côté client. Pour remédier à cette vulnérabilité, Kameleoon utilise la liste IAB/ABC International Spiders and Bots pour identifier les bots et spiders connus. Kameleoon utilise également le champ UserAgent 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 transmettre la valeur curl/8.0 de l’userAgent pour les exclure de nos analytics.

UniqueIdentifier

Si vous n’ajoutez pas UniqueIdentifier pour un visiteur, 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 vidées au visiteur associé à l’identifiant spécifié. Le UniqueIdentifier peut également être utile dans d’autres scénarios particuliers, par exemple lorsque vous ne pouvez pas accéder au visitorCode anonyme qui a été initialement attribué au visiteur, mais vous avez accès à un ID interne qui est connecté au visiteur anonyme grâce aux capacités de fusion de sessions.

OperatingSystem

OperatingSystem contient des informations sur le système d’exploitation du visiteur.
Chaque visiteur ne peut avoir qu’un seul OperatingSystem. Ajouter un deuxième OperatingSystem remplace le premier.
Cookie contient des informations sur le cookie stocké sur l’appareil du visiteur.
Chaque visiteur ne peut avoir qu’un seul Cookie. Ajouter un deuxième Cookie remplace le premier.

Geolocation

Geolocation contient les détails de géolocalisation du visiteur.
  • Chaque visiteur ne peut avoir qu’une seule Geolocation. Ajouter une deuxième Geolocation remplace la première.

ApplicationVersion

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

Types renvoyés

DataFile

Le DataFile contient les détails de configuration du SDK. Il peut être étendu avec des informations supplémentaires si les clients le demandent. Si vous avez besoin de plus de détails, veuillez contacter votre Customer Success Manager.

FeatureFlag

Le FeatureFlag représente un ensemble de propriétés qui définissent un feature flag lui-même — par exemple, ses Variations, Rules, statut d’environnement et autres détails associés. 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.

Rule

La Rule représente un ensemble de propriétés qui définissent une règle elle-même — par exemple, ses Variations. Elle peut être étendue avec des informations supplémentaires si les clients le 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, si aucune attribution spécifique n’existe).
  • L’objet Variation fournit des détails sur la variation attribuée et son expérience associée, tandis que l’objet Variable contient des détails spécifiques sur chaque variable au sein d’une variation.
  • Assurez-vous que votre code gère le cas où id ou experiment_id peut être nil, indiquant une variation par défaut.
  • Le hash variables peut être vide si aucune variable n’est associée à la variation.

Variable

Variable contient des informations sur une variable associée à la variation attribuée.

Méthodes obsolètes

Ces méthodes sont obsolètes et seront supprimées dans la version 4.0.0 du SDK.

get_feature_variation_key()

  • 📨 Envoie des données de tracking à Kameleoon
Utilisez get_variation() à la place.
Pour obtenir une clé de variation de feature, appelez la méthode get_feature_variation_key. Cette méthode prend un visitor_code et une feature_key comme arguments obligatoires pour obtenir la clé de variation d’un utilisateur. Si un tel utilisateur n’a jamais été associé à ce feature flag, le SDK renvoie une clé de variation 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 la clé de variation. Si l’utilisateur ne correspond à aucune des règles, la valeur par défaut sera renvoyée, que nous pouvons définir dans le compte de votre client. Vous devez vous assurer qu’une gestion appropriée des erreurs 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 vidées au visiteur associé à l’identifiant spécifié.
Le paramètre is_unique_identifier est obsolète. 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 visitorCode anonyme qui a été initialement attribué au visiteur, mais vous avez accès à un ID interne qui est connecté au visiteur anonyme grâce aux capacités de fusion de sessions.
Arguments
Valeur de retour
Exceptions levées

get_active_feature_list_for_visitor()

Utilisez get_active_features() à la place.
Cette méthode ne prend que visitorCode comme paramètre d’entrée. Le résultat ne contient que les feature flags actifs pour un visiteur donné.
Arguments
Valeur de retour
Exceptions levées

get_active_features()

La méthode get_active_features récupère les informations sur les feature flags actifs disponibles pour le visitor code spécifié.
Cette méthode est obsolète et sera supprimée dans la version 4.0.0 du SDK. Utilisez get_variations() à la place.
Arguments
Valeur de retour
Exceptions levées

get_feature_variable()

  • 📨 Envoie des données de tracking à Kameleoon
Utilisez get_variation() à la place.
Précédemment appelé obtain_feature_variable - obsolète depuis la version 2.1.0 du SDK et sera supprimé dans une prochaine version.
Pour obtenir une variable de la clé de variation associée à un utilisateur, appelez la méthode get_feature_variable. Cette méthode prend un visitor_code, une feature_key et un variable_name comme arguments obligatoires pour obtenir une variable de la clé de variation pour un utilisateur donné. Si un tel utilisateur n’a jamais été associé à ce feature flag, le SDK renvoie une valeur de variable de la clé de variation 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 variable pour la variation précédemment associée. Si l’utilisateur ne correspond à aucune des règles, la variable par défaut sera renvoyée. Vous devez vous assurer qu’une gestion appropriée des erreurs 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 vidées au visiteur associé à l’identifiant spécifié.
Le paramètre is_unique_identifier est obsolète. 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 visitorCode anonyme qui a été initialement attribué au visiteur, mais vous avez accès à un ID interne qui est connecté au visiteur anonyme grâce aux capacités de fusion de sessions.
Arguments
Valeur de retour
Exceptions levées

get_feature_variation_variables()

Utilisez get_variation() à la place.
Pour récupérer toutes les variables de feature, appelez la méthode get_feature_variation_variables. Une variable de feature peut être modifiée à l’aide de notre application web. Cette méthode prend feature_key et variation_key comme arguments obligatoires. Elle renverra les données avec le type d’objet, tel que défini dans l’interface web. Elle lève une erreur (FeatureNotFound) si le feature flag demandé n’a pas été trouvé dans la configuration du client SDK. Si la clé de variation n’est pas trouvée, la méthode lève une erreur (FeatureVariationNotFound).
Arguments
Valeur de retour
Exceptions levées

get_feature_list()

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