Что хранить в сессии и аккаунте: простые правила

Почему возникает путаница

Путаница начинается не с данных, а с привычки. Команда думает: если запись помогает пользователю прямо сейчас, значит, ее надо сохранить. Потом выясняется, что одни данные нужны на пять минут, а другие человек ожидает увидеть через месяц, уже с другого устройства.

Сессия живет недолго. Пользователь закрыл вкладку, вышел из аккаунта, почистил браузер или просто давно не заходил - и часть состояния пропала. Это нормально для временных вещей: открытого шага формы, выбранного фильтра, черновика, который нужен только до отправки.

Аккаунт работает иначе. Он переживает новый телефон, переустановку приложения и длинный перерыв. Если человек однажды выбрал язык интерфейса, часовой пояс или формат уведомлений, он ожидает, что эти настройки останутся. Иначе сервис кажется сломанным, хотя формально все работает.

Сложность в том, что одна и та же запись может быть полезной и при этом рискованной для постоянного хранения. История задач - хороший пример. Пользователю удобно вернуться к прошлым действиям, посмотреть, что он запускал вчера, и повторить шаги. Но если в названии задачи, комментарии или фрагменте текста лежат персональные или рабочие данные, постоянное хранение уже меняет уровень риска.

Часто проблема начинается в тот момент, когда временные данные вдруг начинают вести себя как постоянные. Черновик "на время" появляется после входа с другого ноутбука. Последний запрос "только для текущей работы" попадает в общую историю аккаунта. Пользователь этого не просил, но система уже решила за него.

В продуктах с задачами, документами или LLM-запросами это случается постоянно. Человек вставил кусок договора или номер клиента, чтобы решить разовую задачу, а сервис сохранил это навсегда ради удобства. Для российского рынка здесь быстро появляется и правовой вопрос: чем дольше вы храните такие данные, тем труднее объяснить, зачем они вообще нужны.

Граница между сессией и аккаунтом ломается не на уровне кода. Она ломается в момент, когда временное удобство тихо превращают в постоянную память.

Что обычно хранить в сессии

В сессии держат то, что нужно прямо сейчас и быстро теряет смысл после паузы, выхода или завершения действия. Это временное состояние экрана, процесса или диалога, а не личная память приложения.

Проверка простая: если человек закрыл вкладку, вернулся через день и спокойно пережил потерю этих данных, сессии достаточно. Если потеря вызовет вопросы или сломает привычный сценарий, хранить это только в сессии уже рискованно.

Обычно сюда относятся выбранная вкладка, сортировка, фильтр, номер страницы в списке, шаг мастера, черновик формы до отправки, временный контекст задачи или чата, короткоживущие токены и служебные флаги вроде "подсказку уже показали" или "запрос выполняется".

Такие данные делают интерфейс спокойнее. Человек открыл кабинет, настроил список задач по статусу, перешел в карточку и вернулся назад. Если фильтр и сортировка сохранились, работа не сбивается. Но хранить это на аккаунте для всех будущих входов обычно не нужно. Завтра у него может быть совсем другой сценарий.

С черновиками правило чуть строже. Пока форма не отправлена, черновик можно держать в сессии, если он живет недолго и не содержит ничего чувствительного. Например, текст комментария, выбранный тариф или несколько полей заявки. Но если человек тратит на форму 20 минут, потеря данных уже раздражает. Тогда команды часто добавляют автосохранение, и это уже не просто сессия, а отдельный объект со своим сроком жизни.

С токенами и флагами состояния нужна дисциплина. В сессии стоит держать только короткоживущие данные для текущего шага. Чем меньше срок жизни, тем лучше. Если настройка ломает работу после обновления страницы или требует "помнить все всегда", значит, в сессию положили слишком много.

Что лучше хранить на аккаунте

На аккаунте хранится то, что человек считает "своим" и ожидает увидеть после выхода, на другом устройстве и через неделю. Если данные должны пережить новую сессию, их лучше привязать к профилю пользователя.

Сюда почти всегда относятся личные настройки аккаунта: язык интерфейса, тема, формат уведомлений, часовой пояс. Пользователь не хочет выбирать это заново после каждого входа. Такие вещи должны работать предсказуемо и одинаково на телефоне, ноутбуке и рабочем компьютере.

К аккаунту часто относится и список последних задач, если к нему возвращаются позже. Не нужно хранить весь шум за день. Обычно хватает короткой истории: недавние проекты, черновики, последние фильтры или открытые карточки. Это удобно, когда человек начал работу утром, а продолжил вечером с другого устройства.

Сохраненные шаблоны и пресеты тоже лучше хранить на аккаунте. Если пользователь один раз настроил шаблон ответа, экспорт, набор полей или режим поиска, он ожидает найти это снова. Иначе функция быстро теряет смысл.

Настройки доступа почти всегда живут на аккаунте. Права, роли, видимость данных и список разрешенных действий не должны зависеть от одной сессии. Если менеджер получил доступ к разделу на ноутбуке, тот же доступ должен работать и в мобильной версии.

История действий тоже часто привязана к аккаунту, если она нужна для отчета, поддержки или разбора спорных случаев. Для рабочего сервиса это обычная практика. Когда пользователь пишет в поддержку "я ничего не менял", команде нужен понятный журнал: кто вошел, что изменил, когда удалил, какой шаблон запускал.

Полезная проверка короткая:

• данные нужны после выхода из системы;
• они должны синхронизироваться между устройствами;
• пользователь будет использовать их повторно;
• они влияют на права доступа или безопасность;
• они нужны для поддержки, отчета или внутренней проверки.

Если совпали хотя бы два пункта, хранение на аккаунте обычно оправдано. Сессия подходит для временного состояния. Аккаунт - для того, что должно остаться с пользователем и не исчезнуть после закрытия вкладки.

Куда отнести чувствительные данные

При выборе между сессией и аккаунтом чувствительные данные лучше сразу вынести в отдельную категорию. Для них почти всегда нужны свои правила хранения, доступа и удаления. Если смешать их с обычными настройками или историей действий, риск утечки быстро растет.

Пароли не хранят ни в сессии, ни в профиле пользователя. Приложение должно хранить только хеш пароля с солью. Полные платежные реквизиты тоже не стоит держать рядом с аккаунтом: для карты обычно оставляют только маску вроде последних четырех цифр и технический идентификатор у платежного провайдера.

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

Паспортные данные, ИНН, адрес, телефон и другие персональные данные храните только там, где без них нельзя выполнить задачу. Если функция работает без полного паспорта, не запрашивайте его "на всякий случай". Лишние данные почти никогда не помогают продукту, зато почти всегда добавляют проблемы юристам, поддержке и разработке.

Если сервис работает в РФ, это еще и вопрос нормальной операционной дисциплины. Например, в RU LLM маскирование PII и аудит-трейлы встроены на уровне запросов, потому что логи очень быстро разрастаются и в них легко оказываются поля, которые никто не собирался хранить.

Практичное правило

Для чувствительных данных полезно отвечать на четыре вопроса: нужно ли это для работы функции прямо сейчас, кто реально должен это видеть, сколько дней запись должна жить и можно ли хранить маску или ссылку вместо полного значения.

Хороший пример - история задач в личном кабинете. Сам факт, что пользователь запускал задачу, можно хранить в аккаунте. Но если в содержимом задачи есть паспорт, номер карты или токен интеграции, такие поля лучше не показывать в истории целиком и не писать в логи без маски.

Лишние данные удаляйте по сроку хранения, а не вручную "когда доберемся". Ручная чистка почти всегда запаздывает. Намного надежнее задать срок для каждого типа данных: токен - на часы или дни, черновик - на месяц, документы - только на период, когда они нужны для проверки. Это проще контролировать и легче объяснить на аудите.

Как принять решение по шагам

Когда вы решаете, куда положить данные, не начинайте с таблиц и полей. Сначала ответьте на простой вопрос: что сломается для пользователя, если он закроет приложение прямо сейчас?

Если объект нужен только до конца текущего входа, ему обычно место в сессии. Если человек ожидает увидеть его завтра, после повторного входа или на другом устройстве, это уже данные аккаунта.

Дальше помогает короткая проверка:

1. Переживет ли эта вещь выход из системы? Корзина на 10 минут, открытый фильтр или черновой шаг мастера часто живут в сессии.
2. Нужен ли тот же объект на телефоне и ноутбуке? Если да, храните его на аккаунте.
3. Какова цена ошибки? Если случайное удаление раздражает, но не вредит, правила мягче. Если утечка бьет по деньгам, репутации или приватности, храните меньше и строже ограничивайте доступ.
4. Какой у записи срок жизни? Не "потом почистим", а конкретно: 30 минут, 7 дней, 6 месяцев.
5. Это удобство или обязательная часть функции? Темную тему и язык интерфейса можно хранить долго. Одноразовый токен подтверждения или временный код - нет.

Есть и еще один полезный тест: представьте две неприятные ситуации. Первая - данные утекли. Вторая - данные исчезли. Сравните ущерб в каждом случае. Историю задач, список сохраненных проектов и личные настройки аккаунта обычно неприятно терять, поэтому их сохраняют дольше. Паспортные данные, платежные реквизиты, медицинские заметки и другие чувствительные поля требуют другого подхода: минимальный объем, короткий срок, понятная причина хранения.

На практике это выглядит просто. Пользователь выставил язык, часовой пояс и формат даты - это аккаунт. Он открыл форму, ввел половину текста и отвлекся на звонок - это сессия или короткий черновик с ясным сроком удаления. История выполненных задач нужна через неделю и на втором устройстве - значит, ей место в аккаунте.

Если сомневаетесь, храните меньше. Лишние данные редко радуют, а проблем создают много.

Пример: кабинет с историей задач

Представьте рабочий кабинет, где пользователь собирает отчет, меняет тему интерфейса и иногда возвращается к старым задачам. На таком примере быстро видно, что держать в сессии, что хранить на аккаунте, а что лучше вообще не тащить в историю.

Тема оформления и язык интерфейса почти всегда живут на аккаунте. Человек ожидает, что после нового входа, с другого ноутбука или через неделю кабинет откроется так же, как он настроил раньше. Это личные настройки аккаунта, и они не зависят от одной попытки работы.

Теперь другой случай. Пользователь начал собирать отчет, заполнил половину формы и отвлекся. Черновик, выбранные фильтры, временный шаг мастера и несохраненные поля лучше держать в сессии. Если вкладка случайно обновится, сессия поможет не потерять прогресс. Но после долгого простоя или выхода из аккаунта такой черновик может исчезнуть, и это нормально.

С историей задач логика обратная. Если человек хочет через неделю открыть уже выполненную задачу, посмотреть статус, дату отправки и результат, история должна быть на аккаунте. Иначе кабинет будет казаться ненадежным: сегодня задача есть, завтра ее нет.

Схема простая: настройки темы и языка - на аккаунте; незавершенный отчет и черновик формы - в сессии; список выполненных задач и их статусы - на аккаунте; чувствительные поля из формы - только там, где без них нельзя завершить действие.

Отдельно проверьте поля с чувствительными данными. Если в форме есть номер карты клиента, не копируйте его в историю задачи, комментарии, уведомления и журналы просто "на всякий случай". После отправки обычно хватает безопасных меток: номера задачи, времени, статуса, типа операции и, если нужно, маски вроде последних четырех цифр.

Такой подход делает кабинет чище и спокойнее для пользователя. Все, что помогает продолжить текущий шаг, живет в сессии. Все, что должно пережить новый вход и остаться частью личного опыта, хранится на аккаунте.

Ошибки, которые делают почти все

Когда команда выбирает, где хранить данные, она часто идет по самому простому пути и записывает в аккаунт почти все. Так в профиле оседают временные вещи, которые нужны на пару минут: выбранная вкладка, разовый фильтр, черновик поиска, порядок колонок для одной страницы. Через неделю человек открывает сервис на другом устройстве и видит старое состояние, которое уже потеряло смысл.

Такой перекос особенно заметен в кабинете с историей задач. Пользователь один раз отсортировал список по дате, открыл конкретную задачу и ввел черновик комментария. Если приложение записало это в аккаунт как постоянную настройку, оно начинает тащить случайный контекст за человеком повсюду. В итоге настройка профиля смешивается с состоянием одной страницы, и интерфейс кажется капризным.

Есть и другая крайность: слишком долгая сессия. Если токен, черновики и последнее действие держатся неделями, сессия уже не выглядит временной. На личном ноутбуке это раздражает, а на общем устройстве это просто риск. Человек вышел из задачи вчера, а приложение все еще помнит детали сегодня, хотя не должно.

Обычно ошибки выглядят так:

• язык, тема, часовой пояс и уведомления хранят как попало, хотя это данные аккаунта;
• фильтры таблицы, раскрытые блоки и шаг текущего мастера сохраняют слишком надолго;
• несохраненные поля формы тянут между входами, хотя они нужны только в рамках одного визита.

Еще одна частая ошибка - полные логи. Разработчикам удобно писать в журнал весь запрос, весь ответ и все поля формы. Но вместе с отладкой в логах остаются телефон, почта, части документов, тексты задач и другие чувствительные данные. Для сервисов с российским контекстом это быстро упирается и в безопасность, и в требования 152-ФЗ. Маскировать такие поля нужно до записи, а не потом.

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

Быстрая проверка перед запуском

Перед релизом полезно пройтись не по экрану, а по каждой записи, которую вы собираетесь хранить. Обычно хватает пяти вопросов. Если команда не может ответить на них за минуту, схема хранения еще сырая.

1. Что случится, если запись пропадет после закрытия вкладки? Если пользователь почти не заметит потерю, храните это в сессии. Если он вернется и будет ждать те же данные, переносите на аккаунт.
2. Должен ли человек увидеть это после входа с другого устройства? Фильтр задач, язык интерфейса, тема, история действий и сохраненные черновики чаще живут на аккаунте. Временный шаг мастера, открытая вкладка или разовый токен обычно нет.
3. Сможет ли поддержка объяснить, зачем запись вообще существует? Хороший ответ занимает одну фразу. Плохой обычно звучит так: "на всякий случай".
4. Есть ли у записи срок жизни и человек, который отвечает за удаление? Не пишите "удалим потом". Напишите конкретно: сессия живет 12 часов, лог ошибки - 30 дней, удаленный черновик - 7 дней до очистки.
5. Убрали ли вы лишнее из логов и экспорта? Чаще всего туда случайно попадают email, телефоны, фрагменты документов, промпты и токены доступа. Если поле не помогает чинить проблему или выполнять законное требование, его лучше не сохранять.

Это особенно часто ломается в AI-продуктах. Промпт выглядит как обычный текст, но в нем легко оказываются персональные данные, номера договоров и внутренняя переписка. Если вы используете шлюз вроде RU LLM, проверьте, что маскирование PII настроено, а аудит-трейлы не дублируют пользовательский контент без причины.

Хорошая финальная проверка тоже простая: возьмите одну реальную запись из базы, один лог и один файл экспорта. Пусть продукт, поддержка и разработчик отдельно ответят, зачем это хранится, кто это видит и когда запись исчезнет. Если ответы расходятся, лучше притормозить выпуск на день, чем потом месяц чистить лишние данные.

Что сделать дальше

После всех правил нужен один практичный шаг: соберите список полей, которые хранит приложение. Не на уровне экранов, а на уровне конкретных данных. Например: тема интерфейса, последний открытый фильтр, история задач, номер телефона, комментарий к задаче, токен входа.

У каждого поля сразу пометьте четыре вещи: где оно живет, зачем нужно, сколько хранится и кто к нему имеет доступ. Такая простая таблица быстро показывает, что должно лежать в сессии, что - в аккаунте, а что вообще не стоит сохранять без явной причины.

Дальше пройдитесь по данным в одном порядке. Сначала вынесите в отдельный список все поля, которые видит пользователь, и все поля, которые пишет система. Затем для каждого поля укажите место хранения: сессия, аккаунт, база истории или отдельное защищенное хранилище. После этого задайте срок жизни отдельно для сессии, истории задач и логов - у них почти никогда не должен быть один срок на все. И в конце проверьте, попадает ли поле в резервные копии, аналитику, экспорт отчетов и служебные журналы.

Именно на этом этапе обычно всплывают странные вещи. Команда удаляет поле из основной базы, но забывает про бэкапы. Или не хранит чувствительные данные в профиле, зато отправляет их в аналитику вместе с событиями. Такие утечки чаще появляются не в основном хранилище, а вокруг него.

Сроки хранения лучше задавать раздельно. Тема интерфейса может жить на аккаунте месяцами. Черновой фильтр поиска лучше держать в сессии и удалять быстро. Историю задач стоит хранить столько, сколько она реально нужна пользователю и поддержке. Логи аутентификации живут по своим правилам, а не по сроку жизни истории задач.

Если вы строите LLM-функции и работаете с персональными данными в РФ, проверьте это заранее и отдельно. Нужны понятные правила для логов, маскирования персональных данных и аудита каждого запроса. У RU LLM это уже предусмотрено на уровне API-шлюза: логи и бэкапы хранятся в РФ, а маскирование PII и аудит-трейлы встроены в обработку запросов. Но границу ответственности все равно задает ваша команда: какие поля вы отправляете в модель, какие скрываете и что пишете в логи.

Последний тест лучше делать на одном реальном действии. Пользователь входит в кабинет, открывает историю задач, меняет личную настройку, пишет комментарий и выходит. После этого у команды должен быть точный ответ: что исчезло вместе с сессией, что осталось на аккаунте и что ушло в журналы.