Reaalajas personaliseerimine tähendab veebilehe sisu muutmist külastuse ajal kättesaadavate signaalide põhjal: külastaja ettevõte, kust ta tuli, mida ta on selles ja varasemates seanssides vaadanud. Otsus tehakse lehe laadimise ajal või siis, kui külastaja lehtede vahel liigub, mitte päevi hiljem e-kirjade jadas.
Näide (illustratiivne): teie sihtkontode nimekirjas oleva suure ettevõtte külastaja jõuab avalehele. Ettevõtte tuvastamine seob konto juba esimesel päringul, nii et pealkiri räägib vaikesõnumi asemel turvalisusest ja haldusest, tõendiplokk näitab sama valdkonna klienti ja CTA pakub „Loe lähemalt“ asemel vestlust kontomeeskonnaga. Külastaja ei loginud sisse ega täitnud midagi. See postitus käsitleb, mille poolest see erineb aeglasematest personaliseerimise vormidest, milliseid signaale see saab kasutada, B2B näiteid, esimest juurutust, tehnilisi osi ja seda, kuidas mõõta, kas see toimib.
Reaalajas vs viitega personaliseerimine
Enamik turunduse personaliseerimisest toimib viitega. Külastaja laadib alla valge raamatu, CRM-i töövoog märgistab ta ja mõne päeva pärast läheb välja sobiv e-kiri. Kasulik, kuid see reageerib sellele, mida inimene tegi eelmisel nädalal.
Reaalajas personaliseerimine on dünaamilise sisu vorm, mis tegutseb reaalajas signaalide põhjal: iga päringu puhul vaatab süsteem, mida ta külastaja kohta teab, hindab segmendireegleid ja valib variandi. See on oluline, sest B2B teekonnad on ebaregulaarsed. Potentsiaalne klient võib osaleda veebiseminaril, vaikida kolm kuud ja seejärel tulla tagasi otsingu kaudu ja lugeda ühe istumisega viis kliendilugu. Iganädalane töövoog näeb seda korduvkülastust liiga hilja; reaalajas reegel saab reageerida teisel lehel.
| Viivitusega (partiidena) | Reaalajas | |
|---|---|---|
| Küsimus, millele see vastab | Mida see inimene hiljuti tegi? | Mida see külastaja praegu teeb ja mida peaks leht talle järgmisena näitama? |
| Tüüpiline kanal | E-post, reklaamid, müügiülesanded | Veebilehed, rakendusesisesed sõnumid |
| Vajalik andmete värskus | Tunnid kuni päevad | Saadaval päringu ajal |
| Peamine tehniline risk | Aegunud segmendid | Aeglased otsused ja virvendus |
Signaalid, mida saate külastuse ajal kasutada
- Firmograafilised andmed. Ettevõte, tööstusharu, suurus ja asukoht, mille külastajate tuvastamise teenus tuletab külastaja IP-aadressist. Saadaval juba esimesel lehe laadimisel külastajate puhul, kelle võrk seostub ettevõttega, mistõttu on see kõige levinum B2B päästik. Katvus on osaline: kodu- ja mobiiliühendused sageli ei seostu.
- Seansikäitumine. Vaadatud lehed, sisukategooriad, kerimissügavus, otsingud lehel. Külastaja, kes loeb hinnalehte ja seejärel integratsioonide lehte, annab teile midagi väga konkreetset teada.
- Ajalugu. Varasemad külastused, allalaadimised ja veebiseminaridel osalemine, saadaval siis, kui külastaja tuntakse ära esimese osapoole küpsise, sisselogimise või jälgitava e-posti lingi kaudu.
- Suunamise kontekst. UTM-parameetrid, viitav domeen ja kampaania. Klõps finantsjuhtidele suunatud LinkedIni reklaamilt ei tohiks jõuda üldise sõnumini.
- CRM-i olek. Kas konto on klient, kas tal on avatud müügivõimalus või on ta ABM-nimekirjas. Nõuab CRM-i ja personaliseerimistööriista vahelist sünkroonimist.
- Tehnograafilised andmed. Ettevõtte kasutatavad tööriistad, kolmanda osapoole andmetest. Kasulik õige integratsiooniga alustamiseks, kuid kontrollige täpsust; need andmed vananevad.
B2B näited
Allolevad näited on illustratiivsed mustrid, mitte juhtumiuuringud.
Avaleht konto taseme järgi
1. taseme sihtkontod näevad pealkirjas oma valdkonna probleemi, asjakohast kliendilugu ja CTA-d kohtumiseks oma nimelise kontohalduriga. 2. taseme kontod näevad valdkonnapõhist sõnumit iseteenindusliku demo CTA-ga. Kõik teised näevad vaikimisi versiooni. Nii liigub kontopõhine turundus väljaminevast e-postist veebisaidile, mida kontod juba külastavad.
Sotsiaalne tõestus valdkonniti
Fikseeritud logoseina asemel näitab tõendiplokk külastaja valdkonnale kõige lähemaid kliente ja üht lühikest tsitaati sarnaselt ettevõttelt. See toimib ainult siis, kui teil on igas personaliseeritavas valdkonnas päris kliente; jätke vaikeversioon alles valdkondades, kus teil neid pole.
Sisusoovitused seansi põhjal
Külastaja, kes on lugenud kolm analüütikapostitust, saab külgribal vaikimisi „populaarseimate“ nimekirja asemel analüütikaga seotud soovitusi. Naasev külastaja, kes vaatas eelmisel korral tootedemot, näeb uue tutvustuse asemel kliendilugusid.
CTA-d etapi järgi
Esmakülastaja tundmatust ettevõttest: „Loe juhendit“ või „Vaata, kuidas see töötab“. Tagasipöörduv külastaja sihtkontost, kes on lugenud tootelehti: „Broneeri demo“. Keegi, kes on juba demot taotlenud: „Valmistu oma demoks“ koos päevakava ja integratsiooni kontrollnimekirjaga, mitte teine päringuvorm. Meie postitus andmepõhiste personaliseeritud CTA-de kohta käsitleb nende testimist.
Hinnaleht ettevõtte suuruse järgi
50 töötajaga ettevõte näeb keskmist paketti soovitatuna; 5000 töötajaga ettevõte näeb esile tõstetud suurettevõtte kaarti koos müügi-CTA-ga. Hinnad ja paketid jäävad kõigile samaks; muutub ainult rõhuasetus.
Esimene juurutus viie sammuga
- Üks leht, üks segment. Tavaliselt avaleht või peamine maandumisleht ning segment, mida saate usaldusväärselt tuvastada, näiteks teatud suurusest suuremad ettevõtted või üks valdkond. Mitu lehte ja segmenti korraga on see, kuidas sellised projektid seisma jäävad.
- Kirjutage kõigepealt variant. Pealkiri, tõendusplokk ja CTA. Kui te ei oska öelda, mida segment teisiti kuulma peaks, ei ole te valmis midagi seadistama.
- Ühendage tuvastamine segmenteerimisega. Kirjutage reegel („ettevõttel on 500+ töötajat: näita suurettevõtte varianti; muul juhul vaikimisi“) ja testige seda enne käivitamist tuntud ettevõtete külastustega.
- Edastage ilma vilkumiseta. Otsustage variant serveris või servas või laske kliendipoolsel skriptil vahetada ainult personaliseeritud plokk, samal ajal kui ülejäänu renderdub. Külastajad ei tohiks näha, kuidas vaikimisi pealkiri välgatab ja muutub.
- Mõõtke kontrollgrupi suhtes. Jagage segment vaikeversiooni ja variandi vahel, otsustage valimi suurus enne käivitamist ja laiendage ainult siis, kui variant võidab.
Tehnilised osad
Andmekiht. Kust külastaja profiil pärineb: tuvastusteenus, CDP või kiire API-ga CRM. Kui päring on aeglane, renderdab leht vaikeversiooni enne, kui otsus kohale jõuab. Mõõtke päringu vastamisaega päris liiklusel, mitte oma kontori ühendusel.
Otsustusmootor. Hindab reegleid ja valib variandi. Enamik B2B meeskondi alustab selgesõnaliste kui/siis-reeglitega, sest neid on lihtne selgitada ja siluda. Mudelipõhine variandivalik vajab segmendi kohta palju rohkem liiklust, kui enamikul B2B saitidel on.
Edastamine. Kliendipoolset JavaScripti on kõige kiirem seadistada, kuid see võib põhjustada värelemist. Serveripoolne renderdamine väldib värelemist, kuid vajab arendusaega. Servas edastamine (vastuse muutmine CDN-is) väldib mõlemat, kui teie CDN seda toetab.
Jõudlus ja puhverdamine
Kontrollige mõju Core Web Vitalsile enne ja pärast käivitamist, eriti Largest Contentful Painti (päis on sageli LCP element) ja Cumulative Layout Shifti (vahetatud plokk, mis muudab suurust, nihutab lehte). Reserveerige personaliseeritud plokkidele ruum, et need sisu allapoole ei lükkaks.
Lehed, mis külastajati erinevad, vajavad vahemällu salvestamisel hoolt. Kas salvestage vahemällu ühine lehe raam ja personaliseerige ainult konkreetseid plokke, või tehke otsus servas, et iga külastaja saaks oma tulemuse. Personaliseeritud vastus, mis salvestatakse vahemällu ja serveeritakse järgmisele külastajale, on levinud viga ja see võib saada ka selleks, mida otsingumootorid indekseerivad; vaadake, kuidas personaliseerimine SEO-d mõjutab.
Kuidas mõõta, kas see töötab
Peamine mõõdik on konversioonimäär segmendi sees: personaliseeritud vs sama segmendi kontrollrühm, mis näeb vaikimisi versiooni. Personaliseeritud külastajate võrdlemine saidi keskmisega ei tööta: tuvastatud sihtkontod konverteerivad niikuinii teisiti kui anonüümne liiklus.
Teisesed mõõdikud aitavad tulemust selgitada: klikid personaliseeritud elemendil, lehti seansi kohta ja tagasipöördumised. Kui kaasatus kasvab, kuid konversioonid mitte, saab variant tähelepanu, ilma et otsuseid muudaks; proovige seda suurema kavatsusega lehel.
Ärge hinnake personaliseerimist liikluse järgi. See muudab seda, mida külastajad pärast saabumist teevad, mitte seda, kui palju neid saabub. Testitulemuste äriliseks põhjenduseks muutmise kohta vaadake meie juhendit personaliseerimise ROI mõõtmisest.
Lõksud
- Personaliseerimine halbade andmete põhjal. Kui tuvastamine sobitab valed ettevõtted või CRM-andmed on aegunud, tundub leht juhuslik. Kontrollige vasteid pisteliselt teile tuntud ettevõtete vastu enne, kui ehitate nende põhjal reegleid.
- Liiga palju korraga. Iga elemendi muutmine külastajaandmete põhjal võib tunduda jälgimisena. Kaks või kolm elementi lehe kohta on täiesti piisav: külastaja peaks tundma, et leht on asjakohane, mitte et see teab temast kõike.
- Puudub meeskondadeülene vastutaja. Turundus kirjutab variante, müük peab kontoandmeid usaldama ja keegi tehniline vastutab andmetoru eest. Kui üks neist puudub, seiskub projekt pärast esimest testi.
- Katkenud teekonnad. Isikupärastatud reklaam, mis maandub üldisel lehel, murrab lubaduse. Viige sama segmendi reklaamid, e-kirjad ja lehed kooskõlla; meie selgitus kuidas B2B veebisaidi isikupärastamine toimib katab kogu seadistuse algusest lõpuni.
Kust alustada
Valige üks leht, üks usaldusväärsete andmetega segment ning kaks või kolm muudetavat elementi ja käitage seda kontrollrühma vastu, kuni planeeritud valim on saavutatud. Kui see võidab, lisage järgmine segment; kui mitte, kontrollige enne uut katset, kas muudatus oli piisavalt suur ja segment piisavalt kitsas. Markettailor ühendab külastajate tuvastamise reeglipõhise sihtimisega lehemuudatustega, kui soovite selle esimese testi käivitada ilma taristut ise ehitamata.
