Core/Dash Dimension: Anpassade etiketter & Segmentering

Anpassad segmentering i CoreDash

Tekniska dimensioner som land och enhetstyp byggs från webbläsarsignaler. CoreDash samlar in dem automatiskt. De tre dimensionerna som behandlas här är annorlunda: Page Label, A/B Test och Logged In Status är användardefinierade. Du ställer in dem genom att tilldela en window-variabel i din egen kod innan CoreDash körs.

Det skiftet från automatiskt till avsiktligt är hela poängen. Din applikation vet saker som webbläsaren inte kan härleda: vilken checkout-variant en användare ser, om den aktuella URL:en är en produktdetaljsida eller en landningssida, om användaren är autentiserad. Att skicka den kontexten till CoreDash innebär att dina prestandadata speglar hur ditt företag faktiskt fungerar.

Page Label (lb)

Page Label-dimensionen låter dig gruppera sidor efter affärsfunktion snarare än URL-struktur. Definiera den så här:

window.__CWVL = 'mypagelabel';

Typiska värden: checkout, product-detail, landing-page, category, search-results, account. Värdet är en godtycklig sträng som du kontrollerar.

Varför detta är viktigt

URL-baserad analys har ett grundläggande skalningsproblem. En stor e-handelssajt kan ha 50 000 produktdetaljsidor. Deras URL:er ser ut som /products/blue-widget-32oz och /products/red-gadget-xl. Dessa är samma mall, samma affärsfunktion, samma optimeringsmål. Att analysera dem en URL i taget är inte användbart. Att gruppera dem under product-detail ger dig en enda prestandaprofil för hela produktkatalogen.

Page Label separerar också sidor som har olika prestandabudgetar. En checkout-sida har en acceptabel LCP-tröskel eftersom den bär direkt intäkt. Ett blogginlägg har en annan tolerans. En landningssida med betald trafik har noll tolerans för långsam LCP eftersom varje millisekund kostar dig annonspengar.

När du väl etiketterar sidor efter affärsfunktion kan du ställa in olika larmtrösklar i CoreDash per etikett och dirigera rätt larm till rätt team.

A/B Test (ab)

A/B Test-dimensionen innehåller en etikett som du tilldelar till den aktuella varianten som en användare upplever. Definiera den så här:

window.__CWAB = 'my page version';

Värdet är godtyckligt. variant-a och variant-b är uppenbara val, men du kan använda vilken sträng som helst som mappar till din experimentplattforms variantidentifierare.

Varför detta är viktigt

A/B-tester är en av de vanligaste källorna till oavsiktliga prestandaregressioner. Variant B levererar ett nytt hero image-karusell. Variant B laddar en tredjeparts rekommendationswidget. Variant B inkluderar en extra omgång React-hydrering. Alla dessa medför en prestandakostnad som ditt experimentverktyg nästan säkert inte mäter.

De flesta experimentplattformar spårar konverteringsgrader och intäkter. De spårar inte p75 LCP eller INP. Om variant B konverterar 2% bättre men laddar 400ms långsammare på mobil, behöver du veta det innan du rullar ut det till 100% av trafiken. Prestandakostnaden kan radera konverteringsvinsten under nästa kvartal när användare tappar tålamodet.

Med __CWAB satt, öppna CoreDash, filtrera efter ab = variant-b, och jämför Core Web Vitals sida vid sida med kontrollen. Jag har sett A/B-tester där den vinnande varianten hade 600ms sämre p75 LCP än kontrollen eftersom den laddade ett tyngre typsnitt. Affärsteamet såg konverteringslyftet; de såg inte prestandaregressionen. Det är vad denna dimension förhindrar.

Logged In Status (li)

Logged In Status-dimensionen registrerar om den aktuella användaren är autentiserad. Definiera den så här:

window.__CWVLI = 1; // logged in
window.__CWVLI = 0; // logged out

Varför detta är viktigt

Inloggade användare får en fundamentalt annorlunda sida än anonyma besökare. Deras förfrågningar kringgår många CDN-cachelager. Servern kör databasfrågor för personaliserat innehåll: användarens varukorg, deras orderhistorik, deras sparade artiklar. Det serverarbetet läggs direkt till TTFB.

På frontend laddar autentiserade sidor ofta mer JavaScript: kontowidgetar, notifikationssystem, varukorgsreaktivitet. De kan också hoppa över förrenderingen eller edge-cachningen som gör anonyma sidor snabba. Resultatet är att inloggade användare ofta ser långsammare prestanda än anonyma användare, men inloggade användare är vanligtvis dina mest värdefulla kunder. De har redan konverterat. De är de du mest behöver behålla.

Utan li-dimensionen döljs långsam autentiserad prestanda i dina aggregerade siffror. Din anonyma LCP kan vara 1,8s medan din inloggade LCP är 3,4s. Aggregatet visar 2,3s och ser acceptabelt ut. Dela upp efter li och bilden förändras helt.

Implementation

Alla tre dimensioner använder samma mönster: sätt en window-variabel innan CoreDash-snippeten körs. Placera dem i en script-tagg i ditt dokumenthuvud eller i din applikations initieringskod:

// Set all three based on your app state
window.__CWVL  = 'checkout';      // page label
window.__CWAB  = 'variant-b';     // A/B test variant
window.__CWVLI = 1;               // logged in

Etikettvärdena är strängar (förutom __CWVLI som tar 1 eller 0). Håll dem konsekventa genom hela din kodbas. Om du använder product-detail i en mall och productDetail i en annan, behandlar CoreDash dem som två separata segment och dina data fragmenteras. Välj en konvention och tillämpa den.

Kombinera alla tre

Det verkliga värdet uppstår när du staplar dessa dimensioner tillsammans. Du kör ett A/B-test på din checkout-sida för inloggade användare. Du vill veta om variant B gör den autentiserade checkout-upplevelsen snabbare eller långsammare.

I CoreDash, filtrera efter ab = variant-b plus lb = checkout plus li = 1. Det ger dig prestandan för din checkout-variant specifikt för autentiserade användare. Inget annat övervakningsverktyg visar den kombinationen utan anpassat ingenjörsarbete på din sida.

Standardtekniska dimensioner berättar vad webbläsaren upplevde. Anpassade dimensioner berättar vad verksamheten upplevde. En 400ms LCP-regression betyder något helt annat på en landing-page med betald trafik jämfört med ett blog-inlägg. Dessa distinktioner spelar roll för prioritering, och prioritering är där prestandaarbete antingen lyckas eller stannar av.