Передача IP-адреса в Google Analytics 4

06 июля, 2024

Обновленный материал по передаче IP-адресов пользователей вашего сайта в Google Analytics 4 с использованием Google Tag Manager.

Содержание

Зачем нам IP-адрес в аналитике?

IP-адрес для инструментов веб-аналитики - это тема, которую продолжают обсуждать интернет-маркетологи и которая остается популярной на протяжении последних десяти лет. Нужно ли отправлять IP-адрес в Google Analytics 4 или нет? Поможет ли он чем-то при анализе собранных GA4 данных? А в блокировке "сомнительных переходов" Google Ads, чтобы не скликивали рекламу? Можно ли вообще отправлять его в свой ресурс аналитики или нет? Что ж, давайте разбираться.

Очень часто пользователи моего сайта читают статьи и пытаются выполнить отслеживание по определению IP-адреса пользователя, чтобы впоследствии передать это значение в Яндекс Метрику или Google Analytics 4. В связи с этим в своем блоге я опубликовал ряд материалов на эту тему:

Но вопрос остается открытым - можно или нельзя? Если можно, то как теперь передать IP-адрес пользователя в Google Analytics 4? Попробуем разобраться.

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

Примечание: Google Analytics 4 собирает все данные с устройств в ЕС (определяется по местоположению IP-адреса) через домены и на серверах, которые размещены на территории ЕС, а затем выполняет переадресацию трафика на серверы Google Analytics для обработки.

В соответствии с GDPR (Общим регламентом по защите данных ЕС) IP-адрес пользователя является персональной информацией пользователя, поскольку он может использоваться для определения и идентификации конкретного пользователя в сети.

Даже если желаете отслеживать IP-адреса собственных пользователей и передавать их в GA4 исключительно для обучающих/внутренних целей, вы не должны забывать про такое понятие, как кардинальность (cardinality). Кардинальность характеризует уникальность данных. Высокая кардинальность - уникальные данные, низкая кардинальность - повторяющиеся данные.

Например, стандартный отчет Google Analytics 4 по полу пользователей содержит высокоповторяющиеся данные, поскольку параметр Пол (Gender) может принимать всего три значения - male, female и unknown. Каждый пользователь имеет одно из перечисленных состояний, и когда вы будете анализировать данные в разрезе каждого пользователя, то в столбце Пол будете видеть много повторяющихся значений. Это низкая кардинальность. Стандартный отчет по браузерам обладает меньшим количеством повторяющихся данных, поскольку параметр Браузер (Browser) принимает больше разных значений. Не три браузера, а их гораздо больше - Chrome, Safari, Android Webview, Firefox, Edge, Opera, YaBrowser, Samsung Internet и т.д. В этом случае говорят о нормальной кардинальности. А вот отчеты по городам или целевым страницам (страницам входа) обладают уникальными данными, так как география пользователей еще более обширна, чем количество тех же браузеров, а страницы, на которые могут приземляться посетители на вашем сайте, могут исчисляться сотнями и даже тысячами.

Если вам интересно подробнее узнать о том, как Google Analytics 4 собирает, обрабатывает данные и представляет их в ваших отчетах, обязательно посмотрите эту лекцию (про кардинальность на 2:23:50):

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

Какие еще данные обладают высокой кардинальностью? Например, информация о телефонах/e-mail пользователях, тот же уникальный идентификатор пользователя Client ID и User ID. Если в предыдущей версии Universal Analytics мы передавали их как специальные параметры и не задумались о последствиях, то в Google Analytics 4 так делать уже не следует. Google в официальной документации в способах предотвращения появления строки (other) пишет следующее: не используйте параметры с большим количеством уникальных значений, если этого можно избежать. Такие параметры увеличивают количество строк в таблице и могут привести к тому, что ограничение для ресурса будет превышено. Не настраивайте специальные параметры, чтобы создавать отдельные идентификаторы для каждого пользователя.

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

Так или иначе, многие все же хотят настроить передачу данных IP-адреса в GA4. Но какой практический смысл? Хорошо, вот у вас есть Исследование, в котором вы можете выбрать специальный параметр IP-адрес, и даже использовать его для просмотра количества событий или активных пользователей.

Пример Исследования с IP-адресом

Что вы дальше будете делать с этой информацией? Как она позволит вам улучшить ключевые показатели эффективности бизнеса (KPI)? Ответить сложно. В Universal Analytics мы еще строили отчеты по IP-адресу с привязкой к Client ID (уникальному идентификатору пользователя), чтобы видеть различные комбинации и детализацию вплоть до отдельной сессии пользователя.

Client ID и IP-адрес (пример специального отчета Universal Analytics)

С другой стороны, такая аналитика нужна для проектов, которые уже внедрили сквозную аналитику и хотят работать в плоскости клиент/CRM - пользователь/аналитика. Но даже в этом случае нет необходимости передавать IP-адрес в Google Analytics, чтобы узнать что-то дополнительное о пользователе. Достаточно передать всю необходимую информацию о лиде/заказе в саму CRM в отдельные поля карточки клиента, в том числе Client ID, извлеченный из файла cookie _ga, или User ID, определенный системой вашего сайта, и уже потом объединить данные CRM и счетчика аналитики с помощью этого идентификатора. Вряд ли IP-адрес вам как-то поможет в этом.

Другой пример, который я часто слышу от своих слушателей и подписчиков - это борьба со спам-трафиком и скликиванием рекламы. Аргумент такой: если я буду знать IP-адрес пользователя, который переходит на сайт и скликивает мою рекламу, то его можно заблокировать по IP-адресу в настройках Google Рекламы. И тогда мы сэкономим бюджет на рекламу.

Исключение IP-адресов в настройках Google Рекламы

Это не так. Если было бы все так просто, то не было бы целой индустрии кликфрода и специальных сервисов по защите от скликивания, которые пытаются отличить хороший, качественный трафик от мошеннического. И там анализ идет не только по IP-адресу, но и по целому ряду других технических и поведенческих критериев. User-Agent, провайдер трафика, география, файлы cookie, информация об устройстве, версия браузера, часовой пояс, язык, время клика, время конверсии, использование прокси, fingerprint, анализ движения мыши, анализ поведения пользователя, Google reCAPTCHA, скорость выполнения действий (клики, набор текста на клавиатуре, скроллинг/прокрутка страницы, просмотр видео), разница во времени между двумя событиями, общее время нахождения на странице, длительность визита и т.д.

Читайте еще:

И это только верхушка айсберга. Целые команды разработчиков (как со стороны сервисов, так и на стороне рекламных инструментов) ежедневно работают над совершенствованием своих алгоритмов классификации машинного обучения, используя самые передовые технологии, ИИ, чтобы решить эту узкоспециализированную проблему, или, по крайней мере, постараться снизить ущерб рекламодателей от кликфрода. И даже у них это не особо получается. А чего уж говорить про нашу текущую настройку IP-адреса для Google Analytics 4... Один настроенный параметр абсолютно никак не решит эту проблему.

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

Создание правила для внутреннего трафика по IP

Но даже в этом варианте передавать сам IP-адрес в GA4 не требуется. Его нужно только узнать и прописать в соответствующее поле. Подробнее об этом читайте в этом статье.

Единственный пример, который оправдывает передачу IP-адреса пользователя в счетчики аналитики (Google Analytics 4 или Яндекс Метрику) - это использование IP в качестве индикатора для выявления резких скачков неопознанного трафика и сопоставления количественных данных в отчетах с журналами сервера (log-файлами на стороне вашего хостинг-провайдера). Что я имею в виду?

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

Пример резкого скачка прямых заходов в Яндекс Метрике

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

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

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

Пример журнала сервера

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

Активация журналов сервера на хостинге

Примечание: у каждого хостинг-провайдера свои настройки по журналам сервера. Подробности уточняйте у техподдержки.

Журнал сервера позволит проанализировать пользовательскую активность, а также выявить злоумышленников при возникновении странных запросов и понять причину резкого повышения нагрузки (CP) на сайт. А вот в связке с переданным IP-адресом в аналитику у вас появляется возможность найти те самые запросы, которые регистрирует аналитика, и заблокировать их на уровне сервера, до их появления в Яндекс Метрике и Google Analytics 4.

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

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

Если вы хотите оградиться от мошеннических роботов, представляющихся роботами Яндекса или Google, вы можете использовать фильтрацию, основанную на обратных DNS запросах. Такая схема более предпочтительна по сравнению с управлением доступом на основе IP-адресов, так как она устойчива к изменениям внутренних сетей.

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

Настройка IP-адреса

Настройку будем выполнять с использованием Google Tag Manager. Следует отметить, что отслеживание IP-адреса пользователя напрямую через JavaScript не является возможным из-за ограничений безопасности, установленных в браузерах. Обычно IP-адрес пользователя получают на стороне сервера, а затем передают в клиентский JavaScript, если это необходимо. Подробнее про такой способ вы можете почитать в этой статье.

В качестве подтверждения мной написанного вы можете обратиться за помощью к Gemini, чтобы он написал вам код с нуля. Вопрос может быть таким: Напиши мне JavaScript код на ECMAScript ниже 2015, который бы позволил отслеживать IP-адрес пользователя на сайте, и чтобы это значение сохранялось в глобальной переменной JavaScript.

Ответ Gemini

Как видите, чат-бот от Google ответил так же. Либо серверная часть, либо альтернативное решение - использовать сторонние API. Причем пример кода он не привел. Но если воспользоваться другим чат-ботом на базе нейросетей, то там может быть совершенно другой результат:

Альтернативное решение от другого чат-бота (на базе ChatGPT)

Если вам интересно, как еще можно использовать нейросети в качестве помощников для Google Tag Manager, обязательно прочитайте это руководство.

Создание тега

Перейдите в свой контейнер Google Tag Manager и создайте тег типа Пользовательский HTML. Добавьте в него нижеприведенный код:

<script>
// Создаем функцию для получения IP-адреса
function getIP() {
  var xhr = new XMLHttpRequest();
  xhr.open("GET", "https://api.ipify.org?format=json", false);
  xhr.send();

  if (xhr.status === 200) {
    var response = JSON.parse(xhr.responseText);
    return response.ip;
  }
}

// Получаем IP-адрес пользователя и сохраняем его в глобальной переменной
window.userIP = getIP();
</script>

// Создаем функцию для получения IP-адреса

function getIP() {

var xhr = new XMLHttpRequest();

xhr.open("GET", "https://api.ipify.org?format=json", false);

xhr.send();

if (xhr.status === 200) {

var response = JSON.parse(xhr.responseText);

return response.ip;

}

// Получаем IP-адрес пользователя и сохраняем его в глобальной переменной

window.userIP = getIP();

</script>

В Google Tag Manager это будет выглядеть так:

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

В качестве триггера активации задайте Initialization. Сохраните тег.

Создание переменной

Значение IP-адреса будет храниться в глобальной переменной userIP. Для его извлечения и передачи в Google Analytics 4 создайте пользовательскую переменную типа Переменная JavaScript с этим именем:

Переменная JavaScript

Задайте переменной название (например, userIP) и сохраните ее.

Добавление переменной в тег Google

Все, что осталось сделать - это добавить созданную переменную в тег Google, чтобы IP-адрес пользователя передавался с каждой загрузкой счетчика GA4. Для этого перейдите в свой тег Google и в общих параметрах события добавьте параметр (например, user_ip) со значением переменной:

Параметр события в теге Google

Сохраните тег.

Проверка передачи IP-адреса

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

IP-адрес пользователя в параметре события

Аналогичным образом можно проверить с помощью инструмента DebugView:

IP-адрес пользователя в DebugView

Создание специального параметра

Поскольку мы передаем IP-адрес пользователя в параметре события, то для дальнейшей работы в интерфейсе Google Analytics 4 необходимо создать специальный параметр.

Задайте произвольное название параметра, область действия - Событие, а в качестве параметра укажите то значение, которое вы использовали в теге Google. В моем примере - это user_ip:

Специальный параметр для IP-адреса

Сохраните специальный параметр. Подождите 24 часа, пока данные об этом параметре начнут поступать в ваш ресурс Google Analytics 4.

IP-адрес в отчетах

Теперь вы можете использовать созданный параметр в своих отчетах и Исследованиях GA4.

Пример специального отчета с IP

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

Метки: Google Analytics 4, Google Tag Manager, IP-адрес