Wymiar Core/Dash: Niestandardowe Etykiety i Segmentacja

Niestandardowa Segmentacja w CoreDash

Wymiary techniczne, takie jak kraj i typ urządzenia, są budowane na podstawie sygnałów z przeglądarki. CoreDash zbiera je automatycznie. Trzy omawiane tutaj wymiary są inne: Etykieta Strony, Test A/B i Stan Zalogowania są definiowane przez użytkownika. Ustawiasz je, przypisując zmienną window we własnym kodzie, zanim uruchomi się CoreDash.

To przejście od automatyzacji do intencjonalności jest kluczowe. Twoja aplikacja wie rzeczy, których przeglądarka nie może wywnioskować: jaki wariant koszyka widzi użytkownik, czy obecny adres URL to strona szczegółów produktu, czy landing page, a także czy użytkownik jest uwierzytelniony. Przekazanie tego kontekstu do CoreDash sprawia, że dane o wydajności odzwierciedlają to, jak faktycznie działa Twój biznes.

Etykieta Strony (lb)

Wymiar Etykieta Strony pozwala pogrupować strony według funkcji biznesowej, a nie struktury adresów URL. Zdefiniuj go w ten sposób:

window.__CWVL = 'mypagelabel';

Typowe wartości: checkout, product-detail, landing-page, category, search-results, account. Wartość jest dowolnym ciągiem znaków, nad którym masz pełną kontrolę.

Dlaczego to ma znaczenie

Analiza oparta na adresach URL ma fundamentalny problem ze skalowaniem. Duża witryna e-commerce może mieć 50 000 stron ze szczegółami produktów. Ich adresy URL wyglądają jak /products/blue-widget-32oz oraz /products/red-gadget-xl. To ten sam szablon, ta sama funkcja biznesowa, ten sam cel optymalizacji. Analizowanie ich po jednym adresie URL na raz nie jest użyteczne. Zgrupowanie ich pod product-detail daje jeden profil wydajności dla całego katalogu produktów.

Etykieta Strony oddziela również strony, które mają różne budżety wydajnościowe. Strona kasy (checkout) ma jeden akceptowalny próg LCP, ponieważ generuje bezpośrednie przychody. Wpis na blogu ma inną tolerancję. Landing page obsługujący płatny ruch ma zerową tolerancję dla powolnego LCP, ponieważ każda milisekunda kosztuje Cię wydatki na reklamę.

Po przypisaniu etykiet stronom na podstawie ich funkcji biznesowych, możesz ustawić w CoreDash różne progi alertów dla każdej etykiety i przekierowywać odpowiednie alerty do właściwych zespołów.

Test A/B (ab)

Wymiar Test A/B przechowuje etykietę przypisaną do obecnego wariantu, którego doświadcza użytkownik. Zdefiniuj go w ten sposób:

window.__CWAB = 'my page version';

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

Dlaczego to ma znaczenie

Testy A/B to jedno z najczęstszych źródeł niezamierzonych regresji wydajności. Wariant B wprowadza nową karuzelę głównych obrazów. Wariant B ładuje widżet rekomendacji od firmy trzeciej. Wariant B zawiera dodatkową rundę hydratacji React. Wszystko to niesie za sobą koszty wydajnościowe, których Twoje narzędzia do eksperymentów niemal na pewno nie mierzą.

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

Po ustawieniu __CWAB, otwórz CoreDash, filtruj po ab = variant-b i porównaj Core Web Vitals obok siebie z wariantem kontrolnym. Widziałem testy A/B, w których zwycięski wariant miał o 600ms gorsze p75 LCP niż wariant kontrolny, ponieważ ładował cięższą czcionkę. Zespół biznesowy widział wzrost konwersji; nie widział regresji wydajności. Właśnie temu zapobiega ten wymiar.

Stan Zalogowania (li)

Wymiar Stan Zalogowania rejestruje, czy obecny użytkownik jest uwierzytelniony. Zdefiniuj go w ten sposób:

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

Dlaczego to ma znaczenie

Zalogowani użytkownicy otrzymują fundamentalnie inną stronę niż anonimowi goście. Ich żądania omijają wiele warstw pamięci podręcznej CDN. Serwer uruchamia zapytania do bazy danych o spersonalizowane treści: koszyk użytkownika, historię jego zamówień, zapisane przedmioty. Ta praca po stronie serwera bezpośrednio wpływa na TTFB.

Na frontendzie uwierzytelnione strony często ładują więcej JavaScript: widżety konta, systemy powiadomień, reaktywność koszyka. Mogą one również pominąć prerendering lub cachowanie brzegowe, co sprawia, że anonimowe strony są szybkie. W rezultacie zalogowani użytkownicy często doświadczają niższej wydajności niż anonimowi użytkownicy, a mimo to ci zalogowani to zazwyczaj Twoi najbardziej wartościowi klienci. Oni już dokonali konwersji. To ich najbardziej musisz zatrzymać.

Bez wymiaru li powolna wydajność uwierzytelnionych ukrywa się w Twoich łącznych wynikach. Twoje anonimowe LCP może wynosić 1.8s, podczas gdy Twoje LCP dla zalogowanych to 3.4s. Wynik sumaryczny wynosi 2.3s i wygląda akceptowalnie. Podziel to według li, a obraz całkowicie się zmieni.

Wdrożenie

Wszystkie trzy wymiary używają tego samego wzorca: ustaw zmienną 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óre przyjmuje 1 lub 0). Utrzymuj ich spójność w całej bazie kodu. Jeśli użyjesz product-detail w jednym szablonie, a productDetail w innym, CoreDash potraktuje je jako dwa oddzielne segmenty, a Twoje dane ulegną fragmentacji. Wybierz konwencję i egzekwuj jej przestrzeganie.

Łączenie wszystkich trzech

Prawdziwa wartość pojawia się, gdy połączysz te wymiary ze sobą. Przeprowadzasz test A/B na stronie kasy dla zalogowanych użytkowników. Chcesz wiedzieć, czy wariant B sprawia, że proces płatności po uwierzytelnieniu jest szybszy czy wolniejszy.

W CoreDash filtruj według ab = variant-b plus lb = checkout plus li = 1. To daje Ci obraz wydajności wariantu koszyka specjalnie dla uwierzytelnionych użytkowników. Żadne inne narzędzie do monitorowania nie ukazuje takiej kombinacji bez niestandardowych prac inżynieryjnych po Twojej stronie.

Standardowe wymiary techniczne mówią Ci, czego doświadczyła przeglądarka. Wymiary niestandardowe informują, czego doświadczył biznes. Regresja LCP o 400ms oznacza coś zupełnie innego na landing-page obsługującym płatny ruch, niż we wpisie na blog. Te rozróżnienia mają znaczenie dla priorytetyzacji, a priorytetyzacja to miejsce, w którym praca nad wydajnością odnosi sukces lub utyka w martwym punkcie.