Passer au contenu principal
Le mode hybride vous permet de combiner le moteur web Kameleoon et un SDK cote serveur afin que chaque tache utilise l’integration la plus appropriee.
  • Implementez et deployez plus facilement les variations cote serveur, tandis que le suivi vers des outils d’analyse tiers peut etre effectue plus efficacement en utilisant le moteur Kameleoon via le fichier d’application engine.js (anciennement appele kameleoon.js), car de nombreuses solutions d’analyse web tierces ne fonctionnent que sur le front-end.
  • Ciblez les utilisateurs en utilisant les donnees collectees cote client, telles que les conversions d’objectif ou les donnees personnalisees basees sur des variables du data layer, au sein de segments.
  • Filtrez et decomposez les donnees dans les rapports Kameleoon en utilisant plus de 25 points de donnees collectes cote client par le moteur d’application front-end.
  • Excluez les utilisateurs d’un feature flag s’ils ont ete exposes a une experience web ou a une personnalisation.
Cet article decrit comment implementer l’integration optimale entre le SDK web Kameleoon et le fichier d’application front-end Kameleoon afin que les deux cotes communiquent entre eux. Utilisez la balise asynchrone Kameleoon sans anti-flicker.
Pour l’experimentation web, vous devez normalement ajouter la balise d’installation JavaScript soit dans la balise <head>, soit au debut de la balise <body> pour eviter le flickering. Si vous utilisez le mode hybride, ou le flickering n’est pas une preoccupation, vous pouvez installer le script n’importe ou avant la balise fermante </body>, car la balise n’est utilisee qu’a des fins de suivi.
L’experimentation 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 donnees collectes sur le site web peuvent toujours etre exploites si un site web et une application mobile sont proposes. Cela signifie que les donnees recueillies aupres d’un utilisateur identifie sur le site web peuvent egalement etre utilisees dans l’application mobile, a condition que le visiteur soit identifie de maniere coherente sur les deux plateformes.

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

L’un des defis du mode hybride est de s’assurer que Kameleoon peut correctement identifier chaque visiteur comme la meme personne des deux cotes. Dans Kameleoon, cette exigence signifie que le visitorCode, qui est un ID unique pour chaque visiteur, doit etre identique des deux cotes. Par exemple, un visiteur enregistre avec le visitorCode 10ctbql0zpf4rwjy pour une variation d’expérience dans le back-end doit etre associe au visitor code 10ctbql0zpf4rwjy lorsqu’une conversion est declenchee dans le front-end. L’utilisation du meme ID garantit un suivi correct des actions du visiteur, ce qui donne des donnees et des statistiques correctes. Pour synchroniser les ID utilisateur, votre application hybride doit appeler la methode getVisitorCode() avant d’appeler d’autres methodes du SDK. Comme les conventions de nommage varient selon les langages, les noms de methodes varient legerement en fonction du SDK, mais chaque langage dispose d’une methode equivalente nommee de maniere similaire. Kameleoon utilise l’approche suivante :
  1. Sur le front-end, le moteur JavaScript Kameleoon genere aleatoirement un visitorCode pour chaque nouveau visiteur. Le moteur considere un visiteur comme nouveau s’il ne trouve pas de visitor code precedent dans le navigateur de l’utilisateur (par exemple, dans un cookie ou le local storage). Cela se produit normalement lorsque le moteur Kameleoon s’execute pour la premiere fois dans le navigateur du visiteur. Le moteur Kameleoon peut egalement obtenir l’identifiant a partir d’un cookie que le back-end lui transmet. Cette option vous permet de definir l’identifiant cote serveur, plutot que dans le front-end. Par exemple, utilisez cette option si vous souhaitez specifier votre propre visitor code unique pour chaque visiteur.
Si vous unifiez les donnees de session entre sous-domaines, Kameleoon recherche une cle kameleoonVisitorCode dans le local storage. Si la cle est presente, sa valeur est utilisee comme identifiant pour le visitor code. La version local storage de cette cle a toujours la priorite, meme si un cookie kameleoonVisitorCode avec une valeur differente existe. Notez que Kameleoon ne reinitialise pas le cookie JavaScript si les valeurs du local storage et du cookie correspondent. A des fins ITP, il est important de laisser intacts les cookies qui ont pu etre definis cote serveur.
  1. Sur le back-end, vous devez appeler la methode getVisitorCode() ou son equivalent dans votre SDK. Veillez a appeler cette methode avant de fournir un identifiant de visiteur a toute autre methode du SDK. La methode getVisitorCode() prend un argument string optionnel que vous pouvez utiliser pour transmettre votre propre identifiant plutot que de vous fier a un ID Kameleoon genere aleatoirement. Lorsque la methode est appelee, Kameleoon recherche d’abord un cookie ou un parametre de requete kameleoonVisitorCode associe a la requete HTTP en cours. S’il est trouve, le SDK utilise cette valeur comme identifiant du visiteur.
Si aucun cookie ou parametre n’est trouve, Kameleoon utilise l’argument de la methode getVisitorCode(), si vous en avez fourni un, comme identifiant. Si vous ne fournissez pas d’argument, Kameleoon genere l’ID aleatoirement. Dans ces deux cas, Kameleoon definit egalement le cookie kameleoonVisitorCode cote serveur avec la valeur (via un en-tete HTTP). En suivant cette approche, le visitorCode est enregistre et partage entre le front-end et le back-end. Si une expérience est implementee sur la premiere page du parcours d’un visiteur sur votre site web, le SDK generera l’identifiant et le transmettra au moteur JavaScript. Si le parcours commence sur une page ou getVisitorCode() n’est pas appele (ou que le snippet de synchronisation n’est pas execute) sur le back-end, alors le moteur JavaScript generera l’identifiant en premier et le transmettra au SDK. Le SDK le lira puis le reecrira en tant que cookie cote 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’implementer le suivi sur le front-end en utilisant le moteur JavaScript. Il s’agit d’un scenario courant pour les raisons suivantes :
  • Les plateformes d’analyse web (telles que Mixpanel ou Google Analytics 4) tendent a etre implementees sur le front-end.
  • Un plan de tagging standard cote client pour Kameleoon en utilisant la Web Experimentation peut deja etre en place.
  • Le suivi des evenements et des points de donnees cote front-end a des fins d’analyse avec reporting est souvent plus pratique.
  • Il existe des points de donnees adaptes a l’utilisation dans les expériences de feature, qui sont plus faciles a collecter sur le front-end.

​
Envoyer des evenements d’exposition aux analyses tierces​

Kameleoon fournit des integrations natives avec les plateformes d’analyse et CDP. En mode hybride, vous pouvez utiliser n’importe laquelle de ces integrations en combinaison avec des expériences de feature, sans avoir besoin d’ecrire de code supplementaire. Le moteur front-end doit savoir chaque fois qu’une expérience a eu lieu dans le back-end, c’est-a-dire lorsqu’un visiteur a ete affecte a une expérience. Cela garantit que seuls les visiteurs qui ont reellement declenche et vu l’expérience sont comptabilises. Pour atteindre cet objectif, utilisez la methode getEngineTrackingCode() (le nom varie legerement en fonction du SDK), disponible dans tous les SDK cote serveur. Cette methode renvoie le code JavaScript a inserer dans la page pour envoyer automatiquement les evenements d’exposition du front-end vers la solution d’analyse utilisee. Il peut etre integre dans la page HTML retournee. Par exemple : 
<!DOCTYPE html>
<html lang="en">
  <body>
    <script>
      const engineTrackingCode = `
        window.kameleoonQueue = window.kameleoonQueue || [];
        window.kameleoonQueue.push(['Experiments.assignVariation', 123456, 7890]);
        window.kameleoonQueue.push(['Experiments.trigger', 123456, true]);
      `;
      const script = document.createElement('script');

      script.textContent = engineTrackingCode;
      document.body.appendChild(script);
    </script>
  </body>
</html>
Vous devez egalement activer l’integration choisie (par exemple, Google Analytics 4 ou Mixpanel) lors de la configuration de votre expérience de feature. Les donnees 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 envoyees a la plateforme tierce par le moteur JavaScript Kameleoon.

​
Utiliser des points de donnees et des evenements front-end dans les expériences de feature​

Si vous avez implemente Kameleoon en mode hybride, les objectifs et les points de donnees seront automatiquement suivis sur le front-end et apparaitront dans les rapports Kameleoon comme criteres de filtrage et de decomposition. De plus, plusieurs conditions de ciblage seront disponibles dans le SDK Kameleoon, prêtes a etre utilisees a des fins de ciblage.

​
Gerer le consentement en mode hybride​

Lorsque vous utilisez Kameleoon en mode Hybride et que le consentement est defini sur “Required”, assurez-vous que l’API d’activation JavaScript et les methodes du SDK sont appelees lors de la collecte du consentement afin que Kameleoon puisse collecter les evenements utilisateur a la fois depuis le fichier d’application Kameleoon et le SDK. De plus, comme Kameleoon est limite dans le stockage de la cle visitorCode dans un cookie, assurez-vous que la cle visitorCode generee par le SDK pour toutes les premieres requetes est partagee avec le moteur Kameleoon s’executant cote client. Lisez les considerations techniques.
Les informations de consentement sont synchronisees entre le moteur Kameleoon (engine.js) et le SDK JavaScript uniquement lorsque l’un des composants est reinitialise (par exemple, au rechargement de la page ou lors de l’appel de API.Core.load). Par consequent, nous recommandons fortement de gerer explicitement le consentement en utilisant les methodes dediees fournies par le moteur et le SDK, plutot que de s’appuyer sur ce mecanisme de synchronisation.