Сеансов меньше, чем пользователей. Кейс по устранению

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

В моем блоге большинство статей посвящено разбору технических настроек аналитических инструментов, среди которых - Google Analytics, Google Tag Manager и Яндекс.Метрика. Про практические примеры анализа данных с помощью отчетов, из которых делались невероятные выводы, кардинально влияющие на показатели бизнеса, написано не так много. С одной стороны, это связано с тем, что интересные задачи встречаются крайне редко (если делать по инструкции и чек-листам, то количество ошибок и вариаций сводится к минимуму), с другой - работа со статистикой подразумевает нахождение трендов/аномалий, определение причинно-следственных связей, построение логических цепочек, предположений и выводов. А это достаточно сложно и всегда индивидуально, поскольку процессы человеческого мышления (то, как ты думал во время решения задачи) содержат в себе элементы творчества и креатива, тяжело поддающиеся систематизации и формализации на бумаге. Еще встречается и NDA (соглашение о неразглашении).

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

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

Но когда мне написал слушатель, в его основном счетчике Universal Analytics картина была другой:

Диапазон дат выставлен одинаковый (январь 2022), никаких фильтров и других ограничений в представлении Universal Analytics нет. Оба счетчика установлены через Google Tag Manager. Почему же в одном случае он показывает общее количество пользователей 12 299, а сеансов 20 061, а в другом - 26 700 пользователей и только 20 417 сеансов? Проблема с пользователями, сеансами? Что на них так влияет? К сожалению, техническая поддержка Google дала поверхностный комментарий, сославшись на то, что разница в отчетах заключается в том, что у нас на одном сайте было установлено сразу несколько счетчиков Google Analytics, что крайне не рекомендуется.

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

Вместе со слушателем было принято решение поставить второй счетчик Google Analytics, параллельно "проблемному", без каких-либо настроенных целей, событий, электронной торговли, наложенных фильтров, дополнительных представлений и т.д. Чтобы в процессе накопления статистики в обоих счетчиках можно было бы сравнить итоговые значения и увидеть расхождения в данных. Собственно, на двух скриншотах выше - это результат данного действия. Новый "чистый" Google Analytics собирает данные так, как обычно - сеансов больше, чем пользователей, а второй наоборот. Значит проблема в старом счетчике слушателя. Начинаем расследование!

Первое, что бросается в глаза в том же отчете по источникам трафика - статистика по прямым заходам:

В обоих случаях количество сеансов для (direct) / (none) схоже, по крайне мере порядок (1 202 и 1 220). А вот количество пользователей отличается очень сильно - 11 861 vs 844. Есть еще определенные отличия в данных по платному трафику google / cpc и yandex / cpc, но об этом чуть позже.

Следующий шаг, который логичен - это проверить страницы, на которые попадали пользователи из данного источника трафика сразу же после перехода на сайт. Создав сегмент на прямые заходы, перейдем в отчет по страницам входа в разделе Поведение - Контент сайта. Просмотрев весь список страниц входа, мы находим целевую страницу (Landing Page) с именем (not set), которая имеет такие показатели:

• Сеансы - 3
• Новые сеансы - 366 500%
• Новые пользователи - 10 995
• Показатель отказов - 0%
• Страниц/сеанс - 0%

В новом "здоровом" счетчике Google Analytics страницы с названием (not set) нет. Явно что-то не то! Откуда взялся (not set)? В официальной документации Google разобрано несколько примеров появления такого значения в отчетах Google Analytics, а также дается следующее определение:

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

Что это значит? Как вы уже знаете из моих других публикаций в блоге, в основе принципа работы счетчика Universal Analytics лежат области действия (Scope). Они разделены на 4 типа:

1. пользователь (user);
2. сеанс (session);
3. хит (hit);
4. товар (product) - для электронной торговли.

Хит (обращение, hit) – любое отдельное взаимодействие пользователя с сайтом, в результате которого данные отправляются в Google Analytics. Хитами могут быть: просмотр страницы/экрана, транзакция, просмотр видео, скачивание файла, скроллинг или любое другое событие. При заходе посетителя на сайт сразу отправляется первый хит – просмотр страницы (pageview).

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

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

Таким образом, хиты происходят в сеансах, которые привязываются к определенному пользователю, который имеет свою куку и Client ID. 1 пользователь может совершить 5 сеансов и в них 25 обращений. Именно так данные в Google Analytics объединяются и привязываются к конкретному пользователю. Поэтому в отчетах Google Analytics мы видим, что сеансов больше, чем пользователей. Но у нас наоборот.

Если в рамках сеанса не зарегистрировано ни одного просмотра страниц или экранов, то в отчете по целевым страницам будет (not set). Но просмотр страницы (pageview) или экрана (screenview) - это лишь один из типов обращения Google Analytics. Есть еще событие (event), транзакция (transaction), социальное взаимодействие (social), пользовательское время (timing), исключение (exception).

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

Параметры

• Целевая страница
• Категория событий

Показатели

• Пользователи
• Сеансы
• Всего событий

Находим новую улику - событие расширенной электронной торговли Enhanced Ecommerce имеет целевую страницу (not set) и генерирует большое количество пользователей (14 851!):

В остальных случаях целевая страница ведет на реальный URL-адрес, а соотношение пользователей и сеансов сохранено (сеансов больше, чем пользователей). Сделав простой фильтр над таблицей по целевой страницей (not set), а также добавив еще один параметр Действие по событию, получим таблицу с такими данными:

Получается, что события Enhanced Ecommerce как-то влияют на показатель Пользователи в отчетах Google Analytics.

Кстати, если в специальный отчет добавить еще параметр Источник или канал, то увидим, что помимо прямых заходов аномальные значения представлены в платном трафике google / cpc и yandex / cpc, о которых я упомянул чуть ранее, а также в ряде других источников.

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

Создав еще один сегмент по прямым заходам и с условием целевой страницы, равной (not set), вернемся в отчет по источникам трафика. Поскольку в "больном" счетчике настроены события расширенной электронной торговли, мы можем посмотреть, были ли какие-нибудь транзакции по данному срезу. И если да, то какие у них идентификаторы транзакций и суммы покупок. Это даст нам возможность проанализировать данные по заказам в администраторской панели сайта OpenCart (реальные ли они?), а также посмотреть историю всех посещений, сеансов и обращений (хитов) по уникальному идентификатору пользователя в Google Analytics, которые совершали покупатели на сайте, через отчет Статистика пользователей в разделе Аудитория.

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

За весь январь 2022 года было совершено 8 транзакций на сумму 573,29$ по прямым заходам (direct / none) со значением целевой страницы входа (not set). Добавив дополнительный параметр Идентификатор транзакции к отчету, можно сопоставить эти заказы с реальными данными.

Например, возьмем транзакцию 4603 на сумму 71,85$ и в отчете Конверсии - Электронная торговля - Эффективность продаж посмотрим, какие продукты были куплены и на какую сумму:

Тоже самое сделаем, перейдя в админку сайта:

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

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

Смущает две вещи:

1. измененные идентификаторы клиентов;
2. меньшее количество транзакций, чем в отчете по источникам;

Идентификатор клиента (Client ID, уникальные идентификатор пользователя) - это метка, состоящая из случайного числа и даты первого посещения пользователем сайта в Unix формате, которая сохраняется в основном файле cookie (_ga) в течение 2 лет. Она создается сразу же после того, как посетитель впервые зайдет к вам на сайт.

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

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

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

Сегмент с "нулевыми сеансами" выдал следующие результаты:

46,9% от всех пользователей за отчетный период составляют "нулевые сеансы". Причем все идентификаторы клиентов изменены, а 12 099 пользователей сгенерированы этими четырьмя Client ID. Кликнув на модицифированный идентификатор клиента, попадаем в карточку данного пользователя. И там нас ждет очередное удивление:

Первое и единственное для данного пользователя событие было Покупка - Purchase (Enhanced Ecommerce). Вы когда-нибудь видели, чтобы пользователь, перейдя на сайт, сразу же совершал покупку, без просмотра карточек товара, без добавления товаров в корзину, без ввода контактной информации, без перехода со страницы на страницу и т.д.? Да еще и с нулевым сеансом? Я нет. Но именно такое поведение может происходить в том случае, если данные события отправляются извне с помощью Measurement Protocol, без фактического перехода пользователя на сайт.

Анализ отчетов оставшихся пользователей показал то же самое - первым и единственным событием была Покупка - Purchase. Значит помимо того, что у слушателя некорректно настроена электронная торговля, так еще и активирована опция отправки офлайн-событий в Universal Analytics. Этот вопрос я задал человеку напрямую, на что получил положительный ответ. На сайте на OpenCart был установлен модуль SP SEO Remarketing All In One Pro и включена функция Ecommerce - Measurement Protocol:

Хорошо, что у данного плагина есть логирование (запись) отправленных событий Measurement Protocol. Включив ее, можно узнать о том, какие события передаются в счетчик Google Analytics, когда и с какими параметрами запроса:

Лог показал, что в одно и то же время для одного и того же пользователя с модифицированным Client ID отправляется несколько одинаковых событий. На примере ниже, таким событием является Product Clicks:

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

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

Настроив специальный параметр Client ID, можно посмотреть какое кол-во событий передается для конкретного пользователя.

Как видно из скриншота выше, один конкретно взятый пользователь за один день совершил 470 событий Product Clicks. Все те же клики по товарам, что были отправлены через MP и записаны в логе. Странно ли это? Да, потому что в отчете Статистика пользователей по данному пользователю эти события были совершены за 1 сеанс в интервале 29 минут, о чем свидетельствует поминутное логирование:

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

При его использовании важно правильно настроить запрос, который будет отправляться в Google Analytics и связываться с хитами, сессиями и пользователем. Ключевым параметром для связки транзакции с конкретным пользователем в Google Analytics является уникальный идентификатор клиента (Client ID, cid), о котором шла речь выше. Для каждой транзакции, пересылаемой по Measurement Protocol, Client ID должен соответствовать пользователю, совершившему этот заказ на сайте. Иначе многие ваши заказы будут иметь неправильно определенный источник трафика direct / none. Что у нас и произошло. Идет классический разрыв сеанса, когда пользователь, перешедший на сайт, получил определенный Client ID, а транзакция была привязана к совершенно другому идентификатору клиента. Тем самым происходит разрыв данных.

Поскольку модуль электронной торговли отправляет данные Enhanced Ecommerce через Measurement Protocol как события, самое время вспомнить, как они работают в Universal Analytics и из чего состоят. В моей другой статье эта тема разбирается очень подробно. Для нас важно то, как в Google Analytics отправляются события, посредством каких запросов и компонент.

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

- для analytics.js:

- для gtag.js:

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

, где:

• eventCategory (Категория события, обязательный параметр) – общее имя для группы объектов, которое нужно отслеживать. Например: кнопка, форма, ссылка и т.д.;
• eventAction (Действие по событию, обязательный параметр) – определяет тип взаимодействия пользователя с объектом сайта. Например: клик, просмотр, загрузка и т.д.;
• eventLabel (Ярлык события, необязательный параметр, но рекомендуемый) – это категория (группа), к которой относится отслеживаемый объект. Например: «навигационное меню»;
• eventValue (Ценность события, необязательный параметр) – целочисленное значение, которое можно использовать для предоставления данных о событии пользователя, например: «время, сумма транзакции, прохождение n-ого уровня в игре и т.д.»
• nonInteraction / non_interaction (без взаимодействия, необязательный параметр) - может принимать значение true (1) или false (0). Влияет на показатель отказов.

Параметр nonInteraction / non_interaction, хоть и является необязательным, но в нашем случае он крайне важен. Именно тогда, когда отправляется событие без взаимодействия (nonInteraction принимает значение true), оно не инициирует новый сеанс, поэтому количество сеансов, зарегистрированных в Google Analytics, не увеличивается. Но количество пользователей становится больше. И если у вас есть какое-то приложение, которое отправляет много событий без взаимодействия (у слушателя это делалось с помощью модуля Ecommerce - Measurement Protocol), то вы можете получить гораздо более высокие числа для пользователей по сравнению с сеансами.  Так было и у слушателя.

В официальной документации Google по Measurement Protocol есть параметр Пассивное событие, Non-Interaction Hit (ni=1), который указывает на то, что обращение не должно считаться взаимодействием.

В логах плагина разработчик как раз отправляет данный параметр со значением 1:

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

Но есть и другие варианты, при которых может появляться такая ошибка и в отчетах по целевой странице может присутствовать (not set). Среди них:

Закончилось время ожидания сеанса

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

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

Решение - увеличить Время ожидания сеанса с 30 минут до необходимого значения. В нашем примере это не влияет на результат.

Неправильно настроены фильтры

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

Решение - проверьте фильтры, скорректируйте их работу или вовсе удалите.

Сеанс только из событий

Если сеанс содержит только события (тип - event), и не включает просмотр страницы (тип - pageview), это также может привести к значению (not set) для целевой страницы.

Вход -> Событие 1 -> Событие 2 -> Событие 3 -> Событие 4 -> Выход

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

У Симо Ахавы (Simo Ahava) есть очень интересная статья на тему отправки событий до pageview, в которой описаны различные варианты такого поведения. Думаю, в ближайшее время сделаю перевод этого материала.

Резюме

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

• наибольшие расхождения в данных по пользователям и сеансам была зафиксировано у прямых заходов (direct / none);
• большое количество пользователей имело целевую страницу (страницу входа) со значением (not set);
• значение (not set) явилось результатом активации событий расширенной электронной торговли Enhanced Ecommerce, которые отправлялись с помощью установленного плагина интернет-магазина;
• плагин интернет-магазина некорректно передавал данные по событиям, а также неправильно связывал покупки пользователей с идентификатором клиента с помощью Measurement Protocol - перезаписывал его, обрывал сеанс, создавал сеанс без взаимодействия только с одним событием Purchase;
• конвертация валюты из интернет-магазина в транзакции Google Analytics идет с ошибками;

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

Готовые модули для различных CMS-систем очень популярны среди владельцев интернет-магазинов. Но даже для типизированных решений требуется индивидуальная и тонкая настройка, про которую многие забывают. Покупка плагина и активация ряда функций через интерфейс вовсе не означает, что он будет сразу же работать как требуется. Особенно когда делается касается отслеживания событий расширенной электронной торговли, имеющей множество вариаций (через Measurement Protocol, напрямую в коде сайта или через диспетчер тегов Google, с помощью уровня данных, библиотеки gtag.js или analytics.js и т.д.). Не ленитесь читать документацию и не стесняйтесь задавать вопросы разработчику купленного решения!