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

ROMI

Идентификатор сессии (Session ID, SID) — это уникальная строка, по которой сервер «узнаёт» пользователя между несколькими HTTP-запросами и связывает их с одним сеансом (корзина, авторизация, настройки и т. п.). Сам идентификатор — лишь ключ; состояние (данные сессии) обычно хранится на сервере.

Примеры форматов: c1f9e4a1b2... (hex), Y2FjZ... (Base64), UUID (b1c2...-...). Надёжный SID должен иметь случайность ≥128 бит.

Где и зачем он используется

Авторизация/личный кабинет: после логина сервер помнит, кто вы;
Корзина, настройки, шаги мастера: клик за кликом — в рамках одной сущности;
A/B-тесты, аналитика: связывает события в один сеанс (не путать с «client id»);
API/мобильные приложения: близкая роль у токенов доступа.

Как передается SID

1. Cookie (стандарт в вебе)

Сервер отвечает: Set-Cookie: session_id=abc123...; Path=/; HttpOnly; Secure; SameSite=Lax; Max-Age=1800
Браузер автоматически шлёт cookie в следующих запросах:
Cookie: session_id=abc123...

2. URL-параметр (устаревшая/вынужденная практика)

https://site.ru/catalog?session=abc123
Риск утечки в логи/рефереры и проблемы для SEO → избегать.

3. Заголовок/тело запроса (чаще для SPA/API)

Например, Authorization: Bearer <token>.

Где хранится «сессия»

На сервере: RAM/файл/Redis/БД по ключу = SID (надежно, можно принудительно завершить);
Целиком в токене (JWT): данные сессии внутри подпсанного токена → сервер «без памяти». Плюсы — масштабирование; минусы — сложно отозвать токен до истечения срока.

Жизненный цикл

Создание: при первом визите/после логина;
Продление (sliding): таймаут (например, 30 мин) продлевается активностью;
Перевыпуск (rotation): при входе/повышении прав/подозрении — выдать новый SID;
Завершение: логаут, неактивность, истечение срока, серверная инвалидация.

Безопасность: типовые риски и защита

Риски

Перехват/подмена (hijacking) через XSS/несекюрный транспорт;
Фиксация сессии (session fixation) — навязанный злоумышленником SID до логина;
Утечка через URL/рефереры/логи при передаче SID в строке запроса;
Предсказуемость SID — слабая генерация.

Защита (обязательно)

Только HTTPS;
Cookie-флаги: HttpOnly, Secure, SameSite=Lax/Strict (для SSO/платежей — аккуратно);
Rotation SID после логина/эскалации прав;
Короткий TTL и sliding по активности;
SID = непрозрачный случайный токен (не JWT) для веб-сессий авторизации; в cookie не хранить PII/права;
Защита от XSS/CSRF (CSP, escaping, CSRF-токены);
Ограничения по устройствам/IP, уведомления о новых входах, серверный logout all;
Для JWT: короткий срок жизни, ротация + refresh-токены, список отозванных (revocation list).

Идентификатор сессии, analytics и авторизация

Session ID (auth) — привязывает запросы к сеансу авторизованного/анонимного пользователя на вашем сервере;
Client/User ID (аналитика) — псевдо-идентификатор в системе аналитики (GA/Метка), живёт долго, может переживать много сессий;
Session ID (аналитики) — агрегирует хиты в «сеанс» внутри инструмента аналитики и не управляет авторизацией.

Влияние на SEO

1. SID в URL — дубли страниц, «пыль» индекса, утечки параметров.

Рекомендации:

используйте cookie, а не URL-параметры;
если параметр неизбежен — ставьте rel="canonical" на «чистый» URL, добавляйте noindex/nofollow нужным ссылкам, не генерируйте внутренние ссылки с ?session=...;
фильтруйте такие URL в аналитике и логах.

2. Коды ответов/редиректы при истечении сессии не должны ломать индексацию (не отдавайте 302/401 для общедоступных страниц без нужды).

Частые ошибки

Хранение SID в локальном хранилище (доступно JS → уязвимо к XSS);
Долгоживущие сессии без ротации после логина;
Отсутствие флагов Secure/HttpOnly/SameSite;
Передача SID в URL и рассылках;
Использование JWT как cookie-сессии без механизма отзыва;
Смешение «авторизационной» и «аналитической» сессий в отчетах.

Мини-чек-лист внедрения

SID генерируется криптостойко (≥128 бит случайности);
Передаётся cookie с HttpOnly; Secure; SameSite=Lax/Strict; Path=/; + разумный Max-Age;
Ротация SID при логине/смене ролей; logout инвалидирует серверные данные;
Сессии хранятся на сервере (Redis/БД), данные в cookie не кладём;
Для SPA/API — короткоживущие access-токены + refresh-токены; чёрные списки;
Нет SID в URL и внутренних ссылках; каноникал на чистые URL;
Таймауты: интерактивные 15–30 мин простоя, «remember me» — отдельный, с усиленной защитой;
Логи/аудит входов, защита от XSS/CSRF включена.

Вывод

Идентификатор сессии — ключ к состоянию пользователя между запросами. Делайте его случайным и короткоживущим, передавайте только в защищённой cookie с правильными флагами, храните состояние на сервере, регулярно ротируйте и не допускайте SID в URL. Это одновременно повышает безопасность, стабильность продукта и чистоту SEO.