Passer au contenu principal
Kameleoon met régulièrement à jour cette liste avec les questions courantes des clients.
Si votre site web restreint le chargement de ressources (scripts, images, médias, CSS) via l’en-tête HTTP standard Content-Security-Policy (CSP), mettez à jour la CSP de votre site pour permettre le chargement des ressources Kameleoon.

Configuration simple (avec caractères génériques)

script-src l’emporte toujours sur default-src. N’utilisez pas cette configuration si vous utilisez déjà la configuration complète dans votre CSP.
Ajoutez le contenu suivant à la configuration de votre en-tête CSP :

Configuration complète (entièrement détaillée)

Kameleoon ajoute régulièrement de nouvelles fonctionnalités au produit, ce qui peut entraîner des URL supplémentaires. Listez explicitement tous les hôtes et types de ressources possibles (script, image, etc.) dans l’en-tête CSP.
Remplacez [your-site-code] par votre site code Kameleoon dans chaque ligne où il apparaît et ajoutez ceci à votre configuration :
Chaque URL de la politique CSP a un objectif spécifique :
Web Experimentation
  • https://[your-site-code].kameleoon.xx : Charge le script de l’application Kameleoon Web Experimentation, engine.js (précédemment nommé kameleoon.js).
  • https://(eu|na)-data.kameleoon.(eu|io) : Utilisé pour le suivi.
  • https://logger.kameleoon.io : Envoie les données de suivi pour la journalisation.
  • https://data.kameleoon.net : Requis si vous utilisez l’outil de simulation Kameleoon pour faire le QA des expériences sur plusieurs sous-domaines.
Feature Experimentation (SDK côté client)
  • https://client-config.kameleoon.com : Requis pour les versions de SDK < 2.1.0.
  • https://sdk-config.kameleoon.eu : Requis pour les versions de SDK >= 2.1.0.
  • https://(eu|na)-data.kameleoon.(eu|io) : Utilisé pour le suivi.
  • https://logger.kameleoon.io : Envoie les données de suivi pour la journalisation.
Éditeurs graphiques
  • https://static.kameleoon.com : (déprécié) Charge les ressources statiques de l’ancien éditeur graphique.
  • https://editor.kameleoon.com : (déprécié) Utilisé par l’ancien éditeur graphique.
  • https://graphical-editor.kameleoon.com : Utilisé par le nouvel éditeur graphique.
  • https://storage.kameleoon.(eu|io) : Charge les images utilisées dans les expériences créées avec les éditeurs graphiques.
Prompt-Based Experimentation (PBX)
  • https://aibuilder.kameleoon.com : Utilisé par l’éditeur basé sur prompt.
  • https://electra.kameleoon.com : Utilisé par l’éditeur basé sur prompt.
  • https://storage.kameleoon.(eu|io) : Charge les images dans l’éditeur basé sur prompt.
  • https://api.kameleoon.com : Charge les informations liées au compte.
  • https://sdk-config.kameleoon.eu : Contrôle les feature flags Kameleoon activés dans l’éditeur basé sur prompt.
  • wss://electra.kameleoon.com : Utilisé pour les échanges de données.
Simulation
  • https://api.kameleoon.com : Utilisé par l’ancienne simulation.
  • https://simulation.kameleoon.com : Utilisé par la nouvelle simulation.
Recommandation produit
  • https://static.products.kameleoon.com : Charge les ressources pour le module de recommandation produit.
  • https://api.products.kameleoon.com : API utilisée par le module de recommandation produit.
  • https://images.products.kameleoon.com : Charge les images de produits pour les recommandations.
API et intégrations
  • https://api.kameleoon.com : Requis si vous comptez utiliser l’API d’automatisation pour les tests directement depuis le navigateur.
  • https://customers.kameleoon.com : Requis si vous utilisez l’API SDK ou une intégration personnalisée développée par Kameleoon.
Ressources internes
Par défaut, engine.js n’inclut pas les chemins de simulation ni les informations spécifiques à l’application pour minimiser la taille du script. Pour fournir ces détails, chargez le script complet kameleoonFull.js, qui fournit à engine.js les données nécessaires sur les ressources internes et les instructions de chargement.
  • https://static.kameleoon.com : Charge les ressources internes.
  • https://static.experimentation.dev : Charge les ressources internes.
  • https://sdk-config.experimentation.dev : Contrôle les feature flags Kameleoon activés dans le produit Kameleoon.
  • https://eu-data.experimentation.dev : Envoie les données de suivi à des fins de journalisation.
Le domaine de vos scripts Kameleoon https://[your-site-code].kameleoon.xx peut varier d’un projet à l’autre. Les projets utilisent soit kameleoon.eu soit kameleoon.io selon leur date de création. Utilisez le domaine affiché dans l’application Kameleoon pour votre projet.
Non. Le script de Kameleoon utilise une technologie de pointe pour s’exécuter de manière asynchrone (lorsque le snippet d’installation asynchrone est utilisé) et reste entièrement mis en cache par le navigateur pendant 90 minutes. Il ne bloque jamais le chargement de la page, même lors de rares incidents CDN (disponibilité de 99,99 %). En moyenne, le script se charge en moins de 70 ms sur une connexion 4G ou des conditions réseau plus rapides.Kameleoon minimise encore l’impact grâce à des techniques de compression avancées, combinant TypeScript et Brotli, ce qui donne une taille de script de base de seulement 28,4 Ko.

Livraison CDN et évolutivité

Le script engine.js est servi via le CDN Cloudflare, ce qui signifie qu’il évolue automatiquement quel que soit le volume de trafic de votre site web. Il n’y a aucun problème de chargement ou de lenteur, quel que soit le niveau de trafic — le réseau mondial de Cloudflare gère la diffusion, de sorte que ni les pics ni un trafic élevé soutenu n’affectent les performances du script pour vos visiteurs.

Mise en cache

Par défaut, le navigateur met en cache engine.js pendant 90 minutes, ce qui minimise les temps de chargement répétés pour les visiteurs récurrents. Si votre cas d’usage nécessite une durée de cache plus courte, elle peut être réduite — jusqu’à seulement 1 minute — sur demande. Contactez le support Kameleoon pour ajuster ce paramètre pour votre compte.

Considérations importantes

La taille du script peut augmenter en fonction du nombre d’expériences que vous exécutez et de leur contenu (CSS/JavaScript).Pour les expériences ou campagnes de personnalisation qui n’ont pas besoin de se charger immédiatement, utilisez le tag « DELAYED ». Cela retarde le chargement des expériences non essentielles après le premier chargement de la page. Kameleoon gère ces expériences intelligemment : il ne télécharge la configuration qu’après 10 secondes d’inactivité ou lorsqu’un visiteur est ciblé et alloué à une variation autre que la version de contrôle. Cette approche garantit un impact minimal sur les performances de chargement tout en offrant une fonctionnalité complète pour les expériences prioritaires.

Web Experimentation (engine.js)

Le moteur engine.js traite les requêtes sortantes via une file d’attente interne qui s’exécute environ toutes les 500 ms. La file regroupe les événements en lots et envoie des lots supplémentaires de manière récursive si nécessaire. Lors du déchargement ou du nettoyage de la page, le moteur force le traitement immédiat de tous les événements en attente. Sur Safari, le moteur conserve les événements non envoyés dans le stockage de session pour éviter la perte de données.Le moteur envoie également un événement d’activité toutes les 60 secondes lorsqu’un défilement ou un clic est détecté. Lorsqu’aucune activité n’est détectée, le moteur n’effectue aucun appel de suivi supplémentaire.

Feature Experimentation (SDKs)

Pour les cas d’utilisation avec des feature flags et des SDKs, Kameleoon effectue les évaluations de flags localement après l’initialisation. Les requêtes de suivi vers la Data API sont regroupées en lots et envoyées en arrière-plan plutôt qu’individuellement pour chaque évaluation. Le regroupement en lots réduit le volume des requêtes et évite la dégradation des performances lors des pics de trafic. L’intervalle de vidage est configurable dans le SDK, avec une valeur par défaut d’une seconde.

Limites de débit de la Data API

Kameleoon applique des limites de débit à la Data API pour protéger la fiabilité du service. Les limites sont basées sur votre nombre contractuel de visiteurs uniques mensuels (MUV) et l’adresse IP du demandeur. Si vous dépassez ces limites, l’API renvoie HTTP 429.Ces limites s’appliquent à toutes les requêtes qui atteignent la Data API, notamment les appels de suivi qu’engine.js envoie automatiquement et les requêtes de suivi regroupées que les SDK Feature Experimentation envoient. Dans les environnements où de nombreux visiteurs partagent une seule adresse IP (comme les bureaux ou les réseaux d’entreprise), les limites basées sur l’IP peuvent s’appliquer même si vos MUV totaux restent dans les limites du contrat.Pour les intégrations côté serveur, vous pouvez lever les limites basées sur l’IP en authentifiant vos requêtes. Si votre cas d’utilisation nécessite des limites plus élevées, contactez le support Kameleoon pour discuter des options.Les limites de débit s’appliquent à l’ensemble de votre compte client, et non à des projets individuels. Si un projet génère un nombre excessif de requêtes (par exemple parce qu’une implémentation défectueuse crée une boucle qui envoie des événements de données personnalisées de manière répétée), ce projet consomme la limite partagée du compte et peut provoquer des erreurs HTTP 429 dans tous vos autres projets.Pour identifier le projet qui génère un trafic inattendu, utilisez la page Live events (Insights > Live events). Sélectionnez chaque projet tour à tour et comparez le nombre d’événements de la dernière heure ou des dernières 24 heures avec le volume attendu. Un projet générant beaucoup plus d’événements que ne le justifie son volume de visiteurs (par exemple, des dizaines de millions d’événements pour un contrat de 100 000 MUV) est probablement la source du problème. Filtrez les événements par type pour identifier la cause : les événements de données personnalisées sont les plus souvent responsables, souvent parce qu’une boucle mal configurée envoie la même variable de données personnalisées, ou toutes les variables de données personnalisées, à chaque chargement de page.

Évolutivité de la plateforme

La plateforme Kameleoon utilise la mise à l’échelle horizontale, une infrastructure à mise à l’échelle automatique, la répartition de charge, et des tests de charge et de stress réguliers. Pour plus de détails, voir Comment la plateforme Kameleoon prend-elle en charge l’évolutivité et l’élasticité ?.
Le moteur JavaScript Kameleoon nécessite la fonction eval() pour ajouter du code personnalisé à Kameleoon, comme des données personnalisées et du JavaScript personnalisé, lors de la mise en œuvre de variations d’une page. La fonction eval() permet à Kameleoon d’exécuter dynamiquement ce code personnalisé au moment de l’exécution.Si vous utilisez une directive Content Security Policy (CSP) qui empêche l’utilisation de la fonction eval(), implémentez le snippet JavaScript suivant avant le tag d’installation Kameleoon :
Si votre CSP bloque eval(), la mise en œuvre du snippet de code ne supprimera pas ces restrictions. Pour assurer une fonctionnalité complète, ajustez la directive CSP concernée pour autoriser eval() ou des fonctions similaires. Sinon, certaines fonctionnalités avancées de ciblage ou de personnalisation dans Kameleoon resteront inaccessibles en raison de l’application des règles de sécurité du navigateur.
L’éditeur graphique Kameleoon (y compris le panneau de simulation) nécessite également la fonction eval(). Cependant, vous pouvez contourner cette exigence en installant l’extension Chrome Kameleoon et en activant le paramètre Dev Tools > Tag injection > Bypass policies pour outrepasser localement les politiques. Vous devez également fournir votre sitecode. L’activation du paramètre Bypass policies vous permet d’utiliser l’éditeur graphique dans un navigateur Chrome.
Paramètre Bypass policies dans l'extension Chrome
Certaines fonctionnalités de Kameleoon ne sont pas disponibles si une directive CSP bloque la fonction eval(). Ces limitations s’appliquent même si vous utilisez l’un des snippets de code ou contournements mentionnés dans la FAQ. Les fonctionnalités suivantes resteront indisponibles sauf si votre CSP autorise explicitement eval() :
  • Cibler un segment avec une condition JavaScript personnalisée (uniquement pris en charge lorsque la condition s’exécute de manière asynchrone).
Paramètre asynchrone de la condition de ciblage
  • Utiliser des données personnalisées avec du code JavaScript personnalisé.
  • Utiliser des canaux d’acquisition avec du code JavaScript personnalisé.
Oui, Kameleoon propose cette option avancée. Transférez toutes les requêtes HTTP reçues sur votre serveur vers (eu|na)-data.kameleoon.(eu|io). Par exemple, si vous choisissez tracking.yourdomain.com comme domaine de suivi, une requête de suivi serait une POST vers tracking.yourdomain.com. Votre serveur devrait alors transférer la requête, avec toutes les données et paramètres nécessaires, vers l’hôte (eu|na)-data.kameleoon.(eu|io). Pour activer cette option, contactez votre Customer Success Manager.
Lors du transfert des requêtes vers (eu|na)-data.kameleoon.(eu|io), assurez-vous de réécrire l’URL de la requête vers (eu|na)-data.kameleoon.(eu|io). Il ne suffit pas de transférer la requête en conservant l’en-tête HTTP Host: d’origine défini sur votre domaine. Définissez l’en-tête Host: sur (eu|na)-data.kameleoon.(eu|io).
Malheureusement, non. Bien que SRI offre une fonctionnalité de sécurité utile, le fichier d’application Kameleoon change au fil du temps. Si ce n’était pas le cas, des fonctionnalités comme démarrer et arrêter des expériences instantanément sans redéploiement seraient impossibles. Comme le contenu du fichier change, le hash de la ressource change également, ce qui signifie que SRI ne peut pas être utilisé. Sinon, le navigateur bloquerait la ressource dès qu’elle serait mise à jour sur les serveurs.
Il s’agit d’un bug connu sur Firefox. En attendant que l’équipe Firefox le corrige, suivez ce contournement : assurez-vous que votre ressource CSS liée est suivie d’une balise <script> (même presque vide).Exemple :
Cela supprime entièrement l’effet de clignotement.
Les scripts Kameleoon sont déjà courts, et utiliser une version minifiée n’affecte pas significativement le temps de chargement de la page car le code est déjà compressé avec Brotli ou Gzip. Kameleoon ne recommande pas les versions minifiées, mais si nécessaire, elles sont disponibles ci-dessous.

Chargement asynchrone avec anti-flicker

Unifier les données de session entre sous-domaines

Si vous utilisez le tag de données de session unifiées pour unifier les données de session entre sous-domaines avec soit le tag synchrone, soit le tag asynchrone sans anti-flicker :
Si vous utilisez le tag de données de session unifiées et le tag asynchrone avec anti-flicker, ajoutez les trois balises de script dans l’ordre suivant :
  1. Tag asynchrone avec anti-flicker.
  2. Tag de données de session unifiées.
  3. Tag d’installation Kameleoon.
Ne modifiez pas les tags d’installation. Leur code est largement testé et optimisé. Les modifier peut entraîner une configuration non fonctionnelle. Si un tag d’installation nécessite une modification, contactez votre Customer Success Manager Kameleoon pour coordonner avec les développeurs. Ne tentez pas de modifications indépendantes.
N’incluez aucun tag d’installation dans son propre script externe séparé. Par exemple, ne faites jamais ceci :
Bien que cela puisse techniquement fonctionner, cela affecte significativement les performances de Kameleoon et introduit un effet de clignotement notable. Cette configuration crée les problèmes de l’utilisation d’un tag manager sans aucun des avantages associés.
Oui, les partitions où les données sont stockées peuvent être chiffrées. Cette option nécessite un coût de configuration supplémentaire. Contactez votre Customer Success Manager pour plus d’informations.
Oui, vous pouvez différer les expériences non essentielles après le premier chargement de page. Pour différer une expérience, ajoutez le tag DELAYED aux expériences que vous souhaitez reporter. Pour plus d’informations, consultez la documentation sur la gestion des tags.Kameleoon gère intelligemment les expériences taguées « DELAYED ». Il ne télécharge la configuration qu’après 10 secondes d’inactivité ou lorsque le visiteur est ciblé et alloué à une variation autre que la version de contrôle. Concentrez-vous sur la fourniture de la meilleure expérience utilisateur en différant les tests gourmands en ressources.
La plateforme Kameleoon offre une évolutivité et une élasticité élevées, garantissant des performances optimales à mesure que les volumes de données augmentent. La plateforme gère une charge moyenne de 20 000 requêtes par seconde avec des pics jusqu’à 100 000 requêtes. Les facteurs clés incluent :
  • Architecture évolutive : L’architecture distribuée et modulaire permet un dimensionnement horizontal.
  • Infrastructure à mise à l’échelle automatique : L’infrastructure basée sur le cloud met à l’échelle automatiquement les ressources de calcul.
  • Répartition de charge : Des techniques avancées répartissent uniformément le trafic entre les serveurs.
  • Ingestion et traitement des données : Des API robustes et un broker de données gèrent efficacement de grands volumes de données.
  • Tests d’évolutivité : Les tests réguliers de charge et de stress garantissent que le système gère des conditions extrêmes.
  • Stockage de données élastique : Le stockage à plusieurs niveaux permet un accès rapide aux données et une évolutivité à long terme.
Kameleoon utilise les bases de données NoSQL et technologies suivantes dans l’architecture de flux de données :
  • Hadoop File System (avec Spark)
  • Cassandra
  • ClickHouse
  • Kafka
Le moteur Kameleoon initie plusieurs requêtes réseau pour assurer un fonctionnement transparent :

Requête de segments

  • Objectif : Collecte les événements pour les segments ciblés par le visiteur.
  • Endpoint : https://${SITECODE}.kameleoon.io/audiences/segments.js
  • Méthode : GET
  • Note : Le navigateur met le fichier en cache pendant 90 minutes.

Requête de configuration des expériences en mise à jour en direct

  • Objectif : Récupère la configuration des expériences taguées LIVE-UPDATE.
  • Endpoint : https://${SITECODE}.kameleoon.io/live-experiments/config.js
  • Méthode : GET
  • Note : Le navigateur met le fichier en cache pendant 2 minutes.

Requête de variation d’expérience différée

  • Objectif : Charge les données de variation pour les expériences taguées DELAYED.
  • Endpoint : https://${SITECODE}.kameleoon.io/experiments/${action.id}/variations/${variationId}.js
  • Méthode : GET
  • Note : Le navigateur met le fichier en cache pendant 30 jours.

Requête de variation de personnalisation différée

  • Objectif : Charge les données de variation pour les personnalisations taguées DELAYED.
  • Endpoint : https://${SITECODE}.kameleoon.io/personalizations/${action.id}/variations/${variationId}.js
  • Méthode : GET
  • Note : Le navigateur met le fichier en cache pendant 30 jours.

Requête des visites précédentes

Requête des événements de suivi

  • Objectif : Enregistre les événements pendant les visites.
  • Endpoint : https://(eu|na)-data.kameleoon.(eu|io)/visit/events
  • Méthode : POST
Kameleoon envoie un événement toutes les 60 secondes lorsqu’un défilement ou un clic se produit. Cela garantit le suivi correct de la durée de session. Si le moteur ne détecte aucune activité, il n’effectue pas d’appel de suivi supplémentaire.

Requête d’adresse IP

  • Objectif : Permet l’exclusion/inclusion de visiteurs en fonction de l’adresse IP.
  • Endpoint : https://(eu|na)-data.kameleoon.(eu|io)/ip
  • Méthode : GET
  • Note : Kameleoon ne stocke jamais les IPs dans des bases de données. Le navigateur du visiteur utilise l’IP uniquement à des fins de comparaison.

Requête de géolocalisation

  • Objectif : Obtient les données de géolocalisation pour le ciblage et l’analyse.
  • Endpoint : https://(eu|na)-data.kameleoon.(eu|io)/geolocation
  • Méthode : GET

Requête météo actuelle

  • Objectif : Retourne les conditions météorologiques actuelles.
  • Endpoint : https://(eu|na)-data.kameleoon.(eu|io)/weather/weather
  • Méthode : GET

Requête de prévisions météorologiques

  • Objectif : Retourne des prévisions météo sur 5 jours.
  • Endpoint : https://(eu|na)-data.kameleoon.(eu|io)/weather/forecast
  • Méthode : GET

Requête de détection du script Kameleoon

  • Objectif : Détecte le statut d’implémentation du script Kameleoon.
  • Endpoint : https://(eu|na)-data.kameleoon.(eu|io)/active-script/event
  • Méthode : POST

Requête des produits

  • Objectif : Recueille les événements produits pour le ciblage et les recommandations.
  • Endpoint : https://(eu|na)-data.kameleoon.(eu|io)/product/events
  • Méthode : POST

Requête des scores de conversion Kameleoon

  • Objectif : Récupère les scores prédictifs pour le ciblage.
  • Endpoint : https://(eu|na)-data.kameleoon.(eu|io)/predict/latestPredictionScoreHistograms
  • Méthode : GET
Le service standard de Kameleoon repose sur une architecture SaaS multi-tenant. Vos données partagent l’infrastructure avec d’autres tenants, mais elles sont logiquement isolées de toutes les autres données clients grâce aux contrôles d’accès basés sur les rôles, la ségrégation des environnements et l’hébergement régional. Aucun autre tenant ne peut accéder à vos données.Si vos exigences de sécurité nécessitent une isolation physique, Kameleoon propose une option d’architecture mono-tenant. Contactez votre Customer Success Manager Kameleoon pour discuter de l’hébergement mono-tenant avant de signer votre contrat.
Kameleoon contrôle l’accès des employés aux comptes clients selon un modèle d’accès basé sur les rôles et le principe du moindre privilège. Les employés n’obtiennent un accès que lorsqu’un besoin opérationnel légitime l’exige : livraison de service, support, dépannage, opérations de sécurité ou réponse aux incidents. L’accès à votre compte n’est pas largement disponible au sein de Kameleoon ; seul le personnel autorisé avec un besoin documenté peut y accéder.

Qui peut accéder à votre compte

L’accès autorisé peut inclure du personnel de support ou de service affecté à votre compte. L’accès au niveau production est réservé au personnel technique spécifiquement autorisé. Tout accès aux systèmes de production nécessite une authentification multi-facteurs (MFA) et fait l’objet de révisions régulières.

Ce que les employés peuvent faire dans votre compte

Les employés de Kameleoon ne peuvent pas effectuer d’actions sans restriction dans votre compte. Les autorisations basées sur les rôles, la ségrégation des environnements et les contrôles d’autorisation au niveau tenant limitent toutes les activités. Tous les accès et actions administratives sont enregistrés et auditables.