Personalisering i stor skala er i hovedsak et driftsproblem. Fem regler får plass i hodet til én person. Femti regler, skrevet av fire personer i løpet av et år, gjør det ikke. Uten en viss struktur ender du opp med regler ingen eier, to regler som slåss om den samme overskriften på prissiden, og en gammel pris som fortsatt vises for ett segment fordi ingen husket at den varianten fantes.
Dette innlegget dekker strukturen som holder et voksende regelsett håndterbart: navngivning, et register, en eksplisitt prioriteringsrekkefølge ved konflikter, plassbaserte maler i stedet for spesialsider, ytelsessjekker og hvem som eier hva. Ingenting av det er komplisert. Det må bare være på plass før antall regler vokser, ikke etterpå.
Tegn på at du har vokst ut av dagens oppsett
- Ingen kan si hva en gitt besøkende ser. Noen spør «hva ser en enterprise-besøkende fra helse på forsiden?», og for å svare må man åpne flere regler, kanskje i mer enn ett verktøy.
- Konflikter avgjøres tilfeldig. To regler retter seg mot samme element for overlappende segmenter, og hvilken som vinner, avhenger av lasterekkefølge eller opprettelsesdato i stedet for en beslutning noen har tatt.
- Innholdsendringer blir til søkeoppdrag. En endring i pris eller produktnavn betyr at du må lete gjennom alle varianter for å finne hvor den gamle formuleringen står.
- Sidene ble tregere eller begynte å flimre etter hvert som regler ble lagt til, og ingen la merke til når.
- Testingen stoppet fordi vedlikehold av eksisterende regler tar all tilgjengelig tid.
Å kutte antall regler er noen ganger riktig svar, særlig når mange aldri har blitt målt. Oftere er reglene greie, og det som mangler, er en måte å se og styre dem på.
Navngi regler slik at navnet forklarer regelen
Velg ett mønster og bruk det overalt. Et som fungerer: nivå, segment, side, element og versjon, satt sammen med bindestrek i den rekkefølgen:
tier-segment-page-element-version
T1-acme-corp-homepage-hero-v2T2-enterprise-healthcare-pricing-proof-v1T3-returning-visitor-blog-cta-v3
Nivåprefikset henger sammen med konfliktrekkefølgen som er beskrevet nedenfor. Resten gjør at alle som leser en liste over regler, kan se hva hver av dem gjør uten å åpne den. Filtrer på side, og du har alle reglene som kan påvirke den siden; filtrer på segment, og du har alt et segment ser.
Før et register
Et regneark er nok. Én rad per aktiv regel, med disse kolonnene:
| Kolonne | Hvorfor det er der |
|---|---|
| Regelnavn | Samsvarer nøyaktig med navnet i verktøyet |
| Formål | Én setning: «Vis kundecaser fra helsesektoren til besøkende fra helsesektoren for å øke antall demoforespørsler» |
| Eier | Personen du skal spørre, og personen som oppdaterer det |
| Segmentdefinisjon | De faktiske betingelsene, så overlapp blir synlige |
| Side og element | Hvor det endrer innhold |
| Fakta den inneholder | Priser, plannavn, kundenavn, produktnavn; dette er kolonnen du søker i når noe av dette endres |
| Kontrollgruppe / teststatus | Målt, under måling eller aldri målt |
| Sist gjennomgått | Dato |
Legg til to vaner rundt det. Nye regler går gjennom en kort forespørsel til den som eier registeret (en Slack-melding holder), som fanger opp duplikater før de lanseres. Og hvert kvartal går du gjennom listen: avvikle regler som ikke har vist noen effekt etter en full test, oppdater utdatert innhold og slå sammen regler som gjør samme jobb for overlappende segmenter. Malen vår for personaliserings-playbook kan fungere som register hvis du ikke vil bygge ditt eget; den har en kolonne for prioritet ved overlapp.
Avgjør konflikter før de oppstår
En gjenkommende besøkende fra et stort helseselskap på en liste over målkontoer kan matche en kontoregel, en regel for bransje pluss størrelse, en bransjeregel og en regel for gjenkommende besøkende på én gang. Hvis alle retter seg mot hero-seksjonen, må noe avgjøre. Gjør det til en eksplisitt rekkefølge:
- Nivå 1: regler for navngitte kontoer. Alt som er laget for en bestemt konto eller kontoliste, vinner. Disse er de mest spesifikke og er vanligvis knyttet til en aktiv salgsdialog.
- Nivå 2: sammensatte segmenter. Regler som kombinerer to eller flere egenskaper (enterprise + helse) går foran regler med én egenskap, fordi noen har bestemt at den kombinasjonen fortjente sitt eget budskap.
- Tier 3: regler med ett attributt. «Alle besøkende fra store virksomheter», «alle besøkende fra USA». Reserveløsninger.
- Standardside. Det alle andre ser, og det crawlere ser.
Innenfor et nivå bør du ikke la «sist oppdatert» eller innlastingsrekkefølge avgjøre. Gi hver regel på et nivå et eksplisitt rangnummer i registeret, eller enda bedre: unngå regler på samme nivå for samme element for overlappende segmenter i utgangspunktet. Stille avgjørelser ved likhet er hvordan en besøkende ender opp med å se en variant ingen hadde tenkt.
Konflikter kan også unngås per element. Hvis kontoreglene eier toppseksjonen og bransjereglene eier bevisblokken, får en besøkende som treffer begge, begge deler, uten konflikt. Dette er den enkleste løsningen og verdt å prøve først.
Maler og plasser i stedet for skreddersydde sider
Mønsteret som gjør et stort regelsett overkommelig: lås sideoppsettet og definer noen få plasser som kan personaliseres. En regel fyller plasser; den redesigner ikke siden.
Eksempler på innholdsplasser for en B2B-forside:
- Hero-overskrift (med tegnbegrensning, slik at variantene passer på mobil)
- Hero-underoverskrift
- Bevisblokk: en logorad og ett sitat
- Etikett og mål for primær CTA
- Fremhevet kundecase
Å lage en variant betyr da å skrive tekst til fem felt og velge en kundecase, noe en markedsfører kan gjøre uten tid fra design eller utvikling. Det gjør også registeret nyttig: du vet nøyaktig hvilke felt en regel kan endre.
Avveiningen er reell. Helsevarianten og fintech-varianten din vil ligne på hverandre fordi de deler oppsett. For de fleste B2B-nettsteder er det akseptabelt, siden det er budskapet som endres per segment. Spar helt skreddersydd behandling til en kort liste over navngitte kontoer der avtalestørrelsen forsvarer ekstraarbeidet, og godta at disse sidene trenger eget vedlikehold.
Følg med på ytelsen etter hvert som regler legges til
Hvor mye et regelsett koster i hastighet, avhenger av hvor beslutningen tas. En beslutning på serversiden eller i edge legger til arbeid før siden sendes; et skript på klientsiden legger til arbeid etter at siden er gjengitt og kan gi flimring. Uansett bør du måle i stedet for å anta:
- Largest Contentful Paint og flimmer på personaliserte sider. Sammenlign en personalisert variant med standardsiden i PageSpeed Insights eller en labtest, på en strupet mobilprofil. Er den personaliserte heroen LCP-elementet og vises senere enn standardversjonen ville gjort, skjer beslutningen for sent.
- Beslutningstid fra personaliseringsverktøyet. De fleste verktøy logger hvor lang tid en beslutning tar. Følg den over tid, og se på hva som endret seg hver gang den hopper.
- Reserverate. Hvor ofte en regel feiler og standardversjonen vises i stedet. En stille reserveløsning er bedre enn en ødelagt side, men en høy rate betyr at besøkende ikke får det registeret sier at de får.
Registrer et utgangspunkt før hver runde med nye regler går live, slik at en forverring kan knyttes til endringen som forårsaket den. Overvåking av Core Web Vitals i RUM-verktøyet ditt eller Search Console vil flagge vedvarende problemer, men først etter at nok ekte trafikk er berørt.
Hvem eier hva
| Rolle | Ansvarsområder | Ofte innehatt av |
|---|---|---|
| Eier av personaliseringen | Register, navngiving, konfliktrekkefølge, kvartalsvis gjennomgang, siste ord om nye regler | Marketing ops- eller vekstansvarlig |
| Innholdsprodusenter | Skrive tekst til plassene per segment og holde fakta oppdatert | Produktmarkedsføring, innholdsteam |
| Teknisk implementør | Sette opp regler, feilsøke konflikter, ytelsessjekker | Webutvikler eller en teknisk markedsfører, avhengig av verktøyet |
| Analytiker | Kontrollgrupper, resultater per regel, flagging av regler som skal fases ut | Markedsanalytiker (se karriere innen markedsanalyse for hva den jobben innebærer) |
I små team har én eller to personer alle fire rollene, og det er greit så lenge registeret finnes, for da kan en annen person ta over arbeidet. Eierrollen er den som ikke kan deles på en vag måte: hvis alle eier regelsettet, avvikler ingen noe. For RACI, utrullingsfaser og styring i større organisasjoner, se playbook for utrulling av personalisering i store virksomheter.
Mål reglene, ikke bare programmet
En kontrollgruppe på programnivå forteller deg at personaliseringen som helhet er verdt å beholde. Den forteller deg ikke hvilke av femti regler som gjør jobben. Gi hver regel på nivå 2 og 3 sin egen kontrollgruppe eller A/B-test når trafikken tillater det, og merk regler som ikke kan nå et lesbart utvalg som «ikke målt» i registeret i stedet for å anta at de hjelper. Innlegget vårt om måling av ROI på personalisering dekker størrelse på kontrollgrupper og måltallshierarkiet.
Sjekkliste før antallet regler vokser
- Et navnemønster alle bruker
- Et register med eier, formål, segment, fakta og teststatus for hver regel
- En skriftlig konfliktrekkefølge, pluss eierskap til elementer per nivå
- Slotmaler for minst forsiden og prissiden
- Et ytelsesutgangspunkt og en sjekk etter hver runde med regler
- Én navngitt eier og en dato for neste kvartalsvise gjennomgang
Et praktisk første steg: eksporter alle aktive regler fra verktøyet ditt til registerformatet over. Enhver regel du ikke kan fylle ut (ingen kjent ansvarlig, ingen oppgitt hensikt, ingen anelse om den virker) havner på listen til første gjennomgang. Hvis du setter dette opp i Markettailor, holder segmenteringen segmentdefinisjonene samlet på ett sted, noe som gjør det lettere å oppdage overlapp mellom regler.