Measurement Protocol для Google Analytics 4

Руководство по использованию Measurement Protocol для веб-потоков Google Analytics 4 (GA4).

Обновление (февраль 2022): я выпустил электронное руководство по Google Analytics 4. Бесплатно скачать его можно в формате .PDF по ссылке.

Что такое Measurement Protocol?

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

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

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

• отправлять данные об офлайн-конверсиях в Google Analytics;
• связывать офлайн и онлайн-конверсии между собой;
• отслеживать клиентские и серверные взаимодействия.

Примечание: поскольку я работаю только с веб-сайтами, то описанные ниже примеры и настройки будут больше применительны к веб-потокам.

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

На мой взгляд, нет более простого и наглядного примера работы Measurement Protocol, чем показанного в этом видео:

Хоть на видео и используется Google Analytics предыдущей версии (Universal Analytics), принцип работы MP от этого не меняется.

Примечание: если вы хотите познакомиться с Measurement Protocol для Universal Analytics, то читайте эту статью.

Небольшой комментарий по видео: на планшете отображается три смайлика (зеленый, оранжевый и красный). При клике на каждый из них с планшета в счетчик Google Analytics отправляется информация о совершенном событии. Например, при нажатии на зеленый смайл, отправляется событие cool, по клику на желтый смайлик - событие good, а при нажатии на красную рожицу - событие bad.

Как это происходит? Дело в том, что планшет со смайликами подключен к интернету и является тем самым устройством, c которого отправляются http-запросы на сервера Google Analytics. Как только человек нажимает на тот или иной смайл, запускается команда, которая заранее сформирована по определенному принципу для каждого из них (разберем чуть ниже). В одном смайлике прописана специальная конструкция по событию cool, в другом - событие good, у третьего - событие bad. И когда человек кликает по одной из рожиц, система понимает какой запрос нужно отправить и автоматически делает это. Google Analytics эту информацию видит, принимает, обрабатывает, и отображает у себя в отчетах.

Пример со смайликами - это больше демонстрация работы Measurement Protocol, нежели его практическое использование. Хотя в каком-нибудь отделении банка такая оценка качества работы сотрудников вполне может пригодиться. Но есть много и других вариантов использования протокола измерений.

Примеры использования

Пример №1. Офлайн-конверсии

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

Пример №2. Офлайн-конверсии

Пользователь перешел на ваш сайт по рекламному объявлению из Google Рекламы. Client ID и gclid при этом были записаны. Человек делает заказ, но хочет оплатить его после получения. Данные по Client ID и gclid попадают в вашу базу данных / CRM-систему. Затем пользователь приезжает к вам в офис и делает покупку офлайн. С помощью Measurement Protocol конверсии можно передать в Google Analytics и Google Рекламу.

Пример №3. Изменение статуса сделки

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

Для этого требуется ряд настроек, в числе которых:

• настройка уникального идентификатора пользователя (Client ID) через специальный параметр;
• создание отдельного поля Client ID и сохранение его значения в лиде/сделке CRM;
• для каждого требуемого действия в CRM-системе сформировать свой http-запрос, который будет отправлять данные в Google Analytics после его срабатывания;
• при изменении статуса сделки в CRM отправлять событие для конкретного пользователя в Google Analytics.

Подробно эти и другие процессы сквозной аналитики разбираются в онлайн-курсе "Сквозная аналитика". Также на моем YouTube-канале есть видео, в котором с помощью нестандартных приемов работы с Google Tag Manager я создаю собственную CRM-систему на базе Google Таблиц и отправляю в нее полученные заявки с сайта. А благодаря Measurement Protocol, эти обращения привязываю к статусам сделок и передаю эту информацию обратно в Universal Analytics. Еще одна наглядная демонстрация работы протокола передачи данных:

К слову, инструменты типа Albato и ApiX-Drive позволяют автоматизировать процесс формирования и отправки http-запросов (специальных конструкций), которые понимает Google Analytics.

Пример №4. Связывание офлайн и онлайн конверсий

Если вы отслеживаете User ID, вы можете связать действия каждого человека как офлайн, так и онлайн. Например, первый контакт с вашей продукцией он совершил не в интернете, а офлайн-магазине. Во время покупки вы предлагаете ему оформить скидочную карту (просто заполнить анкету со всеми данными), а затем активировать ее на сайте в личном кабинете.

Человек оплачивает покупку офлайн (на кассе), получает скидочную карту, идет домой, садится за компьютер/телефон, регистрируется на сайте и активирует ее. Всё. С этого момента все его действия можно связать воедино. Теперь у компании есть цепочка касаний офлайн-онлайн, а предоставленная информация на кассе в анкете позволяет идентифицировать этого человека по местоположению, полу и возрасту. Теперь маркетологи компании могут отправлять ему e-mail рассылки, специальные акции, предложения, настроить на определенный сегмент ремаркетинговые кампании, отследить полный путь этого пользователя как офлайн (подарочная карта - это ваш идентификатор в офлайне), так и онлайн (Client ID / User ID - ваши идентификаторы в сети).

Пример №5. Длинный цикл сделки и много касаний

Есть такие бизнесы, в которых преобладает длинный цикл сделки (период от первого касания/знакомства с товаром или услугой до покупки) и много разных касаний, как онлайн, так и офлайн. Например, в автомобильной тематике. Ведь покупка автомобиля - большой шаг, а выбор машины – долгий и ответственный процесс. Именно поэтому многие из мужчин (да и женщин тоже) перед тем, как приобрести автомобиль, хотят убедиться, что выбранная модель отвечает всем требованиям будущего владельца.

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

Для таких проектов очень важно отслеживать всю цепочку взаимодействий от первого контакта на посадочной странице (записи на тест-драйв) до передачи ключей от автомобиля в руки новому владельцу (покупка).

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

Остался нерешенным самый главный вопрос - а как Google Analytics понимает какому конкретно пользователю записать отправляемое через Measurement Protocol событие? Ответ на него будет дан ниже.

Из чего состоит запрос?

Если у вас на сайте просто установлен счетчик Google Analytics 4, то вы уже используете Measurement Protocol. Каждый раз, когда на вашем сайте запускается событие page_view (просмотр страницы) или любое другое, http-запрос отправляется на сервера Google Analytics.

Чтобы увидеть http-запрос, который отправляет данные в Google Analytics 4, выполните следующие шаги:

• перейдите на сайт, где установлен GA4;
• в браузере откройте панель разработчика - вкладка Network (клавиша F12 для Google Chrome). Либо используйте вызов контекстного меню правой кнопкой мыши и команду Просмотреть код

• установите две галочки рядом с Preserve log и Disable cache:

• обновите страницу;

В таблице начнут появлятся строчки с различными запросами и временем их выполнения. Игнорируем это. В поле Filter введите идентификатор вашего потока данных Google Analytics 4. Он начинается на G-

Все сетевые запросы, которые начинаются с collect?v, являются запросами протокола измерений. У вас их может быть 1, 2 или больше. Все они передают информацию в Google Analytics через Measurement Protocol. Кликните по любому запросу из списка. Вы должны увидеть полную информацию о запросе:

Полный запрос протокола передачи данных может выглядеть так:

Процесс отправки данных в Google Analytics с помощью Measurement Protocol состоит из:

• строки отправки (transport);
• строки набора данных с параметрами (payload data). В официальной документации Google ее называют полезной нагрузкой.

Cтрока отправки (transport) указывает куда и как отправлять данные. Пример:

Она состоит из нескольких частей:

• метод POST - определяет, как будут отправляться данные на сервер Google Analytics (/mp/collect);
• www.google-analytics.com - расположение сервера (HOST), куда будут отправляться данные;
• адрес конечной точки - URL-адрес, на который вам необходимо отправить итоговый запрос или несколько обращений в запросе (https://www.google-analytics.com/mp/collect).

URL-адрес конечной точки может содержать /collect (одно обращение), /batch (несколько обращений в одном запросе) или /debug (проверка запроса).

Строка набора данных (payload data) содержит набор параметров, передаваемых в запросе. Пример:

Она очень напоминает url-адрес, в ссылке которого после символа ? передаются utm_метки. Только вместо привычных пяти переменных (utm_source, utm_medium, utm_campaign, utm_campaign и utm_term), разделенных между собой символом &, здесь используются другие параметры, которые точно так же отделяются друг от друга амперсандом.

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

Чтобы разобрать, из каких параметров состоит запрос, перейдите на вкладку Payload:

Вы увидите ваш запрос, разделенный на отдельные строки:

Чтобы посмотреть запрос в декодированном (понятном) виде, нажмите на view decoded:

Тогда часть значений, содержащая специальные символы (%D0%A1....), будет отображаться в удобочитаемом виде:

Каждая строка в запросе - это пара ключ=значение. Например:

То, что идет до знака равно - это ключ, после - значение. Например, ключами могут быть:

• v - версия Measurement Protocol (для Google Analytics 4 - 2, для Universal Analytics - 1);
• tid - идентификатор потока данных;
• cid - уникальный идентификатор пользователя (Client ID);
• ul - язык браузера пользователя;
• sr - разрешение экрана.

А их значения:

• v = 2
• tid = G-BMPB32GC7T
• cid = 1142061052.1623097982
• ul = ru-ru
• sr = 1536x864

Примечание: все значения должны быть кодированы в UTF-8 и URL-кодированы.

Список параметров, которые вы можете передавать в Measurement Protocol для Google Analytics 4, доступен в официальной документации Google.

Как вы уже знаете, новый Google Analytics построен на модели данных, основанной на событиях (Event data modeling). Поэтому все, что вы будете отправлять в GA4 через протокол передачи данных, также будет являться событиями.

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

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

• api_secret - секретный ключ API (API Secret);
• measurement_id - идентификатор потока данных.

Секретный ключ API

В Universal Analytics с помощью Measurement Protocol можно сформировать запрос и отправить его в абсолютно любой счетчик аналитики, и, таким образом, исказить данные в чужом проекте. Для этого достаточно знать только идентификатор отслеживания (UA-XXXXX-Y) сайта.

В Google Analytics 4 появился так называемый секретный ключ (API Secret), который является дополнительной проверкой на валидацию, что запрос действительно был отправлен из достоверного источника тем, кто владеет счетчиком GA4, а не кем попало.

Секретный ключ генерируется в интерфейсе Google Analytics. Чтобы его получить, перейдите в раздел Администратор - Потоки данных:

Выберите свой веб-поток. Затем откройте раздел О Mesurement Protocol API:

В открывшемся окне нажмите кнопку Создать:

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

На последнем шаге создания секретного ключа API укажите его псевдоним. Он нужен, чтобы вы смогли отличать API ключи друг от друга по функциональному назначению. Например, один - для передачи офлайн-конверсий, другой - для CRM-системы, третий - для телефонии и т.д. Само значение псевдонима не будет нигде использоваться, а лишь отображаться в интерфейсе Google Analytics. Допускаются как латинские буквы, так и кириллица.

После ввода псевдонима нажмите кнопку Создать:

После создания ключа он отобразится в списке доступных в столбце Значение секретного ключа:

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

Вы можете изменить псевдоним API ключа или вовсе удалить его. Для этого справа от секретного ключа нажмите на иконку с тремя точками и выберите нужное действие.

Идентификатор потока данных

Чтобы найти идентификатор потока данных Google Analytics 4, , перейдите в раздел Администратор - Потоки данных:

Выберите свой веб-поток данных:

В открывшемся окне скопируйте значение, указанное в правом верхнем углу в поле Идентификатор потока данных:

Это и есть ваш идентификатор отслеживания Google Analytics 4.

После этого можно начать формировать сам http-запрос конечной точки с необходимыми параметрами. Для Google Analytics 4 URL формируется по следующему принципу:

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

, где:

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

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

Тело запроса

Помимо параметров запроса, для отправки данных с помощью Measurement Protocol необходимо сформировать тело запроса. Это те данные, которые вы планируете передать в Google Analytics 4. Они отправляются методом POST (в Universal Analytics можно POST и GET) в формате JSON (JSON - JavaScript Object Notation) - стандартный текстовый формат для представления структурированных данных на основе синтаксиса объекта JavaScript.

Тело запроса также состоит из набора параметров, без которых передача данных в Google Analytics просто невозможна. Для веб-потоков обязательными являются:

• client_id - уникальный идентификатор пользователя (Client ID);
• events - массив объектов, в котором передаются данные о событии(ях). В одном запросе можно передавать данные о максимум 25 событиях;
• events[].name - название передаваемого события.

Помните главный вопрос, который мы озвучили выше? Как Google Analytics понимает какому конкретно пользователю записать отправляемое через Measurement Protocol событие? Именно с помощью уникального идентификатора пользователя

Помимо обязательных параметров, в Google Analytics 4 есть еще ряд необязательных, но не менее полезных параметров, которые вы можете отправить с запросом:

• user_id - уникальный идентификатор пользователя, определенный внутри вашей системы (не путать с Client ID);
• timestamp_micros - метка времени Unix (в микросекундах) используется только для регистрации уже произошедших событий. С ее помощью можно переопределять временные метки (timestamp) других событий и user_property (свойства пользователя). События можно отправлять задним числом (до трех дней) по часовому поясу ресурса;
• user_properties - свойства пользователя;
• non_personalized_ads - настройка персонализированный рекламы. Чтобы не использовать события для персонализации рекламы задайте значение true;
• events[].params - параметры события.

Примечание: для лучшего понимания как Google Analytics 4 идентифицирует пользователей, рекомендую прочитать этот материал.

Ограничения

Для Measurement Protocol в Google Analytics 4 существуют следующие ограничения:

• один запрос может содержать не больше 25 событий;
• одно событие может содержать не больше 25 параметров;
• одно событие может содержать не больше 25 свойств пользователей;
• название свойства пользователя может содержать не больше 24 символов;
• значение свойства пользователя может содержать не больше 36 символов;
• название события может содержать не больше 40 символов (буквы, цифры, знаки подчеркивания) и должно начинаться с буквы;
• название параметра может содержать не больше 40 символов (буквы, цифры, знаки подчеркивания) и должно начинаться с буквы. Это касается и параметров объектов;
• значение параметра может содержать не больше 100 символов. Это касается и параметров объектов;
• в параметрах объектов можно использовать не больше 10 специальных параметров;
• размер тела запроса POST должен быть менее 130 КБ.

Пример формирования запроса

Теперь давайте объединим все полученные знания, и сформируем итоговый запрос со специальным событием в формате JSON, используя пары ключ:значение, чтобы эта информация передалась в Google Analytics 4.

В качестве примера отправим в Google Analytics 4 запрос со следующими данными:

Название события - mp_events;

Параметры события:

• mpQuery со значением firstQuery;
• mpApp со значением eventBuilder;
• mpValue со значением 1;

Свойства пользователя:

• mpCountry со значением Russia;
• mpStatus со значением Author;

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

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

1. api_secret (секретный ключ API);
2. measurement_id (идентификатор потока данных).

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

Event Builder

Для того, чтобы упростить себе задачу формирования запроса и не ошибиться в итоговой конструкции Measurement Protocol, используйте специальный инструмент Event Builder.

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

• pageview - просмотр страницы;
• screenview - просмотр экрана приложения;
• event - событие;
• transaction - транзакция стандартной электронной торговли;
• item - товар в стандартной электронной торговли;
• social - социальные взаимодействия;
• exception - информация о возникающих на сайте ошибках;
• timing - информация о различных временных интервалах, например, время загрузки страницы.

В то время, как в Google Analytics 4 мы всегда отправляем события (events). Именно поэтому один инструмент имеет в названии приставку Hit, а другой Event. Также с помощью данных приложений вы можете вручную отправлять данные в Google Analytics (метод POST).

Итак, чтобы начать использовать Event Builder, перейдите по ссылке. Авторизуйтесь под той учетной записью Gmail, где присутствует счетчик Google Analytics 4, в которой вы планируете отправить запрос:

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

• client - поток данных, для которого вы будете формировать запрос. Если вы создаете его для веб-сайта, то ползунок должен быть переключен на gtag.js, если для мобильного приложения, то на firebase;
• api_secret - секретный ключ API;
• measurement_id - идентификатор потока данных;
• client_id - уникальный идентификатор пользователя.

И вот именно с этим полем возникает наибольшее количество вопросов у маркетологов и аналитиков. Если отправка одного запроса вручную не так сложна и может быть выполнена через тот же Event Builder, то что делать, когда пользователей на сайте / в мобильном приложении много, и требуется отложенно отправить какое-либо событие в аналитику. Например, после изменения статуса сделки CRM в Google Analytics 4? Как тогда находить этот уникальный идентификатор и автоматически подставлять в URL-адрес конечной точки для отправки?

Это достаточно сложный и комплексный процесс, который требует слаженной работы не только от вас, но и от вашего разработчика. Во-первых, он должен позаботиться, чтобы в вашу CRM-систему сохранялось значение уникального идентификатора пользователя в отдельное поле. А во-вторых, вы должны попросить своего разработчика для каждого из действий, требующего отправки через MP в GA4, сформировать свой собственный запрос, в который как раз и будет подставляться сохраненое в отдельном поле значение Client ID, динамически для каждого уникального пользователя. По аналогии с самым первым примером с тремя смайликами. В этой статье я подробно описал процесс настройки сквозной аналитики и передачу статусов сделок из amoCRM в Universal Analytics с помощью сервиса Albato.

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

• user_id - уникальный идентификатор пользователя, определенный внутри вашей системы;
• event_category - тип события: рекомендуемое или специальное;

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

Когда вы выбираете какую-либо рекомендуемую группу из списка (не Custom), в деталях события ниже автоматически будут добавлены соответствующие поля с параметрами события для нее. Вам останется только заполнить их значениями. Например, вот такие параметры события отображаются при выборе группы Retail/Ecommerce:

• event_name - название события;
• timestamp_micros - метка времени Unix (в микросекундах) используется только для регистрации уже произошедших событий.
• non_personalized_ads - настройка персонализированный рекламы

Далее идет раздел с деталями события (Event details). В нем можно добавить параметры события и свойства пользователя. Для управления полями пользовательских данных (добавления и удаления) поставьте галочку рядом с show advanced options:

У передаваемых параметров должны быть указаны типы данных. В Event Builder доступно три типа данных:

1. string - строка;
2. number - число;
3. items - массив значений (товаров для электронной торговли).

Основные настройки разобраны. Самое время заполнить все поля согласно нашему примеру. Первая часть настроек выглядит так:

Поскольку я хочу передать специальное событие, то в поле event_category выбрано Custom. Идентификатор потока данных и секретный ключ API были скопированы из интерфейса Google Analytics 4, а название события mp_events придумано для этого примера. Свой уникальный идентификатор (client_id) я узнал с помощью консольной команды браузера document.cookie, которую ввел на вкладке Console. Его значение для Google Analytics хранится в куке _ga:

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

После заполнения всех данных вы можете переместиться вниз страницы и в отдельном блоке Validate & Send event увидеть, как выглядит ваш запрос в формате JSON. Для моего примера он выглядит так:

В Event Builder:

Перед отправкой запрос в Google Analytics 4 его следует проверить. Для этого нажмите на оранжевую кнопку Validate Event:

Если при заполнении полей была допущена ошибка, отобразится уведомление Event is invalid с указанием проблемного места:

Если все поля заполнены правильно, вы увидите сообщение Event is valid:

Теперь есть путей:

• SEND TO GA - отправить данные сразу же в Google Analytics;
• COPY PAYLOAD - скопировать тело запроса, чтобы прикрепить его к ТЗ для разработчиков;
• COPY SHARABLE LINK - скопировать ссылку на запрос с текущими настройками. Ее также можно передать программистам или прикрепить к техническому заданию.

Давайте отправим наш сформированный запрос. Нажав на оранжевую кнопку SEND TO GA, данные отправятся в Google Analytics, а название кнопки изменится на SENT.

Примечание: при получении http-запроса Measurement Protocol всегда показывает код статуса 2XX. Measurement Protocol не выводит код ошибки, если данные полезной нагрузки неверны, имеют некорректный формат или Google Analytics не удалось их обработать.

Проверка события в Google Analytics 4

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

Нажав на него, вы увидите все передаваемые параметры события:

Автоматизация

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

Как правило, это запуск собственного сервера, его настройка, создание скриптов загрузки и установка частоты их выполнения. То есть классическая задача разработчика, который должен взять на себя все эти процессы. Либо же используются готовые интеграции и сервисы типа Albato и ApiX-Drive, с настройкой которых справится любой интернет-маркетолог.

Итоги

Подводя итоги работы и отличия одной версии Measurement Protocol от другой (Universal Analytics - версия 1 и Google Analytics 4 - версия 2), стоит выделить следующее:

• в UA можно отправлять запросы как методом GET, так и POST, а в GA4 только POST;
• изменена конечная точка. В Universal Analytics используется адрес https://www.google-analytics.com/collect, а в Google Analytics 4 https://www.google-analytics.com/mp/collect
• в GA4 появился секретный ключ API, а в GA3 его нет;
• в Universal Analytics можно отправлять разные типы хитов (pageview, event, transaction, social и т.д.), а в Google Analytics 4 только события (events);
• в GA4 передаваемые данные должны быть отправлены в JSON формате;
• в GA4 события можно датировать задним числом (до трех дней) по часовому поясу ресурса благодаря параметру timestamp_micros. В UA тоже есть способ отправки хитов "в прошлое". Для этого используется параметр Время в очереди (&qt).

Дополнительную информацию о Measurement Protocol для Google Analytics 4 читайте в официальной документации разработчика.