Dimensione Core/Dash: Etichette Personalizzate & Segmentazione

Segmentazione Personalizzata in CoreDash

Dimensioni tecniche come il paese e il tipo di dispositivo vengono create a partire dai segnali del browser. CoreDash le raccoglie automaticamente. 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 dell'esecuzione di CoreDash.

Questo passaggio da automatico a intenzionale è il punto fondamentale. La tua applicazione sa cose che il browser non può dedurre: quale variante del checkout sta visualizzando un utente, se l'URL attuale è una pagina di dettaglio prodotto o una landing page, se l'utente è autenticato. Passare questo contesto a CoreDash significa che i tuoi dati di performance riflettono come funziona realmente il tuo business.

Page Label (lb)

La dimensione Page Label ti permette di raggruppare le pagine in base alla funzione di business piuttosto che alla 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 sotto il tuo controllo.

Perché è importante

L'analisi basata sugli URL ha un problema fondamentale di scalabilità. Un grande sito e-commerce potrebbe avere 50.000 pagine di dettaglio prodotto. I loro URL si presentano come /products/blue-widget-32oz e /products/red-gadget-xl. Si tratta dello stesso template, della stessa funzione di business, dello stesso target di ottimizzazione. Analizzarle un URL alla volta non è utile. Raggrupparle sotto product-detail ti fornisce un unico profilo di performance per l'intero catalogo prodotti.

La Page Label separa anche le pagine che rispondono a diversi budget di performance. Una pagina di checkout ha una soglia di LCP accettabile perché porta ricavi diretti. Un post del blog ha una tolleranza diversa. Una landing page che riceve traffico a pagamento ha tolleranza zero per un LCP lento, poiché ogni millisecondo ti costa in spesa pubblicitaria.

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

A/B Test (ab)

La dimensione A/B Test contiene un'etichetta che assegni alla variante attuale mostrata all'utente. Definiscila in questo modo:

window.__CWAB = 'my page version';

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

Perché è importante

Gli A/B test sono una delle fonti più comuni di regressioni involontarie delle performance. 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. Tutte queste opzioni comportano un costo in termini di performance che i tuoi strumenti di sperimentazione, 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 carica 400ms più lentamente su mobile, devi saperlo prima di distribuirla al 100% del traffico. Il costo sulle performance potrebbe annullare il guadagno in conversioni nel trimestre successivo, man mano che gli utenti perdono la pazienza.

Con __CWAB impostato, apri CoreDash, filtra per ab = variant-b e confronta i Core Web Vitals fianco a fianco con quelli di controllo. Ho visto A/B test in cui la variante vincente aveva un p75 di LCP peggiore di 600ms rispetto a quella di controllo perché caricava un font più pesante. Il team di business ha visto l'aumento delle conversioni; non ha visto la regressione delle performance. Questo è esattamente ciò che questa dimensione previene.

Logged In Status (li)

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

window.__CWVLI = 1; // logged in
window.__CWVLI = 0; // logged out

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 al database per contenuti personalizzati: il carrello dell'utente, la cronologia degli ordini, gli elementi salvati. Quel lavoro lato server si aggiunge direttamente al TTFB.

Sul frontend, le pagine autenticate spesso caricano più JavaScript: widget dell'account, sistemi di notifica, reattività del carrello della spesa. Potrebbero anche saltare il prerendering o l'edge caching che rendono veloci le pagine anonime. Il risultato è che gli utenti loggati vedono spesso performance più lente rispetto agli utenti anonimi, eppure gli utenti loggati sono tipicamente i tuoi clienti di maggior valore. Hanno già convertito. Sono quelli che devi maggiormente fidelizzare.

Senza la dimensione li, le performance lente dei loggati si nascondono all'interno dei tuoi numeri aggregati. Il tuo LCP anonimo potrebbe essere di 1.8s, mentre l'LCP loggato è di 3.4s. L'aggregato segna 2.3s e sembra accettabile. Dividi per li e il quadro cambia completamente.

Implementazione

Tutte e tre le dimensioni utilizzano lo stesso pattern: impostare una variabile window prima che venga eseguito lo snippet di CoreDash. Inseriscile in un tag script nell'head del tuo documento o nel codice di inizializzazione della tua applicazione:

// Set all three based on your app state
window.__CWVL  = 'checkout';      // page label
window.__CWAB  = 'variant-b';     // A/B test variant
window.__CWVLI = 1;               // logged in

I valori delle etichette sono stringhe (tranne __CWVLI che accetta 1 o 0). Mantienili coerenti in tutta la tua codebase. Se usi product-detail in un template e productDetail in un altro, CoreDash li tratta come due segmenti separati e i tuoi dati si frammentano. Scegli una convenzione e rispettala.

Combinare tutte e tre le dimensioni

Il vero valore emerge quando metti insieme queste dimensioni. Stai eseguendo un A/B test sulla tua 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 la performance della tua variante di checkout specificamente per gli utenti autenticati. Nessun altro strumento di monitoraggio mette in luce questa combinazione senza un lavoro ingegneristico personalizzato da parte tua.

Le dimensioni tecniche standard ti dicono cosa ha vissuto il browser. Le dimensioni personalizzate ti dicono cosa ha vissuto il business. Una regressione LCP di 400ms significa qualcosa di molto diverso su una landing-page che riceve traffico a pagamento rispetto a un post del blog. Queste distinzioni sono importanti per la definizione delle priorità, e le priorità sono il punto in cui il lavoro sulle performance ha successo o entra in stallo.