Skip to main content

​
Configuration et bucketing des feature flags

Lorsqu’une configuration de feature flag est mise à jour ou activée/désactivée, les SDK peuvent obtenir la configuration mise à jour depuis le Content Delivery Network (CDN) Cloudflare en utilisant le polling ou le streaming. Le polling est l’option par défaut tandis que le streaming est une option premium. Les SDK Kameleoon sont conçus pour se conformer à une politique zéro latence. Cela signifie que le SDK ne nécessite pas d’appels supplémentaires à un serveur distant pour activer et affecter les utilisateurs à un feature flag. Même l’appel à un serveur distant le plus rapide ajouterait au minimum 20 ms de latence à l’application et, selon plusieurs facteurs, ce délai peut atteindre des centaines de millisecondes, voire bloquer complètement le chargement de l’application web pour l’utilisateur final. Pour éviter cette latence supplémentaire, les SDK Kameleoon affectent les visiteurs aux expériences localement.
Pour les SDK côté client, qui s’exécutent sur l’appareil de l’utilisateur, l’application doit récupérer les configurations actives des feature flags au début de la session. Cela nécessite un appel distant avec un callback associé, ce qui signifie que le code applicatif qui utilise le SDK ne peut pas exécuter d’expériences ou appliquer de feature flags avant que ce callback ne termine son exécution.

​
Polling (par défaut)

Dans ce mode, le SDK envoie une requête au CDN à intervalles réguliers (par défaut, toutes les 60 minutes) pour récupérer la configuration la plus récente. L’intervalle peut être personnalisé dans la configuration du SDK en utilisant le paramètre refresh_interval_minute (ou refresh_interval).
Lorsque les intervalles sont modérément espacés, la mise à jour de la configuration consomme très peu de ressources mémoire et réseau.
Pour les SDK Web côté client, la stratégie de polling inclut une logique de cache local :
  1. Chargement initial : Lorsqu’une page web est ouverte, le SDK tente d’abord de charger la configuration depuis le cache (si disponible).
  2. Mise à jour en arrière-plan : Si le refresh_interval s’est écoulé, le SDK effectue une requête en arrière-plan pour mettre à jour la configuration et rafraîchir le cache.
  3. Validité du cache : La configuration mise en cache est considérée comme valide pendant 1,5 heure après la dernière mise à jour réussie. Si le visiteur ouvre une page dans cette fenêtre de 1,5 heure, la version en cache sera utilisée. Sinon, le cache est ignoré et une nouvelle requête est effectuée immédiatement.
Cette stratégie de mise en cache garantit des chargements de page plus rapides et une utilisation minimale du réseau, tout en conservant une configuration raisonnablement à jour.Supposons que refresh_interval soit défini sur 15 minutes et qu’un utilisateur soit exposé à un feature flag. Si le feature flag est désactivé 10 minutes plus tard et que le même utilisateur revient sur le site web 20 minutes plus tard :
  • Le SDK chargera d’abord la configuration depuis le cache (montrant toujours le flag comme actif).
  • Simultanément, il effectuera une requête en arrière-plan pour récupérer la configuration mise à jour et rafraîchir le cache.
  • Cette conception privilégie la performance, garantissant des chargements de page rapides tout en se synchronisant de manière asynchrone avec la dernière configuration.
Ainsi, même s’il existe une courte fenêtre pendant laquelle un utilisateur peut voir une configuration obsolète (selon l’intervalle), le SDK la met rapidement à jour en arrière-plan. La configuration mise à jour sera appliquée la prochaine fois que le visiteur ouvrira une page.

​
Impact sur les expériences et feature flags nouvellement lancés

dataFileCacheTtl et dataFileRefreshInterval déterminent ensemble la rapidité avec laquelle les visiteurs sont évalués selon la configuration d’une expérience ou d’un feature flag nouvellement lancé. Les visiteurs dont le fichier de données en cache a déjà dépassé dataFileCacheTtl, ou qui n’en ont pas encore, reçoivent immédiatement la nouvelle configuration, car initialize() attend l’arrivée d’un fichier de données à jour. Les visiteurs dont le fichier de données en cache est encore dans la fenêtre dataFileCacheTtl continuent d’être évalués selon la configuration précédente jusqu’à ce que ce cache dépasse dataFileCacheTtl, ou jusqu’à ce qu’une actualisation en arrière-plan se termine et qu’ils chargent une autre page. Par conséquent, avec la valeur par défaut de dataFileCacheTtl de 90 minutes, le trafic entrant dans une expérience nouvellement lancée augmente progressivement au lieu d’atteindre immédiatement son volume complet. Par exemple, une expérience nouvellement lancée peut exposer environ 40% de sa population ciblée finale au cours de la première heure suivant le lancement, environ 57% à la deuxième heure, et plus de 95% à la troisième heure, une fois qu’un nombre suffisant de fichiers de données en cache des visiteurs ont dépassé cette fenêtre de 90 minutes. Aucun visiteur n’est exclu définitivement de l’expérience ; chacun la rejoint dès que son appareil récupère la configuration mise à jour.
Lorsque vous comparez les chiffres d’exposition Kameleoon à ceux d’un autre outil d’analyse juste après le lancement d’une campagne, attendez-vous à une période de montée en charge d’environ dataFileCacheTtl minutes (90 par défaut) avant que les chiffres d’exposition ne se stabilisent et ne correspondent à la population ciblée. Un nombre de visiteurs exposés plus faible pendant cette période ne signifie pas que des visiteurs sont perdus ou mal ciblés. Si votre cas d’usage nécessite un démarrage plus rapide, réduisez dataFileCacheTtl (en le gardant supérieur à dataFileRefreshInterval pour éviter d’ajouter des requêtes bloquantes inutiles au chargement de la page), ou discutez de l’option streaming avec le support Kameleoon, qui contourne entièrement ce modèle de cache pour le fichier de données du SDK.
Une configuration associant un SDK côté serveur ou edge avec getEngineTrackingCode() et le script de tracking Engine.js peut tout de même présenter une montée en charge similaire dans les résultats trackés, causée par le cache navigateur distinct d’Engine.js lui-même. Consultez le comportement de mise en cache d’Engine.js pour plus de détails.

​
Streaming (option premium)

Le mode streaming en temps réel permet au SDK d’appliquer automatiquement la nouvelle configuration sans délai. Lorsque le streaming est activé, le SDK Kameleoon est notifié de toute modification de la configuration en temps réel, grâce aux server-sent events (SSE). Principaux avantages :
  • Mettre à jour la configuration immédiatement (sans attendre le prochain cycle de polling).
  • Utiliser moins de trafic réseau que le polling à courts intervalles. Le streaming n’envoie pas de requêtes périodiques. Il ouvre la connexion une fois et la maintient ouverte en permanence, prête à recevoir des données.
Disponibilité :
  • Il s’agit d’une option premium qui nécessite un abonnement. Pour activer le streaming en temps réel sur un compte Kameleoon, contactez le Customer Success Manager ou envoyez un e-mail à support@kameleoon.com.
  • Le SDK PHP ne prend pas en charge le streaming en raison de contraintes techniques. Le SDK PHP ne peut actuellement pas écouter les mises à jour de configuration de manière non bloquante car le SDK PHP ne persiste pas entre les requêtes. Chaque requête crée une nouvelle instance du SDK qui se détruit dès qu’elle reçoit une réponse.
  • Le mode streaming en temps réel n’est actuellement pas compatible avec les plateformes serverless edge compute.
  • Pour les autres langages, consultez la matrice de compatibilité des SDK pour la version minimale prise en charge dans le langage préféré.

​
Stockage des données

Les SDK de Kameleoon sont conçus pour des performances et une expérience utilisateur optimales. Pour y parvenir, ils gèrent les données visiteur localement, soit sur le serveur, soit directement sur l’appareil, au lieu de les récupérer depuis une source distante. Toutes les données visiteur pertinentes pour les expériences et feature flags Kameleoon sont stockées localement, ce qui inclut les affectations d’expérience, les données de segment, et toute custom data ajoutée à l’aide de méthodes comme addData() ou récupérée depuis le serveur avec getRemoteVisitorData(). La manière dont ces données sont stockées et leur durée de vie diffère selon que vous utilisez un SDK côté serveur ou côté client.

​
SDK côté serveur

Pour les SDK côté serveur, les données visiteur sont stockées dans la mémoire volatile du serveur (RAM), ce qui permet un accès rapide pour les évaluations d’expérience et de feature flag. Les données sont organisées sous forme de map, en utilisant des valeurs visitorCode uniques comme clés.
  • Stockage basé sur la session : Les données ne sont conservées en mémoire que pendant la durée de la session active d’un utilisateur, qui se termine, par défaut, après 30 minutes d’inactivité (pas de vues de page, clics, etc.). Toutes les données collectées pendant la session expirent en même temps.
    • Paramètre session_duration : La durée de la session peut être ajustée en utilisant le paramètre session_duration dans la configuration du SDK. Ce paramètre permet à la session Kameleoon de s’aligner avec la gestion côté serveur de l’application.
Augmenter session_duration nécessitera que le SDK alloue plus de RAM pour stocker les données visiteur accrues.
  • Perte de données au redémarrage du serveur : Comme les données sont stockées en RAM, elles seront perdues si le serveur d’application redémarre. Généralement, la perte de données n’est pas un problème, car les données visiteur importantes (comme les ID utilisateur ou les attributs) sont généralement récupérées depuis une base de données persistante et réaffectées au visiteur lors d’une nouvelle requête.
  • Récupérer les données des visites précédentes : La méthode getRemoteVisitorData() vous permet de récupérer les custom data collectées lors de la visite précédente d’un visiteur. Cette méthode associe automatiquement la dernière entrée de données pour un visiteur, éliminant le besoin d’appeler addData() à nouveau.

​
SDK côté client

Contrairement aux SDK côté serveur, les SDK côté client utilisent un stockage local persistant sur l’appareil de l’utilisateur. Ce mécanisme garantit que les données visiteur peuvent être conservées entre les sessions de navigateur, les redémarrages d’application et même les redémarrages d’appareil. Le mécanisme de stockage spécifique varie selon la plateforme :
  • iOS : UserDefaults
  • Android : SharedPreferences
  • JavaScript/TypeScript : LocalStorage
    • Note pour le SDK JS : Le kameleoonVisitorCode est également partagé via des cookies pour assurer une continuité transparente des données et la communication avec le fichier d’application Kameleoon (engine.js).
  • React Native : MMKV Storage
Contrairement aux SDK côté serveur qui utilisent un session_duration global, les SDK côté client n’opèrent pas sur une expiration basée sur la session pour toutes les données. À la place, ils utilisent soit targetingDataCleanupInterval soit data_expiration_interval_minute pour contrôler la durée de stockage des éléments de données individuels.
  • targetingDataCleanupInterval/data_expiration_interval_minute : Ces paramètres déterminent la durée de vie individuelle de chaque entrée de données spécifique. Par défaut, les données sont stockées indéfiniment (jusqu’à ce qu’elles soient explicitement effacées) pour assurer des expériences utilisateur cohérentes entre les visites. Vous pouvez définir ce paramètre sur un nombre spécifique de minutes si vous voulez que des points de données individuels expirent après un certain temps.
  • Persistance des données : Cette différence fondamentale signifie que les données persistent même si l’utilisateur ferme l’onglet du navigateur, navigue hors du site ou ferme l’application mobile.
  • Justification de la convention de nommage : La différence de terminologie des paramètres (session_duration vs data_expiration_interval_minute) reflète directement la philosophie de stockage sous-jacente. session_duration régit la durée de vie globale de toutes les données au sein d’une session côté serveur. data_expiration_interval_minute permet un contrôle granulaire sur la durée de vie de chaque élément de données spécifique stocké de manière persistante sur le client.

​
SDK en edge

Les SDK en edge, déployés via les starter kits pour serverless edge compute, ne conservent pas les données visiteur entre les requêtes de la même manière que les SDK côté serveur ou côté client. Une plateforme edge peut détruire et recréer une instance de worker à tout moment, donc un paramètre session_duration n’a aucune mémoire durable à laquelle s’appliquer, et un edge worker n’a aucune garantie de voir une requête ultérieure du même visiteur. Pour cette raison, votre intégration est responsable de rendre les données visiteur disponibles pour l’edge worker à chaque requête, généralement en les transmettant sous forme de cookie et en appelant addData() avant d’évaluer un feature flag ou une expérience. Consultez Contraintes de ciblage en edge pour l’explication complète et un exemple de code.

​
Liste des domaines

Les SDK Kameleoon nécessitent l’accès à un ensemble d’URI qui fournissent des services spécifiques au SDK. Si vous restreignez l’accès et devez explicitement mettre des domaines sur liste blanche, assurez-vous que nos SDK peuvent atteindre les domaines suivants : Pour autoriser ces domaines dans un en-tête Content-Security-Policy, consultez domaines Kameleoon à autoriser, qui répertorie tous les domaines utilisés par les produits Kameleoon.
Le domaine de vos scripts Kameleoon peut varier d’un projet à l’autre. Vos projets peuvent être hébergées soit sur kameleoon.eu, soit sur kameleoon.io selon leur date de création. Assurez-vous d’utiliser le domaine affiché dans votre projet dans l’application Kameleoon.

​
FAQ

Kameleoon utilise des serveurs CDN lors de l’initialisation. Une fois que le SDK a reçu et mis en cache la configuration, la récupération et les mises à jour sont rapides, généralement de 50 à 70 ms selon la latence du serveur par rapport au CDN le plus proche.
Il existe deux méthodes pour obtenir la configuration : le Polling et le Streaming.
Le Streaming utilise le protocole server-sent events (SSE ou EventSource).
Kameleoon purge le CDN à chaque fois que vous mettez à jour la configuration d’un feature flag (par exemple, les variations, les expositions du trafic et le ciblage), ou toutes les 24 heures.
Chaque instance de serveur stocke les données visiteur qu’elle collecte dans sa propre mémoire. Acheminez les requêtes d’un même visiteur vers la même instance de serveur. Sinon, ajoutez l’ensemble des données visiteur avec addData() avant chaque requête de suivi, ou chargez-les avec la méthode getRemoteVisitorData.Si des instances de serveur appliquent des configurations SDK différentes en même temps, utilisez l’option Streaming pour que chaque instance reçoive les modifications de configuration en temps réel.
Toutes les évaluations se font en local pour éliminer la latence. Les requêtes de suivi sont ensuite envoyées de manière asynchrone aux serveurs Data API de Kameleoon.
Pour affecter un visiteur à une variation d’expérience, Kameleoon construit d’abord un identifiant à partir du visitor code, de l’ID de l’expérience et, le cas échéant, d’un élément supplémentaire en cas de respooling. Ensuite, une implémentation synchrone de la fonction de hachage SHA-256 calcule un hash de cet identifiant. L’entier obtenu par le hachage est ensuite converti en un nombre à virgule flottante compris entre zéro et un, afin de l’affecter à une variation d’expérience. La fonction SHA-256 est déterministe : le même utilisateur (avec le même visitor code) reçoit donc toujours la même variation pour une expérience, sauf si vous demandez explicitement un recalcul de l’attribution.
L’article Ajouter une nouvelle règle de rollout explique tous les cas possibles.
Les SDK côté serveur conservent les données visiteur en mémoire pendant toute la durée de la session du visiteur, qui est de 30 minutes par défaut. Les SDK côté client les conservent dans le stockage local de l’appareil, où elles persistent jusqu’à ce que vous les supprimiez ou jusqu’à l’expiration d’un intervalle configuré. Consultez Stockage des données pour plus de détails.