Avec le SDK Rust de Kameleoon, vous pouvez exécuter des expériences et activer des feature flags dans vos services Rust et vos back-ends web.
Pour commencer : pour vous aider à démarrer, consultez le guide du développeur.
Changelog : dernière version du SDK Rust : 0.9.3 Changelog.
Méthodes du SDK : pour la documentation de référence complète du SDK Rust, consultez la section référence.
Guide du développeur
Ce guide est conçu pour vous aider à intégrer rapidement le SDK Rust et à commencer à évaluer des feature flags dans votre application Rust.
Pour commencer
Installer le client Rust
Si vous travaillez dans l’espace de travail actuel, ajoutez le SDK en tant que dépendance de chemin avec tokio, car plusieurs méthodes du SDK sont asynchrones :
[dependencies]
kameleoon-client = "0.9.3"
Configuration supplémentaire
Créez un fichier de configuration client-rust.json pour fournir les identifiants et personnaliser le comportement du SDK. Vous pouvez également télécharger notre fichier de configuration d’exemple.
Nous vous recommandons d’enregistrer ce fichier dans le chemin par défaut, /etc/kameleoon/client-rust.json, mais vous pouvez l’enregistrer n’importe où dans le classpath sous le nom client-rust.json.
Le SDK Rust peut être configuré soit avec un fichier JSON utilisé par create_with_path(), soit en construisant une instance KameleoonClientConfig avec create_with_config() directement dans le code.
Le tableau suivant présente les propriétés disponibles que vous pouvez définir :
| Clé (Code / Fichier de configuration) | Description | Valeur par défaut |
|---|
client_id / clientId (requis) | Requis pour l’authentification auprès du service Kameleoon. Pour trouver votre client_id, consultez la documentation identifiants d’API. | |
client_secret / clientSecret (requis) | Requis pour l’authentification auprès du service Kameleoon. Pour trouver votre client_secret, consultez la documentation identifiants d’API. | |
session_duration / sessionDurationMinutes (optionnel) | Intervalle de temps, en minutes, pendant lequel le SDK conserve un visiteur et ses données associées en mémoire. | 30 minutes |
refresh_interval / refreshIntervalMinutes (optionnel) | Intervalle, en minutes, utilisé pour rafraîchir la configuration des expériences actives et des feature flags. | 60 minutes |
default_timeout / defaultTimeoutMillis (optionnel) | Délai d’attente par défaut, en millisecondes, pour les requêtes réseau du SDK. | 10000 millisecondes |
tracking_interval / trackingIntervalMillis (optionnel) | Intervalle, en millisecondes, utilisé pour regrouper les requêtes de tracking. Les valeurs sont restreintes à l’intervalle [1000, 5000]. | 1000 millisecondes |
environment / environment (optionnel) | Environnement à partir duquel la configuration des feature flags doit être utilisée. La valeur peut être production, staging ou development. | production |
top_level_domain / topLevelDomain (optionnel) | Le domaine de premier niveau actuel pour votre site web. Utilisez le format example.com sans protocole ni sous-domaines. | None |
proxy_host / proxyHost (optionnel) | Hôte proxy pour les appels SDK sortants. Formats pris en charge : https://my.prox, https://my.prox:4545, socks5://192.168.1.1:9000. | None |
network_domain / networkDomain (optionnel) | Domaine personnalisé utilisé par les SDK pour les requêtes sortantes, souvent pour le proxying. Doit être un domaine valide (par exemple, example.com ou sub.example.com). Les formats invalides utilisent la valeur de Kameleoon par défaut. | None |
Initialiser le client Kameleoon
Après avoir installé le SDK et configuré vos identifiants, créez un KameleoonClient en utilisant KameleoonClientFactory.
use std::time::Duration;
use kameleoon_client::config::KameleoonClientConfigBuilder;
use kameleoon_client::factory::KameleoonClientFactory;
async fn create_client() -> Result<KameleoonClient, KameleoonError> {
let site_code = "a8st4f59bj";
let client = KameleoonClientFactory::create_with_path(site_code, "/etc/kameleoon/client-rust.json")?;
client.initialize().await?;
Ok(client)
}
use std::time::Duration;
use kameleoon_client::config::KameleoonClientConfigBuilder;
use kameleoon_client::factory::KameleoonClientFactory;
async fn create_client() -> Result<KameleoonClient, KameleoonError> {
let site_code = "a8st4f59bj";
let config = KameleoonClientConfigBuilder::default()
.client_id("<client-id>".to_owned()) // mandatory
.client_secret("<client-secret>".to_owned()) // mandatory
.refresh_interval(Duration::from_mins(60)) // optional (60 minutes by default)
.session_duration(Duration::from_mins(30)) // optional (30 minutes by default)
.default_timeout(Duration::from_millis(10_000)) // optional (10000 ms by default)
.tracking_interval(Duration::from_millis(1_000)) // optional (10000 ms by default)
.environment("development".to_owned()) // optional
.top_level_domain(".example.com") // mandatory if you use hybrid mode (engine or web experiments)
.proxy_host("http://192.168.0.25:8080".to_owned()) // optional
.network_domain("example.com".to_owned()) // optional
.build()
.unwrap();
let client = KameleoonClientFactory::create_with_config(site_code, config)?;
client.initialize().await?;
Ok(client)
}
Un KameleoonClient est l’objet principal utilisé pour évaluer les feature flags, ajouter des données de visiteur et envoyer des requêtes de tracking.
- Il est recommandé d’utiliser
KameleoonClient comme un objet singleton, car il sert de pont entre votre application et la plateforme Kameleoon. Il expose toutes les méthodes et propriétés requises pour exécuter des expériences efficacement.
- Le SDK Rust s’initialise de manière asynchrone. Vous devez appeler
initialize() avant de vous appuyer sur l’évaluation des fonctionnalités dans le code de production.
Activer un feature flag
Attribuer un identifiant unique à un utilisateur
Pour attribuer un identifiant unique à un utilisateur, vous pouvez utiliser la méthode get_visitor_code(). Si un visitor code n’existe pas (issu 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 de la méthode get_visitor_code() garantit que l’identifiant 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 l’état ou la variation d’un feature flag pour un utilisateur spécifique, vous devez utiliser la méthode get_variation() ou is_feature_active() pour récupérer la configuration en fonction de la feature_key.
La méthode get_variation() gère à la fois les feature flags simples avec des états ON/OFF et les flags plus complexes avec plusieurs variations. La méthode récupère la variation appropriée pour l’utilisateur en vérifiant les règles du feature, en attribuant la variation et en la renvoyant en fonction de la feature_key et du visitor_code.
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 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 vous appuyer plutôt sur le tracking côté client géré par le moteur Kameleoon, par exemple. De plus, définir track=false est utile lors de l’utilisation de la méthode get_variations(), où vous pourriez avoir besoin uniquement 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
Ajouter des points de données pour cibler un utilisateur ou filtrer / segmenter les visites dans les rapports
Pour cibler un utilisateur, assurez-vous d’avoir ajouté des 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 ciblage disponibles, consultez l’article détaillé sur le sujet.
De plus, les points de données que vous ajoutez au profil du visiteur seront disponibles lors de l’analyse de vos expériences, vous permettant de filtrer et de segmenter vos résultats par des facteurs tels que l’appareil et le navigateur. Le mode hybride de Kameleoon collecte automatiquement une variété de points de données côté client, ce qui facilite la segmentation de vos résultats en fonction de ces points de données pré-collectés. Voir la liste complète ici.
Si vous devez suivre des points de données supplémentaires au-delà de ce qui est 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.
Suivre les 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éthode track_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). Si vous préférez envoyer la requête immédiatement, utilisez la méthode flush_instant().
Envoyer des événements à des 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. Utilisez ensuite 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’analyse. L’utilisation de cette méthode vous permet d’enregistrer des événements et de les envoyer à la plateforme d’analyse de votre choix.
Utiliser 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 de feature flag. 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 le stockage persistant pour les SDK mobiles). Cependant, dans certains scénarios, vous pourriez avoir besoin de garantir que tous les utilisateurs de la 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 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 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 les fonctionnalités d’A/B test qui ont un impact sur toute une équipe ou une entreprise.
En implémentant une clé de bucketing personnalisée, vous garantissez une plus grande cohérence et précision dans vos expériences, ce qui conduit à des résultats plus fiables et à une meilleure expérience utilisateur.
Détails techniques
Lorsque vous configurez une clé de bucketing personnalisée pour un feature flag, vous fournissez à Kameleoon un identifiant spécifique provenant des données de votre application :
use kameleoon_client::data::CustomData;
client.add_data(visitor_code, [CustomData::new(42, vec!["new_visitor_code".to_owned()])])?;
- 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 transmettrez votre clé de bucketing personnalisée choisie en tant qu’objet CustomData. Ici, new_visitor_code fait référence à l’identifiant que vous souhaitez utiliser pour votre bucketing (par exemple, le nouveau user_id ou account_id).
Pour que la clé de bucketing personnalisée fonctionne correctement, 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 des utilisateurs aux variations utiliseront ce new_visitor_code (votre clé personnalisée) au lieu du visitor_code par défaut. L’utilisation du new_visitor_code signifie que la décision de bucketing est liée à votre identifiant personnalisé, garantissant des attributions cohérentes à travers divers contextes où cet identifiant est présent.
- Suivi des données et analyses : 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 au visitor_code d’origine. Cette séparation garantit que vos analyses reflètent fidèlement 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 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 un
&str.
- 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 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 façon dont Kameleoon gère les données entre les appareils sont disponibles dans l’article sur l’expérimentation cross-device.
Synchroniser des données personnalisées entre appareils
Bien que la synchronisation du mapping 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 du mapping personnalisé n’est pas requise :
Même identifiant utilisateur sur tous les appareils
Si le même identifiant 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 souhaitez synchroniser les données collectées entre plusieurs appareils.
Instances multi-serveurs avec des identifiants cohérents
Dans les configurations complexes impliquant plusieurs serveurs (par exemple, des instances de serveurs distribués), où le même identifiant utilisateur est disponible sur tous les serveurs, la synchronisation entre serveurs (avec get_remote_visitor_data()) est suffisante sans synchronisation de 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, il est supposé 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 le scope Visitor pour vos données personnalisées.
// In this example, a Custom data with index `90` was set to "Visitor" scope in Kameleoon.
use kameleoon_client::data::CustomData;
const VISITOR_SCOPE_CUSTOM_DATA_INDEX: u32 = 90;
client.add_data(visitor_code, [CustomData::new(VISITOR_SCOPE_CUSTOM_DATA_INDEX, vec!["your data".to_owned()])])?;
client.flush_instant(visitor_code).await?;
// Before working with the data, call the `get_remote_visitor_data` method.
client.get_remote_visitor_data(visitor_code, None).await?;
// After calling the method, the SDK on Device B will have access to CustomData of Visitor scope defined on Device A.
// So, "your data" will be available for targeting and tracking the visitor.
Utiliser des 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 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, 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 Visiteur des pages de résultats de votre expérience, ces sessions apparaîtront comme un seul visiteur.
La configuration du SDK garantit que les sessions associées voient toujours la même variation de l’expérience. Cependant, il existe certaines limitations concernant l’allocation de variation cross-device. Ces limitations sont décrites ici.
Suivez le guide activer 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 :
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 qui est associé à un autre visiteur.
Voici un exemple d’utilisation de données personnalisées pour la fusion de sessions.
// In this example, 91 represents the Custom Data's index configured as a unique identifier in Kameleoon.
use kameleoon_client::data::{CustomData, UniqueIdentifier};
const MAPPING_INDEX: u32 = 91;
const FEATURE_KEY: &str = "ff123";
let anonymous_visitor_code = "anonymous-visitor";
let user_id = "authenticated-user";
// 1. Before the visitor is authenticated
// Retrieve the variation for an unauthenticated visitor.
// Assume anonymousVisitorCode is the randomly generated ID for that visitor.
let anonymous_variation = client.get_variation(anonymous_visitor_code, FEATURE_KEY)?;
// 2. After the visitor is authenticated
// Assume `userId` is the visitor code of the authenticated visitor.
client.add_data(anonymous_visitor_code, [CustomData::new(MAPPING_INDEX, vec![user_id.to_owned()])])?;
client.flush_instant(anonymous_visitor_code).await?;
// Indicate that `userId` is a unique identifier.
client.add_data(user_id, [UniqueIdentifier::new(true)])?;
// 3. After the visitor was authorized
// Retrieve the variation for the `userId`, which will match the anonymous visitor code's variation.
let user_variation = client.get_variation(user_id, FEATURE_KEY)?;
let is_same_variation = user_variation.key == anonymous_variation.key; // True
// `userId` and `anonymousVisitorCode` are now linked and can be tracked as a single visitor.
client.track_conversion(user_id, 123)?;
// Additionally, the linked visitors share all fetched previously tracked remote data.
client.get_remote_visitor_data(user_id, None).await?;
Dans cet exemple, l’application a une page de connexion. Comme l’identifiant 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 que l’utilisateur se connecte, le visiteur anonyme est associé à l’identifiant utilisateur et utilisé comme identifiant unique pour le visiteur.
Journalisation
Le SDK génère des journaux pour refléter divers processus internes et problèmes.
Niveaux de journalisation
Le SDK prend en charge la configuration de la limitation de la journalisation par niveau de journal.
use kameleoon_client::logging::{KameleoonLogger, LogLevel};
// The `None` log level does not allow logging.
KameleoonLogger::set_log_level(LogLevel::None);
// The `Error` log level only allows logging issues that may affect the SDK's primary behaviour.
KameleoonLogger::set_log_level(LogLevel::Error);
// The `Warning` log level allows logging issues which may require an attention.
// It extends the `ERROR` log level.
// The `WARNING` log level is a default log level.
KameleoonLogger::set_log_level(LogLevel::Warning);
// The `Info` log level allows logging general information on the SDK's internal processes.
// It extends the `WARNING` log level.
KameleoonLogger::set_log_level(LogLevel::Info);
// The `Debug` level logs additional details about the SDK’s internal processes and extends the `INFO` level
// with more granular. diagnostic output.
// This information is not intended for end-user interpretation but can be sent to our support team
// to assist with internal troubleshooting.
KameleoonLogger::set_log_level(LogLevel::Debug);
Gestion personnalisée des journaux
Le SDK écrit ses journaux dans la sortie console par défaut. Ce comportement peut être remplacé.
La limitation de la journalisation par niveau de journal est effectuée indépendamment de la logique de gestion des journaux.
use kameleoon_client::logging::{KameleoonLogger, LogLevel, Logger};
use log::{error, warn, info, debug};
pub struct CustomLogger;
impl Logger for CustomLogger {
// `log` method accepts logs from the SDK
fn log(&self, log_level: LogLevel, message: &str) {
// Custom log handling logic here. For example:
match log_level {
LogLevel::Error => error!("{}", message),
LogLevel::Warning => warn!("{}", message),
LogLevel::Info => info!("{}", message),
LogLevel::Debug => debug!("{}", message),
}
}
}
// Log level filtering is applied separately from log handling logic.
// The custom logger will only accept logs that meet or exceed the specified log level.
// Ensure the log level is set correctly.
KameleoonLogger::set_log_level(LogLevel::Debug); // Optional; defaults to `LogLevel.WARNING`.
KameleoonLogger::set_logger(Box::new(CustomLogger));
Référence
Voici la documentation de référence complète du SDK Rust.
Initialisation
create()
Pour utiliser le SDK, créez un KameleoonClient à partir d’une instance KameleoonClientConfig avec KameleoonClientFactory::create_with_config()/KameleoonClientFactory::create_with_file().
create_with_config()
create_with_file()
use std::time::Duration;
use kameleoon_client::config::KameleoonClientConfigBuilder;
use kameleoon_client::factory::KameleoonClientFactory;
let config = KameleoonClientConfigBuilder::default()
.client_id("<client-id>".to_owned()) // mandatory
.client_secret("<client-secret>".to_owned()) // mandatory
.refresh_interval(Duration::from_mins(60)) // optional (60 minutes by default)
.session_duration(Duration::from_mins(30)) // optional (30 minutes by default)
.default_timeout(Duration::from_millis(10_000)) // optional (10000 ms by default)
.tracking_interval(Duration::from_millis(1_000)) // optional (10000 ms by default)
.environment("development".to_owned()) // optional
.top_level_domain(".example.com") // mandatory if you use hybrid mode (engine or web experiments)
.proxy_host("http://192.168.0.25:8080".to_owned()) // optional
.network_domain("example.com".to_owned()) // optional
.build()
.unwrap();
let client = KameleoonClientFactory::create_with_config(site_code, config)?;
Arguments
| Nom | Type | Description |
|---|
site_code (requis) | &str | Clé unique du projet Kameleoon utilisée par le SDK. |
config (requis) | KameleoonClientConfig | Objet de configuration du SDK. |
use kameleoon_client::factory::KameleoonClientFactory;
let client = KameleoonClientFactory::create_with_file("a8st4f59bj", "/etc/kameleoon/client-rust.json")?;
Arguments
| Nom | Type | Description |
|---|
site_code (requis) | &str | Clé unique du projet Kameleoon utilisée par le SDK. |
config_path (requis) | &str | Chemin vers le fichier de configuration JSON. |
Valeur de retour
| Type | Description |
|---|
Result<KameleoonClient, KameleoonError> | Une instance de client en cas de succès, sinon une erreur d’initialisation. |
Erreurs
| Type | Description |
|---|
ErrorCode::ConfigCredentialsInvalid | Les identifiants du SDK sont manquants. |
ErrorCode::SiteCodeIsEmpty | Le code de site fourni est vide. |
initialize()
Attend que le client Kameleoon s’initialise, en utilisant soit le default_timeout configuré, soit un timeout fourni. Cette méthode garantit que le client est entièrement initialisé avant d’effectuer toute autre opération.
use std::time::Duration;
// Initializes the client using the configured default timeout
client.initialize().await?;
// Initializes the client with a custom timeout of 5 seconds
client.initialize_with_timeout(Duration::from_secs(5)).await?;
Arguments
| Nom | Type | Description |
|---|
timeout (optionnel) | Duration | Temps maximum d’attente pour l’initialisation. |
Valeur de retour
| Type | Description |
|---|
Result<(), KameleoonError> | Indique si l’initialisation s’est terminée avec succès ou si une erreur s’est produite. |
Erreurs
| Type | Description |
|---|
ErrorCode::Initialization | Indique que le SDK n’est pas encore entièrement initialisé. |
is_ready()
Vérifie si le client a été initialisé.
if client.is_ready() {
// The client is ready
}
Valeur de retour
| Type | Description |
|---|
bool | true si le client est prêt à être utilisé ; sinon false. |
forget()
Supprime le client SDK mis en cache associé au site_code spécifié.
use kameleoon_client::factory::KameleoonClientFactory;
// Removes the cached client for the given site code
KameleoonClientFactory::forget("a8st4f59bj")?;
// Removes the cached client for the given site code and environment
KameleoonClientFactory::forget_with_environment("a8st4f59bj", "production")?;
Arguments
| Nom | Type | Description |
|---|
site_code (requis) | &str | Identifiant unique du projet Kameleoon. |
environment (optionnel) | &str | Clé d’environnement associée au client mis en cache. |
Valeur de retour
| Type | Description |
|---|
Result<(), KameleoonError> | Indique si le client mis en cache a été supprimé avec succès ou si une erreur s’est produite. |
Feature flags et variations
is_feature_active()
- 📨 Envoie des données de tracking à Kameleoon (selon l’option
track)
Détermine si un feature flag est actif pour un utilisateur donné.
Si le visiteur n’a pas encore été évalué pour ce feature flag, le SDK évalue les règles de ciblage et renvoie le résultat. Si le visiteur a déjà une évaluation stockée pour le feature, le SDK réutilise le résultat existant pour assurer la cohérence.
Kameleoon utilise le tracking pour compter les sessions et les visiteurs lorsque vous appelez certaines méthodes, telles que is_feature_active(), get_variation() ou get_variations().Utilisez la valeur par défaut true pour le paramètre track lorsque vous exposez des visiteurs à une variation et devez les compter. Définissez le paramètre track sur false uniquement si vous appelez ces méthodes avant d’exposer les visiteurs.Par exemple, si vous appelez get_variations() pour récupérer toutes les variations avant d’exposer les visiteurs, définissez le paramètre track sur false. Ce réglage empêche Kameleoon de compter prématurément une session. Vous pouvez ensuite déclencher le tracking plus tard lorsque vous exposez explicitement le visiteur.Kameleoon envoie des 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 en une seule session tant que l’intervalle entre les événements est inférieur à 30 minutes. Si plus de 30 minutes s’écoulent entre les événements de tracking, Kameleoon compte les événements comme des sessions séparées. Une visite apparaît dans vos rapports 30 minutes après le dernier événement enregistré dans la session.
La méthode is_feature_active() évalue la variante servie, et non l’état du flag maître. 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 On.
use kameleoon_client::client::IsFeatureActiveOpts;
let feature_key = "new_checkout";
// Evaluates the feature flag and sends tracking data (default behavior)
let active = client.is_feature_active(visitor_code, feature_key)?;
// Evaluates the feature flag without sending tracking data
let active_without_tracking = client.is_feature_active_with_opts(
visitor_code,
feature_key,
IsFeatureActiveOpts::new().track(false),
)?;
Arguments
| Nom | Type | Description | Défaut |
|---|
visitor_code (requis) | &str | Identifiant unique de l’utilisateur. | |
feature_key (requis) | &str | Clé du feature à évaluer pour l’utilisateur. | |
track (optionnel) | bool | Active ou désactive le tracking de l’évaluation du feature. | true |
Valeur de retour
| Type | Description |
|---|
Result<bool, KameleoonError> | Indique si le feature flag est actif pour le visitor_code spécifié, ou renvoie une erreur. |
Erreurs
| Type | Description |
|---|
ErrorCode::Initialization | Indique que le SDK n’est pas encore entièrement initialisé. |
ErrorCode::FeatureNotFound | Exception indiquant que la clé de feature demandée n’a pas été trouvée dans la configuration interne du SDK. Cela signifie généralement que le feature flag n’est pas activé dans l’application Kameleoon (mais que le code implémentant le feature est déjà déployé dans l’application). |
ErrorCode::VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide. Il est soit vide, soit plus long que 255 caractères. |
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 visitor_code et 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 d’erreur 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 delivery 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… » dans une interface de gestion.
use kameleoon_client::client::GetVariationOpts;
let feature_key = "new_checkout";
// Retrieves the variation assigned to the visitor (with tracking enabled by default)
let variation = client.get_variation(visitor_code, feature_key)?;
// Retrieves the variation without sending tracking data
let variation_without_tracking = client.get_variation_with_opts(
visitor_code,
feature_key,
GetVariationOpts::new().track(false),
)?;
Arguments
| Nom | Type | Description | Défaut |
|---|
| visitor_code (requis) | &str | Identifiant unique du visiteur. | |
| feature_key (requis) | &str | Clé du feature que vous souhaitez exposer à un visiteur. | |
| track (optionnel) | bool | Paramètre optionnel pour activer ou désactiver le tracking de l’évaluation du feature. | true |
Valeur de retour
| Type | Description |
|---|
Result<Variation, KameleoonError> | Une Variation attribuée à un visiteur donné pour un feature flag spécifique en cas de succès, sinon une erreur. |
Erreurs
| Type | Description |
|---|
ErrorCode::Initialization | Indique que le SDK n’est pas encore entièrement initialisé. |
ErrorCode::VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide. Il est soit vide, soit plus long que 255 caractères. |
ErrorCode::FeatureNotFound | Exception indiquant que la clé de feature demandée n’a pas été trouvée dans la configuration interne du SDK. Cela signifie généralement que le feature flag n’est pas activé dans l’application Kameleoon (mais que le code implémentant le feature est déjà déployé dans l’application). |
ErrorCode::FeatureEnvironmentDisabled | Exception indiquant que le feature flag est désactivé pour l’environnement actuel du visiteur (par exemple, production, staging ou development). |
ErrorCode::FeatureEvaluationBlocked | Exception indiquant que l’évaluation du feature est bloquée. La raison est décrite dans le message d’erreur. Cela se produit généralement en raison de restrictions RGPD lorsque le visiteur n’a pas donné de consentement légal. |
get_variations()
- 📨 Envoie des données de tracking à Kameleoon (selon le paramètre
track)
Récupère une carte 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 suivra ou non les attributions de variation. Par défaut, il est défini sur true. S’il est défini sur false, le tracking sera désactivé.
La carte renvoyée se compose des clés de feature flag comme clés et de leurs Variation correspondantes 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 d’erreur 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 delivery 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… » dans une interface de gestion.
use kameleoon_client::client::GetVariationsOpts;
// Retrieves all variations assigned to the visitor (with default options)
let variations = client.get_variations(visitor_code)?;
// Retrieves only active variations for the visitor
let only_active_variations = client.get_variations_with_opts(
visitor_code,
GetVariationsOpts::new().only_active(true),
)?;
// Retrieves variations without sending tracking data
let variations_without_tracking = client.get_variations_with_opts(
visitor_code,
GetVariationsOpts::new().track(false),
)?;
Arguments
| Nom | Type | Description | Défaut |
|---|
| visitor_code (requis) | &str | Identifiant unique du visiteur. | |
| only_active (optionnel) | bool | Paramètre optionnel indiquant s’il faut renvoyer les variations pour les feature flags actifs (true) ou tous (false). | false |
| track (optionnel) | bool | Paramètre optionnel pour activer ou désactiver le tracking de l’évaluation du feature. | true |
Valeur de retour
| Type | Description |
|---|
Result<HashMap<String, Variation>, KameleoonError> | Carte qui contient les objets Variation attribués des feature flags en utilisant les clés des features correspondants en cas de succès, sinon une erreur. |
Erreurs
| Type | Description |
|---|
ErrorCode::Initialization | Indique que le SDK n’est pas encore entièrement initialisé. |
ErrorCode::VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide. Il est soit vide, soit plus long que 255 caractères. |
set_forced_variation()
La méthode vous permet d’attribuer par programmation une Variation 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 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 les conditions de segmentation et 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.
Une variation forcée est traitée de la même manière qu’une variation évaluée. Elle est suivie dans les analyses et stockée dans le contexte utilisateur comme toute variation évaluée standard, assurant la cohérence dans les rapports.
La méthode peut lancer des exceptions dans certaines conditions (par exemple, paramètres invalides, contexte utilisateur ou problèmes internes). Une gestion appropriée des exceptions est essentielle pour garantir que votre application reste stable et résiliente.
Il est important de distinguer les variations forcées des variations simulées :
- Variations forcées : sont spécifiques à une expérience individuelle.
- Variations simulées : affectent le résultat global du feature flag.
use kameleoon_client::client::SetForcedVariationOpts;
let experiment_id = 202387;
// Forces the visitor into "variation_2" for the given experiment
client.set_forced_variation(visitor_code, experiment_id, Some("variation_2"))?;
// Removes any previously forced variation for the visitor in this experiment
client.set_forced_variation(visitor_code, experiment_id, None)?;
// Forces the visitor into "variation_2" with custom options
// In this case, targeting rules are respected (force_targeting = false)
client.set_forced_variation_with_opts(
visitor_code,
experiment_id,
Some("variation_2"),
SetForcedVariationOpts::new().force_targeting(false),
)?;
Arguments
| Nom | Type | Description | Défaut |
|---|
| visitor_code (requis) | &str | Identifiant unique du visiteur. | |
| experiment_id (requis) | u32 | ID d’expérience qui sera ciblé et sélectionné lors du processus d’évaluation. | |
| variation_key (requis) | Option<&str> | Clé de variation correspondant à une Variation qui doit être forcée comme valeur retournée pour l’expérience. Si la valeur est None, la variation forcée sera réinitialisée. | |
| force_targeting (optionnel) | bool | Indique si le ciblage pour l’expérience doit être forcé et ignoré (true) ou appliqué comme dans le processus d’évaluation standard (false). | true |
Valeur de retour
| Type | Description |
|---|
Result<(), KameleoonError> | Indique si la variation forcée a été définie avec succès ou si une erreur s’est produite. |
Erreurs
| Type | Description |
|---|
ErrorCode::Initialization | Indique que le SDK n’est pas encore entièrement initialisé. |
ErrorCode::VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide. Il est soit vide, soit plus long que 255 caractères. |
ErrorCode::FeatureExperimentNotFound | Exception indiquant que l’ID d’expérience demandé n’a pas été trouvé dans la configuration interne du SDK. Cela est généralement normal et signifie que l’expérience correspondant à la règle n’a pas encore été activée du côté de Kameleoon. |
ErrorCode::FeatureVariationNotFound | Exception indiquant que la clé (id) de variation demandée n’a pas été trouvée dans la configuration interne du SDK. Cela est généralement normal et signifie que l’expérience correspondant à la variation n’a pas encore été activée du côté de Kameleoon. |
evaluate_audiences()
- 📨 Envoie des données de tracking à Kameleoon
Cette méthode évalue les visiteurs par rapport à tous les segments disponibles dans Audiences Explorer 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.
client.evaluate_audiences(visitor_code)?;
Arguments
| Nom | Type | Description |
|---|
| visitor_code (requis) | &str | Identifiant unique du visiteur. |
Valeur de retour
| Type | Description |
|---|
Result<(), KameleoonError> | Indique si l’évaluation de l’audience a réussi ou si une erreur s’est produite. |
Erreurs
| Type | Description |
|---|
ErrorCode::VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide. Il est soit vide, soit plus long que 255 caractères. |
get_datafile()
Pour évaluer tous les feature flags, utilisez get_variations(). Cette méthode est plus efficace que d’appeler DataFile et d’itérer sur les flags avec get_variation().
Renvoie la configuration actuelle du SDK sous la forme d’un objet DataFile.
let datafile = client.get_datafile()?;
Valeur de retour
| Type | Description |
|---|
Result<Arc<DataFile>, KameleoonError> | Le DataFile contenant la configuration du SDK en cas de succès, sinon une erreur. |
Erreurs
| Type | Description |
|---|
ErrorCode::Initialization | Indique que le SDK n’est pas encore entièrement initialisé. |
Données du visiteur
get_visitor_code()
Utilisez get_visitor_code() pour obtenir le visitor_code Kameleoon du visiteur actuel. La méthode fonctionne avec tout stockage de cookies qui implémente le trait CookieAccessor.
La logique d’implémentation est la suivante :
- Le SDK vérifie si un cookie
kameleoonVisitorCode est déjà disponible via l’accesseur fourni.
- Si le cookie est absent, le SDK utilise
default_visitor_code lorsque vous en fournissez un.
- Sinon, le SDK génère un nouveau visitor code et le stocke via l’accesseur.
Pour plus d’informations, reportez-vous à Expérimentation hybride.
Si vous fournissez votre propre visitor_code, son unicité doit être garantie de votre côté. Notez également que la longueur du visitor_code est limitée à 255 caractères.
La méthode get_visitor_code() vous permet de définir des variations simulées pour un visiteur. Lorsque les cookies (d’une requête ou d’un document) contiennent la clé kameleoonSimulationFFData, 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 Panneau de simulation.
- 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 assurer un bon fonctionnement, la valeur du cookie doit être encodée en tant que composant URI à l’aide d’une méthode telle que encodeURIComponent.
use std::collections::HashMap;
use kameleoon_client::cookies::CookieAccessor;
// A simple in-memory cookie store, useful for testing or non-HTTP environments
struct MemoryCookies {
values: HashMap<String, String>,
}
impl CookieAccessor for MemoryCookies {
// Store the cookie value by key (max_age and top_level_domain are unused here)
fn set<'a>(&mut self, key: &str, value: &str, _max_age: u32, _top_level_domain: Option<&'a str>) {
self.values.insert(key.to_owned(), value.to_owned());
}
// Retrieve a cookie value by key
fn get(&self, key: &str) -> Option<&str> {
self.values.get(key).map(String::as_str)
}
}
// Generate or retrieve a visitor code using auto-generated value
let visitor_code = client.get_visitor_code(&mut cookies, None)?;
// Generate or retrieve a visitor code using a predefined user ID
let visitor_code = client.get_visitor_code(&mut cookies, Some("user_id"))?;
use axum::{ extract::State, http::StatusCode, response::{IntoResponse, Response} };
use axum_extra::extract::cookie::{Cookie, CookieJar};
use kameleoon_client::client::KameleoonClient;
use kameleoon_client::cookies::CookieAccessor;
use time::Duration;
// Wrapper around Axum's CookieJar to implement the CookieAccessor trait
struct AxumCookies(CookieJar);
impl CookieAccessor for AxumCookies {
// Build and add a cookie with path, max_age, and optional domain, then insert into the jar
fn set<'a>(&mut self, key: &str, value: &str, max_age: u32, top_level_domain: Option<&'a str>) {
let mut builder =
Cookie::build((key.to_owned(), value.to_owned())).path("/").max_age(Duration::seconds(i64::from(max_age)));
if let Some(domain) = top_level_domain {
builder = builder.domain(domain.to_owned());
}
self.0 = std::mem::take(&mut self.0).add(builder.build());
}
// Retrieve a cookie value by key from the jar
fn get(&self, key: &str) -> Option<&str> {
self.0.get(key).map(|cookie| cookie.value())
}
}
async fn get_visitor_code(
State(client): State<KameleoonClient>,
jar: CookieJar,
) -> Result<(StatusCode, CookieJar, String), Response> {
let mut cookies = AxumCookies(jar);
// Retrieve or generate a visitor code; map any SDK error to a 500 response
let visitor_code = client
.get_visitor_code(&mut cookies, None)
.map_err(|error| (StatusCode::INTERNAL_SERVER_ERROR, error.to_string()).into_response())?;
// Return the status, updated cookie jar, and visitor code in the response
Ok((StatusCode::OK, cookies.0, visitor_code))
}
use actix_web::{ HttpRequest, HttpResponse, cookie::Cookie, http::{StatusCode, header}, web};
use kameleoon_client::client::KameleoonClient;
use kameleoon_client::cookies::CookieAccessor;
use kameleoon_client::error::KameleoonError;
use time::Duration;
// Holds both request cookies (read-only) and response cookies (to be set on the client)
struct ActixCookies<'a> {
request: Ref<'a, Vec<Cookie<'static>>>,
response: Vec<Cookie<'static>>,
}
impl CookieAccessor for ActixCookies<'_> {
// Build a cookie with path, max_age, and optional domain;
// update it if it already exists in the response, otherwise append it
fn set<'a>(&mut self, key: &str, value: &str, max_age: u32, top_level_domain: Option<&'a str>) {
let mut builder =
Cookie::build(key.to_owned(), value.to_owned()).path("/").max_age(Duration::seconds(i64::from(max_age)));
if let Some(domain) = top_level_domain {
builder = builder.domain(domain.to_owned());
}
let next_cookie = builder.finish();
match self.response.iter_mut().find(|cookie| cookie.name() == key) {
Some(cookie) => *cookie = next_cookie,
None => self.response.push(next_cookie),
}
}
// Check response cookies first, then fall back to request cookies
fn get(&self, key: &str) -> Option<&str> {
self.response
.iter()
.find(|cookie| cookie.name() == key)
.map(|cookie| cookie.value())
.or_else(|| self.request.iter().find(|cookie| cookie.name() == key).map(|cookie| cookie.value()))
}
}
fn get_visitor_code(client: web::Data<KameleoonClient>, request: HttpRequest) -> Result<HttpResponse, KameleoonError> {
// Parse cookies from the incoming request
let request_cookies = request.cookies().map_err(|error| error.to_string())?;
let mut cookies = ActixCookies {
request: request_cookies,
response: Vec::new(),
};
// Retrieve or generate a visitor code using the SDK
let visitor_code = client.get_visitor_code(&mut cookies, None)?;
// Attach any new/updated cookies to the response headers
let mut response = HttpResponse::build(StatusCode::OK);
for cookie in cookies.response {
response.append_header((header::SET_COOKIE, cookie.encoded().to_string()));
}
Ok(response.body(visitor_code))
}
Arguments
| Nom | Type | Description |
|---|
cookies (requis) | &mut impl CookieAccessor | Accesseur de cookies mutable utilisé pour lire et stocker le cookie du visiteur. |
default_visitor_code (optionnel) | Option<&str> | Visitor code à utiliser lorsqu’aucun cookie n’est présent. |
Valeur de retour
| Type | Description |
|---|
Result<String, KameleoonError> | Chaîne représentant un visitor code unique utilisé dans le SDK en cas de succès, sinon une erreur. |
add_data()
La méthode add_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 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 future à l’aide de la méthode 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 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.
use kameleoon_client::data::{Browser, BrowserKind, PageView, UserAgent};
client.add_data(visitor_code, [Browser::new(BrowserKind::Chrome, Some(123.0))])?;
client.add_data(
visitor_code,
[
PageView::new("https://example.com/pricing".to_owned(), Some("Pricing".to_owned()), vec![3]).into(),
UserAgent::new("Mozilla/5.0".to_owned()).into(),
],
)?;
client.add_data_with_track(
visitor_code,
vec![PageView::new("https://example.com/checkout".to_owned(), Some("Checkout".to_owned()), vec![])],
false,
)?;
Arguments
| Nom | Type | Description | Valeur par défaut |
|---|
| visitor_code (requis) | &str | Identifiant unique du visiteur. | |
| data (requis) | impl IntoIterator<Item = impl Into<KameleoonData>> | Collection de types de données Kameleoon. | |
| track (optionnel) | bool | Spécifie si les données ajoutées sont éligibles au tracking. Lorsqu’il est défini sur false, les données sont stockées localement et utilisées uniquement pour l’évaluation du ciblage ; elles ne sont pas envoyées à la Data API de Kameleoon. | true |
Valeur de retour
| Type | Description |
|---|
Result<(), KameleoonError> | Indique si les données ont été ajoutées avec succès ou si une erreur s’est produite. |
Erreurs
| Type | Description |
|---|
ErrorCode::Initialization | Indique que le SDK n’est pas encore entièrement initialisé. |
ErrorCode::VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide. Il est soit vide, soit plus long que 255 caractères. |
flush()
- 📨 Envoie des données de tracking à Kameleoon
La méthode flush() agrège toutes les données Kameleoon associées à un visiteur et envoie une requête de tracking au serveur. Cette requête comprend toutes les données précédemment ajoutées via la méthode add_data qui n’ont pas encore été transmises via 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 permet de contrôler le moment où les données liées à un visitor_code spécifique sont transmises. Par exemple, si add_data() est appelée plusieurs fois, 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.
flush() — Met en file d’attente une opération de flush selon l’intervalle de tracking configuré.
flush_instant() — Envoie les données de tracking immédiatement sans attendre l’intervalle.
// Queues a flush operation for the given visitor_code.
// Data will be sent according to the configured tracking interval (non-blocking).
client.flush(visitor_code)?;
// Immediately sends all pending tracking data for the given visitor_code.
// This is an async operation and must be awaited.
client.flush_instant(visitor_code).await?;
Arguments
| Nom | Type | Description |
|---|
visitor_code (requis) | &str | Identifiant unique du visiteur. |
Valeur de retour
| Type | Description |
|---|
Result<(), KameleoonError> | Indique si l’opération a été planifiée ou exécutée avec succès, ou si une erreur s’est produite. |
Erreurs
| Type | Description |
|---|
ErrorCode::Initialization | Indique que le SDK n’est pas encore entièrement initialisé. |
ErrorCode::VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide. Il est soit vide, soit plus long que 255 caractères. |
get_remote_data()
La méthode get_remote_data() vous permet de récupérer des données distantes stockées sur les serveurs Kameleoon pour la key spécifiée. Dans la plupart des configurations, ces données sont écrites via la Data API de Kameleoon et peuvent être récupérées ultérieurement par votre service Rust 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é.
let data = client.get_remote_data("test-key").await?;
Arguments
| Nom | Type | Description |
|---|
key (requis) | &str | Clé associée aux données distantes que vous souhaitez récupérer. |
Valeur de retour
| Type | Description |
|---|
Result<String, KameleoonError> | Charge utile associée à la key spécifiée en cas de succès, sinon une erreur. Dans la plupart des cas, la charge utile est du JSON sérialisé sous forme de chaîne. |
Erreurs
| Type | Description |
|---|
ErrorCode::Initialization | Indique que le SDK n’est pas encore entièrement initialisé. |
ErrorCode::Network | Renvoyée lorsque la requête de données distantes échoue ou que le serveur répond avec un code d’état non réussi. |
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 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 à l’aide de 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 antérieures.
- 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.
Lisez cet article pour mieux comprendre les cas d’utilisation possibles.
use kameleoon_client::types::RemoteVisitorDataFilter;
// Fetch remote visitor data without any filter
// This will return all available data for the given visitor
client.get_remote_visitor_data(visitor_code, None).await?;
// Create a filter to limit the returned data
let filter = RemoteVisitorDataFilter {
// Include data from the last 5 visits
previous_visit_amount: 5,
// Include conversion events (e.g., goals, transactions)
conversions: true,
// Include page view history
page_views: true,
// Use default values for all other fields
..Default::default()
};
// Fetch remote visitor data using the specified filter
// This will return only the data matching the filter criteria
client.get_remote_visitor_data(visitor_code, Some(filter)).await?;
Arguments
| Nom | Type | Description | Défaut |
|---|
visitor_code (requis) | &str | Visitor code dont les données doivent être récupérées. | |
filter (optionnel) | Option<RemoteVisitorDataFilter> | Filtre décrivant quelles données distantes du visiteur doivent être récupérées. | RemoteVisitorDataFilter::default() |
Valeur de retour
| Type | Description |
|---|
Result<(), KameleoonError> | Renvoie avec succès lorsque les données sont récupérées et ajoutées localement, sinon une erreur. |
Erreurs
| Type | Description |
|---|
ErrorCode::Initialization | Indique que le SDK n’est pas encore entièrement initialisé. |
ErrorCode::VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide. Il est soit vide, soit plus long que 255 caractères. |
ErrorCode::Network | Renvoyée lorsque la requête de données distantes du visiteur échoue, ne peut pas être analysée, ou que le serveur répond avec un code d’état non réussi. |
Utilisation des paramètres dans get_remote_visitor_data()
La méthode get_remote_visitor_data() vous permet de contrôler quelles données sont récupérées pour un visiteur. La même approche de filtrage fonctionne pour les objectifs, les expériences, les variations et autres données de visiteur.
Par exemple, si vous souhaitez cibler les utilisateurs qui ont converti sur un objectif lors de leurs cinq dernières visites, vous pouvez définir previous_visit_amount sur 5 et conversions sur true.
La flexibilité illustrée dans cet exemple ne se limite pas aux données d’objectifs. Vous pouvez utiliser le filtre pour récupérer de nombreux comportements de visiteur différents et les rendre disponibles pour la logique de ciblage et de reporting de votre application Rust.
Champs RemoteVisitorDataFilter
| Nom | Type | Description | Défaut |
|---|
previous_visit_amount | i32 | Nombre de visites précédentes à partir desquelles récupérer les données. | 1 |
current_visit | bool | Si true, les données de la visite actuelle seront récupérées. | true |
custom_data | bool | Si true, les données personnalisées seront récupérées. | true |
visitor_code | bool | Si true, le visitor code le plus récent sera réutilisé. | true |
page_views | bool | Si true, les données de page vue seront récupérées. | false |
geolocation | bool | Si true, les données de géolocalisation seront récupérées. | false |
device | bool | Si true, les données d’appareil seront récupérées. | false |
browser | bool | Si true, les données de navigateur seront récupérées. | false |
operating_system | bool | Si true, les données de système d’exploitation seront récupérées. | false |
conversions | bool | Si true, les données de conversion seront récupérées. | false |
experiments | bool | Si true, les données d’expérience seront récupérées. | false |
kcs | bool | Si true, les données Kameleoon Conversion Score seront récupérées. | false |
personalizations | bool | Si true, les données de personnalisation seront récupérées. | false |
cbs | bool | Si true, les données de score Contextual Bandit seront récupérées. | false |
get_visitor_warehouse_audience()
Cette méthode récupère les données d’audience associées à un visiteur dans votre intégration d’entrepôt en utilisant le visitor_code spécifié et, éventuellement, une warehouse_key. La warehouse_key est généralement votre ID utilisateur interne. Le paramètre custom_data_index correspond aux données personnalisées Kameleoon que Kameleoon utilise pour cibler vos visiteurs.
Lorsque l’appel réussit, le SDK convertit la liste d’audiences renvoyée en CustomData, l’ajoute localement au visiteur et la rend disponible pour le ciblage. Pour plus de contexte, consultez la documentation sur le ciblage d’entrepôt.
// Fetch audience data for a visitor using only the visitor_code.
client.get_visitor_warehouse_audience(visitor_code, None, 98).await?;
// Fetch audience data for a visitor using both visitor_code and warehouse_key.
// Useful when your warehouse uses a different identifier than visitor_code.
client.get_visitor_warehouse_audience(visitor_code, Some("internal-user-id"), 98).await?;
Arguments
| Nom | Type | Description | Défaut |
|---|
visitor_code (requis) | &str | Visiteur dont les audiences d’entrepôt doivent être récupérées. | |
warehouse_key (optionnel) | Option<&str> | Clé d’entrepôt externe, généralement votre ID utilisateur interne. | visitor_code |
custom_data_index (requis) | u32 | Index de données personnalisées configuré dans Kameleoon pour le ciblage d’audience d’entrepôt. | |
Valeur de retour
| Type | Description |
|---|
Result<(), KameleoonError> | Succès lorsque les données d’audience d’entrepôt sont récupérées et stockées localement en tant que CustomData. |
Erreurs
| Type | Description |
|---|
ErrorCode::Initialization | Indique que le SDK n’est pas encore entièrement initialisé. |
ErrorCode::VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide. Il est soit vide, soit plus long que 255 caractères. |
ErrorCode::Network | Renvoyée lorsque la requête d’audience d’entrepôt échoue, ne peut pas être analysée, ou que le serveur répond avec un code d’état non réussi. |
set_legal_consent()
Vous devez utiliser cette méthode pour spécifier si le visiteur a donné son consentement légal pour utiliser des données personnelles. Définir legal_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 du visiteur de manière responsable. Pour plus d’informations, consultez la politique de gestion du consentement.
Si vous fournissez un accesseur de cookies, le SDK met également à jour les cookies du visiteur en fonction de l’état du consentement.
// Set consent and update cookies
client.set_legal_consent(visitor_code, true, Some(&mut cookies))?;
// Set consent without updating cookies
client.set_legal_consent(visitor_code, true, None)?;
Arguments
| Nom | Type | Description | Défaut |
|---|
visitor_code (requis) | &str | L’identifiant unique de l’utilisateur. | |
legal_consent (requis) | bool | true indique que le visiteur a donné son consentement légal, false indique que le visiteur n’a jamais fourni, ou a retiré, son consentement légal. | |
cookies (optionnel) | Option<&mut impl CookieAccessor> | Accesseur de cookies optionnel utilisé pour mettre à jour les cookies. | None |
Valeur de retour
| Type | Description |
|---|
Result<(), KameleoonError> | Indique si l’état de consentement du visiteur a été mis à jour avec succès, sinon une erreur. |
Erreurs
| Type | Description |
|---|
ErrorCode::Initialization | Indique que le SDK n’est pas encore entièrement initialisé. |
ErrorCode::VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide. Il est soit vide, soit plus long que 255 caractères. |
Comportement de révocation du consentement
Lorsque vous appelez 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é exigent la suppression immédiate du fichier de cookie lors de l’opt-out, vous devez le supprimer manuellement à l’aide des méthodes de gestion de cookies natives de votre framework. Le SDK ne supprimera pas le fichier automatiquement.
Objectifs et analyses tierces
track_conversion()
- 📨 Envoie des données de tracking à Kameleoon
Utilisez cette méthode pour suivre une conversion pour un objectif et un utilisateur spécifiques. Cette méthode nécessite visitor_code et goal_id. De plus, cette méthode accepte également des arguments optionnels revenue, negative et metadata. Le visitor_code est généralement identique à celui utilisé lors du déclenchement de l’expérience.
Cette méthode est non bloquante car l’appel serveur est effectué de manière asynchrone.
use kameleoon_client::client::TrackConversionOpts;
use kameleoon_client::data::CustomData;
// Track a goal
client.track_conversion(visitor_code, goal_id)?;
// Track a goal with revenue
client.track_conversion_with_opts(visitor_code, goal_id, TrackConversionOpts::new().revenue(100.0))?;
// Track a goal with negative revenue
client.track_conversion_with_opts(
visitor_code,
goal_id,
TrackConversionOpts::new().revenue(100.0).negative(true)
)?;
// Track a goal with custom metadata
client.track_conversion_with_opts(
visitor_code,
goal_id,
TrackConversionOpts::new().metadata(vec![CustomData::new(4, vec!["true".to_owned()])]),
)?;
Arguments
| Nom | Type | Description | Défaut |
|---|
| visitor_code (requis) | &str | Identifiant unique du visiteur. | |
| goal_id (requis) | u32 | ID de l’objectif. | |
| negative (optionnel) | bool | Définit si le revenu est positif ou négatif. | false |
| revenue (optionnel) | f32 | Revenu de la conversion. | 0 |
| metadata (optionnel) | Vec<CustomData> | Métadonnées de la conversion. Doivent être définies au préalable dans l’application Kameleoon. | vec![] |
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é à l’aide de 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 explicitement passées en tant que paramètres à la méthode track_conversion().Dans l’exemple ci-dessous, Kameleoon associera la conversion uniquement à la valeur de données personnalisées explicitement fournie en tant que paramètre (ici : index 5 avec la valeur ‘Amex Credit Card’).client.add_data(
visitor_code,
[
CustomData::new(5, vec!["Credit Card".to_owned()]),
CustomData::new(9, vec!["Express Delivery".to_owned()])
]
)?;
client.track_conversion_with_opts(
visitor_code,
goal_id,
TrackConversionOpts::new().metadata(vec![CustomData::new(5, vec!["Amex Credit Card".to_owned()])]),
)?
Valeur de retour
| Type | Description |
|---|
Result<(), KameleoonError> | Indique si la conversion a été mise en file d’attente avec succès pour un tracking asynchrone, sinon une erreur. |
Erreurs
| Type | Description |
|---|
ErrorCode::Initialization | Indique que le SDK n’est pas encore entièrement initialisé. |
ErrorCode::VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide. Il est soit vide, soit plus long que 255 caractères. |
get_engine_tracking_code()
Kameleoon s’intègre à plusieurs solutions d’analyse, notamment Mixpanel, Google Analytics 4 et Segment. Pour suivre correctement les expériences côté serveur, appelez la méthode get_engine_tracking_code() après que le visiteur a déclenché une expérience. Le SDK renvoie des commandes de file d’attente JavaScript pour les expériences que le visiteur a déclenchées au cours des 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 analytique active.
Reportez-vous à l’expérimentation hybride pour plus d’informations sur l’implémentation de cette méthode.
let tracking_code = client.get_engine_tracking_code(visitor_code)?;
- Pour utiliser cette fonctionnalité, implémentez à la fois le SDK Rust et le Engine.js de Kameleoon. Comme Engine.js n’est utilisé que pour le tracking dans ce flux, vous pouvez installer la balise asynchrone avant la balise de fermeture
</body>.
- Si vous souhaitez uniquement suivre les expériences dans Kameleoon et n’avez pas besoin d’envoyer les événements d’exposition à des outils d’analyse 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>.
<html lang="en">
<body>
<script>
const engineTrackingCode = `
window.kameleoonQueue = window.kameleoonQueue || [];
window.kameleoonQueue.push(['Experiments.assignVariation', 123456, 7890, true]);
window.kameleoonQueue.push(['Experiments.trigger', 123456, true]);
window.kameleoonQueue.push(['Experiments.assignVariation', 234567, 8901, true]);
window.kameleoonQueue.push(['Experiments.trigger', 234567, true]);
`;
const script = document.createElement('script');
script.textContent = engineTrackingCode;
document.body.appendChild(script);
</script>
</body>
</html>
Dans cet exemple, 123456 et 234567 sont des ID d’expérience, et 7890 et 8901 sont des ID de variation. Dans votre implémentation, le SDK génère ces valeurs dans le code de tracking renvoyé.
Arguments
| Nom | Type | Description |
|---|
| visitor_code (requis) | &str | Identifiant unique du visiteur. |
Valeur de retour
| Type | Description |
|---|
Result<String, KameleoonError> | Code JavaScript à insérer dans la page en cas de succès ; sinon, une erreur. |
Erreurs
| Type | Description |
|---|
ErrorCode::Initialization | Indique que le SDK n’est pas encore entièrement initialisé. |
ErrorCode::VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide. Il est soit vide, soit plus long que 255 caractères. |
Événements
on_datafile_update()
La méthode on_datafile_update() vous permet de gérer les événements de mise à jour du datafile. Elle accepte un seul paramètre, handler, qui est appelé chaque fois que la configuration est mise à jour via des événements de mise à jour de datafile par polling ou streaming.
// Register a callback that is invoked whenever the configuration
// is updated through a polling or streaming datafile update event.
client.on_datafile_update(Some(Box::new(|| {
// Custom logic to execute after the datafile has been updated.
println!("Kameleoon datafile updated");
})));
// Unregister the datafile update callback.
// No callback will be invoked for future datafile updates.
client.on_datafile_update(None);
Arguments
| Nom | Type | Description |
|---|
| handler | Option<Box<dyn Fn() + Send + Sync>> | Le gestionnaire qui sera appelé lorsque la configuration est mise à jour à l’aide d’un événement de configuration en temps réel. |
Types de données
Cette section répertorie les types de données Rust réexportés par le SDK dans kameleoon_client::data.
ApplicationVersion
ApplicationVersion représente le numéro de version sémantique de votre application.
Un visiteur ne peut avoir qu’une seule ApplicationVersion. L’ajout d’une seconde instance écrasera la première.
| Nom | Type | Description |
|---|
| version (optionnel) | &str | La version de l’application mobile. Ce champ doit suivre le versionnage sémantique. Les formats acceptés sont major, major.minor ou major.minor.patch. |
use kameleoon_client::data::ApplicationVersion;
// major
client.add_data(visitor_code, [ApplicationVersion::new("10")])?;
// major.minor
client.add_data(visitor_code, [ApplicationVersion::new("10.20")])?;
// major.minor.patch
client.add_data(visitor_code, [ApplicationVersion::new("10.20.30")])?;
Browser
L’ensemble de données Browser stocké ici peut être utilisé pour filtrer les rapports d’expérience et de personnalisation par toute valeur qui lui est associée.
| Nom | Type | Description |
|---|
| kind (requis) | BrowserKind | Liste des navigateurs : BrowserKind::Chrome, BrowserKind::InternetExplorer, BrowserKind::Firefox, BrowserKind::Safari, BrowserKind::Opera, BrowserKind::Other. |
| version (optionnel) | Option<f32> | Version du navigateur, le nombre à virgule flottante représente la version majeure et mineure du navigateur |
use kameleoon_client::data::{Browser, BrowserKind};
// Browser data with a version
client.add_data(visitor_code, [Browser::new(BrowserKind::Safari, 26.4)])?;
// Browser data without a version
client.add_data(visitor_code, [Browser::new(BrowserKind::Chrome, None)])?;
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.
| Nom | Type | Description | Défaut |
|---|
| goal_id (requis) | u32 | ID de l’objectif. | |
| revenue (optionnel) | f32 | Revenu de la conversion | 0 |
| negative (optionnel) | bool | Définit si le revenu est positif ou négatif. | false |
| metadata (optionnel) | Vec<CustomData> | Métadonnées de la conversion. | vec![] |
use kameleoon_client::data::{Conversion, ConversionOpts, CustomData};
// Add a simple conversion with ID 32
client.add_data(visitor_code, [Conversion::new(32)])?;
// Add conversion with ID 33 including revenue and marked as negative
client.add_data(visitor_code, [Conversion::new_with_opts(33, ConversionOpts::new().revenue(10.0).negative(true))])?;
// Add conversion with ID 34 including revenue, negative flag, and custom metadata
client.add_data(
visitor_code,
[
Conversion::new_with_opts(
34,
ConversionOpts::new().revenue(10.0).negative(true).metadata(vec![
CustomData::new(3, vec!["metadata1".to_owned(), "md2".to_owned()]),
CustomData::new(5, vec!["md3".to_owned()]),
]),
)
],
)?;
Cookie
Cookie contient des informations sur les cookies stockés sur l’appareil du visiteur.
| Nom | Type | Description |
|---|
| cookies | HashMap<String, String> | Une carte de chaînes contenant des clés et des valeurs de cookies. |
Chaque visiteur ne peut avoir qu’un seul Cookie. L’ajout d’un second Cookie écrase le premier.
use std::collections::HashMap;
use kameleoon_client::data::Cookie;
client.add_data(visitor_code, [Cookie::new(HashMap::from([("segment".to_owned(), "vip".to_owned())]))])?;
CustomData
CustomData permet l’association de tout type de données avec 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 ventilation dans les rapports d’expérience. Pour plus d’informations sur les données personnalisées, veuillez consulter cet article.
Définissez les types de données personnalisées dans l’application Kameleoon ou dans la Data API et utilisez-les depuis le SDK.
| Nom | Type | Description | Défaut |
|---|
| index/name (requis) | u32/String | Index ou nom des données personnalisées. Soit index, soit name doit être fourni pour identifier les données. | |
| values (requis) | Vec<String> | Valeurs des données personnalisées à stocker. | |
| overwrite (optionnel) | bool | Drapeau permettant de contrôler explicitement comment les valeurs sont stockées et comment elles apparaissent dans les rapports. Voir plus | true |
-
Chaque visiteur n’est autorisé qu’à une seule
CustomData pour chaque index(name) unique. L’ajout d’une autre CustomData avec le même index(name) remplacera celle existante.
-
L’« index » des données personnalisées 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 des données personnalisées.
-
L’ajout d’une instance de
CustomData créée avec un nom lorsque l’instance du SDK n’est pas initialisée ou que le nom n’est pas enregistré entraînera l’ignorance des données.
use kameleoon_client::data::{CustomData, CustomDataOpts};
client.add_data(visitor_code, [CustomData::new_with_index(1, vec!["value".to_owned()])])?;
// With several values
client.add_data(
visitor_code,
[CustomData::new_with_index(
1,
vec!["value1".to_owned(), "value2".to_owned()],
)],
)?;
// To set the `overwrite` flag to false
client.add_data(
visitor_code,
[CustomData::new_with_index_opts(
1,
vec!["value".to_owned()],
CustomDataOpts::new().overwrite(false),
)],
)?;
// To use a name instead of the index
client.add_data(
visitor_code,
[CustomData::new_with_name(
"my-custom-data".to_owned(),
vec!["value".to_owned()],
)],
)?;
// To use a name instead of the index and set the `overwrite` flag to false
client.add_data(
visitor_code,
[CustomData::new_with_name_opts(
"my-custom-data",
vec!["value".to_owned()],
CustomDataOpts::new().overwrite(false),
)],
)?;
Device
Vous pouvez utiliser les données d’appareil pour filtrer les rapports d’expérience et de personnalisation par toute valeur associée.
| Nom | Type | Description |
|---|
| kind | DeviceKind | Type d’appareil. Les valeurs possibles sont Phone, Tablet et Desktop. |
use kameleoon_client::data::{Device, DeviceKind};
client.add_data(visitor_code, [Device::new(DeviceKind::Desktop)])?;
Geolocation
Geolocation contient les détails de géolocalisation du visiteur.
| Nom | Type | Description |
|---|
| country (requis) | &str | Le pays du visiteur. |
| region (optionnel) | Option<String> | La région du visiteur. |
| city (optionnel) | Option<String> | La ville du visiteur. |
| postal_code (optionnel) | Option<String> | Le code postal du visiteur. |
| latitude (optionnel) | Option<f32> | La coordonnée de latitude représentant l’emplacement du visiteur. Le nombre de coordonnées représente des degrés décimaux. |
| longitude (optionnel) | Option<f32> | La coordonnée de longitude représentant l’emplacement du visiteur. Le nombre de coordonnées représente des degrés décimaux. |
- Chaque visiteur ne peut avoir qu’une seule
Geolocation. L’ajout d’une seconde Geolocation écrase la première.
use kameleoon_client::data::GeolocationBuilder;
let geolocation = GeolocationBuilder::default()
.country("France")
.region("Ile-de-France".to_owned())
.city("Paris".to_owned())
.postal_code("75009".to_owned())
.latitude(48.8720171)
.longitude(2.3338352)
.build()
.unwrap();
client.add_data(visitor_code, [geolocation])?;
OperatingSystem
OperatingSystem contient des informations sur le système d’exploitation de l’appareil du visiteur.
| Nom | Type | Description |
|---|
| kind | OperatingSystemKind | Famille de système d’exploitation. Les valeurs possibles sont Windows, Mac, IOS, Linux, Android et WindowsPhone. |
Chaque visiteur ne peut avoir qu’un seul OperatingSystem. L’ajout d’un second OperatingSystem écrase le premier.
use kameleoon_client::data::{OperatingSystem, OperatingSystemKind};
client.add_data(visitor_code, [OperatingSystem::new(OperatingSystemKind::Windows)])?;
PageView
Stocke les événements de page vue.
| Nom | Type | Description | Défaut |
|---|
| url | String | URL de la page consultée. | |
| title | Option<String> | Titre de la page consultée. | None |
| referrers | Vec<u32> | Index de referrer des pages précédemment consultées. | vec![] |
L’index de referrer est disponible dans l’application Kameleoon sur la page de configuration du canal d’acquisition. Attention : l’index commence à 0, donc le premier canal d’acquisition que vous créez a l’ID 0, et non 1.
use kameleoon_client::data::{PageView, PageViewOpts};
// new() - full constructor with url, optional title, and referrers
client.add_data(visitor_code, [PageView::new("https://example.com", Some("Homepage"), vec![3])])?;
// new_with_url() - minimal constructor, only requires a URL
client.add_data(visitor_code, [PageView::new_with_url("https://example.com")])?;
// new_with_opts() - constructor using PageViewOpts builder for optional fields
let opts = PageViewOpts::builder().title("Homepage").referrers(vec![3]).build();
client.add_data(visitor_code, [PageView::new_with_opts("https://example.com", opts)])?;
UniqueIdentifier
Si vous n’ajoutez pas de 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(true), le SDK lie les données envoyées avec le visiteur associé à l’identifiant spécifié.
Cela peut être utile dans les 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.
| Nom | Type | Description |
|---|
value | bool | Si le visitor_code actuel doit être traité comme un identifiant unique. |
use kameleoon_client::data::UniqueIdentifier;
client.add_data(visitor_code, [UniqueIdentifier::new(true)])?;
UserAgent
Les expériences côté serveur sont plus susceptibles d’être affectées par le trafic de bots que les expériences côté client. Kameleoon utilise la liste IAB/ABC International Spiders and Bots pour reconnaître les bots et spiders connus, et utilise également le champ UserAgent pour filtrer d’autres trafics indésirables susceptibles de 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.
| Nom | Type | Description |
|---|
| value | String | Valeur User-Agent envoyée avec les requêtes de tracking. |
use kameleoon_client::data::UserAgent;
client.add_data(visitor_code, [UserAgent::new("Mozilla/5.0")])?;
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 souhaitent. Si vous avez besoin de plus de détails, veuillez contacter votre Customer Success Manager.
| Nom | Type | Description |
|---|
| feature_flags | HashMap<String, FeatureFlag> | Une carte d’objets FeatureFlag, indexés par clés de feature flag. |
| date_modified | i64 | L’horodatage (en millisecondes) indiquant la dernière modification du DataFile. |
// Retrieves the map of feature flags from the DataFile.
// The map is keyed by feature flag identifiers, with each value being a FeatureFlag object.
let feature_flags: &HashMap<String, FeatureFlag> = &datafile.feature_flags;
// Retrieves the last modification timestamp of the DataFile.
// The value is an i64 representing milliseconds since the Unix epoch.
let date_modified: i64 = datafile.date_modified;
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, son statut d’environnement et d’autres détails connexes.
Il peut être étendu avec des informations supplémentaires si les clients le souhaitent. Si vous avez besoin de plus de détails, veuillez contacter votre Customer Success Manager.
| Nom | Type | Description |
|---|
| environment_enabled | bool | Indique si le feature flag est activé dans l’environnement actuel. |
| default_variation_key | &str | La clé de la variation par défaut associée au feature flag. |
| variations | HashMap<String, Variation> | Une carte d’objets Variation, indexés par clés de variation. |
| rules | Vec<Rule> | Une liste d’objets Rule |
// Check whether the feature flag is enabled in the current environment.
let environment_enabled: bool = feature_flag.environment_enabled;
// Retrieve the key of the default variation.
let default_variation_key: &String = &feature_flag.default_variation_key;
// Retrieve the default variation object.
let default_variation: &Variation = feature_flag.default_variation();
// Retrieve all variations of the feature flag as a map (key = variation key, value = Variation object).
let variations: &HashMap<String, Variation> = &feature_flag.variations;
// Retrieve all targeting rules associated with the feature flag.
let rules: &Vec<Rule> = &feature_flag.rules;
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 souhaitent. Si vous avez besoin de plus de détails, veuillez contacter votre Customer Success Manager.
| Nom | Type | Description |
|---|
| variations | HashMap<String, Variation> | Une carte d’objets Variation, indexés par clés de variation. |
// Retrieve all variations of the rule as a map (key = variation key, value = Variation object)
let variations = &rule.variations;
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.
| Nom | Type | Description |
|---|
| name | String | Le nom de la variation. |
| key | String | La clé unique identifiant la variation. |
| id | Option<u32> | L’ID de la variation attribuée, ou None pour une variation par défaut. |
| experiment_id | Option<u32> | L’ID de l’expérience associée à la variation, ou None pour une variation par défaut. |
| variables | Vec<Variable> | Variables associées à la variation. Cette collection peut être vide lorsqu’aucune variable n’est attachée. |
Variation décrit la variation attribuée ou par défaut, tandis que Variable contient les détails de chaque variable individuelle.
id et experiment_id peuvent être None, ce qui indique une variation par défaut qui n’est pas liée à une attribution d’expérience spécifique.
Méthodes utilitaires supplémentaires :
| Méthode | Type de retour | Description |
|---|
is_active() | bool | Renvoie false pour la variation off. |
get_variable(key) | Option<&Variable> | Renvoie une variable de variation par clé. |
// Retrieving the variation name
let variation_name = &variation.name;
// Retrieving the variation key
let variation_key = &variation.key;
// Retrieving the variation id
let variation_id = variation.id;
// Retrieving the experiment id
let experiment_id = variation.experiment_id;
// Retrieving the variables `Vec`
let variables = &variation.variables;
// Checking if the variation is active (i.e., currently being served to visitors)
let is_active = variation.is_active();
// Retrieving a variable by its key, returning `None` if not found
let variable = variation.get_variable("title")?;
Variable
Variable contient des informations sur une variable associée à la variation attribuée.
| Nom | Type | Description |
|---|
| key | String | La clé unique identifiant la variable. |
| kind | String | Le type de variable. Les valeurs possibles incluent BOOLEAN, NUMBER, STRING, JSON, JS et CSS. |
| value | JsonValue | La valeur de la variable. Selon kind, elle peut contenir un booléen, un nombre, une chaîne, une chaîne JSON, un extrait JavaScript ou un extrait CSS. |
use kameleoon_client::types::JsonValue;
// Retrieve the list of variables associated with the variation
let variables = &variation.variables;
// Access the variable type (kind) for conditional handling
let kind = &variable.kind;
// Extract the value as a number (returns `None` if not a number)
let number: Option<f64> = variable.value.as_number();
// Extract the value as a boolean (returns `None` if not a boolean)
let apply_discount: Option<bool> = variable.value.as_bool();
// Extract the value as a string slice (returns `None` if not a string)
let title: Option<&str> = variable.value.as_str();
JsonValue
JsonValue représente la valeur d’une variable de variation en Rust.
| Valeur | Description |
|---|
JsonValue::Boolean(bool) | Représente une valeur booléenne. |
JsonValue::Number(f64) | Représente une valeur numérique. |
JsonValue::String(String) | Représente une valeur de chaîne. |
JsonValue::Json(String) | Représente une valeur encodée en JSON. |
JsonValue::Js(String) | Représente un extrait de code JavaScript. |
JsonValue::Css(String) | Représente un extrait de code CSS. |
Méthodes dépréciées
Ces méthodes sont dépréciées et seront supprimées dans la version 1.0.0 du SDK.
get_feature_keys()
Renvoie une liste des clés de feature flag actuellement disponibles pour le SDK.
let feature_keys = client.get_feature_keys()?;
Valeur de retour
| Type | Description |
|---|
Result<Vec<String>, KameleoonError> | Liste des clés de feature flag en cas de succès, sinon une erreur. |
Erreurs
| Type | Description |
|---|
ErrorCode::Initialization | Indique que le SDK n’est pas encore entièrement initialisé. |