Core/Dash Dimension: Brugerdefinerede labels & segmentering

Brugerdefineret segmentering i CoreDash

Tekniske dimensioner som land og enhedstype bygger på browsersignaler. CoreDash indsamler dem automatisk. De tre dimensioner, der dækkes her, er anderledes: Page Label, A/B Test og Logged In Status er brugerdefinerede. Du angiver dem ved at tildele en window-variabel i din egen kode, før CoreDash kører.

Dette skift fra automatisk til bevidst er hele humlen. Din applikation ved ting, som browseren ikke kan udlede: hvilken checkout-variant en bruger ser, om den aktuelle URL er en produktside eller en landing page, og om brugeren er logget ind. Ved at videregive denne kontekst til CoreDash sikrer du, at dine performancedata afspejler, hvordan din forretning rent faktisk fungerer.

Page Label (lb)

Dimensionen Page Label lader dig gruppere sider efter forretningsfunktion frem for URL-struktur. Definer den således:

window.__CWVL = 'mypagelabel';

Typiske værdier: checkout, product-detail, landing-page, category, search-results, account. Værdien er en valgfri streng, som du selv styrer.

Hvorfor det er vigtigt

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

Page Label adskiller også sider, der opererer med forskellige performancebudgetter. En checkout-side har én acceptabel LCP-grænse, fordi den driver direkte omsætning. Et blogindlæg har en anden tolerance. En landing page med betalt trafik har nultolerance over for langsom LCP, fordi hvert millisekund koster dig annoncekroner.

Når du mærker sider efter forretningsfunktion, kan du opsætte forskellige alarmgrænser i CoreDash per label og sende de rigtige alarmer til de rigtige teams.

A/B Test (ab)

Dimensionen A/B Test indeholder en label, du tildeler den aktuelle variant, som brugeren oplever. Definer den således:

window.__CWAB = 'my page version';

Værdien er valgfri. variant-a og variant-b er oplagte valg, men du kan bruge en hvilken som helst streng, der matcher identifikatorerne i din eksperimentplatform.

Hvorfor det er vigtigt

A/B-tests er en af de mest almindelige årsager til utilsigtede forringelser af performance. Variant B introducerer en ny hero image-karrusel. Variant B indlæser en tredjepartsanbefalings-widget. Variant B inkluderer en ekstra runde React-hydration. Alt dette medfører en performanceomkostning, som dit eksperimentværktøj højst sandsynligt 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æses 400 ms langsommere på mobil, har du brug for at vide det, før du ruller den ud til 100 % af trafikken. Performanceomkostningen kan udradere konverteringsgevinsten i løbet af det næste kvartal, efterhånden som brugerne mister tålmodigheden.

Når __CWAB er sat, 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å konverteringsløftet; de så ikke tilbagegangen i performance. Det er dét, denne dimension forhindrer.

Logged In Status (li)

Dimensionen Logged In Status registrerer, om den aktuelle bruger er autentificeret. Definer den således:

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 for personaliseret indhold: brugerens indkøbskurv, deres ordrehistorik, deres gemte varer. Dette arbejde på serversiden lægges direkte oven i TTFB.

På frontend-siden indlæser autentificerede sider ofte mere JavaScript: konto-widgets, notifikationssystemer, reaktivitet i indkøbskurven. De springer muligvis også den prerendering eller edge-caching over, som gør anonyme sider hurtige. Resultatet er, at brugere, der er logget ind, ofte oplever langsommere performance end anonyme brugere, selvom det typisk er dine mest værdifulde kunder. De har allerede konverteret. Det er dem, du har allermest brug for at fastholde.

Uden dimensionen li skjuler den langsomme autentificerede performance sig i dine aggregerede tal. Din anonyme LCP er måske 1,8 s, mens din LCP for loggede brugere er 3,4 s. Gennemsnittet lyder på 2,3 s og ser acceptabelt ud. Opdel efter li, og billedet ændrer sig fuldstændigt.

Implementering

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

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

Label-værdierne er strenge (med undtagelse af __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 reelle værdi viser sig, når du kombinerer disse dimensioner. 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 performancen for din checkout-variant hos autentificerede brugere. Intet andet overvågningsværktøj fremhæver den kombination uden skræddersyet ingeniørarbejde 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 med betalt trafik sammenlignet med et blog-indlæg. Disse forskelle har betydning for prioritering, og prioritering er dét, der afgør, om performancearbejdet lykkes eller går i stå.