Chatbot pokalbių tęstinumas: sesijos, įrenginio keitimas ir saugus perdavimas

Lankytojas svetainės Chatbot užduoda tris klausimus, pereina į produkto puslapį ir vėliau grįžta. Klientė pradeda pokalbį išmaniajame telefone ir nori jį tęsti nešiojamajame kompiuteryje. Klientų aptarnavimo skyriuje pokalbį galiausiai perima žmogus. Visais trimis atvejais tikimasi to paties: pokalbis turi sklandžiai tęstis. Tačiau techniškai ir organizaciškai tai yra trys skirtingos užduotys. Jas sumaišius rizikuojama prarasti kontekstą, netyčia atskleisti duomenis arba išlaikyti aktyvią sesiją ilgiau nei būtina.

„Tęsti“ nereiškia „atpažinti“

Planuojant padeda aiškus trijų tęstinumo lygmenų atskyrimas:

1. Vieno apsilankymo metu: pokalbis išsaugomas, kai kas nors naršo tarp puslapių arba uždaro ir vėl atidaro pokalbio langą.
2. Vėlesnio grįžimo metu: ta pati naršyklė per ribotą laiką suranda ankstesnį pokalbį.
3. Tarp skirtingų įrenginių: asmuo tęsia pokalbį kitoje naršyklėje arba kitame įrenginyje. Tam paprastai reikia patikimo susiejimo su paskyra arba sąmoningai aktyvuoto, trumpai galiojančio perdavimo proceso.

Egzistuojanti pokalbio istorija dar neįrodo tapatybės. Todėl asmuo, turintis pokalbio ID arba nuorodą, neturėtų automatiškai gauti prieigos prie užsakymų, sutarties duomenų ar asmens informacijos. Tai yra ta pati pagrindinė riba, kuri taikoma ir atskiriant viešąjį Chatbot nuo autentiškumą patvirtinusio klientų portalo: kontekstas suteikia patogumo, tačiau nepakeičia prisijimo ir teisių patikrinimo.

Techninis pagrindas: nuoroda naršyklėje, būsena serveryje

Patikima architektūra naršyklėje saugo tik atsitiktinę, beprasmią nuorodą. Susijusi pokalbio būsena yra serveryje ir kiekvienos užklausos metu tikrinama pagal galiojimą, kliento identifikatorių, teises ir galiojimo pabaigos datą. OWASP sesijų valdymo rekomendacijose patariama naudoti beprasmius, sunkiai atspėjamus sesijų identifikatorius ir serveryje kontroliuojamus laiko limitus. Be to, sesijų identifikatoriams ne vieta URL adresuose: jie gali būti perduoti per istoriją, žurnalus, nuorodų šaltinius (referrers) arba bendrinamas nuorodas.

Naršyklės atmintis turi skirtingą veikimo spindulį. Remiantis MDN Web Storage API, sessionStorage yra susietas su kortele bei šaltiniu ir paprastai baigiasi uždarius kortelę. localStorage išlieka per kelias naršyklės sesijas, tačiau tik tame pačiame naršyklės profilyje. Nė vienas iš jų nesukuria tarpįrengininės tapatybės. Jautrių transkriptų ar ilgalaikių prieigos žetonų (tokens) saugojimas tiesiogiai ten tik padidina skripto ar įrenginio perėmimo pasekmes.

Kokius duomenis turėtų apimti būsena

Kad tęstinumas būtų naudingas, sistemai dažnai reikia mažiau informacijos nei viso transkripto. Gali pakakti kompaktiško, versijuoto būsenos duomenų rinkinio:

• dabartinis užklausos tikslas ir patvirtinta užduotis,
• jau išaiškinti, nejautrūs faktai,
• atviri klausimai ir kitas logiškas žingsnis,
• naudoti žinių šaltiniai arba jų versijos,
• sutikimo, autentiškumo patvirtinimo ir perdavimo (handoff) būsena,
• paskutinio aktyvumo laikas bei nustatyta galiojimo pabaigos data.

Taip pokalbį galima rišliai tęsti neperkeliant kiekvienos ankstesnės žinutės į aktyvų užklausos tekstą (prompt). Visa istorija gali būti saugoma atskirai, sutrumpinta arba visai nesaugoma – priklausomai nuo tikslo, vartotojo lūkesčių ir nustatytų taisyklių. Asmens duomenims svarbūs projektavimo principai yra tikslinei paskirčiai nustatytos ribos, duomenų kiekio mažinimas ir saugojimo trukmės ribojimas pagal BDAR 5 straipsnį. Tai nepakeičia teisinės konsultacijos, tačiau suteikia aiškų reikalavimą produktui: saugoti tik tai, kas tikrai būtina nurodytam tikslui.

Anonymiems ir prisijungusiems vartotojams taikykite skirtingus principus

Anoniminis grįžimas toje pačioje naršyklėje

Anoniminiams lankytojams funkcija „tęsti pokalbį“ turėtų likti tik riboto patogumo galimybė. Prasminga nustatyti trumpą saugojimo terminą, pateikti aiškiai matomą ištrynimo komandą ir paaiškinimą, kad istorija bus surasta tik šioje naršyklėje. Chatbot neturėtų daryti prielaidos, kad vėl apsilankė tas pats fizinis asmuo. Pasibaigus galiojimui arba praradus vietinę nuorodą, prasideda nauja sesija.

Praktikoje Chatbot grįžusiam vartotojui gali paklausti: „Ar norite tęsti pokalbį apie produkto pasirinkimą, ar pradėti iš naujo?“ Tai yra geriau nei tyliai aktyvuoti senąjį kontekstą. Bendro naudojimo įrenginiuose šis patvirtinimas užkerta kelią kitam asmeniui iškart pamatyti svetimą turinį.

Įrenginio keitimas prisijungus

Tęstinumas tarp skirtingų įrenginių turėtų būti susietas su patvirtinta paskyra ir jos dabartinėmis teisėmis. Po prisijungimo serveris įkelia tik tuos pokalbius, kurie priskirti šiai paskyrai ir tinkamam klientui. Atliekant jautrius veiksmus – pavyzdžiui, keičiant adresą, tikrinant sutartį ar pateikiant užsakymą – prasminga reikalauti pakartotinio autentiškumo patvirtinimo, net jei bendras pokalbis vis dar aktyvus.

Dabartinėse NIST SP 800-63B sesijų valdymo gairėse sesija apibūdinama kaip ryšys tarp patvirtinto asmens ir paslaugos per sesijos paslaptį. Jei reikalaujama nustatyti tiek neaktyvumo, tiek bendro laiko limitus, taip pat užtikrinti nutraukimą serverio pusėje. Produkto komandoms iš to išplaukia: „prisijungęs“ negali būti neribota būsena, o pasibaigus paskyros ar sesijos žetono galiojimui, jo negalima atkurti vien dėl to, kad išliko pokalbio istorija.

Perdavimo kodas – tik kaip griežtai apibrėžtas tiltas

Kai kurios paslaugos nori suteikti galimybę anonimiškai pakeisti įrenginį naudojant vienkartinį kodą arba QR kodą. Tokiu atveju kodas turėtų būti trumpalaikis, vienkartinis ir atšaukiamas. Jame neturi būti nei transkripto, nei kliento duomenų – tik atsitiktinė nuoroda į patvirtintą, minimalią pokalbio būseną. Sėkmingai perėmus pokalbį, senoji nuoroda tampa negaliojančia. Kodas yra tik tiltas kontekstui perduoti, o ne tapatybės įrodymas ar prieiga prie jautrių paskyros duomenų.

Galiojimo taisyklės turi būti aiškios sąsajoje

Techniniai laiko limitai išsprendžia tik pusę užduoties. Vartotojai turi žinoti, ar ir kiek laiko jų pokalbis bus išsaugotas. NIST vartotojų patirties (CX) gairėse pabrėžiama, kad svarbu pateikti aiškią informaciją apie sesijos pabaigą, kad nebūtų prarastas darbas ir žmonės nesinaudotų nesaugiais apėjimo būdais.

Tinkama galiojimo pabaigos koncepcija tiesiogiai pokalbyje atsako į šiuos klausimus:

• Ar pokalbis išlieka uždarius langą?
• Ar tai galioja tik šiai naršyklei, ar ir prisijungus kitame įrenginyje?
• Kada sesija baigiasi dėl neaktyvumo ir kada ištrinama išsaugota istorija?
• Kurią dalį vartotojas gali pats pašalinti arba eksportuoti?
• Kas nutinka su atviru užklausos atveju po sesijos pabaigos?

Prieš numatomą sesijos pabaigą subtilus pranešimas gali pasiūlyti išsaugoti informaciją arba perduoti ją klientų aptarnavimui. Pasibaigus laikui, sąsaja turėtų aiškiai skirti sąvokas „sesija baigėsi“ ir „istorija ištrinta“. Vienas dalykas susijęs su prieiga, kitas – su duomenų saugojimu.

Human Handoff: konteksto perdavimas ir atsakomybės parodymas

Perduodant pokalbį žmogui, trumpa struktūrizuota santrauka dažnai yra vertingesnė nei ilga, nekomentuota istorija. Joje nurodoma užklausa, patvirtinti duomenys, jau pasiūlyti veiksmai, atviri klausimai ir naudoti šaltiniai. Jautrus turinys perduodamas tik tada, kai jis būtinas aptarnavimo atvejui ir yra patvirtintas.

Vartotojas turėtų matyti, kad pokalbį perima žmogus, kokia informacija perduodama ir ar atsiras naujas laukimo laikas. Kartu dirbtinis intelektas po perdavimo turi žinoti, ar jis turi tylėti, teikti tik organizacinę pagalbą, ar vėliau vėl perimti pokalbį. Konkrečius aktyvavimo veiksnius ir eskalavimo taisykles rasite straipsnyje apie Human Handoff svetainės pokalbių bote.

Įgyvendinimas per šešis žingsnius

1. Nustatykite naudojimo scenarijus: atskirai apibrėžkite naršymą puslapyje, vėlesnį grįžimą, įrenginio keitimą ir perdavimą žmogui.
2. Apibrėžkite pasitikėjimo lygmenis: nustatykite, koks turinys pasiekiamas anonimiškai, koks – susiejus paskyrą, o koks – tik po pakartotinio autentiškumo patvirtinimo.
3. Sumažinkite būsenos apimtį: sukurkite struktūrizuotą „resume-state“ su tikslu, patvirtintais faktais, atvirais klausimais ir galiojimo laiku.
4. Užtikrinkite gyvavimo ciklą: išbandykite neaktyvumo limitą, absoliutų limitą, ištrynimą, atšaukimą ir atsijungimą serverio pusėje.
5. Suprojektuokite perdavimus: padarykite matomus vartotojo patvirtinimą, aptarnavimo santrauką, laukimo būseną ir atsakomybę.
6. Matuokite sėkmę be pilno teksto: fiksuokite tokius įvykius kaip „pasiūlyta tęsti“, „priimta“, „pasibaigė galiojimas“, „įrenginio keitimas baigtas“ ir „perdavimas sėkmingas“. Kaip tai atlikti taupant duomenis, parodyta DI Chatbot analitikos gairėse.

Testavimo matrica kompiuteriams, mobiliesiems ir ribiniams atvejams

Prieš paleidimą turėtų veikti ne tik sėkmingasis scenarijus. Nedidelė testavimo matrica padeda pastebėti būdingas klaidas:

• Naršymas toje pačioje svetainėje su atidarytu ir uždarytu pokalbio langu,
• Grįžimas toje pačioje naršyklėje prieš ir po neaktyvumo limito,
• Grįžimas privačiame lange arba ištrynus vietinius naršyklės duomenis,
• Įrenginio keitimas prieš prisijungimą, po jo ir po atsijungimo,
• Paskyros keitimas bendro naudojimo įrenginyje,
• Pasibaigusio galiojimo, jau panaudotas arba atšauktas perdavimo kodas,
• Ištrintas pokalbis, užblokuota paskyra ir pasikeitusios kliento teisės,
• Tęstinumas atnaujinus žinių bazę,
• Perdavimas žmogui su aiškiai patvirtinta santrauka ir be jos,
• Ilgi pavadinimai, kitos kalbos tekstai ir mobilieji pločiai be horizontalaus pervišio.

Kiekvienu atveju, be matomo atsakymo, tikrinamos tinklo užklausos, sesijos anuliavimas, klaidų žurnalai ir analitikos įvykiai. Chatbot gali mandagiai paaiškinti, kad kontekstas nepasiekiamas. Tačiau jis niekada neturi jo atkurti iš panašių vartotojo duomenų ar priskirti kitam asmeniui.

Išvada: tęstinumas yra kontroliuojamas perdavimas

Gera pokalbio tęsimo patirtis nereiškia, kad viskas saugoma amžinai. Tai reiškia tik tikslaus, minimalaus konteksto pernešimą per aiškiai apibrėžtą atstumą. Tai pačiai naršyklei, prisijungusiam antrajam įrenginiui ir klientų aptarnavimo kanalui reikia skirtingų pasitikėjimo ir galiojimo taisyklių. Kai pokalbio būsena, tapatybė ir teisės išlieka atskirtos, sukuriamas patogumas be tylaus duomenų atskleidimo.

Tie, kurie šias taisykles anksti įdiegia į Conversational UX, gali sumažinti nutrūkusių sesijų skaičių ir padaryti perdavimą klientų aptarnavimui aiškesnį. ChatReact funkcijos pateikia svetainių pokalbių botų galimų komponentų apžvalgą; konkrečią sesijų ir duomenų apsaugos konfigūraciją reikėtų suplanuoti bei išbandyti atsižvelgiant į savo naudojimo atvejį.

Šaltiniai

• NIST SP 800-63B: Session Management
• NIST SP 800-63C: Customer Experience
• OWASP Session Management Cheat Sheet
• MDN: Web Storage API
• EUR-Lex: Bendrasis duomenų apsaugos reglamentas, 5 straipsnis