Core/Dash-dimensjon: Egendefinerte etiketter og segmentering

Egendefinert segmentering i CoreDash

Tekniske dimensjoner som land og enhetstype bygges fra nettlesersignaler. CoreDash samler dem inn automatisk. De tre dimensjonene som dekkes her er annerledes: Page Label, A/B Test og Logged In Status er brukerdefinerte. Du angir dem ved å tildele en window-variabel i din egen kode før CoreDash kjører.

Dette skiftet fra automatisk til tilsiktet er hele poenget. Applikasjonen din vet ting nettleseren ikke kan utlede: hvilken betalingsvariant en bruker ser, om den gjeldende URL-en er en produktdetaljside eller en landingsside, om brukeren er autentisert. Ved å sende denne konteksten til CoreDash betyr det at dine ytelsesdata gjenspeiler hvordan virksomheten din faktisk fungerer.

Page Label (lb)

Dimensjonen Page Label lar deg gruppere sider etter forretningsfunksjon i stedet for URL-struktur. Definer den slik:

window.__CWVL = 'mypagelabel';

Typiske verdier: checkout, product-detail, landing-page, category, search-results, account. Verdien er en vilkårlig streng du kontrollerer.

Hvorfor dette betyr noe

URL-basert analyse har et fundamentalt skaleringsproblem. Et stort e-handelsnettsted kan ha 50 000 produktdetaljsider. URL-ene deres ser ut som /products/blue-widget-32oz og /products/red-gadget-xl. Dette er samme mal, samme forretningsfunksjon, samme optimaliseringsmål. Å analysere dem én URL om gangen er ikke nyttig. Ved å gruppere dem under product-detail får du én enkelt ytelsesprofil for hele produktkatalogen.

Page Label skiller også sider som har ulike ytelsesbudsjetter. En betalingsside har én akseptabel LCP-terskel fordi den fører til direkte inntekter. Et blogginnlegg har en annen toleranse. En landingsside som kjører betalt trafikk har nulltoleranse for treg LCP fordi hvert millisekund koster deg annonsekostnader.

Når du har merket sider etter forretningsfunksjon, kan du angi ulike varslingsterskler i CoreDash per etikett og rute de riktige varslene til de riktige teamene.

A/B Test (ab)

Dimensjonen A/B Test inneholder en etikett du tildeler den gjeldende varianten en bruker opplever. Definer den slik:

window.__CWAB = 'my page version';

Verdien er vilkårlig. variant-a og variant-b er åpenbare valg, men du kan bruke hvilken som helst streng som samsvarer med din eksperimenteringsplattforms variantidentifikatorer.

Hvorfor dette betyr noe

A/B-tester er en av de vanligste kildene til utilsiktede ytelsesregresjoner. Variant B sender en ny hero-bildekarusell. Variant B laster en tredjeparts anbefalingswidget. Variant B inkluderer en ekstra runde med React-hydrering. Alle disse medfører en ytelseskostnad som eksperimentverktøyet ditt nesten helt sikkert ikke måler.

De fleste eksperimenteringsplattformer sporer konverteringsfrekvenser og inntekter. De sporer ikke p75 LCP eller INP. Hvis variant B konverterer 2 % bedre, men laster 400 ms tregere på mobil, må du vite det før du ruller den ut til 100 % av trafikken. Ytelseskostnaden kan utradere konverteringsgevinsten i neste kvartal etter hvert som brukerne mister tålmodigheten.

Med __CWAB angitt, åpne CoreDash, filtrer etter ab = variant-b, og sammenlign Core Web Vitals side om side med kontrollgruppen. Jeg har sett A/B-tester der den vinnende varianten hadde en 600 ms dårligere p75 LCP enn kontrollgruppen fordi den lastet en tyngre font. Forretningsteamet så konverteringsløftet; de så ikke ytelsesregresjonen. Det er dette denne dimensjonen forhindrer.

Logged In Status (li)

Dimensjonen Logged In Status registrerer om den nåværende brukeren er autentisert. Definer den slik:

window.__CWVLI = 1; // pålogget
window.__CWVLI = 0; // utlogget

Hvorfor dette betyr noe

Påloggede brukere mottar en fundamentalt annerledes side enn anonyme besøkende. Forespørslene deres omgår mange CDN-cachelag. Serveren kjører databaseforespørsler for personlig tilpasset innhold: brukerens handlekurv, deres ordrehistorikk, deres lagrede varer. Det serverarbeidet legger direkte til TTFB.

På frontend laster autentiserte sider ofte mer JavaScript: kontowidgeter, varslingssystemer, reaktivitet i handlekurven. De kan også hoppe over forhåndsrendring eller edge-caching som gjør anonyme sider raske. Resultatet er at påloggede brukere ofte opplever tregere ytelse enn anonyme brukere, men påloggede brukere er vanligvis dine mest verdifulle kunder. De har allerede konvertert. De er de du mest trenger å beholde.

Uten li-dimensjonen skjuler treg autentisert ytelse seg i dine aggregerte tall. Din anonyme LCP kan være 1,8 s, mens din påloggede LCP er 3,4 s. Aggregatet leses som 2,3 s og ser akseptabelt ut. Delt opp etter li endrer bildet seg fullstendig.

Implementering

Alle tre dimensjonene bruker samme mønster: angi en window-variabel før CoreDash-snutten kjøres. Plasser dem i en script-tag i dokumentets head eller i applikasjonens initialiseringskode:

// Angi alle tre basert på app-status
window.__CWVL  = 'checkout';      // sideetikett
window.__CWAB  = 'variant-b';     // A/B-testvariant
window.__CWVLI = 1;               // pålogget

Etikettverdiene er strenger (unntatt __CWVLI som tar 1 eller 0). Hold dem konsistente på tvers av kodebasen. Hvis du bruker product-detail i én mal og productDetail i en annen, behandler CoreDash dem som to separate segmenter og dataene dine fragmenteres. Velg en konvensjon og håndhev den.

Kombinere alle tre

Den virkelige verdien vises når du stabler disse dimensjonene sammen. Du kjører en A/B-test på betalingssiden din for påloggede brukere. Du vil vite om variant B gjør den autentiserte betalingsopplevelsen raskere eller tregere.

I CoreDash, filtrer etter ab = variant-b pluss lb = checkout pluss li = 1. Det gir deg ytelsen til din betalingsvariant spesifikt for autentiserte brukere. Ingen andre overvåkingsverktøy viser den kombinasjonen uten tilpasset ingeniørarbeid på din side.

Standard tekniske dimensjoner forteller deg hva nettleseren opplevde. Egendefinerte dimensjoner forteller deg hva virksomheten opplevde. En LCP-regresjon på 400 ms betyr noe helt annet på en landing-page som kjører betalt trafikk enn på et blog-innlegg. Disse skillene betyr noe for prioritering, og prioritering er der ytelsesarbeid enten lykkes eller stopper opp.