Passer au contenu principal

​
Configuration et bucketing des feature flags​

Lorsqu’une configuration de feature flag est mise a jour ou activee/desactivee, les SDK peuvent obtenir la configuration mise a jour depuis le Content Delivery Network (CDN) Cloudflare en utilisant le polling ou le streaming. Le polling est l’option par defaut tandis que le streaming est une option premium. Les SDK Kameleoon sont concus pour se conformer a une politique zero latence. Cela signifie que le SDK ne necessite pas d’appels supplementaires a un serveur distant pour activer et affecter les utilisateurs a un feature flag. Meme l’appel a un serveur distant le plus rapide ajouterait au minimum 20 ms de latence a l’application et, selon plusieurs facteurs, ce delai peut atteindre des centaines de millisecondes, voire bloquer completement le chargement de l’application web pour l’utilisateur final. Pour eviter cette latence supplementaire, les SDK Kameleoon affectent les visiteurs aux expériences localement.
Pour les SDK cote client, qui s’executent sur l’appareil de l’utilisateur, l’application doit recuperer les configurations actives des feature flags au debut de la session. Cela necessite un appel distant avec un callback associe, ce qui signifie que le code applicatif qui utilise le SDK ne peut pas executer d’expériences ou appliquer de feature flags avant que ce callback ne termine son execution.

​
Polling (par defaut)​

Dans ce mode, le SDK envoie une requete au CDN a intervalles reguliers (par defaut, toutes les 60 minutes) pour recuperer la configuration la plus recente. L’intervalle peut etre personnalise dans la configuration du SDK en utilisant le parametre refresh_interval_minute (ou refresh_interval).
Lorsque les intervalles sont moderement espaces, la mise a jour de la configuration consomme tres peu de ressources memoire et reseau.
Pour les SDK Web cote client, la strategie 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 a jour en arriere-plan : Si le refresh_interval s’est ecoule, le SDK effectue une requete en arriere-plan pour mettre a jour la configuration et rafraichir le cache.
  3. Validite du cache : La configuration mise en cache est consideree comme valide pendant 1,5 heure apres la derniere mise a jour reussie. Si le visiteur ouvre une page dans cette fenetre de 1,5 heure, la version en cache sera utilisee. Sinon, le cache est ignore et une nouvelle requete est effectuee immediatement.
Cette strategie de mise en cache garantit des chargements de page plus rapides et une utilisation minimale du reseau, tout en conservant une configuration raisonnablement a jour.Supposons que refresh_interval soit defini sur 15 minutes et qu’un utilisateur soit expose a un feature flag. Si le feature flag est desactive 10 minutes plus tard et que le meme 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).
  • Simultanement, il effectuera une requete en arriere-plan pour recuperer la configuration mise a jour et rafraichir le cache.
  • Cette conception privilegie la performance, garantissant des chargements de page rapides tout en se synchronisant de maniere asynchrone avec la derniere configuration.
Ainsi, meme s’il existe une courte fenetre pendant laquelle un utilisateur peut voir une configuration obsolete (selon l’intervalle), le SDK la met rapidement a jour en arriere-plan. La configuration mise a jour sera appliquee la prochaine fois que le visiteur ouvrira une page.

​
Streaming (option premium)​

Le mode streaming en temps reel permet au SDK d’appliquer automatiquement la nouvelle configuration sans delai. Lorsque le streaming est active, le SDK Kameleoon est notifie de toute modification de la configuration en temps reel, grace aux server-sent events (SSE). Principaux avantages :
  • Mettre a jour la configuration immediatement (sans attendre le prochain cycle de polling).
  • Utiliser moins de trafic reseau que le polling a courts intervalles. Le streaming n’envoie pas de requetes periodiques. Il ouvre la connexion une fois et la maintient ouverte en permanence, prete a recevoir des donnees.
Disponibilite :
  • Il s’agit d’une option premium qui necessite un abonnement. Pour activer le streaming en temps reel sur un compte Kameleoon, contactez le Customer Success Manager ou envoyez un e-mail a 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 ecouter les mises a jour de configuration de maniere non bloquante car le SDK PHP ne persiste pas entre les requetes. Chaque requete cree une nouvelle instance du SDK qui se detruit des qu’elle recoit une reponse.
  • Le mode streaming en temps reel n’est actuellement pas compatible avec les plateformes serverless edge compute.
  • Pour les autres langages, consultez la matrice de compatibilite des SDK pour la version minimale prise en charge dans le langage prefere.

​
Stockage des donnees​

Les SDK de Kameleoon sont concus pour des performances et une experience utilisateur optimales. Pour y parvenir, ils gerent les donnees visiteur localement, soit sur le serveur, soit directement sur l’appareil, au lieu de les recuperer depuis une source distante. Toutes les donnees visiteur pertinentes pour les expériences et feature flags Kameleoon sont stockees localement, ce qui inclut les affectations d’expérience, les donnees de segment, et toute custom data ajoutee a l’aide de methodes comme addData() ou recuperee depuis le serveur avec getRemoteVisitorData(). La maniere dont ces donnees sont stockees et leur duree de vie differe selon que vous utilisez un SDK cote serveur ou cote client.

​
SDK cote serveur​

Pour les SDK cote serveur, les donnees visiteur sont stockees dans la memoire volatile du serveur (RAM), ce qui permet un acces rapide pour les evaluations d’expérience et de feature flag. Les donnees sont organisees sous forme de map, en utilisant des valeurs visitorCode uniques comme cles.
  • Stockage base sur la session : Les donnees ne sont conservees en memoire que pendant la duree de la session active d’un utilisateur, qui se termine, par defaut, apres 30 minutes d’inactivite (pas de vues de page, clics, etc.). Toutes les donnees collectees pendant la session expirent en meme temps.
    • Parametre session_duration : La duree de la session peut etre ajustee en utilisant le parametre session_duration dans la configuration du SDK. Ce parametre permet a la session Kameleoon de s’aligner avec la gestion cote serveur de l’application.
Augmenter session_duration necessitera que le SDK alloue plus de RAM pour stocker les donnees visiteur accrues.
  • Perte de donnees au redemarrage du serveur : Comme les donnees sont stockees en RAM, elles seront perdues si le serveur d’application redemarre. Generalement, la perte de donnees n’est pas un probleme, car les donnees visiteur importantes (comme les ID utilisateur ou les attributs) sont generalement recuperees depuis une base de donnees persistante et reaffectees au visiteur lors d’une nouvelle requete.
  • Recuperer les donnees des visites precedentes : La methode getRemoteVisitorData() vous permet de recuperer les custom data collectees lors de la visite precedente d’un visiteur. Cette methode associe automatiquement la derniere entree de donnees pour un visiteur, eliminant le besoin d’appeler addData() a nouveau.

​
SDK cote client​

Contrairement aux SDK cote serveur, les SDK cote client utilisent un stockage local persistant sur l’appareil de l’utilisateur. Ce mecanisme garantit que les donnees visiteur peuvent etre conservees entre les sessions de navigateur, les redemarrages d’application et meme les redemarrages d’appareil. Le mecanisme de stockage specifique varie selon la plateforme :
  • iOS : UserDefaults
  • Android : SharedPreferences
  • JavaScript/TypeScript : LocalStorage
    • Note pour le SDK JS : Le kameleoonVisitorCode est egalement partage via des cookies pour assurer une continuite transparente des donnees et la communication avec le fichier d’application Kameleoon (engine.js).
  • React Native : MMKV Storage
Contrairement aux SDK cote serveur qui utilisent un session_duration global, les SDK cote client n’operent pas sur une expiration basee sur la session pour toutes les donnees. A la place, ils utilisent soit targetingDataCleanupInterval soit data_expiration_interval_minute pour controler la duree de stockage des elements de donnees individuels.
  • targetingDataCleanupInterval/data_expiration_interval_minute : Ces parametres determinent la duree de vie individuelle de chaque entree de donnees specifique. Par defaut, les donnees sont stockees indefiniment (jusqu’a ce qu’elles soient explicitement effacees) pour assurer des experiences utilisateur coherentes entre les visites. Vous pouvez definir ce parametre sur un nombre specifique de minutes si vous voulez que des points de donnees individuels expirent apres un certain temps.
  • Persistance des donnees : Cette difference fondamentale signifie que les donnees persistent meme si l’utilisateur ferme l’onglet du navigateur, navigue hors du site ou ferme l’application mobile.
  • Justification de la convention de nommage : La difference de terminologie des parametres (session_duration vs data_expiration_interval_minute) reflete directement la philosophie de stockage sous-jacente. session_duration regit la duree de vie globale de toutes les donnees au sein d’une session cote serveur. data_expiration_interval_minute permet un controle granulaire sur la duree de vie de chaque element de donnees specifique stocke de maniere persistante sur le client.

​
Liste des domaines​

Les SDK Kameleoon necessitent l’acces a un ensemble d’URI qui fournissent des services specifiques au SDK. Si vous restreignez l’acces et devez explicitement mettre des domaines sur liste blanche, assurez-vous que nos SDK peuvent atteindre les domaines suivants :
URLUtilise par
https://sdk-config.kameleoon.eu/<sitecode>Fichier de configuration
https://<sitecode>.kameleoon.io/sdk-config / https://client-config.kameleoon.com/mobileFichier de configuration (deprecie)
https://events.kameleoon.com:8110/sseStreaming en temps reel
https://api.kameleoon.com/oauth/tokenAuthentification
https://eu-data.kameleoon.io/ https://na-data.kameleoon.ioSuivi
Le domaine de vos scripts Kameleoon peut varier d’un projet a l’autre. Vos projets peuvent etre hebergees soit sur kameleoon.eu, soit sur kameleoon.io selon leur date de creation. Assurez-vous d’utiliser le domaine affiche dans votre projet dans l’application Kameleoon.