Продължаване на разговори с чатбот: Сесии, смяна на устройства и сигурно предаване

Посетител задава три въпроса в уебсайт чатбота, преминава към продуктовата страница и по-късно се връща. Клиентка започва на смартфона и иска да продължи на лаптопа. В поддръжката най-накрая се включва човек. И в трите случая очакването е едно и също: разговорът трябва да продължи смислено. От техническа и организационна гледна точка обаче това са три различни задачи. Всеки, който ги смесва, рискува загуба на контекст, нежелано споделяне на данни или сесия, която остава активна по-дълго от необходимото.

„Продължаване“ не е същото като „разпознаване“

За планирането помага ясното разграничаване на три нива на приемственост:

1. В рамките на едно посещение: Разговорът се запазва, докато някой навигира между страниците или затваря и отваря отново прозореца на чата.
2. При последващо завръщане: Същият браузър намира отново предишен разговор в рамките на ограничен срок.
3. Mежду различни устройства: Дадено лице продължава разговора в друг браузър или на друго устройство. За целта обикновено е необходима надеждна връзка с профил или съзнателно задействан, краткотраен процес на прехвърляне.

Наличието на история на разговора все още не е доказателство за самоличност. Всеки, който притежава ID на разговор или линк, не трябва автоматично да получава достъп до поръчки, договорни данни или лична информация. Това е същата основна граница, която важи и при разделянето на публичния чатбот от автентикирания клиентски портал: контекстът може да създаде удобство, но не замества влизането в профила и проверката на правата.

Техническата основа: Референция в браузъра, състояние на сървъра

Надеждната архитектура съхранява в браузъра по възможност само случайна, непрозрачна референция. Съответното състояние на разговора се намира на сървъра и при всяка заявка се проверява за валидност, клиентски профил, права и дата на изтичане. Препоръките на OWASP за Session Management съветват да се използват безсмислени, трудни за отгатване идентификатори на сесии и контролирани от сървъра времеви лимити. Освен това идентификаторите на сесии нямат място в URL адресите: те могат да бъдат предадени чрез историята, логовете, referrer или споделени линкове.

Паметта на браузъра има различен обхват. Според MDN Web Storage API sessionStorage е обвързан с раздела и произхода и обикновено приключва със затварянето на раздела. localStorage, от друга страна, се запазва между различните сесии на браузъра, но отново само в рамките на същия профил на браузъра. Нито едното, нито другото не създава идентичност между различни устройства. Директното записване на чувствителни транскрипти или постоянни токени за достъп там увеличава последствията при неоторизиран достъп до скрипта или устройството.

Какви данни трябва да съдържа състоянието

За да предложи полезно продължаване, системата често се нуждае от по-малко от пълен транскрипт. Компактен набор от данни за състоянието с версия може да бъде напълно достатъчен:

• текущото запитване и потвърдената цел,
• вече изяснени, нечувствителни факти,
• отворени въпроси и следващата логична стъпка,
• използвани източници на знания или техните версии,
• статус на съгласие, автентификация и Handoff,
• момент на последната активност, както и определена дата на изтичане.

По този начин разговорът може да продължи свързано, без да се копира всяко предишно съобщение за неограничено време в активния промпт. Пълната история може да се съхранява отделно, в по-кратък вид или изобщо да не се пази – в зависимост от целта, очакванията на потребителя и установените правила. За личните данни важни принципи за проектиране са най-вече ограничението на целите, свеждането на данните до минимум и ограничението на съхранението от член 5 от GDPR. Това не замества индивидуалната правна консултация, но дава ясно продуктово изискване: съхранявайте само онова, което наистина е необходимо за посочената цел.

Различно третиране на анонимни и логнати разговори

Анонимно завръщане в същия браузър

При анонимни посетители функцията „Продължаване на разговора“ трябва да остане ограничена функция за удобство. Разумно е да има кратък срок на съхранение, добре видима команда за изтриване и обяснение, че историята може да бъде намерена отново само в този браузър. Чатботът не трябва да дава заключение от повторното идване, че пред него седи същото физическо лице. След изтичане на срока или при загуба на локалната референция започва нова сесия.

На практика при завръщане чатботът може да попита: „Искате ли да продължите разговора си за избор на продукт, или да започнете нов?“ Това е по-добре, отколкото мълчаливо да активирате стария контекст. На споделени устройства това потвърждение предотвратява възможността следващият човек веднага да види съдържание, което не го засяга.

Смяна на устройство с влизане в профила

Приемствеността между устройствата трябва да бъде обвързана с потвърден профил и неговите текущи права. След влизане в профила сървърът зарежда само разговори, които са асоциирани с този профил и правилния клиент. При чувствителни действия – като промяна на адрес, справка по договор или поръчка – е разумно да се направи повторна автентификация, дори ако общият чат все още е активен.

Текущото указание на NIST SP 800-63B за управление на сесиите описва сесиите като връзка между автентикирано лице и услуга чрез тайна на сесията. То изисква както времеви лимити за неактивност, така и общи времеви лимити, както и прекратяване от страна на сървъра. За продуктовите екипи от това следва: „влезли в профила“ не трябва да бъде неограничено състояние, а изтекъл токен за профила или сесията не трябва да се възстановява чрез все още налична история на чата.

Код за прехвърляне само като строго ограничен мост

Някои услуги искат да позволят анонимна смяна чрез еднократен код или QR код. В такъв случай кодът трябва да бъде краткотраен, за еднократна употреба и с възможност за анулиране. Той не съдържа нито транскрипт, нито клиентски данни, а само случайна референция към одобрено, минимално състояние на разговора. След успешно прехвърляне старата референция става невалидна. Кодът е мост за контекста, а не доказателство за самоличност или за достъп до чувствителни данни в профила.

Правилата за изтичане трябва да са разбираеми в интерфейса

Техническите времеви лимити решават само половината от задачата. Потребителите трябва да знаят дали и колко дълго се запазва разговорът им. На насоките на NIST за Customer Experience наблягат на ясната информация относно края на сесията, за да не се губи извършена работа и хората да не прибягват до несигурни заобиколни начини.

Поради това добрата концепция за изтичане на сесиите отговаря директно в чата на следните въпроси:

• Запазва ли се разговорът след затваряне?
• Това важи ли само за този браузър или и след влизане в профила на други устройства?
• Кога сесията приключва поради неактивност и кога се изтрива запазената история?
• Кои части потребителят може сам да премахне или експортира?
• Какво се случва с отворен казус за поддръжка след изтичането?

Преди очаквания край на сесията дискретно известие може да предложи да се запази наличната информация или да се препредаде на поддръжката. След изтичането интерфейсът трябва ясно да прави разлика между „Сесията е прекратена“ и „Историята е изтрита“. Едното засяга достъпа, другото – съхранението.

Human Handoff: Предаване на контекста, показване на отговорността

При преминаване към човек краткото структурирано резюме често е по-ценно от некоментирана дълга история. То посочва запитването, потвърдените данни, вече предложените стъпки, отворения въпрос и използваните източници. Чувствително съдържание се предава само ако е необходимо за случая на поддръжка и е одобрено за това.

Потребителят трябва да види, че сега поема човек, каква информация се предава и дали възниква ново време за изчакване. В същото време изкуственият интелект трябва да знае след предаването дали трябва да мълчи, да помага само организационно или да поеме отново по-късно. Конкретни тригери и правила за ескалация са описани в статията за Human Handoff в уебсайт чатбота.

Внедряване в шест стъпки

1. Дефиниране на сценариите за използване: Специфицирайте отделно навигацията в сайта, последващото завръщане, смяната на устройството и предаването на човек.
2. Определяне на нивата на доверие: Установете кое съдържание е достъпно анонимно, кое след свързване с профил и кое едва след повторна автентификация.
3. Минимизиране на състоянието: Проектирайте структурирано Resume-State с цел, потвърдени факти, отворени точки и време на изтичане.
4. Налагане на жизнен цикъл: Тествайте на сървъра лимита за неактивност, абсолютния лимит, изтриването, анулирането и излизането от профила.
5. Оформяне на прехвърлянията: Направете видими потвърждението от потребителя, резюмето за поддръжката, статуса на чакане и отговорността.
6. Измерване на успеха без пълен текст: Отчитайте събития като „Предложено продължаване“, „Прието“, „Изтекло“, „Завършена смяна на устройство“ и „Успешен Handoff“. Как става това с пестене на данни показва ръководството за Analytics за AI чатботове.

Тестова матрица за десктоп, мобилни устройства и реални гранични случаи

Преди официалното пускане трябва да работи не само стандартният идеален сценарий. Малка тестова матрица покрива типичните грешки:

• Навигация в рамките на същия уебсайт с отворен и затворен прозорец на чата,
• Завръщане в същия браузър преди и след лимита за неактивност,
• Завръщане в частен прозорец или след изтриване на локалните данни на браузъра,
• Смяна на устройството преди и след влизане в профила, както и след излизане,
• Смяна на профила на споделено устройство,
• Изтекъл, вече използван или анулиран код за прехвърляне,
• Изтрит разговор, блокиран профил и променени права на клиента,
• Продължаване след актуализация на базата от знания,
• Handoff с и без изрично одобрено резюме,
• Дълги заглавия, езици с различна дължина на текста и мобилни ширини без хоризонтално преливане.

При всеки случай, освен видимия отговор, към проверката спадат и мрежовите достъпи, инвалидирането на сесията, логовете за грешки и събитията в Analytics. Чатботът може любезно да обясни, че даден контекст вече не е наличен. Той обаче никога не трябва да го възстановява от подобни потребителски данни или да го причислява към нов човек.

Заключение: Приемствеността е контролирано предаване

Доброто изживяване при продължаване на разговора не означава запазване на абсолютно всичко завинаги. То означава пренасяне на правилния, минимален контекст през ясно ограничен участък. Същият браузър, логнато второ устройство и човешки канал за поддръжка се нуждаят от различни правила за доверие и изтичане за тази цел. Когато състоянието на разговора, самоличността и правата останат разделени, се получава удобство без мълчаливо споделяне на данни.

Всеки, който внедри тези правила рано в Conversational UX, може да намали прекъсванията на сесиите и да направи предаването към поддръжката по-разбираемо. Функциите на ChatReact дават преглед на възможните градивни елементи за уебсайт чатботове; конкретната конфигурация на сесиите и защитата на данните следва да бъде планирана и тествана спрямо собствения конкретен случай.

Източници

• NIST SP 800-63B: Session Management
• NIST SP 800-63C: Customer Experience
• OWASP Session Management Cheat Sheet
• MDN: Web Storage API
• EUR-Lex: Общ регламент относно защитата на данните, Член 5