Passer au contenu principal
Les split tests par redirection d’URL ne sont disponibles que dans le Graphic editor et le Code editor — ils ne sont pas disponibles dans PBX.
Contrairement à une expérience A/B classique, une expérience A/B avec redirection d’URL implique que les différentes versions de la page testée soient développées et hébergées sur votre serveur web : les versions sont rendues disponibles aux visiteurs directement via votre site web. Prenons l’exemple suivant : vous avez deux pages d’inscription que vous souhaitez tester. Voici leurs URL : http://mywebsite.com/SubscriptionA.html http://mywebsite.com/SubscriptionB.html Les pages sont accessibles via votre site web. Avec Kameleoon, vous pouvez A/B tester ces deux pages et analyser leurs performances et résultats.

​
Redirection simple d’URL

Lancez le Graphic editor ou le Code editor de Kameleoon comme d’habitude. Cliquez sur la flèche à côté de Add variation et sélectionnez Add URL redirection. Vous pouvez alors configurer la redirection d’URL pour la variation. Il existe deux types de redirection : Global redirection et Redirection by parameter.
Kameleoon Web Experimentation effectue les redirections en utilisant JavaScript. Si vous préférez effectuer une redirection d’URL avec le code de statut de réponse HTTP 302, utilisez la solution Feature Experimentation de Kameleoon et un SDK.
Lors de la configuration d’une expérience de redirection, Kameleoon gère automatiquement l’auto-redirection pour la variation originale, ce qui est fortement recommandé pour les raisons suivantes :
  • Cohérence de l’expérience utilisateur : rediriger la variation originale garantit que tous les utilisateurs sont traités de la même manière, qu’ils voient le contrôle ou une variante. Sans cette redirection, les utilisateurs de la variation originale peuvent subir de légers délais ou différences dus à la façon dont les variations sont servies, ce qui pourrait introduire un biais dans les résultats du test. Voir la section 9 de cet article pour plus d’informations.
  • Collecte de données précise : dans les tests basés sur la redirection, ne pas rediriger vers la variation originale pourrait provoquer des écarts dans la mesure des interactions. Par exemple, les visiteurs de la page originale peuvent ne pas être soumis aux mêmes systèmes de suivi et de reporting que ceux de la variation redirigée, conduisant à des données incomplètes ou biaisées (voir la section sur le SRM).

​
Redirection globale

La redirection globale est une simple redirection d’URL sans paramètres supplémentaires.
Vous devez saisir une URL complète (et pas seulement un fragment de l’URL). Par exemple, vous pouvez indiquer une redirection globale de : http://www.website/page1 vers : http://www.website/page2 Vous pouvez également choisir d’inclure les paramètres de requête dans la redirection. Par exemple, si vous redirigez les utilisateurs de https://www.example.com/products?category=shoes vers https://www.example2.com/products, le paramètre de requête category=shoes sera transmis à l’URL de redirection (https://www.example2.com/products?category=shoes).

​
Redirection par paramètre

Si vous souhaitez utiliser la même URL mais avec des paramètres supplémentaires, sélectionnez Redirection by parameter. Indiquez les paramètres à ajouter à la fin de l’URL. Cette option peut être utile si vous souhaitez par exemple modifier le tri par défaut des résultats sur une page produit. Répétez cette opération pour chaque variation que vous souhaitez tester, en indiquant, pour chacune, l’URL vers laquelle les visiteurs doivent être redirigés.
Dans le cas d’une expérience A/B split URL, il est important de cibler correctement votre expérience. Vous ne devez pas utiliser l’option de ciblage Presence of an element on the page car cela augmentera considérablement l’effet de flickering. Kameleoon devrait attendre que la page soit chargée pour vérifier la présence ou l’absence de l’élément ciblé puis rediriger les visiteurs vers une variation. Pour ce type d’expérience, utilisez les autres options de ciblage (URL ou condition JavaScript avancée). De même, si du code JavaScript est utilisé pour une redirection complexe, gardez la case Load this JavaScript code after page has finished loading (at DOMReady) décochée. De plus, il n’est pas nécessaire d’indiquer dans le ciblage de votre expérience que les deux pages (A et B) sont pertinentes : la page A suffit.

​
Redirection d’URL sur plusieurs pages

Lorsqu’une expérience A/B split URL s’exécute sur plusieurs pages (par exemple, chaque page d’information produit), vous avez besoin de plus de fonctionnalités que celles disponibles dans le panneau de redirection ci-dessus. Vous devez souvent gérer la redirection avec un code JavaScript personnalisé. Disons par exemple que vous voulez rediriger chaque visiteur accédant aux pages suivantes : http://mywebsite.com/product/sheet/technology,product,id.aspx vers ces pages : http://mywebsite.com/product_AB/sheet/technology,product,id.aspx Les paramètres technology, product et ID changent en fonction de la page d’information produit affichée. Pour exécuter ce test, vous devez écrire du code JavaScript pour vous assurer que chaque cas possible est pris en compte. Voici un exemple : 
var url = window.location.href;
var redirect_url = url.replace("/product/", "/product_AB/");
Kameleoon.API.Core.processRedirect(redirect_url);
Une fois le code JavaScript écrit, vous devez définir la cible avec soin. Si vous souhaitez cibler via une URL, vous devez restreindre le test aux URL contenant le fragment suivant : http://mywebsite.com/product/sheet/
Exécuter une expérience A/B split URL sur plusieurs pages implique que les éléments d’identification ne soient pas gérés comme des paramètres mais directement dans l’URL. Le type de page ne sera pas category.php?product= mais /category/product.html.
N’hésitez pas à consulter notre documentation développeur sur la redirection d’URL

​
Redirection d’URL et politique de consentement

Lorsque Kameleoon effectue une redirection, certaines données (telles que l’ID de la variation exposée) doivent être temporairement stockées dans le navigateur du visiteur pour garantir un suivi correct après la redirection. Cependant, comme le stockage de données n’est pas autorisé avant le consentement, nous recommandons d’exécuter les expériences de redirection uniquement pour les utilisateurs ayant donné leur consentement. Pour mettre cela en œuvre, utilisez la condition de ciblage JavaScript suivante dans la configuration de votre expérience : return Kameleoon.API.Visitor.experimentLegalConsent || false;
Si vous choisissez d’exécuter l’expérience pour les utilisateurs n’ayant pas donné leur consentement, Kameleoon stockera temporairement l’ID de la variation dans le session storage afin de maintenir l’allocation initiale lorsque l’utilisateur recharge la page.
Plus d’informations sur la politique de consentement

​
Redirection d’URL et outils d’analytics tiers

​
Impact sur les intégrations d’analytics personnalisées

Lors de l’utilisation d’une intégration analytics personnalisée dans une expérience de redirection, les données ne sont pas envoyées lorsque le visiteur est initialement ciblé car l’outil analytics peut ne pas avoir assez de temps pour se charger avant que la redirection ne se produise. Pour garantir un suivi précis, Kameleoon stocke les données dans le navigateur avant la redirection, puis envoie les données après la redirection (sur la page de variation), ce qui garantit que les outils analytics reçoivent les informations correctes tout en permettant aux redirections de se dérouler en douceur (sans flickering).

​
Impact sur le suivi du Referrer

Lorsque Kameleoon effectue une redirection, les outils analytics tiers perdent l’accès au referrer d’origine document.referrer. Par exemple, si un visiteur arrive sur votre site via une campagne Facebook payante mais est immédiatement redirigé vers une variation, le referrer enregistré sera la page originale (avant la redirection) — et non la campagne Facebook. Campagne Facebook → page originale (avant la redirection) → page de variation (après la redirection) Dans Google Analytics 4 (GA4), cela signifie que la version originale de la page sera toujours enregistrée comme referrer lorsque les visiteurs sont redirigés vers une variation. Pour récupérer le bon referrer, vous pouvez soit vérifier les données dans Kameleoon, soit utiliser Kameleoon.Gatherer.Referrer.obtain() sur la page de variation et enregistrer la valeur dans une variable personnalisée de votre côté pour vous assurer que le referrer correct (campagne Facebook, par exemple) est capturé.

​
Redirection d’URL et Sample Ratio Mismatch

Même si Kameleoon redirige automatiquement la variation originale, mener des expériences impliquant des redirections d’URL augmente la probabilité de rencontrer un SRM. Le SRM se produit lorsque les visiteurs redirigés vers la variante B ne voient pas la page ou lorsque la collecte de données n’a lieu qu’après le chargement de la page B. Le SRM entraîne une certaine perte de données dans la variante B qui ne serait pas présente sur la page originale. Pour traiter le SRM, suivez les directives décrites ici.
Lors de la configuration de votre expérience avec une allocation de trafic original 0 %, contrôle 50 % et redirection 50 %, assurez-vous de définir le nouveau contrôle comme référence sur la page Results.

​
Comment faire la QA des expériences de redirection d’URL

Pour faire la QA des expériences split URL, ouvrez un onglet de navigation privée dans votre navigateur et suivez ces étapes :
  1. Allez à votre page, en incluant les paramètres UTM : https://www.site.com?utm_param
  2. Ouvrez un nouvel onglet avec la simulation.
  3. Rafraîchissez l’onglet ; vous serez ciblé.
  4. Basculez vers votre variation.
La redirection sera alors effectuée. Kameleoon suit les conversions pour les visiteurs ciblés dès l’exposition initiale et pour toutes les visites de retour ultérieures dans la fenêtre d’attribution. La fenêtre d’attribution détermine la période durant laquelle les conversions et transactions des visiteurs sont attribuées à une variation spécifique. Les conversions des visiteurs ne sont prises en compte dans une expérience que si la visite a été ciblée par l’expérience ou si elle entre dans la fenêtre d’attribution. Pour plus d’informations, vous pouvez consulter cet article.

​
Redirection d’URL et impact SEO

Si vous êtes inquiet de l’impact potentiel des expériences de redirection sur le SEO de votre site web, ou si vous avez remarqué que vos pages web ont été désindexées depuis le démarrage de vos expériences, consultez cet article.