Core/Dash Dimension: Custom Labels & Segmentierung

Eigene Segmentierung in CoreDash

Technische Dimensionen wie Land und Gerätetyp basieren auf Browser-Signalen. CoreDash erfasst sie automatisch. Die drei hier behandelten Dimensionen sind anders: Page Label, A/B Test und Logged In Status sind benutzerdefiniert. Du legst sie fest, indem du eine window-Variable in deinem eigenen Code zuweist, bevor CoreDash läuft.

Dieser Wechsel von automatisch zu gezielt ist der entscheidende Punkt. Deine Anwendung weiß Dinge, die der Browser nicht ableiten kann: welche Checkout-Variante ein Nutzer sieht, ob die aktuelle URL eine Produktdetailseite oder eine Landingpage ist, ob der Nutzer angemeldet ist. Die Übergabe dieses Kontexts an CoreDash sorgt dafür, dass deine Performance-Daten widerspiegeln, wie dein Geschäft tatsächlich funktioniert.

Page Label (lb)

Die Dimension Page Label ermöglicht es dir, Seiten nach ihrer geschäftlichen Funktion statt nach der URL-Struktur zu gruppieren. Definiere sie so:

window.__CWVL = 'mypagelabel';

Typische Werte: checkout, product-detail, landing-page, category, search-results, account. Der Wert ist ein beliebiger String, den du kontrollierst.

Warum das wichtig ist

Die URL-basierte Analyse hat ein grundlegendes Skalierungsproblem. Eine große E-Commerce-Website hat vielleicht 50.000 Produktdetailseiten. Ihre URLs sehen aus wie /products/blue-widget-32oz und /products/red-gadget-xl. Sie nutzen dasselbe Template, dieselbe geschäftliche Funktion und haben dasselbe Optimierungsziel. Sie einzeln URL für URL zu analysieren, ist nicht sinnvoll. Eine Gruppierung unter product-detail liefert dir ein einziges Performance-Profil für den gesamten Produktkatalog.

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

Sobald du Seiten nach geschäftlicher Funktion labelst, kannst du in CoreDash pro Label unterschiedliche Warnschwellen definieren und die richtigen Alarme an die richtigen Teams weiterleiten.

A/B-Test (ab)

Die Dimension A/B-Test enthält ein Label, das du der aktuellen Variante zuweist, die ein Nutzer sieht. Definiere sie so:

window.__CWAB = 'my page version';

Der Wert ist beliebig. variant-a und variant-b sind naheliegende Optionen, aber du kannst jeden beliebigen String verwenden, der auf die Varianten-IDs deiner Experimentierplattform verweist.

Warum das wichtig ist

A/B-Tests sind eine der häufigsten Ursachen für unbeabsichtigte Performance-Regressionen. Variante B liefert ein neues Hero-Bild-Karussell aus. Variante B lädt ein Empfehlungs-Widget eines Drittanbieters. Variante B erfordert eine zusätzliche Runde React-Hydration. All das verursacht Performance-Kosten, die dein Experiment-Tooling fast sicher nicht misst.

Die meisten Experimentierplattformen erfassen Conversion-Rates und Umsatz. Sie messen weder p75 LCP noch INP. Wenn Variante B um 2 % besser konvertiert, aber auf Mobilgeräten 400 ms langsamer lädt, musst du das wissen, bevor du sie für 100 % des Traffics freischaltest. Die Performance-Kosten könnten den Conversion-Gewinn im nächsten Quartal wieder zunichtemachen, wenn die Nutzer die Geduld verlieren.

Sobald __CWAB gesetzt ist, öffne CoreDash, filtere nach ab = variant-b und vergleiche 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 hatte als die Kontrollgruppe, weil sie eine schwerere Schriftart lud. Das Business-Team sah den Conversion-Anstieg, sah aber nicht die Performance-Regression. Genau das verhindert diese Dimension.

Logged In Status (li)

Die Dimension Logged In Status erfasst, ob der aktuelle Nutzer angemeldet ist. Definiere sie so:

window.__CWVLI = 1; // angemeldet
window.__CWVLI = 0; // abgemeldet

Warum das wichtig ist

Angemeldete Nutzer erhalten eine grundlegend andere Seite als anonyme Besucher. Ihre Anfragen umgehen viele CDN-Cache-Layer. Der Server führt Datenbankabfragen für personalisierte Inhalte aus: den Warenkorb des Nutzers, seine Bestellhistorie, seine gespeicherten Artikel. Diese serverseitige Arbeit erhöht direkt die TTFB.

Im Frontend laden authentifizierte Seiten oft mehr JavaScript: Account-Widgets, Benachrichtigungssysteme, Warenkorb-Reaktivität. Sie überspringen oft auch das Prerendering oder das Edge-Caching, das anonyme Seiten schnell macht. Das Ergebnis: Angemeldete Nutzer erleben oft eine schlechtere Performance als anonyme Besucher – obwohl angemeldete Nutzer meist deine wertvollsten Kunden sind. Sie haben bereits konvertiert. Sie sind diejenigen, die du am ehesten binden musst.

Ohne die Dimension li versteckt sich eine langsame Performance für angemeldete Nutzer in deinen aggregierten Zahlen. Dein anonymer LCP liegt vielleicht bei 1,8 s, während dein LCP für angemeldete Nutzer bei 3,4 s liegt. Der aggregierte Wert wird mit 2,3 s angezeigt und sieht akzeptabel aus. Nach li aufgeteilt, ändert sich das Bild komplett.

Implementierung

Alle drei Dimensionen nutzen dasselbe Muster: Setze eine window-Variable, bevor das CoreDash-Snippet ausgeführt wird. Platziere sie in einem script-Tag im Head deines Dokuments oder im Initialisierungscode deiner Anwendung:

// Setze alle drei basierend auf deinem App-Status
window.__CWVL  = 'checkout';      // Page-Label
window.__CWAB  = 'variant-b';     // A/B-Test-Variante
window.__CWVLI = 1;               // angemeldet

Die Label-Werte sind Strings (außer __CWVLI, das 1 oder 0 erwartet). Halte sie in deiner gesamten Codebasis einheitlich. Wenn du product-detail in einem Template und productDetail in einem anderen verwendest, behandelt CoreDash sie als zwei separate Segmente und deine Daten fragmentieren. Lege eine Konvention fest und setze sie durch.

Kombination aller drei

Der wahre Wert zeigt sich, wenn du diese Dimensionen kombinierst. Du führst einen A/B-Test auf deiner Checkout-Seite für angemeldete Nutzer durch. Du willst wissen, ob Variante B den Checkout für angemeldete Nutzer schneller oder langsamer macht.

Filtere in CoreDash nach ab = variant-b plus lb = checkout plus li = 1. Das liefert dir die Performance deiner Checkout-Variante speziell für angemeldete Nutzer. Kein anderes Monitoring-Tool liefert diese Kombination ohne zusätzlichen Entwicklungsaufwand deinerseits.

Standardmäßige technische Dimensionen zeigen dir, was der Browser erlebt hat. Custom-Dimensionen zeigen dir, was das Geschäft erlebt hat. Eine LCP-Regression von 400 ms bedeutet auf einer landing-page mit bezahltem Traffic etwas völlig anderes als bei einem blog-Beitrag. Diese Unterschiede sind wichtig für die Priorisierung – und an der Priorisierung entscheidet sich, ob Performance-Arbeit Erfolg hat oder stagniert.