Почему сеансов больше чем кликов

Почему клики и сеансы в отчетах никогда не совпадают и это нормально?

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

Давайте разберемся, почему так происходит и как с этим быть.

Пример расхождения в отчете

Клики vs Сеансы

Для начала давайте вспомним определение.
Клик – нажатие на рекламное объявление. Фиксируется рекламным сервером.

Сеанс – последовательность взаимодействий пользователя с сайтом за указанный промежуток времени. Фиксируется системой веб-аналитики.

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

Как минимизировать возможное расхождение?

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

1. Особенности настройки счетчиков аналитики и их установки на сайте

• Счетчик не установлен на целевых страницах или моб. версии сайта
• В представлении Google Analytics стоит фильтр на целевой трафик, который не попадает в отчет

2. Проблемы с UTM метками

• Метка сформирована неверно (ошибка написания, несоблюдение правил формирования)
• Включена автоматическая пометка (может произойти затирание метки)
• В шаблоне отслеживания на уровне объявления указана ссылка без UTM (характерно для Google Ads)

Пример ссылки с корректным расположением параметров

1. Проблемы с сайтом или посадочной страницей

• Сайт «упал»
• Сайт или приложение «затирают» UTM метки
• На целевой странице настроен редирект на другую страницу без сохранения меток
• Низкая скорость загрузки сайта (40% пользователей покидают сайт, если время загрузки превышает 3 секунды)

2. Особенности поведения пользователей

• Повторные клики
• Браузер пользователя блокирует загрузку GA/Метрики (AdBlock, настройки безопасности)
• Случайный клик (пользователь закрыл сайт до того, как загрузился счетчик)

3. Особенности учета кликов для разных форматов

• Клики на промопост в соц. сетях часто ведут на сообщество внутри соц. сети
• За клики по интерактивным ссылкам (например, проложить маршрут в Google Ads) будут начисляться клики, но не будет сеанса в GA/Метрике

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

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

Почему не совпадает количество кликов и сессий в Google Analytics

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

В этой статье вы узнаете, почему так происходит и как учитывается сессия в Google Analytics.

Ситуация: сеансов больше, чем кликов

Разрыв и возобновление сеанса

Открываем Google Analytics, отчет Источники трафика / Google Реклама / Кампании:

Мы видим, что сессий больше, чем кликов: 24 927 против 13 594:

Искать причину стоит в настройках сеанса. Напомним, клиент имеет отношение к электронной торговле. Большой ассортимент товаров, покупатели проводят много времени на сайте.

Переходим в отчет Поведение / Контент сайта / Все страницы:

Это – среднее время на сайте:

В нашем случае – 54 секунды. Много, но такое бывает.

Если пользователь на сайте больше 30 минут, сессия начинается заново. И в статистике на одного пользователя получается две сессии. Аналогично – для случаев, когда пользователь отвлекся или отошел на какое-то время. Сеанс начинается заново. Это и фиксирует Google Analytics.

Анализируйте страницы, которые пользователь посетил за 1 сеанс.

В Google Analytics дефолтная сессия длится 30 минут. Цифру можно изменить в настройках администратора:

Настройки свойств / Информация о трекинге / Длительность сессии.

Недействительные клики и Google Ads

Google Реклама отфильтровывает недействительные клики, а Google Analytics нет. Этот сценарий срабатывает, например, в контекстно-медийных или ремаркетинговых кампаниях. GA все равно учитывает посещения как сеанс.

Ситуация: кликов больше, чем сеансов

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

Посетитель сравнивает цены

Клики превышают сеансы, когда пользователь изучает или сравнивает цены. Например, на телевизоры. Нажимает рекламу, возвращается и снова попадает на рекламу. Google Реклама фиксирует два клика, а Google Аналитика игнорирует просмотр дополнительной страницы и учитывает только один сеанс.

Упали метки GLID (Google Click ID)

Это метки Google Ads, которые передают в зашифрованном виде информацию о кликах в Google Analytics. GA перестала связывать клики и сессии. Сайт сделал редирект с http:// на https:// и сбросил все метки:

После обновления редирект исчез.

Клики просто потерялись по пути в аналитику.

Системы платежей с привлечением третьей стороны

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

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

Остановка загрузки страницы

Пользователи останавливают загрузку страницы кнопкой «Назад». Или вообще внезапно закрывают страницу. Google Ads клик зафиксирует, но в Google Analytics данные не попадут, так как страница загрузилась не полностью.

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

Почему сеансов больше чем кликов

+38 (067) 538 00 81

Расхождения данных о кликах из AdWords в Google Analytics
upd 27.02.2017

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

Частая проблема, когда вы запускаете рекламную кампанию в Google AdWords и после анализируете данные в Google Analytics, данные по кликам не совпадают. Но когда это 1-2%, то это не страшно, но когда данные не совпадают в два раза или вообще не отображаются, это проблема. Давай-те разберемся, почему так может происходить.

Расхождение данных из adwords в google analytics
Какие типы проблем бывают?

В целом, ситуаций может несколько:

• В отчете ACQUISITION -> AdWords -> Campaigns есть данные, но они помечены как (not set)
• Там же, есть данные по названию рекламной кампании, но кликов 0
• Там же, клики есть, но нет сенасов
• Там же, клики и сеансы есть, но данные сильно отличаются (больше, чем на 20%)

Потенциальные проблемы и как их решить

Для начала нужно понимать, что клики и сеансы (визиты) это не одно и то же. Клики – это число переходов на ваш сайт по объявлению, а Сеансы – число уникальных сеансов. Число кликов и сеансов может не совпадать.

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

Кроме того, частые проблемы возникают в:

1. Мобильная/таблет версия

Случается, что при доработке мобильной или таблет версии вашего сайта, что-то забывают, например разместить код отслеживания google analytics или tag manager, или же может быть одна из причин, описанная ниже. Чтобы проверить, заходим в отчет ACQUISITION -> AdWords -> Campaigns и добавляем в secondary dimension параметр device category, и проблема с этими версиями сразу становится явной.

2. Затирание параметра gclid

Очень частая проблема. Суть заключается в том, что существует программная (в коде сайта) или серверная перезапись/стирание параметров перехода, т.е. нашего параметра domain.com/?gclid=123ddxsa434343yz или utm-меток

Чтобы проверить, что это ваша ситуация, нужно открыть открыть отчет реального времени — источники трафика и зайти на сайт с тестовыми параметрами domain.com/?utm_source=test&utm_campaing=test

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

Кейс по устранению проблемы, приводившей к серьезному искажению данных в отчетах 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%

Целевая страница (not set)

В новом «здоровом» счетчике 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!):

События расширенной электронной торговли влияют на (not set)

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

События расширенной электронной торговли с (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)

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

Товары в транзакции (данные интернет-магазина)

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

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

Отчет «Статистика пользователей»

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

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

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

Пример основного файла cookie (_ga) для моего сайта

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

Классические идентифкаторы клиентов (Client ID)

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

Классические и модифицированные идентификаторы клиентов

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

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

Сегмент с «нулевыми сеансами»

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

Карточка пользователя с модифицированным Client ID

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

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

Ecommerce — Measurement Protocol

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

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

Дубли событий, которые передаются через Measurement Protocol в течение нескольких секунд

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

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

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

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

События Enhanced Ecommerce отдельно взятого пользователя

Как видно из скриншота выше, один конкретно взятый пользователь за один день совершил 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: