Проще говоря, сессия отвечает на вопрос: что происходило с этим посетителем прямо сейчас. Он пришел из рекламы, открыл страницу услуги, задал вопрос в виджете, получил ответ, оставил email и был передан менеджеру. Без сессии эти действия распадаются на отдельные события, и агент не понимает контекст.
Сессия обычно имеет session_id. Иногда рядом есть visitor_id, который помогает узнать возвращающегося посетителя, и user_id, если человек авторизован. Эти идентификаторы лучше не смешивать. Session_id описывает визит, visitor_id - браузер или устройство, user_id - конкретного известного пользователя.
Для AI-агента сессия важна потому, что она связывает conversation context с поведением на сайте. Агент может видеть, с какой страницы пришел вопрос, какие UTM-метки были у перехода, какие товары или статьи смотрел человек, был ли уже handoff и можно ли запрашивать контакт.
Сессия посетителя не равна cookie. Cookie может хранить идентификатор или настройки в браузере, а сессия - это серверная или аналитическая запись о событиях визита. Cookie может помочь восстановить session_id, но сама по себе не содержит весь контекст.
Сессия также не равна долговременной памяти. Память может сохранять устойчивые факты между визитами, например предпочтения пользователя. Сессия живет ограниченное время: до закрытия диалога, истечения тайм-аута или завершения визита. В ней не стоит хранить лишние персональные данные.
Для первого AI-виджета достаточно хранить: session_id, visitor_id, текущий URL, referrer, UTM-метки, timestamp, сообщения, consent, статус диалога, source page, agent_run_id, handoff_status и краткое summary для менеджера. Этого хватает, чтобы не потерять контекст и не превращать виджет в черный ящик.
Главный риск - собирать больше данных, чем нужно. Если сессия хранит телефон, email, переписку, IP, UTM и историю страниц, нужно явно понимать цель обработки, срок хранения, доступы и правила удаления. AI-агент не должен использовать сессионные данные для скрытой персонализации или передачи в CRM без понятного основания.
Примеры
- Посетитель пришел по UTM-метке из рекламы, открыл страницу услуги и написал в чат: "Сколько стоит внедрение?". Сессия связывает источник, страницу и вопрос в один контекст.
- AI-виджет передает менеджеру handoff summary: session_id, URL страницы, последние сообщения, интерес пользователя и контакт, который он оставил с consent.
- Пользователь обновил страницу во время диалога. Благодаря session_id виджет восстановил историю сообщений и не начал разговор заново.
- В интернет-магазине сессия показывает, что посетитель смотрел две карточки товара, спросил про доставку и оставил email. Агент может передать менеджеру не просто email, а полный контекст интереса.
Где используется
- сохранение истории диалога в чат-виджете
- передача контекста менеджеру при handoff
- связка UTM-меток с вопросами посетителя
- lead capture на сайте
- аналитика поведения посетителей
- персонализация ответа в рамках текущего визита
- поиск проблемных сценариев в AI-виджете
- связь agent runs с конкретным диалогом
Связанные термины
Частые вопросы
Чем сессия посетителя отличается от пользователя?
Сессия описывает один визит или диалог. Пользователь - это известный человек или аккаунт. Один пользователь может иметь много сессий, а анонимная сессия может существовать без user_id.
Чем session_id отличается от visitor_id?
Session_id обычно относится к одному визиту или диалогу. Visitor_id помогает связать несколько визитов одного браузера или устройства. В AI-виджете оба идентификатора полезны, но их не стоит смешивать.
Какие данные хранить в сессии AI-виджета?
Минимум: session_id, текущий URL, referrer, UTM-метки, timestamp, сообщения, consent, статус диалога, agent_run_id и handoff summary. Контакты и персональные данные храните только при понятной цели и согласии.
Можно ли использовать сессию для персонализации ответа?
Да, но только в рамках понятного контекста: страница, вопрос, выбранный товар, язык, регион или предыдущие сообщения. Не стоит делать скрытую персонализацию на чувствительных данных без прозрачных правил.
Когда сессию нужно завершать?
Обычно сессию закрывают после тайм-аута без активности, завершения диалога, успешного handoff или явного действия пользователя. Для отчетности важно фиксировать статус: resolved, abandoned, handoff или lead_created.