Что такое веб сессия

HTTP сессия

Так как HTTP — это клиент-серверный протокол, HTTP сессия состоит из трёх фаз:

Клиент устанавливает TCP соединения (или другое соединение, если не используется TCP транспорт).
Клиент отправляет запрос и ждёт ответа.
Сервер обрабатывает запрос и посылает ответ, в котором содержится код статуса и соответствующие данные.

Начиная с версии HTTP/1.1, после третьей фазы соединение не закрывается, так как клиенту позволяется инициировать другой запрос. То есть, вторая и третья фазы могут повторяться.

Установка соединения

Так как HTTP это клиент-серверный протокол, соединение всегда устанавливается клиентом. Открыть соединение в HTTP — значит установить соединение через соответствующий транспорт, обычно TCP.

В случае с TCP, в качестве порта HTTP сервера по умолчанию на компьютере используется порт 80, хотя другие также часто используются, например 8000 или 8080. URL загружаемой страницы содержит доменное имя и порт, который можно и не указывать если он соответствует порту по умолчанию.

Примечание: Клиент-серверная модель не позволяет серверу посылать данные клиенту без явного запроса этих данных. Чтобы обойти эту проблему, веб разработчики используют различные техники: периодически пингуют сервер используя XMLHTTPRequest Javascript объект, HTML WebSockets API, или похожие протоколы.

Отправка запроса клиента

Когда соединение установлено user-agent может послать запрос. (user-agent это обычно веб браузер, но может им не быть) Клиентский запрос это текстовые директивы, разделённые между собой при помощи CRLF (переноса строки). Сам запрос включает в себя три блока:

Первые строки содержат метод запроса и его параметры:
- путь к документу — абсолютная URL без указания протокола и доменного имени
- версию HTTP протокола
Каждая последующая строка представляет собой HTTP заголовок и передаёт серверу некоторую информацию о типах предпочитаемых данных (например, какой язык , какие MIME типы) или инструкции меняющие поведение сервера (например, не отправлять ответ, если он уже в кеше) . Эти HTTP заголовки формируют блок, который заканчивается пустой строкой.
Последний блок является не обязательным и содержит дополнительные данные. По большей части используется методом POST.

Примеры запросов

Получаем главную страницу developer.mozilla.org, http://developer.mozilla.org/, и говорим серверу, что user-agent предпочитает страницу на французском, если это возможно:

GET / HTTP/1.1 Host: developer.mozilla.org Accept-Language: fr

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

Отправляем результат сабмита формы:

POST /contact_form.php HTTP/1.1 Host: developer.mozilla.org Content-Length: 64 Content-Type: application/x-www-form-urlencoded name=Joe%20User&request=Send%20me%20one%20of%20your%20catalogue

Методы запроса

HTTP определяет набор методов запроса с указанием желаемого действие на ресурсе. Хотя они также могут быть и существительными, эти запросы методы иногда называют HTTP-командами. Наиболее распространённые запросы GET и POST :

GET используется для запроса содержимого указанного ресурса. Запрос с использованием GET должен только получать данные.
POST метод отправляет данные на сервер, так что он может изменять своё состояние. Этот метод часто используется для HTML форм.

Структура ответа от сервера

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

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

Примеры ответов

Успешное получение веб страницы:

HTTP/1.1 200 OK Date: Sat, 09 Oct 2010 14:28:02 GMT Server: Apache Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT ETag: "51142bc1-7449-479b075b2891b" Accept-Ranges: bytes Content-Length: 29769 Content-Type: text/html

Сообщение о том, что запрашиваемый ресурс был перемещён:

HTTP/1.1 301 Moved Permanently Server: Apache/2.2.3 (Red Hat) Content-Type: text/html; charset=iso-8859-1 Date: Sat, 09 Oct 2010 14:30:24 GMT Location: https://developer.mozilla.org/ (это новый адрес запрошенного ресурса, ожидается, что клиент запросит его) Keep-Alive: timeout=15, max=98 Accept-Ranges: bytes Via: Moz-Cache-zlb05 Connection: Keep-Alive X-Cache-Info: caching X-Cache-Info: caching Content-Length: 325 (Контент содержит стандартную страницу, которая будет показана, если клиент не может перейти по ссылке) 301 Moved Permanently

Moved Permanently

The document has moved here.

Apache/2.2.3 (Red Hat) Server at developer.mozilla.org Port 80

Сообщение о том, что запрашиваемый ресурс не существует:

HTTP/1.1 404 Not Found Date: Sat, 09 Oct 2010 14:33:02 GMT Server: Apache Last-Modified: Tue, 01 May 2007 14:24:39 GMT ETag: "499fd34e-29ec-42f695ca96761;48fe7523cfcc1" Accept-Ranges: bytes Content-Length: 10732 Content-Type: text/html

Коды статусов ответа

HTTP-коды ответов показывают, выполнен ли успешно определённый HTTP-запрос. Ответы сгруппированы в пять классов: информационные ответы, успешные ответы, редиректы, ошибки клиента и ошибки сервера.

200 : OK. Запрос завершился успехом.
301 : Moved Permanently. Этот код значит, что URI запрошенного ресурса был изменён.
404 : Not Found. Сервер не может найти запрошенный ресурс.

Смотрите также

Определение ресурсов в Интернете
HTTP заголовки
Методы HTTP запроса
Коды ответа HTTP

Found a content problem with this page?

Edit the page on GitHub.
Report the content issue.
View the source on GitHub.

This page was last modified on 7 авг. 2023 г. by MDN contributors.

Your blueprint for a better internet.

Сессия — Веб-разработка на PHP

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

Сессии реализуются на уровне конкретных фреймворков и только в PHP сессии встроены в язык. Общий принцип работы сессии сводится к трем операциям:

Старт сессии. Так мы говорим системе, что хотим начать следить за пользователем. Во многих фреймворках эта операция выполняется неявно при попытке чтения или записи в сессию
Запись данных в сессию
Чтение данных из сессии

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

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

Сессия — более высокоуровневая абстракция. Например, в PHP по умолчанию данные сессии хранятся в файлах. Из этого следует сразу два вывода:

Сессия ограничена только физическим пространством дисков
Данные хранятся на сервере, что безопаснее

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

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

 // Операция идемпотентна. Не важно, была ли инициализирована сессия раньше, старт сессии выполняется всегда session_start(); if (!isset($_SESSION['count']))  $_SESSION['count'] = 0; > else  $_SESSION['count']++; > print_r($_SESSION['count']);

Этот простой скрипт демонстрирует работу сессий в PHP. В отличие от остальных суперглобальных массивов для работы с HTTP массив $_SESSION — изменяемый. Всё, что добавится в него, автоматически попадает в сессию и сохраняется между запросами до тех пор, пока кука не удалится или не изменится.

Из примера выше видно, что сессия упрощает работу с пользователем. Также значением массива $_SESSION может быть любая составная структура, массив или объект. Механизм сессий автоматически беспокоится о сериализации и десереализации.

Внутри Slim нет особенного механизма для работы с сессиями, так как они не являются частью стандарта PSR-7. Работа с сессией происходит напрямую.

Перепишем наш пример добавления товаров в корзину, используя сессию:

 session_start(); $app->post('/cart-items', function ($request, $response)  // Информация о добавляемом товаре $item = $request->getParsedBodyParam('item'); // Добавление нового товара $_SESSION['cart'][] = $item; return $response->withRedirect('/'); >);

По сравнению с версией на куках ушла значительная часть кода. Кодирование и декодирование в JSON, извлечение куки и перезапись куки.

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

Обновление куки с установкой даты в прошлое
Обнуление массива $_SESSION — $_SESSION = []
Обнуление хранилища сессий — session_destroy()

Открыть доступ

Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно

130 курсов, 2000+ часов теории
1000 практических заданий в браузере
360 000 студентов

Наши выпускники работают в компаниях:

Что такое сессия на сайте?

Наверняка, каждый пользователь Интернета хоть раз сталкивался с ситуацией, когда на сайте появляется уведомление «Ваша сессия истекла». Звучит весьма странно и непонятно. Кто, куда и зачем истек – совсем не ясно.

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

Обо всем по порядку. Начнем с поиска ответа на главный вопрос: «Что такое сессия, и зачем она нужна?»

Немного о главном

Сессия (от латинского sessio, от английского session – заседание) – это временной промежуток, охватывающий период использования Интернет-ресурса с момента, когда пользователь кликнул и перешел по начальному URL (ссылке) и до самого закрытия последней.

Рассчитывать длительность сессии принято вычислением временной разницы между первым и последним запросом.

Более детально разобраться в понятии можно с помощью HTTP (HyperText TransferProtocol – протокол передачи гипертекста). Сессия здесь выступает в качестве вспомогательного логического объекта, который способствует осуществлению качественной передаче данных между последовательными HTTP-запросами конкретного пользователя.

Пример для понимания

1. Запускаем браузер.
2. Открываем привычный сайт с авторизацией пользователя и пытаемся зайти сразу на двух аккаунтах.
Ничего, конечно же, не вышло. Нужно выбрать какой-либо один аккаунт.
3. Запускаем второй браузер.
4. Авторизуемся на том же сайте с другого аккаунта, оставив вкладку и авторизацию в предыдущем браузере.

Вуаля, авторизация пройдена. Почему? Потому что сервер создал абсолютно разные, параллельные сессии для браузеров по отдельности.

Наиболее распространенные сценарии использования сессии

Рассматривая сессию, с точки зрения свершившегося события, в работе сервисов web-аналитики, ее использование осуществляется для фиксации и анализа пользовательского поведения. Для этого во внимание берутся следующие критерии:

просмотр страницы;
длительность посещения страницы (сеанса);
перечень совершаемых пользователем действий;
показатель вовлеченности.

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

обработка введенных пользователем данных с последующем удалением конфиденциальной информации;
анализ трафика Интернет-ресурса;
проведение тестов сервера или сайта.

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

Этапы сессии

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

открытие – момент открытия первой вкладки, начало работы с сайтом;
учет переменных – хранение полученной информации в процессе перехода на различные страницы (данные авторизации, идентификатор и пр.);
завершение – закрытие последней пользовательской ссылки и браузера в целом.

Особенности начала и окончания сессии

Создание и окончание сессии реализуется с помощью применения функции session_start() и session_destroy() соответственно.

Образование сессии реализуется в следующем порядке:

Шаг 1. Отправка запроса хосту.

Шаг 2. Присвоение уникального ID для начатой сессии (сохраняется на протяжение работы сессии).

Шаг 3. Реализация событий (бездействие пользователя на протяжении 30 минут и более, авторизация, обновление страницы, некорректность ID).

Шаг 4. Завершение сессии.

Хранение уникального ID сессии может осуществляться на протяжении достаточно длительного временного промежутка (день/неделя/месяц/год).

Сессия в системах аналитики

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

Сессия в «Яндекс.Метрика»

Среди особенностей работы сервиса «Яндекс.Метрика» стоит выделить взаимозаменяемость понятий «визит» и «сессия». Оба они трактуются, как последовательность действий посетителя на сайте, а именно, любая пользовательская активность (просмотр, обновление страницы и пр.).

Визит или сессия в «Яндекс.Метрике» считается оконченными при развитии двух сценариев:

Истечение установленного временного промежутка в 30 минут (можно изменить в настройках «Тайм-аут визита»).
Фиксирование рекламного перехода.

Особенности сессии в Google Analytics

Google Analytics определяет сессию, как веб-сеанс, трактующий временной промежуток, который пользователь провел в работе с сайтом или приложением.

Сеанс сессии в Google Analytics можно представить во вполне логичной последовательности действий:

1-й просмотр страницы;
2-й просмотр страницы;
свершение события 1;
свершение события 2;
взаимодействие;
транзакция (фиксация цепочки событий).

Завершение сессии по умолчанию реализуется в трех случаях:

Случай 1. Переход по рекламному объявлению со стороннего источника.

Случай 2. Отсутствие активности на протяжение 30 минут (временной период корректируется в настройках).

Случай 3. Полночь в часовом поясе пользователя.

Разбираемся в понятиях: «сессия» и «сеанс» – одно и тоже или есть какая-то разница?

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

На самом деле, каким бы абсурдным и непонятным это не казалось, сессия и сеанс не являются равнозначными понятиями.

Сеанс – понятие, соотносимое исключительно к взаимодействию пользователя с Интернет-ресурсом, который в целом образуется следующими составляющими:

Переход на Интернет-ресурс.
Открытие страницы.
Свершение событий.
Закрытие Интернет-ресурса.

Сессия – это скорее последовательность запросов, поступающих от одного и того же пользователя, каждый из которых идентифицируется сервером с помощью уникального ID.

Почему появляется уведомление «Ваша сессия истекла»?

«Сессия истекла», «Время Вашей сессии закончилось», «Ваша сессия истекла» – что все это значит и почему так случается?

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

Основными причинами появления такого рода уведомления принято считать:

Бездействие пользователя на странице (стандартно время окончания сессии – 24 минуты, но показатель может быть изменен).
Закрытие браузера.

Подводя итоги

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

Более того, существует вполне значимая разница между понятием «сессия» и «сеанс».

В целом, понятие «сессия» применимо именно к сайту, а формирование понимания о его широком значении позволяет отнести понятие к категории многозначных. Определение «сессия» наиболее востребовано при трактовке аналитических отчетов.

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

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

Хиты, сессии, пользователи - как правильно интерпретировать данные веб-аналитики

Каждый день мы говорим о данных — сессии, визиты, конверсия, страницы, посещения ит.д. Но иногда мы неправильно понимаем, как все эти метрики соотносятся друг с другом и откуда они берутся. Давайте разберёмся, как упорядочены данные в инструментах веб-аналитики.

Все данные, собранные системами веб-аналитики, можно представить в виде пирамиды из трёх основных блоков — пользователи, визиты и просмотры. Абсолютно не имеет значения, откуда эти данные получены — с веб-сайта, мобильного приложения или из торгового терминала.

Данные веб-аналитики организованы в виде пирамиды из хитов, сессий и пользователей.

Иногда мы используем понятие «посетитель» вместо понятия «пользователь» и «посещение» вместо «сессии» — это всё синонимы. Развитие мобильных устройств и цифрового телевидения побудило нас ввести новые понятия в наш словарный запас.

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

Давайте начнём с основания пирамиды — хитов, а затем постепенно рассмотрим содержание понятий «сессия» и «пользователь».

Хиты

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

Все данные передаются с помощью хитов. Большинство хитов — это запросы невидимых графических файлов.

Существует несколько разновидностей хитов в зависимости от используемой Вами системы веб-аналитики. Вот некоторые из наиболее распространенных хитов в Google Analytics:

Просмотр страницы/экрана

Хит «просмотр страницы» используется для веб-сайта, а «просмотры экрана» — для мобильного приложения. Как правило, эти хиты автоматически генерируются и позволяют измерять количество просмотров пользователями определённых фрагментов контента. Просмотры страниц — одна из основных метрик в веб-аналитике. Она используется для расчета многих других показателей, таких как число просмотров страниц за одно посещение и среднее время, проведённое на странице.

События

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

Транзакции

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

Социальные взаимодействия

Данный хит происходит каждый раз, когда пользователь нажимает на кнопки retweet, +1 или Like. Если вы хотите знать, когда люди нажимают на кнопки социальных сетей, а затем использовать эту информацию, то необходимо вручную настроить данный вид треккинга.

Пользовательские тайминги

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

Все типы хитов отправляются в Google Analytics через треккинг-код. Структура и вид кода зависят от тех данных, которые вы отслеживаете. Если вы отслеживаете веб-сайт, то используется код на JavaScript, который называется analytics.js, который генерирует и отправляет хиты на сервер веб-аналитики. Если вы отслеживаете мобильные приложения, тогда хиты генерируются SDK (набором средств разработки либо под Android, либо под iOS). Если вы отслеживаете сенсорные торговые терминалы, тогда вам самим нужно генерировать хиты с помощью специального протокола измерений (measurement protocol).

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

http://www.google-analytics.com/collect?v=1&_v=j16&a=164718749&t=pageview&_s=1&dl=http%3A%2F%2Fcutroni.com%2F&ul=en-us&de=UTF-8&dt=Analytics%20Talk%20-%20Digital%20Analytics%20for%20Business&sd=24-bit&sr=1920x1080&vp=1308x417&je=1&fl=12.0%20r0&_utma=32856364.1751219558.1391525474.1391525475.1391525475.1&_utmz=32856364.1391525475.1.1.utmcsr%3D(direct)%7Cutmccn%3D(direct)%7Cutmcmd%3D(none)&_utmht=1391525534970&_u=cACC~&cid=1751219558.1391525474&tid=UA-91817-11&z=378275262

Для тех, кто хочет лучше понять, что здесь происходит: данные отправляются через запрос типа GET или POST. Это необходимо знать, потому что количество передаваемых данных по каждому протоколу ограничено: GET-запрос может передавать 2048 символов данных. POST-запрос теоретически может быть любой длины, но при отправке данных в Google Analytics количество символов ограничено примерно 8000 знаков.

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

Немного о мобильных телефонах.

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

Сессии

Сессии — это наборы данных хитов от одного пользователя, сгруппированные вместе. По умолчанию большинство аналитических систем, включая Google Analytics, будут группировать хиты вместе на основании активности пользователя. Когда инструменты веб-аналитики определяют, что пользователь больше не совершает действий на сайте, его сессия будет прервана; когда пользователь снова начнёт что-то делать — начнётся новая сессия.

Большинство систем веб-аналитики используют интервал неактивности для разделения сессий. Эти периоды называются тайм-аутами

Сессия — это набор хитов. Она заканчивается, когда пользователь не совершал действий в течение 30 минут.

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

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

Если пользователь смотрит видео дольше 60 минут (под просмотром я понимаю то, что он не совершает других действий на сайте), его сессия будет прервана через 30 минут после совершения последнего хита. Для того чтобы избежать этого, вам нужно увеличить тайм-аут.

Или лучше вообще отправлять дополнительные хиты во время просмотра пользователем видео. Подумайте об этом — больше хитов даёт больше информации о пользователе и позволяет лучше рассчитывать продолжительность сессии. Поверьте, вам стоит выделить 12 минут на чтение статьи how Google Analytics performs time calculations.

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

Пользователи

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

Далее показано, как определяются пользователи на наиболее распространённых цифровых платформах.

Пользователи сайта

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

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

Теперь давайте поговорим о cookies

Google Analytics использует первую часть cookies, которая содержит название домена, создавшего её. Только этот домен может обращаться к первой части cookies. Таким образом, cookies, которая была поставлена пользователю на сайте cutroni.com, может быть использована только этим сайтом.

В Universal Analytics cookie называются _ga, а в предыдущей версии Google Analytics cookie назывались __utma.

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

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

Системы аналитики используют первую часть cookie, чтобы хранить идентификатор пользователя.

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

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

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

Сторонние cookie могут быть использованы разными сайтами.

Однако сторонние cookies не могут быть созданы большинством браузеров, что приводит к невозможности получить корректные данные.

Google Analytics не использует сторонние cookie. Вы можете прочитать об использовании cookies в Google Analytics в руководстве разработчика developer documentation.

Так как же решить эту проблему? Как правильно определять пользователя, если ваш сайт размещён на нескольких доменах? В Google Analytics мы обычно используем функцию, которая называется Cross Domain Tracking. В данном посте я не буду на этом подробно останавливаться, но вы можете почитать об этом по следующей ссылке support documentation.

Пользователи мобильных устройств

Теперь давайте перейдём к мобильным платформам

Мобильный трекинг похож на трекинг веб-сайтов. Есть анонимный идентификатор, устанавливаемый на устройство. Идентификатор генерируется каждый раз, когда на устройство устанавливается приложение. Если пользователь удалит приложение, то и идентификатор тоже будет удалён. Но это правило не распространяется на обновление приложения: идентификатор при этом меняться не будет.

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

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

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

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

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

Так, теперь мы знаем о мобильных пользователях и пользователях веб-сайта. А что же с сенсорными торговыми терминалами?

Другие цифровые сенсорные устройства

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

Одной из особенностей Universal Analytics является возможность отслеживать пользователей, использующих разные девайсы, в т.ч. сенсорные торговые терминалы. Это стало возможным благодаря использованию технологии, которая получила название протокол измерений (measurement protocol).

Как это работает на практике?

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

Но что происходит с идентификацией пользователей, когда используется протокол измерений?

Когда вы создаёте хиты, вы должны вставить в него идентификатор пользователя. Затем Google Analytics будет использовать этот идентификатор как уникальный номер, когда начнёт обрабатывать данные.

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

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

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