Core/Dash-dimensio: Mukautetut tunnisteet & segmentointi

Mukautettu segmentointi CoreDashissa

Tekniset dimensiot, kuten maa ja laitetyyppi, muodostetaan selaimen signaaleista. CoreDash kerää ne automaattisesti. Tässä käsitellyt kolme dimensiota ovat erilaisia: Sivun tunniste (Page Label), A/B-testi ja Kirjautumistila (Logged In Status) ovat käyttäjän määrittelemiä. Asetat ne määrittämällä window-muuttujan omassa koodissasi ennen kuin CoreDash suoritetaan.

Tämä siirtymä automaattisesta tarkoitukselliseen on koko asian ydin. Sovelluksesi tietää asioita, joita selain ei voi päätellä: minkä kassavariantin käyttäjä näkee, onko nykyinen URL-osoite tuotesivu vai laskeutumissivu, onko käyttäjä tunnistautunut. Tämän kontekstin välittäminen CoreDashille tarkoittaa, että suorituskykydatasi heijastaa sitä, miten liiketoimintasi todella toimii.

Sivun tunniste (lb)

Sivun tunniste -dimensio (Page Label) antaa sinun ryhmitellä sivuja liiketoimintatoiminnon, eikä URL-rakenteen perusteella. Määrittele se näin:

window.__CWVL = 'mypagelabel';

Tyypillisiä arvoja: checkout, product-detail, landing-page, category, search-results, account. Arvo on mielivaltainen merkkijono, jota hallitset.

Miksi tällä on merkitystä

URL-pohjaisessa analyysissä on perustavanlaatuinen skaalautuvuusongelma. Suurella verkkokauppasivustolla voi olla 50 000 tuotesivua. Niiden URL-osoitteet näyttävät tältä: /products/blue-widget-32oz ja /products/red-gadget-xl. Ne ovat samaa mallia, niillä on sama liiketoiminnallinen funktio ja sama optimointikohde. Niiden analysointi URL kerrallaan ei ole hyödyllistä. Niiden ryhmittely product-detail -tunnisteen alle antaa sinulle yhden suorituskykyprofiilin koko tuoteluettelolle.

Sivun tunniste erottaa myös sivut, jotka palvelevat eri suorituskykybudjetteja. Kassasivulla on yksi hyväksyttävä LCP-kynnys, koska se tuottaa suoraa tuloa. Blogikirjoituksella on eri toleranssi. Maksettua liikennettä vastaanottavalla laskeutumissivulla on nollatoleranssi hitaalle LCP:lle, koska jokainen millisekunti maksaa mainoskuluja.

Kun olet merkinnyt sivut liiketoimintatoiminnon mukaan, voit asettaa CoreDashissa eri hälytyskynnykset tunnisteittain ja ohjata oikeat hälytykset oikeille tiimeille.

A/B-testi (ab)

A/B-testi -dimensio sisältää tunnisteen, jonka määrität käyttäjän parhaillaan kokemalle variantille. Määrittele se näin:

window.__CWAB = 'my page version';

Arvo on mielivaltainen. variant-a ja variant-b ovat ilmeisiä valintoja, mutta voit käyttää mitä tahansa merkkijonoa, joka vastaa kokeilualustasi varianttien tunnisteita.

Miksi tällä on merkitystä

A/B-testit ovat yksi yleisimmistä tahattomien suorituskyvyn taantumien lähteistä. Variantti B sisältää uuden hero-kuvakarusellin. Variantti B lataa kolmannen osapuolen suosituswidgetin. Variantti B sisältää ylimääräisen kierroksen Reactin hydraatiota. Kaikilla näillä on suorituskykykustannus, jota kokeilutyökalusi ei lähes varmasti mittaa.

Useimmat kokeilualustat seuraavat konversioprosentteja ja tuloja. Ne eivät seuraa p75 LCP:tä tai INP:tä. Jos variantti B konvertoituu 2 % paremmin, mutta latautuu 400 ms hitaammin mobiililaitteilla, sinun on tiedettävä se ennen kuin julkaiset sen 100 %:lle liikenteestä. Suorituskykykustannus voi pyyhkiä konversiohyödyn pois seuraavan vuosineljänneksen aikana, kun käyttäjät menettävät kärsivällisyytensä.

Kun __CWAB on asetettu, avaa CoreDash, suodata ab = variant-b ja vertaile Core Web Vitals -metriikoita rinnakkain kontrolliversion kanssa. Olen nähnyt A/B-testejä, joissa voittavalla variantilla oli 600 ms huonompi p75 LCP kuin kontrollilla, koska se latasi raskaamman fontin. Liiketoimintatiimi näki konversion nousun; he eivät nähneet suorituskyvyn heikkenemistä. Tämän tämä dimensio estää.

Kirjautumistila (li)

Kirjautumistila-dimensio (Logged In Status) tallentaa, onko nykyinen käyttäjä tunnistautunut. Määrittele se näin:

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

Miksi tällä on merkitystä

Kirjautuneet käyttäjät saavat täysin erilaisen sivun kuin anonyymit vierailijat. Heidän pyyntönsä ohittavat monia CDN-välimuistitasoja. Palvelin suorittaa tietokantakyselyitä personoitua sisältöä varten: käyttäjän ostoskori, heidän tilaushistoriansa, tallennetut tuotteet. Tämä palvelinpuolen työ lisää suoraan TTFB:tä.

Front-endissä tunnistautuneet sivut lataavat usein enemmän JavaScriptiä: tilividgettejä, ilmoitusjärjestelmiä, ostoskorin reaktiivisuutta. Ne saattavat myös ohittaa esirenderöinnin tai reunavälimuistituksen (edge caching), jotka tekevät anonyymeistä sivuista nopeita. Tuloksena on, että kirjautuneet käyttäjät kokevat usein hitaamman suorituskyvyn kuin anonyymit käyttäjät, vaikka kirjautuneet käyttäjät ovat tyypillisesti arvokkaimpia asiakkaitasi. He ovat jo konvertoituneet. He ovat niitä, jotka sinun eniten täytyy pitää.

Ilman li-dimensiota hidas tunnistautunut suorituskyky piiloutuu yhdistettyjen lukujen sisään. Anonyymi LCP-arvosi saattaa olla 1,8 s, kun taas kirjautuneen käyttäjän LCP on 3,4 s. Yhdistetty arvo näyttää 2,3 s ja vaikuttaa hyväksyttävältä. Kun jaat datan li-arvon mukaan, kuva muuttuu täysin.

Toteutus

Kaikki kolme dimensiota käyttävät samaa mallia: aseta window-muuttuja ennen kuin CoreDash-koodinpätkä suoritetaan. Sijoita ne script-tunnisteeseen dokumenttisi head-osiossa tai sovelluksesi alustuskoodissa:

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

Tunnisteiden arvot ovat merkkijonoja (paitsi __CWVLI, joka ottaa arvon 1 tai 0). Pidä ne yhdenmukaisina koko koodikannassasi. Jos käytät arvoa product-detail yhdessä mallissa ja productDetail toisessa, CoreDash käsittelee niitä kahtena erillisenä segmenttinä ja datasi pirstaloituu. Valitse käytäntö ja pidä siitä kiinni.

Kaikkien kolmen yhdistäminen

Todellinen arvo tulee esiin, kun pinoat nämä dimensiot yhteen. Olet tekemässä A/B-testiä kassasivullasi kirjautuneille käyttäjille. Haluat tietää, tekeekö variantti B tunnistautuneen kassakokemuksen nopeammaksi vai hitaammaksi.

CoreDashissa, suodata parametreillä ab = variant-b sekä lb = checkout sekä li = 1. Tämä antaa sinulle kassavarianttisi suorituskyvyn nimenomaan tunnistautuneille käyttäjille. Mikään muu seurantatyökalu ei tuo tätä yhdistelmää esiin ilman omaa koodaustyötäsi.

Standardit tekniset dimensiot kertovat sinulle, mitä selain koki. Mukautetut dimensiot kertovat, mitä liiketoiminta koki. 400 ms LCP:n taantuma tarkoittaa aivan eri asiaa maksettua liikennettä vastaanottavalla landing-page-sivulla kuin blog-kirjoituksessa. Nämä erot ovat ratkaisevia priorisoinnissa, ja priorisointi on se alue, jolla suorituskykytyö joko onnistuu tai pysähtyy.