Core/Dash Dimension : labels personnalisés & segmentation

Segmentation personnalisée dans CoreDash

Les dimensions techniques comme le pays et le type d'appareil sont générées à partir des signaux du navigateur. CoreDash les collecte automatiquement. Les trois dimensions présentées ici sont différentes : Page Label, A/B Test et Logged In Status sont définies par l'utilisateur. Vous les configurez en attribuant une variable window dans votre propre code avant l'exécution de CoreDash.

Ce passage de l'automatique à l'intentionnel est tout l'intérêt. Votre application sait des choses que le navigateur ne peut pas deviner : quelle variante de paiement l'utilisateur consulte, si l'URL actuelle est une page produit ou une page d'atterrissage, et si l'utilisateur est authentifié. Transmettre ce contexte à CoreDash permet à vos données de performance de refléter le fonctionnement réel de votre entreprise.

Page Label (lb)

La dimension Page Label vous permet de regrouper les pages par fonction métier plutôt que par structure d'URL. Définissez-la ainsi :

window.__CWVL = 'mypagelabel';

Valeurs typiques : checkout, product-detail, landing-page, category, search-results, account. La valeur est une chaîne de caractères arbitraire que vous contrôlez.

Pourquoi c'est important

L'analyse par URL pose un problème fondamental de passage à l'échelle. Un grand site e-commerce peut compter 50 000 pages produit. Leurs URL ressemblent à /products/blue-widget-32oz et /products/red-gadget-xl. Il s'agit du même template, de la même fonction métier et du même objectif d'optimisation. Les analyser une URL à la fois n'a aucun intérêt. Les regrouper sous product-detail vous fournit un profil de performance unique pour l'ensemble du catalogue produit.

Page Label permet également de séparer les pages qui ont des budgets de performance différents. Une page de paiement a un seuil LCP acceptable strict car elle génère directement du chiffre d'affaires. Un article de blog a une tolérance différente. Une page d'atterrissage qui reçoit du trafic payant n'a aucune tolérance pour un LCP lent : chaque milliseconde vous coûte en dépenses publicitaires.

Une fois vos pages étiquetées par fonction métier, vous pouvez configurer différents seuils d'alerte par label dans CoreDash et acheminer les bonnes alertes vers les bonnes équipes.

A/B Test (ab)

La dimension A/B Test contient le label que vous attribuez à la variante actuelle que l'utilisateur voit. Définissez-la ainsi :

window.__CWAB = 'my page version';

Pourquoi c'est important

Les tests A/B sont l'une des sources les plus courantes de régressions de performance involontaires. La variante B embarque un nouveau carrousel d'images principal. La variante B charge un widget de recommandation tiers. La variante B inclut une étape supplémentaire d'hydratation React. Tout cela a un coût en performance que vos outils d'expérimentation ne mesurent presque certainement pas.

La plupart des plateformes d'expérimentation suivent les taux de conversion et le chiffre d'affaires. Elles ne mesurent pas le p75 du LCP ou de l'INP. Si la variante B convertit 2 % de mieux mais charge 400 ms plus lentement sur mobile, vous devez le savoir avant de la déployer auprès de 100 % du trafic. Ce coût en performance peut annuler le gain de conversion au trimestre suivant, à mesure que les utilisateurs perdent patience.

Une fois __CWAB défini, ouvrez CoreDash, filtrez par ab = variant-b et comparez les Core Web Vitals côte à côte avec le contrôle. J'ai vu des tests A/B où la variante gagnante avait un p75 LCP plus lent de 600 ms par rapport au contrôle, simplement parce qu'elle chargeait une police plus lourde. L'équipe business a vu la hausse des conversions ; elle n'a pas vu la régression des performances. C'est exactement ce que cette dimension empêche.

Logged In Status (li)

La dimension Logged In Status indique si l'utilisateur actuel est authentifié. Définissez-la ainsi :

window.__CWVLI = 1; // connecté
window.__CWVLI = 0; // déconnecté

Pourquoi c'est important

Les utilisateurs connectés reçoivent une page fondamentalement différente de celle des visiteurs anonymes. Leurs requêtes contournent de nombreuses couches de cache CDN. Le serveur exécute des requêtes en base de données pour du contenu personnalisé : le panier, l'historique de commandes, les articles enregistrés. Ce travail côté serveur s'ajoute directement au TTFB.

Côté frontend, les pages authentifiées chargent souvent plus de JavaScript : widgets de compte, systèmes de notification, réactivité du panier d'achat. Elles contournent parfois le pré-rendu ou l'edge caching qui rendent les pages anonymes rapides. Résultat : les utilisateurs connectés subissent souvent des performances plus lentes. Pourtant, ce sont vos clients à plus forte valeur. Ils ont déjà converti. Ce sont eux que vous devez fidéliser en priorité.

Sans la dimension li, les performances lentes des utilisateurs connectés sont masquées par vos données globales. Votre LCP anonyme peut être de 1,8 s tandis que votre LCP connecté atteint 3,4 s. La valeur globale s'affiche à 2,3 s et semble acceptable. Séparez par li et la situation change complètement.

Implémentation

Les trois dimensions utilisent le même principe : définir une variable window avant l'exécution du script CoreDash. Placez-les dans une balise script dans l'en-tête de votre document ou dans le code d'initialisation de votre application :

// Définissez les trois selon l'état de votre application
window.__CWVL  = 'checkout';      // label de page
window.__CWAB  = 'variant-b';     // variante de test A/B
window.__CWVLI = 1;               // connecté

Les valeurs des labels sont des chaînes de caractères (sauf __CWVLI qui prend 1 ou 0). Gardez-les cohérentes dans toute votre base de code. Si vous utilisez product-detail dans un template et productDetail dans un autre, CoreDash les traitera comme deux segments distincts et vos données seront fragmentées. Choisissez une convention et appliquez-la.

Combiner les trois

La véritable valeur apparaît lorsque vous combinez ces dimensions. Imaginons que vous lanciez un test A/B sur votre page de paiement pour les utilisateurs connectés. Vous voulez savoir si la variante B accélère ou ralentit l'expérience de paiement des utilisateurs connectés.

Dans CoreDash, filtrez par ab = variant-b plus lb = checkout plus li = 1. Vous obtenez ainsi les performances de votre variante de paiement spécifiquement pour les utilisateurs connectés. Aucun autre outil de monitoring ne présente cette combinaison sans un travail de développement spécifique de votre côté.

Les dimensions techniques standards indiquent ce que le navigateur a vécu. Les dimensions personnalisées indiquent ce que votre activité a vécu. Une régression de 400 ms du LCP signifie quelque chose de très différent sur une landing-page avec du trafic payant par rapport à un article de blog. Ces distinctions sont essentielles pour la priorisation. Et la priorisation est précisément ce qui fait réussir ou bloquer les projets de performance.