Core/Dash Dimensie: Custom Labels & Segmentatie

Custom Segmentatie in CoreDash

Technische dimensies zoals land en apparaattype worden opgebouwd uit browsersignalen. CoreDash verzamelt deze automatisch. De drie dimensies die hier worden behandeld zijn anders: Page Label, A/B Test en Logged In Status zijn door de gebruiker gedefinieerd. Je stelt ze in door een window variabele toe te wijzen in je eigen code voordat CoreDash draait.

Die verschuiving van automatisch naar doelbewust is precies waar het om gaat. Jouw applicatie weet dingen die de browser niet kan afleiden: welke checkout-variant een gebruiker ziet, of de huidige URL een productdetailpagina of een landingspagina is, of de gebruiker is geauthenticeerd. Door die context door te geven aan CoreDash, weerspiegelt je prestatiedata hoe je bedrijf daadwerkelijk werkt.

Page Label (lb)

Met de Page Label dimensie kun je pagina's groeperen op bedrijfsfunctie in plaats van URL-structuur. Definieer het als volgt:

window.__CWVL = 'mypagelabel';

Typische waarden: checkout, product-detail, landing-page, category, search-results, account. De waarde is een willekeurige string die je zelf beheert.

Waarom dit belangrijk is

URL-gebaseerde analyse heeft een fundamenteel schaalprobleem. Een grote e-commerce site kan wel 50.000 productdetailpagina's hebben. Hun URL's zien eruit als /products/blue-widget-32oz en /products/red-gadget-xl. Dit is hetzelfde template, dezelfde bedrijfsfunctie, hetzelfde optimalisatiedoel. Het één voor één analyseren van deze URL's is niet zinvol. Door ze te groeperen onder product-detail krijg je één prestatieprofiel voor de volledige productcatalogus.

Page Label scheidt ook pagina's die verschillende prestatiebudgetten bedienen. Een checkout-pagina heeft een bepaalde acceptabele LCP-drempel omdat het direct omzet oplevert. Een blogpost heeft een andere tolerantie. Een landingspagina met betaald verkeer heeft nultolerantie voor een trage LCP omdat elke milliseconde je advertentiebudget kost.

Zodra je pagina's labelt op bedrijfsfunctie, kun je in CoreDash verschillende waarschuwingsdrempels per label instellen en de juiste waarschuwingen naar de juiste teams routeren.

A/B Test (ab)

De A/B Test dimensie bevat een label dat je toewijst aan de huidige variant die een gebruiker ervaart. Definieer het als volgt:

window.__CWAB = 'my page version';

De waarde is willekeurig. variant-a en variant-b zijn voor de hand liggende keuzes, maar je kunt elke string gebruiken die overeenkomt met de variant-identifiers van je experimentatieplatform.

Waarom dit belangrijk is

A/B-testen zijn een van de meest voorkomende bronnen van onbedoelde prestatieregressies. Variant B levert een nieuwe hero image carrousel. Variant B laadt een third-party aanbevelingswidget. Variant B bevat een extra ronde React hydratatie. Al deze zaken brengen prestatiekosten met zich mee die je experimentatietooling vrijwel zeker niet meet.

De meeste experimentatieplatforms volgen conversieratio's en omzet. Ze volgen geen p75 LCP of INP. Als variant B 2% beter converteert maar op mobiel 400ms langzamer laadt, moet je dat weten voordat je het uitrolt naar 100% van het verkeer. De prestatiekosten kunnen de conversiewinst in het volgende kwartaal tenietdoen naarmate gebruikers hun geduld verliezen.

Met __CWAB ingesteld, open je CoreDash, filter je op ab = variant-b, en vergelijk je de Core Web Vitals zij aan zij met de controle. Ik heb A/B-testen gezien waarbij de winnende variant een 600ms slechtere p75 LCP had dan de controle omdat deze een zwaarder lettertype laadde. Het business team zag de conversiestijging; zij zagen de prestatieregressie niet. Dat is wat deze dimensie voorkomt.

Logged In Status (li)

De Logged In Status dimensie registreert of de huidige gebruiker is geauthenticeerd. Definieer het als volgt:

window.__CWVLI = 1; // ingelogd
window.__CWVLI = 0; // uitgelogd

Waarom dit belangrijk is

Ingelogde gebruikers ontvangen een fundamenteel andere pagina dan anonieme bezoekers. Hun verzoeken omzeilen veel CDN cache-lagen. De server voert database query's uit voor gepersonaliseerde content: het winkelwagentje van de gebruiker, hun bestelgeschiedenis, hun opgeslagen items. Dat server-side werk telt direct op bij de TTFB.

Op de frontend laden geauthenticeerde pagina's vaak meer JavaScript: account-widgets, notificatiesystemen, reactiviteit van het winkelwagentje. Ze slaan mogelijk ook het prerenderen of edge cachen over dat anonieme pagina's snel maakt. Het resultaat is dat ingelogde gebruikers vaak tragere prestaties ervaren dan anonieme gebruikers, hoewel ingelogde gebruikers doorgaans je meest waardevolle klanten zijn. Ze zijn al geconverteerd. Zij zijn degenen die je het meest moet behouden.

Zonder de li dimensie verbergen trage geauthenticeerde prestaties zich in je geaggregeerde cijfers. Je anonieme LCP is misschien 1.8s, terwijl je ingelogde LCP 3.4s is. Het gemiddelde toont 2.3s en lijkt acceptabel. Splits dit op per li en het beeld verandert volledig.

Implementatie

Alle drie de dimensies gebruiken hetzelfde patroon: stel een window variabele in voordat de CoreDash snippet wordt uitgevoerd. Plaats ze in een script-tag in je document head of in de initialisatiecode van je applicatie:

// Stel ze alle drie in op basis van je app state
window.__CWVL  = 'checkout';      // page label
window.__CWAB  = 'variant-b';     // A/B-testvariant
window.__CWVLI = 1;               // ingelogd

De labelwaarden zijn strings (behalve __CWVLI die 1 of 0 accepteert). Houd ze consistent in je codebase. Als je product-detail in één template gebruikt en productDetail in een ander, behandelt CoreDash ze als twee afzonderlijke segmenten en fragmenteert je data. Kies een conventie en handhaaf deze.

Alle drie combineren

De echte waarde blijkt pas wanneer je deze dimensies met elkaar combineert. Je voert een A/B-test uit op je checkout-pagina voor ingelogde gebruikers. Je wilt weten of variant B de geauthenticeerde checkout-ervaring sneller of langzamer maakt.

In CoreDash, filter op ab = variant-b plus lb = checkout plus li = 1. Dat geeft je specifiek de prestaties van je checkout-variant voor geauthenticeerde gebruikers. Geen enkele andere monitoring tool brengt die combinatie naar boven zonder custom engineering werk aan jouw kant.

Standaard technische dimensies vertellen je wat de browser ervaart. Custom dimensies vertellen je wat het bedrijf ervaart. Een 400ms LCP regressie betekent iets heel anders op een landing-page met betaald verkeer dan op een blog post. Deze verschillen zijn belangrijk voor prioritering, en prioritering is waar prestatiewerk ofwel slaagt of vastloopt.