Core/Dash-dimensio: Mukautetut tunnisteet & segmentointi

Mukautettu segmentointi CoreDashissa

Tekniset dimensiot, kuten maa ja laitetyyppi, rakentuvat selaimen signaaleista. CoreDash kerää ne automaattisesti. Tässä käsiteltävät 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 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ä todennettu. Tämän kontekstin välittäminen CoreDashille tarkoittaa, että suorituskykydatasta heijastuu se, miten liiketoimintasi todellisuudessa toimii.

Sivun tunniste (lb)

Sivun tunniste (Page Label) -dimensio antaa sinun ryhmitellä sivuja liiketoimintatoiminnon, ei URL-rakenteen, mukaan. Määritä 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. Kyseessä on sama sivupohja, sama liiketoimintatoiminto ja sama optimointikohde. Niiden analysointi yksi URL-osoite kerrallaan ei ole hyödyllistä. Niiden ryhmittely tunnisteen product-detail alle antaa sinulle yhden suorituskykyprofiilin koko tuotekatalogille.

Sivun tunniste myös erottaa toisistaan sivut, joilla on eri suorituskykybudjetit. Kassasivulla on yksi hyväksyttävä LCP-raja-arvo, koska se tuottaa suoraa tuloa. Blogikirjoituksella on eri toleranssi. Maksettua liikennettä ohjaavalla laskeutumissivulla on nollatoleranssi hitaalle LCP:lle, koska jokainen millisekunti maksaa sinulle mainoskuluja.

Kun merkitset sivut liiketoimintatoiminnon mukaan, voit asettaa CoreDashissa eri hälytysrajat kullekin tunnisteelle 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ääritä 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 heikentymisten (regressioiden) lähteistä. Variantti B tuo mukanaan uuden hero-kuvakarusellin. Variantti B lataa kolmannen osapuolen suositus-widgetin. Variantti B sisältää ylimääräisen kierroksen React-hydraatiota. Kaikki nämä tuovat mukanaan suorituskykykustannuksen, jota kokeilutyökalusi ei lähes varmasti mittaa.

Useimmat kokeilualustat seuraavat konversioasteita ja tuloja. Ne eivät seuraa p75 LCP:tä tai INP:tä. Jos variantti B konvertoi 2 % paremmin mutta latautuu mobiililaitteella 400 ms hitaammin, sinun on tiedettävä se ennen kuin julkaiset sen 100 prosentille liikenteestä. Suorituskykykustannus saattaa nollata konversiohyödyn seuraavan vuosineljänneksen aikana käyttäjien menettäessä kärsivällisyytensä.

Kun __CWAB on asetettu, avaa CoreDash, suodata asetuksella ab = variant-b, ja vertaa Core Web Vitals -arvoja rinnakkain kontrollivariantin kanssa. Olen nähnyt A/B-testejä, joissa voittaneella variantilla oli 600 ms huonompi p75 LCP kuin kontrollilla, koska se latasi raskaamman fontin. Liiketoimintatiimi näki konversion kasvun; he eivät nähneet suorituskyvyn heikentymistä. Juuri tämän tämä dimensio estää.

Kirjautumistila (li)

Kirjautumistila-dimensio tallentaa, onko nykyinen käyttäjä todennettu. Määritä se näin:

window.__CWVLI = 1; // kirjautunut sisään
window.__CWVLI = 0; // kirjautunut ulos

Miksi tällä on merkitystä

Sisäänkirjautuneet käyttäjät saavat täysin erilaisen sivun kuin anonyymit vierailijat. Heidän pyyntönsä ohittavat monet CDN-välimuistikerrokset. Palvelin suorittaa tietokantakyselyitä personoitua sisältöä varten: käyttäjän ostoskori, tilaushistoria, tallennetut tuotteet. Tuo palvelinpuolen työ lisää suoraan TTFB-aikaa.

Käyttöliittymäpuolella (frontend) todennetut sivut lataavat usein enemmän JavaScriptiä: tili-widgettejä, ilmoitusjärjestelmiä, ostoskorin reaktiivisuutta. Ne saattavat myös ohittaa esirenderöinnin tai reunan välimuistin, joka tekee anonyymeistä sivuista nopeita. Tuloksena on, että sisäänkirjautuneet käyttäjät kokevat usein hitaampaa suorituskykyä kuin anonyymit käyttäjät, vaikka sisäänkirjautuneet käyttäjät ovat tyypillisesti arvokkaimpia asiakkaitasi. He ovat jo konvertoituneet. He ovat niitä, jotka sinun on kaikkein tärkeintä pitää asiakkainasi.

Ilman li-dimensiota todennettujen käyttäjien hidas suorituskyky piiloutuu kokonaislukujesi sekaan. Anonyymi LCP saattaa olla 1,8 s, kun taas sisäänkirjautuneiden LCP on 3,4 s. Yhdistetty arvo näyttää lukemaa 2,3 s ja vaikuttaa hyväksyttävältä. Jaa data li:n mukaan, ja kuva muuttuu täysin.

Toteutus

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

// Aseta kaikki kolme sovelluksesi tilan perusteella
window.__CWVL  = 'checkout';      // sivun tunniste
window.__CWAB  = 'variant-b';     // A/B-testivariantti
window.__CWVLI = 1;               // kirjautunut sisään

Tunnisteiden arvot ovat merkkijonoja (paitsi __CWVLI, joka saa arvon 1 tai 0). Pidä ne johdonmukaisina koko koodikannassasi. Jos käytät yhdessä mallissa arvoa product-detail ja toisessa arvoa productDetail, CoreDash käsittelee niitä kahtena erillisenä segmenttinä ja datasi pirstaloituu. Valitse yksi nimeämiskäytäntö ja pitäydy siinä.

Kaikkien kolmen yhdistäminen

Todellinen arvo tulee esiin, kun yhdistät nämä dimensiot. Suoritat A/B-testiä kassasivullasi sisäänkirjautuneille käyttäjille. Haluat tietää, tekeekö variantti B todennetusta kassakokemuksesta nopeamman vai hitaamman.

Suodata CoreDashissa asetuksilla ab = variant-b plus lb = checkout plus li = 1. Tämä antaa sinulle nimenomaan todennettujen käyttäjien kassan suorituskyvyn kyseiselle variantille. Mikään muu valvontatyökalu ei nosta esiin tätä yhdistelmää ilman omaa mukautettua ohjelmointityötäsi.

Vakiona tulevat tekniset dimensiot kertovat, mitä selain koki. Mukautetut dimensiot kertovat, mitä liiketoiminta koki. 400 millisekunnin LCP:n heikentyminen tarkoittaa aivan eri asiaa maksettua liikennettä ohjaavalla landing-page-sivulla kuin blog-kirjoituksessa. Nämä erot ovat tärkeitä priorisoinnin kannalta, ja juuri priorisoinnissa suorituskykytyö joko onnistuu tai pysähtyy.