Guide du développeur
Ce guide est conçu pour vous aider à intégrer rapidement le SDK Elixir et à commencer à évaluer des feature flags dans votre application Elixir.Pour commencer
Installer le client Elixir
Ajoutez le SDK comme dépendance dans votre fichiermix.exs :
mix.exs
Configuration supplémentaire
Créez un fichier de configurationclient-elixir.conf pour fournir les identifiants et personnaliser le comportement du SDK.
Nous recommandons d’enregistrer ce fichier au chemin par défaut, /etc/kameleoon/client-elixir.conf. Kameleoon.ClientFactory.create utilise automatiquement ce chemin lorsque vous ne transmettez pas d’options de configuration. Si vous stockez le fichier ailleurs, indiquez le chemin avec l’option config_path: lors de la création du client.
Le SDK Elixir peut être configuré soit avec un fichier de configuration utilisé par Kameleoon.ClientFactory.create, soit en passant une structure %Kameleoon.ClientConfig\{\} avec l’option config:.
Le tableau suivant présente les propriétés disponibles que vous pouvez définir :
Initialiser le client Kameleoon
Une fois que vous avez installé le SDK et configuré vos identifiants, créez un%Kameleoon.Client\{\} en utilisant Kameleoon.ClientFactory.
- Fichier de configuration
- Code
%Kameleoon.Client\{\} est l’objet principal utilisé pour évaluer les feature flags, ajouter des données de visiteur et envoyer des requêtes de tracking.
Activation d’un feature flag
Attribution d’un identifiant unique à un utilisateur
Pour attribuer un identifiant unique à un utilisateur, vous pouvez utiliser la méthodeClient.get_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 identifiant unique aléatoire ou utilise un default_visitor_code que vous auriez généré. L’identifiant est ensuite défini dans un cookie des en-têtes de réponse.
Si vous utilisez Kameleoon en mode hybride, l’appel à la méthode Client.get_visitor_code garantit que l’identifiant 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éthodeClient.get_variation ou Client.is_feature_active? afin de récupérer la configuration en fonction de la feature_key.
La méthode Client.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 Client.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 à des feature flags plus complexes avec plusieurs variations ou options de ciblage.
Si votre feature flag est associé à des variables (telles que des comportements spécifiques liés à chaque variation), Client.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 paramètre tracking_interval_millis du SDK. Par défaut, cet intervalle est défini à 1000 millisecondes (1 seconde).
La méthode Client.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 lors de l’utilisation de la méthode Client.get_variations, où vous pourriez n’avoir besoin que des variations de 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 points de données pour cibler un utilisateur ou filtrer / découper 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éthodeClient.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 Client.get_remote_visitor_data. Cette méthode récupère les données depuis les serveurs de manière asynchrone. Il est important d’appeler Client.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é à ce 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écouper vos résultats par facteurs tels que l’appareil et le navigateur. Le mode hybride de Kameleoon collecte automatiquement une variété de points de données côté client, ce qui facilite la 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 ceux collectés automatiquement, vous pouvez utiliser la fonctionnalité Custom Data de Kameleoon. Les Custom Data vous permettent de capturer et d’analyser des informations spécifiques pertinentes pour vos expériences. N’oubliez pas d’appeler la méthode Client.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 à l’aide du 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éthodeClient.track_conversion et fournissez les paramètres visitor_code et goal_id requis.
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_millis). Si vous préférez envoyer la requête immédiatement, utilisez la méthode Client.flush_instant.
Envoi d’événements aux solutions d’analyse
Pour suivre les conversions et envoyer des événements d’exposition à votre solution d’analyse client, vous devez d’abord implémenter Kameleoon en mode hybride. Ensuite, utilisez la méthodeClient.get_engine_tracking_code.
La méthode Client.get_engine_tracking_code récupère le code de tracking unique requis pour envoyer des événements d’exposition à votre solution d’analyse. L’utilisation de cette méthode vous permet d’enregistrer les événements et de les envoyer à la plateforme d’analyse de votre choix.
Utilisation d’une clé de bucketing personnalisée
Par défaut, Kameleoon utilise un identifiant de visiteur anonyme unique (visitor_code) pour attribuer les utilisateurs aux variations des feature flags. Cet identifiant est généralement généré et stocké sur l’appareil de l’utilisateur (dans un cookie de navigateur pour les SDK côté client et côté serveur — dans un stockage persistant pour les SDK mobiles). Cependant, dans certains scénarios, vous pouvez avoir besoin de garantir que tous les utilisateurs d’une même organisation voient la même variante d’un feature flag.
L’option Clé de bucketing personnalisée vous permet de remplacer ce comportement par défaut en fournissant votre propre identifiant personnalisé pour le bucketing. Ce remplacement garantit que la logique d’attribution de Kameleoon utilise la clé que vous avez 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 flags, 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 souhaitez attribuer tous les utilisateurs d’une même organisation à la même variation, vous pouvez utiliser un identifiant tel qu’un
account_id. Les clés de bucketing personnalisées sont cruciales pour les tests A/B de fonctionnalités qui impactent toute une équipe ou une entreprise.
Détails techniques
Lorsque vous configurez une clé de bucketing personnalisée pour un feature flag, vous fournissez à Kameleoon un identifiant spécifique 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
Client.add_data. Dans cette méthode, vous passerez votre clé de bucketing personnalisée choisie sous la forme d’un objetCustomData. Ici,new_visitor_codefait référence à l’identifiant que vous souhaitez utiliser pour votre bucketing (par exemple, le nouveauuser_idouaccount_id).
- Logique de bucketing : Une fois qu’une clé de bucketing personnalisée est fournie via la méthode
Client.add_data, tous les calculs de hachage 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 analyse : 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_coded’origine. Cette séparation garantit que vos analyses 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 originales de visiteur restent intactes pour un reporting complet.
Exigences techniques
Pour utiliser efficacement une clé de bucketing personnalisée :- La clé doit être un
String.t(). - Elle doit être unique pour l’entité que vous souhaitez bucketer (par exemple, si vous utilisez un
user_id, l’identifiant 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 visite pour cibler les utilisateurs. Vous pouvez également utiliser vos propres données externes pour cibler les utilisateurs.Expérimentation cross-device
Pour prendre en charge les visiteurs qui accèdent à une application depuis plusieurs appareils, Kameleoon permet la synchronisation des données de visiteur précédemment collectées sur chacun des appareils du visiteur, ainsi que la réconciliation de leur historique de visite sur tous les appareils grâce à l’expérimentation cross-device. Des études de cas et des informations détaillées sur la façon dont Kameleoon gère les données entre les appareils sont disponibles dans l’article sur l’expérimentation cross-device.Synchronisation des données personnalisées entre les appareils
Bien que la synchronisation par mappage personnalisé soit utilisée pour aligner les données de visiteur entre les appareils, elle n’est pas toujours nécessaire. Voici deux scénarios où la synchronisation par mappage 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 par mappage personnalisé. Il suffit d’appeler la méthodeClient.get_remote_visitor_data lorsque vous souhaitez synchroniser les données collectées entre plusieurs appareils.
Instances multi-serveurs avec identifiants cohérents
Dans des configurations complexes impliquant plusieurs serveurs (par exemple, des instances de serveurs distribués), où le même ID utilisateur est disponible sur tous les serveurs, la synchronisation entre les serveurs (avec Client.get_remote_visitor_data) est suffisante sans synchronisation par mappage personnalisé supplémentaire.
Les clients qui ont besoin de données supplémentaires peuvent se référer à la description de la méthode Client.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, également 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 le scope Visitor pour vos données personnalisées.
Appareil A
Appareil B
Utilisation de données personnalisées 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 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 à Client.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 Visiteur des pages de résultats de votre expérience, ces sessions apparaîtront comme un visiteur unique.
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’attribution de variations cross-device. Ces limitations sont décrites ici.
Suivez le guide activation de la réconciliation d’historique cross-device pour configurer vos données personnalisées 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 :
Client.get_remote_visitor_dataavecUniqueIdentifier(true)ajouté - pour récupérer les données de tous les visiteurs liés.Client.track_conversionouClient.flushavec la donnéeUniqueIdentifier(true)ajoutée - pour suivre certaines données pour un visiteur spécifique qui est associé à un autre visiteur.
Client.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.
Journalisation
Le SDK génère des logs pour refléter les différents processus et problèmes internes.Niveaux de log
Le SDK prend en charge la limitation de la journalisation par 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 niveau de log est effectuée indépendamment de la logique de gestion des logs.
Référence
Voici la documentation complète de référence pour le SDK Elixir.Initialisation
create()
Pour utiliser le SDK, créez un%Kameleoon.Client\{\} avec Kameleoon.ClientFactory.create. Par défaut, create lit /etc/kameleoon/client-elixir.conf. Vous pouvez également fournir soit une structure %Kameleoon.ClientConfig\{\} via config:, soit un chemin de fichier de configuration personnalisé via config_path:.
- config:
- config_path:
Arguments
Valeur retournée
Erreurs
initialize()
Attend que le client Kameleoon soit initialisé, en utilisant soit la valeur configuréedefault_timeout_millis, soit un timeout fourni. Cette méthode garantit que le client est entièrement initialisé avant d’effectuer toute autre opération.
Arguments
Valeur retournée
Erreurs
is_ready()
Vérifie si le client a été initialisé.Valeur retournée
forget()
Supprime le client SDK mis en cache associé ausite_code spécifié.
Arguments
Valeur retournée
Feature flags et variations
is_feature_active()
- 📨 Envoie des données de tracking à Kameleoon (selon l’option
track)
Kameleoon utilise le tracking pour compter les sessions et les visiteurs lorsque vous appelez certaines méthodes, telles que
Client.is_feature_active?, Client.get_variation ou Client.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 Client.get_variations pour récupérer toutes les variations avant d’exposer les visiteurs, définissez le paramètre track sur false. Ce paramètre empêche Kameleoon de comptabiliser prématurément une session. Vous pouvez ensuite déclencher le tracking ultérieurement lorsque vous exposez explicitement le visiteur.Kameleoon envoie les données de tracking chaque seconde par défaut. Vous pouvez configurer cet intervalle jusqu’à cinq secondes à l’aide de 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 comptabilise 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 retournée
Erreurs
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 vaut true par défaut.
Elle renvoie la Variation attribuée au visiteur. Si le visiteur n’est associé à aucune règle de feature flag, la méthode renvoie la Variation par défaut pour le feature flag donné.
Assurez-vous qu’une gestion appropriée des erreurs est implémentée dans votre code pour gérer les exceptions potentielles.
La variation par défaut désigne 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, il s’agit de la variation de repli appliquée à tous les utilisateurs qui ne sont pas ciblés par des règles spécifiques. Elle est représentée comme la variation dans la section « Then, for everyone else… » d’une interface de gestion.
Arguments
Valeur retournée
Erreurs
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 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_activeest défini surtrue, la méthodeClient.get_variationsrenverra 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 variations. Par défaut, il est défini surtrue. S’il est défini surfalse, le tracking sera désactivé.
Variation correspondantes en tant que 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 désigne 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, il s’agit de la variation de repli appliquée à tous les utilisateurs qui ne sont pas ciblés par des règles spécifiques. Elle est représentée comme la variation dans la section « Then, for everyone else… » d’une interface de gestion.
Arguments
Valeur retournée
Erreurs
set_forced_variation()
La méthode vous permet d’attribuer par programmation uneVariation spécifique à un utilisateur, en contournant le processus d’évaluation standard. Cela est particulièrement précieux 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 tels que le débogage ou les tests personnalisés.
Lorsqu’une variation forcée est définie, elle remplace la logique d’évaluation en temps réel de Kameleoon. Les 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 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 terminé en premier.
Arguments
Valeur retournée
Erreurs
evaluate_audiences()
- 📨 Envoie des données de tracking à Kameleoon
Client.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
Valeur retournée
Erreurs
get_datafile()
Renvoie la configuration actuelle du SDK sous forme d’objetDataFile.
Valeur retournée
Erreurs
Données du visiteur
get_visitor_code()
Utilisezget_visitor_code() pour obtenir le visitor_code Kameleoon du visiteur actuel. La méthode fonctionne avec n’importe quel store de cookies qui implémente le behaviour Kameleoon.CookieAccessor.
La logique d’implémentation est la suivante :
- Le SDK vérifie si un cookie
kameleoonVisitorCodeest déjà disponible via l’accessor fourni. - Si le cookie est absent, le SDK utilise
default_visitor_codelorsque vous en fournissez un. - Sinon, le SDK génère un nouveau visitor code et le stocke via l’accessor.
La méthode
Client.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 les 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 via le Simulation Panel.
- Manuellement : Définissez manuellement le cookie
kameleoonSimulationFFData.
- 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.- Map
- Plug.Conn
Arguments
Le module accessor doit implémenter
get et set. get lit une valeur de cookie depuis l’état de l’accessor, et set renvoie l’état mis à jour après avoir reçu key, value, max_age et top_level_domain.
Valeur retournée
add_data()
La méthodeClient.add_data ajoute des données de ciblage au stockage afin que d’autres méthodes puissent les utiliser pour décider s’il faut cibler ou non le visiteur actuel.
La méthode Client.add_data ne renvoie aucune valeur et n’interagit pas avec les serveurs back-end de Kameleoon par elle-même. Au lieu de cela, toutes les données déclarées sont enregistrées pour une transmission ultérieure via la méthode Client.flush. Cette approche réduit le nombre d’appels au serveur, car les données sont généralement regroupées en un seul appel au serveur déclenché par Client.flush.
La méthode Client.track_conversion envoie également toutes les données précédemment associées, tout comme Client.flush. Il en va de même pour les méthodes Client.get_variation et Client.get_variations si une règle d’expérimentation est déclenchée.
Arguments
Valeur retournée
Erreurs
flush()
- 📨 Envoie des données de tracking à Kameleoon
flush() agrège toutes les données Kameleoon associées à un visiteur et envoie une requête de tracking au serveur. Cette requête inclut toutes les données précédemment ajoutées via la méthode add_data qui n’ont pas encore été transmises par d’autres mécanismes de tracking (voir les méthodes référencées pour plus de détails). L’opération flush() est non bloquante, car l’appel au serveur est effectué de manière asynchrone.
Cette méthode offre un contrôle sur le moment où les données liées à un visitor_code spécifique sont transmises. Par exemple, si add_data() est appelée plusieurs fois, l’envoi d’une requête après chaque invocation serait inefficace. Au lieu de cela, vous pouvez regrouper ces mises à jour et appeler flush() une seule fois pour envoyer toutes les données accumulées en une seule requête.
La méthode flush() utilise le visitor_code fourni comme identifiant unique du visiteur.
Arguments
Valeur retournée
Erreurs
get_remote_data()
La méthodeget_remote_data() vous permet de récupérer des données distantes stockées sur les serveurs Kameleoon pour la key spécifiée. Dans la plupart des configurations, ces données sont écrites via l’API Data de Kameleoon et peuvent ensuite être récupérées par votre service Elixir chaque fois que vous avez besoin d’un contexte applicatif supplémentaire.
Cette méthode est utile lorsque vous souhaitez conserver des informations structurées sur l’infrastructure distante de Kameleoon et les réutiliser depuis votre back-end sans maintenir un mécanisme de récupération séparé.
Arguments
Valeur retournée
Erreurs
get_remote_visitor_data()
get_remote_visitor_data() récupère les données de visite Kameleoon pour le visitor_code fourni. La méthode ajoute les données au stockage local du visiteur afin que d’autres méthodes du SDK puissent les utiliser pour les décisions de ciblage.
Les données obtenues via cette méthode sont particulièrement utiles lorsque vous souhaitez :
- utiliser des données collectées depuis d’autres appareils.
- accéder à l’historique d’un visiteur, comme les pages précédemment consultées lors de visites passées.
- utiliser des données qui ne sont disponibles que côté client, telles que les variables de datalayer et les conversions d’objectifs front-end.
Arguments
Valeur retournée
Erreurs
Utilisation des paramètres dans get_remote_visitor_data()
La méthodeget_remote_visitor_data() vous permet de contrôler quelles données sont récupérées pour un visiteur. La même approche de filtrage fonctionne pour les objectifs, les expériences, les variations et autres données du visiteur.
Par exemple, si vous souhaitez cibler les utilisateurs qui ont converti sur un objectif lors de leurs cinq dernières visites, vous pouvez définir previous_visit_amount sur 5 et conversions sur true.
La flexibilité illustrée dans cet exemple ne se limite pas aux données d’objectifs. Vous pouvez utiliser le filtre pour récupérer de nombreux comportements de visiteurs différents et les rendre disponibles pour la logique de ciblage et de reporting dans votre application Elixir.
Champs de RemoteVisitorDataFilter
get_visitor_warehouse_audience()
Cette méthode récupère les données d’audience associées à un visiteur dans votre intégration warehouse en utilisant levisitor_code spécifié et, éventuellement, une warehouse_key. La warehouse_key est généralement votre ID utilisateur interne. Le paramètre custom_data_index correspond à la donnée personnalisée Kameleoon que Kameleoon utilise pour cibler vos visiteurs.
Lorsque l’appel réussit, le SDK convertit la liste d’audiences renvoyée en CustomData, l’ajoute au visiteur localement et la rend disponible à des fins de ciblage. Pour plus de contexte, consultez la documentation sur le ciblage warehouse.
Arguments
Valeur retournée
Erreurs
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éfinirlegal_consent sur false limite les types de données pouvant être inclus dans les requêtes de tracking. Cela vous aide à respecter les exigences légales et réglementaires tout en gérant les données des visiteurs de manière responsable. Pour plus d’informations, consultez la politique de gestion du consentement.
Le SDK Elixir met à jour les cookies du visiteur via l’adaptateur Kameleoon.CookieAccessor requis et renvoie l’état mis à jour de l’adaptateur.
Arguments
Valeur retournée
Erreurs
Comportement de révocation du consentement
Lorsque vous appelezClient.set_legal_consent avec legal_consent=false, le SDK ne supprime pas le cookie kameleoonVisitorCode. Au lieu de cela, il cesse de prolonger la date d’expiration du cookie, permettant au cookie de persister jusqu’à son expiration naturelle.
Si vos exigences de conformité imposent la suppression immédiate du fichier cookie lors du retrait du consentement, vous devez le supprimer manuellement en utilisant les méthodes natives de gestion des cookies de votre framework. Le SDK ne supprimera pas le fichier automatiquement.
Objectifs et analyses tierces
track_conversion()
- 📨 Envoie des données de tracking à Kameleoon
visitor_code et goal_id. De plus, cette méthode accepte également des arguments optionnels revenue, negative et metadata. Le visitor_code est généralement identique à celui utilisé lors du déclenchement de l’expérience.
Arguments
Les valeurs des métadonnées 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 en cours au lieu de ce qui a été précédemment collecté en utilisant la méthode Client.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 explicitement passées en tant que paramètres à la méthode Client.track_conversion.Dans l’exemple ci-dessous, Kameleoon associera la conversion uniquement à la valeur de donnée personnalisée explicitement fournie en paramètre (ici : index 5 avec la valeur ‘Amex Credit Card’).Valeur retournée
Erreurs
get_engine_tracking_code()
Kameleoon s’intègre à plusieurs solutions d’analyse, notamment Mixpanel, Google Analytics 4 et Segment. Pour suivre correctement les expériences côté serveur, appelez la méthodeClient.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’analyse active.
Consultez l’expérimentation hybride pour plus d’informations sur l’implémentation de cette méthode.
- Pour utiliser cette fonctionnalité, implémentez à la fois le SDK Elixir 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 des événements d’exposition à des outils d’analyse tiers, utilisez le SDK JavaScript / TypeScript. Cette option fonctionne bien pour les plateformes de calcul serverless en périphérie. Le SDK JavaScript / TypeScript suit automatiquement les variations lorsque vous appelez
getVisitorCode, à condition que vous ajoutiez les attributions d’expérience correspondantes àwindow.kameleoonQueue. - Vous pouvez insérer le code de tracking renvoyé directement dans une balise HTML
<script>.
123456 et 234567 sont des IDs d’expérience, et 7890 et 8901 sont des IDs de variation. Dans votre implémentation, le SDK génère ces valeurs dans le code de tracking renvoyé.Arguments
Valeur retournée
Erreurs
Événements
on_datafile_update()
La méthodeClient.on_datafile_update vous permet de gérer l’événement déclenché 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
Cette section répertorie les types de données Elixir disponibles sousKameleoon.Data.
ApplicationVersion
ApplicationVersion représente le numéro de version sémantique de votre application.
Browser
L’ensemble de donnéesBrowser stocké ici peut être utilisé pour filtrer les rapports d’expérience et de personnalisation par toute valeur qui lui est associée.
Conversion
L’ensemble de donnéesConversion stocké ici peut être utilisé pour filtrer les rapports d’expérience et de personnalisation par tout objectif qui lui est associé.
Cookie
Cookie contient des informations sur les cookies stockés sur l’appareil du visiteur.
CustomData
CustomData permet l’association de tout type de données à chaque visiteur, ce qui en fait un outil efficace pour les conditions de ciblage dans les segments. De plus, il peut être utilisé comme filtre ou découpage dans les rapports d’expérience. Pour plus d’informations sur les custom data, veuillez consulter cet article.
Définissez les types de données personnalisées dans l’application Kameleoon ou via l’API Data, puis utilisez-les depuis le SDK.
-
Chaque visiteur n’est autorisé à avoir qu’une seule
CustomDatapour chaqueindex(name) unique. L’ajout d’une autreCustomDataavec le mêmeindex(name) remplacera l’existante. - L’« index » de la donnée personnalisée se trouve dans le tableau de bord 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 donnée personnalisée.
-
L’ajout d’une instance de
CustomDatacréée avec un nom alors que l’instance du SDK n’est pas initialisée ou que le nom n’est pas enregistré entraînera l’ignorance de la donnée.
Device
Vous pouvez utiliser les données d’appareil pour filtrer les rapports d’expérience et de personnalisation par toute valeur associée.Geolocation
Geolocation contient les détails de géolocalisation du visiteur.
OperatingSystem
OperatingSystem contient des informations sur le système d’exploitation de l’appareil du visiteur.
PageView
Stocker les événements de page vue.L’index de référent est disponible dans l’application Kameleoon sur la page de configuration des canaux d’acquisition. Attention : l’index commence à
0, donc le premier canal d’acquisition que vous créez a l’ID 0, et non 1.UniqueIdentifier
Si vous n’ajoutez pasUniqueIdentifier pour un visiteur, visitor_code est utilisé comme identifiant unique du visiteur, ce qui est utile pour l’expérimentation cross-device. Lorsque vous ajoutez UniqueIdentifier(true), le SDK lie les données envoyées (flush) au visiteur associé à l’identifiant spécifié.
Cela peut être utile dans des situations où vous ne pouvez pas accéder au visitor_code anonyme attribué à l’origine à un visiteur, mais où vous avez accès à un identifiant interne lié à ce visiteur via la fusion de sessions.
UserAgent
Les expériences côté serveur sont plus susceptibles d’être affectées par le trafic des bots que les expériences côté client. Kameleoon utilise la liste IAB/ABC International Spiders and Bots pour reconnaître les bots et spiders connus, et utilise également le champUserAgent pour filtrer d’autres trafics indésirables qui pourraient fausser vos métriques de conversion. Pour plus d’informations, consultez l’article d’aide sur le filtrage des bots.
Si vous utilisez des bots internes, nous vous recommandons d’envoyer la valeur user-agent curl/8.0 pour les exclure des analyses.
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 en ont besoin. 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, son statut d’environnement et d’autres détails associés.
Il peut être étendu avec des informations supplémentaires si les clients en ont besoin. Si vous avez besoin de plus de détails, veuillez contacter votre Customer Success Manager.
Rule
LaRule représente un ensemble de propriétés qui définissent une règle elle-même — par exemple, ses Variations.
Elle peut être étendue avec des informations supplémentaires si les clients en ont besoin. Si vous avez besoin de plus de détails, veuillez contacter votre Customer Success Manager.
Variation
Variation contient des informations sur la variation attribuée au visiteur, ou la variation par défaut lorsqu’aucune attribution spécifique n’existe.
Variationdécrit la variation attribuée ou par défaut, tandis queVariablecontient les détails de chaque variable individuelle.idetexperiment_idpeuvent êtrenil, ce qui indique une variation par défaut qui n’est pas liée à une attribution d’expérience spécifique.
Variable
Variable contient des informations sur une variable associée à la variation attribuée.