Passer au contenu principal
Utilisez le script d’application Kameleoon pour les expériences web creees avec l’editeur graphique ou de code. Utilisez le SDK web pour les feature flags et les expériences de feature.Notez que Kameleoon peut s’executer en mode hybride. Le mode hybride utilise a la fois les SDK Web et le fichier d’application JavaScript Kameleoon. Le mode hybride vous permet d’utiliser l’approche optimale pour des taches individuelles. Par exemple, vous pouvez implementer et deployer plus facilement des variations cote serveur, tandis que le suivi peut etre effectue plus efficacement avec le fichier JavaScript.
Kameleoon utilise des serveurs CDN lors de l’initialisation. Une fois la configuration recue et mise en cache, la recuperation et la mise a jour se produisent rapidement (50-70 ms selon la latence du serveur par rapport au CDN le plus proche).
Il existe deux methodes pour obtenir la configuration : le Polling et le Streaming.
Le protocole Server Side Events (SSE ou EventSource) est utilise.
Le CDN est purge a chaque fois que vous mettez a jour une configuration de feature flag (par exemple, variations, expositions de trafic et ciblage), ou toutes les 24 heures.
Si vous utilisez un SDK cote client et que le site web restreint le chargement de ressources (scripts, images, medias, CSS) via l’en-tete HTTP standard Content-Security-Policy (CSP), mettez a jour la CSP du site pour permettre le chargement des ressources Kameleoon :
script-src https://[your-site-code].kameleoon.io https://[your-site-code].kameleoon.eu https://client-config.kameleoon.com https://sdk-config.kameleoon.eu https://*.experimentation.dev 'unsafe-eval';
connect-src https://[your-site-code].kameleoon.io https://[your-site-code].kameleoon.eu https://eu-data.kameleoon.eu https://eu-data.kameleoon.io https://na-data.kameleoon.eu https://na-data.kameleoon.io https://editor.kameleoon.com https://api.kameleoon.com https://customers.kameleoon.com https://logger.kameleoon.io https://client-config.kameleoon.com https://sdk-config.kameleoon.eu https://*.experimentation.dev;
Si vous utilisez Kameleoon en mode hybride, le domaine de vos scripts Kameleoon https://[your-site-code].kameleoon.xx 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. Remplacez [your-site-code] par votre site code Kameleoon dans chaque ligne ou il apparait et ajoutez ceci a votre configuration.
Comme chaque instance de serveur dispose de sa propre memoire, toutes les donnees visiteur collectees seront stockees sur une instance donnee. Vous devez utiliser un framework dans lequel les requetes d’un meme visiteur sont traitees par la meme instance de serveur. Sinon, les donnees visiteur doivent etre ajoutees completement avant chaque requete de suivi, ou chargees a l’aide de la methode getRemoteVisitorData.Si le probleme reside dans la difference de configuration du SDK, utilisez l’option Streaming.
Toutes les evaluations se produisent localement pour eliminer la latence. Les requetes de suivi sont ensuite envoyees de maniere asynchrone aux serveurs Data API de Kameleoon.
Pour affecter un visiteur a une variation d’expérience, Kameleoon construit d’abord un identifiant en utilisant le visitor code, l’ID d’expérience et un element supplementaire potentiel en cas de respooling. Ensuite, une implementation synchrone de la fonction de hachage SHA-256 calcule un hash de cet identifiant. L’entier obtenu par hashing est ensuite mappe a un nombre flottant entre zero et un pour l’affecter a une variation d’expérience. La fonction SHA-256 est deterministe, donc le meme utilisateur (avec le meme visitor code) sera toujours affecte a la meme variation pour une expérience, sauf si un recalcul de l’attribution est explicitement demande.
Suivez la methodologie detaillee ici.
Tous les cas possibles sont expliques dans cet article.
Plusieurs raisons peuvent expliquer l’absence d’affichage de donnees sur la page de resultats :
  • Attendez 30-60 minutes que le serveur Kameleoon confirme une visite. Chaque fois que le meme visiteur arrive sur le site web, Kameleoon cree une nouvelle visite. La visite se termine des que Kameleoon ne recoit plus de nouveaux evenements d’activite (par exemple, exposition a une campagne, vue de page, scroll, clics) dans les 30 dernieres minutes. Kameleoon cree une nouvelle visite apres 30 minutes d’inactivite.
  • Si vous avez active le filtrage des bots dans les parametres du projet, il peut y avoir une erreur dans la valeur user-agent definie sur le SDK. Reportez-vous a cet article pour plus de details.
  • Le consentement legal est defini sur Required dans les parametres du projet, mais la methode SDK setLegalConsent n’a pas ete appelee. Reportez-vous a cette documentation pour plus de details.
  • Aucune des methodes SDK qui envoient une requete de suivi aux serveurs Kameleoon n’a ete utilisee.
L’article suivant fournit une aide supplementaire pour deboguer le probleme.
Si vous voyez un grand nombre de visites provenant de visiteurs, il peut s’agir de bots. Pour empecher les bots d’affecter votre expérience, activez l’option Bot filtering dans les parametres de votre projet. Pour indiquer qu’un visiteur n’est pas un bot, vous devez passer les donnees UserAgent Kameleoon a l’aide de la methode SDK. Appeler la methode empechera Kameleoon de filtrer l’utilisateur.
Si vos rapports montrent une allocation inattendue (par exemple, 10/90 au lieu de 50/50) ou si des visiteurs manquent, cela peut etre du a l’une des raisons suivantes :
  • Restreindre le pool de visiteurs pour des variations specifiques : Si vous appelez d’abord getVariations(onlyActive: true, track: false), le SDK ne renvoie que les visiteurs affectes a des variations actives (ON). Si vous n’affichez ensuite que les pages d’expérience et appelez getVariation(track: true) pour ces visiteurs specifiques, Kameleoon ne suit que la variation ON, ce qui donne un rapport qui ne montre qu’une seule variation.
  • Temps insuffisant pour les requetes de suivi : Kameleoon envoie des donnees a un intervalle specifique. Si un visiteur reste sur une page avec un client Kameleoon integre pour la variation ON, mais passe a une page sans client pour la variation OFF, le client peut ne pas avoir suffisamment de temps pour envoyer la requete de suivi pour la variation OFF.
  • Configuration manquante pour des variations specifiques : Vous avez peut-etre omis le UserAgent ou setLegalConsent pour certaines variations. Par exemple, si vous ne fournissez le consentement que sur la page pour la variation ON, Kameleoon ne peut pas suivre les visiteurs de la variation OFF.
  • Donnees visiteur manquantes : Le SDK ne collecte pas automatiquement les donnees visiteur ; vous devez les ajouter explicitement pour que le ciblage et le suivi fonctionnent correctement.

​
Verifiez votre configuration de ciblage

Si vous suspectez des problemes de ciblage, suivez ces etapes :
  1. Creez une regle sans ciblage avec 100 % d’exposition et attribuez votre variation souhaitee.
  2. Ajoutez le ciblage et assurez-vous que l’utilisateur cesse de recevoir la variation.
  3. Ajoutez les donnees Kameleoon requises.
L’utilisateur devrait recevoir la variation a nouveau. Si cela echoue, essayez d’utiliser des conditions de ciblage plus simples pour isoler le probleme.
Oui, les donnees sont immediatement disponibles pour le ciblage. Les donnees seront disponibles pendant la session du visiteur pour les SDK bases sur le serveur et pendant la duree de vie definie pour les SDK bases sur le client (mobile et web).
Cela depend du type de SDK.Dans les SDK serveur, les donnees du visiteur sont stockees en memoire operationnelle pendant la session du visiteur. La duree de la session peut etre definie, bien que la valeur par defaut soit de 30 minutes.
Plus la duree de la session est longue avec le parametre sessionDuration, plus le SDK conserve de donnees en memoire. Plus de donnees signifie une consommation accrue. La session est prolongee de 30 minutes supplementaires chaque fois qu’un visiteur est contacte. Ainsi, le SDK garantit que les donnees ne seront pas supprimees pendant au moins 30 minutes a partir de la derniere requete.
Dans les SDK client (mobile et web), les donnees sont stockees dans des stockages locaux (dans le web LocalStorage). Les donnees peuvent etre stockees indefiniment ; cependant, en utilisant le parametre dataExpirationInterval ou targetingDataCleanupInterval, vous pouvez definir la date d’expiration des donnees, apres laquelle les donnees seront supprimees.
Generalement, il n’est pas necessaire d’appeler manuellement la methode “flush” : les donnees sont envoyees avec d’autres appels aux methodes SDK. Cependant, si vous devez envoyer des donnees a la Data API sans declencher le feature flag du visiteur, utilisez la methode “flush”.
Si vous disposez d’un SDK base sur le serveur, les donnees sont stockees pendant la session du visiteur. Vous n’avez pas besoin de charger les donnees a chaque requete si la session de l’utilisateur n’a pas expire. Dans les SDK mobiles, les donnees sont stockees indefiniment (ou conformement a vos parametres).Si la session de l’utilisateur n’est plus active ou si le visiteur passe d’un appareil a l’autre dans le SDK client, appelez la methode getRemoteVisitorData avec les parametres appropries pour obtenir les donnees envoyees a la Data API. Apres le chargement, les donnees sont incluses dans le ciblage du visiteur.
Si le consentement legal est active, les donnees ne peuvent etre collectees qu’avec le consentement des visiteurs.
Si vous utilisez la regle Experiment et ne recevez pas de statistiques visiteurs, verifiez que :
  • Dans l’application Kameleoon
    • La regle est creee pour le bon environnement (production, staging ou development).
    • La regle est activee (mise sur on).
    • La regle cible un trafic qui peut reellement etre expose.
    • Si le filtrage des bots est active sur votre projet, ajoutez l’User Agent au filtre.
  • Dans le SDK
    • Le KameleoonClient est cree avec la bonne configuration (siteCode, variable environment et, le cas echeant, networkDomain).
    • getVisitorCode est appele une seule fois, et sa valeur est reutilisee partout ou le visitorCode est necessaire.
    • Si vous utilisez le mode hybride (engine.js sur le front), le visitorCode est correctement synchronise avec le front-end.
    • Pour les regles d’expérience, setLegalConsent(true) est appele pour s’assurer que la collecte de donnees est autorisee.
    • Pour les regles de delivrance, isFeatureActive() (ou getVariation()) est appele et retourne true (ou la variation attendue).
    • Pour les regles d’expérience, getVariation() est appele et retourne la variation attendue.
  • Conseils de debogage
    • Journalisez dans la console : la valeur de consentement, le visitorCode et les valeurs de variation, et verifiez qu’elles correspondent a ce que vous voyez dans le navigateur.
    • Activez la journalisation du SDK et verifiez les erreurs eventuelles.
Conformement aux regles RGPD, sans consentement du visiteur, Kameleoon n’utilise que les informations techniques necessaires au bon fonctionnement des fonctionnalites du produit.Sans consentement, Kameleoon envoie les variations pour les regles de Targeted Delivery (mais pas pour les regles d’Experiment). Toutes les autres informations (par exemple, CustomData, Page Views et Geolocation) ne sont envoyees qu’avec le consentement du visiteur (lorsque l’autorisation a ete accordee).Vous pouvez en savoir plus sur la gestion du consentement ici.
Par defaut, le SDK regroupe plusieurs evenements ensemble et envoie une requete de suivi aux serveurs Kameleoon a des fins d’analyse a un intervalle configurable. Cette approche ameliore l’efficacite et reduit la charge du serveur.Une requete de suivi sera envoyee :
  • Periodiquement : Par defaut, une requete est envoyee toutes les 1000 millisecondes (1 seconde). Vous pouvez modifier cet intervalle en definissant la valeur tracking interval.
  • A la demande : Instantanement, si une methode comme flush(instant=true) est appelee dans votre code.
Plus precisement, une requete de suivi est declenchee si l’une des methodes suivantes est appelee avant l’expiration de l’intervalle :
  • getVariation (lorsque track est defini sur true).
  • getVariations (lorsque track est defini sur true).
  • isFeatureActive (lorsque track est defini sur true).
  • trackConversion
  • flush (avec ou sans instant=true)
En plus des appels de methode ci-dessus, les SDK cote client envoient une requete de suivi toutes les 15 secondes si aucune autre activite ne s’est produite. Cette requete aide a maintenir la session du visiteur. L’intervalle de suivi d’activite peut etre configure avec les SDK Android et iOS.Pour les SDK cote serveur, le regroupement d’evenements est particulierement utile car chaque requete de suivi peut consolider les donnees de plusieurs visiteurs dans une seule requete. Cette approche agrege les informations sur tous les visiteurs affectes et les envoie une fois par intervalle, ameliorant l’efficacite et reduisant la charge du serveur.
Les requetes de suivi sont soumises aux limites de debit de la Data API.Pour les SDK cote client, dans les environnements ou plusieurs visiteurs partagent le meme reseau (par exemple, dans un bureau), ils peuvent apparaitre comme provenant de la meme adresse IP, ce qui peut depasser la limite de debit et provoquer une erreur 429 - Too Many Requests.
Dans les differents SDK, les methodes peuvent etre nommees differemment en raison des particularites linguistiques.
Voici une liste des methodes SDK qui effectuent des requetes HTTP :
  • isFeatureActive / getFeatureVariationKey / getFeatureVariable / trackConversion / flush
    • Ces methodes effectuent des requetes asynchrones vers la Data API pour stocker toutes les informations sur le visiteur (y compris les variations recues par l’utilisateur), qui sont utilisees pour afficher les statistiques dans app.kameleoon.com
  • getRemoteData / getRemoteVisitorData / getWarehouseAudience
    • Ces methodes effectuent des requetes synchrones vers la Data API pour obtenir des informations sur le visiteur
  • De plus, le SDK effectue des requetes asynchrones pour obtenir la configuration necessaire au travail interne.
isFeatureActive peut etre appele lorsque vous devez savoir si le flag est actif, mais que vous n’avez pas besoin de connaitre la variation exacte recue pour le visiteur. Lorsque vous utilisez des regles d’expérience, il est preferable d’appeler getFeatureVariationKey si vous avez deux variations ou plus en plus de “off.”
Oui, vous pouvez implementer une integration hybride en utilisant a la fois un SDK cote client (tel que le SDK JavaScript Kameleoon ou le fichier d’application engine.js) et un SDK cote serveur. Dans cette configuration, il est essentiel d’appeler la methode getVisitorCode. Cela garantit une reconnaissance coherente du visiteur entre le navigateur et le serveur, et garantit une allocation coherente des variations lors de l’execution de code cote client (par exemple, le suivi des evenements) et de code cote serveur (comme l’execution de fonctionnalites) pour un feature flag donne.
Vous devez utiliser getVisitorCode dans les cas ou vous utilisez une integration hybride (site web <-> server sdk, js sdk <-> server, engine <-> server sdk). Lors de l’appel a getVisitorCode, le visitor code sera obtenu et transmis a l’aide d’un cookie. Si vous n’utilisez pas d’integration hybride, vous n’avez pas besoin d’appeler getVisitorCode ; cependant, vous pouvez toujours l’appeler pour generer un visitor code aleatoire.
L’installation de domaine est requise pour getVisitorCode. Sinon, vous pourriez obtenir differentes variations pour un meme visiteur, car il aurait differents visitor codes sur differents sous-domaines de votre site.
Si vous utilisez les SDK serveur et client en meme temps, vous devez definir le consentement pour les deux SDK.Veuillez consulter cet article pour plus de details.
Kameleoon, comme de nombreuses solutions d’optimisation d’experience, peut etre bloque par certains bloqueurs de publicites. Ceux-ci affectent principalement le fichier d’application Web Experimentation (engine.js) et les SDK cote client, qui s’appuient sur du code JavaScript charge sur votre site web. Les SDK cote serveur, cependant, fonctionnent au sein de vos serveurs et ne sont pas affectes par les bloqueurs de publicites.Si vous voulez que les utilisateurs avec des bloqueurs de publicites soient inclus dans vos expériences, Kameleoon propose une option premium qui vous permet d’utiliser un domaine personnalise au lieu du domaine par defaut de Kameleoon. Les domaines personnalises empechent les bloqueurs de publicites de detecter et de bloquer Kameleoon. Une fois configure, Kameleoon utilisera votre domaine personnalise pour toutes les requetes reseau sortantes vers nos serveurs, que ce soit a des fins de suivi ou pour recuperer les mises a jour de configuration du SDK.Utiliser un domaine personnalise n’est pas la meme chose que l’auto-hebergement. Lorsque vous utilisez un domaine personnalise, l’infrastructure Kameleoon heberge et sert toujours tout le contenu (par exemple, engine.js, configuration SDK, appels de suivi). La difference est que ces requetes sont acheminees via un domaine que vous controlez, comme experiments.mydomain.com.Pour activer cette option, contactez votre Technical Account Manager. Vous devez fournir un domaine complet (par exemple, experiments-mydomain.com), pas un sous-domaine (par exemple, experiments.mydomain.com). Le nom de domaine ne peut pas contenir la sous-chaine kameleoon.
  • Pour Web Experimentation, remplacez les references au domaine Kameleoon par defaut (kameleoon.) par votre domaine personnalise.
    • Exemple : //SITE_CODE.{your-domain}/engine.js
  • Pour les SDK cote client, utilisez le parametre networkDomain dans l’initialisation du SDK.
Si vous souhaitez vous auto-heberger plutot que d’utiliser un domaine personnalise, suivez ce guide.