Http Session State. SessionID Свойство
Некоторые сведения относятся к предварительной версии продукта, в которую до выпуска могут быть внесены существенные изменения. Майкрософт не предоставляет никаких гарантий, явных или подразумеваемых, относительно приведенных здесь сведений.
Возвращает уникальный идентификатор сеанса.
public: property System::String ^ SessionID < System::String ^ get(); >;
public string SessionID
member this.SessionID : string
Public ReadOnly Property SessionID As String
Значение свойства
Уникальный идентификатор сеанса.
Примеры
В следующем примере кода показан файл Web.config, который настраивает состояние сеанса для использования идентификаторов сеансов без файлов cookie. Дополнительные сведения см. в описании свойства IsCookieless.
Комментарии
Свойство SessionID используется для уникальной идентификации браузера с данными сеанса на сервере. Значение SessionID создается случайным образом ASP.NET и сохраняется в файле cookie сеанса без истечения срока действия в браузере. Затем SessionID значение отправляется в файле cookie с каждым запросом к приложению ASP.NET.
Если вы хотите отключить использование файлов cookie в приложении ASP.NET и по-прежнему UseUriиспользовать состояние сеанса, можно настроить приложение для хранения идентификатора сеанса в URL-адресе, а не в файле cookie, задав cookieless атрибуту элемента true конфигурации sessionState значение , или значение , в файле Web.config приложения. Вы можете ASP.NET определить, поддерживаются ли файлы cookie браузером, указав значение UseDeviceProfile для атрибута cookieless . Вы также можете ASP.NET определить, включены ли файлы cookie для браузера, указав значение AutoDetect для атрибута cookieless . Если файлы cookie поддерживаются при UseDeviceProfile указании или включены при AutoDetect указании, идентификатор сеанса будет храниться в файле cookie; в противном случае идентификатор сеанса будет храниться в URL-адресе. Дополнительные сведения см. в описании свойства IsCookieless.
передается SessionID между сервером и браузером в виде файла cookie или URL-адреса. В результате нежелательный источник может получить доступ к сеансу другого пользователя, получив значение и включив SessionID его в запросы к серверу. Если вы храните частную или конфиденциальную информацию в состоянии сеанса, рекомендуется использовать SSL для шифрования любого обмена данными между браузером и сервером, включающим SessionID.
При использовании состояния сеанса на основе файлов cookie ASP.NET не выделяет хранилище для данных сеанса Session , пока не будет использован объект . В результате для каждого запроса страницы создается новый идентификатор сеанса, пока не будет получен доступ к объекту сеанса. Если приложению требуется статический идентификатор сеанса для всего сеанса, можно либо реализовать Session_Start метод в файле Global.asax приложения и сохранить данные в Session объекте для исправления идентификатора сеанса, либо использовать код в другой части приложения для явного хранения данных в объекте Session .
Если приложение использует состояние сеанса без файлов cookie, идентификатор сеанса создается в первом представлении страницы и сохраняется в течение всего сеанса.
Применяется к
См. также раздел
Идентификатор сессии
Идентификатор сессии — персональный номер, который прибавляется к URL, когда пользователь заходит на страницу с отключенным cookies.
Номер прилагается к адресу для того, чтобы можно было определить пользователя и его действия на странице: сколько и какие просмотрел, какие файлы загрузил и т.д.
Идентификатор сессии прибавляется со всем адресам на сайте, что довольно проблематично для работы поискового бота, который адреса с таким персональным номером считает за новые страницы, из-за этого в поисковой базе собирается много копий страниц, которые являются техническими дублями сайта.
В таких случаях используются особые алгоритмы, которые фиксируют идентификаторы сессий, но происходит это не всегда. Следовательно, устанавливать идентификаторы надо с осторожностью или лучше их вообще отключать.
Session id что это


Google Analytics по умолчанию предоставляет только агрегированные данные. Для того, чтобы можно было получать исходные «сырые» данные, используется несколько способов: установка отправки SessionID + UserID для каждого события, передаваемого счетчиком Google, и стриминг данных в базу данных. SessionID используется для построения моделей атрибуции, а также для удобства обработки сырых данных.
Мы столкнулись с проблемой, в которой имеющий большое распространение код для формирования SessionID перестал удовлетворять нашим требованиям. Сделали свой.
Почему возникли сложности с передачей session id в нашем случае?
Инструкцию по передаче session id и код для настройки предлагает и Симо Ахава, признанный эксперт по Google Analytics и Tag Manager. Однако его недостаток заключается в том, что код создает при каждом действии новый SessionID, не объединяя их в реальные сессии. При дальнейшем создании правил и объединении данных на их основе такая логика может оказаться подходящей. Тем не менее, мы сочли это неудобным. Наша цель была в том, чтобы SessionID присваивался корректно.
Была предпринята попытка взять данные о SessionID из файлов cookies, которые формирует Google. Оказалось, что cookie, доступные для пользователей, отдают только номера установленных счетчиков и пикселей.
Fail!
Но мы нашли решение
Мы решили написать код SessionID, который будет работать так же, как и в Google Analytics. Сессия начинается в тот момент, когда пользователь заходит на сайт, и заканчивается либо когда он закрывает браузер, либо, когда проходит 30 минут с момента его последнего действия. Ограничение в 30 минут выставляется в самом коде, и его можно менять.
Подробнее о структуре кода
Код разделен на две части: readCookie и writeCookie. При первой его активации, когда происходит загрузка сайта, код пытается «считать» SessionID из cookie-файлов. Однако мы не можем получить доступ к куки Google. Поэтому проверяем наличие записи уже своей куки. Когда код не видит SessionID, он его создает.
Здесь начинается второй этап — writeCookie. SessionID создается кодом на основе правила, указанного в предыдущем разделе. При последующих активациях кода, когда происходят любые действия пользователя на сайте, процесс повторяется. В этом случае SessionID уже создан, а значит, код просто обновляет время действия, а не создает новую сессию.
Код и инструкция к нему лежат в публичной части нашего репозитория.
Пользуйтесь и вспоминайте нас добрым словом!
Настройка Session ID в Google Analytics
![]()
Материал про настройку идентификатора сессии (Session ID) в Google Analytics с помощью Google Tag Manager.
Как вы уже знаете, в Google Analytics существуют различные области действия — Товар, Хит (обращение), Сеанс и Пользователь. Хиты привязываются к сеансам, которые принадлежат определенному пользователю, который имеет свою куку и уникальный идентификатор в системе.
Большинство отчетов в Google Analytics строятся на основе сеансов. По умолчанию в них нет детальной статистики по времени совершения какого-либо хита (с точностью до секунды). Но мы можем создать пользовательский параметр с областью действия Hit, который будет показывать точное время просмотра страницы/экрана, совершения транзакции, просмотра видео, скачивания файла, скроллинга или любого другого события. Подробнее об это вы можете прочитать в соответствующем материале.
Аналогично обстоят дела и с уникальным идентификатором пользователя (он же Client ID). С помощью одного из способов, представленного в этой статье, мы можем настроить передачу Client ID в Google Analytics в качестве пользовательского параметра с областью действия Пользователь или Сеанс. Тогда в отчетах Google Analytics вы сможете добавлять этот параметр в стандартные отчеты или специальные в качестве основного и дополнительного параметра и смотреть детально статистику конкретного пользователя (браузера/устройства!).
Еще материалы про уникальный идентификатор пользователя (Client ID):
- Cookie файлы в Google Analytics
- ClientID в Яндекс.Метрике
- Самый простой способ передачи Client ID в Google Analytics
Таким образом, у нас есть специальные параметры:
- Hit Timestamp, который позволяет получать точное время обращения любого события пользователя;
- Client ID, который дает возможность анализировать отчеты в разрезе уникального устройства и браузера пользователя.
Если построить специальный отчет, это будет выглядеть так:

Client ID и Hit Timestamp
На скриншоте синим и зеленым выделены хиты (просмотры страниц) одного и того же пользователя с Client ID (256538244.1532446839), но которые были совершены в разные сеансы, поскольку 3 состоялись в интервале с 13 до 14 часов, а еще один в 16:14:59.
Что подтвердить эту информацию, можно перейти в отчет Статистика по пользователям и посмотреть перечень хитов этого пользователя:

Статистика по пользователям
Как видим, данные с хитами по карточке пользователя сходятся со статистикой специальных параметров. Мы можем создать еще один специальный параметр, который будет называться Session ID и иметь область действия Сеанс. С его помощью можно связать хиты в сеансы и всегда знать, какое количество обращений было совершено в каждый из сеансов пользователя.
В качестве идентификатора сеанса будет использоваться случайная строка, которая отправляется при каждом просмотре страницы в Google Analytics. Поскольку вы отправляете его в специальный параметр в рамках сеанса, только последнее отправленное вами значение будет применяться к обращениям в сеансе.
Выполнять настройку Session ID будем с помощью Google Tag Manager. Для начала вам необходимо создать специальный параметр с областью действия Сеанс.

Специальный параметр Session ID
Сохраните параметр и запомните его индекс.

Индекс специального параметра
Затем перейдите в Google Tag Manager и создайте пользовательскую переменную типа Собственный код JavaScript. Вставьте нижеописанный код (оригинал):
var d = new Date (). getTime ();
if ( typeof performance !== ‘undefined’ && typeof performance.now === ‘function’)<
d += performance.now();
return 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx' . replace (/[ xy ]/ g , function ( c ) <
var r = ( d + Math . random () * 16 ) % 16 | 0 ;
d = Math . floor ( d / 16 );
return ( c === 'x' ? r : ( r & 0x3 | 0x8)).toString(16);
return new Date (). getTime () + '.' + Math . random (). toString ( 36 ). substring ( 5 );
Отличие состоит в том, какой вы получите результат. Первый код генерирует уникальный, случайный идентификатор сеанса вида xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx. Второй берет метку времени обращения в формате Unix, добавляет точку и случайную последовательность в виде букв и цифр. Поскольку используется Unix-время (с точностью до миллисекунд), то маловероятна ситуация, при которой будут созданы два одинаковых идентификатора сеанса. Результат в режиме отладке Google Tag Manager:

Режим предварительного просмотра
Есть еще более интересный формат Session ID, при котором в переменной отображается дата сеанса и случайный идентификатор сеанса через вертикальный слэш:
var currentDate = ( function () <
var today = new Date ();
var dd = today . getDate (). toString ();
var mm = ( today . getMonth ()+ 1 ). toString ();
var yyyy = today . getFullYear (). toString ();
if ( dd . length < 2 ) <
if ( mm . length < 2 ) <
return dd + mm + yyyy ;
var randomNumberString = Math . floor (( Math . random () * 10000000 ) + 1 ). toString ();
var randomEightDigitNumber = ( function () < if ( randomNumberString . length === 8 ) <
return randomNumberString ;
while ( randomNumberString . length < 8 ) <
randomNumberString = '0' + randomNumberString ;
> return randomNumberString ;
return currentDate + ‘|’ + randomEightDigitNumber ;
Вы можете использовать любой из представленных способов для своих проектов. Я применяю последний, поскольку в нем есть еще и текущая дата в формате ЧЧММГГГ. На последней стадии настройки в теге Google Analytics с типом отслеживания Просмотр страницы добавьте специальный параметр в разделе Дополнительные настройки — Специальные параметры. Задайте номер индекса в поле Индекс, который вы получили на этапе создания специального параметра в интерфейсе Google Analytics. В Значение параметра установите значение созданной переменной на предыдущем шаге.

Тег Google Analytics — Дополнительные настройки — Специальные параметры
Используя тег просмотра страницы, вы будете отправлять идентификатор сеанса (Session ID) при каждой загрузке страницы. А при выборе области действия Сеанс, когда в одном сеансе задано два значения и одним порядковым номером, приоритет отдается тому, которое задано последним! Это значение применяется ко всем обращениям на протяжении сеанса. Сохраните настройки. Проверить корректность передачи данных можно с помощью специальных расширений для браузера или режима предварительного просмотра.

Активированный тег и значения его параметров
Если сделать нижеописанное в этой статье, то вы получите такой отчет в Google Analytics:

Отчет в Google Analytics с Session ID
Дополнительно: в случае, если у вас на сайте есть личный кабинет или возможность определять пользователей в момент авторизации под своей учетной записью, то вы можете связывать воедино обращения, сеансы и Client ID с помощью четвертого специального параметра User ID (подробнее в этой статье).

User ID, Client ID, Session ID, Hit ID
Идентификатор User ID (на скриншоте = 84) хранится в базе данных сайта и принадлежит уникальному пользователю (человеку, не браузеру!). Этот пользователь заходил с разных браузеров и устройств, в результате которых создалось 2 Client ID. За это время он совершил 3 сеанса (Session ID) и n-ое количество хитов. Таким образом, после настройки четырех специальных параметров в Google Analytics, у вас будет полная картина на всех уровнях организации данных.
