Dimension Core/Dash : Libellés personnalisés et segmentation

Segmentation personnalisée dans CoreDash

Les dimensions techniques telles que le pays et le type d'appareil sont construites à partir des signaux du navigateur. CoreDash les collecte automatiquement. Les trois dimensions abordées ici sont différentes : Libellé de page, Test A/B, et État de connexion sont définis par l'utilisateur. Vous les configurez en assignant une variable window dans votre propre code avant l'exécution de CoreDash.

Ce passage de l'automatique à l'intentionnel est tout l'enjeu. Votre application sait des choses que le navigateur ne peut pas déduire : quelle variante de paiement un utilisateur voit, si l'URL actuelle est une page de détail de produit ou une landing page, si l'utilisateur est authentifié. Transmettre ce contexte à CoreDash signifie que vos données de performance reflètent le fonctionnement réel de votre entreprise.

Libellé de page (lb)

La dimension Libellé de page 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 basée sur l'URL pose un problème fondamental de mise à l'échelle. Un grand site e-commerce peut avoir 50 000 pages de détail de produit. Leurs URL ressemblent à /products/blue-widget-32oz et /products/red-gadget-xl. Il s'agit du même modèle, de la même fonction métier, de la même cible d'optimisation. Les analyser une URL à la fois n'est pas utile. Les regrouper sous product-detail vous donne un profil de performance unique pour l'ensemble du catalogue de produits.

Le libellé de page sépare également les pages qui répondent à différents budgets de performance. Une page de paiement a un seuil LCP acceptable spécifique car elle génère des revenus directs. Un article de blog a une tolérance différente. Une landing page qui reçoit du trafic payant n'a aucune tolérance pour un LCP lent, car chaque milliseconde vous coûte des dépenses publicitaires.

Une fois que vous avez étiqueté les pages par fonction métier, vous pouvez définir différents seuils d'alerte dans CoreDash pour chaque libellé et acheminer les bonnes alertes aux bonnes équipes.

Test A/B (ab)

La dimension Test A/B contient un libellé que vous attribuez à la variante actuelle qu'un utilisateur est en train d'expérimenter. Définissez-la ainsi :

window.__CWAB = 'my page version';

La valeur est arbitraire. variant-a et variant-b sont des choix évidents, mais vous pouvez utiliser n'importe quelle chaîne qui correspond aux identifiants de variante de votre plateforme d'expérimentation.

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 déploie un nouveau carrousel d'images hero. La variante B charge un widget de recommandation tiers. La variante B inclut un cycle supplémentaire d'hydratation React. Tout cela a un coût en termes de performances que vos outils d'expérimentation ne mesurent presque certainement pas.

La plupart des plateformes d'expérimentation suivent les taux de conversion et les revenus. Elles ne suivent pas le LCP au p75 ni 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 sur 100 % du trafic. Le coût en performances pourrait effacer le gain de conversion au cours du trimestre suivant, à mesure que les utilisateurs perdent patience.

Avec __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 LCP au p75 pire de 600 ms par rapport au contrôle parce qu'elle chargeait une police plus lourde. L'équipe métier a vu l'augmentation de la conversion ; elle n'a pas vu la régression de performance. C'est ce que cette dimension permet d'éviter.

État de connexion (li)

La dimension État de connexion enregistre 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 des visiteurs anonymes. Leurs requêtes contournent de nombreuses couches de cache CDN. Le serveur exécute des requêtes de base de données pour du contenu personnalisé : le panier de l'utilisateur, son historique de commandes, ses articles sauvegardés. Ce travail côté serveur s'ajoute directement au TTFB.

Sur le frontend, les pages authentifiées chargent souvent plus de JavaScript : widgets de compte, systèmes de notification, réactivité du panier d'achat. Elles peuvent également ignorer le prérendu ou le cache à la périphérie qui rendent les pages anonymes rapides. Le résultat est que les utilisateurs connectés constatent souvent des performances plus lentes que les utilisateurs anonymes, alors que les utilisateurs connectés sont généralement vos clients à plus forte valeur. Ils ont déjà converti. Ce sont ceux que vous devez le plus fidéliser.

Sans la dimension li, la lenteur des performances authentifiées se cache dans vos chiffres globaux. Votre LCP anonyme peut être de 1,8 s tandis que votre LCP connecté est de 3,4 s. La moyenne globale s'affiche à 2,3 s et semble acceptable. Séparez par li et le tableau change complètement.

Implémentation

Les trois dimensions utilisent le même modèle : définissez une variable window avant l'exécution du snippet CoreDash. Placez-les dans une balise script dans le head de votre document ou dans le code d'initialisation de votre application :

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

Les valeurs des libellés sont des chaînes de caractères (sauf __CWVLI qui prend 1 ou 0). Gardez-les cohérentes sur l'ensemble de votre base de code. Si vous utilisez product-detail dans un modèle et productDetail dans un autre, CoreDash les traite comme deux segments distincts et vos données se fragmentent. Choisissez une convention et respectez-la.

Combiner les trois

La véritable valeur apparaît lorsque vous cumulez ces dimensions. Vous exécutez un test A/B sur votre page de paiement pour les utilisateurs connectés. Vous voulez savoir si la variante B rend l'expérience de paiement authentifiée plus rapide ou plus lente.

Dans CoreDash, filtrez par ab = variant-b plus lb = checkout plus li = 1. Cela vous donne spécifiquement les performances de votre variante de paiement pour les utilisateurs authentifiés. Aucun autre outil de surveillance ne fait remonter cette combinaison sans un travail d'ingénierie personnalisé de votre part.

Les dimensions techniques standards vous indiquent ce que le navigateur a expérimenté. Les dimensions personnalisées vous indiquent ce que l'entreprise a expérimenté. Une régression du LCP de 400 ms signifie quelque chose de très différent sur une landing-page générant du trafic payant par rapport à un article de blog. Ces distinctions comptent pour la priorisation, et c'est dans la priorisation que le travail sur les performances réussit ou stagne.