Core/Dash-dimensjon: Egendefinerte etiketter & segmentering

Egendefinert segmentering i CoreDash

Tekniske dimensjoner som land og enhetstype baserer seg på nettlesersignaler. CoreDash samler dem inn automatisk. De tre dimensjonene vi dekker her er annerledes: Page Label, A/B Test og Logged In Status er brukerdefinerte. Du setter dem ved å tilordne en window-variabel i din egen kode før CoreDash kjører.

Dette skiftet fra automatisk til bevisst er hele poenget. Applikasjonen din vet ting nettleseren ikke kan utlede: hvilken checkout-variant en bruker ser, om den gjeldende URL-en er en produktdetaljside eller en landingsside, om brukeren er autentisert. Ved å sende denne konteksten til CoreDash sørger du for at ytelsesdataene dine reflekterer 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 er viktig

URL-basert analyse har et fundamentalt skaleringsproblem. En stor nettbutikk kan ha 50 000 produktdetaljsider. URL-ene deres ser ut som /products/blue-widget-32oz og /products/red-gadget-xl. Dette er den samme malen, den samme forretningsfunksjonen og det samme optimaliseringsmålet. Å 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 med ulike ytelsesbudsjetter. En checkout-side har én akseptabel LCP-terskel fordi den genererer direkte omsetning. Et blogginnlegg har en helt annen toleranse. En landingsside som kjører betalt trafikk har nulltoleranse for treg LCP, fordi hvert millisekund koster deg annonsekroner.

Når du merker sider etter forretningsfunksjon, kan du sette ulike varslingsgrenser per etikett i CoreDash og rute de riktige varslene til de riktige teamene.

A/B Test (ab)

Dimensjonen A/B Test inneholder en etikett du tildeler varianten brukeren opplever for øyeblikket. Definer den slik:

window.__CWAB = 'my page version';

Verdien er vilkårlig. variant-a og variant-b are opplagte valg, men du kan bruke hvilken som helst streng som kan mappes til variant-ID-ene i eksperimenteringsplattformen din.

Hvorfor dette er viktig

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

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

Med __CWAB satt kan du åpne CoreDash, filtrere på ab = variant-b og sammenligne Core Web Vitals side om side med kontrollgruppen. Jeg har sett A/B-tester der den vinnende varianten hadde 600 ms dårligere p75 LCP enn kontrollgruppen fordi den lastet inn en tyngre skrifttype. Forretningsteamet så konverteringsløftet, men de så ikke ytelsesregresjonen. Det er nettopp dette denne dimensjonen forhindrer.

Logged In Status (li)

Dimensjonen Logged In Status registrerer om den gjeldende brukeren er autentisert. Definer den slik:

window.__CWVLI = 1; // logget inn
window.__CWVLI = 0; // logget ut

Hvorfor dette er viktig

Innloggede brukere får en fundamentalt annerledes side enn anonyme besøkende. Forespørslene deres går utenom mange CDN-hurtiglagre. Serveren kjører databaseforespørsler for personlig tilpasset innhold: brukerens handlekurv, ordrehistorikk og lagrede varer. Dette arbeidet på serversiden legger seg direkte på TTFB-en.

På frontend laster ofte autentiserte sider mer JavaScript: kontowidgeter, varslingssystemer og handlekurvreaktivitet. De kan også hoppe over forhåndsrendring eller edge-hurtiglagring som gjør anonyme sider raske. Resultatet er at innloggede brukere ofte opplever dårligere ytelse enn anonyme brukere – til tross for at de innloggede brukerne vanligvis er dine mest verdifulle kunder. De har allerede konvertert. Det er nettopp disse du har størst behov for å beholde.

Uten li-dimensjonen skjuler den trege ytelsen for autentiserte brukere seg i de aggregerte tallene. LCP-en for anonyme brukere kan være 1,8 s, mens den for innloggede brukere er 3,4 s. Det aggregerte tallet viser 2,3 s og ser akseptabelt ut. Splitter du etter li, endrer bildet seg fullstendig.

Implementering

Alle de tre dimensjonene bruker samme mønster: Sett en window-variabel før CoreDash-skriptet kjører. Plasser dem i en script-tag i dokumenthodet eller i applikasjonens oppstartskode:

// Sett alle tre basert på apptilstand
window.__CWVL  = 'checkout';      // page label
window.__CWAB  = 'variant-b';     // A/B-testvariant
window.__CWVLI = 1;               // logget inn

Etikettverdiene er strenger (bortsett fra __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, vil CoreDash behandle dem som to separate segmenter, og dataene dine fragmenteres. Velg en konvensjon og håndhev den.

Kombinere alle tre

Den virkelige verdien oppstår når du stabler disse dimensjonene. Du kjører en A/B-test på checkout-siden din for innloggede brukere. Du vil vite om variant B gjør den autentiserte checkout-opplevelsen raskere eller tregere.

I CoreDash kan du filtrere på ab = variant-b pluss lb = checkout pluss li = 1. Det gir deg ytelsen til checkout-varianten din spesifikt for autentiserte brukere. Intet annet overvåkingsverktøy viser denne kombinasjonen uten at du må gjøre tilpasset utviklingsarbeid selv.

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 med betalt trafikk enn på et blog-innlegg. Disse forskjellene er avgjørende for prioritering, og prioritering er der ytelsesarbeid enten lykkes eller stopper opp.