Core/Dash Dimension: Benutzerdefinierte Labels & Segmentierung

Benutzerdefinierte Segmentierung in CoreDash

Technische Dimensionen wie Land und Gerätetyp werden aus Browser-Signalen generiert. CoreDash erfasst diese automatisch. Die drei hier behandelten Dimensionen sind anders: Page Label, A/B Test und Logged In Status sind benutzerdefiniert. Sie legen diese fest, indem Sie eine window-Variable in Ihrem eigenen Code zuweisen, bevor CoreDash ausgeführt wird.

Dieser Wechsel von automatisch zu absichtlich ist der entscheidende Punkt. Ihre Anwendung weiß Dinge, die der Browser nicht ableiten kann: welche Checkout-Variante ein Benutzer sieht, ob die aktuelle URL eine Produktdetailseite oder eine Landingpage ist, ob der Benutzer authentifiziert ist. Wenn Sie diesen Kontext an CoreDash übergeben, spiegeln Ihre Leistungsdaten wider, wie Ihr Unternehmen tatsächlich funktioniert.

Page Label (lb)

Mit der Dimension Page Label können Sie Seiten nach Geschäftsfunktion statt nach URL-Struktur gruppieren. Definieren Sie es wie folgt:

window.__CWVL = 'mypagelabel';

Typische Werte: checkout, product-detail, landing-page, category, search-results, account. Der Wert ist eine beliebige Zeichenfolge, die Sie kontrollieren.

Warum das wichtig ist

URL-basierte Analysen haben ein grundlegendes Skalierungsproblem. Eine große E-Commerce-Website kann 50.000 Produktdetailseiten haben. Deren URLs sehen aus wie /products/blue-widget-32oz und /products/red-gadget-xl. Dies ist dasselbe Template, dieselbe Geschäftsfunktion, dasselbe Optimierungsziel. Sie eine URL nach der anderen zu analysieren, ist nicht sinnvoll. Wenn Sie sie unter product-detail gruppieren, erhalten Sie ein einziges Leistungsprofil für den gesamten Produktkatalog.

Das Page Label trennt auch Seiten, die unterschiedliche Performance-Budgets bedienen. Eine Checkout-Seite hat einen bestimmten akzeptablen LCP-Schwellenwert, da sie direkten Umsatz bringt. Ein Blogbeitrag hat eine andere Toleranz. Eine Landingpage mit bezahltem Traffic hat null Toleranz für einen langsamen LCP, da Sie jede Millisekunde Werbeausgaben kostet.

Sobald Sie Seiten nach Geschäftsfunktion kennzeichnen, können Sie in CoreDash pro Label unterschiedliche Warnschwellenwerte festlegen und die richtigen Warnungen an die richtigen Teams weiterleiten.

A/B Test (ab)

Die Dimension A/B Test enthält ein Label, das Sie der aktuellen Variante zuweisen, die ein Benutzer erlebt. Definieren Sie es wie folgt:

window.__CWAB = 'my page version';

Der Wert ist beliebig. variant-a und variant-b sind naheliegende Optionen, aber Sie können jede beliebige Zeichenfolge verwenden, die den Variantenbezeichnern Ihrer Experimentierplattform entspricht.

Warum das wichtig ist

A/B-Tests sind eine der häufigsten Ursachen für unbeabsichtigte Performance-Regressionen. Variante B liefert ein neues Hero-Image-Karussell aus. Variante B lädt ein Empfehlungs-Widget von einem Drittanbieter. Variante B beinhaltet eine zusätzliche Runde React-Hydratation. All dies ist mit Leistungskosten verbunden, die Ihre Experimentierwerkzeuge fast sicher nicht messen.

Die meisten Experimentierplattformen verfolgen Konversionsraten und Umsatz. Sie erfassen weder p75 LCP noch INP. Wenn Variante B eine um 2 % bessere Konversion erzielt, aber auf mobilen Geräten 400 ms langsamer lädt, müssen Sie das wissen, bevor Sie sie auf 100 % des Traffics ausrollen. Die Leistungskosten können den Konversionsgewinn im nächsten Quartal zunichtemachen, da die Benutzer die Geduld verlieren.

Wenn __CWAB festgelegt ist, öffnen Sie CoreDash, filtern Sie nach ab = variant-b und vergleichen Sie die Core Web Vitals direkt mit der Kontrollgruppe. Ich habe A/B-Tests gesehen, bei denen die Gewinner-Variante einen um 600 ms schlechteren p75 LCP aufwies als die Kontrolle, weil eine schwerere Schriftart geladen wurde. Das Business-Team sah die Konversionssteigerung; sie sahen jedoch nicht die Performance-Regression. Genau das verhindert diese Dimension.

Logged In Status (li)

Die Dimension Logged In Status erfasst, ob der aktuelle Benutzer authentifiziert ist. Definieren Sie es wie folgt:

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

Warum das wichtig ist

Eingeloggte Benutzer erhalten eine grundlegend andere Seite als anonyme Besucher. Ihre Anfragen umgehen viele CDN-Cache-Schichten. Der Server führt Datenbankabfragen für personalisierte Inhalte aus: den Warenkorb des Benutzers, seine Bestellhistorie, seine gespeicherten Artikel. Diese serverseitige Arbeit trägt direkt zum TTFB bei.

Im Frontend laden authentifizierte Seiten oft mehr JavaScript: Konto-Widgets, Benachrichtigungssysteme, Warenkorb-Reaktivität. Möglicherweise überspringen sie auch das Prerendering oder Edge-Caching, das anonyme Seiten schnell macht. Das Ergebnis ist, dass eingeloggte Benutzer oft eine langsamere Performance erleben als anonyme Benutzer, obwohl eingeloggte Benutzer in der Regel Ihre wertvollsten Kunden sind. Sie haben bereits konvertiert. Sie sind diejenigen, die Sie am dringendsten binden müssen.

Ohne die li-Dimension verbirgt sich eine langsame authentifizierte Performance in Ihren aggregierten Zahlen. Ihr anonymer LCP könnte bei 1,8 s liegen, während Ihr eingeloggter LCP bei 3,4 s liegt. Der aggregierte Wert wird als 2,3 s angezeigt und sieht akzeptabel aus. Teilt man dies nach li auf, ändert sich das Bild komplett.

Implementierung

Alle drei Dimensionen verwenden dasselbe Muster: Setzen Sie eine window-Variable, bevor das CoreDash-Snippet ausgeführt wird. Platzieren Sie diese in einem script-Tag in Ihrem Document Head oder im Initialisierungscode Ihrer Anwendung:

// 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

Die Label-Werte sind Strings (außer __CWVLI, das 1 oder 0 akzeptiert). Halten Sie diese in Ihrer gesamten Codebasis konsistent. Wenn Sie product-detail in einem Template und productDetail in einem anderen verwenden, behandelt CoreDash diese als zwei separate Segmente und Ihre Daten fragmentieren. Entscheiden Sie sich für eine Konvention und setzen Sie diese konsequent um.

Kombination aller drei

Der wahre Wert zeigt sich, wenn Sie diese Dimensionen miteinander kombinieren. Sie führen einen A/B-Test auf Ihrer Checkout-Seite für eingeloggte Benutzer durch. Sie möchten wissen, ob Variante B das authentifizierte Checkout-Erlebnis schneller oder langsamer macht.

Filtern Sie in CoreDash nach ab = variant-b plus lb = checkout plus li = 1. Das liefert Ihnen gezielt die Performance Ihrer Checkout-Variante für authentifizierte Benutzer. Kein anderes Monitoring-Tool bringt diese Kombination ohne eigene Entwicklungsarbeit auf Ihrer Seite zum Vorschein.

Standardmäßige technische Dimensionen verraten Ihnen, was der Browser erlebt hat. Benutzerdefinierte Dimensionen verraten Ihnen, was das Unternehmen erlebt hat. Eine LCP-Regression von 400 ms bedeutet auf einer landing-page mit bezahltem Traffic etwas völlig anderes als auf einem blog-Beitrag. Diese Unterschiede sind für die Priorisierung von Bedeutung, und an der Priorisierung entscheidet sich, ob Performance-Arbeit erfolgreich ist oder ins Stocken gerät.