Personointi laajassa mittakaavassa on enimmäkseen operatiivinen ongelma. Viisi sääntöä mahtuu yhden ihmisen päähän. Viisikymmentä sääntöä, jotka neljä ihmistä on kirjoittanut vuoden aikana, ei mahdu. Ilman rakennetta päädyt sääntöihin, joilla ei ole omistajaa, kahteen sääntöön, jotka kamppailevat samasta hinnoittelusivun otsikosta, ja vanhaan hintaan, joka näkyy yhä yhdelle segmentille, koska kukaan ei muistanut variantin olemassaoloa.
Tämä kirjoitus käsittelee rakennetta, joka pitää kasvavan sääntöjoukon hallittavana: nimeäminen, rekisteri, eksplisiittinen prioriteettijärjestys ristiriidoille, paikkapohjaiset sivupohjat räätälöityjen sivujen sijaan, suorituskykytarkistukset ja vastuunjako. Mikään siitä ei ole monimutkaista. Sen täytyy vain olla olemassa ennen kuin sääntöjen määrä kasvaa, ei sen jälkeen.
Merkit siitä, että olet kasvanut nykyisestä ratkaisustasi ulos
- Kukaan ei osaa sanoa, mitä tietty kävijä näkee. Joku kysyy "mitä enterprise-tason terveydenhuollon kävijä näkee etusivulla?", ja vastaaminen vaatii useiden sääntöjen avaamista, mahdollisesti useammassa kuin yhdessä työkalussa.
- Konfliktit ratkeavat sattumalta. Kaksi sääntöä kohdistuu samaan elementtiin päällekkäisille segmenteille, ja voittaja riippuu latausjärjestyksestä tai luontipäivästä eikä kenenkään tekemästä päätöksestä.
- Sisältömuutoksista tulee etsintää. Hinnan tai tuotenimen muutos tarkoittaa jokaisen version läpikäymistä vanhan sanamuodon löytämiseksi.
- Sivut hidastuivat tai alkoivat välkkyä sääntöjen lisääntyessä, eikä kukaan huomannut milloin.
- Testaus loppui, koska olemassa olevien sääntöjen ylläpito vie kaiken käytettävissä olevan ajan.
Sääntöjen määrän vähentäminen on joskus oikea ratkaisu, varsinkin kun monia niistä ei ole koskaan mitattu. Useammin säännöt ovat kunnossa, ja puuttuva palanen on tapa nähdä ja hallita niitä.
Nimeä säännöt niin, että nimi selittää säännön
Valitse yksi kaava ja käytä sitä kaikkialla. Yksi toimiva: taso, segmentti, sivu, elementti ja versio väliviivoilla yhdistettynä tässä järjestyksessä:
tier-segment-page-element-version
T1-acme-corp-homepage-hero-v2T2-enterprise-healthcare-pricing-proof-v1T3-returning-visitor-blog-cta-v3
Tasoetuliite liittyy alla kuvattuun konfliktijärjestykseen. Loput antavat kenen tahansa sääntölistaa lukevan nähdä, mitä kukin tekee avaamatta sitä. Suodata sivun mukaan, niin näet kaikki säännöt, jotka voivat koskea sitä sivua; suodata segmentin mukaan, niin näet kaiken, mitä segmentti näkee.
Pidä rekisteriä
Taulukko riittää. Yksi rivi jokaista aktiivista sääntöä kohden näillä sarakkeilla:
| Sarake | Miksi se on siellä |
|---|---|
| Säännön nimi | Vastaa työkalussa olevaa nimeä täsmälleen |
| Tarkoitus | Yksi lause: ”Näytä terveydenhuollon asiakastarinoita terveydenhuollon kävijöille demopyyntöjen lisäämiseksi” |
| Omistaja | Henkilö, jolta kysyä, ja henkilö, joka päivittää sen |
| Segmentin määritelmä | Todelliset ehdot, jotta päällekkäisyydet näkyvät |
| Sivu ja elementti | Missä se muuttaa sisältöä |
| Sisältämät tiedot | Hinnat, pakettien nimet, asiakkaiden nimet, tuotenimet; tästä sarakkeesta haet, kun jokin niistä muuttuu |
| Verrokkiryhmän / testin tila | Mitattu, mittauksessa tai ei koskaan mitattu |
| Viimeksi tarkistettu | Päivämäärä |
Lisää sen ympärille kaksi tapaa. Uudet säännöt kulkevat lyhyen pyynnön kautta rekisterin omistajalle (Slack-viesti riittää), mikä nappaa kaksoiskappaleet ennen julkaisua. Ja käy lista läpi joka vuosineljännes: poista säännöt, jotka eivät ole osoittaneet vaikutusta täyden testin jälkeen, päivitä vanhentunut sisältö ja yhdistä säännöt, jotka tekevät saman työn päällekkäisille segmenteille. Personoinnin pelikirjan pohjamme voi toimia rekisterinä, jos et halua rakentaa omaa; siinä on sarake päällekkäisyyksien prioriteetille.
Ratkaise ristiriidat ennen kuin niitä syntyy
Kohdeasiakaslistalla olevan suuren terveydenhuoltoyrityksen palaava kävijä voi osua samanaikaisesti asiakassääntöön, toimiala-plus-koko-sääntöön, toimialasääntöön ja palaavan kävijän sääntöön. Jos ne kaikki kohdistuvat heroon, jonkin on ratkaistava. Tee siitä selkeä järjestys:
- Taso 1: nimettyjen yritysten säännöt. Kaikki tietylle yritykselle tai yrityslistalle rakennettu voittaa. Nämä ovat tarkimpia ja liittyvät yleensä käynnissä olevaan myyntikeskusteluun.
- Taso 2: yhdistelmäsegmentit. Kahta tai useampaa ominaisuutta yhdistävät säännöt (enterprise + terveydenhuolto) voittavat yhden ominaisuuden säännöt, koska joku päätti, että tuo yhdistelmä ansaitsee oman viestinsä.
- Taso 3: yhden ominaisuuden säännöt. ”Kaikki enterprise-kävijät”, ”kaikki kävijät Yhdysvalloista”. Varavaihtoehtoja.
- Oletussivu. Mitä kaikki muut näkevät ja mitä hakurobotit näkevät.
Älä anna saman tason sisällä ”viimeksi päivitetyn” tai latausjärjestyksen ratkaista. Anna jokaiselle tason säännölle rekisterissä eksplisiittinen järjestysnumero, tai mieluummin vältä alun perin saman tason sääntöjä samalle elementille päällekkäisille segmenteille. Hiljaiset ratkaisusäännöt ovat syy siihen, että vierailija päätyy näkemään variantin, jota kukaan ei tarkoittanut.
Ristiriidat voi välttää myös elementeittäin. Jos yrityssäännöt omistavat hero-osion ja toimialasäännöt todisteosion, kävijä, joka täyttää molemmat, saa molemmat ilman konfliktia. Tämä on yksinkertaisin ratkaisu ja kannattaa kokeilla ensin.
Mallipohjat ja paikat räätälöityjen sivujen sijaan
Malli, joka tekee suuresta sääntökokonaisuudesta kustannustehokkaan: lukitse sivun asettelu ja määrittele muutama personoitava paikka. Sääntö täyttää paikkoja; se ei suunnittele sivua uudelleen.
Esimerkkipaikat B2B-etusivulle:
- Hero-otsikko (merkkirajalla, jotta versiot mahtuvat mobiiliin)
- Hero-osion alaotsikko
- Todisteosio: logorivi ja yksi lainaus
- Ensisijaisen CTA:n teksti ja kohde
- Nostettu asiakastarina
Uuden version luominen tarkoittaa silloin tekstin kirjoittamista viiteen kenttään ja asiakastarinan valitsemista, minkä markkinoija pystyy tekemään ilman suunnittelijan tai kehittäjän aikaa. Se tekee myös rekisteristä hyödyllisen: tiedät tarkalleen, mitä kenttiä sääntö voi muuttaa.
Kompromissi on todellinen. Terveydenhuollon ja fintechin versiosi näyttävät samankaltaisilta, koska ne jakavat asettelun. Useimmille B2B-sivustoille se on hyväksyttävää, koska segmentin mukaan muuttuu viesti. Varaa täysin räätälöity käsittely lyhyelle listalle nimettyjä yrityksiä, joiden kaupan koko oikeuttaa lisätyön, ja hyväksy, että niiden sivut vaativat oman ylläpitonsa.
Seuraa suorituskykyä sääntöjä lisättäessä
Kuinka paljon sääntökokonaisuus maksaa nopeudessa, riippuu siitä, missä päätös tehdään. Palvelin- tai edge-päätös lisää työtä ennen sivun lähettämistä; selainpuolen skripti lisää työtä sivun renderöinnin jälkeen ja voi aiheuttaa välkkymistä. Kummassakin tapauksessa mittaa äläkä oleta:
- Largest Contentful Paint ja välkkyminen personoiduilla sivuilla. Vertaa personoitua varianttia oletussivuun PageSpeed Insightsissa tai laboratoriotestissä hidastetulla mobiiliprofiililla. Jos personoitu hero on LCP-elementti ja ilmestyy myöhemmin kuin oletus ilmestyisi, päätös tehdään liian myöhään.
- Personointityökalun päätösaika. Useimmat työkalut kirjaavat, kuinka kauan päätös kestää. Seuraa sitä ajan mittaan ja katso, mikä muuttui aina, kun se hyppää.
- Varavaihtoehdon osuus. Kuinka usein sääntö epäonnistuu ja tilalle näytetään oletus. Hiljainen varavaihtoehto on parempi kuin rikkinäinen sivu, mutta korkea osuus tarkoittaa, että kävijät eivät saa sitä, mitä rekisteri sanoo heidän saavan.
Kirjaa lähtötaso ennen jokaisen uuden sääntöerän julkaisua, jotta heikentyminen voidaan yhdistää sen aiheuttaneeseen muutokseen. Core Web Vitals -seuranta RUM-työkalussasi tai Search Consolessa ilmoittaa pitkäkestoisista ongelmista, mutta vasta kun riittävästi todellista liikennettä on jo kärsinyt.
Kuka omistaa mitäkin
| Rooli | Vastuut | Usein roolissa |
|---|---|---|
| Personoinnin omistaja | Rekisteri, nimeäminen, konfliktijärjestys, neljännesvuosikatselmus, viimeinen sana uusista säännöistä | Markkinoinnin operatiivinen vetäjä tai kasvun vetäjä |
| Sisällöntuottajat | Paikkojen tekstien kirjoittaminen segmenteittäin, faktojen pitäminen ajan tasalla | Tuotemarkkinointi, sisältötiimi |
| Tekninen toteuttaja | Sääntöjen asetus, ristiriitojen selvittäminen, suorituskykytarkistukset | Verkkokehittäjä tai tekninen markkinoija työkalusta riippuen |
| Analyytikko | Vertailuryhmät, sääntökohtaiset tulokset, käytöstä poistettavien sääntöjen merkitseminen | Markkinointianalyytikko (katso markkinointianalytiikan urat, mitä työ pitää sisällään) |
Pienissä tiimeissä yksi tai kaksi ihmistä hoitaa kaikki neljä roolia, mikä on kunnossa, kunhan rekisteri on olemassa, koska silloin toinen henkilö voi ottaa työn hoitaakseen. Omistajan roolia ei voi jakaa epämääräisesti: jos kaikki omistavat sääntökokonaisuuden, kukaan ei poista mitään. RACI-mallia, käyttöönoton vaiheita ja hallintaa suuremmissa organisaatioissa käsittelee enterprise-personoinnin käyttöönoton pelikirja.
Mittaa sääntöjä, älä vain ohjelmaa
Ohjelmatason kontrolliryhmä kertoo, että personointi kokonaisuutena kannattaa säilyttää. Se ei kerro, mitkä viidestäkymmenestä säännöstä tekevät työn. Anna jokaiselle tason 2 ja 3 säännölle oma kontrolliryhmänsä tai A/B-testinsä, kun liikenne riittää, ja merkitse rekisteriin "mittaamaton" säännöt, jotka eivät saavuta luotettavaa otosta, sen sijaan että olettaisit niiden auttavan. Artikkelimme personoinnin ROI:n mittaamisesta käsittelee kontrolliryhmän mitoitusta ja mittarihierarkiaa.
Tarkistuslista ennen kuin sääntöjen määrä kasvaa
- Nimeämiskäytäntö, jota kaikki noudattavat
- Rekisteri, jossa on omistaja, tarkoitus, segmentti, faktat ja testin tila jokaiselle säännölle
- Kirjallinen ristiriitojen ratkaisujärjestys sekä elementtien omistajuus tasoittain
- Paikkapohjat vähintään etusivulle ja hinnoittelusivulle
- Suorituskyvyn lähtötaso ja tarkistus jokaisen sääntöerän jälkeen
- Yksi nimetty omistaja ja päivämäärä seuraavalle neljännesvuositarkastelulle
Käytännöllinen ensimmäinen askel: vie jokainen aktiivinen sääntö työkalustasi yllä olevaan rekisterimuotoon. Jokainen sääntö, jota et pysty täyttämään (ei tunnettua omistajaa, ei kirjattua tarkoitusta, ei tietoa toimiiko se), menee ensimmäisen katselmuksen listalle. Jos otat tämän käyttöön Markettailorissa, sen segmentointi pitää segmenttimääritelmät yhdessä paikassa, mikä helpottaa sääntöjen päällekkäisyyksien havaitsemista.