Personalisering i stor skala är främst en driftsfråga. Fem regler ryms i en persons huvud. Femtio regler, skrivna av fyra personer under ett år, gör det inte. Utan någon struktur får du regler som ingen äger, två regler som slåss om samma rubrik på prissidan och ett gammalt pris som fortfarande visas för ett segment eftersom ingen kom ihåg att varianten fanns.
Det här inlägget går igenom den struktur som gör en växande regeluppsättning hanterbar: namngivning, ett register, en uttrycklig prioritetsordning vid konflikter, platsbaserade mallar i stället för specialbyggda sidor, prestandakontroller och vem som äger vad. Inget av det är komplicerat. Det måste bara finnas innan antalet regler växer, inte efteråt.
Tecken på att du har vuxit ur din nuvarande lösning
- Ingen kan säga vad en viss besökare ser. Någon frågar ”vad ser en enterprise-besökare från vården på startsidan?” och för att svara måste man öppna flera regler, kanske i mer än ett verktyg.
- Konflikter avgörs av en slump. Två regler riktar sig mot samma element för överlappande segment, och vilken som vinner beror på laddningsordning eller skapandedatum snarare än ett beslut någon har fattat.
- Innehållsändringar blir sökjakter. Ett ändrat pris eller produktnamn innebär att du måste leta igenom varje variant för att hitta var den gamla formuleringen finns.
- Sidorna blev långsammare eller började flimra i takt med att regler lades till, och ingen märkte när.
- Testandet upphörde eftersom underhållet av befintliga regler tar all tillgänglig tid.
Att minska antalet regler är ibland rätt svar, särskilt när många aldrig har mätts. Oftare är reglerna bra och det som saknas är ett sätt att se och styra dem.
Namnge regler så att namnet förklarar regeln
Välj ett mönster och använd det överallt. Ett som fungerar: nivå, segment, sida, element och version, sammanfogade med bindestreck i den ordningen:
tier-segment-page-element-version
T1-acme-corp-homepage-hero-v2T2-enterprise-healthcare-pricing-proof-v1T3-returning-visitor-blog-cta-v3
Nivåprefixet hänger ihop med konfliktordningen som beskrivs nedan. Resten gör att alla som läser en lista med regler kan se vad varje regel gör utan att öppna den. Filtrera på sida så har du alla regler som kan påverka den sidan; filtrera på segment så har du allt ett segment ser.
För ett register
Ett kalkylark räcker. En rad per aktiv regel, med de här kolumnerna:
| Kolumn | Varför det finns där |
|---|---|
| Regelnamn | Matchar namnet i verktyget exakt |
| Syfte | En mening: ”Visa kundcase från vården för besökare från vården för att öka demoförfrågningarna” |
| Ägare | Personen att fråga, och personen som uppdaterar det |
| Segmentdefinition | De faktiska villkoren, så att överlapp syns |
| Sida och element | Var det ändrar innehåll |
| Fakta den innehåller | Priser, plannamn, kundnamn, produktnamn; det här är kolumnen du söker i när något av dem ändras |
| Kontrollgrupp / teststatus | Mätt, mäts eller aldrig mätt |
| Senast granskad | Datum |
Lägg till två vanor runt det. Nya regler går via en kort förfrågan till den som äger registret (ett Slack-meddelande räcker), vilket fångar dubbletter innan de går live. Och varje kvartal går du igenom listan: avveckla regler som inte har visat någon effekt efter ett fullständigt test, uppdatera inaktuellt innehåll och slå ihop regler som gör samma jobb för överlappande segment. Vår mall för personaliseringsplaybook kan fungera som register om du inte vill bygga ett eget; den har en kolumn för prioritet vid överlapp.
Avgör konflikter innan de uppstår
En återkommande besökare från ett stort vårdföretag på en lista över målkonton kan matcha en kontoregel, en regel för bransch plus storlek, en branschregel och en regel för återkommande besökare samtidigt. Om alla riktar sig mot heron måste något avgöra. Gör det till en uttalad ordning:
- Nivå 1: regler för namngivna konton. Allt som är byggt för ett specifikt konto eller en kontolista vinner. De är de mest specifika och hör oftast ihop med en pågående säljdialog.
- Nivå 2: sammansatta segment. Regler som kombinerar två eller fler attribut (enterprise + vård) går före regler med ett attribut, eftersom någon har bestämt att den kombinationen förtjänar ett eget budskap.
- Nivå 3: regler med ett enda attribut. ”Alla enterprise-besökare”, ”alla besökare från USA”. Reservlägen.
- Standardsida. Det som alla andra ser, och det som sökrobotar ser.
Låt inte ”senast uppdaterad” eller laddningsordningen avgöra inom en nivå. Ge varje regel i en nivå ett uttryckligt rangnummer i registret, eller ännu bättre, undvik redan från början regler på samma nivå för samma element för överlappande segment. Tysta avgöranden är hur en besökare till slut ser en variant som ingen avsåg.
Konflikter kan också undvikas per element. Om kontoregler äger hero-sektionen och branschregler äger bevisblocket får en besökare som matchar båda båda, utan konflikt. Det är den enklaste lösningen och värd att prova först.
Mallar och platser i stället för specialbyggda sidor
Mönstret som gör en stor regeluppsättning överkomlig: lås sidlayouten och definiera några platser som kan personaliseras. En regel fyller platser; den gör inte om sidans design.
Exempel på innehållsytor för en B2B-startsida:
- Herorubrik (med teckengräns, så att varianterna får plats på mobilen)
- Underrubrik i hero
- Bevisblock: en logotyprad och ett citat
- Primär CTA: text och destination
- Utvalt kundcase
Att skapa en variant innebär då att skriva text för fem fält och välja ett kundcase, något en marknadsförare kan göra utan tid från design eller utveckling. Det gör också registret användbart: du vet exakt vilka fält en regel kan ändra.
Kompromissen är verklig. Din variant för vården och din variant för fintech kommer att se likadana ut eftersom de delar layout. För de flesta B2B-webbplatser är det acceptabelt, eftersom det är budskapet som ändras per segment. Spara helt skräddarsydd behandling för en kort lista med namngivna konton där affärens storlek motiverar extraarbetet, och acceptera att de sidorna behöver eget underhåll.
Följ prestandan när regler läggs till
Hur mycket en regeluppsättning kostar i hastighet beror på var beslutet fattas. Ett beslut på serversidan eller i edge lägger till arbete innan sidan skickas; ett skript på klientsidan lägger till arbete efter att sidan har renderats och kan orsaka flimmer. Hur som helst, mät i stället för att anta:
- Largest Contentful Paint och flimmer på personaliserade sidor. Jämför en personaliserad variant med standardsidan i PageSpeed Insights eller ett labbtest, med en strypt mobilprofil. Om den personaliserade hero-sektionen är LCP-elementet och visas senare än standardversionen skulle ha gjort, fattas beslutet för sent.
- Beslutstid från personaliseringsverktyget. De flesta verktyg loggar hur lång tid ett beslut tar. Följ det över tid och titta på vad som ändrats när det hoppar upp.
- Andel reservvisningar. Hur ofta en regel misslyckas och standardversionen visas i stället. En tyst reserv är bättre än en trasig sida, men en hög andel betyder att besökarna inte får det som registret säger att de får.
Registrera en baslinje innan varje omgång nya regler går live, så att en försämring kan knytas till den ändring som orsakade den. Övervakning av Core Web Vitals i ditt RUM-verktyg eller i Search Console flaggar långvariga problem, men först efter att tillräckligt mycket verklig trafik har påverkats.
Vem äger vad
| Roll | Ansvarsområden | Innehas ofta av |
|---|---|---|
| Ansvarig för personalisering | Register, namngivning, konfliktordning, kvartalsgenomgång, sista ordet om nya regler | Marketing ops- eller growth-ansvarig |
| Innehållsproducenter | Skriva text för varje plats per segment, hålla fakta aktuella | Produktmarknadsföring, innehållsteam |
| Teknisk implementatör | Sätta upp regler, felsöka konflikter, kontrollera prestanda | Webbutvecklare eller en teknisk marknadsförare, beroende på verktyget |
| Analytiker | Kontrollgrupper, resultat per regel, flagga regler som ska avvecklas | Marknadsanalytiker (se karriärer inom marknadsanalys för vad jobbet innebär) |
I små team har en eller två personer alla fyra rollerna, vilket är okej så länge registret finns, för då kan en andra person ta över arbetet. Ägarrollen är den som inte kan delas på ett vagt sätt: om alla äger regeluppsättningen avvecklar ingen något. För RACI, utrullningsfaser och styrning i större organisationer, se playbooken för utrullning av personalisering i stora företag.
Mät reglerna, inte bara programmet
En kontrollgrupp på programnivå visar att personaliseringen som helhet är värd att behålla. Den visar inte vilka av femtio regler som gör jobbet. Ge varje regel på nivå 2 och 3 en egen kontrollgrupp eller ett eget A/B-test när trafiken räcker, och markera regler som inte kan nå ett läsbart urval som ”ej mätta” i registret i stället för att anta att de hjälper. Vårt inlägg om att mäta ROI för personalisering går igenom dimensionering av kontrollgrupper och målhierarkin.
Checklista innan antalet regler växer
- Ett namngivningsmönster som alla använder
- Ett register med ansvarig, syfte, segment, fakta och teststatus för varje regel
- En skriftlig konfliktordning, plus ägarskap av element per nivå
- Platsmallar för åtminstone startsidan och prissidan
- En prestandabaslinje och en kontroll efter varje omgång regler
- En namngiven ägare och ett datum för nästa kvartalsgenomgång
Ett praktiskt första steg: exportera alla aktiva regler från ditt verktyg till registerformatet ovan. Varje regel du inte kan fylla i (ingen känd ansvarig, inget angivet syfte, ingen aning om den fungerar) hamnar på listan för den första genomgången. Om du sätter upp detta i Markettailor håller dess segmentering segmentdefinitionerna på ett ställe, vilket gör det lättare att upptäcka överlappning mellan regler.