Core/Dash Dimension: Egna etiketter & segmentering

Egen segmentering i CoreDash

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

Skiftet från automatiskt till avsiktligt är hela poängen. Din applikation vet saker som webbläsaren inte kan räkna ut: vilken checkout-variant en användare ser, om den aktuella URL:en är en produktsida eller en landningssida, och om användaren är inloggad. Genom att skicka den kontexten till CoreDash speglar din prestandadata hur din verksamhet faktiskt fungerar.

Page Label (lb)

Dimensionen Page Label låter dig gruppera sidor efter affärsfunktion istället för URL-struktur. Du definierar den så här:

window.__CWVL = 'mypagelabel';

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

Varför det här spelar roll

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

Page Label separerar också sidor med olika prestandabudgetar. En checkout-sida har ett specifikt acceptabelt LCP-gränsvärde eftersom den genererar direkta intäkter. Ett blogginlägg har en helt annan tolerans. En landningssida med betald trafik har noll tolerans för långsam LCP eftersom varje millisekund kostar dig annonspengar.

När du har märkt upp sidorna efter affärsfunktion kan du ställa in olika larmgränser per etikett i CoreDash och skicka rätt larm till rätt team.

A/B Test (ab)

Dimensionen A/B Test innehåller etiketten för den variant som användaren upplever just nu. Du definierar den så här:

window.__CWAB = 'my page version';

Värdet är valfritt. variant-a och variant-b är uppenbara val, men du kan använda vilken sträng som helst som mappar mot variantidentifierarna i din experimentplattform.

Varför det här spelar roll

A/B-tester är en av de vanligaste orsakerna till oavsiktliga prestandaförsämringar. Variant B lanserar en ny karusell för herobilder. Variant B laddar en extern rekommendationswidget. Variant B kräver en extra omgång React-hydrering. Allt detta medför en prestandakostnad som ditt experimentverktyg nästan säkert inte mäter.

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

När __CWAB är inställt öppnar du CoreDash, filtrerar på 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 600 ms sämre p75 LCP än kontrollen eftersom den laddade ett tyngre typsnitt. Affärsteamet såg konverteringslyftet; de såg inte prestandaförsämringen. Det är precis vad den här dimensionen förhindrar.

Logged In Status (li)

Dimensionen Logged In Status registrerar om den aktuella användaren är inloggad. Du definierar den så här:

window.__CWVLI = 1; // inloggad
window.__CWVLI = 0; // utloggad

Varför det här spelar roll

Inloggade användare får en helt annan sida än anonyma besökare. Deras anrop går förbi många CDN-cachelager. Servern kör databasfrågor för personligt anpassat innehåll: användarens varukorg, orderhistorik och sparade artiklar. Det arbetet på serversidan ökar din TTFB direkt.

I frontend laddar inloggade sidor ofta mer JavaScript: kontowidgetar, notifieringssystem och reaktivitet i varukorgen. De kan också hoppa över prerendering eller edge caching som gör anonyma sidor snabba. Resultatet blir att inloggade användare ofta upplever sämre prestanda än anonyma användare – trots att de inloggade vanligtvis är dina mest värdefulla kunder. De har redan konverterat. Det är dem du bäst behöver behålla.

Utan dimensionen li göms den långsamma prestandan för inloggade användare i dina aggregerade siffror. Din anonyma LCP kanske ligger på 1,8 s medan din inloggade LCP är 3,4 s. Det aggregerade värdet visar 2,3 s och ser acceptabelt ut. Dela upp det efter li så ändras bilden helt.

Implementation

Alla tre dimensioner använder samma mönster: sätt en window-variabel innan CoreDash-kodsnutten körs. Lägg dem i en script-tagg i ditt dokuments head eller i din applikations initieringskod:

// Sätt alla tre baserat på din applikations status
window.__CWVL  = 'checkout';      // Page Label
window.__CWAB  = 'variant-b';     // A/B-testvariant
window.__CWVLI = 1;               // inloggad

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å olika segment och din data fragmenteras. Välj en konvention och följ den konsekvent.

Kombinera alla tre

Det verkliga värdet uppstår när du kombinerar dessa dimensioner. 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 inloggade checkout-upplevelsen snabbare eller långsammare.

I CoreDash filtrerar du på ab = variant-b plus lb = checkout plus li = 1. Det ger dig prestandan för din checkout-variant för just inloggade användare. Inget annat övervakningsverktyg visar den kombinationen utan att du behöver göra eget utvecklingsarbete.

Tekniska standarddimensioner berättar vad webbläsaren upplevde. Egna dimensioner berättar vad verksamheten upplevde. En LCP-försämring på 400 ms betyder helt olika saker på en landing-page med betald trafik jämfört med ett blog-inlägg. De här skillnaderna är avgörande för prioriteringen, och prioriteringen är där prestandaarbete antingen lyckas eller stannar av.