Сколько транзакций может произойти во время одной сессии на сайте

2.19. Транзакции

Язык запросов Transact-SQL взял свое название от слова транзакция. Я думаю, что Microsoft не зря сконцентрировало на этом понятии особое внимание, ведь транзакции действительно являются очень мощным средством управления базой данных.

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

Рассмотрим классическую задачу – банковскую проводку. Допустим, что у нас есть таблица из двух полей – номер счета в банке и сумма денег на этом счету. Нам необходимо перевести деньги с одного счета на другой. Для этого нужно выполнить запрос UPDATE, чтобы уменьшить сумму первого счета на нужную сумму. После этого выполняем UPDATE, чтобы увеличить значение второго счета. Все вроде бы нормально. А что, если после уменьшения первого счета выключат свет и сервер не успеет пополнить другой счет? Деньги уже сняты, но никуда не записаны, а значит, они пропали.

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

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

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

Существует две разновидности транзакций в SQL Server:

• Скрытые транзакции, каждый оператор, такой как INSERT, UPDATE или DELETE выполняется в транзакции. Неявными транзакциями можно управлять и об этом мы поговорим в разделе 4.1.2;
• Явные транзакции объявленные пользователем – операторы, сгруппированные в BEGIN TRANSACTION и COMMIT TRANSACTION.

Очень важно понимать, что транзакции необходимы только при модификации данных, т.е. использовании операторов INSERT, UPDATE или DELETE. Простая выборка SELECT не изменяет данных, и запоминать или откатывать нечего. Нет, выполнять операции выборки в транзакции можно, но если транзакция не изменяет данные, то незачем ее вообще начинать.

В транзакции можно включать далеко не все операторы. Внутри транзакции не может быть следующих операторов:

• ALTER DATABASE
• BUCKUP LOG
• CREATE DATABASE
• DROP DATABASE
• RECONFIGURE
• RESTORE DATABASE
• RESTORE LOG
• UPDATE STATISTICS

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

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

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

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

Начало транзакции в MS SQL Server имеет следующий синтаксис:

BEGIN TRAN[SACTION] [transaction name | @transaction name variable [WITH MARK[‘description]]]

Опция Transaction name указывает имя транзакции определенное пользователем. Опция WITH MARK указывает, что транзакция маркирована в журнале транзакций.

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

COMMIT [ TRAN [ SACTION ] [ transaction_name | @tran_name_variable ] ]

Отмена транзакции и всех изменений производиться командой ROLLBACK, которая в общем виде выглядит следующим образом:

ROLLBACK [ TRAN [ SACTION ] [ transaction_name | @tran_name_variable | savepoint_name | @savepoint_variable ] ]

Очень важно понимать, если начата транзакция и изменены какие-то записи, то эти записи блокируются, пока транзакция не будет завершена. Давайте посмотрим это на примере, заодно познакомимся с самой командой. Выполните следующие команды в Query Analyzer:

-- Начинаем транзакцию BEGIN TRANSACTION -- Очищаем таблицу товаров DELETE Товары

Теперь откройте еще одну копию программы или установите новое соединение, выбрав меню File/Connect (Файл/Соединиться). В новом окне напишем и выполним следующий запрос:

SELECT * FROM Товары

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

Нам удалять данные не нужно, поэтому давайте вернемся в первое окно, где мы создавали транзакции и выполним откат:

ROLLBACK TRANSACTION

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

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

Теперь откатываем транзакцию, выполняя команду ROLLBACK TRANSACTION. Снова выполняем запрос SELECT и видим, что данные вернулись на родину. Транзакция удачно отклонена и физического удаления из базы данных не произошло. Почему мы в этот раз без проблем смогли просмотреть таблицу, а из другой сессии просмотр изменяемой в транзакции таблицы не доступен? Блокировки происходит для всех сессий кроме той, которая выполняет транзакцию. В листинге 2.8 показан весь код эксперимента с подробными комментариями.

Листинг 2.8. Пример эксперимента с удалением данных в транзакции

-- Начинаем транзакцию BEGIN TRANSACTION -- Очищаем таблицу товаров DELETE Товары -- Проверяем и убеждаемся, что таблица пуста SELECT * FROM Товары -- Откатываем транзакцию ROLLBACK TRANSACTION -- Можете убедиться, что товары на месте SELECT * FROM Товары

Все эти команды нужно выполнять в одном и том же окне. К тому же, если в одном окне (сессии) вы начали транзакцию, то именно в этом окне вы должны ее завершить (COMMIT) или откатить (ROLLBACK).

Если в листинге 2.8 заменить вызов команды ROLLBACK TRANSACTION на COMMIT TRANSACTION, то произойдет физическое удаление всех записей из таблицы товаров. Теперь удаленные строки вернуть уже невозможно.

Теперь посмотрим еще один пример в листинге 2.9.

Листинг 2.9. Пример работы с транзакциями

-- Начинаем транзакцию BEGIN TRANSACTION -- Вставляем строку данных в -- таблицу товаров INSERT INTO Товары (Дата, [Название товара], Цена, Количество) VALUES ('3.3.2005', 'КАРТОФЕЛЬ', 12.50, 10) -- Обновить данные в последней строке UPDATE Товары SET Цена = 15 WHERE [Название товара] LIKE 'КАРТОФЕЛЬ' COMMIT TRANSACTION -- Обновить данные в последней строке UPDATE Товары SET Цена = 17 WHERE [Название товара] LIKE 'КАРТОФЕЛЬ' -- Откатить транзакцию ROLLBACK TRANSACTION -- Выбрать все данные из таблицы SELECT * FROM Товары

Тут достаточно много действий, поэтому давайте их рассмотрим поэтапно:

1. Начинаем транзакцию;
2. Добавляем запись о покупке товара с названием Картофель;
3. Обновить цену картофеля, увеличив ее до 15 рублей;
4. Завершаем транзакцию, запоминая изменения;
5. Обновляем цену до 17 руб.;
6. Откатываем транзакцию;
7. Просматриваем содержимое таблицы.

Что произошло с содержимым таблицы? Запись о картофеле добавлена, а значит, все что было до запоминания изменений (шаг 4) выполнено удачно. А вот цена равна 17-ти рублям. Почему? Неужели на шаге 6 мы не откатили изменение цены? Да, отката не произошло, потому что новая транзакция не начиналась. На шаге 1 мы начали транзакцию, а на шаге 4 завершили. Новая транзакция не начиналась, а значит откатывать нечего и шаг 6 завершиться ошибкой:

The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION.

Запрос ROLLBACK TRANSACTION не имеет соответствующего BEGIN TRANSACTION.

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

Для каждого оператора BEGIN TRANSACTION должен быть только один оператор COMMIT TRANSACTION или ROLLBACK TRANSACTION.

А что если внутри транзакции начать новую транзакцию? Результат неожиданный и давайте его увидим на примере (см. листинг 2.10).

2.10. Вложенные транзакции

-- Начинаем транзакцию 1 BEGIN TRANSACTION -- Вставляем строку данных в таблицу товаров INSERT INTO Товары (Дата, [Название товара], Цена, Количество) VALUES ('4.3.2005', 'МОРКОВЬ', 11.30, 1) -- Начинаем транзакцию 2 BEGIN TRANSACTION -- Обновить данные в последней строке UPDATE Товары SET Цена = 14 WHERE [Название товара] LIKE 'МОРКОВЬ' ROLLBACK TRANSACTION -- Запоминаем изменения COMMIT TRANSACTION -- Выбрать все данные из таблицы SELECT * FROM Товары

Логика запроса следующая:

• Начать транзакцию;
• Вставить строку;
• Начать транзакцию;
• Обновить таблицу;
• Откатить транзакцию;
• Запомнить изменения.

По логике вещей, на шаге 5 мы должны были откатить вторую транзакцию (т.е. изменение таблицы), а на шаге 6 запоминаем транзакцию 1, в которой происходит добавление записи. Посмотрите содержимое таблицы. Ни добавления, ни тем более изменения. Почему? Если посмотреть сообщения, которые выдал сервер, то вы увидите, что на шаге 6 произошла ошибка о том, что нет соответствующего начала транзакции и нечего начинать. Получается, что оператор ROLLBACK TRANSACTION откатывает все начатые транзакции.

Но это не значит, что невозможно использовать вложенные транзакции. Просто откатывать транзакции нельзя на один шаг назад. Если заменить оператор ROLLBACK TRANSACTION на COMMIT, то ошибки не будет.

Посмотрим на листинг 2.11. В нем показан такой же пример, но с именованными транзакциями и без отката.

Листинг 2.11. Использование вложенных транзакций

BEGIN TRANSACTION T1 -- Вставляем строку данных в таблицу товаров INSERT INTO Товары (Дата, [Название товара], Цена, Количество) VALUES ('4.3.2005', 'МОРКОВЬ', 11.30, 1) -- Начинаем транзакцию 2 BEGIN TRANSACTION T2 -- Обновить данные в последней строке UPDATE Товары SET Цена = 14 WHERE [Название товара] LIKE 'МОРКОВЬ' COMMIT TRANSACTION T2 -- Запоминаем изменения COMMIT TRANSACTION T1 -- Выбрать все данные из таблицы SELECT * FROM Товары

В данном примере после операторов BEGIN TRANSACTION и COMMIT TRANSACTION указывается имя T1 и T2. Таким образом, мы идентифицируем транзакции и завершаем их в обратном порядке объявлению.

Но как же тогда можно откатывать транзакции до определенной точки? Достаточно просто и вложенные транзакции тут не причем. Для этого нужно просто поставить точку сохранения с помощью оператора SAVE TRAN, который имеет следующий вид:

SAVE TRAN [ SACTION ]

Минимум, что необходимо указать – это сам оператор и имя точки сохранения. Например, следующий оператор создает точку сохранения с именем point1:

SAVE TRAN point1

В листинге 2.12 показан пример, в котором наконец-то создаем строку, изменяем ее и откатываем только изменение, а не всю транзакцию, вместе с добавлением строки.

Листинг 2.12. Откат до определенной точки

-- Начинаем транзакцию 1 BEGIN TRANSACTION T1 -- Вставляем строку данных в -- таблицу товаров INSERT INTO Товары (Дата, [Название товара], Цена, Количество) VALUES ('4.3.2005', 'МОРКОВЬ', 11.30, 1) -- Сохраняем транзакцию SAVE TRAN ins_complete -- Обновить данные в последней строке UPDATE Товары SET Цена = 14 WHERE [Название товара] LIKE 'МОРКОВЬ' -- Откатываем транзакцию ROLLBACK TRANSACTION ins_complete -- Запоминаем изменения COMMIT TRANSACTION T1 -- Выбрать все данные из таблицы SELECT * FROM Товары

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

1. Начинаем транзакцию;
2. Добавляем строку;
3. С помощью оператора SAVE TRAN сохраняем состояние таблицы. Точнее сказать, ставим точку в журнале, ведь пока все изменения происходят только в журнале транзакций;
4. Обновляем цену последней добавленной строки;
5. Восстанавливаем состояние таблицы на точку сохранения, установленную на третьем шаге. В этот момент из журнала транзакций удаляется запись о необходимости обновить цену, а остается только запись о необходимости добавить строку;
6. Запоминаем изменения, а в журнале транзакций находиться только добавление строки и именно это сохраняется в таблице товаров.

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

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

Следующие рекомендации позволят вам сделать транзакции как можно короче:

• Без особой надобности не выполняйте запросы SELECT. Выборка данных должна происходить вне транзакции;
• Для уменьшения времени транзакции, будьте внимательны, когда используете долго выполняемые операторы Transact-SQL, такие как циклы и создание объектов базы данных;
• Не требуйте от пользователя ввода данных во время выполнения транзакции. Делайте ввод данных до начала выполнения транзакции.
• Операторы INSERT, UPDATE и DELETE должны быть главными в транзакции и они должны быть написаны так, чтобы получать минимальный набор строк, что позволяет повысить скорость работы любого запроса.
• Все проверки данных и подготовительные расчеты необходимо произвести до начала транзакции. После оператора BEGIN TRANSACTION должно выполняться только изменение данных.

Как отличить клики, сеансы и пользователей в GA4

Новые пользователи, Вернувшиеся пользователи, Пользователи, Клики, Сеансы в Google Analytics. А есть ли разница? Есть! И существенная. Попробуем разобраться в этом материале.

Если вашего бизнеса нет в интернете, значит, вас нет в бизнесе (с).

Трафик — нефть 21 века. Причем этот трафик можно добывать по-разному.

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

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

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

Итак, давайте разберем каждый показатель максимально подробно.

Сеансы (Sessions)

• Тип данных: string (строка)
• API Google Analtics: ga:sessions
• Группа в Dimensions & Metrics Explorer: Session
• Область действия: Сеанс

Сеанс (сессия, session, визит) — последовательность действий (хитов, обращений), которые выполнил пользователь на вашем сайте за определенный промежуток времени. Примеры трех сеансов, в которых были совершены разные хиты (действия пользователей) К сеансу привязываются все данные об использовании: просмотры экрана, события, транзакции электронной торговли и т. д. Присутствует практически во всех отчетах, поскольку является фундаментальной метрикой, на основе которой строятся все дальнейшие вычисления и отслеживания в Google Analytics. Показатель «Сеансы» в отчете Для наглядности разберем конкретную последовательность действий:

1. Просмотр каталога сайта
2. Переход в корзину для оформления заказа
3. Переход на форму заполнения контактных данных
4. Покупка, совершение транзакции

Пример 1. Все действия пользователя совершены в рамках одной сессии Пример 2. Действия пользователя записались как два сеанса В примере 1 пользователь просматривал каталог сайта 10 минут, потом перешел в корзину товаров. Через 29 минут он переходит на страницу для оформления заказа, а через 5 минут на последний этап завершения заказа. Оформление заказа происходит в рамках одной сессии, поскольку еще не прошло 30 минут. Все время не суммируется (10 + 29 + 5 = 44 минуты), а при каждом взаимодействии оно сдвигается. То есть теперь 30 минут фиксируются не с момента, как он оказался в каталоге, а с момента, как он перешел в корзину товаров.

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

При создании нового счетчика для сайта по умолчанию время ожидания сеанса составляет 30 минут. При желании его можно изменить. Настройки сеанса — Время ожидания сеанса Например, когда вы смотрите фильм на сайте или обучающий онлайн-семинар длиной 3 часа, при такой настройке сеанса он закрывался бы каждые 30 минут и в Google Analytics мы увидели бы 6 сеансов (180 минут / 30 минут = 6). Хотя уникальный пользователь всего 1. В данном случае время ожидания сеанса можно увеличить. Диапазон изменений времени — от 1 минуты до 4 часов 59 минут. Но ситуаций, при которых пользователи проводят довольно длительное время на сайте, — немного. В большинстве своем 30 минут достаточно для корректного сбора информации о посетителях сайта, поэтому стандартную настройку в GA нет необходимости менять.

Однако существует еще несколько случаев окончания сеанса без учета 30 минут.

• Сеанс закрывается в полночь. Если вы загрузили страницу в 23:50, а на следующую перешли в 00:02, то будет создано два сеанса. Один зафиксируется с 23:50 до 23:59, а второй с 00:00 следующего дня).
• Автоматическая пометка тегами glid. При использовании этой настройки в Google Рекламе при каждом переходе по рекламному объявлению создается новое значение glid, каждый клик рассматривается в отдельности и всегда создается новый сеанс.
• Рефералы. Новый сеанс создается всегда, когда пользователь переходит по ссылке на ваш сайт с другого сайта (так называемый «реферальный трафик»).

В Google Analytics есть специальная настройка, с помощью которой можно исключить создание таких источников. Сюда же можно отнести случай, когда пользователь заходит на сайт по какому-нибудь источнику (organic, cpc), оформляет заказ, затем он перенаправляется на сайт платежного агрегатора, а после совершения транзакции, возвращается обратно на сайт. Если вы не добавите платежный шлюз в список исключаемых источников перехода, то тогда предыдущий сеанс с одним источником закроется, и начнется новая сессия с источником referral.

Сторонние платежные системы

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

Google Аналитика сохраняет информацию об источнике кампании. При каждом обновлении значения кампании регистрируется новый сеанс. Например, пользователь сначала перешел на сайт по органическому поиск (organic) по ключевому слову «настройка веб-аналитики», а позже вернулся по платному трафику (cpc) и ключевому слову «настройка google analytics». В результате будет зафиксировано 2 сеанса, поскольку каждый поисковый запрос обновляет кампанию и каждому ключевому слову соответствует свой сеанс.

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

Пользователи (Users)

• Тип данных: string (строка)
• API Google Analytics: ga:users
• Группа в Dimensions & Metrics Explorer: User
• Область действия: Пользователь

Чтобы определить, с каким пользователем связана та или иная статистика (доля трафика, события, конверсии и др.), в Google Analytics для каждого посетителя создается уникальный идентификатор. Им может быть:

• функция User ID, которая позволяет отслеживать действия пользователей на различных устройствах.
• собственный файл cookie с названием _ga

Файл cookie с названием _ga Пользователь (посетитель, user) — совокупность сеансов, которые совершаются с одного и того же браузера и имеют один файл cookie. Пользователь — это уникальный куки файл и уникальный идентификатор отслеживания (он же Client ID) за определенный период времени. Пользователь, который совершил три сеанса, в которых он совершил различные хиты (действия)

Фактически, показатель Пользователи — это уникальный cookie-файл за определенный период времени. В Google Analytics он не является абсолютным. Вы можете посмотреть историю всех посещений, сеансов и обращений (хитов) пользователя по его уникальному идентификатору в отчете Статистика по пользователям, который находится в разделе Аудитория.

Статистика по пользователям Количество пользователей за каждый отдельно взятый период суммарно не равно количеству пользователей за весь период в целом. Подсчет количества пользователей Например. 14 июля на сайт по поисковой системе Google зашло 204 пользователя, и они совершили 248 сеансов. 15 июля – 132 пользователя и 152 сеанса. 16 июля – 107 и 119. Google Analytics фиксирует активность по файлам cookie в конкретный промежуток времени.

Во все эти три дня на сайт мог заходить один пользователь с уникальным cookie. И система 14, 15, 16 июля запишет нам его по одному разу. Но этого не произойдет, если мы построим сводный отчет сразу же по всем трем дням. Количество сеансов останется неизменным, тогда как показатель Пользователи не будет равен сумме трех дней, построенных в отдельности (204+132+107 = 443).

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

Чтобы Google Analytics быстро загружался при изменении дат таблицы и стандартные отчеты сразу перестраивались, Google Analytics использует так называемую выборку данных (data smapling).

Другими словами, Google из общего количества данных, которые есть у него по вашему проекту, берет некоторую выборку, например, 10%, умножает ее на 10 и говорит нам, что так вели бы себя все 100% пользователей. При построении отчета Google Analytics находит в этих таблицах все данные по каждому показателю и включает их в ваши отчеты. Например, если вы вместо периода 1 октября — 31 октября выберете период 1 октября — 1 ноября, то система найдет в таблице данные по каждому показателю за 1 ноября и добавит их к имеющимся результатам предыдущего месяца. Такой подход работает хорошо, когда просто нужно просуммировать данные за различные диапазоны дат.

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

Для решения этой проблемы в Google Analytics предусмотрено два метода расчета показателя Пользователи:

1. Предварительный расчет данных
2. Оперативный расчет данных

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

Метод расчета №1. Предварительный расчет данных (Pre-calculated data)

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

• Аудитория — обзор (без сегментов)
• Специальные отчеты

У такого метода есть недостаток, поскольку расчет статистики основан на количестве сеансов и времени на стороне клиента. Чтобы избежать различия в данных вы можете создать специальный отчет с любым параметром, кроме времени. Например, Браузер, Страна, Операционная система и т.д., который будет неизменным для всех сеансов пользователя. Это обеспечит применение второго метода расчета.

Метод расчета 2. Оперативный расчет данных (Data calculated on the fly)

Data calculated on the fly можно перевести как «Данные, расcчитываемые на лету». Однако «на лету» в данном контексте не означает быстро, а предполагает, что вычисления осуществляются всякий раз, когда вы делаете запрос к данным Google. Данный метод расчета зависит от способа назначения, сбора и хранения постоянных данных о трафике с использованием файлов cookie.

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

Переключение между двумя методами подсчета

Новый метод расчета (№2) активен по умолчанию. Для его изменения перейдите в Администратор — Ресурс — Настройки ресурса. В разделе Анализ данных о пользователях измените ползунок на нужный в Добавление показателя «Пользователи» в отчеты: Анализ данных о пользователях Когда функция включена, используется новый метод подсчета, когда выключена — старый. При переключении между разными методами вычисления изменяется лишь способ создания отчетов на основе первичных данных. Сами данные остаются неизменны.

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

Метод расчета №1 (функция выключена):

• Параметр — Дата; Показатель: Пользователи
• Параметр — Дата; Показатель: Пользователи, Сеансы
• Параметр — Страна; Показатель: Пользователи, Сеансы

Метод расчета №2 (функция включена):

• Параметр — Дата; Показатель: Пользователи
• Параметр — Дата; Показатель: Пользователи, Сеансы
• Параметр — Страна; Показатель: Пользователи, Сеансы

В результате получим такое сравнение (диапазон дат везде одинаковый): Сравнение методов расчета (Сверху — выкл/№1, Снизу — вкл./№2) Из скриншота видно, что при методе расчета №1 значение пользователей 4962 только в том случае, если в качестве основного параметра используется Дата. Когда мы изменяем на другой (например, Страна), то количество пользователей изменяется на 4620 (применяется оперативный расчет данных).

При методе №2 количество пользователей одинаково вне зависимости от использования основного параметра (и Дата, и Страна), и равно 4638. Сам отчет формировался дольше, поскольку статистика рассчитывалась в момент запроса к данным.

Новый метод подсчета применяется для пользовательских данных с сентября 2016 г. Если на диапазон дат отчета приходятся данные, собранные до сентября 2016 г., будет применена выборка. А с августа 2017 г. новый метод подсчета применяется для данных в специальных таблицах (доступна только в Аналитике 360).

Вернувшиеся пользователи (Returning Visitor)

В Google Analytics нет отдельной метрики, которая показывала бы количество вернувшихся пользователей. Такое понятие встречается только в отчете Аудитория — Поведение — Новые и вернувшиеся и относится к параметру Тип пользователя (User Type):

Новые и вернувшиеся пользователи И вот здесь возникает путаница: если вы посмотрите на цифры в отчете, то заметите, что количество новых и вернувшихся пользователей суммарно не дает итоговое значение 222 663, которое написано сверху (221 326 + 59 548 ≠ 222 663).

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

Такое может произойти, например, если между двумя сеансами пользователя прошло более 30 минут, и он в течение одного дня заходил на ваш сайт несколько раз, посетив первый раз и повторно. В этом случае он будет записан и в новых, и в вернувшихся (пример запроса в Query Explorer): Пользователь с Client ID 1967819514.1572117974 как новый пользователь и как вернувшийся

Отсюда можно сделать вывод: Пользователи ≠ Новые + Вернувшиеся

Новые пользователи (New Users)

• Тип данных: string (строка)
• API Google Analytics: ga:newUsers
• Группа в Dimensions & Metrics Explorer: User

Пользователи и Новые пользователи Пользователь является новым для Google Analytics, пока он не совершил повторного сеанса. Добавив параметры и показатели в Query Explorer, связанные с пользователями, сеансами и номером сеанса, получим такой запрос: Показатель Новые пользователи Показатель Новые пользователи (New Users) со значением 1 добавлен только в первый сеанс, который имеет тип New Visitor. Все последующие сеансы (Count of Sessions — 2 и 3) имеют значение 0, поскольку данный пользователь для Google Analytics уже является вернувшимся.

Есть одна маленькая деталь, которая способна смутить начинающего маркетолога:

Количество сеансов может быть меньше количества новых пользователей.

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

Клики (Clicks)

• Тип данных: string (строка)
• API Google Analytics: ga:adClicks
• Группа в Dimensions & Metrics Explorer: Adwords
• Область действия: Hit

Каждый клик по рекламному объявлению засчитывается как отдельный сеанс независимо от времени. В этом очень легко убедиться, открыв отчет Статистика по пользователям конкретного пользователя. Каждый клик по рекламному объявлению засчитывается как отдельный сеанс На скриншоте выше видно, как один пользователь совершил 3 сеанса 24 октября 2020 г. в течение 20 минут по источнику yandex / cpc. Причем первый клик по рекламному объявлению был в 11:28, а два других в одно и то же время — 11:48 (с разницей в несколько секунд). И тем не менее, Google Analytics зафиксировал их как 3 разных сеанса.

Клики — это показатель области действия Hit (Обращение). Применяется в связке с другими показателями для отчетов категории Google Реклама (Показы, Стоимость, CTR, CPC и т.д.). Если у вас связаны аккаунты Google Analytics и Google Ads, то данные отчетов по Google Рекламе вы будете видеть в Аналитике. Статистика в двух системах одинакова, но иногда может различаться:

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

А теперь пришло время поговорить о разнице между пользователями, кликами и сеансами в Google Analytics.

Разница между кликами и сеансами

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

Google Реклама = Клики, а Google Analytics = Сеансы
В Google Analytics отчеты строятся на основе сеансов и тому, что в них происходило. Расчет коэффициента конверсии/транзакции также происходит на основе сеансов. Сеансы — ключевой показатель в Google Analytics (как Визит в Яндекс.Метрике). Однако это и создает большое количество проблем, с которыми сложно бороться по причине ограничений системы, и забывчивости принципов работы интернет-маркетологов.

Google Реклама работает с кликами.
Например, если пользователь нажмет на рекламное объявление, затем нажмет кнопку Назад, а потом снова нажмет на объявление, в Google Ads будет зарегистрировано два клика, а в Аналитике — один сеанс. Повторные клики возникают и тогда, когда пользователь сравнивает несколько товаров в поисковой выдаче, последовательно переходя по разным рекламным объявлениям торговых кампаний (Google Shopping).

Отключена автоматическая пометка тегами
Автоматическая пометка тегами в настройках аккаунта Google Ads Если функция автоматической пометки отключена, и вы не используете в конечных URL-ссылках пометку utm_метками вручную, то трафик будет обозначен не как клики, связанные с объявлениями в Google Рекламе, а как клики по результатам обычного поиска на сайте Google.

Блокировка кода Google Analytics на стороне браузера
Современные браузеры последних версий позволяют блокировать файлы cookie по умолчанию. Это затрудняет идентификацию пользователя в интернете и отслеживание его статистики в Google Analytics. Например, Firefox с версии 69 блокирует cookies и не позволяет сайтам следить за пользователем, а также составлять его портрет для показа рекламы. Блокировка в браузере Mozilla Поскольку клик по рекламе засчитывается в момент перехода пользователя по объявлению, то он будет отображен в отчетах Google Ads. А вот сеанс может так и не начаться, если браузер заблокирует отслеживание трекера, и данные в Google Analytics не передадутся.

Разные часовые пояса в Google Analytics и Google Ads
Распространённая, но не очевидная причина расхождения данных между аккаунтами. Настройки часовых поясов в Google Analytics и Google Ads При создании счетчика Google Analytics по умолчанию стоит часовой пояс отчетов Соединенные штаты — (GTM-08:00) Лос-Анджелес. Если вы не изменили его на этапе настройки, и он отличается от часового пояса в Google Ads, то и данные за определенные дни в отчетах будут различаться.

Разница между кликами и пользователями

Клики и пользователи — это два разных показателя в Google Analytics. Один фиксирует число переходов по рекламным объявлениям, а другой — количество уникальных пользователей, нажавших на объявление. В связи с этим число кликов и пользователей может не совпадать. Причины те же самые, что и в кликах/сеансах:

• Google Реклама отфильтровывает недействительные клики из отчетов, а Google Аналитика отображает все данные.
• Долгая загрузка кода Google Analytics (прерывание) или счетчик установлен не на всех страницах.
• Несколько кликов по рекламе, но один зафиксированный пользователь в Google Analytics.

Разница между сеансами и пользователями

Сеансы и пользователи — также разных метрики в Google Analytics. Самое важное, что необходимо запомнить о сеансах и пользователях: если период бездействия пользователя на сайте продолжается более 30 минут, будет создан новый сеанс. Если прошло менее 30 минут, сеанс не прерывается.

Первый заход пользователя на сайт создает уникальный идентификатор пользователя (файл cookie, cid, Client ID), а показатели Пользователи и Новые пользователи принимает значение 1. Также создается сеанс, и он учитывается как новый. Новые сеансы, % Затем система запоминает пользователя и регистрирует для него только сеансы.

Таким образом, метрики Новые пользователи, Вернувшиеся пользователи, Пользователи, Клики, Сеансы в Google Analytics имеют существенные различия в работе и свои подводные камни. Это порождает неточность данных и ошибки в последующих выводах.

С появлением нового типа ресурса Google Analytics 4 (GA4) в 2020 году (в 2019 он назывался Web + App) произошел переход от традиционной модели Сеансы/Просмотры страниц, которую я описал в этой статье и которую использовали интернет-маркетологи и веб-аналитики более 10 лет, к модели Событие/Параметр, где концепция просмотров страниц и сеансов перестала иметь фундаментальное значение.

Что такое сессия на сайте: описание термина, использование, различия у «Яндекса» и Google

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

Понять смысл сессии на сайте очень просто на следующем примере:

1. Запустите любой браузер.
2. Залогиньтесь в двух аккаунтах одновременно (например, в аккаунте Gmail). Но у вас не получится — сперва сайт предложит выйти из какого-то одного аккаунта.
3. Откройте еще один браузер, не закрывая предыдущий. Попробуйте авторизоваться во втором Gmail-аккаунте.
4. Теперь — получилось. Сервер создал уникальную сессию для каждого браузера отдельно и мы смогли авторизоваться в 2 аккаунтах одновременно.

Сценарии сессии на сайте

Сессия как событие в «Яндекс.Метрике» и Google Analytics используется для определения поведения посетителей сайта. С сессией непосредственно связаны следующие метрики:

1. Просмотр страницы.
2. Длительность сеанса.
3. Действия за одну сессию.
4. Вовлеченность трафика.

Кроме веб-аналитики, сессия как событие применима в следующих сценариях:

• Обработка данных с дальнейшим удалением идентификационных сведений пользователей.
• Анализ внутреннего трафика.
• Тестирование серверной инфраструктуры.
• Любые события, когда необходимо создать искусственную посещаемость, например — протестировать сервер или сайт.

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

Продвижение сайтов

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

Клиент и сервер. Как происходит идентификация запроса

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

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

Сервер может различать каждый запрос, который поступает от клиента. Самый популярный вариант идентификации запроса — cookies-файл, но он не единственный. Распространена идентификация запросов клиента через параметры запроса, MAC-адрес, при помощи расширенных HTTP-заголовков.

Читайте также:
16 действенных способов увеличить трафик сайта

Как создается сессия на сайте и как заканчивается

Скриптовый язык PHP позволяет управлять сессией при помощи функции session_start() — это начало сессии — и завершать ее функцией session_destroy().

Механизм сессии строится следующим образом:

1. Клиент обращается к хосту при помощи уникального запроса.
2. Хост регистрирует обращение и присваивает клиенту ID-сессии.
3. Этот идентификатор затем используется во время регистрации последующих обращений.
4. Происходит определенное событие, и сессия завершается.

В качестве события завершения сессии могут выступать:

• Бездействие пользователя в течение 30 минут.
• Достижение определенного временного интервала.
• Обращение с авторизацией.
• Завершение сеанса.
• Обращение с некорректным ID сессии.

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

Сессия в системах аналитики «Яндекс» и Google

В «Яндекс.Метрике» термины «сессия» и «визит» можно считать взаимозаменяемыми.

Под последовательностью действий понимается любая пользовательская активность: регистрация события (например, hit или notBounce), переход по URL, просмотр страницы. Для изучения поведения пользователя в рамках визита можно использовать «Вебвизор» «Яндекс.Метрики»:

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

1. По истечении 30 минут. Этот период можно кастомизировать в настройках «Тайм-аут визита».
2. При фиксировании перехода из рекламы.

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

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

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

1. Переход по объявлению из другого источника рекламной кампании.
2. Неактивность посетителя в течение 30 минут (в настройках параметров сеанса можно кастомизировать этот интервал).
3. Наступление полуночи в часовом поясе пользователя.

Есть ли разница между сессией и сеансом

То, о чем сейчас пойдет речь, актуально для любой системы веб-аналитики. Сеанс и сессия не являются тождественными понятиями.

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

1. Переход на сайт.
2. Открытие страницы.
3. Взаимодействие с контентом.
4. Закрытие страницы по любой причине.

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

Читайте также:
Как создать карту сайта (sitemap.xml)

Браузерное уведомление «Время сессии истекло»: почему оно появляется

Часто в браузере появляется сообщение «Время сессии истекло». Оно может появляться при разных сценариях, но все они сводятся к одному: продолжительное бездействие на странице.

Стандартное время окончания сессии в языке PHР по умолчанию составляет ровно 24 минуты.

Если страница загружается дольше, появляется эта ошибка.

Присоединяйтесь к нашему Telegram-каналу!

• Теперь Вы можете читать последние новости из мира интернет-маркетинга в мессенджере Telegram на своём мобильном телефоне.
• Для этого вам необходимо подписаться на наш канал.

Заключение

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

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

Время ожидания сеанса в Google Analytics 4

Что такое время ожидания сеанса в Google Analytics 4? Чем оно отличается от Universal Analytics? Как его настроить? Подробнее в этом материале.

Общая информация

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

Сеанс (Session) — последовательность взаимодействий пользователя с вашим сайтом, которую он выполнил за определенный промежуток времени. Взаимодействиями можно считать:

• просмотры страниц;
• события (клик по кнопке, отправка формы, просмотр видео, скроллинг страницы и т.д.);
• совершенные транзакции;

А определенный промежуток времени — это нечто иное, как длительность сеанса (время ожидания сеанса), или как его еще называют, тайм-аут сеанса (session timeout). По умолчанию в Universal Analytics время ожидания сеанса составляет 30 минут. Но вы можете изменить это значение в настройках ресурса. Подробнее о том, как это делается, разберем ниже.

Когда пользователь переходит на сайт, Google Analytics регистрирует начало сеанса. Если он не взаимодействует с сайтом в течение 30 минут, а затем возвращается назад, обновив страницу, предыдущий сеанс прерывается и начинается новый.

Для наглядности разберем конкретную последовательность действий пользователя:

1. просмотр каталога сайта;
2. переход в корзину для оформления заказа;
3. переход на форму заполнения контактных данных;
4. покупка, совершение транзакции.

Пример 1. Все действия пользователя совершены в рамках одной сессии

Пример 2. Действия пользователя записались как два сеанса

В первом примере пользователь просматривал каталог сайта 10 минут, потом перешел в корзину товаров. Через 29 минут он переходит на страницу для оформления заказа, а через 5 минут на последний этап завершения заказа. Оформление заказа происходит в рамках одной сессии, поскольку еще не прошло 30 минут.

Не забывайте, что в Universal Analytics все время не суммируется (10 + 29 + 5 = 44 минуты), а при каждом взаимодействии оно сдвигается. То есть теперь 30 минут фиксируются не с момента, как пользователь оказался в каталоге, а с момента как он перешел в корзину товаров.

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

Настройки сеанса в Universal Analytics

Чтобы длительность сеанса считалась иначе, вы можете изменить значение 30 минут в разделе Код отслеживания — Настройки сеанса:

Время ожидания сеанса в Universal Analytics

Когда вы смотрите фильм на сайте или обучающий вебинар длиной 3 часа, при такой настройке сеанса он закрывался бы каждые 30 минут и в Universal Analytics мы увидели бы 6 сеансов (180 минут / 30 минут = 6). Хотя уникальный пользователь всего 1. В данном случае время ожидания сеанса можно увеличить. Диапазон изменений времени в Universal Analytics – от 1 минуты до 4 часов 59 минут.

Можно рассмотреть и другой пример: когда вы зашли на мой сайт, чтобы прочитать эту статью, был запущен сеанс. И если вы сейчас чем-то отвлеклись, а через 30 минут (или больше) вернулись, чтобы продолжить просмотр текущей публикации и других материалов блога, для вас будет засчитан новый сеанс. Это в том случае, если бы я использовал настройки Universal Analytics по умолчанию.

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

• через 30 минут бездействия (время ожидания сеанса по умолчанию);
• в полночь (если вы загрузили страницу в 23:58, а на следующую перешли в 00:02, то будет создано два сеанса. Один зафиксируется с 23:58 до 23:59, а второй с 00:00 следующего дня. Время окончания дня определяется настройками часового пояса на уровне представления);
• в случае смены источника кампании (при изменении любого из перечисленных параметров URL независимо от фактического времени, прошедшего в текущем сеансе: utm_source, utm_medium, utm_campaign, utm_content, utm_term,utm_id и gclid);
• при переходе по ссылке с другого сайта ( / referral).

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

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

Часть заказов присваивается платежным системам, а не реальному источнику трафика

Чтобы этого избежать, в Universal Analytics существует настройка на уровне ресурса, которая называется Список исключаемых источников перехода. Подробнее об этом читайте в этой публикации. В Google Analytics 4 это тоже нужно сделать. Подробнее здесь.

Прямой трафик (direct / none) не заменяет существующие данные об источнике и не разрывает сеанс. Если вы переходите на сайт через поисковую выдачу, а потом в течение 30 минут возвращаетесь по прямому заходу, набрав url-сайта в адресной строке браузера, то такие действия будут отмечены как один активный сеанс.

Время ожидания сеанса в Google Analytics рекомендуют не менять, чтобы уменьшить расхождение статистики в счетчиках Яндекс.Метрики и Universal Analytics, поскольку и там и там оно одинаково:

Аналогичный тайм-аут визита в Яндекс.Метрике (от 30 до 360 минут)

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

Каких-то конкретных рекомендаций по тайм-ауту сеанса для разных тематик сайтов или типов бизнеса дать не представляется возможным, поскольку все индивидуально. Но учитывая вышеописанное и ограничения, связанные с выставлением значений в настройках счетчиков Яндекс.Метрики и Universal Analytics, если используете на сайте оба счетчика:

• время ожидания сеанса устанавливаете от 30 минут (в Universal Analytics можно задать меньше, а в Яндекс.Метрике нельзя);
• если пользователи подолгу просматривают на вашем сайте контент, то тайм-аут сеанса следует увеличить (вспомните пример с просмотром фильмов, вебинаров и т.д.);
• если на вашем сайте разработчик внедрил автоматическое завершение сеанса по истечении определенного времени, которое отлично от текущего в счетчике, то для синхронизации веб-сервера и Universal Analytics можно выставить одинаковое значение. Например, в PHP этот параметр равен 24 минутам или 1440 секундам).

Настройки сеанса в Google Analytics 4

В новом счетчике есть существенные отличия в подсчете сеансов в отличие от своего предшественника. Например, количество сеансов в Google Analytics 4 может быть меньше, чем для ресурса Universal Analytics. Это происходит потому, что при изменении источника кампании в течение сеанса в GA4 не создается новый сеанс, а в UA создается.

Также если сеанс начинается в один день и заканчивается в другой день (например, с 23:55 и до 00:05), в Google Analytics 4 он считается одним сеансом, но учитывается для каждого из этих двух дней. Поэтому никогда не сравниваете количество сеансов в старом и новом счетчиках, они никогда не будут совпадать!

Примечание: также, как в Universal Analytics, в Google Analytics 4 сеанс завершается через 30 минут бездействия.

Сеанс в GA4 начинается, когда пользователь просматривает страницу на вашем сайте, при этом никаких других активных сеансов у него нет. С сеансами в Google Analytics 4 связано три важных показателя:

1. Сеансы (Sessions) — количество новых сеансов, начавшихся на веб-сайте или в мобильном приложении. Считается по автоматически регистрируемому событиюsession_start.
2. Сеансы с взаимодействием (Engaged sessions) — количество сеансов, продлившихся более 10 секунд, включающих конверсию или состоящих из просмотра не менее двух страниц/экранов.
3. Сеансы с взаимодействием на пользователя (Engaged sessions per user) — отношение числа сеансов с взаимодействием к количеству пользователей.

В Google Analytics 4 понятие «отказов» (показатели Показатель отказов, Отказы) заменено на Сеансы с взаимодействием (Engaged sessions).

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

Чтобы сеанс в GA4 считался как сеанс с взаимодействием, пользователь должен выполнить хотя бы одно из следующих действий:

• активно взаимодействовать с вашим сайтом или приложением не менее 10 секунд;
• выполнить конверсию;
• просмотреть 2 или более страниц/экранов.

Если проще, то если сеанс длится дольше определенного времени, он становится сеансом с взаимодействием. Условие с временной меткой, которое добавили в Google Analytics 4, очень важно и многое меняет. Теперь получается, что если пользователь был на сайте менее 10 секунд и не совершал никаких взаимодействий, то такой сеанс определяется как отказ (без взаимодействия), если больше, но все равно не совершал никаких событий, то уже не отказ, а сеанс с взаимодействием!

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

Несмотря на то, что временной порог у двух систем аналитики отличается (в GA4 — 10 секунд, в ЯМ — 15 секунд), его можно поменять в настройках ресурса.

Чтобы изменить значение таймера сеанса с взаимодействием и время ожидания сеанса в Google Analytics 4, на странице Администратор перейдите к нужному ресурсу и выберите Потоки данных:

Выберите поток данных сайта:

Поток данных — ваш веб-сайт

В разделе Дополнительные настройки нажмите на Дополнительные настройки добавления тегов:

Дополнительные настройки добавления тегов

В открывшемся окне выберите Откорректируйте длительность сеанса:

Откорректируйте длительность сеанса

В настройке Откорректируйте время ожидания сеанса (session timeout) установите новое значение в часах и минутах:

Время ожидания сеанса в Google Analytics 4

Диапазон изменений времени ожидания сеанса в Google Analytics – от 5 минут до 7 часов 55 минут.

Под длительностью сеанса располагается настройка таймера для сеансов с взаимодействием (timer for engaged sessions), которую также можно изменить:

Таймер для сеансов с взаимодействием

К сожалению, ввести вручную число не удастся, его можно выбрать только из выпадающего списка с шагом в 10 секунд — 10, 20, 30, 40, 50, 60. Поэтому таймер для сеансов с взаимодействием в Google Analytics 4 не будет равен тем же настройкам в Яндекс.Метрике, где за пороговое значение принято 15 секунд.

Для того, чтобы попробовать сделать его одинаковым в двух системах аналитики, можно изменить таймер для сеансов с взаимодействием с 10 секунд до 20, а также настроить отправку в GA4 «искусственного события» через 15 секунд после того, как пользователь перешел на сайт. Например, с помощью Google Tag Manager и триггера Таймер.

Однако я считаю это действие бесмысленным, поскольку Яндекс.Метрика использует традиционную модель отслеживания на основе визитов, просмотров страниц и отказов, а Google Analytics 4 перешел на модель данных, управляемую на основе событий, параметров и свойств пользователя. И одинаковые данные в обеих системах, при всем желании, сделать не получится.

После изменений не забудьте сохранить настройки.