Skip to main content

Gestion du consentement

Selon le pays dans lequel vous exploitez votre site web, vous devrez peut-être gérer le consentement avant de collecter des données sur vos visiteurs. Pour plus de détails, consultez la documentation sur la gestion du consentement.

Réconciliation cross-device de l’historique

La fonctionnalité de réconciliation cross-device de l’historique de Kameleoon fusionne l’historique et les actions d’un utilisateur sur différents appareils. Lorsqu’un utilisateur visite un site web plusieurs fois via différents appareils, Kameleoon l’identifie comme un visiteur récurrent et signale avec précision le nombre de visites. Cette fonctionnalité est simple à activer tant que vous pouvez identifier les utilisateurs, généralement via une connexion client. En utilisant la réconciliation cross-device de l’historique, vous bénéficiez de trois avantages majeurs :
  • Un système de ciblage cohérent qui prend en compte toutes les visites et actions sur les appareils.
  • Garantir qu’un visiteur voit la même variation pour une expérience A/B donnée, indépendamment de l’appareil qu’il utilise.
  • Un système de reporting précis et fiable qui compte correctement les visiteurs uniques.
Pour en savoir plus sur cette fonctionnalité, vous pouvez consulter cette documentation.

Gestion ITP

Si une part importante du trafic de votre site web provient d’appareils mobiles, mettez en œuvre une méthode de synchronisation des cookies pour éviter les problèmes liés à l’Intelligent Tracking Prevention (ITP) sur Safari. Pour plus de détails techniques sur la gestion ITP, consultez la documentation. Plusieurs options sont disponibles pour synchroniser l’identifiant visitorCode (via le cookie kameleoonVisitorCode) entre le frontend et le backend afin d’éviter les problèmes ITP sur Safari. Ces options incluent :
  • Modifier la configuration de votre serveur web frontal ou de votre Content Delivery Network (CDN) pour générer et ajouter le cookie kameleoonVisitorCode. Kameleoon peut fournir des instructions pour Akamai.
  • Implémenter un snippet de code spécifique sur votre serveur backend (Java, NodeJS ou un autre langage).

Snippet de code Nginx

Pour l’intégration avec Nginx, utilisez le snippet de code suivant :

Snippets de code backend

Vous pouvez héberger l’un des snippets de code backend soit sur une URL unique appartenant à votre domaine principal, soit sur chaque page. Si vous optez pour un endpoint unique, Kameleoon effectue un appel par session vers l’endpoint spécifié pour s’assurer que votre serveur définit le cookie kameleoonVisitorCode. Cet appel est asynchrone et se produit après le chargement complet de la page. Contactez votre Technical Account Manager pour activer cette option. Kameleoon aura besoin de l’URL que vous choisissez.
L’endpoint de synchronisation que vous créez ne doit retourner aucune donnée. Un code de réponse 204 No Content suffit. Cet endpoint est utilisé uniquement pour définir un cookie côté serveur et doit accepter une requête GET envoyée à l’URL de synchronisation que vous définissez, en utilisant le code suivant :
Si vous intégrez le snippet de code backend sur chaque page, vous n’avez besoin d’aucune action supplémentaire. Le snippet crée automatiquement le cookie lorsque les requêtes de page normales atteignent vos serveurs.
Vous pouvez fournir votre propre code visiteur, généralement un identifiant unique de votre base de données, au lieu de vous appuyer sur la génération automatique. Assurez-vous que le visitorCode que vous fournissez est unique pour chaque visiteur afin de contribuer à garantir des données précises pour vos expériences.
Si vous utilisez à la fois Kameleoon Web et Feature Experiments avec l’un des SDKs côté serveur, vous pouvez directement utiliser la méthode getVisitorCode(). Cette méthode utilitaire récupère automatiquement le code visiteur Kameleoon pour le visiteur actuel et crée le cookie côté back-end.

Java

NodeJS

PHP

Copiez-collez ce code et remplacez MY_DOMAIN par votre domaine principal de base (par exemple, mydomain.com).

C#

Go

Python

Ruby

Utiliser un domaine personnalisé

Si vous voulez utiliser votre propre domaine au lieu du domaine par défaut de Kameleoon, ou si des bloqueurs de publicités empêchent certains utilisateurs d’entrer dans les expériences, Kameleoon offre une option premium pour configurer un domaine personnalisé et contourner la détection. En savoir plus sur l’activation d’un domaine personnalisé.

Utiliser votre propre CDN ou serveur d’hébergement (auto-hébergement)

Le fichier d’application Kameleoon engine.js (précédemment nommé kameleoon.js), que vous pouvez héberger soit sur le CDN Kameleoon, soit sur votre propre CDN ou vos propres serveurs. L’héberger sur vos propres serveurs peut offrir une légère amélioration de performance en évitant une requête DNS et une poignée de main SSL supplémentaires que le CDN Kameleoon nécessite. De plus, vous pouvez choisir l’auto-hébergement pour des raisons de sécurité, car vous pouvez garantir la conformité avec vos politiques de sécurité internes et assumer la responsabilité de la sécurité de vos serveurs d’hébergement. Si vous voulez auto-héberger le fichier d’application Kameleoon, consultez la documentation auto-hébergement.

FAQ

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 Technical Account 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).
Certains bloqueurs de publicités peuvent bloquer Kameleoon, comme de nombreuses solutions d’optimisation de l’expérience. Ces bloqueurs affectent principalement le fichier d’application Web Experimentation (engine.js) et les SDK côté client, qui s’appuient sur du code JavaScript chargé sur votre site web. En revanche, les SDK côté serveur fonctionnent au sein de vos serveurs et ne sont pas affectés par les bloqueurs de publicités.Si vous souhaitez inclure dans vos expériences les utilisateurs qui utilisent un bloqueur de publicités, Kameleoon propose une option premium qui vous permet d’utiliser un domaine personnalisé à la place du domaine par défaut de Kameleoon. Les domaines personnalisés empêchent les bloqueurs de publicités de détecter et de bloquer Kameleoon. Une fois configuré, Kameleoon utilise votre domaine personnalisé pour toutes les requêtes réseau sortantes vers les serveurs de Kameleoon, qu’il s’agisse du suivi ou de la récupération des mises à jour de configuration du SDK.Utiliser un domaine personnalisé n’est pas la même chose que l’auto-hébergement. Lorsque vous utilisez un domaine personnalisé, l’infrastructure de Kameleoon continue d’héberger et de diffuser tout le contenu (par exemple, engine.js, la configuration du SDK, les appels de suivi). La différence est que Kameleoon achemine ces requêtes par un domaine dédié que vous fournissez, tel que experiments-mydomain.com.Pour activer cette option, contactez votre Technical Account Manager. Vous devez fournir un domaine complet dédié, tel que experiments-mydomain.com. Le nom de domaine ne peut pas contenir la sous-chaîne kameleoon.
  • Pour Web Experimentation, remplacez les références au domaine Kameleoon par défaut (kameleoon.) par votre domaine personnalisé.
    • Exemple : //SITE_CODE.experiments-mydomain.com/engine.js
  • Pour les SDK côté client, utilisez le paramètre networkDomain lors de l’initialisation du SDK.
Si vous souhaitez vous auto-héberger au lieu d’utiliser un domaine personnalisé, suivez le guide d’auto-hébergement simple.