Personalisering i stor skala er mest et driftsproblem. Fem regler kan én person holde styr på. Halvtreds regler, skrevet af fire personer over et år, kan ikke. Uden en vis struktur ender du med regler, som ingen ejer, to regler, der kæmper om den samme overskrift på prissiden, og en gammel pris, der stadig vises for et segment, fordi ingen huskede, at varianten fandtes.
Dette indlæg gennemgår den struktur, der holder et voksende regelsæt håndterbart: navngivning, et register, en eksplicit prioriteringsrækkefølge ved konflikter, pladsbaserede skabeloner i stedet for specialsider, performancetjek, og hvem der ejer hvad. Intet af det er kompliceret. Det skal bare være på plads, før antallet af regler vokser, ikke efter.
Tegn på, at du er vokset ud af din nuværende opsætning
- Ingen kan sige, hvad en given besøgende ser. Nogen spørger »hvad ser en besøgende fra en stor sundhedsvirksomhed på forsiden?«, og for at svare skal man åbne flere regler, måske i mere end ét værktøj.
- Konflikter afgøres tilfældigt. To regler målretter det samme element for overlappende segmenter, og hvilken der vinder, afhænger af indlæsningsrækkefølge eller oprettelsesdato i stedet for en beslutning, nogen har truffet.
- Indholdsændringer bliver til søgninger. En ændring af en pris eller et produktnavn betyder, at du skal lede gennem alle varianter for at finde, hvor den gamle formulering står.
- Siderne blev langsommere eller begyndte at flimre, efterhånden som der kom flere regler, og ingen bemærkede hvornår.
- Testningen er gået i stå, fordi vedligeholdelsen af de eksisterende regler tager al den tid, der er.
At skære ned på antallet af regler er nogle gange det rigtige svar, især når mange aldrig er blevet målt. Oftere er reglerne fine, og det, der mangler, er en måde at se og styre dem på.
Navngiv regler, så navnet forklarer reglen
Vælg ét mønster, og brug det overalt. Et, der virker: niveau, segment, side, element og version, forbundet med bindestreger i den rækkefølge:
tier-segment-page-element-version
T1-acme-corp-homepage-hero-v2T2-enterprise-healthcare-pricing-proof-v1T3-returning-visitor-blog-cta-v3
Tier-præfikset hænger sammen med konfliktrækkefølgen, der er beskrevet nedenfor. Resten gør, at alle, der læser en liste med regler, kan se, hvad hver gør uden at åbne den. Filtrér på side, så har du alle regler, der kan påvirke den side; filtrér på segment, så har du alt, hvad et segment ser.
Før et register
Et regneark er nok. Én række pr. aktiv regel med disse kolonner:
| Kolonne | Hvorfor det er der |
|---|---|
| Regelnavn | Matcher navnet i værktøjet nøjagtigt |
| Formål | Én sætning: »Vis cases fra sundhedssektoren til besøgende fra sundhedssektoren for at øge antallet af demoanmodninger« |
| Ejer | Den person, du skal spørge, og den person, der opdaterer det |
| Segmentdefinition | De faktiske betingelser, så overlap er synlige |
| Side og element | Hvor det ændrer indhold |
| Fakta, den indeholder | Priser, plannavne, kundenavne, produktnavne; det er den kolonne, du søger i, når noget af det ændrer sig |
| Holdout-/teststatus | Målt, ved at blive målt eller aldrig målt |
| Senest gennemgået | Dato |
Tilføj to vaner omkring det. Nye regler går gennem en kort anmodning til den person, der ejer registret (en Slack-besked er fin), hvilket fanger dubletter, før de går live. Og gennemgå listen hvert kvartal: udfas regler, der ikke har vist nogen effekt efter en fuld test, opdatér forældet indhold, og flet regler, der gør det samme for overlappende segmenter. Vores skabelon til personaliseringsplaybook kan fungere som register, hvis du ikke vil bygge dit eget; den har en kolonne til prioritet ved overlap.
Afgør konflikter, før de opstår
En tilbagevendende besøgende fra en stor virksomhed i sundhedssektoren på en liste over målkonti kan på én gang matche en kontoregel, en regel for branche plus størrelse, en brancheregel og en regel for tilbagevendende besøgende. Hvis de alle er rettet mod hero-sektionen, må noget afgøre det. Gør det til en eksplicit rækkefølge:
- Tier 1: regler for navngivne konti. Alt, der er bygget til en specifik konto eller kontoliste, vinder. De er de mest specifikke og som regel knyttet til en aktiv salgsdialog.
- Niveau 2: sammensatte segmenter. Regler, der kombinerer to eller flere egenskaber (enterprise + sundhed), slår regler med én egenskab, fordi nogen har besluttet, at den kombination fortjente sit eget budskab.
- Niveau 3: regler med én attribut. "Alle enterprise-besøgende", "alle besøgende fra USA". Reserveløsninger.
- Standardside. Det, alle andre ser, og det, crawlere ser.
Inden for et niveau må "senest opdateret" eller indlæsningsrækkefølgen ikke afgøre det. Giv hver regel på et niveau et eksplicit rangnummer i registret, eller endnu bedre: Undgå regler på samme niveau på samme element for overlappende segmenter i første omgang. Tavse tiebreakers er måden, hvorpå en besøgende ender med at se en variant, som ingen havde tænkt sig.
Konflikter kan også undgås pr. element. Hvis account-regler ejer heroen, og brancheregler ejer bevisblokken, får en besøgende, der matcher begge, begge dele uden konflikt. Det er den enkleste løsning og værd at prøve først.
Skabeloner og slots i stedet for specialsider
Mønstret, der gør et stort regelsæt overkommeligt: lås sidens layout, og definér nogle få pladser, der kan personaliseres. En regel udfylder pladser; den redesigner ikke siden.
Eksempler på slots for en B2B-forside:
- Hero-overskrift (med en tegngrænse, så varianterne passer på mobil)
- Underoverskrift i hero
- Bevisblok: en logorække og ét citat
- Primær CTA-tekst og destination
- Fremhævet case
At oprette en variant betyder så at skrive tekst til fem felter og vælge en case – noget en marketingmedarbejder kan gøre uden design- eller udviklertid. Det gør også registret nyttigt: Du ved præcis, hvilke felter en regel kan ændre.
Afvejningen er reel. Din sundhedsvariant og din fintech-variant kommer til at ligne hinanden, fordi de deler layout. For de fleste B2B-websites er det acceptabelt, da det er budskabet, der ændrer sig pr. segment. Gem den fuldt skræddersyede behandling til en kort liste over navngivne konti, hvor aftalestørrelsen retfærdiggør det ekstra arbejde, og acceptér, at de sider kræver deres egen vedligeholdelse.
Hold øje med performance, efterhånden som der tilføjes regler
Hvor meget et regelsæt koster i hastighed, afhænger af, hvor beslutningen træffes. En beslutning på serveren eller i edge tilføjer arbejde, før siden sendes; et client-side-script tilføjer arbejde, efter siden er renderet, og kan give flimmer. Uanset hvad: mål i stedet for at antage:
- Largest Contentful Paint og flimmer på personaliserede sider. Sammenlign en personaliseret variant med standardsiden i PageSpeed Insights eller en labtest med en neddroslet mobilprofil. Hvis den personaliserede hero er LCP-elementet og vises senere, end standardversionen ville, sker beslutningen for sent.
- Beslutningstid fra personaliseringsværktøjet. De fleste værktøjer logger, hvor lang tid en beslutning tager. Følg den over tid, og se på, hvad der ændrede sig, hver gang den springer op.
- Fallback-rate. Hvor ofte en regel fejler, og standardversionen vises i stedet. En stille fallback er bedre end en ødelagt side, men en høj rate betyder, at besøgende ikke får det, registret siger, de får.
Registrér en baseline, før hver ny omgang regler går live, så en forringelse kan kobles til den ændring, der forårsagede den. Overvågning af Core Web Vitals i dit RUM-værktøj eller Search Console markerer vedvarende problemer, men først når nok rigtig trafik er blevet påvirket.
Hvem ejer hvad
| Rolle | Ansvarsområder | Ofte varetaget af |
|---|---|---|
| Ejer af personalisering | Register, navngivning, konfliktrækkefølge, kvartalsvis review, sidste ord om nye regler | Marketing ops- eller growth-ansvarlig |
| Indholdsproducenter | At skrive tekst til pladserne pr. segment og holde fakta opdaterede | Produktmarketing, indholdsteam |
| Teknisk implementør | Opsætning af regler, fejlfinding i konflikter, performancetjek | Webudvikler eller en teknisk marketingmedarbejder, afhængigt af værktøjet |
| Analytiker | Holdouts, resultater pr. regel, markering af regler, der skal udfases | Marketinganalytiker (se karrierer inden for marketinganalyse for, hvad jobbet indebærer) |
I små teams har en eller to personer alle fire roller, hvilket er fint, så længe registret findes, for så kan en anden person tage over. Ejerrollen er den, der ikke må deles vagt: hvis alle ejer regelsættet, udfaser ingen noget. For RACI, udrulningsfaser og governance i større organisationer, se playbooken til udrulning af personalisering i store virksomheder.
Mål regler, ikke kun programmet
En holdout på programniveau fortæller dig, at personalisering som helhed er værd at beholde. Den fortæller dig ikke, hvilke af 50 regler der gør arbejdet. Giv hver regel på niveau 2 og 3 sin egen holdout eller A/B-test, når trafikken tillader det, og marker regler, der ikke kan nå en læsbar stikprøve, som "ikke målt" i registret i stedet for at antage, at de hjælper. Vores indlæg om måling af ROI på personalisering dækker dimensionering af holdouts og metrikhierarkiet.
Tjekliste, før antallet af regler vokser
- En navngivningskonvention, som alle bruger
- Et register med ejer, formål, segment, fakta og teststatus for hver regel
- En skriftlig prioriteringsrækkefølge ved konflikter plus ejerskab af elementer pr. niveau
- Slot-skabeloner til mindst forsiden og prissiden
- En performance-baseline og et tjek efter hver omgang regler
- Én navngiven ejer og en dato for den næste kvartalsvise gennemgang
Et praktisk første skridt: Eksportér alle aktive regler fra dit værktøj til registerformatet ovenfor. Enhver regel, du ikke kan udfylde (ingen kendt ejer, intet angivet formål, ingen idé om, hvorvidt den virker), kommer på listen til første review. Hvis du sætter det op i Markettailor, holder dens segmentering segmentdefinitionerne samlet ét sted, hvilket gør overlap mellem regler nemmere at få øje på.