Personalisering i sanntid betyr å endre hva en nettside viser basert på signaler som er tilgjengelige under selve besøket: den besøkendes selskap, hvor de kom fra, hva de har sett i denne og tidligere økter. Beslutningen tas mens siden lastes eller mens den besøkende beveger seg mellom sider, ikke dager senere i en e-postsekvens.
Eksempel (illustrerende): en besøkende fra en stor bedrift på mållisten din lander på forsiden. Bedriftsidentifiseringen finner kontoen ved første forespørsel, så overskriften handler om sikkerhet og administrasjon i stedet for standardbudskapet, bevisblokken viser en kunde fra samme bransje, og CTA-en tilbyr en samtale med kontoteamet i stedet for «Les mer». Den besøkende verken logget inn eller fylte ut noe. Dette innlegget forklarer hvordan det skiller seg fra tregere former for personalisering, hvilke signaler det kan bruke, B2B-eksempler, en første implementering, de tekniske delene og hvordan du måler om det virker.
Personalisering i sanntid vs. forsinket personalisering
Mesteparten av personaliseringen i markedsføring skjer med forsinkelse. En besøkende laster ned en whitepaper, en arbeidsflyt i CRM-et merker dem, og noen dager senere sendes en tilpasset e-post. Nyttig, men den reagerer på hva personen gjorde forrige uke.
Sanntidspersonalisering er en form for dynamisk innhold som handler på levende signaler: Ved hver forespørsel ser systemet på hva det vet om den besøkende, evaluerer segmentregler og velger en variant. Det betyr noe fordi B2B-kjøpsreiser er uregelmessige. Et prospekt kan delta på et webinar, bli stille i tre måneder og så komme tilbake via et søk og lese fem kundecaser i én økt. En ukentlig arbeidsflyt ser det tilbakevendende besøket for sent; en sanntidsregel kan reagere allerede på den andre siden.
| Forsinket (batch) | Sanntid | |
|---|---|---|
| Spørsmålet det besvarer | Hva gjorde denne personen nylig? | Hva gjør denne besøkende nå, og hva bør siden vise videre? |
| Typisk kanal | E-post, annonser, salgsoppgaver | Nettsider, meldinger i appen |
| Hvor ferske data som trengs | Timer til dager | Tilgjengelig under forespørselen |
| Største tekniske risiko | Utdaterte segmenter | Trege beslutninger og flimring |
Signaler du kan bruke under et besøk
- Firmografiske data. Selskap, bransje, størrelse og beliggenhet, utledet fra den besøkendes IP-adresse av en tjeneste for identifisering av besøkende. Tilgjengelig ved første sidevisning for besøkende der nettverket kan knyttes til et selskap, noe som gjør det til den vanligste B2B-utløseren. Dekningen er delvis: hjemme- og mobilforbindelser lar seg ofte ikke knytte til et selskap.
- Atferd i økten. Sider som er sett, innholdskategorier, rulledybde, søk på nettstedet. En besøkende som leser prissiden og deretter integrasjonssiden, forteller deg noe konkret.
- Historikk. Tidligere besøk, nedlastinger og deltakelse på webinarer, tilgjengelig når den besøkende gjenkjennes gjennom en førstepartskapsel, en innlogging eller en sporet e-postlenke.
- Henvisningskontekst. UTM-parametere, henvisende domene og kampanje. Et klikk fra en LinkedIn-annonse rettet mot økonomiledere bør ikke lande på et generisk budskap.
- CRM-status. Om kontoen er kunde, har en åpen mulighet eller står på en ABM-liste. Krever synkronisering mellom CRM og personaliseringsverktøy.
- Teknografiske data. Verktøy selskapet bruker, fra tredjepartsdata. Nyttig for å åpne med riktig integrasjon, men sjekk nøyaktigheten; disse dataene blir fort utdaterte.
B2B-eksempler
Eksemplene nedenfor er illustrerende mønstre, ikke kundecaser.
Forside etter kontonivå
Målkontoer på nivå 1 ser bransjens problem i overskriften, en relevant kundecase og en CTA for å møte sin navngitte kundeansvarlige. Kontoer på nivå 2 ser bransjebudskap med en CTA for selvbetjent demo. Alle andre ser standardversjonen. Dette flytter kontobasert markedsføring fra utgående e-post til nettstedet kontoene allerede besøker.
Sosiale bevis per bransje
I stedet for en fast logovegg viser bevisblokken kundene som ligger nærmest den besøkendes bransje, og ett kort sitat fra en lignende bedrift. Det fungerer bare med ekte kunder i hver bransje du personaliserer for; behold standardversjonen for bransjer der du ikke har noen.
Innholdsanbefalinger fra økten
En besøkende som har lest tre innlegg om analyse, får analyserelaterte anbefalinger i sidefeltet i stedet for standardlisten over «mest populære». En tilbakevendende besøkende som så produktdemoen forrige gang, ser kundehistorier i stedet for en ny introduksjon.
CTA-er etter fase
Førstegangsbesøkende fra et ukjent selskap: «Les guiden» eller «Se hvordan det fungerer». Gjenkommende besøkende fra en målkonto som har lest produktsider: «Book en demo». Noen som allerede har bedt om demo: «Forbered deg til demoen» med agenda og integrasjonssjekkliste, i stedet for et nytt forespørselsskjema. Innlegget vårt om datadrevne, personaliserte CTA-er dekker hvordan du tester disse.
Prisside etter selskapsstørrelse
Et selskap med 50 ansatte ser mellomnivået merket som anbefalt; et selskap med 5 000 ansatte ser enterprise-kortet fremhevet med en salgs-CTA. Priser og abonnementer er de samme for alle; bare vektleggingen endres.
En første implementering i fem steg
- Én side, ett segment. Som regel forsiden eller hovedlandingssiden, og et segment du kan identifisere pålitelig, som selskaper over en viss størrelse eller én bransje. Flere sider og segmenter samtidig er nettopp slik disse prosjektene stopper opp.
- Skriv varianten først. Overskrift, bevisblokk og CTA. Hvis du ikke kan si hva segmentet bør høre annerledes, er du ikke klar til å konfigurere noe.
- Koble identifisering til segmentering. Skriv regelen («selskapet har 500+ ansatte: vis enterprise-varianten, ellers standard») og test den med besøk fra kjente selskaper før lansering.
- Lever uten flimring. Bestem varianten på serveren eller i edge, eller la skriptet på klientsiden bytte ut bare den personaliserte blokken mens resten rendres. Besøkende skal ikke se standardoverskriften blinke og endre seg.
- Mål mot en kontrollgruppe. Del segmentet mellom standard og variant, bestem utvalgsstørrelsen før lansering, og utvid bare hvis varianten vinner.
De tekniske delene
Datalag. Hvor besøksprofilen kommer fra: en identifiseringstjeneste, en CDP eller et CRM med et raskt API. Er oppslaget tregt, viser siden standardversjonen før beslutningen kommer. Mål svartiden for oppslaget på ekte trafikk, ikke på kontorlinjen din.
Beslutningsmotor. Vurderer reglene og velger en variant. De fleste B2B-team starter med eksplisitte hvis/så-regler fordi de er enkle å forklare og feilsøke. Modellbasert valg av variant krever mye mer trafikk per segment enn de fleste B2B-nettsteder har.
Levering. JavaScript på klientsiden er raskest å sette opp, men gir risiko for flimring. Gjengivelse på serversiden unngår flimring, men krever utviklertid. Levering i edge (endring av responsen i CDN-et) unngår begge deler, hvis CDN-et ditt støtter det.
Ytelse og caching
Sjekk effekten på Core Web Vitals før og etter lansering, særlig Largest Contentful Paint (heroen er ofte LCP-elementet) og Cumulative Layout Shift (en utskiftet blokk som endrer størrelse, flytter siden). Reserver plass til personaliserte blokker, slik at de ikke skyver innholdet nedover.
Sider som varierer etter besøkende, krever omtanke rundt caching. Enten cacher du et felles sideskall og personaliserer bare bestemte blokker, eller så tar du beslutningen på edge, slik at hver besøkende får sitt eget resultat. Et personalisert svar som caches og vises til neste besøkende, er en vanlig feil, og det kan også bli det søkemotorene crawler; se hvordan personalisering påvirker SEO.
Slik måler du om det fungerer
Hovedmåltallet er konverteringsraten innenfor segmentet, personalisert mot en kontrollgruppe fra samme segment som ser standardversjonen. Å sammenligne personaliserte besøkende med gjennomsnittet for nettstedet fungerer ikke: identifiserte målkontoer konverterer uansett annerledes enn anonym trafikk.
Sekundære måltall hjelper deg med å forklare resultatet: klikk på det personaliserte elementet, sider per økt og gjentatte besøk. Øker engasjementet, men ikke konverteringene, får varianten oppmerksomhet uten å endre beslutninger; prøv den på en side med høyere intensjon.
Ikke vurder personalisering etter trafikk. Den endrer hva besøkende gjør når de først er der, ikke hvor mange som kommer. For å gjøre testresultater om til et forretningscase, se guiden vår om måling av ROI på personalisering.
Fallgruver
- Å personalisere på dårlige data. Hvis identifikasjonen matcher feil selskaper, eller CRM-dataene er utdaterte, vil siden virke tilfeldig. Stikkprøvekontroller matchene mot kontoer du kjenner før du bygger regler på dem.
- For mye på en gang. Å endre hvert element basert på besøksdata kan føles som overvåking. To eller tre elementer per side er mer enn nok: den besøkende skal føle at siden er relevant, ikke at den vet alt om dem.
- Ingen eier på tvers av team. Markedsføring skriver varianter, salg må stole på kontodataene, og noen teknisk ansvarlig eier datastrømmen. Mangler én av dem, stopper prosjektet opp etter den første testen.
- Usammenhengende reiser. En personalisert annonse som lander på en generisk side, bryter løftet. Samordne annonser, e-poster og sider for det samme segmentet; forklaringen vår om hvordan B2B-nettstedspersonalisering fungerer dekker oppsettet fra start til slutt.
Hvor du bør starte
Velg én side, ett segment med pålitelige data og to eller tre elementer å endre, og kjør det så mot en holdout-gruppe til det planlagte utvalget er nådd. Vinner det, legger du til neste segment; vinner det ikke, sjekker du om endringen var stor nok og segmentet smalt nok før du prøver igjen. Markettailor kobler identifisering av besøkende til endringer på siden med regelbasert målretting, hvis du vil lansere den første testen uten å bygge rørleggerarbeidet selv.
