Avec le SDK PHP, vous pouvez exécuter des expériences et activer des feature flags sur votre serveur PHP back-end. L’intégration de notre SDK dans votre application web est simple, et son empreinte (utilisation de la mémoire et du réseau) est faible.
Premiers pas : Pour obtenir de l’aide afin de démarrer, consultez le guide du développeur.
Changelog : Dernière version du SDK PHP : 4.23.0 Changelog.
Méthodes du SDK : Pour la documentation de référence complète du SDK PHP, consultez la section référence.
Developer guide
Ce guide est conçu pour vous aider à intégrer notre SDK dans le code de votre application.
Premiers pas
Vous devez d’abord installer notre SDK. Une fois décompressé, vous verrez deux répertoires : kameleoon/ et job/.
Installation du client PHP (paquet Composer)
Le paquet d’installation est disponible sur Packagist. Vous pouvez installer le SDK PHP en l’ajoutant en tant que dépendance via Composer :
{
"require": {
"kameleoon/kameleoon-client-php": "^4.18.0"
}
}
Enfin, exécutez la commande suivante pour régénérer l’autoloader :
Avec une tâche cron (recommandé)
Configurer la tâche cron permet le suivi des données ajoutées par le SDK PHP avec la méthode addData(). Cependant, si vous ne pouvez pas l’installer, le suivi front-end peut toujours être mis en œuvre en suivant ce guide.
Le répertoire job/ correspond à une tâche qui doit être exécutée via un planificateur de tâches standard (comme cron).
Nous suggérons d’installer le script dans /usr/local/opt/kameleoon/kameleoon-client-php-process-queries.sh et d’utiliser notre entrée crontab par défaut. Cependant, vous pouvez l’installer à un autre emplacement et modifier l’entrée crontab en conséquence.
Sans tâche cron
Si vous ne pouvez pas installer la tâche cron, vous pouvez utiliser Kameleoon en mode hybride pour bénéficier des capacités de suivi du Kameleoon Application Engine, engine.js (anciennement nommé kameleoon.js). Notre SDK fournit la méthode getEngineTrackingCode(), qui envoie des événements d’exposition à Kameleoon ou à toute autre solution d’analyse que vous utilisez sur votre site web.
Avec cette approche, vous ne pourrez pas suivre les données ajoutées avec la méthode addData() du SDK PHP.
En d’autres termes, le seul moyen pour le SDK PHP de collecter et de traiter les données d’expérience côté serveur est via la tâche cron.
Le mode hybride est utile à des fins de suivi, mais ne permet pas la collecte de données back-end.
Configuration supplémentaire
Vous pouvez personnaliser le comportement du SDK PHP via un fichier de configuration. Nous fournissons un exemple de fichier de configuration nommé client-php.json.sample dans l’archive du SDK. Vous pouvez également télécharger un exemple de configuration. Nous suggérons d’installer ce fichier au chemin par défaut /tmp/kameleoon/client-php.json. 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 Identifiants API. | |
clientSecret / client_secret (obligatoire) | Requis pour l’authentification auprès du service Kameleoon. Pour trouver votre client_secret, consultez la documentation Identifiants API. | |
kameleoonWorkDir / kameleoon_work_dir (optionnel) | Spécifie un répertoire de travail pour le client PHP (qui créera des fichiers dans ce répertoire). Le répertoire doit être accessible en écriture par l’utilisateur PHP. | /tmp/kameleoon/client-php/ |
refreshIntervalMinute / refresh_interval_minute (optionnel) | Spécifie l’intervalle de rafraîchissement, en minutes, auquel le SDK récupère la configuration des expériences actives et des feature flags. Cette valeur détermine le temps maximum nécessaire à la propagation des changements, tels que l’activation ou la désactivation des feature flags ou le lancement d’expériences, vers vos serveurs de production. | 60 minutes |
defaultTimeoutMillisecond / 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 par défaut pour cette méthode particulière. Si vous ne spécifiez pas explicitement le délai pour une méthode, le SDK utilise cette valeur par défaut. | 10000 millisecondes |
cookieOptions->topLevelDomain / cookie_options.domain (obligatoire en mode hybride) | Le domaine de niveau supérieur actuel de votre site web. Utilisez le format : example.com. N’incluez pas https://, www, ni d’autres sous-domaines. Kameleoon utilise cette information pour définir le cookie correspondant sur le domaine de niveau supérieur. | null |
cookieOptions->secure / cookie_options.secure (optionnel) | Contrôle l’attribut Secure du cookie. | false |
cookieOptions->httpOnly / cookie_options.http_only (optionnel) | Contrôle l’attribut HttpOnly du cookie. | false |
cookieOptions->sameSite / cookie_options.samesite (optionnel) | Contrôle l’attribut SameSite du cookie. | Lax |
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 sur la gestion des environnements pour plus de détails. | production |
networkDomain / network_domain (optionnel) | Domaine personnalisé utilisé par les SDK pour les requêtes sortantes, souvent à des fins de proxy. Doit être un domaine valide (par exemple, example.com ou sub.example.com). Les formats non valides utilisent par défaut la valeur de Kameleoon. | null |
requestBodySizeLimitBytes / request_body_size_limit_bytes (optionnel) | Limite la taille des paquets de tracking (en octets) — fichiers qui stockent les données collectées entre les exécutions de la tâche cron. Dans certains cas, réduire la taille des paquets peut être nécessaire en raison de restrictions serveur ou réseau. La valeur maximale autorisée est de 2,5 Mo (2621440 octets). | 2621440 |
debugMode / debug_mode (obsolète) | Ce paramètre envoie des informations supplémentaires à nos serveurs de tracking pour aider à analyser les problèmes. Il doit normalement être désactivé (false), mais son activation (true) n’a aucun impact sur les performances du SDK. Ce champ est obsolète et sera supprimé dans la version 5.0.0 du SDK. Utilisez plutôt KameleoonLogger::setLogLevel. | false |
Si vous n’utilisez pas le chemin par défaut (/tmp/kameleoon/client-php.json) pour le fichier de configuration, vous devrez :
- passer le chemin de votre fichier de configuration comme troisième argument de la méthode
KameleoonClientFactory::create() ;
- modifier votre entrée crontab pour ajouter l’argument —conf au script de tâche (par exemple, ce serait
bash /usr/local/opt/bin/kameleoon-client-php-process-queries.sh --conf /my/path/kameleoon.json).
Pour en savoir plus sur client_id et client_secret, et sur la façon de les obtenir, consultez l’article Identifiants API. Notez que le SDK PHP Kameleoon utilise l’API Automation et suit le flux d’identifiants client OAuth 2.0.
Initialisation du client Kameleoon
Après avoir installé le SDK dans votre application et configuré les identifiants corrects (dans /tmp/kameleoon/client-php.json), l’étape suivante consiste à créer le client Kameleoon dans le code de votre application. Par exemple :
require "vendor/autoload.php";
use Kameleoon\KameleoonClientConfig;
use Kameleoon\KameleoonClientFactory;
use Kameleoon\Exception\ConfigCredentialsInvalid;
use Kameleoon\Exception\KameleoonException;
use Kameleoon\Exception\SiteCodeIsEmpty;
$siteCode = "a8st4f59bj";
try {
// Read from default configuration path: "/tmp/kameleoon/php-client/"
$kameleoonClient = KameleoonClientFactory::create($siteCode);
} catch (SiteCodeIsEmpty $ex) {
// indicates that provided site code is empty
} catch (ConfigCredentialsInvalid $ex) {
// indicates that provided clientId / clientSecret are not valid
} catch (KameleoonException $ex) {
// probably indicates that the SDK is unable to access the **Kameleoon working directory**
}
try {
$kameleoonClient = KameleoonClientFactory::create($siteCode, "custom/file/path/client-php.json");
} catch (SiteCodeIsEmpty $ex) {
// indicates that provided site code is empty
} catch (ConfigCredentialsInvalid $ex) {
// indicates that provided clientId / clientSecret are not valid
} catch (KameleoonException $ex) {
// probably indicates that the SDK is unable to access the **Kameleoon working directory**
}
try {
$cookieOptions = KameleoonClientConfig::createCookieOptions(
"example.com", // domain: optional, but strictly recommended
false, // secure: optional (false by default)
false, // httponly: optional (false by default)
"Lax" // samesite: optional (Lax by default)
);
$config = new KameleoonClientConfig(
"<clientId>", // clientId: mandatory
"<clientSecret>", // clientSecret: mandatory
"/tmp/kameleoon/php-client/", // kameleoonWorkDir: optional / ("/tmp/kameleoon/php-client/" by default)
60, // refreshIntervalMinute: in minutes, optional (60 minutes by default)
10_000, // defaultTimeoutMillisecond: in milliseconds, optional (10_000 ms by default)
false, // debugMode: optional (false by default)
$cookieOptions, // cookieOptions: optional
"development", // environment: optional ("production" by default)
"example.com", // networkDomain: optional (null by default)
1024*1024, // requestBodySizeLimitBytes: optional (2560 * 1024 by default)
);
$kameleoonClient = KameleoonClientFactory::createWithConfig($siteCode, $config);
} catch (SiteCodeIsEmpty $ex) {
// indicates that provided site code is empty
} catch (ConfigCredentialsInvalid $ex) {
// indicates that provided clientId / clientSecret are not valid
} catch (KameleoonException $ex) {
// probably indicates that the SDK is unable to access the **Kameleoon working directory**
}
Un KameleoonClient est un objet singleton qui sert de pont entre votre application et la plateforme Kameleoon. Il inclut toutes les méthodes et propriétés dont vous avez besoin pour exécuter une expérience. Notez que le SDK prend ses paramètres dans un fichier de configuration. Par défaut, le chemin /tmp/kameleoon/client-php.json sera utilisé, mais vous pouvez utiliser un chemin différent pour le fichier de configuration en fournissant un troisième argument optionnel à la méthode KameleoonClientFactory::create().
Il est de votre responsabilité en tant que développeur d’application d’utiliser une logique correcte dans le code de votre application dans le contexte des A/B test via Kameleoon. Une bonne pratique consiste à toujours supposer que le visiteur actuel peut être exclu de l’expérience car celle-ci n’a pas encore été lancée. Exclure le visiteur actuel est simple, car cela correspond à la mise en œuvre de la logique de variation par défaut / de référence. Les exemples de code du paragraphe suivant illustrent une telle approche.
Activation d’un feature flag
Attribution d’un ID unique à un utilisateur
Pour attribuer un ID unique à un utilisateur, vous pouvez utiliser la méthode getVisitorCode(). Si un visitor code n’existe pas (à partir du cookie des en-têtes de requête), la méthode génère un ID unique aléatoire ou utilise un defaultVisitorCode que vous auriez généré. L’ID est ensuite défini dans un cookie des en-têtes de réponse.
Si vous utilisez Kameleoon en mode hybride, appeler la méthode getVisitorCode() garantit que l’ID unique (visitor code) est partagé entre le fichier d’application engine.js (anciennement nommé kameleoon.js) et le SDK.
Récupération de la configuration d’un flag
Pour mettre en œuvre 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 sur la base du 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 attribuant la variation et en la renvoyant sur la base du 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 à des 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 attribuée et son expérience associée. Cette méthode vérifie si l’utilisateur est ciblé, trouve la variation attribuée au visiteur et la sauvegarde dans le stockage. Lorsque track=true, le SDK enverra l’événement d’exposition à l’expérience spécifiée lors de l’une des prochaines requêtes de tracking, qui est automatiquement effectuée par la tâche cron. Par défaut, son intervalle est de 1 minute.
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 Kameleoon engine, 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 voulez en savoir plus sur le fonctionnement du tracking, consultez cet article
Ajout de points de données pour cibler un utilisateur ou filtrer / segmenter les visites dans les rapports
Pour cibler un utilisateur, assurez-vous d’avoir ajouté 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 les données des serveurs de manière asynchrone. 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 attribuer une variation donnée à un utilisateur.
Pour en savoir plus sur les conditions de ciblage disponibles, consultez l’article détaillé sur le sujet.
De plus, les points de données que vous ajoutez au profil du visiteur seront disponibles lors de l’analyse de vos expériences, vous permettant de filtrer et de segmenter vos résultats par des facteurs tels que l’appareil et le navigateur. Le mode hybride de Kameleoon collecte automatiquement une variété de points de données côté client, ce qui facilite la segmentation de vos résultats sur la base de ces points de données pré-collectés. Consultez la liste complète ici.
Si vous devez suivre des points de données supplémentaires au-delà de ce qui est automatiquement collecté, 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.
Suivi des conversions d’objectif
Lorsqu’un utilisateur effectue une action souhaitée (comme un achat), elle est enregistrée comme une conversion. Pour suivre les conversions, utilisez la méthode trackConversion() et fournissez les paramètres visitorCode et goalId requis.
La requête de suivi de conversion sera envoyée avec la prochaine requête de tracking programmée, que le SDK envoie à intervalles réguliers (définis dans la crontab d’intervalle de tracking). Si vous préférez envoyer la requête immédiatement, utilisez la méthode flush() avec le paramètre instant=true.
Envoi d’événements vers les solutions d’analyse
Pour suivre les conversions et envoyer des événements d’exposition à votre solution d’analyse client, vous devez d’abord mettre en œuvre Kameleoon en mode hybride. Ensuite, utilisez la méthode getEngineTrackingCode().
La méthode getEngineTrackingCode() récupère le code de tracking unique nécessaire pour envoyer des événements d’exposition à votre solution d’analyse. L’utilisation de cette méthode vous permet d’enregistrer des événements et de les envoyer à votre plateforme d’analyse souhaitée.
Expérimentation cross-device
Pour prendre en charge les visiteurs qui accèdent à une application depuis plusieurs appareils, Kameleoon permet la synchronisation des données visiteur précédemment collectées sur chacun des appareils du visiteur ainsi que la réconciliation de leur historique de visites entre les appareils grâce à l’expérimentation cross-device. Des études de cas et des informations détaillées sur la manière dont Kameleoon gère les données entre les appareils sont disponibles dans l’article sur l’expérimentation cross-device.
Synchronisation des custom data entre les appareils
Bien que la synchronisation des mappings personnalisés soit utilisée pour aligner les données visiteur entre les appareils, elle n’est pas toujours nécessaire. Voici deux scénarios dans lesquels la synchronisation des mappings personnalisés n’est pas requise :
Même ID utilisateur sur tous les appareils
Si le même ID utilisateur est utilisé de manière cohérente sur tous les appareils, la synchronisation est gérée automatiquement sans synchronisation de mapping personnalisé. Il suffit d’appeler la méthode getRemoteVisitorData() lorsque vous souhaitez synchroniser les données collectées entre plusieurs appareils.
Instances multi-serveurs avec des ID cohérents
Dans des configurations complexes impliquant plusieurs serveurs (par exemple, des instances de serveurs distribués), où le même ID utilisateur est disponible sur tous les serveurs, la synchronisation entre 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 plus d’informations. 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 la portée Visitor pour vos custom data.
// In this example, Custom data with index `90` was set to "Visitor" scope on Kameleoon.
const VISITOR_SCOPE_CUSTOM_DATA_INDEX = 90;
$kameleoonClient->addData($visitorCode, new CustomData(VISITOR_SCOPE_CUSTOM_DATA_INDEX, "your data"));
$kameleoonClient->flush($visitorCode);
// Call the `getRemoteVisitorData` method before working with the data.
$kameleoonClient->getRemoteVisitorData($visitorCode);
// After the call, the SDK on Device B will have access to CustomData of Visitor scope defined on Device A.
// So, "your data" will be available to target and track the visitor.
Utilisation des custom data pour la fusion de sessions
L’expérimentation cross-device permet de combiner l’historique d’un visiteur sur chacun de ses appareils (réconciliation d’historique). La réconciliation d’historique permet de fusionner différentes sessions de visiteurs en une seule. Pour réconcilier l’historique des visites, utilisez CustomData pour fournir un identifiant unique pour le visiteur. Pour plus d’informations, consultez la documentation dédiée.
Une fois la réconciliation cross-device activée, l’appel de getRemoteVisitorData() avec le paramètre userId récupère toutes les données connues pour un utilisateur donné.
Les sessions ayant le même identifiant se verront toujours présenter la même variation dans une expérience. Dans la vue Visiteur des pages de résultats de votre expérience, ces sessions apparaîtront comme un visiteur unique.
La configuration du SDK garantit que les sessions associées voient toujours la même variation de l’expérience. Cependant, il existe certaines limitations concernant l’allocation cross-device des variations. Ces limitations sont décrites ici.
Suivez le guide d’activation de la réconciliation d’historique cross-device pour configurer vos custom data sur la plateforme Kameleoon.
Ensuite, vous pouvez utiliser le SDK normalement. Les méthodes suivantes peuvent être utiles dans le contexte de la fusion de sessions :
getRemoteVisitorData() avec l’ajout de UniqueIdentifier(true) - pour récupérer les données de tous les visiteurs liés.
trackConversion() ou flush() avec l’ajout de la donnée UniqueIdentifier(true) - pour suivre certaines données pour un visiteur spécifique 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.
const MAPPING_INDEX = 91;
const 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.
$anonymousVariation = $kameleoonClient->getVariation($anonymousVisitorCode, FEATURE_KEY);
// 2. After the visitor is authenticated
// Assume `userId` is the authenticates visitor's visitor code.
$kameleoonClient->addData($anonymousVisitorCode, new CustomData(MAPPING_INDEX, $userId));
$kameleoonClient->flush($anonymousVisitorCode, null, null, true);
// Indicate that `userId` is a unique identifier.
$kameleoonClient->addData($userId, new UniqueIdentifier(true));
// 3. After the visitor has been authenticated
// Retrieve the variation for the `userId`, which will match the anonymous visitor code's variation.
$userVariation = $kameleoonClient->getVariation($userId, FEATURE_KEY);
$isSameVariation = $userVariation->key == $anonymousVariation->key; // true
// The `userId` and `anonymousVisitorCode` are now linked and tracked as a single visitor.
$kameleoonClient->trackConversion($userId, 123, 10.0);
// Additionally, the linked visitors will share all fetched remote visitor data.
$kameleoonClient->getRemoteVisitorData($userId);
Dans cet exemple, l’application a une page de connexion. Comme l’ID utilisateur est inconnu au moment de la connexion, un identifiant anonyme de visiteur généré par la méthode getVisitorCode() est utilisé. Une fois l’utilisateur connecté, le visiteur anonyme est associé à l’ID utilisateur et utilisé comme identifiant unique pour le visiteur.
Utilisation d’une clé de bucketing personnalisée
Par défaut, Kameleoon utilise un ID de visiteur unique et anonyme (visitorCode) pour attribuer les utilisateurs aux variations de feature flag. Cet ID est généralement généré et stocké sur l’appareil de l’utilisateur (dans un cookie de navigateur pour les SDK côté client et côté serveur, et dans un stockage persistant pour les SDK mobiles). Cependant, dans certains scénarios, vous pouvez avoir besoin de garantir que tous les utilisateurs d’une même organisation voient la même variante d’un feature flag.
L’option Clé de bucketing personnalisée vous permet de remplacer ce comportement par défaut en fournissant votre propre identifiant personnalisé pour le bucketing. Ce remplacement garantit que la logique d’attribution de Kameleoon utilise votre clé spécifiée à la place du visitorCode par défaut.
Cas d’utilisation
L’utilisation d’une clé de bucketing personnalisée est essentielle pour maintenir la cohérence et la précision dans vos attributions de feature flag, en particulier dans ces situations :
- Expériences au niveau du compte ou de l’organisation : Pour les produits B2B ou les scénarios où vous souhaitez attribuer tous les utilisateurs d’une même organisation à la même variation, vous pouvez utiliser un identifiant comme
accountId. Les clés de bucketing personnalisées sont cruciales pour les A/B test de fonctionnalités qui impactent toute une équipe ou entreprise.
En mettant en œuvre une clé de bucketing personnalisée, vous garantissez une plus grande cohérence et précision dans vos expériences, ce qui conduit à des résultats plus fiables et à une meilleure expérience utilisateur.
Détails techniques
Lorsque vous configurez une clé de bucketing personnalisée pour un feature flag, vous fournissez à Kameleoon un identifiant spécifique provenant des données de votre application :
$kameleoonClient->addData($visitorCode, new Kameleoon\Data\CustomData(1, "newVisitorCode"));
- Fourniture de 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 clé de bucketing personnalisée choisie en tant qu’objet CustomData. Ici, newVisitorCode fait référence à l’identifiant que vous souhaitez utiliser pour votre bucketing (par exemple, le nouveau userId ou accountId).
Pour que la clé de bucketing personnalisée fonctionne correctement, elle doit également être définie et configurée pour le feature flag lors 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 configuration dans Kameleoon, consultez cet article.
- Logique de bucketing : Une fois qu’une clé de bucketing personnalisée est fournie via la méthode
addData(), tous les calculs de hash pour attribuer les utilisateurs aux variations utiliseront ce newVisitorCode (votre clé personnalisée) au lieu du visitorCode par défaut. L’utilisation du newVisitorCode signifie que la décision de bucketing est liée à votre identifiant personnalisé, garantissant des attributions cohérentes dans divers contextes où cet identifiant est présent.
- Suivi des données et analyses : 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 vos analyses reflètent avec précision les parcours utilisateur individuels et les interactions dans le contexte plus large de votre expérience, même lorsque le bucketing est effectué à un niveau supérieur (comme un compte) ou sur plusieurs appareils/sessions. Vos données visiteur originales restent intactes pour des rapports complets.
Exigences techniques
Pour utiliser efficacement une clé de bucketing personnalisée :
- La clé doit être de type
string.
- Elle doit être unique pour l’entité que vous souhaitez 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 du feature flag est évaluée pour cet utilisateur ou cette requête.
Conditions de ciblage
Les SDK Kameleoon prennent en charge une variété de conditions de ciblage prédéfinies que vous pouvez utiliser pour cibler les utilisateurs dans vos campagnes. Pour la liste des conditions prises en charge par ce SDK, consultez utiliser l’historique des visites pour cibler les utilisateurs.
Vous pouvez également utiliser vos propres données externes pour cibler les utilisateurs.
Logging
Le SDK génère des logs pour refléter divers processus internes et problèmes.
Niveaux de log
Le SDK prend en charge la configuration de la limitation des logs par un niveau de log.
use Kameleoon\logging\KameleoonLogger;
use Kameleoon\logging\LogLevel;
// The `NONE` log level does not allow logging.
KameleoonLogger::setLogger(LogLevel::NONE);
// The `ERROR` log level only allows logging issues that may affect the SDK's primary behavior.
KameleoonLogger::setLogger(LogLevel::ERROR);
// The `WARNING` log level allows logging issues which may require additional attention.
// It extends the `ERROR` log level.
// The `WARNING` log level is a default log level.
KameleoonLogger::setLogger(LogLevel::WARNING);
// The `INFO` log level allows logging general information on the SDK's internal processes.
// It extends the `WARNING` log level.
KameleoonLogger::setLogger(LogLevel::INFO);
// The `DEBUG` level logs additional details about the SDK’s internal processes and extends the `INFO` level
// with more granular. diagnostic output.
// This information is not intended for end-user interpretation but can be sent to our support team
// to assist with internal troubleshooting.
KameleoonLogger::setLogger(LogLevel::DEBUG);
Gestion personnalisée des logs
Le SDK écrit ses logs sur la sortie console par défaut. Ce comportement peut être remplacé.
La limitation des logs par un niveau de log est effectuée indépendamment de la logique de gestion des logs.
use Kameleoon\logging\KameleoonLogger;
use Kameleoon\logging\Logger;
use Kameleoon\logging\LogLevel;
use Monolog\Logger as MonologLogger;
public class CustomLogger implements Logger {
// Monolog logger
private MonologLogger $inner;
public function __construct(MonologLogger $inner)
{
$this->inner = $inner;
}
// `log` method accepts logs from the SDK
public function log($level, string $message): void
{
// Custom log handling logic here. For example:
switch ($level) {
case LogLevel::ERROR:
$this->inner->error($message);
break;
case LogLevel::WARNING:
$this->inner->warning($message);
break;
case LogLevel::INFO:
$this->inner->info($message);
break;
case LogLevel::DEBUG:
$this->inner->debug($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.
KameleoonLogger::setLogLevel(LogLevel::DEBUG); // Optional; defaults to `LogLevel::WARNING`.
KameleoonLogger::setLogger(new CustomLogger($inner));
Reference
Voici la documentation de référence complète du SDK PHP.
Initialisation
create()
Cette méthode de Kameleoon\KameleoonClientFactory crée une instance KameleoonClient en fournissant votre configuration de SDK dans un fichier de configuration. Vous devez initialiser le SDK en créant cette instance de KameleoonClient avant de pouvoir utiliser les autres méthodes du SDK. Toutes les interactions avec le SDK utilisent cette instance KameleoonClient. Pour fournir la configuration en tant qu’objet KameleoonClientConfig à la place, consultez la méthode createWithConfig.
require "vendor/autoload.php";
use Kameleoon\KameleoonClientFactory;
use Kameleoon\Exception\ConfigCredentialsInvalid;
use Kameleoon\Exception\KameleoonException;
use Kameleoon\Exception\SiteCodeIsEmpty;
$siteCode = "a8st4f59bj";
try {
// Read from default configuration path: "/tmp/kameleoon/php-client/"
$kameleoonClient = KameleoonClientFactory::create($siteCode);
} catch (SiteCodeIsEmpty $ex) {
// indicates that provided site code is empty
} catch (ConfigCredentialsInvalid $ex) {
// indicates that provided clientId / clientSecret are not valid
} catch (KameleoonException $ex) {
// probably indicates that the SDK is unable to access the **Kameleoon working directory**
}
try {
$kameleoonClient = KameleoonClientFactory::create($siteCode, "custom/file/path/client-php.json");
} catch (SiteCodeIsEmpty $ex) {
// indicates that provided site code is empty
} catch (ConfigCredentialsInvalid $ex) {
// indicates that provided clientId / clientSecret are not valid
} catch (KameleoonException $ex) {
// probably indicates that the SDK is unable to access the **Kameleoon working directory**
}
Arguments
| Nom | Type | Description |
|---|
| siteCode | String | Il s’agit d’une clé unique du projet Kameleoon que vous utilisez avec le SDK. Ce champ est obligatoire. |
| configurationFilePath | String | Chemin vers le fichier de configuration du SDK. Ce champ est optionnel et défini à /tmp/kameleoon/client-php.json par défaut. |
Valeur de retour
| Type | Description |
|---|
| Kameleoon\KameleoonClient | Une instance de la classe KameleoonClient qui sera utilisée pour gérer vos expériences et feature flags. |
Exceptions levées
| Type | Description |
|---|
| SiteCodeIsEmpty | Exception indiquant que les identifiants demandés n’ont pas été fournis (soit via le fichier de configuration, soit via le paramètre config de la méthode). |
| ConfigCredentialsInvalid | Exception indiquant que les identifiants demandés n’ont pas été fournis (soit via le fichier de configuration, soit via le paramètre config de la méthode). |
| KameleoonException | Exception pouvant indiquer que le SDK ne peut pas accéder au répertoire de travail Kameleoon. |
createWithConfig()
Cette méthode de Kameleoon\KameleoonClientFactory crée une instance KameleoonClient et vous permet de passer votre configuration de SDK dans un objet KameleoonClientConfig. Vous devez initialiser le SDK en créant cette instance KameleoonClient avant de pouvoir utiliser les autres méthodes du SDK. Toutes les interactions avec le SDK utilisent cette instance KameleoonClient. Pour fournir votre configuration de SDK dans un fichier à la place, utilisez la méthode create.
require "vendor/autoload.php";
use Kameleoon\KameleoonClientConfig;
use Kameleoon\KameleoonClientFactory;
use Kameleoon\Exception\ConfigCredentialsInvalid;
use Kameleoon\Exception\KameleoonException;
use Kameleoon\Exception\SiteCodeIsEmpty;
$siteCode = "a8st4f59bj";
try {
$cookieOptions = KameleoonClientConfig::createCookieOptions(
"example.com", // domain: optional, but strictly recommended
false, // secure: optional (false by default)
false, // httponly: optional (false by default)
"Lax" // samesite: optional (Lax by default)
);
$config = new KameleoonClientConfig(
"<clientId>", // clientId: mandatory
"<clientSecret>", // clientSecret: mandatory
"/tmp/kameleoon/php-client/", // kameleoonWorkDir: optional / ("/tmp/kameleoon/php-client/" by default)
60, // refreshIntervalMinute: in minutes, optional (60 minutes by default)
10_000, // defaultTimeoutMillisecond: in milliseconds, optional (10_000 ms by default)
false, // debugMode: optional (false by default)
$cookieOptions, // cookieOptions: optional
"development", // environment: optional ("production" by default)
"example.com", // networkDomain: optional (null by default)
1024*1024, // requestBodySizeLimitBytes: optional (2560 * 1024 by default)
);
$kameleoonClient = KameleoonClientFactory::create($siteCode, $config);
} catch (SiteCodeIsEmpty $ex) {
// indicates that provided site code is empty
} catch (ConfigCredentialsInvalid $ex) {
// indicates that provided clientId / clientSecret are not valid
} catch (KameleoonException $ex) {
// probably indicates that the SDK is unable to access the **Kameleoon working directory**
}
Arguments
| Nom | Type | Description |
|---|
| siteCode | String | Code du site web sur lequel vous souhaitez exécuter des expériences. Cet ID de code unique se trouve dans l’application Kameleoon. Ce champ est obligatoire. |
| kameleoonConfig | KameleoonClientConfig | Objet de configuration du SDK que vous transmettez. Ce champ est optionnel. |
Valeur de retour
| Type | Description |
|---|
| KameleoonClient | Une instance de la classe KameleoonClient que vous utilisez pour gérer vos expériences et feature flags. |
Exceptions levées
| Type | Description |
|---|
| SiteCodeIsEmpty | Exception indiquant que les identifiants demandés n’ont pas été fournis (soit via le fichier de configuration, soit via le paramètre config de la méthode). |
| ConfigCredentialsInvalid | Exception indiquant que les identifiants demandés n’ont pas été fournis (soit via le fichier de configuration, soit via le paramètre config de la méthode). |
| KameleoonException | Exception pouvant indiquer que le SDK ne peut pas accéder au répertoire de travail Kameleoon. |
Feature flags et variations
isFeatureActive()
- 📨 Envoie des données de tracking à Kameleoon (selon le paramètre
track)
Cette méthode s’appelait précédemment activateFeature, qui a été supprimée dans la version 4.0.0 du SDK.
Cette méthode prend un visitorCode et un featureKey comme arguments obligatoires pour vérifier si le feature spécifié sera actif pour un utilisateur donné.
Si un tel utilisateur n’a jamais été associé à ce feature flag, le SDK renvoie une valeur booléenne aléatoirement (true si l’utilisateur doit avoir ce feature ou false sinon). Si un utilisateur avec un visitorCode donné est déjà enregistré avec ce feature flag, il détectera la valeur précédente du FeatureFlag.
Vous devez vous assurer qu’une gestion appropriée des erreurs est mise en place dans votre code comme indiqué dans l’exemple à droite pour intercepter les exceptions potentielles.
Si vous spécifiez un visitorCode, la méthode isFeatureActive() l’utilise comme identifiant unique de visiteur, ce qui est utile pour l’expérimentation cross-device. Lorsque vous spécifiez un visitorCode et définissez le paramètre isUniqueIdentifier à true, le SDK lie les données envoyées au visiteur associé à l’identifiant spécifié.
Le paramètre isUniqueIdentifier est obsolète. Veuillez utiliser UniqueIdentifier à la place.Le paramètre isUniqueIdentifier peut également être utile dans d’autres scénarios particuliers, par exemple lorsque vous ne pouvez pas accéder au visitorCode anonyme initialement attribué au visiteur, mais que vous avez accès à un ID interne connecté au visiteur anonyme à l’aide des fonctionnalités de fusion de sessions.
Kameleoon utilise le tracking pour compter les sessions et les visiteurs lorsque vous appelez certaines méthodes, telles que isFeatureActive(), getVariation() ou getVariations().Utilisez la valeur par défaut true pour le paramètre track lorsque vous exposez les visiteurs à une variation et avez besoin de les compter. Définissez le paramètre track à false uniquement si vous appelez ces méthodes avant d’exposer les visiteurs.Par exemple, si vous appelez getVariations() pour récupérer toutes les variations avant d’exposer les visiteurs, définissez le paramètre track à false. Ce réglage empêche Kameleoon de compter prématurément une session. Vous pouvez ensuite déclencher le tracking plus tard lorsque vous exposez explicitement le visiteur.Kameleoon envoie les données de tracking toutes les secondes par défaut. Vous pouvez configurer cet intervalle jusqu’à cinq secondes à l’aide de l’option de configuration de l’intervalle de tracking. Kameleoon regroupe les événements de tracking en une seule session tant que l’intervalle entre les événements est inférieur à 30 minutes. Si plus de 30 minutes s’écoulent entre les événements de tracking, Kameleoon compte les événements comme des sessions distinctes. Une visite apparaît dans vos rapports 30 minutes après le dernier événement enregistré dans la session.
$visitorCode = $kameleoonClient->getVisitorCode();
$featureKey = "new_checkout";
$hasNewCheckout = false;
try {
$hasNewCheckout = $kameleoonClient->isFeatureActive($visitorCode, $featureKey, $timeout);
// disabling tracking
$hasNewCheckout = $kameleoonClient->isFeatureActive($visitorCode, $featureKey, $timeout, null, false);
} catch (Kameleoon\Exception\FeatureNotFound $e) {
// Feature toggle not yet activated on Kameleoon's side - we consider the feature inactive.
$hasNewCheckout = false;
} catch (Kameleoon\Exception\VisitorCodeInvalid $e) {
// VisitorCode, which you passed to a method, is invalid and can't be accepted.
} catch (Kameleoon\Exception\DataFileInvalid $e) {
// It appears that the configuration has not been loaded and
// there is no previously saved version of the configuration available.
} catch (Exception $e) {
// This is a generic Exception handler which will handle all exceptions.
echo "Exception: ", $e->getMessage(), "\n";
}
if ($hasNewCheckout) {
// Implement new checkout code here.
}
La méthode isFeatureActive() évalue la variante servie, pas l’état du master flag. Si vous excluez des règles, la méthode utilise l’état par défaut Then, for everyone else serve. Si vous sélectionnez Off pour cet état par défaut, la méthode renvoie toujours false même lorsque le master feature flag est On.
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. |
| timeout | ?int | Délai d’expiration (en millisecondes). Ce paramètre spécifie la durée maximale pendant laquelle la méthode peut bloquer en attente d’un résultat. Ce champ est optionnel. Si aucune valeur de délai n’est fournie, le SDK utilise le default_timeout spécifié dans votre configuration. |
| isUniqueIdentifier (Obsolète) | ?bool | 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 null. Le champ est optionnel. |
| track | bool | Paramètre optionnel pour activer ou désactiver le tracking de l’évaluation du feature (true par défaut). |
Valeur de retour
| Type | Description |
|---|
| bool | Valeur du feature flag qui est enregistrée pour un visitorCode donné. |
Exceptions levées
| Type | Description |
|---|
| FeatureNotFound | Exception indiquant que l’ID du feature demandé n’a pas été trouvé dans la configuration interne du SDK. Cela est généralement normal et signifie que le feature flag n’a pas encore été activé du côté Kameleoon (mais le code mettant en œuvre le feature est déjà déployé du côté de l’application web). |
| VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide (vide ou plus long que 255 caractères). |
| DataFileInvalid | Exception indiquant que la configuration n’a pas été chargée et qu’aucune version précédemment sauvegardée de la configuration n’est disponible. |
getVariation()
- 📨 Envoie des données de tracking à Kameleoon (selon le paramètre
track)
Récupère la Variation attribuée à un visiteur donné pour un feature flag spécifique.
Cette méthode prend un visitorCode et un featureKey comme arguments obligatoires. L’argument track est optionnel et vaut true par défaut.
Elle renvoie la Variation attribuée au visiteur. Si le visiteur n’est associé à aucune règle de feature flag, la méthode renvoie la Variation par défaut pour le feature flag donné.
Assurez-vous qu’une gestion appropriée des erreurs est mise en œuvre dans votre code pour gérer les exceptions potentielles.
La variation par défaut fait référence à la variation attribuée à un visiteur lorsqu’il ne correspond à aucune règle de livraison prédéfinie pour un feature flag. En d’autres termes, c’est la variation de repli appliquée à tous les utilisateurs qui ne sont pas ciblés par des règles spécifiques. Elle est représentée comme la variation dans la section « Then, for everyone else… » d’une interface de gestion.
$featureKey = "new_checkout";
try {
$variation = $kameleoonClient->getVariation($visitorCode, $featureKey);
// disabling tracking
$variation = $kameleoonClient->getVariation($visitorCode, $featureKey, false);
} catch (Kameleoon\Exception\FeatureNotFound $e) {
// An error has occurred; the feature flag isn't found in the current configuration.
} catch (Kameleoon\Exception\FeatureEnvironmentDisabled $e) {
// The feature flag is disabled for the environment.
} catch (Kameleoon\Exception\VisitorCodeInvalid $e) {
// The visitor code you passed to the method is invalid and can't be accepted by the SDK.
}
// Fetch a variable value for the assigned variation
$title = $variation->variables["title"]->value;
switch ($variation->key) {
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 | Par défaut |
|---|
| visitorCode (obligatoire) | string | Identifiant unique du visiteur. | |
| featureKey (obligatoire) | string | Clé du feature que vous souhaitez exposer à un visiteur. | |
| track (optionnel) | bool | Paramètre optionnel pour activer ou désactiver le tracking de l’évaluation du feature. | true |
Valeur de retour
| Type | Description |
|---|
Variation | Une Variation attribuée à un visiteur donné pour un feature flag spécifique. |
Exceptions levées
| 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 le code mettant en œuvre 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 attribués à un visiteur donné sur tous les feature flags.
Cette méthode itère sur tous les feature flags disponibles et renvoie la Variation attribuée pour chaque flag associé au visiteur spécifié. Elle prend visitorCode comme argument obligatoire, tandis que onlyActive et track sont optionnels.
- Si
onlyActive est défini à true, la méthode getVariations() renverra les variations de feature flags à condition que l’utilisateur ne soit pas bucketé avec la variation off.
- Le paramètre
track contrôle si la méthode suit ou non les attributions de variation. Par défaut, il est défini à true. S’il est défini à false, le tracking sera désactivé.
La map retournée se compose de feature flag keys comme clés et de leur Variation correspondante comme valeurs. Si aucune variation n’est attribuée pour un feature flag, la méthode renvoie la Variation par défaut pour ce flag.
Une gestion appropriée des erreurs doit être mise en œuvre pour gérer les exceptions potentielles.
La variation par défaut fait référence à la variation attribuée à un visiteur lorsqu’il ne correspond à aucune règle de livraison prédéfinie pour un feature flag. En d’autres termes, c’est la variation de repli appliquée à tous les utilisateurs qui ne sont pas ciblés par des règles spécifiques. Elle est représentée comme la variation dans la section « Then, for everyone else… » d’une interface de gestion.
try {
$variations = $kameleoonClient->getVariations($visitorCode);
// only active variations
$variations = $kameleoonClient->getVariations($visitorCode, true);
// disable tracking
$variations = $kameleoonClient->getVariations($visitorCode, $onlyActive, false);
} catch (Kameleoon\Exception\VisitorCodeInvalid $e) {
// Handle exception
}
Arguments
| Nom | Type | Description | Par défaut |
|---|
| visitorCode (obligatoire) | string | Identifiant unique du visiteur. | |
| onlyActive (optionnel) | bool | Paramètre optionnel indiquant s’il faut retourner les variations des feature flags actifs (true) ou de tous les feature flags (false). | false |
| track (optionnel) | bool | Paramètre optionnel pour activer ou désactiver le tracking de l’évaluation du feature. | true |
Valeur de retour
| Type | Description |
|---|
array<string, Types\Variation> | Map qui contient les objets Variation attribués des feature flags en utilisant les clés des features correspondants. |
Exceptions levées
| 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’attribuer 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 nécessaire 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. Des processus tels que la segmentation, les conditions de ciblage et les calculs algorithmiques sont ignorés. Pour préserver la segmentation et les conditions de ciblage pendant une expérience, définissez 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 intégralement traité et terminé en premier.
Une variation forcée est traitée de la même manière qu’une variation évaluée. Elle est suivie dans les analyses et stockée dans le contexte utilisateur comme toute variation évaluée standard, garantissant la cohérence du reporting.
La méthode peut lever des exceptions sous certaines conditions (par exemple, paramètres invalides, contexte utilisateur ou problèmes internes). Une gestion appropriée des exceptions est essentielle pour garantir que votre application reste stable et résiliente.
Il est important de distinguer les variations forcées des variations simulées :
- Variations forcées : sont spécifiques à une expérience individuelle.
- Variations simulées : affectent le résultat global du feature flag.
$experimentId = 9516;
try {
// Forcing the variation "on" for the experiment 9516 for the visitor
$kameleoonClient->setForcedVariation($visitorCode, $experimentId, "on");
// Forcing the variation "on" while preserving segmentation and targeting conditions during the experiment
$kameleoonClient->setForcedVariation($visitorCode, $experimentId, "on", false);
// Resetting the forced variation for the experiment 9516 for the visitor
$kameleoonClient->setForcedVariation($visitorCode, $experimentId, null);
} catch (Kameleoon\Exception\KameleoonException $e) {
// Handling the error
}
Arguments
| Nom | Type | Description | Par 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 devrait être forcée comme valeur retournée pour l’expérience. Si la valeur est null, la variation forcée sera réinitialisée. | |
| forceTargeting (optionnel) | bool | Indique si le ciblage de l’expérience doit être forcé et ignoré (true) ou appliqué comme dans le processus d’évaluation standard (false). | true |
| timeout (optionnel) | ?int | Délai d’expiration (en millisecondes). Ce paramètre spécifie la durée maximale pendant laquelle la méthode peut bloquer en attente d’un résultat. Si aucune valeur de délai n’est fournie, le SDK utilise le default_timeout spécifié dans votre configuration. | null |
Exceptions levées
| 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. Cela est généralement normal et signifie que l’expérience correspondant à la règle n’a pas encore été activée du côté Kameleoon. |
FeatureVariationNotFound | Exception indiquant que la variation key (id) demandée n’a pas été trouvée dans la configuration interne du SDK. Cela est généralement normal et signifie que l’expérience correspondant à la variation n’a pas encore été activée du côté 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 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 attribution précise des audiences en fonction de 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 (Kameleoon\Exception\KameleoonException $e) {
// Handling the exception
}
Arguments
| Nom | Type | Description | Par défaut |
|---|
| visitorCode (obligatoire) | string | Identifiant unique du visiteur. | |
| timeout (optionnel) | ?int | Délai d’expiration (en millisecondes). Ce paramètre spécifie la durée maximale pendant laquelle la méthode peut bloquer en attente d’un résultat. Si aucune valeur de délai n’est fournie, le SDK utilise le default_timeout spécifié dans votre configuration. | null |
Exceptions levées
| 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.
getDataFile()
Pour évaluer tous les feature flags, utilisez getVariations(). Cette méthode est plus efficace que d’appeler DataFile et d’itérer sur les flags avec getVariation().
Renvoie la configuration actuelle du SDK sous la forme d’un objet DataFile.
try {
$dataFile = $kameleoonClient->getDataFile();
} catch (Kameleoon\Exception\KameleoonException $e) {
// Recommended (but optional) safeguard for unexpected exceptions from third-party libraries
}
Arguments
| Nom | Type | Description |
|---|
| timeout (optionnel) | ?int | Délai d’expiration (en millisecondes). Ce paramètre spécifie la durée maximale pendant laquelle la méthode peut bloquer en attente d’un résultat. Si aucune valeur de délai n’est fournie, le SDK utilise le default_timeout spécifié dans votre configuration. |
Valeur de retour
| Type | Description |
|---|
DataFile | Le DataFile contenant la configuration du SDK |
Données visiteur
getVisitorCode()
Cette méthode s’appelait précédemment obtainVisitorCode, qui a été supprimée dans la version 4.0.0 du SDK.
Appelez cette méthode pour obtenir le visitorCode Kameleoon du visiteur actuel. L’appel est particulièrement important lors de l’utilisation de Kameleoon dans un environnement mixte front-end et back-end, où la cohérence de l’identification de l’utilisateur doit être garantie. La logique d’implémentation est décrite ici :
-
Tout d’abord, nous vérifions s’il existe un cookie ou un paramètre de requête kameleoonVisitorCode associé à la requête HTTP actuelle. Si c’est le cas, nous l’utilisons comme identifiant de visiteur.
-
Si aucun cookie ou paramètre n’est présent dans la requête actuelle, nous avons deux options pour générer un identifiant. Une option est de créer un nouvel identifiant aléatoirement, et l’autre est d’utiliser l’argument defaultVisitorCode s’il a été fourni. Cette fonctionnalité permet à nos clients d’entrer leurs propres identifiants comme visitor codes, ce qui peut être bénéfique ; elle correspond de manière transparente aux visiteurs Kameleoon avec leurs propres utilisateurs, éliminant le besoin de recherches supplémentaires dans une table de correspondance.
-
Dans tous les cas, le cookie kameleoonVisitorCode côté serveur (via l’en-tête HTTP) est défini avec la valeur. La méthode renvoie cette valeur de visiteur.
Pour plus d’informations, consultez cet article.
Si vous fournissez votre propre 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 en fonction des données fournies.Vous pouvez appliquer des simulations de deux manières :
- Automatiquement (recommandé) : Si vous utilisez Kameleoon Web Experimentation ou le SDK en mode hybride, le cookie est créé automatiquement lors de la simulation de l’affichage d’une variante à l’aide du Simulation Panel.
- Manuellement : Définissez manuellement le cookie
kameleoonSimulationFFData.
Il est important de distinguer les variations simulées des variations forcées :
- Variations simulées : affectent le résultat global du feature flag.
- Variations forcées : sont spécifiques à une expérience individuelle.
⚙️ Configuration manuelleVeuillez vous assurer que le cookie kameleoonSimulationFFData suit ce format :
kameleoonSimulationFFData={"featureKey":{"expId":10,"varId":20}} : Simule la variation avec varId de l’expérience expId pour le featureKey donné.
kameleoonSimulationFFData={"featureKey":{"expId":0}} : Simule la variation par défaut (définie dans la section Then, for everyone else in Production, serve) pour le featureKey donné.
⚠️ Pour assurer un fonctionnement correct, la valeur du cookie doit être encodée en tant que composant URI à l’aide d’une méthode telle que encodeURIComponent.
require "vendor/autoload.php";
// The cookie's domain must be provided in the configuration file if no argument is given.
$visitorCode = $kameleoonClient->getVisitorCode();
// default visitor code provided
$visitorCode = $kameleoonClient->getVisitorCode($defaultVisitorCode);
Arguments
| Nom | Type | Description |
|---|
| defaultVisitorCode | String | Ce paramètre sera utilisé comme visitorCode si aucun cookie kameleoonVisitorCode existant n’est trouvé dans la requête. Ce champ est optionnel et, par défaut, un visitorCode aléatoire sera généré. |
| timeout | ?int | Délai d’expiration (en millisecondes). Ce paramètre spécifie la durée maximale pendant laquelle la méthode peut bloquer en attente d’un résultat. Ce champ est optionnel. Si aucune valeur de délai n’est fournie, le SDK utilise le default_timeout spécifié dans votre configuration. |
Valeur de retour
| Type | Description |
|---|
| String | Un visitorCode qui sera associé à cet utilisateur particulier et qui devra être utilisé avec la plupart des méthodes du SDK. |
Exceptions levées
| Type | Description |
|---|
| InvalidArgumentException | Exception indiquant que la valeur du domaine du cookie n’a pas été fournie (soit via le fichier de configuration, soit via le paramètre topLevelDomain sur la méthode). |
addData()
La méthode addData() ajoute des données de ciblage au stockage afin que d’autres méthodes puissent utiliser ces données pour décider s’il faut ou non cibler le visiteur actuel.
La méthode addData() ne renvoie aucune valeur et n’interagit pas avec les serveurs back-end Kameleoon de manière autonome. Au lieu de cela, toutes les données déclarées sont sauvegardées pour une transmission future à l’aide de la méthode flush(). Cette approche réduit le nombre d’appels au 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 fait exception. Les visiteurs peuvent avoir une instance de CustomData associée par index.
// Add a single data item (tracked by default)
$kameleoonClient->addData($visitorCode, new Kameleoon\Data\Browser(Kameleoon\Data\Browser::CHROME));
// Add multiple data items (tracked by default)
$kameleoonClient->addData(
$visitorCode,
new Kameleoon\Data\PageView("https://url.com", "title", [3]),
new Kameleoon\Data\UserAgent("UserAgent")
);
// Add multiple data items stored locally for targeting only (not sent to the Kameleoon Data API)
$kameleoonClient->addData(
$visitorCode,
false,
new Kameleoon\Data\PageView("https://url.com", "title", [3]),
new Kameleoon\Data\UserAgent("UserAgent")
);
Arguments
| Nom | Type | Description | Valeur par défaut |
|---|
| visitorCode (obligatoire) | string | Identifiant unique du visiteur. | |
| track (optionnel) | bool | 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 des 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() est responsable de l’envoi des données Kameleoon liées à un visiteur spécifique. Elle déclenche une requête de tracking qui inclut toutes les données précédemment ajoutées avec la méthode addData, qui n’ont pas encore été envoyées lors d’un appel antérieur à l’une des méthodes. flush() est non bloquante, car l’appel serveur est effectué de manière asynchrone, sauf si le paramètre instant est défini à true.
La fonction flush() vous permet de décider quand les données liées à un visitorCode spécifique sont envoyées à nos serveurs. Par exemple, si vous appelez addData() plusieurs fois — disons une douzaine de fois — il serait inefficace d’envoyer des données au serveur à chaque appel. Au lieu de cela, vous pouvez rassembler toutes vos données d’abord, puis appeler flush() une fois à la fin pour tout envoyer en une seule fois.
Si vous spécifiez un visitorCode, la méthode flush() l’utilise comme identifiant unique de visiteur, ce qui est utile pour l’expérimentation cross-device. Lorsque vous spécifiez un visitorCode et définissez le paramètre isUniqueIdentifier à true, le SDK lie les données envoyées au visiteur associé à l’identifiant spécifié.
Le paramètre isUniqueIdentifier est obsolète. Veuillez utiliser UniqueIdentifier à la place.Le paramètre isUniqueIdentifier peut être utile dans des situations uniques ; 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.
$visitorCode = $kameleoonClient->getVisitorCode();
$kameleoonClient->addData(
$visitorCode,
new Kameleoon\Data\Browser(Kameleoon\Data\Browser::CHROME).
new Kameleoon\Data\PageView("https://url.com", "title", array(3)),
new Kameleoon\Data\Conversion(32, 10, false)
);
$kameleoonClient->flush($visitorCode); // Interval tracking, non-blocking operation
$kameleoonClient->flush($visitorCode, null, null, true); // Instant tracking, blocking operation
// if you operate with unique ID
$kameleoonClient->addData($visitorCode, new Kameleoon\Data\UniqueIdentifier(true));
$kameleoonClient->flush($visitorCode);
Arguments
| Nom | Type | Description |
|---|
| visitorCode | string | Identifiant unique de l’utilisateur. Ce champ est obligatoire. |
| timeout | ?int | Délai d’expiration (en millisecondes). Ce paramètre spécifie la durée maximale pendant laquelle la méthode peut bloquer en attente d’un résultat. Ce champ est optionnel. Si aucune valeur de délai n’est fournie, le SDK utilise le default_timeout spécifié dans votre configuration. |
| isUniqueIdentifier (Obsolète) | ?bool | 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 null. Le champ est optionnel. |
| instant | bool | Indicateur booléen indiquant si les données doivent être envoyées instantanément (true) ou selon l’intervalle de tracking programmé (false). S’il n’est pas fourni, la valeur par défaut est false. Ce champ est optionnel. |
getRemoteData()
Cette méthode s’appelait précédemment 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 en fonction d’une clé que vous fournissez pour un siteCode spécifique (défini dans KameleoonClientFactory.create()). Un serveur Kameleoon stocke ces données. La Data API est généralement utilisée pour sauvegarder ces données sur nos serveurs distants. Cette méthode, combinée à nos serveurs évolutifs, facilite le stockage de grandes quantités de données. Vous pouvez ensuite accéder à ces données ultérieurement pour chaque visiteur ou utilisateur.
$test_value = $kameleoonClient->getRemoteData("test"); // default timeout will be used
$test_value = $kameleoonClient->getRemoteData("test", 1000); // 1000 milliseconds timeout
try {
$test_value = $kameleoonClient->getRemoteData("test");
} catch (Exception $e) {
// Timeout or Json Decoding Exception
}
Arguments
| Nom | Type | Description |
|---|
| key | string | La clé à laquelle les données que vous essayez d’obtenir sont associées. Ce champ est obligatoire. |
| timeout | ?int | Délai d’expiration (en millisecondes). Ce paramètre spécifie la durée maximale pendant laquelle la méthode peut bloquer en attente d’un résultat. Ce champ est optionnel. Si aucune valeur de délai n’est fournie, le SDK utilise le default_timeout spécifié dans votre configuration. |
Valeur de retour
| Type | Description |
|---|
| Object | Objet associé à la récupération de données pour une clé spécifique. |
Exceptions levées
| Type | Description |
|---|
| Exception | Exception indiquant que la requête a expiré ou que les données récupérées ne peuvent pas être décodées avec la méthode json_decode. |
getRemoteVisitorData()
getRemoteVisitorData() est une méthode asynchrone permettant de récupérer les Kameleoon Visits Data pour le visitorCode à partir de la Kameleoon Data API. La méthode ajoute des 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 à partir 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 ne convertissent qu’au front-end.
Lisez cet article pour une meilleure compréhension des 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(). Cela 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 paramètre isUniqueIdentifier peut être utile dans des situations uniques ; 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.
$visitorCode = "visitorCode";
// Visitor data will be fetched and automatically added for `visitorCode`
$dataArray = $kameleoonClient->getRemoteVisitorData($visitorCode, null); // default timeout will be used
$dataArray = $kameleoonClient->getRemoteVisitorData($visitorCode, 1000); // 1000 milliseconds timeout
// If you only want to fetch data and add it yourself manually, set shouldAddData == `false`
$dataArray = $kameleoonClient->getRemoteVisitorData($visitorCode, null, false); // default timeout will be used
$dataArray = $kameleoonClient->getRemoteVisitorData($visitorCode, 1000, false); // 1000 milliseconds timeout
Arguments
| Nom | Type | Description |
|---|
| visitorCode | string | Le visitor code pour lequel vous souhaitez récupérer les données attribuées. Ce champ est obligatoire. |
| timeout | ?int | Délai d’expiration (en millisecondes). Ce paramètre spécifie la durée maximale pendant laquelle la méthode peut bloquer en attente d’un résultat. Ce champ est optionnel. Si aucune valeur de délai n’est fournie, le SDK utilise le default_timeout spécifié dans votre configuration. |
| addData | bool | Booléen indiquant si la méthode doit automatiquement ajouter les données récupérées pour un visiteur. Si non spécifié, la valeur par défaut est true. Ce champ est optionnel. |
| filter | Kameleoon\Types\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 (new RemoteVisitorDataFilter(1, true, true) ou new RemoteVisitorDataFilter()). Les autres paramètres du filtre sont définis à false. Ce champ est optionnel. |
| isUniqueIdentifier (Obsolète) | ?bool | 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 null. Le champ est optionnel. |
Valeur de retour
| Type | Description |
|---|
array<Kameleoon\Data> | Une liste de données attribuées au visiteur donné. |
Utilisation des paramètres dans 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 sur la base d’objectifs, d’expériences ou de variations, la même approche s’applique à tous les types de données.
Par exemple, supposons que vous souhaitiez récupérer des données sur les visiteurs qui ont atteint 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é illustrée dans cet exemple ne se limite pas aux données d’objectif. Vous pouvez utiliser les paramètres de 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 | Par défaut |
|---|
| previousVisitAmount (optionnel) | int | Nombre de visites précédentes dont récupérer les données. Nombre entre 1 et 25 | 1 |
| currentVisit (optionnel) | bool | Si true, les données de la visite actuelle seront récupérées | true |
| customData (optionnel) | bool | Si true, les custom data seront récupérées. | true |
| pageViews (optionnel) | bool | Si true, les données de page seront récupérées. | false |
| geolocation (optionnel) | bool | Si true, les données de géolocalisation seront récupérées. | false |
| device (optionnel) | bool | Si true, les données d’appareil seront récupérées. | false |
| browser (optionnel) | bool | Si true, les données de navigateur seront récupérées. | false |
| operatingSystem (optionnel) | bool | Si true, les données de système d’exploitation seront récupérées. | false |
| conversions (optionnel) | bool | Si true, les données de conversion seront récupérées. | false |
| experiments (optionnel) | bool | Si true, les données d’expérience seront récupérées. | false |
| kcs (optionnel) | bool | Si true, le Kameleoon Conversion Score (KCS) sera récupéré. Nécessite le module complémentaire AI Predictive Targeting | false |
| visitorCode (optionnel) | bool | 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 voulez vous assurer que le visiteur, identifié par son visitorCode, reçoit toujours la même variation entre les visites pour l’expérimentation cross-device. | true |
| cbs (optionnel) | bool | Si true, les données de score Contextual Bandit seront récupérées. | false |
| personalization (optionnel) | bool | Si true, les données de personnalisation seront récupérées. Cela est requis pour la condition de personnalisation. | false |
getVisitorWarehouseAudience()
Cette méthode récupère toutes les données d’audience associées au visiteur dans votre data warehouse à l’aide des paramètres visitorCode et warehouseKey spécifiés. La 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 consulter la documentation sur le ciblage warehouse pour plus de détails. La méthode transmet le résultat au future retourné sous la forme d’un objet CustomData, confirmant que la donnée a été ajoutée au visiteur et est disponible à des fins de ciblage.
$warehouseAudienceCustomData = $kameleoonClient->getVisitorWarehouseAudience($visitorCode, $customDataIndex);
// If you need to specify warehouse key
$warehouseAudienceCustomData = $kameleoonClient->getVisitorWarehouseAudience(
$visitorCode, $customDataIndex, $warehouseKeyValue
);
// If you need to specify warehouse key & timeout
$warehouseAudienceCustomData = $kameleoonClient->getVisitorWarehouseAudience(
$visitorCode, $customDataIndex, $warehouseKeyValue, 2000
);
Arguments
| Nom | Type | Description |
|---|
| visitorCode | string | L’identifiant unique du visiteur pour lequel vous souhaitez récupérer et ajouter les données. |
| customDataIndex | int | Un entier représentant l’index de la custom data que vous souhaitez utiliser pour cibler vos BigQuery Audiences. |
| warehouseKey | string | La clé unique permettant d’identifier les données du warehouse (généralement, votre ID utilisateur interne). Ce champ est optionnel. |
| timeout | ?int | Délai d’expiration (en millisecondes). Ce paramètre spécifie la durée maximale pendant laquelle la méthode peut bloquer en attente d’un résultat. Ce champ est optionnel. Si aucune valeur de délai n’est fournie, le SDK utilise le default_timeout spécifié dans votre configuration. |
Valeur de retour
| Type | Description |
|---|
?Customdata | Instance de CustomData confirmant que la donnée a été ajoutée au visiteur. Si la valeur est null, la requête a échoué et CustomData n’a pas été ajouté au visiteur. |
Exceptions levées
| Type | Description |
|---|
VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide (vide ou 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 ses 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 pouvez trouver plus d’informations sur les données personnelles dans la politique de gestion du consentement.
$visitorCode = $kameleoonClient->getVisitorCode();
$kameleoonClient->setLegalConsent($visitorCode, true);
Arguments
| Nom | Type | Description |
|---|
| visitorCode | string | L’identifiant unique de l’utilisateur. Ce champ est obligatoire. |
| legalConsent | bool | 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. |
Exceptions levées
| Type | Description |
|---|
| VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide (vide ou plus long que 255 caractères). |
Comportement de révocation du consentement
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 d’un opt-out, vous devez le supprimer manuellement à l’aide des méthodes natives de gestion des cookies de votre framework. Le SDK ne supprimera pas le fichier automatiquement.
Objectifs et analytics tiers
getEngineTrackingCode()
Kameleoon s’intègre à plusieurs solutions d’analyse, notamment Mixpanel, Google Analytics 4 et Segment. Pour suivre correctement les expériences côté serveur, appelez la méthode getEngineTrackingCode() après que le visiteur a déclenché une expérience. Le SDK renvoie des commandes de queue JavaScript pour les expériences que le visiteur a déclenchées au cours des cinq dernières secondes. Lorsque vous insérez ce code dans la page, Engine.js traite les commandes et envoie les événements d’exposition via l’intégration d’analyse active.
Consultez hybrid experimentation pour plus d’informations sur la mise en œuvre de cette méthode.
$engineTrackingCode = $kameleoonClient->getEngineTrackingCode($visitorCode);
- Pour utiliser cette fonctionnalité, mettez en œuvre à la fois le SDK PHP et Kameleoon Engine.js. Comme Engine.js n’est utilisé que pour le tracking dans ce flux, vous pouvez installer la balise asynchrone avant la balise fermante
</body>.
- Si vous souhaitez uniquement suivre les expériences dans Kameleoon et n’avez pas besoin d’envoyer d’événements d’exposition à des outils d’analyse tiers, utilisez le SDK JavaScript / TypeScript. Cette option fonctionne bien pour les plateformes serverless edge compute. Le SDK JavaScript / TypeScript suit automatiquement les variations lorsque vous appelez
getVisitorCode, tant que vous ajoutez les attributions d’expérience correspondantes à window.kameleoonQueue..
- Vous pouvez insérer le code de tracking retourné 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 retourné.
Arguments
| Nom | Type | Description |
|---|
| visitorCode (obligatoire) | string | Identifiant unique du visiteur. |
Valeur de retour
| Type | Description |
|---|
string | Code JavaScript à insérer dans la page. |
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 qui a été 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 paramètre isUniqueIdentifier peut également être utile dans d’autres scénarios particuliers, par exemple lorsque vous ne pouvez pas accéder au visitorCode anonyme initialement attribué au visiteur, mais que vous avez accès à un ID interne connecté au visiteur anonyme à l’aide des fonctionnalités de fusion de sessions.
require "vendor/autoload.php";
$kameleoonClient = Kameleoon\KameleoonClientFactory::create("a8st4f59bj", "/tmp/kameleoon/client-php.json");
$visitorCode = $kameleoonClient->getVisitorCode();
$goalID = 83023;
$kameleoonClient->trackConversion($visitorCode, $goalID);
// if you operate with unique ID
$kameleoonClient->addData($visitorCode, new Kameleoon\Data\UniqueIdentifier(true));
$kameleoonClient->trackConversion($visitorCode, $goalID, 0.0);
// Add metadata
$cd = new Kameleoon\Data\CustomData(1, "metadata");
$kameleoonClient->trackConversion($visitorCode, $goalID, 0.0, null, null, false, [$cd]);
Arguments
| Nom | Type | Description | Par 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) | bool | Définit si le revenu est positif ou négatif. | false |
| metadata (optionnel) | ?array<CustomData> | Vous permet de définir des valeurs spécifiques pour les custom data qui ont été définies comme métadonnées de 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 »). | null |
| isUniqueIdentifier (obsolète) | bool | Paramètre optionnel pour spécifier si le visitorCode est un identifiant unique. | false |
Les valeurs de metadata sont accessibles via les exports de données brutes et la page de résultats.Si le paramètre metadata est fourni, Kameleoon utilisera ces valeurs spécifiées pour la conversion actuelle au lieu de ce qui a été précédemment collecté à l’aide de la méthode addData(). Si le paramètre est omis, Kameleoon utilisera les dernières valeurs suivies pour ces CustomData avant la conversion et au cours de la même visite.Kameleoon ne prendra en compte que les valeurs de metadata 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, 10, 0.0, null, null, false, [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. |
Types de données
Vous pouvez utiliser les types de données prédéfinis suivants de Kameleoon\Data.
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 |
|---|
| browserType (obligatoire) | int | Liste des navigateurs : CHROME, INTERNET_EXPLORER, FIREFOX, SAFARI, OPERA, OTHER. |
| version (optionnel) | float | Version du navigateur, le nombre à virgule flottante représente les versions majeure et mineure du navigateur. |
$kameleoonClient->addData($visitorCode, new Kameleoon\Data\Browser(Kameleoon\Data\Browser::CHROME));
$kameleoonClient->addData($visitorCode, new Kameleoon\Data\Browser(Kameleoon\Data\Browser::CHROME, 10.0));
PageView
| Nom | Type | Description | Par défaut |
|---|
| url (obligatoire) | string | URL de la page consultée. Ce champ est obligatoire. | |
| title (obligatoire) | ?string | Titre de la page consultée. Ce champ est obligatoire. | null |
| referrers (optionnel) | ?array<int> | Référents des pages consultées. Ce champ est optionnel. | null |
L’index (ID) du référent est disponible dans notre Back-Office sur la page de configuration des canaux d’acquisition. Attention : cet index commence à 0, donc le premier canal d’acquisition que vous créez pour un site donné aurait l’ID 0, et non 1.
$kameleoonClient->addData(
$visitorCode,
new Kameleoon\Data\PageView("https://url.com", "title", [3])
);
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 | Par défaut |
|---|
| goalId (obligatoire) | int | ID de l’objectif. | |
| revenue (optionnel) | float | Revenu de la conversion | 0 |
| negative (optionnel) | bool | Définit si le revenu est positif ou négatif. | false |
| metadata (optionnel) | ?array<CustomData> | Métadonnées de la conversion. | null |
$kameleoonClient->addData($visitorCode, new Kameleoon\Data\Conversion(32, 10, false));
$cd = new Kameleoon\Data\CustomData(1, "metadata");
$kameleoonClient->addData($visitorCode, new Kameleoon\Data\Conversion(32, 0.0, false, [$cd]));
CustomData
CustomData permet d’associer facilement n’importe quel type de données à chaque visiteur. Elle peut ensuite être utilisée comme condition de ciblage dans les segments ou comme filtre/segmentation dans les rapports d’expérience.
Pour en savoir plus sur les custom data, veuillez consulter cet article.
| Nom | Type | Description | Par défaut |
|---|
| indexOrName (obligatoire) | int/string | Index ou Nom de la custom data. L’index ou le name doit être fourni pour identifier la donnée. | |
| values (obligatoire) | string... | Valeur(s) de la custom data à stocker. | |
| overwrite (optionnel) | bool | Indicateur pour contrôler explicitement la façon dont les valeurs sont stockées et la façon dont elles apparaissent dans les rapports. Voir plus | true |
-
Chaque visiteur ne peut avoir qu’une seule
CustomData pour chaque index unique. Ajouter une autre CustomData avec le même index remplacera l’existante.
-
L’« index » de la custom data se trouve 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 de
CustomData créée avec un nom alors que la configuration de l’instance du SDK n’est pas à jour ou que le nom n’est pas enregistré, entraînera l’ignorance de la donnée.
$kameleoonClient->addData($visitorCode, new Kameleoon\Data\CustomData(1, "value"));
// With several values
$kameleoonClient->addData($visitorCode, new Kameleoon\Data\CustomData(1, "value1", "value2"));
// To set the 'overwrite' flag to false
$kameleoonClient->addData($visitorCode, Kameleoon\Data\CustomData::newWithOverwrite(1, false, "value"));
// To use a name instead of the index
$kameleoonClient->addData($visitorCode, new Kameleoon\Data\CustomData("my-custom-data", "value"));
// To use a name instead of the index
// and set the 'overwrite' flag to false
$kameleoonClient->addData($visitorCode, Kameleoon\Data\CustomData::newWithOverwrite("my-custom-data", false, "value"));
Device
| Nom | Type | Description |
|---|
| type | int | Liste des appareils : PHONE, TABLET, DESKTOP. Ce champ est obligatoire. |
$kameleoonClient->addData($visitorCode, new Kameleoon\Data\Device(Kameleoon\Data\Device::PHONE));
UserAgent
Conservez la trace des informations de user-agent des visiteurs. Les expériences côté serveur sont plus susceptibles d’être affectées par le trafic des bots que les expériences côté client. Kameleoon utilise la 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 nos analyses.
| 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 Kameleoon\Data\UserAgent("TestUserAgent"));
UniqueIdentifier
Si vous n’ajoutez pas d’UniqueIdentifier pour un visiteur, le visitorCode est utilisé comme identifiant unique du visiteur, ce qui est utile pour l’expérimentation cross-device. Lorsque vous ajoutez un UniqueIdentifier pour un visiteur, le SDK lie les données envoyées au visiteur associé à l’identifiant spécifié.
Le paramètre isUniqueIdentifier peut être utile dans des situations uniques ; 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 | bool | Paramètre pour spécifier si le visitorCode est un identifiant unique. Ce champ est obligatoire. |
$kameleoonClient->addData($visitorCode, new Kameleoon\Data\UniqueIdentifier(true));
OperatingSystem
OperatingSystem contient des informations sur le système d’exploitation de l’appareil du visiteur.
| Nom | Type | Description |
|---|
| type | int | Liste des systèmes d’exploitation : WINDOWS, MAC, IOS, LINUX, ANDROID et WINDOWS_PHONE. Ce champ est obligatoire. |
Chaque visiteur ne peut avoir qu’un seul OperatingSystem. Ajouter un second OperatingSystem remplace le premier.
$kameleoonClient->addData($visitorCode, new Kameleoon\Data\OperatingSystem(Kameleoon\Data\OperatingSystem::WINDOWS));
Cookie
Cookie contient des informations sur le cookie stocké sur l’appareil du visiteur.
| Nom | Type | Description |
|---|
| cookies | array | Une map d’objets string composée de clés et de valeurs de cookie. Ce champ est obligatoire. |
Chaque visiteur ne peut avoir qu’un seul Cookie. Ajouter un second Cookie remplace le premier.
$cookie = new Kameleoon\Data\Cookie([
"k1" => "v1",
"k2" => "v2",
]);
$kameleoonClient->addData($visitorCode, $cookie);
Geolocation
Geolocation contient les détails de la 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 coordonné représente des degrés décimaux. |
| longitude (optionnel) | float | La coordonnée de longitude représentant l’emplacement du visiteur. Le nombre coordonné représente des degrés décimaux. |
- Chaque visiteur ne peut avoir qu’une seule
Geolocation. Ajouter une seconde Geolocation remplace la première.
$kameleoonClient->addData($visitorCode, new Kameleoon\Data\Geolocation("France", "Île-de-France", "Paris"));
ApplicationVersion
ApplicationVersion représente le numéro de version sémantique de votre application.
Un visiteur ne peut avoir qu’une seule ApplicationVersion. Ajouter une seconde instance remplacera la première.
| Nom | Type | Description |
|---|
| version (optionnel) | string | La version de l’application mobile. Ce champ doit suivre le versionnement sémantique. Les formats acceptés sont major, major.minor ou major.minor.patch. |
$kameleoonClient->addData($visitorCode, new Kameleoon\Data\ApplicationVersion("10")); // major
$kameleoonClient->addData($visitorCode, new Kameleoon\Data\ApplicationVersion("10.20")); // major.minor
$kameleoonClient->addData($visitorCode, new Kameleoon\Data\ApplicationVersion("10.20.30")); // major.minor.patch
Types retournés
DataFile
Le DataFile contient les détails de configuration du SDK.
Il peut être étendu avec des informations supplémentaires si nécessaire pour les clients. Si vous avez besoin de plus de détails, veuillez contacter votre Customer Success Manager.
| Nom | Type | Description |
|---|
| featureFlags | array<string, FeatureFlag> | Une map d’objets FeatureFlag, indexée par les feature flag keys. |
| dateModified | int | L’horodatage (en millisecondes) indiquant la dernière modification du DataFile. |
// Retrieves the array of feature flags from the DataFile.
// The array is keyed by feature flag identifiers, with each value being a FeatureFlag object.
$featureFlags = $dataFile->featureFlags;
// Retrieves the last modification timestamp of the DataFile.
// The value is an int representing milliseconds since the Unix epoch.
$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, statut d’environnement et autres détails associés.
Il peut être étendu avec des informations supplémentaires si nécessaire pour les clients. Si vous avez besoin de plus de détails, veuillez contacter votre Customer Success Manager.
| Nom | Type | Description |
|---|
| isEnvironmentEnabled | bool | Indiquant 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 | array<string, Variation> | Une map d’objets Variation, indexée par les clés de variation. |
| rules | array<Rule> | Une liste d’objets Rule |
// Check whether the feature flag is enabled in the current environment
$isEnvironmentEnabled = $featureFlag->isEnvironmentEnabled;
// Retrieve the key of the default variation
$defaultVariationKey = $featureFlag->defaultVariationKey;
// Retrieve the default variation object
$defaultVariation = $featureFlag->getDefaultVariation();
// Retrieve all variations of the feature flag as a map (key = variation key, value = Variation object)
$variations = $featureFlag->variations;
// Retrieve all targeting rules associated with the feature flag
$rules = $featureFlag->rules;
Rule
La Rule représente un ensemble de propriétés qui définissent une règle elle-même — par exemple, ses Variations.
Elle peut être étendue avec des informations supplémentaires si nécessaire pour les clients. Si vous avez besoin de plus de détails, veuillez contacter votre Customer Success Manager.
| Nom | Type | Description |
|---|
| variations | array<string, Variation> | Une map d’objets Variation, indexée par les clés de variation. |
// Retrieve all variations of the rule as a map (key = variation key, value = Variation object)
$variations = $rule->variations;
Variation
Variation contient des informations sur la variation attribuée au visiteur (ou la variation par défaut s’il n’existe pas d’attribution spécifique).
| Nom | Type | Description |
|---|
| name | string | Le nom de la variation. |
| key | string | La clé unique identifiant la variation. |
| id | ?int | L’ID de la variation attribuée (ou null s’il s’agit de la variation par défaut). |
| experimentId | ?int | L’ID de l’expérience associée à la variation (ou null si par défaut). |
| variables | array<string, Variable> | Un tableau contenant les variables de la variation attribuée, indexé par les noms de variables. Cette collection peut être vide si aucune variable n’est associée. |
- L’objet
Variation fournit des détails sur la variation attribuée et son expérience associée, tandis que l’objet Variable contient des détails spécifiques sur chaque variable au sein d’une variation.
- Assurez-vous que votre code gère le cas où
id ou experimentId peut être null, indiquant une variation par défaut.
- Le tableau
variables peut être vide si aucune variable n’est associée à la variation.
// Retrieving the variation name
$variationName = $variation->name;
// Retrieving the variation key
$variationKey = $variation->key;
// Retrieving the variation id
$variationId = $variation->id;
// Retrieving the experiment id
$experimentId = $variation->experimentId;
// Retrieving the variables map
$variables = $variation->variables;
Variable
Variable contient des informations sur une variable associée à la variation attribuée.
| Nom | Type | Description |
|---|
| key | string | La clé unique identifiant la variable. |
| type | string | Le type de la variable. Valeurs possibles : BOOLEAN, NUMBER, STRING, JSON, JS, CSS |
| value | ?mixed | La valeur de la variable, qui peut être de l’un des types suivants : bool, int, float, string, stdClass, array, null. |
// Retrieving the variables map
$variables = $variation->variables;
// Variable type can be retrieved for further processing
$type = $variables["isDiscount"]->type;
// Retrieving the variable value by key
$isDiscount = (bool) $variables["isDiscount"]->value;
// Variable value can be of different types
$title = (string) $variables["title"]->value;
Méthodes obsolètes
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
Pour obtenir la feature variation key, appelez la méthode getFeatureVariationKey() de notre SDK.
Cette méthode prend un visitorCode et un featureKey comme arguments obligatoires pour obtenir la variation key pour un utilisateur donné.
Si un utilisateur n’a jamais été associé à ce feature flag, le SDK renvoie une variation key aléatoirement (selon les règles du feature flag). Si un utilisateur avec un visitorCode donné est déjà enregistré avec ce feature flag, il détectera la valeur précédente de la variation key. Si l’utilisateur ne correspond à aucune des règles, la valeur par défaut sera retournée, que nous pouvons définir dans le compte du client.
Vous devez vous assurer qu’une gestion appropriée des erreurs est mise en place dans votre code comme indiqué dans l’exemple à droite pour intercepter les exceptions potentielles.
Si vous spécifiez un visitorCode, la méthode getFeatureVariationKey() l’utilise comme identifiant unique de visiteur, ce qui est utile pour l’expérimentation cross-device. Lorsque vous spécifiez un visitorCode et définissez le paramètre isUniqueIdentifier à true, le SDK lie les données envoyées au visiteur associé à l’identifiant spécifié.
Le paramètre isUniqueIdentifier est obsolète. Veuillez utiliser UniqueIdentifier à la place.Le paramètre isUniqueIdentifier peut également être utile dans d’autres scénarios particuliers, par exemple lorsque vous ne pouvez pas accéder au visitorCode anonyme initialement attribué au visiteur, mais que vous avez accès à un ID interne connecté au visiteur anonyme à l’aide des fonctionnalités de fusion de sessions.
$visitorCode = $kameleoonClient->getVisitorCode();
$featureKey = "featureKey";
$variationKey = "";
try {
$variationKey = $kameleoonClient->getFeatureVariationKey($visitorCode, $featureKey);
switch ($variationKey) {
case "on":
// Main variation key is selected for visitorCode
break;
case "alternativeVariation":
// Alternative variation key
break;
default:
// Default variation key
break;
}
} catch (Kameleoon\Exception\FeatureNotFound $e) {
// Feature toggle not yet activated on Kameleoon's side - we consider the feature inactive.
} catch (Kameleoon\Exception\DataFileInvalid $e) {
// It appears that the configuration has not been loaded
// and there is no previously saved version of the configuration available.
} catch (Kameleoon\Exception\VisitorCodeInvalid $e) {
// VisitorCode, which you passed to a method, is invalid and can't be accepted.
} catch (Kameleoon\Exception\FeatureEnvironmentDisabled){
// The feature flag is disabled for the environment.
} catch (Exception $e) {
// This is a generic Exception handler which will handle all exceptions.
echo "Exception: ", $e->getMessage(), "\n";
}
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. |
| timeout | ?int | Délai d’expiration (en millisecondes). Ce paramètre spécifie la durée maximale pendant laquelle la méthode peut bloquer en attente d’un résultat. Ce champ est optionnel. Si aucune valeur de délai n’est fournie, le SDK utilise le default_timeout spécifié dans votre configuration. |
| isUniqueIdentifier (Obsolète) | ?bool | 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 null. Le champ est optionnel. |
Valeur de retour
| Type | Description |
|---|
| string | Variation key du feature flag qui est enregistrée pour un visitorCode donné. |
Exceptions levées
| Type | Description |
|---|
| FeatureNotFound | Exception indiquant que l’ID du feature demandé n’a pas été trouvé dans la configuration interne du SDK. Cela est généralement normal et signifie que le feature flag n’a pas encore été activé du côté Kameleoon (mais le code mettant en œuvre le feature est déjà déployé du côté de l’application web). |
| FeatureEnvironmentDisabled | Exception indiquant que le feature flag est désactivé pour l’environnement actuel du visiteur (par exemple, production, staging ou development). |
| VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide (vide ou plus long que 255 caractères). |
| DataFileInvalid | Exception indiquant que la configuration n’a pas été chargée et qu’aucune version précédemment sauvegardée de la configuration n’est disponible. |
getActiveFeatureListForVisitor()
Cette méthode ne prend qu’un paramètre d’entrée : visitorCode. Le résultat ne contient que les feature flags actifs pour un visiteur donné.
$visitorCode = "visitor";
$arrayFeatureFlagKeys = $kameleoonClient->getActiveFeatureListForVisitor($visitorCode);
Arguments
| Nom | Type | Description |
|---|
| visitorCode | string | Identifiant unique de l’utilisateur. Ce champ est obligatoire. |
| timeout | ?int | Délai d’expiration (en millisecondes). Ce paramètre spécifie la durée maximale pendant laquelle la méthode peut bloquer en attente d’un résultat. Ce champ est optionnel. Si aucune valeur de délai n’est fournie, le SDK utilise le default_timeout spécifié dans votre configuration. |
Valeur de retour
| Type | Description |
|---|
| any | Liste des feature flag keys actives pour un visitorCode donné |
Exceptions levées
| Type | Description |
|---|
| VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide (vide ou plus long que 255 caractères). |
| DataFileInvalid | Exception indiquant que la configuration n’a pas été chargée et qu’aucune version précédemment sauvegardée de la configuration n’est disponible. |
getActiveFeatures()
La méthode getActiveFeatures récupère des informations sur les feature flags actifs disponibles pour le visitor code spécifié.
$visitorCode = "visitor";
$arrayActiveFeatures = $kameleoonClient->getActiveFeatures($visitorCode);
Arguments
| Nom | Type | Description |
|---|
| visitorCode | string | Identifiant unique de l’utilisateur. Ce champ est obligatoire. |
| timeout | ?int | Délai d’expiration (en millisecondes). Ce paramètre spécifie la durée maximale pendant laquelle la méthode peut bloquer en attente d’un résultat. Ce champ est optionnel. Si aucune valeur de délai n’est fournie, le SDK utilise le default_timeout spécifié dans votre configuration. |
Valeur de retour
| Type | Description |
|---|
| array | Un tableau qui contient les variations attribuées des features actifs en utilisant les IDs des features actifs comme clés. |
Exceptions levées
| Type | Description |
|---|
| VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide (vide ou plus long que 255 caractères). |
| DataFileInvalid | Exception indiquant que la configuration n’a pas été chargée et qu’aucune version précédemment sauvegardée de la configuration n’est disponible. |
getFeatureVariable()
- 📨 Envoie des données de tracking à Kameleoon
- Utilisez
getVariation() à la place.
- Cette méthode s’appelait précédemment
obtainFeatureVariable, qui est obsolète depuis la version 3.0.0 du SDK et sera supprimée dans une future version.
Pour obtenir la variable d’une variation key associée à un utilisateur, appelez la méthode getFeatureVariable().
Cette méthode prend un visitorCode, un featureKey et un variableName comme arguments obligatoires pour obtenir une variable de la variation key pour un utilisateur donné.
Si l’utilisateur n’a jamais été associé à ce feature flag, le SDK renvoie une valeur de variable de la variation key aléatoirement (selon les règles du feature flag). Si un utilisateur avec un visitorCode donné est déjà enregistré avec ce feature flag, la méthode détectera la valeur de la variable pour la variation associée. Si l’utilisateur ne correspond à aucune des règles, la variable par défaut sera retournée.
Assurez-vous qu’une gestion appropriée des erreurs est mise en place dans votre code comme indiqué dans l’exemple à droite pour intercepter les exceptions potentielles.
Si vous spécifiez un visitorCode, la méthode getFeatureVariable() l’utilise comme identifiant unique de visiteur, ce qui est utile pour l’expérimentation cross-device. Lorsque vous spécifiez un visitorCode et définissez le paramètre isUniqueIdentifier à true, le SDK lie les données envoyées au visiteur associé à l’identifiant spécifié.
Le paramètre isUniqueIdentifier est obsolète. Veuillez utiliser UniqueIdentifier à la place.Le paramètre isUniqueIdentifier est utile dans d’autres scénarios particuliers, par exemple lorsque vous ne pouvez pas accéder au visitorCode anonyme initialement attribué au visiteur, mais que vous avez accès à un ID interne connecté au visiteur anonyme à l’aide des fonctionnalités de fusion de sessions.
$visitorCode = $kameleoonClient->getVisitorCode();
$featureKey = "featureKey";
$variableName = "variableName";
try {
$variationValue = $kameleoonClient->getFeatureVariable($visitorCode, $featureKey, $variableName);
// Your custom code depending of variableValue
} catch (Kameleoon\Exception\FeatureNotFound $e) {
// Feature toggle not yet activated on Kameleoon's side - we consider the feature inactive.
} catch (Kameleoon\Exception\FeatureEnvironmentDisabled){
// The feature flag is disabled for the environment.
} catch (Kameleoon\Exception\VisitorCodeInvalid $e) {
// VisitorCode, which you passed to a method, is invalid and can't be accepted.
} catch (Kameleoon\Exception\FeatureVariableNotFound $e) {
// Requested variable not defined on Kameleoon's side.
} catch (Kameleoon\Exception\DataFileInvalid $e) {
// It appears that the configuration has not been loaded
// and there is no previously saved version of the configuration available.
} catch (Exception $e) {
// This is a generic Exception handler which will handle all exceptions.
echo "Exception: " . $e->getMessage() . "\n";
}
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. |
| variableName | string | Nom de la variable dont vous souhaitez obtenir une valeur. Ce champ est obligatoire. |
| timeout | ?int | Délai d’expiration (en millisecondes). Ce paramètre spécifie la durée maximale pendant laquelle la méthode peut bloquer en attente d’un résultat. Ce champ est optionnel. Si aucune valeur de délai n’est fournie, le SDK utilise le default_timeout spécifié dans votre configuration. |
| isUniqueIdentifier (Obsolète) | ?bool | 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 null. Le champ est optionnel. |
Valeur de retour
| Type | Description |
|---|
| Any | Valeur de la variable de variation qui est enregistrée pour un visitorCode donné pour ce feature flag. Types possibles : bool, int, float, string, object, array |
Exceptions levées
| Type | Description |
|---|
| FeatureNotFound | Exception indiquant que l’ID du feature demandé n’a pas été trouvé dans la configuration interne du SDK. Cela est généralement normal et signifie que le feature flag n’a pas encore été activé du côté Kameleoon (mais le code mettant en œuvre le feature est déjà déployé du côté de l’application web). |
| FeatureEnvironmentDisabled | Exception indiquant que le feature flag est désactivé pour l’environnement actuel du visiteur (par exemple, production, staging ou development). |
| VisitorCodeInvalid | Exception indiquant que le visitor code fourni n’est pas valide (vide ou plus long que 255 caractères). |
| FeatureVariableNotFound | Exception indiquant que la variable demandée n’a pas été trouvée. Vérifiez que l’ID (ou la clé) de la variable correspond à votre code. |
| DataFileInvalid | Exception indiquant que la configuration n’a pas été chargée et qu’aucune version précédemment sauvegardée de la configuration n’est disponible. |
getFeatureVariationVariables()
- Utilisez
getVariation() à la place.
- Cette méthode s’appelait précédemment
getFeatureAllVariables, qui a été supprimée dans la version 4.0.0 du SDK.
Pour récupérer toutes les variables d’un feature, appelez la méthode getFeatureVariationVariables(). Une variable de feature peut être modifiée facilement via notre application web.
Cette méthode prend featureKey et variationKey comme arguments obligatoires. Elle renverra les données avec le type d’objet, tel que défini sur l’interface web. La méthode lève une erreur (FeatureNotFound) si le feature flag demandé n’a pas été trouvé dans la configuration client du SDK. Si la variation key n’est pas trouvée, la méthode lève l’erreur FeatureVariationNotFound.
$featureKey = "test_feature_variables";
$variationKey = "on";
try {
$variables = $kameleoonClient->getFeatureVariationVariables($featureKey, $variationKey);
$firstName = $variables["firstName"];
} catch (Kameleoon\Exception\FeatureNotFound $e) {
// The feature is not yet activated on Kameleoon's side.
} catch (Kameleoon\Exception\FeatureEnvironmentDisabled){
// The feature flag is disabled for the environment.
} catch (Kameleoon\Exception\FeatureVariationNotFound $e) {
// The variation is not yet activated on Kameleoon's side, i.e., the associated experiment is not online.
} catch (Kameleoon\Exception\DataFileInvalid $e) {
// It appears that the configuration has not been loaded
// and there is no previously saved version of the configuration available.
} catch (Exception $e) {
// This is a generic Exception handler which will handle all exceptions.
echo "Exception: " . $e->getMessage() . "\n";
}
Arguments
| Nom | Type | Description |
|---|
| featureKey | string | Clé du feature flag que vous souhaitez obtenir. Ce champ est obligatoire. |
| variationKey | string | Clé de la variation que vous souhaitez obtenir. Ce champ est obligatoire. |
| timeout | ?int | Délai d’expiration (en millisecondes). Ce paramètre spécifie la durée maximale pendant laquelle la méthode peut bloquer en attente d’un résultat. Ce champ est optionnel. Si aucune valeur de délai n’est fournie, le SDK utilise le default_timeout spécifié dans votre configuration. |
Valeur de retour
| Type | Description |
|---|
| Any | Valeur de la variable de variation qui est enregistrée pour un visitorCode donné pour ce feature flag. Types possibles : bool, int, float, string, object, array |
Exceptions levées
| Type | Description |
|---|
| FeatureNotFound | Exception indiquant que l’ID du feature demandé n’a pas été trouvé dans la configuration interne du SDK. Cela est généralement normal et signifie que le feature flag n’a pas encore été activé du côté Kameleoon (mais le code mettant en œuvre le feature est déjà déployé du côté de l’application web). |
| FeatureEnvironmentDisabled | Exception indiquant que le feature flag est désactivé pour l’environnement actuel du visiteur (par exemple, production, staging ou development). |
| FeatureVariationNotFound | Exception indiquant que l’ID de variation demandé n’a pas été trouvé dans la configuration interne du SDK. Cela est généralement normal et signifie que l’expérience correspondant à la variation n’a pas encore été activée du côté Kameleoon. |
| DataFileInvalid | Exception indiquant que la configuration n’a pas été chargée et qu’aucune version précédemment sauvegardée de la configuration n’est disponible. |
getFeatureList()
Renvoie une liste des feature flag keys actuellement disponibles pour le SDK.
$arrayFeatureKeys = $kameleoonClient->getFeatureList();
Arguments
| Nom | Type | Description |
|---|
| timeout (optionnel) | ?int | Délai d’expiration (en millisecondes). Ce paramètre spécifie la durée maximale pendant laquelle la méthode peut bloquer en attente d’un résultat. Si aucune valeur de délai n’est fournie, le SDK utilise le default_timeout spécifié dans votre configuration. |
Valeur de retour
| Type | Description |
|---|
array<string> | Liste des feature flag keys |