Measurement Protocol в Google Analytics 4

Вторая версия Measurement Protocol, принципиально отличается от первой версии, разберем отличия и разберемся как использовать новую версию.

• Что такое Measurement Protocol
• Для чего и когда использовать Measurement Protocol
• Когда не нужно использовать Measurement Protocol
• Принцип работы
• Measurement Protocol в Google Analytics 4
  • Адрес конечной точки
  • ClientID
  • API ключ
  • Передаваемые параметры
  • Параметры в теле запроса
• Пример отправки события
• Типы отправляемых событий через Measurement Protocol
• На что обратить внимание

Что такое Measurement Protocol

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

Вам известно, что когда пользователь переходит на сайт Google Analytics устанавливает в браузере cookie файл, содержащий некоторый идентификатор ClientID, благодаря которому все действия пользователя он объединяет в единую цепочку. Measurement Protocol позволяет добавить в эту последовательность произвольное действие, которое связано с этим ClientID.

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

Пример последовательности действий

Для чего и когда использовать Measurement Protocol

Чаще всего Measurement Protocol используют для фиксации транзакций в электронной торговле, факта создания сделки в CRM системе и других действий, которые происходят на «закрытой» или внутренней части сайта. Например, факт оплаты — это момент, когда интернет магазин получил средства к себе на счет или уведомление об успешном переводе от платежной системы. Он может произойти спустя несколько минут, после того как пользователь совершил заказ на сайте.

Когда я рекомендую использовать Measurement Protocol — только в том случае, когда действие пользователя за пределами сайта необходимо связать с источником трафика, который привел его на сайт. Например:

• покупка
• лидогенерация
• регистрация и т.п.

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

Надеюсь мне удалось разъяснить свою точку зрения по этому вопросу, если есть замечания — готов к дискуссии.

Когда не нужно использовать Measurement Protocol

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

Использование Measurement Protocol Google Analytics в подобных ситуациях не решит задачу. Все, для чего нужно его использовать фиксация некоторого факта. Все последующие действия лучше записывать в специализированные системы. Например, для CRM — использовать ее возможности, если их нет «из коробки» — не сложно проработать такой вариант, для регистрации пользователя — доработать внутренний механизм и протоколировать его путь во воронке.

Принцип работы

Принцип работы заключается в том, что на специальный URL адрес (конечную точку) необходимо отправить специальным образом сформированный запрос. И вот тут мы сталкиваемся с тем, что новый Measurement Protocol принципиально отличается от его первой версии. В первой версии вся отправляемая информация формировалась из пар: ключ = значение, в новой все по другому.

Основное — для отправки запросов в Measurement Protocol Google Analytics 4 нужно использовать только метод POST. Напомню, что ранее допускался как POST, так и GET. Также появилось такое понятие как API ключ, его необходимо предварительно сгенерировать в панели управления, но об этом ниже.

В новой версии изменился адрес конечной точки, добавлено два обязательных параметра, которые передаются в URL. Далее, сам запрос формируется также по схеме ключ = значение, но теперь можно для некоторых параметров (ключей) использовать вложенные структуры данных, за счет чего это удалось достичь? За счет того, что тело запроса (передаваемые нами данные) должны быть отправлены в JSON формате. Предлагаю перейти к настройке и разбору механизма работы протокола передачи данных Google Analytics 4.

Адрес конечной точки

Новый адрес конечной точки: https://www.google-analytics.com/mp/collect

Ранее использовался: https://www.google-analytics.com/collect

Что такое конечная точка и для чего она необходима? Конечная точка или endpoin это URL адрес, на которых вам необходимо отправить запрос или если хотите, это URL адрес по которому от вас ждут некоторую информацию. Все данные, которые планируете передавать в Google Analytics через Measurement Protocol должны быть отправлены на нее.

ClientID

В начале я упоминал про ClientID — идентификатор, по которому Google Analytics связывает действия пользователя в одну последовательность. Какое значение использовать при работе с Measurement Protocol? То, которое было у пользователя, когда он находился на вашем сайте. Как и когда его получить?

Получить его необходимо в тот момент, когда он отправляет информацию с сайта и которая попадает к вам во внутреннюю систему, например:

• отправка формы лидогенерации
• отправка заявки на обратный звонок
• регистрация

Куда его сохранить? Добавьте в вашей внутренней системе дополнительное поле для хранения CientID. Подойдет тип поля строка, длинной до 50 символов. Как это сделать на вашем проекте — уточните у разработчиков или интеграторов CRM.

Как получить ClientID? Существует несколько способов сделать это:

• извлечь из cookie файла _ga
• извлечь с помощью JavaScript непосредственно из счетчика

При извлечении из cookie файла это лучше сделать на стороне сервера. Читаем cookie файл — добавляем в поле для хранения в нашей системе.

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

Код JavaScript для извлечения ClientID в Google Analytics 4:

Этот код извлекает ClientID из первого счетчика Gogle Analytics (точнее из первого трекера Google Analytics). Если используется имя счетчика, что бывает крайне редко, то поможет код:

API ключ

В новой версии Measurement Protocol для Google Analytics 4 появился обязательный параметр API ключ. Это некоторое значение, наличие которого указывает на то, что запрос отправлен действительно из достоверного источника. Думаю, что с его появлением проблема, когда в счетчики рассылалась не желательная информация (спам) исчезнет:

Спам в счетчике Google Analytics

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

Режим администратора в Google Analytics 4

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

Выбор потока данных

В открывшемся окне переходим в нижнюю часть и выбираем О Mesurement Protocol API:

Переход к настройкам протокола передачи данных

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

Список API ключей для потока данных

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

Название API ключа

После создания ключа он отобразится в списке доступных. Скопируйте его, он понадобится для отправки запроса. Теперь у нас есть все необходимое, чтобы отправить запрос через Measurement Protocol в Google Analytics 4.

Передаваемые параметры

На текущий момент мы с вами имеем:

• ClientID
• API ключ

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

Идентификатор показателя

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

https://www.google-analytics.com/mp/collect?measurement_id=ИДЕНТИФИКАТОР_ПОКАЗАТЕЛЯ&api_secret=API_КЛЮЧ

• https://www.google-analytics.com/mp/collect — конечная точка
• ? — разделитель
• measurement_id — идентификатор показателя (копируем из настроек потока)
• api_secret — API ключ (создаем в настройках потока, затем копируем из списка созданных)

Следующий этап формирование тела запроса, это те данные, которые отправляются в Google Analytics. Описываются они по правилам JSON формата, используются пары ключ : значение, для некоторых ключей можно использовать вложенные структуры. Разберемся подробнее на примере отправки события. Событие у нас кастомное (пользовательское), не входит в список рекомендуемых , значит его название и параметры мы можем указать произвольные. Например, фиксируем регистрацию пользователя. Описываем событие:

Имя события и параметры использую только для демонстрации того, как происходит отправка данных! Что передаем:

• user_reg_custom — название события
• user_region — параметр, описывающий пользователя, регион
• user_currency — параметр, описывающий пользователя, валюта, выбранная пользователем
• user_payment_type — параметр, описывающий пользователя, предпочтительный способ оплаты

Теперь дополним эти сведения обязательным параметром client_id, который должен принимать значение, равное ClientID, который мы получили ранее:

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

Такая информация должна быть отправлена в Google Analytics 4. Обязательно в формате JSON ! Кто и как это должен сделать? Нужно подготовить ТЗ для разработчиков, в котором описать что и куда необходимо отправить. Добавить в документ необходимые идентификаторы и описать тело запроса. Способ отправки разработчики выберут самостоятельно.

Параметры в теле запроса

Тело запроса условно можно разделить на блоки:

• параметры запроса
• параметры события

К первой группе относятся следующие параметры:

• client_id — ОБЯЗАТЕЛЬНЫЙ! — идентификатор клиента
• user_id — идентификатор пользователя в вашей внутренней системе
• timestamp_micros — метка времени Unix (в микросекундах) для времени, связанного с событием. Используется только для записи событий, которые произошли в прошлом. Это значение можно переопределить с помощью user_property меток времени или событий. События могут быть зафиксированы задним числом до 48 часов
• user_properties — свойства пользователя (могут быть как автоматически регистрируемые, так и произвольные)
• non_personalized_ads — настройка персонализированный рекламы на основе события. Установите значение, true чтобы указать, что эти события не должны использоваться для персонализированной рекламы

Вторая группа описывает события:

• events[] — ОБЯЗАТЕЛЬНЫЙ! — массив событий
• events[].name — ОБЯЗАТЕЛЬНЫЙ! — название события
• events[].params — параметры события

Пример отправки события

Объединим всю информацию в готовый запрос. URL конечной точки с обязательными параметрами:

Тело запроса в JSON формате:

Отправляем POST запрос, переходим в отчеты в режиме реального времени в разделе событий должно отобразиться отправленное событие:

Проверка в режиме реального времени

Типы отправляемых событий через Measurement Protocol

Все события в Google Analytics 4 делятся на:

• регистрируемые автоматически и те, для которых зарезервированы имена
• пользовательские события

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

На что обратить внимание

Для себя я выделил несколько важных моментов. которые необходимо учесть при использовании Measurement Protocol в Google Analytics 4:

• обеспечить сохранность API ключа
• ТЗ для разработчиков, подготовленные в Google Docs, на внедрение протокола передачи данных предоставлять с доступом по ссылке для ограниченного круга лиц

Также стоит иметь ввиду. то на момент написания материала Measurement Protocol для Google Analytics 4 находится в стадии альфа тестирования. Это значит, что часть настроек может быть изменена либо функционал расширен. Советую обратить внимание на лимиты и ограничения использования. описанные в официальной документации https://developers.google.com/analytics/devguides/collection/protocol/ga4/reference/limitations