Skip to main content
Le mode hybride vous permet de combiner le moteur web Kameleoon et un SDK côté serveur afin que chaque tâche utilise l’intégration la plus appropriée.
  • Implémentez et déployez plus facilement les variations côté serveur, tandis que le suivi vers des outils d’analyse tiers peut être effectué plus efficacement en utilisant le moteur Kameleoon via le fichier d’application engine.js (anciennement appelé kameleoon.js), car de nombreuses solutions d’analyse web tierces ne fonctionnent que sur le front-end.
  • Ciblez les utilisateurs en utilisant les données collectées côté client, telles que les conversions d’objectif ou les données personnalisées basées sur des variables du data layer, au sein de segments.
  • Filtrez et décomposez les données dans les rapports Kameleoon en utilisant plus de 25 points de données collectés côté client par le moteur d’application front-end.
  • Excluez les utilisateurs d’un feature flag s’ils ont été exposés à une expérience web ou à une personnalisation.
Cet article décrit comment implémenter l’intégration optimale entre le SDK web Kameleoon et le fichier d’application front-end Kameleoon afin que les deux côtés communiquent entre eux. Utilisez la balise asynchrone Kameleoon sans anti-flicker.
Pour l’expérimentation web, vous devez normalement ajouter la balise d’installation JavaScript soit dans la balise <head>, soit au début de la balise <body> pour éviter le flickering. Si vous utilisez le mode hybride, où le flickering n’est pas une préoccupation, vous pouvez installer le script n’importe où avant la balise fermante </body>, car la balise n’est utilisée qu’à des fins de suivi.
L’expérimentation hybride n’est actuellement compatible qu’avec les SDK web. Bien que les SDK mobiles ne prennent pas encore en charge le mode hybride avec des outils d’analyse web tiers, les points de données collectés sur le site web peuvent toujours être exploités si un site web et une application mobile sont proposés. Cela signifie que les données recueillies auprès d’un utilisateur identifié sur le site web peuvent également être utilisées dans l’application mobile, à condition que le visiteur soit identifié de manière cohérente sur les deux plateformes.

​
Synchroniser les ID utilisateur entre le back-end et le front-end

L’un des défis du mode hybride est de s’assurer que Kameleoon peut correctement identifier chaque visiteur comme la même personne des deux côtés. Dans Kameleoon, cette exigence signifie que le visitorCode, qui est un ID unique pour chaque visiteur, doit être identique des deux côtés. Par exemple, un visiteur enregistré avec le visitorCode 10ctbql0zpf4rwjy pour une variation d’expérience dans le back-end doit être associé au visitor code 10ctbql0zpf4rwjy lorsqu’une conversion est déclenchée dans le front-end. L’utilisation du même ID garantit un suivi correct des actions du visiteur, ce qui donne des données et des statistiques correctes. Pour synchroniser les ID utilisateur, votre application hybride doit appeler la méthode getVisitorCode() avant d’appeler d’autres méthodes du SDK. Comme les conventions de nommage varient selon les langages, les noms de méthodes varient légèrement en fonction du SDK, mais chaque langage dispose d’une méthode équivalente nommée de manière similaire. Kameleoon utilise l’approche suivante :
  1. Sur le front-end, le moteur JavaScript Kameleoon génère aléatoirement un visitorCode pour chaque nouveau visiteur. Le moteur considère un visiteur comme nouveau s’il ne trouve pas de visitor code précédent dans le navigateur de l’utilisateur (par exemple, dans un cookie ou le local storage). Cela se produit normalement lorsque le moteur Kameleoon s’exécute pour la première fois dans le navigateur du visiteur. Le moteur Kameleoon peut également obtenir l’identifiant à partir d’un cookie que le back-end lui transmet. Cette option vous permet de définir l’identifiant côté serveur, plutôt que dans le front-end. Par exemple, utilisez cette option si vous souhaitez spécifier votre propre visitor code unique pour chaque visiteur.
Si vous unifiez les données de session entre sous-domaines, Kameleoon recherche une clé kameleoonVisitorCode dans le local storage. Si la clé est présente, sa valeur est utilisée comme identifiant pour le visitor code. La version local storage de cette clé a toujours la priorité, même si un cookie kameleoonVisitorCode avec une valeur différente existe. Notez que Kameleoon ne réinitialise pas le cookie JavaScript si les valeurs du local storage et du cookie correspondent. À des fins ITP, il est important de laisser intacts les cookies qui ont pu être définis côté serveur.
  1. Sur le back-end, vous devez appeler la méthode getVisitorCode() ou son équivalent dans votre SDK. Veillez à appeler cette méthode avant de fournir un identifiant de visiteur à toute autre méthode du SDK. La méthode getVisitorCode() prend un argument string optionnel que vous pouvez utiliser pour transmettre votre propre identifiant plutôt que de vous fier à un ID Kameleoon généré aléatoirement. Lorsque la méthode est appelée, Kameleoon recherche d’abord un cookie ou un paramètre de requête kameleoonVisitorCode associé à la requête HTTP en cours. S’il est trouvé, le SDK utilise cette valeur comme identifiant du visiteur.
Si aucun cookie ou paramètre n’est trouvé, Kameleoon utilise l’argument de la méthode getVisitorCode(), si vous en avez fourni un, comme identifiant. Si vous ne fournissez pas d’argument, Kameleoon génère l’ID aléatoirement. Dans ces deux cas, Kameleoon définit également le cookie kameleoonVisitorCode côté serveur avec la valeur (via un en-tête HTTP). En suivant cette approche, le visitorCode est enregistré et partagé entre le front-end et le back-end. Si une expérience est implémentée sur la première page du parcours d’un visiteur sur votre site web, le SDK générera l’identifiant et le transmettra au moteur JavaScript. Si le parcours commence sur une page où getVisitorCode() n’est pas appelé (ou que le snippet de synchronisation n’est pas exécuté) sur le back-end, alors le moteur JavaScript générera l’identifiant en premier et le transmettra au SDK. Le SDK le lira puis le réécrira en tant que cookie côté serveur pour contourner les restrictions ITP.

​
Lier les expériences de feature au code de suivi front-end

Il est souvent utile de configurer les variations d’expérience en utilisant un SDK, mais d’implémenter le suivi sur le front-end en utilisant le moteur JavaScript. Il s’agit d’un scénario courant pour les raisons suivantes :
  • Les plateformes d’analyse web (telles que Mixpanel ou Google Analytics 4) tendent à être implémentées sur le front-end.
  • Un plan de tagging standard côté client pour Kameleoon en utilisant la Web Experimentation peut déjà être en place.
  • Le suivi des événements et des points de données côté front-end à des fins d’analyse avec reporting est souvent plus pratique.
  • Il existe des points de données adaptés à l’utilisation dans les expériences de feature, qui sont plus faciles à collecter sur le front-end.

​
Envoyer des événements d’exposition aux analyses tierces

Kameleoon fournit des intégrations natives avec les plateformes d’analyse et CDP. En mode hybride, vous pouvez utiliser n’importe laquelle de ces intégrations en combinaison avec des expériences de feature, sans avoir besoin d’écrire de code supplémentaire. Le moteur front-end doit savoir chaque fois qu’une expérience a eu lieu dans le back-end, c’est-à-dire lorsqu’un visiteur a été affecté à une expérience. Cela garantit que seuls les visiteurs qui ont réellement déclenché et vu l’expérience sont comptabilisés. Pour atteindre cet objectif, utilisez la méthode getEngineTrackingCode() (le nom varie légèrement en fonction du SDK), disponible dans tous les SDK côté serveur. Cette méthode renvoie le code JavaScript à insérer dans la page pour envoyer automatiquement les événements d’exposition du front-end vers la solution d’analyse utilisée. Il peut être intégré dans la page HTML retournée. Par exemple :
Vous devez également activer l’intégration choisie (par exemple, Google Analytics 4 ou Mixpanel) lors de la configuration de votre expérience de feature. Les données pertinentes (telles que l’ID d’expérience, le nom de l’expérience, l’ID de variation, le nom de la variation) seront automatiquement envoyées à la plateforme tierce par le moteur JavaScript Kameleoon.

​
Utiliser des points de données et des événements front-end dans les expériences de feature

Si vous avez implémenté Kameleoon en mode hybride, les objectifs et les points de données seront automatiquement suivis sur le front-end et apparaîtront dans les rapports Kameleoon comme critères de filtrage et de décomposition. De plus, plusieurs conditions de ciblage seront disponibles dans le SDK Kameleoon, prêtes à être utilisées à des fins de ciblage.

​
Gérer le consentement en mode hybride

Lorsque vous utilisez Kameleoon en Hybrid mode et que le consentement est défini sur “Required”, assurez-vous que l’API d’activation JavaScript et les méthodes du SDK sont appelées lors de la collecte du consentement afin que Kameleoon puisse collecter les événements utilisateur à la fois depuis le fichier d’application Kameleoon et le SDK. De plus, comme Kameleoon est limité dans le stockage de la clé visitorCode dans un cookie, assurez-vous que la clé visitorCode générée par le SDK pour toutes les premières requêtes est partagée avec le moteur Kameleoon s’exécutant côté client. Lisez les considérations techniques.
Les informations de consentement sont synchronisées entre le moteur Kameleoon (engine.js) et le SDK JavaScript uniquement lorsque l’un des composants est réinitialisé (par exemple, au rechargement de la page ou lors de l’appel de API.Core.load). Par conséquent, nous recommandons fortement de gérer explicitement le consentement en utilisant les méthodes dédiées fournies par le moteur et le SDK, plutôt que de s’appuyer sur ce mécanisme de synchronisation.

​
FAQ

Utilisez le script d’application Kameleoon pour les expériences web créées avec l’éditeur graphique ou l’éditeur de code. Utilisez le SDK web pour les feature flags et les expériences de feature.Notez que Kameleoon peut fonctionner en Hybrid mode. Le Hybrid mode utilise à la fois les SDK web et le fichier d’application JavaScript Kameleoon. Il vous permet d’utiliser l’approche optimale pour chaque tâche. Par exemple, vous pouvez implémenter et déployer plus facilement les variations côté serveur, tandis que le fichier JavaScript assure un suivi plus efficace.
Oui, vous pouvez implémenter une intégration hybride en utilisant à la fois un SDK côté client (comme le SDK JavaScript Kameleoon ou le fichier d’application engine.js) et un SDK côté serveur. Dans cette configuration, il est essentiel d’appeler la méthode getVisitorCode. Cet appel garantit une reconnaissance cohérente du visiteur entre le navigateur et le serveur, ainsi qu’une allocation cohérente des variations lorsque le code côté client (par exemple, le suivi des événements) et le code côté serveur (comme l’exécution du feature flag) s’exécutent pour un feature flag donné.
Utilisez getVisitorCode dans une intégration hybride, lorsqu’un site web, un SDK JavaScript ou le moteur fonctionne avec un SDK serveur. Lorsque vous appelez getVisitorCode, la méthode obtient le visitor code et le transmet à l’aide d’un cookie. Si vous n’utilisez pas d’intégration hybride, vous n’avez pas besoin d’appeler getVisitorCode. Vous pouvez toutefois l’appeler pour générer un visitor code aléatoire.
La configuration du domaine est importante lorsque vous utilisez getVisitorCode. Sans elle, un même visiteur peut recevoir des visitor codes différents, et donc des variations différentes, sur les sous-domaines de votre site. Pour les étapes de configuration, consultez Configuration du domaine.
Si vous utilisez des SDK serveur et client en même temps, vous devez définir le consentement pour les deux SDK. Consultez Gérer le consentement en mode hybride pour la configuration hybride, ainsi que l’article sur la gestion du consentement pour plus de détails.