«Unassigned» в Google Analytics 4: как не потерять данные при переходе на GA4

Если на вашем сайте установлена аналитика от Google, вы, вероятно, в курсе, что с первого июля 2023 года Google постепенно отключает для ресурсов доступ к Universal Analytics. На смену же Google предлагает Google Analytics 4 — новую версию аналитики с новыми особенностями.

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

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

Как не потерять важные данные при переходе на GA4 — рассказываем дальше 👇

Предисловие: как возникла проблема с «Unassigned» при нашем переходе на GA4

Виктор, наш Head of Analytics, начал переход на GA4 еще в прошлом году, и, несмотря на прекрасную команду, этот переход не был самым легким.

Три задачи переросло в пять, пять в десять, а десять в 👇

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

Но на этом моменте Виктор увидел проблему, делавшую всю аналитику бессмысленной.

Так что дальше мы начали разбираться с проблемой Unassigned-трафика.

Чтобы лучше понять, что такое неназначенный трафик, почему он возникает и как с ним бороться, дальше приводим свободный перевод статьи «How to Fix Unassigned in Google Analytics 4» Джулиуса Фёдоровитчиуса.

Что такое «Unassigned» в Google Analytics 4

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

К примеру, у вас может быть трафик из органического поиска Bing и органического поиска Google. Оба эти источника трафика будут добавлены в группу каналов органического поиска по умолчанию.

Сейчас есть 18 групп каналов по умолчанию:

• Партнерский трафик (Affiliates). Пользователи попадают на ваш сайт или в приложение, перейдя по ссылке на партнерском сайте.
• Аудио (Audio). Пользователи попадают на ваш сайт или в приложение благодаря объявлениям на платформах для прослушивания вроде Spotify.
• Несколько сетей (Cross-network). Пользователи попадают на ваш сайт или в приложение благодаря объявлениям в разных сетях, например в поисковой и медийной.
• Прямой трафик (Direct). Пользователи попадают на ваш сайт или в приложение, нажав сохраненную ссылку или введя конкретный URL-адрес.
• КМС (Display). Пользователи попадают на ваш сайт или в приложение благодаря медийным объявлениям, включая рекламу в медийной сети Google.
• Электронная почта (Email). Пользователи попадают на ваш сайт или в приложении, нажав ссылку в письме.
• Мобильные push-уведомления (Mobile Push Notifications). Пользователи открывают ваш сайт или приложение, нажав ссылку в push-сообщении на мобильном устройстве.
• Обычный поиск (Organic Search). Пользователи попадают на ваш сайт или в приложение, нажав ссылку без рекламы в результатах обычного поиска.
• Покупки (Organic Shopping). Пользователи попадают на ваш сайт или в приложение, нажав ссылку без рекламы на торговом сайте, например, Amazon или ebay.
• Социальные сети (Organic Social). Пользователи попадают на ваш сайт или в приложение, нажав ссылку без рекламы в социальной сети.
• Видео (Organic Video). Пользователи попадают на ваш сайт или в приложение, нажав ссылку без рекламы в видео на YouTube, в TikTok и так далее.
• Другая реклама (Paid Other). Пользователи попадают на ваш сайт или в приложение благодаря рекламе на других ресурсах, не на торговом или поисковом сайте, в социальной сети или видео.
• Поисковая реклама (Paid Search). Пользователи попадают на ваш сайт или в приложение благодаря рекламе на поисковых сайтах.
• Реклама в Покупках (Paid Shopping). Пользователи попадают на ваш сайт или в приложение благодаря платной рекламе на торговой площадке, например, Amazon или ebay, или на собственном сайте розничного продавца.
• Платная реклама в социальных сетях (Paid Social). Пользователи попадают на ваш сайт или в приложение благодаря рекламе в соцсети.
• Видеореклама (Paid Video). Пользователи попадают на ваш сайт или в приложение благодаря рекламе в видео.
• Переход (Referral). Пользователи попадают на ваш сайт или в приложение, нажав ссылку без рекламы на другом сайте.
• SMS. Пользователи попадают на ваш сайт или в приложение, нажав ссылку в текстовом сообщении.

Существуют фиксированные правила относительно того, как Google назначает определенный источник трафика каждой из этих групп. Например, если посетитель пришел с известного сайта социальной сети, а utm_medium содержит cpc, это будет добавлено в Paid Social.

Вы можете просмотреть список всех правил в справке GA4, перейдя в раздел «Каналы для ручного трафика».

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

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

1. разберемся, как определить, какой тип трафика отображается как «Unassigned»;
2. рассмотрим разные ситуации, почему вы можете получить Unassigned в GA4.

Однако подчеркнем, что не все из этих ситуаций имеют известные решения (по крайней мере, сейчас).

Статья по теме:

View Post

Шаг 1.2. Как установить Google Analytics на сайт

Читать статью

Как определить, какой тип трафика отображается как «Unassigned»

В Google Analytics 4 перейдите на вкладку Reports > Acquisition > Traffic Acquisition. Советуем настроить англоязычный интерфейс GA, так удобнее работать с инструкциями.

Поскольку GA4 позволяет настраивать стандартные отчеты, левая боковая панель может выглядеть иначе. Если вы не видите раздел «Acquisition» на левой боковой панели, просто продолжайте щелкать и искать отчет, связанный с привлечением трафика.

Параметр по умолчанию в этом отчете — Default Channel Group, то есть группа каналов по умолчанию.

Если вы видите там «Unassigned», давайте определять, какой трафик считается неназначенным.

Нажмите иконку с плюсом в таблице и добавьте измерение Session source/medium. Далее в строке поиска введите «Unassigned» и нажмите Enter.

Должно получиться примерно следующее:

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

Почему возникает неназначенный трафик

Десять причин, почему в вашей аналитике может появляться Unassigned-трафик:

#1 Ваши параметры UTM не соответствуют правилам Google

Если вы предлагаете подписчикам блога или просто посетителям электронные книги или другие материалы, возможно, вы захотите отслеживать, переходят ли люди по ссылкам в них. Для нашего WordPress-гайда мы, например, используем utm_medium=guide. GA4 не знает, к какой группе каналов его добавить, поэтому такой трафик отображается как Unassigned.

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

Однако иногда компании обозначают свои маркетинговые кампании некорректными UTM-параметрами, просто не зная об этом. Вместо того чтобы использовать, например, utm_medium=email, они используют utm_medium=em или utm_medium=mail.

Ни «em», ни «mail» не будут распознаны GA4; таким образом у вас появится неназначенная рассылка.

Правильными значениями utm_medium для email-маркетинговых кампаний являются «email», «e-mail», «e_mail», «e mail». Если вы используете одно из этих значений, трафик вашей маркетинговой кампании будет назначен в группу каналов по умолчанию «Email».

Поэтому всегда следите за списком правил из справки Google-аналитики. Если возможно, старайтесь использовать значения, которые автоматически распознает GA4.

Кроме того, можно создать кастомные группы каналов в GA4, которые могут распознавать ваши собственные значения UTM. В этом случае учтите, что Unassigned останется в группе по умолчанию.

Но что делать, если большая часть вашего Unassigned-трафика — (not set)?

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

Давайте рассмотрим разные варианты.

#2 Убедитесь, что тег конфигурации GA4 срабатывает первым

Похоже, если тег события GA4 срабатывает перед тегом конфигурации GA4, это также может увеличить количество «Unassigned» источников/каналов. Поэтому вы можете настроить тег конфигурации GA4 так, чтобы он срабатывал при Initialization — All pages триггере.

Затем, если у вас есть теги событий, срабатывающих на триггере «Просмотр страницы», попробуйте задержать их, например, установив их на срабатывание на триггерах DOM ready или Window Loaded.

Это особенно важно для настроек Google Tag Manager на стороне сервера. В теге конфигурации GA4 необходимо указать URL-адрес конечной точки на стороне сервера. Если тег события сработает раньше, чем тег конфигурации, он не будет знать URL вашего сервера, и это приведет к различным неприятным последствиям. Одно из них — (not set) в отчетах.

#3 Трансляция событий с других платформ в GA4

Некоторые инструменты и платформы предлагают функцию трансляции событий в GA4, например, сервисы Amplitude или Segment.

Можно предположить, что они, вероятно, тоже используют протокол измерения GA4. Поскольку они (опять вероятно) не посылают идентификатор сеанса, все эти события будут отнесены к (not set) источнику/канала. Итак, вы получите Unassigned в GA4.

Что делать? Возможно, вам стоит рассмотреть прямую, стандартную установку GA4 через Google Tag или Google Tag Manager.

#4 Триггеры аудитории

Когда в Google Analytics 4 появилась эта функция, она позволила аналитикам создавать более сложные аудитории, и когда посетитель попадает в эту аудиторию, GA4 автоматически отправляет событие.

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

Если ваш триггер аудитории связан с прогнозируемой аудиторией, то, скорее всего, событие не будет добавлено ни к какой существующей сессии. Таким образом, источником/каналом будет (not set)/(not set), что приводит к Unassigned в Google Analytics 4.

Иногда даже обычные триггеры аудитории без компонента «прогнозирования» вызывают эту проблему.

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

#5 Параметры UTM неполные или неправильные

При использовании параметров UTM всегда указывайте по крайней мере utm_source, utm_medium и utm_campaign.

Большинство правил в документации GA4 рассматривают utm_source и utm_medium. Некоторые из них рассматривают utm_campaign.

Если ссылки ваших маркетинговых кампаний имеют, например, просто utm_campaign (example.com/?utm_campaign=upsell), utm_medium и utm_source будут (not set). Следовательно, эта кампания будет Unassigned в Google Analytics 4.

Поэтому возьмите за правило всегда использовать по меньшей мере 3 параметра UTM: utm_medium, utm_source, utm_campaign.

#6 Данные еще не были полностью обработаны GA4

Google Analytics требуется определенное время для обработки данных — от 24 до 48 часов. Поэтому если вы посмотрите на свои отчеты и проверите вчерашние или сегодняшние данные, вы можете увидеть всплеск нераспределенного трафика.

Это нормально в GA4, поэтому нужно просто подождать. Проверьте тот же диапазон дат завтра, и в разделе «Unassigned» в Google Analytics 4 должно быть меньше сеансов.

#7 Проблемы с тегированием

Если вы связываете свой ресурс GA4 с разными рекламными платформами вроде Google Ads, Display & Video 360 и так далее, то Google рекомендует использовать автоматическое обозначение тегами вместо ручного тегирования. Это связано с тем, что автоматическое обозначение меток предоставляет больше параметров, чем метки вручную.

Кроме того, если вы используете ручное и автоматическое обозначение тегами вместе, то source, medium и другие параметры классификации трафика используют значение автоматического тега.

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

#8 Отсутствует событие запуска сеанса

Этот пункт загадочный. Сессии с (not set) источниками трафика часто не имеют события session_start, которое автоматически отправляется GA4.

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

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

#9 Проблема имеет что-то общее с идентификацией пользователей

GA 4 идентифицирует посетителей разными методами: с помощью идентификатора пользователя, файлов cookie, сигналов Google и так далее. Однажды у Джулиуса был проект, столкнувшийся с большим количеством Unassigned-сессий. После того как Джулиус проверил все известные решения, он так и не смог определить причину. Поэтому начал менять разные настройки, чтобы увидеть, поможет ли что-нибудь.

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

#10 Вы неправильно используете протокол измерений

Протокол измерений или Measurement Protocol — это один из способов передачи данных в GA4. Он предназначен для передачи данных с вашего сервера (например, из CRM) в Google Analytics 4. Однако он предназначен для обогащения данных, собранных вами на вебсайте, он не инициирует новые сеансы и не создает новых пользователей.

Если посетитель был на вашем сайте и начал сессию, вы можете отправить некоторые дополнительные события с сервера и прикрепить их к этой сессии. Вы можете сделать это в течение 72 часов после начала сессии.

Если ваши разработчики отправляют данные через Measurement Protocol текущему активному сеансу на вашем сайте, каждое событие должно содержать параметры client_id и session_id. Если параметр session_id не указан (или session_id не совпадает с идентификатором текущего активного сеанса), источник трафика для этого сеанса не будет установлен.

Если ваши разработчики отправляют данные через Measurement Protocol к уже закончившемуся сеансу (но не старше 72 часов), они также должны отправить параметр timestamp_micros. Если это не будет сделано, вы уже догадались — источник/канал не будет установлен.

Вот видео-туториал, в котором Джулиус показывает, как правильно использовать Measurement Protocol.

Что именно создавало неназначенный трафик в нашей аналитике и как мы решили это

Наша проблема с GA4 возникла именно по последней причине из перечисленных в предыдущем разделе — из-за проблемы с протоколом измерения.

Какое решение нашли

Когда в поисках решения страницы в Google начали завершаться, Виктор наконец-то наткнулся на статью одного израильского аналитика по имени Or Blan.

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

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

Google, мягко говоря, не лучше всего поработал над документацией GA4 и на момент написания статьи там ничего не было по поводу идентификатора сессии. Однако Or Blan смог найти это примечание к релизу от мая 22 года, в котором вводился параметр session_id. Последующие исследования привели его к этой теме, в которой кто-то по имени Кевин из команды Google Analytics API признает, что Google нужно обновить свою документацию по этому вопросу, но не может указать конкретные сроки.

Ниже вы найдете ответ, как добавить session_id в протокол измерения GA4 и где взять этот идентификатор.

Согласно Google: «Для того чтобы активность пользователя отображалась в стандартных отчетах, таких как Realtime, engagement_time_msec и session_id должны быть переданы как часть параметров для события».

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

{
"client_id": "123123123",
"events": [
  {
    "name": "offline_purchase",
    "params": {
      "engagement_time_msec": "100",
      "session_id": "123456"
    }
  }
]}

Итак, теперь, когда мы знаем, куда его положить, нам нужно найти, как вытащить session_id и откуда.

Когда запускается событие session_start, GA создает новый session_id, но он не является частью файла cookie _ga, как это было в Universal, он является частью нового файла cookie, содержащего container_id и выглядит примерно так: _ga_XXXXXXXXXXXX, где X означает идентификатор потока.

Здесь вы можете увидеть пример, в котором выделенная часть — это session_id:

Это идентификатор сеанса в файле cookie.

Непосредственно перед session_id находится session_count, то есть числовой счетчик сеансов, в данном случае — это первый сеанс.

Теперь все, что вам остается сделать — указать вашему разработчику на это число, которое нужно извлечь из клиента, а затем передать его в протокол измерения как параметр session_id в массиве params.

Как получить идентификатор сессии

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

function getSessionNumber() {
// replace ABCDEFG with your GA Stream ID
  const pattern = /_ga_ABCDEFG=GSd.d.(w+).(d+)/;
  const match = document.cookie.match(pattern);
  const sessionNumber = match?.[2];

  if (!sessionNumber) {
    // Cookie not yet available; wait a bit and try again.
    window.setTimeout(() => getSessionNumber(callback), 200);
    return;
  }

  return sessionNumber;
}

Если вы используете GTM, вы можете воспользоваться этим скриптом:

function getSessionId() {
  var pattern = /_ga_0J0X8GBMJE=GSd.d.(w+).(d+)/;
  var match = document.cookie.match(pattern);
  var sessionId = match && match[1];

  if (!sessionId) {
    return;
  }

  return sessionId;
}