Core/Dash Dimension: Brugerdefinerede labels & segmentering

Brugerdefineret segmentering i CoreDash

Tekniske dimensioner som land og enhedstype bygges på baggrund af browsersignaler. CoreDash indsamler dem automatisk. De tre dimensioner, der dækkes her, er anderledes: Sidelabel, A/B-test og Loginstatus er brugerdefinerede. Du indstiller dem ved at tildele en window-variabel i din egen kode, før CoreDash kører.

Det skift fra automatisk til bevidst er hele pointen. Din applikation ved ting, som browseren ikke kan udlede: hvilken checkout-variant en bruger ser, om den aktuelle URL er en produktdetaljeside eller en landingsside, og om brugeren er logget ind. Ved at sende den kontekst til CoreDash afspejler dine performancedata, hvordan din forretning rent faktisk fungerer.

Sidelabel (lb)

Dimensionen Sidelabel giver dig mulighed for at gruppere sider efter forretningsfunktion i stedet for URL-struktur. Definer den sådan her:

window.__CWVL = 'mypagelabel';

Typiske værdier: checkout, product-detail, landing-page, category, search-results, account. Værdien er en vilkårlig streng, du kontrollerer.

Hvorfor det er vigtigt

URL-baseret analyse har et fundamentalt skaleringsproblem. Et stort e-handelswebsite kan have 50.000 produktdetaljesider. Deres URL'er ser ud som /products/blue-widget-32oz og /products/red-gadget-xl. De er den samme skabelon, den samme forretningsfunktion, det samme optimeringsmål. At analysere dem én URL ad gangen er ikke brugbart. Ved at gruppere dem under product-detail får du en enkelt performanceprofil for hele produktkataloget.

Sidelabel adskiller også sider, der opererer med forskellige performancebudgetter. En checkout-side har én acceptabel LCP-grænseværdi, fordi den genererer direkte omsætning. Et blogindlæg har en anden tolerance. En landingsside, der modtager betalt trafik, har nultolerance over for langsom LCP, fordi hvert millisekund koster dig annoncekroner.

Når du først labeler sider efter forretningsfunktion, kan du angive forskellige alarmgrænser i CoreDash per label og dirigere de rigtige alarmer til de rigtige teams.

A/B-test (ab)

Dimensionen A/B-test indeholder et label, du tildeler den aktuelle variant, en bruger oplever. Definer den sådan her:

window.__CWAB = 'my page version';

Værdien er vilkårlig. variant-a og variant-b er oplagte valg, men du kan bruge enhver streng, der matcher din eksperimentplatformens variantidentifikatorer.

Hvorfor det er vigtigt

A/B-tests er en af de mest almindelige kilder til utilsigtede forringelser af performance. Variant B udruller en ny hero image-karrusel. Variant B indlæser en tredjepartsanbefalingswidget. Variant B inkluderer en ekstra runde React-hydrering. Alle disse medfører en performanceomkostning, som dit eksperimentværktøj med stor sandsynlighed ikke måler.

De fleste eksperimentplatforme sporer konverteringsrater og omsætning. De sporer ikke p75 LCP eller INP. Hvis variant B konverterer 2 % bedre, men indlæser 400 ms langsommere på mobil, er du nødt til at vide det, før du ruller den ud til 100 % af trafikken. Performanceomkostningen kan ende med at udviske konverteringsgevinsten i løbet af det næste kvartal, når brugerne mister tålmodigheden.

Med __CWAB angivet kan du åbne CoreDash, filtrere efter ab = variant-b, og sammenligne Core Web Vitals side om side med kontrolgruppen. Jeg har set A/B-tests, hvor vinder-varianten havde en 600 ms dårligere p75 LCP end kontrolgruppen, fordi den indlæste en tungere skrifttype. Forretningsteamet så det øgede antal konverteringer; de så ikke tilbagegangen i performance. Det er dét, denne dimension forhindrer.

Loginstatus (li)

Dimensionen Loginstatus registrerer, om den aktuelle bruger er autentificeret. Definer den sådan her:

window.__CWVLI = 1; // logget ind
window.__CWVLI = 0; // logget ud

Hvorfor det er vigtigt

Brugere, der er logget ind, modtager en fundamentalt anderledes side end anonyme besøgende. Deres anmodninger omgår mange CDN-cachelag. Serveren kører databaseforespørgsler efter personligt indhold: brugerens indkøbskurv, deres ordrehistorik, deres gemte varer. Det serverarbejde lægges direkte oven i TTFB.

På frontend'en indlæser autentificerede sider ofte mere JavaScript: kontowidgets, notifikationssystemer, interaktive indkøbskurve. De springer muligvis også prerendering eller edge-caching over, hvilket normalt gør anonyme sider hurtige. Resultatet er, at brugere, der er logget ind, ofte oplever langsommere performance end anonyme brugere – og dog er det typisk dine mest værdifulde kunder. De har allerede konverteret. Det er dem, du har allermest brug for at fastholde.

Uden dimensionen li skjuler langsom autentificeret performance sig inde i dine samlede tal. Din anonyme LCP kan være 1,8s, mens din indloggede LCP er 3,4s. Det samlede tal står som 2,3s og ser acceptabelt ud. Del det op med li, og billedet ændrer sig fuldstændigt.

Implementering

Alle tre dimensioner bruger det samme mønster: Angiv en window-variabel før CoreDash-snippeten eksekveres. Placer dem i et script-tag i dit dokuments head eller i din applikations initialiseringskode:

// Angiv alle tre baseret på din applikationstilstand
window.__CWVL  = 'checkout';      // sidelabel
window.__CWAB  = 'variant-b';     // A/B-testvariant
window.__CWVLI = 1;               // logget ind

Labelværdierne er strenge (undtagen __CWVLI, som tager 1 eller 0). Hold dem konsistente på tværs af din kodebase. Hvis du bruger product-detail i én skabelon og productDetail i en anden, behandler CoreDash dem som to separate segmenter, og dine data fragmenteres. Vælg en konvention, og håndhæv den.

Kombination af alle tre

Den virkelige værdi opstår, når du kombinerer disse dimensioner. Forestil dig, at du kører en A/B-test på din checkout-side for brugere, der er logget ind. Du vil gerne vide, om variant B gør den autentificerede checkout-oplevelse hurtigere eller langsommere.

I CoreDash filtrerer du efter ab = variant-b plus lb = checkout plus li = 1. Det giver dig specifikt din checkout-variants performance for autentificerede brugere. Intet andet overvågningsværktøj fremhæver den kombination uden skræddersyet udviklingsarbejde fra din side.

Standard tekniske dimensioner fortæller dig, hvad browseren oplevede. Brugerdefinerede dimensioner fortæller dig, hvad forretningen oplevede. En LCP-forringelse på 400 ms betyder noget helt andet på en landing-page, der kører betalt trafik, i forhold til et blog-indlæg. Disse forskelle har betydning for prioritering, og prioritering er dér, hvor performancearbejde enten lykkes eller går i stå.