Proaktyvus Chatbot kreipimasis: trigeriai, frequency caps ir pagarbi UX

Proaktyvus Chatbot kreipimasis tinkamu momentu gali atkreipti lankytojų dėmesį į naudingą trumpesnį kelią. Tačiau jis taip pat greitai gali tapti skaitmeniniu pardavėju, kuris neprašytas užblokuoja kelią. Todėl svarbiausia yra ne tai, ar pranešimas pasirodo automatiškai, o į kokį atpažįstamą poreikį jis reaguoja, kaip susilaikančiai jis suprojektuotas ir ar tikrai priimamas atsakymas „ne“.

Geros taisyklės sujungia tris perspektyvas: žmogaus užduotį, esamo puslapio apkrovą ir verslo naudą. Šis vadovas paverčia šias perspektyvas praktine sistema, susidedančia iš trigerių, išimčių taisyklių, frequency caps, prieinamų sąveikų ir patikrinamų kokybės rodiklių.

Proaktyvus – tai ne tas pats, kas įkyrus

Proaktyvus pranešimas iš pradžių yra tik kvietimas. Jis tampa įkyrus, kai pertraukia esamą užduotį, uždengia vaizdą, perima fokusą, uždarius iškart vėl pasirodo arba sukuria dirbtinę problemą. Todėl dizainas turėtų atitikti paprastą taisyklę: pirmiausia patikimas pagalbos signalas, tada nedidelis kvietimas, ir tik po sąmoningo aktyvavimo – dialogas.

Tai skiria pagalbą nuo automatiškai pasileidžiančio pokalbio. Subtilus pranešimas, pavyzdžiui, „Turite klausimų apie pristatymą?“, tinkamoje vietoje gali būti naudingas. Tuo tarpu neprašytas atidarytas langas su garsu, animacija ir privalomu sprendimu reikalauja dėmesio dar prieš nustatant poreikį. Jei techninį integravimą vis dar tik planuojate, verta papildomai atsižvelgti į patarimus dėl Chatbot integracijos nepabloginant UX ar SEO.

Trigeriai iš vartotojo signalų, o ne iš intuicijos

Vien tik laiko reikšmė retai būna geras signalas. Desimties sekundžių buvimas puslapyje gali reikšti intensyvų orientavimąsi, lėtą skaitymą, telefono skambutį arba tiesiog neaktyvią kortelę. Daug labiau informatyvūs yra puslapio konteksto ir elgsenos deriniai. Be to, kelios aiškios taisyklės dažniausiai duoda daugiau naudos nei sunkiai paaiškinamas vertinimo modelis.

Stiprūs, su užduotimi susiję signalai

• Paskartotinė navigacija: Asmuo kelis kartus perjungia kainų, paslaugų ar pristatymo informaciją.
• Atpažįstamas nutraukimo taškas: Pradedama pildyti kelių žingsnių forma, tačiau sustojama ties lauku, kuriam reikia paaiškinimo.
• Išsamus produkto nagrinėjimas: Vienas po kito atidaromi variantai, sąlygos ar techninės detalės.
• Klaida su pagalbos potencialu: Įvestis pakartotinai nepavyksta, tačiau Chatbot neturi spėlioti duomenų ar sprendimų.
• Grįžimas su tuo pačiu klausimu: Apibrėžtame, duomenis taupančiame kontekste vėl apsilankoma tame pačiame informaciniame puslapyje.

Silpni signalai – tik kaip papildymas

Slinkimo gylis, buvimo laikas ir Exit-Intent gali suteikti papildomų užuominų, tačiau jie neturėtų spęsti vieni. Pelės žymeklio viršutiniame krašte jutikliniuose įrenginiuose nėra; ilgas buvimo laikas be matomo skirtuko sako nedaug. Page Visibility API leidžia atpažinti neaktyvius arba uždengtus skirtukus. Laiku pagrįsti trigeriai turėtų veikti tik tol, kol puslapis yra matomas ir asmuo iš tiesų aktyvus.

Išimčių taisyklės yra tokios pat svarbios kaip ir trigeriai

Kiekvienai trigerio taisyklei reikia priešingybės, kuri užkirstų kelią pranešimui. Joks kvietimas neturėtų pasirodyti, jei pokalbis jau atidarytas, asmuo tuo metu rašo, siunčia formą, vykdo mokėjimo ar autentiškumo patvirtinimo žingsnį arba matomas kitas svarbus dialogas. Taip pat po aiškaus uždarymo pirmenybė turi būti teikiama slopinimui.

Protingas prioritetas skamba taip: saugumo ir transakcijų būsena svarbesnė už vartotojo sprendimą, vartotojo sprendimas svarbesnis už kampanijos logiką, konkreti pagalba svarbesnė už bendrus pranešimus. Tai užkerta kelią rinkodaros pranešimui uždengti palaikymo ar pirkimo užduotį.

Frequency Caps: priminimo modelis vietoj nuolatinio triukšmo

Frequency Caps riboja ne tik parodymus. Jie išsaugo informaciją, kad žmogus jau priėmė sprendimą. Pirmam testui gali pakakti paprasto modelio:

1. Per seansą pasirodo ne daugiau kaip vienas proaktyvus kvietimas.
2. Po aktyvaus uždarymo taikomas kelių dienų ramybės periodas, pavyzdžiui, septynios dienos kaip patikrinama pradinė reikšmė.
3. Po sėkmingo naudojimo tas pats pranešimas nuslopinamas likusiam užduoties keliui.
4. Kelis reikalavimus atitinkančios taisyklės nekonkuruoja; griežtas prioritetas pasirenka ne daugiau kaip vieną kvietimą.
5. Pakartotinis uždarymas prailgina ramybės periodą, užuot didinęs spaudimą.

Šie skaičiai nėra universalūs standartai. Retai naudojamam B2B portalui reikia kitokių ribų nei dažnai lankomam paslaugų puslapiui. Svarbiausia, kad pradinės reikšmės būtų dokumentuotos, įvertintos pagal įrenginį bei puslapio tipą ir pakoreguotos remiantis atmetimo signalais.

Mobiliesiems įrenginiams galioja griežtesni erdvės ir laiko ribojimai

Mažuose ekranuose net ir kompaktiškas pranešimo burbulas gali uždengti turinį, navigaciją ar ekrano klaviatūrą. Todėl kvietimas neturėtų uždengti pagrindinio mygtuko, turi išlaikyti pakankamą atstumą nuo slapukų bei sistemos pranešimų ir išnykti atidarius klaviatūrą. Ypač slinkimo metu prasminga ramybė: pranešimas gali pasirodyti tik po trumpos stabilios fazės.

Pritaikytas taisyklių rinkinys taip pat atsižvelgia į turimą aukštį, o ne tik plotį. Labai mažose rodymo srityse neįkyrus ženklelis (badge) gali būti tinkamesnis nei teksto burbulas. Visas pokalbis atsidaro tik po sąmoningo veiksmo.

Uždarymas ir fokusas turi veikti patikimai

Uždarymas turi būti prieinamas kaip aiškiai pažymėtas veiksmas, pasiekiamas klaviatūra; Escape klavišas turėtų uždaryti atidarytą pokalbį, jei dėl to neprarandama įvestis. Grynai dekoratyvaus „X“ be prieinamo pavadinimo nepakanka. Dar svarbiau: proaktyvus pranešimas neturi neprašytas perkelti klaviatūros fokuso.

WCAG 2.2 reikalauja reikalavime „On Focus“, kad komponento fokusavimas pats savimi nesukeltų konteksto pokyčio. Būsenos informacija pagal WCAG 4.1.3 dėl būsenos pranešimų turi būti atpažįstama pagalbinėms technologijoms neperimant fokuso. Dialogui, atidarytam po vartotojo veiksmo, WAI-ARIA dialogo pavyzdys suteikia patikimas gaires dėl fokuso valdymo, Escape elgsenos ir fokuso grąžinimo.

Jei kvietimas judinamas arba atnaujinamas automatiškai, taip pat aktualūs reikalavimai dėl paauzavimo, sustabdymo ir slėpimo. Praktikoje ramus, statiškas kvietimas dažniausiai yra paprastesnis ir malonesnis nei pulsuojančios ar pasikartojančios animacijos. Išsamesnį patikrinimą siūlo Dirbtinio intelekto Chatbot WCAG kontrolinis sąrašas.

Pranešimas turi sąžiningai atspindėti atpažintą kontekstą

Geras kvietimas įvardija konkrečią, iš tikrųjų prieinamą pagalbą. „Ar paaiškinti šių variantų skirtumus?“ yra lengviau patikrinamas teiginys nei „Tiksliai žinau, ko jums reikia“. Formuluotė neturi nei imituoti prieigos prie asmens duomenų, nei kurti dirbtinės skubos. Taip pat atgaliniam skaičiavimui, dirbtiniam trūkumui ir gėdinantiems atsisakymo variantams nėra vietos pagarbioje komunikacijoje.

Daugiakalbėse svetainėse pranešimas ne tik išverčiamas, bet ir patikrinamas jo ilgis, tonas bei sąsaja su veiksmu kiekvienai kalbai. Trigeris gali veikti vienodai visomis kalbomis, nors teksto ilgis ir skaitymo kryptis gali pakeisti vaizdą. Jei žinių bazėje trūksta informacijos konkrečiam klausimui, kvietimas neturėtų žadėti sprendimo, o prireikus pasiūlyti saugų perdavimą žmogui. Tam tinka vadovas apie Human Handoff svetainės palaikymo sistemoje.

Našumas yra prompto kokybės dalis

Pranešimas nepadeda, jei jo logika sulėtina puslapį pirmojo spustelėjimo metu. Trigerių vertinimas, animacija ir valdiklio įkėlimas neturėtų be reikalo blokuoti pagrindinio srauto (main thread). „Google“ dokumentuotas rodiklis Interaction to Next Paint (INP) vertina vartotojo sąveikų reakcijos greitį viso apsilankymo metu. Todėl promptas neturėtų paleisti ilgų sinchroninių užduočių, o didelės apimties čato funkcijas reikėtų įkelti tik esant tikėtinam naudojimui.

Techniniam patikrinimui priklauso lėti mobilieji įrenginiai, sumažintas judėjimas, navigacija klaviatūra ir nestabilus tinklas. Chatbot skripto klaida neturi blokuoti nei turinio, nei navigacijos. Pagrindinė puslapio užduotis visada turi likti pasiekiama.

Sėkmės matavimas nepasimaunant ant atidarymo rodiklio

Aukštas atidarymo rodiklis gali reikšti, kad kvietimas buvo aktualus. Tačiau jis taip pat gali atsirasti dėl per didelio ploto arba klaidingo uždarymo. Todėl matuokite visą kelią:

• tinkamus trigerius ir faktinius parodymus, atskirai pagal taisyklę ir įrenginį;
• sąmoningus atidarymus, tiesioginį uždarymą ir pakartotinį uždarymą;
• pasiektus pagalbos tikslus, pavyzdžiui, atsakytą klausimą apie produktą, atliktą žingsnį ar pasirinktą perdavimą (handoff);
• nutraukimą, grįžtamąją navigaciją ir formos klaidas po parodymo;
• našumo reikšmes bei technines valdiklio klaidas.

Rinkite tik tiems sprendimams reikalingus duomenis ir apibrėžkite saugojimą bei prieigą prieš eksperimentą. Straipsnis apie duomenis taupančią Chatbot analitiką rodo tam tinkamą įvykių ir peržiūros struktūrą.

Kontroliuojamam eksperimentui reikia apsauginių rodiklių

Palyginkite ne tik konversiją, bet ir apsauginius rodiklius, tokius kaip Dismiss rodiklis, pakartotinis atmetimas, puslapio palikimas, fokuso klaidos ir INP. Prieš pradėdami nustatykite, prie kokio neigiamo signalo variantas bus pristabdytas. Nedidelė papildoma lead reikšmė nepateisina gerokai pablogėjusio naudojimo patogumo.

Iš pradžių išbandykite aiškiai apibrėžtą puslapį ir vieną trigerio taisyklę. Vėliau keiskite tik vieną dimensiją, pavyzdžiui, laiką, tekstą arba Frequency Cap. Kitaip liks neaišku, kuris pokytis sukėlė efektą. Kokybinės imtys iš anonimizuotų pokalbių istorijų gali paaiškinti, kodėl kiekybinis signalas kyla arba krenta.

Aiškaus taisyklių rinkinio pavyzdys

B2B produkto srityje kvietimas galėtų būti leidžiamas tik tada, kai atidarytos bent dvi techninių detalių sritys, puslapis yra matomas, nuo paskutinės sąveikos praėjo trumpa ramybės fazė ir nėra aktyvi nei forma, nei čatas. Jei pranešimas šiame seanse jau buvo parodytas arba per pastarąsias septynias dienas uždarytas, jis neberodomas. Mobiliuose įrenginiuose iš pradžių pasirodo tik kompaktiškas pagalbos mygtukas su užrašu.

Pranešimas susijęs su užduotimi: „Klausimai dėl sąlygų ar variantų?“. Atidarius Chatbot siūlo du aiškius įėjimo taškus ir uždarymo veiksmą. Jei jis negali pateikti įpareigojančio teiginio iš patvirtintų šaltinių, jis pažymi ribą ir paruošia perdavimą. Ši logika yra pakankamai paprasta, kad ją būtų galima paaiškinti komandai ir visiškai padengti testais.

Kontrolinis sąrašas prieš paleidimą (Go-live)

• Ar trigeris susietas su konkrečia užduotimi, o ne tik su laiku?
• Ar yra dokumentuotos išimčių taisyklės formoms, transakcijoms ir aktyviems dialogams?
• Ar uždarymas gerbiamas per kelis seansus?
• Ar klaviatūros fokusas lieka nepakitęs iki sąmoningo aktyvavimo?
• Ar patikrinti uždarymas, Escape, ekrano skaitytuvo pranešimai ir sumažintas judėjimas?
• Ar kvietimas mažose rodymo srityse neuždengia svarbių valdymo elementų?
• Ar našumas, nutraukimas ir atmetimas apibrėžti kaip apsauginiai rodikliai?
• Ar aišku, kada Chatbot perduoda darbą žmogui arba tyli?
• Ar visos palaikomos kalbos buvo išbandytos su realiais tekstų ilgiais?

Pradėkite nuo vieno naudingo kvietimo ir vertinkite kiekvieną uždarymą kaip galiojantį sprendimą. Taip proaktyvus Chatbot kreipimasis taps gerai valdoma paslaugos funkcija – o ne dar vienu trukdžiu svetainėje.

Šaltiniai ir susiję standartai

• W3C: Understanding SC 2.2.2 Pause, Stop, Hide
• W3C: Understanding SC 3.2.1 On Focus
• W3C: Understanding SC 4.1.3 Status Messages
• W3C WAI-ARIA APG: Modal Dialog Pattern
• web.dev: Optimize Interaction to Next Paint
• MDN: Page Visibility API