Avec le SDK Java Kameleoon, vous pouvez exécuter des expériences et activer des feature flags sur votre serveur d’applications Java EE / Jakarta EE.
Premiers pas : Pour obtenir de l’aide afin de démarrer, consultez le guide du développeur
Changelog : Dernière version du SDK Java : 4.19.0 Changelog.
Méthodes du SDK : Pour la documentation de référence complète du SDK Java, consultez la section référence.
Developer guide
Ce guide est conçu pour vous aider à intégrer notre SDK en quelques minutes et à commencer à exécuter des expériences dans vos applications Java.
Getting started
Starter kit
Pour faciliter la prise en main, Kameleoon fournit un starter kit et une application de démonstration permettant de tester le SDK. Le starter kit inclut une application entièrement configurée avec des exemples illustrant l’utilisation des méthodes du SDK dans une application. Le starter kit, l’application de démonstration et les instructions détaillées sont disponibles sur Starter kit for Java
Install the Java client
Le package d’installation est disponible sur le dépôt Maven Central. Vous pouvez installer le SDK Java en ajoutant une dépendance dans le fichier pom.xml de votre projet, comme illustré dans l’exemple ci-contre. Si vous utilisez un autre système de gestion de projet, consultez la page integrations pour obtenir des exemples supplémentaires.
<dependency>
<groupId>com.kameleoon</groupId>
<artifactId>kameleoon-client-java</artifactId>
<version>4.16.0</version>
</dependency>
<dependency>
<groupId>com.kameleoon</groupId>
<artifactId>kameleoon-client-java-jakarta</artifactId>
<version>4.16.0</version>
</dependency>
Additional configuration
Créez un fichier de configuration .properties pour fournir les identifiants et personnaliser le comportement du SDK. Vous pouvez également télécharger notre exemple de fichier de configuration.
Nous vous recommandons d’enregistrer ce fichier à l’emplacement par défaut, /etc/kameleoon/client-java.conf, mais vous pouvez l’enregistrer n’importe où dans le classpath sous le nom kameleoon-client-java.properties.
Le tableau suivant présente les propriétés disponibles que vous pouvez définir :
| Clé | Description | Valeur par défaut |
|---|
clientId / client_id (obligatoire) | Requis pour l’authentification auprès du service Kameleoon. Pour trouver votre client_id, consultez la documentation API credentials. | |
clientSecret / client_secret (obligatoire) | Requis pour l’authentification auprès du service Kameleoon. Pour trouver votre client_secret, consultez la documentation API credentials. | |
sessionDuration / session_duration_minute (optionnel) | Désigne l’intervalle de temps prédéfini pendant lequel Kameleoon conserve le visiteur et ses données associées en mémoire (RAM). Notez que l’augmentation de la durée de session augmente la quantité de RAM à allouer pour stocker les données des visiteurs. | 30 minutes |
refreshInterval / refresh_interval_minute (optionnel) | Spécifie l’intervalle de rafraîchissement, en minutes, durant lequel le SDK récupère la configuration des expériences actives et des feature flags. La valeur détermine le temps maximum nécessaire pour propager les changements, tels que l’activation ou la désactivation des feature flags ou le lancement d’expériences, vers vos serveurs de production. De plus, nous proposons un mode streaming qui utilise des server-sent events (SSE) pour pousser automatiquement les nouvelles configurations vers le SDK et appliquer les nouvelles configurations en temps réel, sans aucun délai. | 60 minutes |
defaultTimeout / default_timeout_millisecond (optionnel) | Spécifie le délai d’expiration, en millisecondes, pour les requêtes réseau du SDK. Définissez la valeur à 30 secondes ou plus si vous n’avez pas une connexion stable. Certaines méthodes disposent d’un paramètre supplémentaire que vous pouvez utiliser pour remplacer le délai d’expiration par défaut pour cette méthode spécifique. Si vous ne spécifiez pas explicitement le délai d’expiration pour une méthode, le SDK utilise cette valeur par défaut. | 10000 millisecondes |
trackingInterval / tracking_interval_millisecond (optionnel) | Spécifie l’intervalle pour les requêtes de tracking en millisecondes. Tous les visiteurs que Kameleoon a évalués pour un feature flag ou dont les données ont été flushées sont inclus dans cette requête de tracking, que le SDK exécute une fois par intervalle. La valeur minimale est 1000 ms, qui est également la valeur par défaut, et la valeur maximale est 5000 ms. | 1000 millisecondes |
environment / environment (optionnel) | Environnement à partir duquel la configuration du feature flag doit être utilisée. La valeur peut être production, staging, development. Consultez l’article managing environments pour plus de détails. | production |
topLevelDomain / top_level_domain (obligatoire en mode hybride) | Le domaine de premier niveau actuel pour votre site web. Utilisez le format : example.com. N’incluez pas https://, www ou d’autres sous-domaines. Kameleoon utilise cette information pour définir le cookie correspondant sur le domaine de premier niveau. | null |
proxyHost / proxy_host (optionnel) | Définit le proxy host pour tous les appels serveur sortants effectués par le SDK. | null |
networkDomain / network_domain (optionnel) | Domaine personnalisé utilisé par les SDKs 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 reviennent à la valeur par défaut de Kameleoon. | null |
Initialize the Kameleoon client
Après avoir installé le SDK dans votre application et configuré vos identifiants et le comportement du SDK (dans /etc/kameleoon/client-java.conf), l’étape suivante consiste à créer le client Kameleoon dans le code de votre application. Par exemple :
import com.kameleoon.KameleoonClientFactory;
String siteCode = "a8st4f59bj";
try {
KameleoonClient kameleoonClient = KameleoonClientFactory.create(siteCode, "custom/file/path/client-java.properties");
} catch (KameleoonException.SiteCodeIsEmpty e) {
// indicates that provided site code is empty
} catch (KameleoonException.ConfigCredentialsInvalid exception) {
// indicates that provided clientId / clientSecret are not valid
}
try {
KameleoonClientConfig config = new KameleoonClientConfig.Builder()
.clientId("<clientId>") // mandatory
.clientSecret("<clientSecret>") // mandatory
.refreshInterval(60) // in minutes, optional (60 minutes by default)
.sessionDuration(30) // in minutes, optional (30 minutes by default)
.defaultTimeout(10_000) // in milliseconds, optional (10000 ms by default)
.trackingInterval(1000) // in milliseconds, optional (1000 ms by default)
.topLevelDomain("example.com") // mandatory if you use hybrid mode (engine or web experiments)
.environment("development") // optional
.proxyHost(new HttpHost("192.168.0.25", 8080, "http")) // optional
.networkDomain("example.com") // optional
.build();
KameleoonClientFactory.create(siteCode, config);
} catch (KameleoonException.SiteCodeIsEmpty e) {
// indicates that provided site code is empty
} catch (KameleoonException.ConfigCredentialsInvalid exception) {
// indicates that provided clientId / clientSecret are not valid
}
Un KameleoonClient est un objet singleton qui sert de passerelle entre votre application et la plateforme Kameleoon. Il inclut toutes les méthodes et propriétés nécessaires pour exécuter une expérience. Notez que nous prenons également en charge l’utilisation d’un proxy HTTP dans le SDK Java (voir la référence de la méthode create() pour plus de détails).
Il est de votre responsabilité d’assurer la logique appropriée du code de votre application dans le contexte de l’A/B test via Kameleoon. Une bonne pratique consiste à toujours supposer que vous pouvez exclure le visiteur actuel de l’expérience si vous n’avez pas lancé l’expérience. Cette exclusion est simple car elle correspond à l’implémentation de la logique de variation par défaut et de référence.
Vous êtes maintenant prêt à commencer à créer et à mettre en œuvre des expériences et du feature flagging.
Activating a feature flag
Assigning a unique ID to a user
Pour attribuer un ID unique à un utilisateur, vous pouvez utiliser la méthode getVisitorCode(). Si un visitor code n’existe pas (à partir du cookie d’en-têtes de requête), la méthode génère un ID unique aléatoire ou utilise un defaultVisitorCode que vous auriez généré. L’ID est ensuite défini dans un cookie d’en-têtes de réponse.
Si vous utilisez Kameleoon en Hybrid mode, appeler la méthode getVisitorCode() garantit que l’ID unique (visitor code) est partagé entre le fichier d’application engine.js (anciennement nommé kameleoon.js) et le SDK.
Retrieving a flag configuration
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éthode getVariation() ou isFeatureActive() pour récupérer la configuration en fonction de la featureKey.
La méthode getVariation() 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 assignant la variation et en la renvoyant en fonction de la featureKey et du visitorCode.
La méthode isFeatureActive() 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 possède des variables associées (comme des comportements spécifiques liés à chaque variation), getVariation() vous permet également d’accéder à l’objet Variation, qui fournit des détails sur la variation assignée et son expérience associée. Cette méthode vérifie si l’utilisateur est ciblé, trouve la variation assignée au visiteur et la sauvegarde dans le stockage. Lorsque track=true, le SDK enverra l’événement d’exposition à l’expérience spécifiée lors de la prochaine requête de tracking, qui est déclenchée automatiquement en fonction du tracking_interval_millisecond du SDK. Par défaut, cet intervalle est défini à 1000 millisecondes (1 seconde).
La méthode getVariation() 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 getVariations(), 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
Adding data points to target a user or filter / breakdown visits in reports
Pour cibler un utilisateur, assurez-vous d’avoir ajouté les points de données pertinents à son profil avant de récupérer la variation du feature ou de vérifier si le flag est actif. Utilisez la méthode addData() 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 utilisateur passées (collectées côté client lors de l’utilisation de Kameleoon en mode hybride), utilisez la méthode getRemoteVisitorData(). Cette méthode récupère de manière asynchrone les données depuis les serveurs. Il est important d’appeler getRemoteVisitorData() 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 assigner 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 décomposer vos résultats par facteurs tels que l’appareil et le navigateur. Le mode hybride de Kameleoon collecte automatiquement une variété de 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. Voir la liste complète ici.
Si vous devez suivre des points de données supplémentaires au-delà de ce qui est collecté automatiquement, vous pouvez utiliser la fonctionnalité Custom Data de Kameleoon. Custom Data vous permet de capturer et d’analyser des informations spécifiques pertinentes pour vos expériences. N’oubliez pas d’appeler la méthode flush() pour envoyer les données collectées aux serveurs Kameleoon pour analyse.
Pour garantir l’exactitude de vos résultats, il est recommandé de filtrer les bots en utilisant le type de données UserAgent.
Tracking goal conversions
Lorsqu’un utilisateur effectue une action souhaitée (telle qu’effectuer un achat), elle est enregistrée comme une conversion. Pour suivre les conversions, utilisez la méthode trackConversion() et fournissez les paramètres requis visitorCode et goalId.
La requête de tracking de conversion sera envoyée avec la prochaine requête de tracking planifiée, que le SDK envoie à intervalles réguliers (définis par tracking_interval_millisecond). Si vous préférez envoyer la requête immédiatement, utilisez la méthode flush() avec le paramètre instant=true.
Sending events to analytics solutions
Pour suivre les conversions et envoyer des événements d’exposition à votre solution d’analytique client, vous devez d’abord implémenter Kameleoon en Hybrid mode. Ensuite, utilisez la méthode getEngineTrackingCode().
La méthode getEngineTrackingCode() récupère le code de tracking unique requis pour envoyer des événements d’exposition à votre solution d’analytique. Utiliser cette méthode vous permet d’enregistrer des événements et de les envoyer à la plateforme d’analytique de votre choix.
Using a custom bucketing key
Par défaut, Kameleoon utilise un ID de visiteur unique et anonyme (visitorCode) pour assigner les utilisateurs aux variations de feature flag. Cet ID est généralement généré et stocké sur l’appareil de l’utilisateur (dans un cookie de navigateur pour les SDKs côté client et côté serveur — dans le stockage persistant pour les SDKs mobiles). Cependant, dans certains scénarios, vous devrez peut-être garantir que tous les utilisateurs d’une même organisation voient la même variante d’un feature flag.
L’option Custom Bucketing Key vous permet de remplacer ce comportement par défaut en fournissant votre propre identifiant personnalisé pour le bucketing. Ce remplacement garantit que la logique d’assignation de Kameleoon utilise votre clé spécifiée au lieu du visitorCode par défaut.
Use cases
L’utilisation d’une custom bucketing key est essentielle pour maintenir la cohérence et l’exactitude de vos assignations de feature flag, en particulier dans les situations suivantes :
- Expériences au niveau du compte ou de l’organisation : Pour les produits B2B ou les scénarios dans lesquels vous souhaitez assigner tous les utilisateurs d’une même organisation à la même variation, vous pouvez utiliser un identifiant tel qu’un
accountId. Les custom bucketing keys sont essentielles pour les fonctionnalités d’A/B test qui ont un impact sur toute une équipe ou une entreprise.
En implémentant une custom bucketing key, vous garantissez une plus grande cohérence et exactitude dans vos expériences, ce qui conduit à des résultats plus fiables et à une meilleure expérience utilisateur.
Technical details
Lorsque vous configurez une custom bucketing key pour un feature flag, vous fournissez à Kameleoon un identifiant spécifique provenant des données de votre application :
kameleoonClient.addData(visitorCode, new CustomData(index, "newVisitorCode"));
- Fournir la clé personnalisée : Vous fournissez votre identifiant personnalisé au SDK Kameleoon à l’aide de la méthode
addData(). Dans cette méthode, vous passerez votre custom bucketing key choisie en tant qu’objet CustomData. Ici, newVisitorCode fait référence à l’identifiant que vous souhaitez utiliser pour votre bucketing (par exemple, le nouveau userId ou accountId).
Pour que la custom bucketing key fonctionne correctement, elle doit également être définie et configurée pour le feature flag lors du processus de création ou d’édition 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 façon de configurer cela dans Kameleoon, reportez-vous à cet article.
- Logique de bucketing : Une fois qu’une custom bucketing key est fournie via la méthode
addData(), tous les calculs de hash pour assigner les utilisateurs aux variations utiliseront ce newVisitorCode (votre clé personnalisée) au lieu du visitorCode par défaut. Utiliser le newVisitorCode signifie que la décision de bucketing est liée à votre identifiant personnalisé, garantissant des assignations cohérentes dans divers contextes où cet identifiant est présent.
- Tracking de données et analytique : Il est crucial de noter que bien que le
newVisitorCode (votre clé personnalisée) soit utilisé pour les décisions de bucketing, toutes les données ultérieures (événements de tracking et conversions, par exemple) sont envoyées et associées au visitorCode original. Cette séparation garantit que votre analytique reflète 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 de visiteur originales restent intactes pour un reporting complet.
Technical requirementes
Pour utiliser efficacement une custom bucketing key :
- La clé doit être une
String.
- Elle doit être unique pour l’entité que vous avez l’intention de bucketer (par exemple, si vous utilisez un
userId, l’ID de chaque utilisateur doit être unique).
- La clé doit être disponible pour le SDK au moment exact où la décision de feature flag est évaluée pour cet utilisateur ou cette requête.
Targeting conditions
Les SDKs 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 use visit history to target users.
Vous pouvez également utiliser vos propres données externes pour cibler les utilisateurs.
Cross-device experimentation
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 sur tous les appareils grâce à la cross-device experimentation. Des études de cas et des informations détaillées sur la manière dont Kameleoon gère les données entre les appareils sont disponibles dans l’article sur la cross-device experimentation.
Synchronizing custom data across devices
Bien que la synchronisation du mapping personnalisé soit utilisée pour aligner les données des visiteurs entre les appareils, elle n’est pas toujours nécessaire. Voici deux scénarios où la synchronisation du mapping personnalisé n’est pas requise :
Même user ID sur tous les appareils
Si le même user ID est utilisé de manière cohérente sur tous les appareils, la synchronisation est gérée automatiquement sans synchronisation de mapping personnalisé. Il suffit d’appeler la méthode getRemoteVisitorData() lorsque vous souhaitez synchroniser les données collectées entre plusieurs appareils.
Instances multi-serveurs avec IDs cohérents
Dans des configurations complexes impliquant plusieurs serveurs (par exemple, des instances de serveurs distribués), où le même user ID est disponible sur les serveurs, la synchronisation entre les serveurs (avec getRemoteVisitorData()) est suffisante sans synchronisation supplémentaire de mapping personnalisé.
Les clients qui ont besoin de données supplémentaires peuvent se référer à la description de la méthode getRemoteVisitorData() pour obtenir des conseils supplémentaires. Dans le code ci-dessous, on suppose que le même identifiant unique (dans ce cas, le visitorCode, 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 custom data.
// In this example, a Custom data with index `90` was set to "Visitor" scope in Kameleoon.
final int VISITOR_SCOPE_CUSTOM_DATA_INDEX = 90;
kameleoonClient.addData(visitorCode, new CustomData(VISITOR_SCOPE_CUSTOM_DATA_INDEX, "your data"));
kameleoonClient.flush(visitorCode);
// Before working with the data, call the `getRemoteVisitorData` method.
kameleoonClient.getRemoteVisitorData(visitorCode).get();
// 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.
Using custom data for session merging
La cross-device experimentation permet de combiner l’historique d’un visiteur sur chacun de ses appareils (réconciliation de l’historique). La réconciliation de l’historique permet de fusionner différentes sessions de visiteurs en une seule. Pour réconcilier l’historique 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 à getRemoteVisitorData() avec le paramètre userId récupère toutes les données connues pour un utilisateur donné.
Les sessions avec le même identifiant verront toujours la même variation dans une expérience. Dans la vue Visitor des pages de résultats de votre expérience, ces sessions apparaîtront comme un seul visiteur.
La configuration du SDK garantit que les sessions associées voient toujours la même variation de l’expérience. Cependant, il existe certaines limitations concernant l’allocation de variation cross-device. Ces limitations sont décrites ici.
Suivez le guide activating cross-device history reconciliation pour configurer vos custom data sur la plateforme Kameleoon.
Par la suite, vous pouvez utiliser le SDK normalement. Les méthodes suivantes peuvent être utiles dans le contexte de la fusion de sessions :
getRemoteVisitorData() avec UniqueIdentifier(true) ajouté - pour récupérer les données de tous les visiteurs liés.
trackConversion() ou flush() avec des 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 des custom data pour la fusion de sessions.
// In this example, 91 represents the Custom Data's index configured as a unique identifier in Kameleoon.
final int MAPPING_INDEX = 91;
final String FEATURE_KEY = "ff123";
// 1. Before the visitor is authenticated
// Retrieve the variation for an unauthenticated visitor.
// Assume anonymousVisitorCode is the randomly generated ID for that visitor.
Variation anonymousVariation = kameleoonClient.getVariation(anonymousVisitorCode, FEATURE_KEY);
// 2. After the visitor is authenticated
// Assume `userId` is the visitor code of the authenticated visitor.
kameleoonClient.addData(anonymousVisitorCode, new CustomData(MAPPING_INDEX, userId));
kameleoonClient.flush(true, anonymousVisitorCode);
// Indicate that `userId` is a unique identifier.
kameleoonClient.addData(userId, new UniqueIdentifier(true));
// 3. After the visitor was authorized
// Retrieve the variation for the `userId`, which will match the anonymous visitor code's variation.
Variation userVariation = kameleoonClient.getVariation(userId, FEATURE_KEY);
boolean isSameVariation = userVariation.getKey().equals(anonymousVariation.getKey()); // true
// `userId` and `anonymousVisitorCode` are now linked and can be tracked as a single visitor.
kameleoonClient.trackConversion(userId, 123, 10.0);
// Additionally, the linked visitors share all fetched previously tracked remote data.
kameleoonClient.getRemoteVisitorData(userId).get();
Dans cet exemple, l’application possède une page de connexion. Étant donné que l’user ID est inconnu au moment de la connexion, un identifiant de visiteur anonyme généré par la méthode getVisitorCode() est utilisé. Une fois que l’utilisateur s’est connecté, le visiteur anonyme est associé à l’user ID et utilisé comme identifiant unique pour le visiteur.
Logging
Le SDK génère des logs pour refléter divers processus et problèmes internes.
Log levels
Le SDK prend en charge la configuration de la limitation du logging par un log level.
// The `NONE` log level does not allow logging.
com.kameleoon.logging.KameleoonLogger.setLogLevel(com.kameleoon.logging.LogLevel.NONE);
// The `ERROR` log level only allows logging issues that may affect the SDK's primary behaviour.
com.kameleoon.logging.KameleoonLogger.setLogLevel(com.kameleoon.logging.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.
com.kameleoon.logging.KameleoonLogger.setLogLevel(com.kameleoon.logging.LogLevel.WARNING);
// The `INFO` log level allows logging general information on the SDK's internal processes.
// It extends the `WARNING` log level.
com.kameleoon.logging.KameleoonLogger.setLogLevel(com.kameleoon.logging.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.
com.kameleoon.logging.KameleoonLogger.setLogLevel(com.kameleoon.logging.LogLevel.DEBUG);
Custom handling of logs
Le SDK écrit ses logs dans la sortie console par défaut. Ce comportement peut être remplacé.
La limitation des logs par un log level est effectuée indépendamment de la logique de gestion des logs.
public class CustomLogger implements com.kameleoon.logging.Logger {
private final java.util.logging.Logger inner;
public CustomLogger(java.util.logging.Logger inner) {
this.inner = inner;
}
// `log` method accepts logs from the SDK
@Override
public void log(com.kameleoon.logging.LogLevel level, String message) {
// Custom log handling logic here. For example:
switch (level) {
case ERROR:
inner.log(java.util.logging.Level.SEVERE, message);
break;
case WARNING:
inner.log(java.util.logging.Level.WARNING, message);
break;
case INFO:
inner.log(java.util.logging.Level.INFO, message);
break;
case DEBUG:
inner.log(java.util.logging.Level.FINE, message);
break;
}
}
}
// 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.
com.kameleoon.logging.KameleoonLogger.setLogLevel(com.kameleoon.logging.LogLevel.DEBUG); // Optional; defaults to `LogLevel.WARNING`.
com.kameleoon.logging.KameleoonLogger.setLogger(new CustomLogger());
Reference
Voici la documentation de référence complète pour le SDK Java.
Initialization
create()
Pour utiliser le SDK, vous devez terminer l’initialisation. Votre application effectue toutes les interactions avec le SDK via un objet de la classe KameleoonClient. Créez cet objet à l’aide de la méthode statique create() dans KameleoonClientFactory.
import com.kameleoon.KameleoonClientFactory;
String siteCode = "a8st4f59bj";
try {
KameleoonClient kameleoonClient = KameleoonClientFactory.create(siteCode, "custom/file/path/client-java.properties");
} catch (KameleoonException.SiteCodeIsEmpty e) {
// indicates that provided site code is empty
} catch (KameleoonException.ConfigCredentialsInvalid exception) {
// indicates that provided clientId / clientSecret are not valid
}
try {
KameleoonClientConfig config = new KameleoonClientConfig.Builder()
.clientId("<clientId>") // mandatory
.clientSecret("<clientSecret>") // mandatory
.refreshInterval(60) // in minutes, optional (60 minutes by default)
.sessionDuration(30) // in minutes, optional (30 minutes by default)
.defaultTimeout(10_000) // in milliseconds, optional (10000 ms by default)
.trackingInterval(1000) // in milliseconds, optional (1000 ms by default)
.topLevelDomain("example.com") // mandatory if you use hybrid mode (engine or web experiments)
.environment("development") // optional
.proxyHost(new HttpHost("192.168.0.25", 8080, "http")) // optional
.networkDomain("example.com") // optional
.build();
KameleoonClientFactory.create(siteCode, config);
} catch (KameleoonException.SiteCodeIsEmpty e) {
// indicates that provided site code is empty
} catch (KameleoonException.ConfigCredentialsInvalid exception) {
// indicates that provided clientId / clientSecret are not valid
}
Arguments
| Nom | Type | Description | Valeur par défaut |
|---|
| siteCode (obligatoire) | String | Il s’agit d’une clé unique du projet Kameleoon que vous utilisez avec le SDK. | |
| configurationPath (optionnel) | String | Chemin vers le fichier de configuration du SDK. | /etc/kameleoon/client-java.conf |
| kameleoonConfig (optionnel) | KameleoonClientConfig | Objet de configuration du SDK que vous pouvez passer au lieu d’utiliser un fichier de configuration. | null |
Return value
| Type | Description |
|---|
KameleoonClient | Une instance de la classe KameleoonClient que votre application peut ensuite utiliser pour gérer vos expériences et feature flags. |
Exceptions thrown
| Type | Description |
|---|
| KameleoonException.ConfigCredentialsInvalid | Exception indiquant que les identifiants requis n’ont pas été fournis (ni dans le fichier de configuration, ni en tant qu’arguments de la méthode). |
| KameleoonException.SiteCodeIsEmpty | Exception indiquant que le site code spécifié est une chaîne vide, ce qui est une valeur invalide. |
waitInit()
waitInit() attend l’initialisation du KameleoonClient. Cette méthode vous permet de vérifier si le SDK a initialisé le client avec succès avant de procéder à d’autres opérations.
Si la méthode waitInit() échoue, le processus d’initialisation se poursuivra sans interruption. Les appels ultérieurs à la méthode waitInit() renverront des résultats reflétant l’état actuel du KameleoonClient. Ainsi, vous pouvez invoquer la méthode waitInit() plusieurs fois pour vérifier l’état du SDK.
// Synchronized approach
try {
kameleoonClient.waitInit().get();
} catch (InterruptedException | ExecutionException exception) {
// Indicates that the client could not be initialized due to the thrown exception.
}
// Asynchronous approach
kameleeoonClient.waitInit().handle((res, ex) -> {
if (ex != null) {
// Indicates that the client could not be initialized due to the thrown exception.
}
return res;
});
Return value
| Type | Description |
|---|
CompletableFuture<Void> | La tâche se termine lorsque le client a été initialisé avec succès. |
Exceptions thrown
| Type | Description |
|---|
| SDKNotReady | Exception indiquant que le client n’est pas correctement initialisé et ne peut pas encore être utilisé. |
Feature flags and variations
isFeatureActive()
- 📨 Envoie des données de tracking à Kameleoon (selon le paramètre
track)
Cette méthode s’appelait auparavant activeFeature, qui a été supprimée dans la version 4.0.0 du SDK.
Appelez cette méthode pour vérifier si un feature flag doit être actif pour un utilisateur spécifié. Cette méthode prend un visitorCode et une featureKey comme arguments obligatoires pour vérifier si le feature est actif pour l’utilisateur.
Si l’utilisateur n’a jamais été associé à ce feature flag, le SDK renvoie une valeur booléenne aléatoire (soit true pour ajouter l’utilisateur à ce feature, soit false pour l’exclure du feature). Si un utilisateur avec le visitorCode spécifié est déjà enregistré avec ce feature flag, le SDK détecte la valeur précédente de featureFlag.
Assurez-vous de capturer et de gérer les exceptions potentielles.
Si vous spécifiez un visitorCode, la méthode isFeatureActive() l’utilise comme identifiant unique du visiteur, ce qui est utile pour la cross-device experimentation. Lorsque vous spécifiez un visitorCode et définissez le paramètre isUniqueIdentifier à true, le SDK lie les données flushées au visiteur associé à l’identifiant spécifié.
Le paramètre isUniqueIdentifier est obsolète. Veuillez utiliser UniqueIdentifier à la place.Le isUniqueIdentifier peut être utile dans des situations particulières ; par exemple, si vous ne pouvez pas accéder au visitorCode anonyme attribué à un visiteur, mais que vous pouvez utiliser un ID interne lié à ce visiteur via la fusion de sessions.
String visitorCode = kameleoonClient.getVisitorCode(httpServletRequest, httpServletResponse);
String featureKey = "new_checkout";
Boolean hasNewCheckout = false;
try {
hasNewCheckout = kameleoonClient.isFeatureActive(visitorCode, featureKey);
// disabling tracking
hasNewCheckout = kameleoonClient.isFeatureActive(false, visitorCode, featureKey);
} catch (KameleoonException.FeatureNotFound e) {
// Feature toggle not yet activated on Kameleoon's side - we consider the feature inactive.
hasNewCheckout = false;
} catch (Exception e) {
// This is a generic exception handler that handles all exceptions.
System.out.println("Exception occurred");
}
if (hasNewCheckout)
{
// Implement new checkout code here
}
Arguments
| Nom | Type | Description |
|---|
| track | boolean | Un paramètre optionnel pour activer ou désactiver le tracking de l’évaluation du feature (true par défaut). |
| visitorCode | String | Identifiant unique de l’utilisateur. Ce champ est obligatoire. |
| featureKey | String | Clé du feature dont vous souhaitez vérifier le statut pour l’utilisateur. Ce champ est obligatoire. |
| isUniqueIdentifier (Deprecated) | boolean | Un paramètre optionnel pour spécifier si le visitorCode est un identifiant unique. S’il n’est pas fourni, la valeur par défaut est false. Le champ est optionnel. |
Return value
| Type | Description |
|---|
boolean | Valeur du feature qui est enregistrée pour le visitorCode spécifié. |
Exceptions thrown
| Type | Description |
|---|
| KameleoonException.FeatureNotFound | Exception indiquant que l’ID de feature demandé n’a pas été trouvé dans la configuration interne du SDK. Cette exception signifie généralement que le feature flag n’a pas encore été activé du côté de Kameleoon (mais que le code qui implémente le feature est déjà déployé dans l’application). |
| KameleoonException.VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide. Il est soit vide, soit plus long que 255 caractères. |
getVariation()
- 📨 Envoie des données de tracking à Kameleoon (selon le paramètre
track)
Récupère la Variation assignée à un visiteur donné pour un feature flag spécifique.
Cette méthode prend un visitorCode et une featureKey comme arguments obligatoires. L’argument track est optionnel et vaut true par défaut.
Elle renvoie la Variation assigné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 fait référence à la variation assignée à un visiteur lorsqu’il ne correspond à aucune règle de delivery prédéfinie pour un feature flag. En d’autres termes, c’est la variation de repli appliquée à tous les utilisateurs qui ne sont pas ciblés par des règles spécifiques. Elle est représentée comme la variation dans la section “Then, for everyone else…” d’une interface de gestion.
String visitorCode = kameleoonClient.getVisitorCode(httpServletRequest, httpServletResponse);
String featureKey = "new_checkout";
Variation variation;
try {
variation = kameleoonClient.getVariation(visitorCode, featureKey);
// disabling tracking
variation = kameleoonClient.getVariation(visitorCode, featureKey, false);
} catch (KameleoonException.FeatureNotFound e) {
// The error has occurred; the feature flag isn't found in the current configuration.
} catch (KameleoonException.FeatureEnvironmentDisabled e) {
// The feature flag is disabled for the environment.
} catch (KameleoonException.VisitorCodeInvalid e) {
// The visitor code you passed to the method is invalid and can't be accepted by SDK.
} catch (KameleoonException ex) {
// Handle the common Kameleoon Exception
}
// Fetch a variable value for the assigned variation
String title = (String) variation.getVariables().get("title").getValue();
switch (variation.getKey()) {
case 'on':
// Main variation key is selected for visitorCode
break;
case 'alternative_variation':
// Alternative variation key
break;
default:
// Default variation key
break;
}
Arguments
| Nom | Type | Description | Défaut |
|---|
| visitorCode (obligatoire) | String | Identifiant unique du visiteur. | |
| featureKey (obligatoire) | String | Clé du feature que vous souhaitez exposer à un visiteur. | |
| track (optionnel) | boolean | Un paramètre optionnel pour activer ou désactiver le tracking de l’évaluation du feature. | true |
Return value
| Type | Description |
|---|
Variation | Une Variation assignée à un visiteur donné pour un feature flag spécifique. |
Exceptions thrown
| Type | Description |
|---|
VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide. Il est soit vide, soit plus long que 255 caractères. |
FeatureNotFound | Exception indiquant que la feature key 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). |
FeatureEnvironmentDisabled | Exception indiquant que le feature flag est désactivé pour l’environnement actuel du visiteur (par exemple, production, staging ou development). |
getVariations()
- 📨 Envoie des données de tracking à Kameleoon (selon le paramètre
track)
Récupère une map d’objets Variation assignés à un visiteur donné pour l’ensemble des feature flags.
Cette méthode itère sur tous les feature flags disponibles et renvoie la Variation assignée pour chaque flag associé au visiteur spécifié. Elle prend visitorCode comme argument obligatoire, tandis que onlyActive et track sont optionnels.
- Si
onlyActive est défini à true, la méthode getVariations() 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 assignations de variation. Par défaut, il est défini à true. S’il est défini à false, le tracking sera désactivé.
La map renvoyée est constituée des feature flag keys comme clés et de leurs Variation correspondantes comme valeurs. Si aucune variation n’est assignée pour un feature flag, la méthode renvoie la Variation par défaut pour ce flag.
Une gestion appropriée des erreurs doit être implémentée pour gérer les exceptions potentielles.
La variation par défaut fait référence à la variation assignée à un visiteur lorsqu’il ne correspond à aucune règle de delivery prédéfinie pour un feature flag. En d’autres termes, c’est la variation de repli appliquée à tous les utilisateurs qui ne sont pas ciblés par des règles spécifiques. Elle est représentée comme la variation dans la section “Then, for everyone else…” d’une interface de gestion.
try {
Map<String, Variation> variations = kameleoonClient.getVariations(visitorCode);
// only active variations
Map<String, Variation> variations = kameleoonClient.getVariations(visitorCode, true);
// disable tracking
Map<String, Variation> variations = kameleoonClient.getVariations(visitorCode, true, false);
} catch (VisitorCodeInvalid e) {
// Handle exception
}
Arguments
| Nom | Type | Description | Défaut |
|---|
| visitorCode (obligatoire) | String | Identifiant unique du visiteur. | |
| onlyActive (optionnel) | boolean | Un paramètre optionnel indiquant s’il faut renvoyer les variations pour les feature flags actifs (true) ou tous (false). | false |
| track (optionnel) | boolean | Un paramètre optionnel pour activer ou désactiver le tracking de l’évaluation du feature. | true |
Return value
| Type | Description |
|---|
Map<String, Variation> | Map contenant les objets Variation assignés des feature flags en utilisant les clés des features correspondants. |
Exceptions thrown
| Type | Description |
|---|
VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide. Il est soit vide, soit plus long que 255 caractères. |
setForcedVariation()
La méthode vous permet d’assigner par programmation une Variation 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 forceTargeting=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 l’analytique et stockée dans le contexte utilisateur comme toute variation évaluée standard, garantissant la cohérence dans le reporting.
La méthode peut lever des exceptions dans certaines conditions (par exemple, paramètres invalides, contexte utilisateur ou problèmes internes). Une gestion appropriée des exceptions est essentielle pour garantir que votre application reste stable et résiliente.
Il est important de distinguer les variations forcées des variations simulées :
- Forced variations : sont spécifiques à une expérience individuelle.
- Simulated variations : affectent le résultat global du feature flag.
try {
// Forcing the variation "on" for the feature flag "featureKey1" for the visitor
final int experimentId = 9516;
kameleoonClient.setForcedVariation(visitorCode, experimentId, "on");
// Resetting the forced variation for the feature flag "featureKey1" for the visitor
kameleoonClient.setForcedVariation(visitorCode, experimentId, null);
} catch (KameleoonException ex) {
// Handle the common Kameleoon Exception
}
Arguments
| Nom | Type | Description | Défaut |
|---|
| visitorCode (obligatoire) | String | Identifiant unique du visiteur. | |
| experimentId (obligatoire) | int | Experiment Id qui sera ciblé et sélectionné pendant le processus d’évaluation. | |
| variationKey (obligatoire) | String | Variation Key correspondant à une Variation qui doit être forcée comme valeur renvoyée pour l’expérience. Si la valeur est null, la variation forcée sera réinitialisée. | |
| forceTargeting (optionnel) | boolean | 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 |
Exceptions thrown
| Type | Description |
|---|
VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide. Il est soit vide, soit plus long que 255 caractères. |
FeatureExperimentNotFound | Exception indiquant que l’experiment id demandé n’a pas été trouvé dans la configuration interne du SDK. C’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. |
FeatureVariationNotFound | Exception indiquant que la variation key(id) demandée n’a pas été trouvée dans la configuration interne du SDK. C’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. |
Dans la plupart des cas, seule l’erreur de base, KameleoonException, doit être gérée, comme illustré dans l’exemple. Cependant, si différents types d’erreurs nécessitent une réponse, gérez chacune séparément en fonction des exigences spécifiques. De plus, pour une fiabilité accrue, les erreurs générales du langage peuvent être gérées en incluant Exception.
evaluateAudiences()
- 📨 Envoie des données de tracking à Kameleoon
Cette méthode évalue les visiteurs par rapport à tous les segments Audiences Explorer disponibles et suit ceux qui correspondent.
evaluateAudiences() doit être appelée après que toutes les données de visiteur pertinentes 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 assignation 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.
try {
kameleoonClient.evaluateAudiences(visitorCode);
} catch (KameleoonException ex) {
// Handle the common Kameleoon Exception
}
Arguments
| Nom | Type | Description |
|---|
| visitorCode (obligatoire) | String | Identifiant unique du visiteur. |
Exceptions thrown
| Type | Description |
|---|
VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide. Il est soit vide, soit plus long que 255 caractères. |
Dans la plupart des cas, seule l’erreur de base, KameleoonException, doit être gérée, comme illustré dans l’exemple. Cependant, si différents types d’erreurs nécessitent une réponse, gérez chacune séparément en fonction des exigences spécifiques. De plus, pour une fiabilité accrue, les erreurs générales du langage peuvent être gérées en incluant Exception.
getFeatureList()
Cette méthode s’appelait auparavant obtainFeatureList, qui a été supprimée dans la version 4.0.0 du SDK.
Renvoie une liste des feature flag keys actuellement disponibles pour le SDK.
List<String> allFeatureFlagKey = kameleoonClient.getFeatureList();
Return value
| Type | Description |
|---|
List<String> | Liste des feature flag keys |
getDataFile()
Pour évaluer tous les feature flags, utilisez getVariations(). Cette méthode est plus efficace que l’appel à DataFile et l’itération sur les flags avec getVariation().
Renvoie la configuration actuelle du SDK sous forme d’objet DataFile.
try {
DataFile dataFile = kameleoonClient.getDataFile();
} catch (Exception e) {
// Recommended (but optional) safeguard for unexpected exceptions from third-party libraries
}
Return value
| Type | Description |
|---|
DataFile | Le DataFile contenant la configuration du SDK |
Visitor data
getVisitorCode()
Cette méthode s’appelait auparavant obtainVisitorCode, qui a été supprimée dans la version 4.0.0 du SDK.
La méthode getVisitorCode() doit être appelée pour obtenir le visitorCode Kameleoon pour le visiteur actuel. Cette méthode est particulièrement importante lors de l’utilisation de Kameleoon dans un environnement mixte front-end et back-end, où la cohérence de l’identification de l’utilisateur doit être garantie. La logique d’implémentation est décrite ici :
-
Nous vérifions si un cookie
kameleoonVisitorCode ou un paramètre de requête associé à la requête HTTP actuelle peut être trouvé. Si c’est le cas, nous utilisons ce kameleoonVisitorCode comme identifiant du visiteur.
-
Si aucun cookie / paramètre n’est trouvé dans la requête actuelle, nous générons soit un nouvel identifiant aléatoire, soit nous utilisons l’argument
defaultVisitorCode comme identifiant s’il est passé. Ce processus permet à nos clients d’utiliser leurs propres identifiants comme visitor codes, s’ils le souhaitent. Cette flexibilité présente l’avantage supplémentaire de faire correspondre les visiteurs Kameleoon avec leurs propres utilisateurs sans recherches supplémentaires dans une table de correspondance.
-
Quoi qu’il en soit, le cookie
kameleoonVisitorCode côté serveur (via l’en-tête HTTP) est défini avec la valeur appropriée. Ensuite, la méthode renvoie cette valeur d’identifiant.
Pour plus d’informations, reportez-vous à cet article.
Si vous fournissez un visitorCode, son unicité doit être garantie de votre côté - le SDK ne peut pas la vérifier. Notez également que la longueur du visitorCode est limitée à 255 caractères. Tout caractère excédentaire lèvera une exception.
La méthode getVisitorCode() 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 Hybrid mode, le cookie est créé automatiquement lors de la simulation de l’affichage d’une variante à l’aide du Simulation Panel.
- Manuellement : Définissez manuellement le cookie
kameleoonSimulationFFData.
Il est important de distinguer les variations simulées des variations forcées :
- Simulated variations : affectent le résultat global du feature flag.
- Forced variations : sont spécifiques à une expérience individuelle.
⚙️ Configuration manuelleVeuillez vous assurer que le cookie kameleoonSimulationFFData respecte ce format :
kameleoonSimulationFFData={"featureKey":{"expId":10,"varId":20}} : simule la variation avec varId de l’expérience expId pour la featureKey donnée.
kameleoonSimulationFFData={"featureKey":{"expId":0}} : simule la variation par défaut (définie dans la section Then, for everyone else in Production, serve) pour la featureKey donnée.
⚠️ Pour garantir le bon fonctionnement, la valeur du cookie doit être encodée en tant que composant URI à l’aide d’une méthode telle que encodeURIComponent.
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
String visitorCode = kameleoonClient.getVisitorCode(httpServletRequest, httpServletResponse);
String visitorCode = kameleoonClient.getVisitorCode(httpServletRequest, httpServletResponse, defaultVisitorCode);
Arguments
| Nom | Type | Description |
|---|
| httpServletRequest | HttpServletRequest | L’objet HttpServletRequest actuel doit être passé comme premier paramètre. Ce champ est obligatoire. |
| httpServletResponse | HttpServletResponse | L’objet HttpServletResponse actuel doit être passé comme second paramètre. Ce champ est obligatoire. |
| defaultVisitorCode | String | Ce paramètre sera utilisé comme visitorCode lorsqu’un cookie kameleoonVisitorCode existant n’est pas trouvé sur la requête. Ce champ est optionnel. S’il n’est pas spécifié, le SDK génère un visitorCode aléatoire lorsqu’aucun cookie kameleoonVisitorCode n’existe. |
Return value
| Type | Description |
|---|
String | Un visitorCode qui sera associé à cet utilisateur particulier et devra être utilisé avec la plupart des méthodes du SDK. |
addData()
La méthode addData() ajoute des données de ciblage au stockage pour que d’autres méthodes puissent utiliser ces données pour décider de cibler ou non le visiteur actuel.
La méthode addData() ne renvoie aucune valeur et n’interagit pas avec les serveurs back-end de Kameleoon d’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 serveur effectués, car les données sont généralement regroupées en un seul appel serveur déclenché par flush().
La méthode trackConversion() envoie également toutes les données précédemment associées, tout comme flush(). Il en va de même pour les méthodes getVariation() et getVariations() 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.
// Add a single data item (tracked by default)
kameleoonClient.addData(visitorCode, Browser.chrome());
// Add multiple data items (tracked by default)
kameleoonClient.addData(visitorCode, new PageView("https://url.com", "title"), new UserAgent("UserAgent"));
// Add multiple data items stored locally for targeting only (not sent to the Kameleoon Data API)
kameleoonClient.addData(visitorCode, false, new PageView("https://url.com", "title"), new UserAgent("UserAgent"));
Arguments
| Nom | Type | Description | Valeur par défaut |
|---|
| visitorCode (obligatoire) | String | Identifiant unique du visiteur. | |
| track (optionnel) | boolean | Spécifie si les données ajoutées sont éligibles au tracking. Lorsqu’il est défini à false, les données sont stockées localement et utilisées uniquement pour l’évaluation du ciblage ; elles ne sont pas envoyées à la Kameleoon Data API. | true |
| data (obligatoire) | Data... | Collection de types de données Kameleoon. | |
Exceptions
| Type | Description |
|---|
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() collecte les données Kameleoon liées au visiteur. Elle envoie ensuite une requête de tracking, avec toutes les données ajoutées à l’aide de la méthode addData, qui n’ont pas encore été envoyées en utilisant l’une de ces méthodes. flush() est non bloquant car l’appel serveur est effectué de manière asynchrone.
flush vous permet de contrôler quand les données associées à un visitorCode donné sont envoyées à nos serveurs. Par exemple, si vous appelez addData() une douzaine de fois, il serait inefficace d’envoyer les données au serveur à chaque appel à addData(). Il vous suffit donc d’appeler flush() une seule fois.
Si vous spécifiez un visitorCode, la méthode flush() utilise ce code comme identifiant unique du visiteur, ce qui est utile pour la cross-device experimentation. Lorsque vous spécifiez un visitorCode et définissez le paramètre isUniqueIdentifier à true, le SDK lie les données flushées au visiteur associé à l’identifiant spécifié.
Le paramètre isUniqueIdentifier est obsolète. Veuillez utiliser UniqueIdentifier à la place.Le isUniqueIdentifier peut être utile dans des situations particulières ; par exemple, si vous ne pouvez pas accéder au visitorCode anonyme attribué à un visiteur, mais que vous pouvez utiliser un ID interne lié à ce visiteur via la fusion de sessions.
try {
kameleoonClient.flush(visitorCode); // Interval tracking (most performant tracking method)
kameleoonClient.flush(true, visitorCode); // Instant tracking
} catch (VisitorCodeInvalid e) {
// Catch exception
}
Arguments
| Nom | Type | Description |
|---|
| instant | boolean | Indicateur booléen indiquant si les données doivent être envoyées instantanément (true) ou selon l’intervalle de tracking par défaut (false) défini avec le paramètre du SDK tracking_interval_millisecond. Ce champ est optionnel. |
| visitorCode | String | Identifiant unique de l’utilisateur. Ce champ est obligatoire. |
| isUniqueIdentifier (Deprecated) | boolean | Un paramètre optionnel pour spécifier si le visitorCode est un identifiant unique. Le visitorCode doit être fourni et non null pour appliquer isUniqueIdentifier à un visiteur, sinon il sera ignoré. S’il n’est pas fourni, la valeur par défaut est false. Le champ est optionnel. |
getRemoteData()
Cette méthode s’appelait auparavant retrieveDataFromRemoteSource, qui a été supprimée dans la version 4.0.0 du SDK.
La méthode getRemoteData() vous permet de récupérer des données (selon une key passée en argument) pour le siteCode spécifié stocké sur le serveur Kameleoon. Votre site code est spécifié dans KameleoonClientFactory.create(). Habituellement, les données sont stockées sur nos serveurs distants à l’aide de notre Data API. Cette méthode, ainsi que la disponibilité de nos serveurs évolutifs, offre un moyen pratique de stocker des données supplémentaires que vous pouvez récupérer ultérieurement pour votre application.
CompletableFuture<JsonObject> data = kameleoonClient.getRemoteData("key");
try {
JsonObject test = kameleoonClient.getRemoteData("key").get(5_000, TimeUnit.MILLISECONDS);
} catch (InterruptedException | ExecutionException | TimeoutException e) {
// Catch exception
}
Arguments
| Nom | Type | Description |
|---|
| key | String | La clé qui est associée aux données récupérées. Ce champ est obligatoire. |
Return value
| Type | Description |
|---|
CompletableFuture<JsonObject> | Futur JsonObject associé à la récupération de données pour une key spécifique. |
getRemoteVisitorData()
getRemoteVisitorData() est une méthode asynchrone pour récupérer les Kameleoon Visits Data pour le visitorCode depuis la Kameleoon Data API. La méthode ajoute les données au stockage pour que d’autres méthodes les utilisent lors de la prise de décisions de ciblage.
Les données obtenues à l’aide de cette méthode jouent un rôle important lorsque vous souhaitez :
- utiliser des données collectées depuis d’autres appareils.
- accéder à l’historique d’un utilisateur, comme les pages précédemment visitées lors de visites passées.
- utiliser des données qui ne sont accessibles que côté client, comme les variables datalayer et les objectifs qui se convertissent côté front-end.
Lisez cet article pour mieux comprendre les cas d’utilisation possibles.
Par défaut, getRemoteVisitorData() récupère automatiquement les dernières custom data stockées avec scope=Visitor et les attache au visiteur sans avoir besoin d’appeler la méthode addData(). C’est particulièrement utile pour synchroniser les custom data entre plusieurs appareils.
Le paramètre isUniqueIdentifier est obsolète. Veuillez utiliser UniqueIdentifier à la place.Le isUniqueIdentifier peut être utile dans des situations particulières ; par exemple, si vous ne pouvez pas accéder au visitorCode anonyme attribué à un visiteur, mais que vous pouvez utiliser un ID interne lié à ce visiteur via la fusion de sessions.
String visitorCode = "visitorCode";
// Visitor data will be fetched and automatically added for `visitorCode`
CompletableFuture<List<Data>> visitorData = kameleoonClient.getRemoteVisitorData(visitorCode);
// If you only want to fetch data and add it yourself manually, set addData == `false`
CompletableFuture<List<Data>> visitorData = kameleoonClient.getRemoteVisitorData(visitorCode, false);
// If you want to fetch custom list of data types
RemoteVisitorDataFilter filter = RemoteVisitorDataFilter.builder()
.previousVisitAmount(25)
.customData(false)
.conversions(true)
.build();
CompletableFuture<List<Data>> visitorData = kameleoonClient.getRemoteVisitorData(visitorCode, filter, true, false);
try {
List<Data> visitorData = kameleoonClient.getRemoteVisitorData(visitorCode).get(5_000, TimeUnit.MILLISECONDS);
// Your custom code
} catch (CancellationException | InterruptedException | ExecutionException | TimeoutException e) {
// Catch exception
}
Arguments
| Nom | Type | Description |
|---|
| visitorCode | string | Le visitor code pour les données que vous souhaitez récupérer. Ce champ est obligatoire. |
| filter | RemoteVisitorDataFilter | Filtre pour spécifier quelles données doivent être récupérées des visites. Par défaut, seules les CustomData sont récupérées de la visite actuelle et de la dernière visite précédente (RemoteVisitorDataFilter.builder().build() ou new RemoteVisitorDataFilter()). Les autres paramètres de filtres sont définis à false. Ce champ est optionnel. |
| addData | boolean | Un booléen indiquant si la méthode doit ajouter automatiquement les données récupérées pour un visiteur. Ce champ est optionnel. |
| isUniqueIdentifier (Deprecated) | boolean | Un paramètre optionnel pour spécifier si le visitorCode est un identifiant unique. S’il n’est pas fourni, la valeur par défaut est false. Le champ est optionnel. |
Return value
| Type | Description |
|---|
CompletableFuture<List<Data>> | Futur List<Data> associé à un visiteur donné. |
Using parameters in getRemoteVisitorData()
La méthode getRemoteVisitorData() offre une flexibilité en vous permettant de définir divers paramètres lors de la récupération de données sur les visiteurs. Que vous cibliez en fonction d’objectifs, d’expériences ou de variations, la même approche s’applique à tous les types de données.
Par exemple, supposons que vous souhaitiez récupérer des données sur les visiteurs ayant complété un objectif “Order transaction”. Vous pouvez spécifier des paramètres dans la méthode getRemoteVisitorData() pour affiner votre ciblage. Par exemple, si vous souhaitez cibler uniquement les utilisateurs qui ont converti sur l’objectif lors de leurs cinq dernières visites, vous pouvez définir le paramètre previousVisitAmount à 5 et conversions à true.
La flexibilité montrée dans cet exemple ne se limite pas aux données d’objectif. Vous pouvez utiliser des paramètres dans la méthode getRemoteVisitorData() pour récupérer des données sur une variété de comportements de visiteurs.
Voici la liste des options kameleoon.types.RemoteVisitorDataFilter disponibles :| Nom | Type | Description | Défaut |
|---|
| previousVisitAmount (optionnel) | int | Nombre de visites précédentes à partir desquelles récupérer les données. Nombre entre 1 et 25 | 1 |
| currentVisit (optionnel) | boolean | Si true, les données de la visite actuelle seront récupérées | true |
| customData (optionnel) | boolean | Si true, les custom data seront récupérées. | true |
| pageViews (optionnel) | boolean | Si true, les données de page seront récupérées. | false |
| geolocation (optionnel) | boolean | Si true, les données de géolocalisation seront récupérées. | false |
| device (optionnel) | boolean | Si true, les données de device seront récupérées. | false |
| browser (optionnel) | boolean | Si true, les données de navigateur seront récupérées. | false |
| operatingSystem (optionnel) | boolean | Si true, les données du système d’exploitation seront récupérées. | false |
| conversions (optionnel) | boolean | Si true, les données de conversion seront récupérées. | false |
| experiments (optionnel) | boolean | Si true, les données d’expérience seront récupérées. | false |
| kcs (optionnel) | boolean | Si true, le Kameleoon Conversion Score (KCS) sera récupéré. Nécessite le AI Predictive Targeting add-on | false |
| visitorCode (optionnel) | boolean | Si true, Kameleoon récupérera le visitorCode de la visite la plus récente et l’utilisera pour la visite actuelle. Cela est nécessaire si vous souhaitez vous assurer que le visiteur, identifié par son visitorCode, reçoit toujours la même variation au fil des visites pour la cross-device experimentation. | true |
| personalization (optionnel) | boolean | Si true, les données de personnalisation seront récupérées. Cela est requis pour la condition de personnalisation. | false |
| cbs (optionnel) | boolean | Si true, les données de score Contextual Bandit seront récupérées. | false |
getVisitorWarehouseAudience()
Cette méthode récupère toutes les données d’audience associées au visiteur dans votre entrepôt de données en utilisant le visitorCode et le warehouseKey spécifiés. Le warehouseKey est généralement votre ID utilisateur interne. Le paramètre customDataIndex correspond aux custom data Kameleoon que Kameleoon utilise pour cibler vos visiteurs. Vous pouvez vous référer à la documentation de warehouse targeting pour des détails supplémentaires. La méthode passe le résultat au futur renvoyé sous forme d’objet CustomData, confirmant que les données ont été ajoutées au visiteur et sont disponibles à des fins de ciblage.
CompletableFuture<CustomData> warehouseAudienceDataCF =
kameleoonClient.getVisitorWarehouseAudience(visitorCode, warehouseKeyValue, customDataIndex);
// If you need to specify warehouse key
CompletableFuture<CustomData> warehouseAudienceDataCF =
kameleoonClient.getVisitorWarehouseAudience(visitorCode, customDataIndex);
try {
CustomData warehouseAudienceData = warehouseAudienceDataCF.get(5_000, TimeUnit.MILLISECONDS);
// Your custom code
} catch (CancellationException | InterruptedException | ExecutionException | TimeoutException e) {
// Catch exception
}
Arguments
| Nom | Type | Description |
|---|
| visitorCode | String | L’identifiant unique du visiteur pour lequel vous souhaitez récupérer et ajouter les données. |
| warehouseKey | String | La clé unique pour identifier les données d’entrepôt (généralement, votre ID utilisateur interne). Ce champ est optionnel. |
| customDataIndex | int | Un entier représentant l’index de la custom data que vous souhaitez utiliser pour cibler vos audiences BigQuery. |
Return value
| Type | Description |
|---|
CompletableFuture<CustomData> | Future instance CustomData confirmant que les données ont été ajoutées au visiteur. |
Exceptions thrown
| Type | Description |
|---|
VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide (il est soit vide, soit plus long que 255 caractères). |
setLegalConsent()
Vous devez utiliser cette méthode pour spécifier si le visiteur a donné son consentement légal pour l’utilisation de données personnelles. Définir le paramètre legalConsent à false limite les types de données que vous pouvez inclure dans les requêtes de tracking. Cette méthode vous aide à respecter les exigences légales et réglementaires tout en gérant de manière responsable les données des visiteurs. Vous trouverez plus d’informations sur les données personnelles dans la politique de gestion du consentement.
// if you do not need to set the visitor code in a cookie to respond
kameleoonClient.setLegalConsent(visitorCode, true);
String visitorCode = kameleoonClient.getVisitorCode(httpServletRequest, httpServletResponse);
kameleoonClient.setLegalConsent(visitorCode, true, httpServletResponse);
Arguments
| Nom | Type | Description |
|---|
| visitorCode | String | L’identifiant unique de l’utilisateur. Ce champ est obligatoire. |
| legalConsent | boolean | Une valeur booléenne représentant le statut du consentement légal. 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. Ce champ est obligatoire. |
| response | HttpServletResponse | La réponse de servlet HTTP où les valeurs des cookies seront ajustées en fonction du statut du consentement légal. Le champ est optionnel. |
Exceptions thrown
| Type | Description |
|---|
| KameleoonException.VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide. Il est soit vide, soit plus long que 255 caractères. |
Consent revocation behavior
Lorsque vous appelez setLegalConsent() avec legalConsent=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é demandent la suppression immédiate du fichier cookie lors du retrait du consentement, vous devez le supprimer manuellement à l’aide des méthodes de gestion natives de cookies de votre framework. Le SDK ne supprimera pas le fichier automatiquement.
Goals and third-party analytics
trackConversion()
- 📨 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 visitorCode et goalId. De plus, cette méthode accepte également des arguments optionnels revenue, negative et metadata. Le visitorCode est généralement identique à celui utilisé lors du déclenchement de l’expérience.
La méthode trackConversion() ne renvoie aucune valeur. Cette méthode est non bloquante car l’appel serveur est effectué de manière asynchrone.
Le paramètre isUniqueIdentifier est obsolète. Veuillez utiliser UniqueIdentifier à la place.Le isUniqueIdentifier peut également être utile dans d’autres scénarios particuliers, par exemple lorsque vous ne pouvez pas accéder au visitorCode anonyme qui a été initialement attribué au visiteur, mais que vous avez accès à un ID interne lié au visiteur anonyme via les capacités de fusion de sessions.
String visitorCode = kameleoonClient.getVisitorCode(httpServletRequest, httpServletResponse);
int goalId = 83023;
kameleoonClient.trackConversion(visitorCode, goalId);
// Add metadata
CustomData cd = new CustomData(1, "metadata");
kameleoonClient.trackConversion(visitorCode, goalId, cd);
Arguments
| Nom | Type | Description | Défaut |
|---|
| visitorCode (obligatoire) | String | Identifiant unique du visiteur. | |
| goalId (obligatoire) | int | ID de l’objectif. | |
| revenue (optionnel) | float | Revenu de la conversion. | 0 |
| negative (optionnel) | boolean | Définit si le revenu est positif ou négatif. | false |
| metadata (optionnel) | CustomData... | Vous permet de définir des valeurs spécifiques pour les custom data qui ont été définies en tant que métadonnées pour l’objectif dans l’application Kameleoon. Exemple : [CustomData{id: 5, value: "Payment Type"}, CustomData{id: 6, value: "Delivery Method"}]. Dans cet exemple, 5 et 9 sont les index des custom data (5 = “Payment Type”, 9 = “Delivery Method”). | new CustomData[0] |
| isUniqueIdentifier (deprecated) | boolean | Un paramètre optionnel pour spécifier si le visitorCode est un identifiant unique. | false |
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 actuelle au lieu de ce qui a été précédemment collecté en utilisant la méthode addData(). Si le paramètre est omis, Kameleoon utilisera les dernières valeurs suivies pour ces CustomData avant la conversion et au sein de la même visite.Kameleoon ne prendra en compte que les valeurs de métadonnées qui sont explicitement passées en paramètres à la méthode trackConversion().Dans l’exemple ci-dessous, Kameleoon associera la conversion uniquement à la valeur de custom data explicitement fournie en paramètre (ici : index 5 avec la valeur ‘Amex Credit Card’).kameleoonClient.addData(visitorCode, new CustomData(5, "Credit Card"), new CustomData(9, "Express Delivery"));
kameleoonClient.trackConversion(visitorCode, 1000, new CustomData(5, "Amex Credit Card"));
Exceptions
| Type | Description |
|---|
VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide. Il est soit vide, soit plus long que 255 caractères. |
getEngineTrackingCode()
Kameleoon s’intègre à plusieurs solutions d’analytique, notamment Mixpanel, Google Analytics 4 et Segment. Pour suivre correctement les expériences côté serveur, appelez la méthode getEngineTrackingCode() après que le visiteur a déclenché une expérience. Le SDK renvoie les commandes de queue JavaScript pour les expériences que le visiteur a déclenchées au cours des cinq dernières secondes. Lorsque vous insérez ce code dans la page, Engine.js traite les commandes et envoie les événements d’exposition via l’intégration d’analytique active.
Reportez-vous à hybrid experimentation pour plus d’informations sur l’implémentation de cette méthode.
String engineTrackingCode = kameleoonClient.getEngineTrackingCode(visitorCode);
- Pour utiliser cette fonctionnalité, implémentez à la fois le SDK Java 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
</body> de fermeture.
- Si vous souhaitez uniquement suivre les expériences dans Kameleoon et que vous n’avez pas besoin d’envoyer des événements d’exposition à des outils d’analytique tiers, utilisez le JavaScript / TypeScript SDK. Cette option fonctionne bien pour les serverless edge compute platforms. Le SDK JavaScript / TypeScript suit automatiquement les variations lorsque vous appelez
getVisitorCode, à condition que vous ajoutiez les assignations 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 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
| Nom | Type | Description |
|---|
| visitorCode (obligatoire) | String | Identifiant unique du visiteur. |
Return value
| Type | Description |
|---|
String | Code JavaScript à insérer dans la page. |
Events
updateConfigurationHandler()
La méthode updateConfigurationHandler() vous permet de gérer l’événement lorsque la configuration a été mise à jour avec 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.
kameleoonClient.updateConfigurationHandler(() -> {
// Configuration was updated
});
Arguments
| Nom | Type | Description |
|---|
| handler | KameleoonUpdateConfigurationHandler | Le handler qui sera appelé lorsque la configuration est mise à jour via un événement de configuration en temps réel. |
Data types
Cette section liste les types de données pris en charge par Kameleoon dans com.kameleoon.Data. Nous fournissons plusieurs types de données standard ainsi que le type CustomData qui vous permet de définir des types de données personnalisés.
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 |
|---|
| type (obligatoire) | Browser.Type | Liste des navigateurs : CHROME, INTERNET_EXPLORER, FIREFOX, SAFARI, OPERA, OTHER. |
| version (optionnel) | Float | Version du navigateur, le nombre à virgule flottante représente la version majeure et mineure du navigateur |
kameleoonClient.addData(visitorCode, Browser.chrome());
kameleoonClient.addData(visitorCode, Browser.safari());
kameleoonClient.addData(visitorCode, new Browser(Browser.Type.CHROME, 10.0));
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
goalId dans l’application Kameleoon.
| Nom | Type | Description | Défaut |
|---|
| goalId (obligatoire) | int | ID de l’objectif. | |
| revenue (optionnel) | float | Revenu de la conversion | 0 |
| negative (optionnel) | boolean | Définit si le revenu est positif ou négatif. | false |
| metadata (optionnel) | CustomData... | Métadonnées de la conversion. | new CustomData[0] |
kameleoonClient.addData(visitorCode, new Conversion(32, 10f));
kameleoonClient.addData(visitorCode, new Conversion(33, null, true));
kameleoonClient.addData(
visitorCode,
new Conversion(34, 5f, new CustomData(3, "metadata1", "md2"), new CustomData(5, "md3"))
);
Cookie
Cookie contient des informations sur le cookie stocké sur l’appareil du visiteur.
| Nom | Type | Description |
|---|
| cookies | Map<String, String> | Une map d’objets string composée de clés et de valeurs de cookies. Ce champ est obligatoire. |
Chaque visiteur ne peut avoir qu’un seul Cookie. Ajouter un second Cookie écrase le premier.
Cookie cookie = new Cookie (new HashMap<String, String>() {{
put("my_key1", "my_value1");
put("my_key2", "my_value1");
}});
kameleoonClient.addData(visitorCode, cookie);
Geolocation
Geolocation contient les détails de géolocalisation du visiteur.
| Nom | Type | Description |
|---|
| country (obligatoire) | String | Le pays du visiteur. |
| region (optionnel) | String | La région du visiteur. |
| city (optionnel) | String | La ville du visiteur. |
| postalCode (optionnel) | String | Le code postal du visiteur. |
| latitude (optionnel) | float | 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) | float | 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. Ajouter une seconde Geolocation écrase la première.
kameleoonClient.addData(visitorCode, new Geolocation("France", "Île-de-France", "Paris"));
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 breakdown dans les rapports d’expérience. Pour plus d’informations sur les custom data, veuillez consulter cet article.
Définissez les types de custom data dans l’application Kameleoon ou la Data API et utilisez-les depuis le SDK.
| Nom | Type | Description | Défaut |
|---|
| index/name (obligatoire) | int/String | Index ou Nom de la custom data. Soit index soit name doit être fourni pour identifier les données.. | |
| values (obligatoire) | String.../List<String> | Valeurs de la custom data à stocker. | |
| overwrite (optionnel) | boolean | Drapeau pour 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. Ajouter une autre CustomData avec le même index(name) remplacera l’existante.
-
L’index de la custom data peut être trouvé dans le dashboard Custom Data sous la colonne “INDEX”.
-
Pour empêcher le SDK d’envoyer les données avec l’index sélectionné aux serveurs Kameleoon pour des raisons de confidentialité, activez l’option : Use this data only locally for targeting purposes lors de la création de la custom data.
-
L’ajout d’une instance
CustomData créé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 des données.
kameleoonClient.addData(visitorCode, new CustomData(1, "value"));
// With several values
kameleoonClient.addData(visitorCode, new CustomData(1, "value1", "value2"));
// To set the 'overwrite' flag to false
kameleoonClient.addData(visitorCode, new CustomData(1, false, "value"));
// To use a name instead of the index
kameleoonClient.addData(visitorCode, new CustomData("my-custom-data", "value"));
Device
| Nom | Type | Description |
|---|
| device | Device | Liste des appareils : PHONE, TABLET, DESKTOP. Ce champ est obligatoire. |
kameleoonClient.addData(visitorCode, Device.desktop());
PageView
Stocke les événements de page view.
| Nom | Type | Description |
|---|
| url | String | URL de la page consultée. Ce champ est obligatoire. |
| title | String | Titre de la page consultée. Ce champ est obligatoire. |
| referrers | List<Integer> | Referrers des pages consultées. Ce champ est optionnel. |
L’index (ID) du referrer est disponible dans l’application Kameleoon dans la page de configuration du canal d’acquisition. Attention : cet index commence à 0, donc le premier canal d’acquisition que vous créez pour le site spécifié aurait l’ID 0, et non 1.
kameleoonClient.addData(
visitorCode,
new PageView("https://url.com", "title", Array.asList(3))
);
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 l’IAB/ABC International Spiders and Bots List pour résoudre ce problème et reconnaître les bots et spiders connus. Kameleoon utilise également le champ UserAgent pour filtrer les bots et autres trafics indésirables qui pourraient fausser vos métriques de conversion. Pour plus de détails, consultez notre article d’aide sur le filtrage des bots.
Si vous utilisez des bots internes, nous vous suggérons de passer la valeur curl/8.0 du userAgent pour les exclure de notre analytique.
| Nom | Type | Description |
|---|
| value | String | La valeur User-Agent qui sera envoyée avec les requêtes de tracking. Ce champ est obligatoire. |
kameleoonClient.addData(visitorCode, new UserAgent("Your User Agent"));
UniqueIdentifier
Si vous n’ajoutez pas UniqueIdentifier pour un visiteur, le visitorCode est utilisé comme identifiant unique du visiteur, ce qui est utile pour la cross-device experimentation. Lorsque vous ajoutez UniqueIdentifier pour un visiteur, le SDK lie les données flushées au visiteur associé à l’identifiant spécifié.
Le isUniqueIdentifier peut être utile dans des situations particulières ; par exemple, si vous ne pouvez pas accéder au visitorCode anonyme attribué à un visiteur, mais que vous pouvez utiliser un ID interne lié à ce visiteur via la fusion de sessions.
| Nom | Type | Description |
|---|
| value | boolean | Paramètre spécifiant si le visitorCode est un identifiant unique. Ce champ est obligatoire. |
kameleoonClient.addData(visitorCode, new UniqueIdentifier(true));
OperatingSystem
OperatingSystem contient des informations sur le système d’exploitation de l’appareil du visiteur.
| Nom | Type | Description |
|---|
| type | OperatingSystem.Type | Liste des systèmes d’exploitation : WINDOWS_PHONE, WINDOWS, ANDROID, LINUX, MAC, et IOS. Ce champ est obligatoire. |
Chaque visiteur ne peut avoir qu’un seul OperatingSystem. Ajouter un second OperatingSystem écrase le premier.
kameleoonClient.addData(visitorCode, new OperatingSystem(OperatingSystem.Type.WINDOWS));
kameleoonClient.addData(visitorCode, OperatingSystem.mac());
ApplicationVersion
ApplicationVersion représente le numéro de version sémantique de votre application.
Un visiteur ne peut avoir qu’un seul ApplicationVersion. Ajouter une seconde instance écrasera la première.
| Nom | Type | Description |
|---|
| version (optionnel) | String | La version de l’application mobile. Ce champ doit suivre la versioning sémantique. Les formats acceptés sont major, major.minor, ou major.minor.patch. |
kameleoonClient.addData(visitorCode, new ApplicationVersion("10")); // major
kameleoonClient.addData(visitorCode, new ApplicationVersion("10.20")); // major.minor
kameleoonClient.addData(visitorCode, new ApplicationVersion("10.20.30")); // major.minor.patch
Returned Types
DataFile
Le DataFile 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.
| Nom | Type | Description |
|---|
| featureFlags | Map<String, FeatureFlag> | Une map d’objets FeatureFlag, indexée par les feature flag keys. |
| dateModified | long | L’horodatage (en millisecondes) indiquant quand le DataFile a été modifié pour la dernière fois. |
// Retrieves the map of feature flags from the DataFile.
// The map is keyed by feature flag identifiers, with each value being a FeatureFlag object.
Map<String, FeatureFlag> featureFlags = dataFile.getFeatureFlags();
// Retrieves the last modification timestamp of the DataFile.
// The value is a long representing milliseconds since the Unix epoch.
long dateModified = dataFile.getDateModified();
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, le statut de l’environnement et d’autres détails associés.
Il peut être étendu avec des informations supplémentaires si les clients en ont besoin. Si vous avez besoin de plus de détails, veuillez contacter votre Customer Success Manager.
| Nom | Type | Description |
|---|
| environmentEnabled | boolean | Indique si le feature flag est activé dans l’environnement actuel. |
| defaultVariationKey | String | La clé de la variation par défaut associée au feature flag. |
| variations | Map<String, Variation> | Une map d’objets Variation, indexée par les variation keys. |
| rules | List<Rule> | Une liste d’objets Rule |
// Check whether the feature flag is enabled in the current environment
boolean isEnvironmentEnabled = featureFlag.isEnvironmentEnabled();
// Retrieve the key of the default variation
String defaultVariationKey = featureFlag.getDefaultVariationKey();
// Retrieve the default variation object
Variation defaultVariation = featureFlag.getDefaultVariation();
// Retrieve all variations of the feature flag as a map (key = variation key, value = Variation object)
Map<String, Variation> variations = featureFlag.getVariations();
// Retrieve all targeting rules associated with the feature flag
List<Rule> rules = featureFlag.getRules();
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 en ont besoin. Si vous avez besoin de plus de détails, veuillez contacter votre Customer Success Manager.
| Nom | Type | Description |
|---|
| variations | Map<String, Variation> | Une map d’objets Variation, indexée par les variation keys. |
// Retrieve all variations of the rule as a map (key = variation key, value = Variation object)
Map<String, Variation> variations = rule.getVariations();
Variation
Variation contient des informations sur la variation assignée du visiteur (ou la variation par défaut, si aucune assignation spécifique n’existe).
| Nom | Type | Description |
|---|
| name | String | Le nom de la variation. |
| key | String | La clé unique identifiant la variation. |
| id | Integer | L’ID de la variation assignée (ou null s’il s’agit de la variation par défaut). |
| experimentId | Integer | L’ID de l’expérience associée à la variation (ou null si par défaut). |
| variables | Map<String, Variable> | Une map contenant les variables de la variation assignée, indexée par les noms de variables. Cela peut être une collection vide si aucune variable n’est associée. |
- L’objet
Variation fournit des détails sur la variation assignée et son expérience associée, tandis que l’objet Variable contient des détails spécifiques sur chaque variable au sein d’une variation.
- Assurez-vous que votre code gère le cas où
id ou experimentId peuvent être null, indiquant une variation par défaut.
- La map
variables peut être vide si aucune variable n’est associée à la variation.
// Retrieving the variation name
String variationName = variation.getName();
// Retrieving the variation key
String variationKey = variation.getKey();
// Retrieving the variation id
Integer variationId = variation.getId();
// Retrieving the experiment id
Integer experimentId = variation.getExperimentId();
// Retrieving the variables map
Map<String, Variable> variables = variation.getVariables();
Variable
Variable contient des informations sur une variable associée à la variation assignée.
| Nom | Type | Description |
|---|
| key | String | La clé unique identifiant la variable. |
| type | String | Le type de la variable. Valeurs possibles : BOOLEAN, NUMBER, STRING, JSON, JS, CSS. |
| value | Object | La valeur de la variable, qui peut être des types suivants : Boolean, Integer, Long, Double, String, JsonObject, JsonArray. |
// Retrieving the variables map
Map<String, Variable> variables = variation.getVariables();
// Variable type can be retrieved for further processing
String type = variables.get("isDiscount").getType();
// Retrieving the variable value by key
Boolean isDiscount = (Boolean) variables.get("isDiscount").getValue();
// Variable value can be of different types
String title = (String) variables.get("title").getValue();
Deprecated methods
Ces méthodes sont obsolètes et seront supprimées dans la version 5.0.0 du SDK.
getFeatureVariationKey()
- 📨 Envoie des données de tracking à Kameleoon
Appelez cette méthode pour obtenir la feature variation key pour un utilisateur et un feature spécifiés. Cette méthode prend un visitorCode et une featureKey comme arguments obligatoires pour obtenir la variation key pour l’utilisateur et le feature.
Si l’utilisateur n’a jamais été associé à ce feature flag, le SDK renvoie une variation key assignée aléatoirement (selon les règles du feature flag). Si un utilisateur avec le visitorCode spécifié est déjà enregistré avec ce feature flag, le SDK détecte la valeur précédente de variation key. Si l’utilisateur ne correspond à aucune des règles, la valeur par défaut est renvoyée, que vous pouvez personnaliser dans l’application Kameleoon.
Assurez-vous de capturer et de gérer les exceptions potentielles.
Si vous spécifiez un visitorCode, la méthode flush() l’utilise comme identifiant unique du visiteur, ce qui est utile pour la cross-device experimentation. Lorsque vous spécifiez un visitorCode et définissez le paramètre isUniqueIdentifier à true, le SDK lie les données flushées au visiteur associé à l’identifiant spécifié.
Le paramètre isUniqueIdentifier est obsolète. Veuillez utiliser UniqueIdentifier à la place.Le isUniqueIdentifier peut être utile dans des situations particulières ; par exemple, si vous ne pouvez pas accéder au visitorCode anonyme attribué à un visiteur, mais que vous pouvez utiliser un ID interne lié à ce visiteur via la fusion de sessions.
String visitorCode = kameleoonClient.getVisitorCode(httpServletRequest, httpServletResponse);
String featureKey = "new_checkout";
String variationKey = ""
try {
variationKey = kameleoonClient.GetFeatureVariationKey(visitorCode, featureKey);
} catch (KameleoonException.FeatureNotFound e) {
// The error has occurred; the feature flag isn't found in the current configuration
} catch (KameleoonException.FeatureEnvironmentDisabled e) {
// The feature flag is disabled for the environment
} catch (KameleoonException.VisitorCodeInvalid e) {
// The visitor code you passed to the method is invalid and can't be accepted by SDK.
}
switch (variationKey) {
case 'on':
// Main variation key is selected for visitorCode
break;
case 'alternative_variation':
// Alternative variation key
break;
default:
// Default variation key
break;
}
Arguments
| Nom | Type | Description |
|---|
| visitorCode | String | Identifiant unique de l’utilisateur. Ce champ est obligatoire. |
| featureKey | String | Clé du feature que vous souhaitez exposer à un utilisateur. Ce champ est obligatoire. |
| isUniqueIdentifier (Deprecated) | boolean | Un paramètre optionnel pour spécifier si le visitorCode est un identifiant unique. S’il n’est pas fourni, la valeur par défaut est false. Le champ est optionnel. |
Return value
| Type | Description |
|---|
String | Variation key du feature flag qui est enregistrée pour le visitorCode spécifié. |
Exceptions thrown
| Type | Description |
|---|
| KameleoonException.FeatureNotFound | Exception indiquant que la feature key demandée n’a pas été trouvée dans la configuration interne du SDK. Cette exception 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é sur votre application). |
| KameleoonException.FeatureEnvironmentDisabled | Exception indiquant que le feature flag est désactivé pour l’environnement actuel du visiteur (par exemple, production, staging ou development). |
| KameleoonException.VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide. Il est vide ou plus long que 255 caractères. |
getActiveFeatures()
Cette méthode prend un seul paramètre visitorCode. Le résultat contient uniquement les features actifs pour un visiteur donné.
try {
Map<String, Variation> activeFeatures = kameleoonClient.getActiveFeatures(visitorCode);
} catch (VisitorCodeInvalid e) {
// Handle exception
}
Arguments
| Nom | Type | Description |
|---|
| visitorCode | String | Identifiant unique de l’utilisateur. Ce champ est obligatoire. |
Return value
| Type | Description |
|---|
Map<String, Variation> | Map qui contient les variations assignées des features actifs en utilisant les clés des features actifs correspondants. |
Exceptions thrown
| Type | Description |
|---|
| VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide. Il est soit vide, soit plus long que 255 caractères. |
getActiveFeatureListForVisitorCode()
- Utilisez
getVariations() à la place.
- Cette méthode s’appelait auparavant
obtainFeatureListForVisitorCode, qui a été supprimée dans la version 4.0.0 du SDK.
Cette méthode prend un seul paramètre visitorCode. Renvoie uniquement les feature flags actifs pour le visiteur spécifié.
List<String> listActiveFeatureFlags = kameleoonClient.getActiveFeatureListForVisitorCode(visitorCode);
Arguments
| Nom | Type | Description |
|---|
| visitorCode | String | Identifiant unique de l’utilisateur. Ce champ est obligatoire. |
Return value
| Type | Description |
|---|
List<String> | Liste des feature flag keys actifs disponibles pour un visitorCode spécifique |
getFeatureVariable()
- 📨 Envoie des données de tracking à Kameleoon
Appelez cette méthode pour obtenir la valeur de la variation de feature associée à un utilisateur. Cette méthode prend un visitorCode, une featureKey et une variableKey comme arguments obligatoires pour obtenir la variable de la variation key pour l’utilisateur spécifié.
Si un utilisateur n’a jamais été associé à ce feature flag, le SDK renvoie une valeur de variable assignée aléatoirement de la variation key selon les règles du feature flag. Si un utilisateur avec le visitorCode spécifié est déjà enregistré avec ce feature flag, le SDK renvoie la valeur de variable pour la variation précédemment associée. Si l’utilisateur ne correspond à aucune des règles, la variable par défaut est renvoyée.
Assurez-vous de capturer et de gérer les exceptions potentielles.
Si vous spécifiez un visitorCode, la méthode getFeatureVariable() utilise le code comme identifiant unique du visiteur, ce qui est utile pour la cross-device experimentation. Lorsque vous spécifiez un visitorCode et définissez le paramètre isUniqueIdentifier à true, le SDK lie les données flushées au visiteur associé à l’identifiant spécifié.
Le paramètre isUniqueIdentifier est obsolète. Veuillez utiliser UniqueIdentifier à la place.Le isUniqueIdentifier peut être utile dans des situations particulières ; par exemple, si vous ne pouvez pas accéder au visitorCode anonyme attribué à un visiteur, mais que vous pouvez utiliser un ID interne lié à ce visiteur via la fusion de sessions.
String visitorCode = kameleoonClient.getVisitorCode(httpServletRequest, httpServletResponse);
String featureKey = "feature_key";
String variableKey = "var"
try {
var variableValue = kameleoonClient.getFeatureVariable(visitorCode, featureKey, variableKey);
// Your custom code, depending on variableValue.
} catch (KameleoonException.FeatureNotFound e) {
// The error has occurred; the feature flag isn't found in current configuration
} catch (KameleoonException.FeatureEnvironmentDisabled e) {
// The feature flag is disabled for the environment.
} catch (KameleoonException.FeatureVariableNotFound e) {
// Requested variable not defined on Kameleoon's side
} catch (KameleoonException.VisitorCodeInvalid e) {
// The visitor code passed to the method is invalid and can't be accepted by SDK.
}
Arguments
| Nom | Type | Description |
|---|
| visitorCode | String | Identifiant unique de l’utilisateur. Ce champ est obligatoire. |
| featureKey | String | Clé du feature que vous souhaitez exposer à un utilisateur. Ce champ est obligatoire. |
| variableKey | String | Nom de la variable pour laquelle vous souhaitez obtenir une valeur. Ce champ est obligatoire. |
| isUniqueIdentifier (Deprecated) | boolean | Un paramètre optionnel pour spécifier si le visitorCode est un identifiant unique. S’il n’est pas fourni, la valeur par défaut est false. Le champ est optionnel. |
Return value
| Type | Description |
|---|
| object | Valeur de la variable de la variation qui est enregistrée pour le visitorCode spécifié pour ce feature flag. Types possibles : bool, int, double, string, JObject, JArray |
Exceptions thrown
| Type | Description |
|---|
| KameleoonException.FeatureNotFound | Exception indiquant que la feature key demandée n’a pas été trouvée dans la configuration interne du SDK. Cela signifie généralement que le feature flag n’a pas encore été activé dans l’application Kameleoon (mais que le code implémentant le feature est déjà déployé dans votre application). |
| KameleoonException.FeatureEnvironmentDisabled | Exception indiquant que le feature flag est désactivé pour l’environnement actuel du visiteur (par exemple, production, staging ou development). |
| KameleoonException.FeatureVariableNotFound | Exception indiquant que la variable demandée n’a pas été trouvée. Vérifiez que la clé de la variable dans l’application Kameleoon correspond à votre code. |
| KameleoonException.VisitorCodeInvalid | Exception indiquant que le visitor code spécifié n’est pas valide. (Il est soit vide, soit plus long que 255 caractères). |
getFeatureVariables()
- 📨 Envoie des données de tracking à Kameleoon
Cette méthode récupère une map contenant les clés de variables et leurs valeurs assignées selon la variation à laquelle le visiteur est assigné dans le feature flag spécifié. Les variables de feature peuvent être modifiées dans l’application Kameleoon.
Si un utilisateur n’a jamais été associé à ce feature flag, le SDK renvoie un ensemble de valeurs de variables assignées aléatoirement dans la variation selon les règles du feature flag. Si un utilisateur avec le visitorCode spécifié est déjà enregistré avec ce feature flag, le SDK renvoie les valeurs de variables pour la variation précédemment utilisée. Si l’utilisateur ne correspond à aucune des règles, les variables par défaut sont renvoyées.
Assurez-vous de capturer et de gérer les exceptions potentielles.
String visitorCode = kameleoonClient.getVisitorCode(httpServletRequest, httpServletResponse);
String featureKey = "feature_key";
String variableKey = "var"
try {
var variableValue = kameleoonClient.getFeatureVariables(visitorCode, featureKey);
// Your custom code, depending on variable values.
} catch (KameleoonException.FeatureNotFound e) {
// The error has occurred; the feature flag isn't found in current configuration.
} catch (KameleoonException.FeatureEnvironmentDisabled e) {
// The feature flag is disabled for the environment.
} catch (KameleoonException.FeatureVariableNotFound e) {
// Requested variable not defined on Kameleoon's side
} catch (KameleoonException.VisitorCodeInvalid e) {
// The visitor code passed to the method is invalid and can't be accepted by SDK.
}
Arguments
| Nom | Type | Description |
|---|
| featureKey | String | Clé du feature que vous souhaitez obtenir. Ce champ est obligatoire. |
| variationKey | String | Clé de la variation que vous souhaitez obtenir. Ce champ est obligatoire. |
Return value
| Type | Description |
|---|
Map<String,Object> | Données associées à ce feature flag. Les valeurs peuvent être Boolean, Integer, Double, String, JsonObject, ou JsonArray (le type est défini dans l’application Kameleoon). |
Exceptions thrown
| Type | Description |
|---|
| KameleoonException.FeatureNotFound | Exception indiquant que la feature key demandée n’a pas été trouvée dans la configuration interne du SDK. Cette exception signifie généralement que le feature flag n’a pas été activé dans l’application Kameleoon (mais que le code implémentant le feature est déjà déployé dans votre application). |
| KameleoonException.FeatureEnvironmentDisabled | Exception indiquant que le feature flag est désactivé pour l’environnement actuel du visiteur (par exemple, production, staging ou development). |
| KameleoonException.FeatureVariationNotFound | Exception indiquant que la variation key demandée n’a pas été trouvée dans la configuration interne du SDK. Cela signifie généralement que l’expérience correspondant à la variation n’est pas activée dans l’application Kameleoon. |
| KameleoonException.VisitorCodeInvalid | Exception indiquant que le visitor code spécifié n’est pas valide. (Il est soit vide, soit plus long que 255 caractères). |
getFeatureVariationVariables()
- Utilisez
getVariation() à la place.
- Cette méthode s’appelait auparavant
getFeatureAllVariables, qui a été supprimée dans la version 4.0.0 du SDK.
Appelez cette méthode pour récupérer toutes les variables de feature pour un feature. Vous pouvez modifier les variables de feature dans l’application Kameleoon.
Cette méthode prend deux paramètres d’entrée : featureKey et variationKey. Elle renvoie les données avec le type Map<String, Object> tel que défini dans l’application Kameleoon. Elle lève une exception (KameleoonException.FeatureNotFound) si le feature que vous demandez n’est pas trouvé dans la configuration interne du SDK.
String featureKey = "featureKey";
String variationKey = "variationKey";
try {
Map<String, Object> allVariables = kameleoonClient.getFeatureVariationVariables(featureKey, variationKey);
} catch (KameleoonException.FeatureNotFound e) {
// The feature is not activated in the Kameleoon app.
} catch (KameleoonException.FeatureEnvironmentDisabled e) {
// The feature flag is disabled for the environment.
} catch (KameleoonException.FeatureVariationNotFound e) {
// The variation is not activated in the Kameleoon app (most likely, the associated experiment is not active)
} catch (Exception e) {
// This is a generic Exception handler which will handle all exceptions.
System.out.println("Exception occurred");
}
Arguments
| Nom | Type | Description |
|---|
| featureKey | String | Clé du feature que vous souhaitez obtenir. Ce champ est obligatoire. |
| variationKey | String | Clé de la variation que vous souhaitez obtenir. Ce champ est obligatoire. |
Return value
| Type | Description |
|---|
Map<String,Object> | Données associées à ce feature flag. Les valeurs peuvent être Boolean, Integer, Double, String, JsonObject, JsonArray (selon le type défini dans l’application Kameleoon). |
Exceptions thrown
| Type | Description |
|---|
| KameleoonException.FeatureNotFound | Exception indiquant que le feature demandé n’a pas été trouvé dans la configuration interne du SDK. Cette exception signifie généralement que le feature flag n’est pas activé dans l’application Kameleoon. |
| KameleoonException.FeatureEnvironmentDisabled | Exception indiquant que le feature flag est désactivé pour l’environnement actuel du visiteur (par exemple, production, staging ou development). |
| KameleoonException.FeatureVariationNotFound | Exception indiquant que la variation key demandée n’a pas été trouvée dans la configuration interne du SDK. Cela signifie généralement que l’expérience correspondant à la variation n’est pas activée dans l’application Kameleoon. |