Wymiar Core/Dash: Własne etykiety i segmentacja

Własna segmentacja w CoreDash

Wymiary techniczne, takie jak kraj i typ urządzenia, powstają na podstawie sygnałów z przeglądarki. CoreDash zbiera je automatycznie. Trzy omawiane tutaj wymiary są inne: Page Label, A/B Test i Logged In Status są definiowane przez użytkownika. Ustawiasz je poprzez przypisanie zmiennej window w swoim kodzie, zanim uruchomi się CoreDash.

To przejście od automatyzacji do świadomego działania to całe sedno. Twoja aplikacja wie o rzeczach, których przeglądarka nie może wywnioskować: który wariant procesu zakupowego widzi użytkownik, czy bieżący URL to strona szczegółów produktu, czy landing page, oraz czy użytkownik jest uwierzytelniony. Przekazanie tego kontekstu do CoreDash sprawia, że dane o wydajności odzwierciedlają rzeczywiste działanie Twojego biznesu.

Page Label (lb)

Wymiar Page Label pozwala grupować strony według funkcji biznesowych, a nie struktury URL. Zdefiniuj go w ten sposób:

window.__CWVL = 'mypagelabel';

Typowe wartości: checkout, product-detail, landing-page, category, search-results, account. Wartość to dowolny ciąg znaków, który kontrolujesz.

Dlaczego to ważne

Analiza oparta na adresach URL ma zasadniczy problem ze skalowaniem. Duży sklep e-commerce może mieć 50 000 stron szczegółów produktu. Ich adresy URL wyglądają jak /products/blue-widget-32oz i /products/red-gadget-xl. To ten sam szablon, ta sama funkcja biznesowa i ten sam cel optymalizacji. Analizowanie ich pojedynczo nie ma sensu. Pogrupowanie ich pod etykietą product-detail daje jeden profil wydajności dla całego katalogu produktów.

Page Label pozwala też oddzielić strony, które mają różne budżety wydajności. Strona procesu zakupowego ma jeden akceptowalny próg LCP, bo generuje bezpośredni przychód. Wpis na blogu ma inną tolerancję. Landing page z płatnym ruchem ma zerową tolerancję na wolne LCP, bo każda milisekunda kosztuje Cię wydatki na reklamy.

Gdy oznaczysz strony według funkcji biznesowych, możesz ustawić w CoreDash różne progi alertów dla każdej etykiety i kierować odpowiednie alerty do właściwych zespołów.

A/B Test (ab)

Wymiar A/B Test przechowuje etykietę przypisaną do wariantu, którego aktualnie doświadcza użytkownik. Zdefiniuj go tak:

window.__CWAB = 'my page version';

Wartość jest dowolna. Oczywistym wyborem są variant-a i variant-b, ale możesz użyć dowolnego ciągu znaków, który mapuje się na identyfikatory wariantów w Twojej platformie eksperymentalnej.

Dlaczego to ważne

Testy A/B to jedno z najczęstszych źródeł niezamierzonych regresji wydajności. Wariant B wprowadza nową karuzelę obrazów typu hero. Wariant B ładuje zewnętrzny widżet rekomendacji. Wariant B zawiera dodatkową rundę hydratacji Reacta. Wszystko to wiąże się z kosztem wydajnościowym, którego Twoje narzędzie do eksperymentów prawie na pewno nie mierzy.

Większość platform eksperymentalnych śledzi współczynniki konwersji i przychody. Nie śledzą one jednak p75 LCP ani INP. Jeśli wariant B konwertuje o 2% lepiej, ale ładuje się o 400 ms wolniej na urządzeniach mobilnych, musisz o tym wiedzieć przed wdrożeniem go dla 100% ruchu. Koszt wydajnościowy może zniweczyć wzrost konwersji w kolejnym kwartale, gdy użytkownicy stracą cierpliwość.

Po ustawieniu __CWAB otwórz CoreDash, przefiltruj po ab = variant-b i porównaj Core Web Vitals bezpośrednio z wersją kontrolną. Widziałem testy A/B, w których zwycięski wariant miał p75 LCP gorszy o 600 ms od wersji kontrolnej, ponieważ ładował cięższy font. Zespół biznesowy widział wzrost konwersji, ale nie widział regresji wydajności. Właśnie temu zapobiega ten wymiar.

Logged In Status (li)

Wymiar Logged In Status rejestruje, czy bieżący użytkownik jest uwierzytelniony. Zdefiniuj go tak:

window.__CWVLI = 1; // zalogowany
window.__CWVLI = 0; // niezalogowany

Dlaczego to ważne

Zalogowani użytkownicy otrzymują zasadniczo inną stronę niż odwiedzający anonimowo. Ich żądania omijają wiele warstw pamięci podręcznej CDN. Serwer wykonuje zapytania do bazy danych w celu pobrania spersonalizowanej zawaktuści: koszyka użytkownika, historii zamówień czy zapisanych produktów. Ta praca po stronie serwera bezpośrednio zwiększa TTFB.

Na frontendzie strony dla zalogowanych użytkowników często ładują więcej JavaScript: widżety konta, systemy powiadomień, reaktywność koszyka zakupowego. Mogą też pomijać prerendering lub edge caching, które przyspieszają strony dla użytkowników anonimowych. W efekcie zalogowani użytkownicy często doświadczają gorszej wydajności niż ci anonimowi, mimo że to zazwyczaj Twoi najcenniejsi klienci. Dokonali już konwersji. To właśnie ich najbardziej musisz zatrzymać.

Bez wymiaru li niska wydajność zalogowanych użytkowników ukrywa się w zagregowanych liczbach. Twoje anonimowe LCP może wynosić 1,8 s, podczas gdy dla zalogowanych jest to 3,4 s. Wartość zagregowana pokaże 2,3 s i będzie wyglądać na akceptowalną. Podziel to po li, a obraz sytuacji zmieni się całkowicie.

Implementacja

Wszystkie trzy wymiary korzystają z tego samego wzorca: ustaw zmienną obiektu window przed wykonaniem fragmentu kodu CoreDash. Umieść je w tagu script w sekcji head dokumentu lub w kodzie inicjalizacyjnym aplikacji:

// Ustaw wszystkie trzy na podstawie stanu aplikacji
window.__CWVL  = 'checkout';      // etykieta strony
window.__CWAB  = 'variant-b';     // wariant testu A/B
window.__CWVLI = 1;               // zalogowany

Wartości etykiet to ciągi znaków (z wyjątkiem __CWVLI, który przyjmuje 1 lub 0). Dbaj o ich spójność w całej bazie kodu. Jeśli w jednym szablonie użyjesz product-detail, a w innym productDetail, CoreDash potraktuje je jako dwa oddzielne segmenty, a Twoje dane ulegną fragmentacji. Wybierz konwencję i się jej trzymaj.

Łączenie wszystkich trzech

Prawdziwa wartość pojawia się, gdy nałożysz te wymiary na siebie. Załóżmy, że prowadzisz test A/B na stronie procesu zakupowego dla zalogowanych użytkowników. Chcesz wiedzieć, czy wariant B przyspiesza, czy spowalnia checkout uwierzytelnionych użytkowników.

W CoreDash przefiltruj dane po ab = variant-b plus lb = checkout plus li = 1. To da Ci wydajność wariantu procesu zakupowego konkretnie dla uwierzytelnionych użytkowników. Żadne inne narzędzie monitorujące nie pokaże takiej kombinacji bez dodatkowej pracy programistycznej po Twojej stronie.

Standardowe wymiary techniczne mówią o tym, czego doświadczyła przeglądarka. Własne wymiary mówią o tym, czego doświadczył biznes. Regresja LCP o 400 ms oznacza coś zupełnie innego na stronie typu landing-page z płatnym ruchem niż we wpisie typu blog. Te różnice mają znaczenie dla priorytetyzacji, a priorytetyzacja to moment, w którym prace nad wydajnością kończą się sukcesem albo utykają w miejscu.