Core/Dash Dimension: Etichette personalizzate & segmentazione

Segmentazione personalizzata in CoreDash

Le dimensioni tecniche come paese e tipo di dispositivo derivano dai segnali del browser. CoreDash le raccoglie in modo automatico. Le tre dimensioni trattate qui sono diverse: Page Label, A/B Test e Logged In Status sono definite dall'utente. Le imposti assegnando una variabile window nel tuo codice prima che CoreDash venga eseguito.

Questo passaggio da automatico a intenzionale è il punto fondamentale. La tua aplicação conosce informazioni che il browser non può dedurre: quale variante di checkout sta visualizzando un utente, se l'URL corrente è una pagina di dettaglio prodotto o una landing page, se l'utente è autenticato. Passare questo contesto a CoreDash permette ai tuoi dati sulle prestazioni di riflettere il reale funzionamento del tuo business.

Page Label (lb)

La dimensione Page Label ti consente di raggruppare le pagine per funzione di business anziché per struttura dell'URL. Definiscila in questo modo:

window.__CWVL = 'mypagelabel';

Valori tipici: checkout, product-detail, landing-page, category, search-results, account. Il valore è una stringa arbitraria che controlli tu.

Perché è importante

L'analisi basata sugli URL ha un problema fondamentale di scalabilità. Un grande e-commerce può avere 50.000 pagine di dettaglio prodotto. I loro URL sono del tipo /products/blue-widget-32oz e /products/red-gadget-xl. Condividono lo stesso template, la stessa funzione di business e lo stesso obiettivo di ottimizzazione. Analizzarli un URL alla volta non serve. Raggrupparli sotto product-detail ti restituisce un unico profilo prestazionale per l'intero catalogo prodotti.

La Page Label separa inoltre le pagine che rispondono a diversi performance budget. Una pagina di checkout ha una determinata soglia di LCP accettabile perché porta entrate dirette. Un post del blog ha una tolleranza diversa. Una landing page con traffico a pagamento ha tolleranza zero per un LCP lento, perché ogni millisecondo in più ti costa in spesa pubblicitaria.

Una volta etichettate le pagine per funzione di business, puoi impostare soglie di alert diverse in CoreDash per ciascuna etichetta e indirizzare gli alert corretti ai team giusti.

A/B Test (ab)

La dimensione A/B Test contiene l'etichetta che assegni alla variante corrente che l'utente sta visualizzando. Definiscila in questo modo:

window.__CWAB = 'my page version';

Il valore è arbitrario. variant-a e variant-b sono scelte scontate, ma puoi usare qualsiasi stringa che si colleghi agli identificatori di variante della tua piattaforma di sperimentazione.

Perché è importante

I test A/B sono una delle cause più comuni di regressioni prestazionali impreviste. La variante B introduce un nuovo carosello di immagini hero. La variante B carica un widget di raccomandazione di terze parti. La variante B include un ciclo extra di idratazione React. Ognuno di questi elementi comporta un costo in termini di prestazioni che i tuoi strumenti di testing quasi certamente non misurano.

La maggior parte delle piattaforme di sperimentazione traccia i tassi di conversione e i ricavi. Non tracciano il p75 di LCP o INP. Se la variante B converte il 2% in più ma si carica 400 ms più lentamente su dispositivi mobile, devi saperlo prima di rilasciarla al 100% del traffico. Questo costo in termini di prestazioni potrebbe annullare il guadagno di conversione nel trimestre successivo, quando gli utenti perderanno la pazienza.

Con __CWAB configurato, apri CoreDash, filtra per ab = variant-b e confronta i Core Web Vitals direttamente con quelli di controllo. Ho visto test A/B in cui la variante vincente registrava un p75 LCP peggiore di 600 ms rispetto a quella di controllo perché caricava un font più pesante. Il team di business ha notato l'aumento delle conversioni, ma non la regressione prestazionale. Questa dimensione serve proprio a evitare questo scenario.

Logged In Status (li)

La dimensione Logged In Status registra se l'utente corrente è autenticato. Definiscila in questo modo:

window.__CWVLI = 1; // loggato
window.__CWVLI = 0; // non loggato

Perché è importante

Gli utenti loggati ricevono una pagina fondamentalmente diversa rispetto ai visitatori anonimi. Le loro richieste bypassano molti livelli di cache della CDN. Il server esegue query sul database per ricavare contenuti personalizzati: il carrello dell'utente, la cronologia degli ordini, gli elementi salvati. Questo lavoro lato server si aggiunge direttamente al TTFB.

Sul frontend, le pagine autenticate caricano spesso più JavaScript: widget dell'account, sistemi di notifica, reattività del carrello. Possono anche escludere il prerendering o l'edge caching che rendono veloci le pagine anonime. Di conseguenza, gli utenti loggati vedono spesso prestazioni più lente rispetto a quelli anonimi, sebbene siano i clienti di maggior valore. Hanno già convertito; sono proprio quelli che devi fidelizzare di più.

Senza la dimensione li, le prestazioni rallentate degli utenti autenticati restano nascoste all'interno dei dati aggregati. Il tuo LCP anonimo potrebbe essere di 1,8 secondi, mentre quello per gli utenti loggati di 3,4 secondi. Il dato aggregato risulterà pari a 2,3 secondi, sembrando accettabile. Suddividi per li e il quadro cambia completamente.

Implementation

Tutte e tre le dimensioni utilizzano lo stesso pattern: imposta una variabile window prima dell'esecuzione del codice di CoreDash. Inseriscile in un tag script nell'head del documento o nel codice di inizializzazione della tua applicazione:

// Configura tutte e tre in base allo stato dell'app
window.__CWVL  = 'checkout';      // etichetta della pagina
window.__CWAB  = 'variant-b';     // variante del test A/B
window.__CWVLI = 1;               // loggato

I valori delle etichette sono stringhe (eccetto __CWVLI che accetta 1 o 0). Mantienili coerenti in tutta la tua codebase. Se utilizzi product-detail in un template e productDetail in un altro, CoreDash li tratterà come due segmenti separati, frammentando i tuoi dati. Scegli una convenzione e falla rispettare.

Combining all three

Il vero valore emerge quando combini queste dimensioni. Stai eseguendo un test A/B sulla pagina di checkout per gli utenti loggati. Vuoi sapere se la variante B rende l'esperienza di checkout autenticata più veloce o più lenta.

In CoreDash, filtra per ab = variant-b più lb = checkout più li = 1. Questo ti restituisce le prestazioni della variante di checkout specificamente per gli utenti autenticati. Nessun altro strumento di monitoraggio evidenzia questa combinazione senza un lavoro di sviluppo personalizzato da parte tua.

Le dimensioni tecniche standard ti dicono cosa ha riscontrato il browser. Le dimensioni personalizzate ti dicono cosa ha riscontrato il business. Una regressione dell'LCP di 400 ms ha un significato molto diverso su una landing-page con traffico a pagamento rispetto a un post del blog. Queste distinzioni sono fondamentali per stabilire le priorità; ed è proprio la definizione delle priorità che determina se il lavoro sulle prestazioni avrà successo o si bloccherà.