Параметры measurement protocol
На днях Universal Analytics вышел из статуса беты и теперь становится основной версией Google Analytics. Это событие позволяет использовать его без ряда ограничений, существовавших ранее. Новая версия несет также ряд новых возможностей для отслеживания посетителей сайта и дает возможность сопоставить действия пользователя на сайте и последующее совершение целевых действие в оффлайне.
Для этих целей используется Measurement Protocol или Протокол передачи данных. В каких случаях вы можете использовать эту возможность? Приведу пару примеров.
Первый вариант — посетитель приобретает у вас на сайте товар или услугу, при этом выбирает вариант оплаты «безналичный расчет». Мы можем предположить, что процесс покупки по ряду причин может быть и не завершен, поэтому передача сведений в Google Analytics о транзакции после завершения процесса оформления заказа/покупки некорректна. Данные должны быть переданы после фактического поступления оплаты.
Второй вариант — оплата наличными курьеру при доставке товара. Покупка считается завершенной после получения оплаты курьером.
В обеих ситуациях, если мы будем передавать данные о покупке (транзакции) после завершения процесса оформления заказа, мы исказим статистику, т.к. у нас пока нет фактической оплаты. Для исправления ситуации с лишними учтенными платежами придется использовать отрицательные транзакции, что не всегда удобно и не совсем правильно.
Решить обозначенную проблему нам поможет новая возможность, появившаяся в Google Analytics с выходом Universal Analytics, под названием Mesurement Protocol.
Разберем подробнее параметры подлежащие передаче.
- 1. v — версия протокола, в настоящей момент используется значение равное 1;
- 2. tid — идентификатор кода отслеживания (ресурса) Google Analytics в виде UA-XXXX-Y;
- 3. cid — анонимный Client-ID;
- 4. t — тип хита.
Если первый и второй параметр не должны вызвать сложностей, то третий и четвертый требуют уточнений.
Параметр cid, это анонимный client-id или идентификатор клиента. Если посетитель просматривает ваш сайт с помощью браузера, Universal Analytics сохранит значение client-id в cookie, а если вам не известно значение, используйте любое свое.
Обратите внимание, если вы используете client-id, который получен из cookie файла, переданные данные будут сопоставлены с другими действиями посетителя, а если передаете свое значение, то будет просто зафиксирован некоторый хит нового посетителя (операции под одним client-id приписываются одному посетителю). Для иллюстрации сказанного посмотрите на изображение:
Просмотр страницы под номером 1 — это первое посещение сайта, просмотр 2 сгенерирован с помощью Mesurement Protocol по клику на кнопке (при этом использовался clid из cookie, установленного в посещении номер 1). У нас по отчету на сайте будет 1 посетитель.
Просмотр 3, как и просмотр 2, сгенерирован при клике на кнопку, при этом в качестве clid передано значение 12345, что приводит к появлению на сайте второго посетителя. У нас по отчету уже 2 посетителя. Просмотр 4 полностью аналогичен просмотру 2 (это действие посетителя номер 1, который ранее осуществил просмотры 1 и 2).
Вернемся к параметрам. Следующий параметр t (это тип хита). Он может принимать ограниченный круг значений — 'pageview', 'appview', 'event', 'transaction', 'item', 'social', 'exception', 'timing'.
Наиболее часто используемые значения:
pageview — просмотр страницы;
event — событие;
transaction — транзакция;
item — элемент транзакции.
Уже сейчас у вас есть возможность передачи в Universal Analytics данных с помощью Measurement Protocol. Но для того, чтобы нам получить в отчетах достоверную и полную информацию, необходимо выполнить еще два действия:
1. Получить client-id посетителя сайта и сохранить его в CRM вместе с данными о заказе (сопоставить активность пользователя на сайте и его оффлайн действия).
2. Дополнить запрос дополнительными параметрами, позволяющими работать нам с передаваемыми данными в отчетах.
Получить clien-id можно из cookie Universal Analytics:
Вы можете самостоятельно либо с помощью разработчиков получить нужное значение. Я в своей деятельности пользуюсь следующим кодом на языке PHP (автор Matt Clarke):
Что касается дополнительных параметров, их достаточно много, некоторые из них с описанием на русском языке вы найдете здесь, а полный список доступен в официальной документации Google Analytics.
- dh — доменное имя сайта;
- dp — адрес страницы относительно доменного имени сайта;
- dt — заголовок страницы;
- ec — категория события;
- ea — действие по событию;
- el — ярлык события;
- ti — идентификатор транзакции;
- ta — название филиала или магазина;
- tr — общая сумма транзакции;
- in — название товара;
- ip — стоимость товара;
- iv — категория товара.
Теперь, когда мы имеем все необходимое для использования Measurement Protocol (протокола передачи данных), можно попробовать на практике приобретенные знания. Мы с вами воспользуемся всеми типами хитов, которые были названы ранее. Я буду демонстрировать передачу данных, отправляя запросы с помощью JQuery.
Отправка данных о просмотре страницы:
Отправка данных о событии:
Отправка данных о покупке:
Обратите внимание, что для отправки данных о покупке необходимо сначала передать данные о транзакции, а затем о каждом товаре.
Как видите, сложного в использовании этого функционала Universal Analytics нет. Используйте его для сбора достоверных данных и оптимизации вашего бизнеса.
Для получения полной и официальной информации обратитесь к документации.
В заключении приведу пример ролика, который демонстрирует фиксацию событий и передачу сведений в Universal Analytics для датчика движения:
В этом документе рассматривается отправка обращений в Google Analytics с помощью протокола передачи статистических данных (Measurement Protocol).
Обзор
-
– подробные инструкции по форматированию запросов. – перечень всех параметров, принимаемых протоколом.
Обязательные значения
Ниже перечислены параметры, которые обязательно должны указываться при каждой отправке данных.
Каждая строка передаваемых данных должна содержать действительный тип обращения. У каждого типа обращения есть собственный набор обязательных полей. Вот как будет выглядеть строка передаваемых данных для просмотра главной страницы – /home :
В разделах ниже подробно описываются распространенные типы обращений.
Несколько обращений в одном запросе
Например, чтобы передать информацию о просмотре страниц "Главная", "О компании" и "Контакты", отправьте такой пакетированный запрос:
Ограничения для пакетированных запросов
Кроме стандартных ограничений Measurement Protocol, для пакетированных запросов действуют следующие правила:
- В одном запросе может быть указано не больше 20 обращений.
- Общий объем данных обращений не должен превышать 16 КБ.
- Для одного фрагмента данных это ограничение составляет 8 КБ.
Отправка различных типов обращений
Ниже вы найдете примеры отправки в Google Analytics некоторых распространенных типов обращений. Однако ваши возможности этим не ограничиваются – комбинируя различные параметры, вы можете создавать собственные наборы данных. Например, чтобы узнать, на какой странице произошло событие, отправьте параметр pagePath ( p ) вместе с параметрами отслеживания событий, как показано ниже.
Полный список всех параметров, которые можно передавать в Google Analytics, вы найдете в Справке по параметрам.
Отслеживание страниц
Просмотрите это обращение в инструменте Measurement Protocol Hit Builder.
Отслеживание событий
Просмотрите это обращение в инструменте Measurement Protocol Hit Builder.
Отслеживание расширенной электронной торговли
Важно! Параметры расширенной электронной торговли нужно отправлять в существующих обращениях (pageview, event), но не в обращениях электронной торговли ( transaction или item ).Вместо них следует использовать обращения расширенной электронной торговли. Если вы хотите перейти с обычной электронной торговли на расширенную, то у вас есть два варианта:
Использование нового ресурса
Создайте новый ресурс и отправляйте в него обращения расширенной электронной торговли.
Перевод существующего ресурса на расширенную электронную торговлю
Переведите все обращения обычной электронной торговли в формат расширенной. Это не повлияет на данные о транзакциях и товарах, полученные ранее с помощью обычной электронной торговли. Они будут доступны в тех же ресурсах и профилях, что и раньше.
Отслеживание показов
Просмотрите это обращение в инструменте Measurement Protocol Hit Builder.
Отслеживание действий
Просмотрите это обращение в инструменте Measurement Protocol Hit Builder.
Объединение показов и действий
Просмотрите это обращение в инструменте Measurement Protocol Hit Builder.
Отслеживание покупок
Просмотрите это обращение в инструменте Measurement Protocol Hit Builder.
Отслеживание возвратов
Если событие, с которым связан возврат, не является взаимодействием (т. е. не инициируется пользователем), рекомендуется создать событие типа "Не взаимодействие". Благодаря этому событие не будет влиять на такие показатели, как число отказов, продолжительность сеанса и т. д.
Просмотрите это обращение в инструменте Measurement Protocol Hit Builder.
Просмотрите это обращение в инструменте Measurement Protocol Hit Builder.
Отслеживание процесса оформления покупки
1. Отслеживание этапов оформления покупки
Просмотрите это обращение в инструменте Measurement Protocol Hit Builder.
2. Отслеживание вариантов оформления покупки
Просмотрите это обращение в инструменте Measurement Protocol Hit Builder.
Отслеживание внутренних рекламных кампаний
Показы внутренней рекламы
Просмотрите это обращение в инструменте Measurement Protocol Hit Builder.
Клики по внутренней рекламе
Просмотрите это обращение в инструменте Measurement Protocol Hit Builder.
Отслеживание электронной торговли
Для передачи данных электронной торговли отправьте одно обращение типа transaction , представляющее всю транзакцию, и по одному обращению типа item для каждого товара, входящего в транзакцию. Все обращения, относящиеся к одной покупке, будут определены по идентификатору транзакции – ti .
Обращение типа transaction
Просмотрите это обращение в инструменте Measurement Protocol Hit Builder.
Обращение типа item
Просмотрите это обращение в инструменте Measurement Protocol Hit Builder.
Социальные взаимодействия
Просмотрите это обращение в инструменте Measurement Protocol Hit Builder.
Отслеживание ошибок
Просмотрите это обращение в инструменте Measurement Protocol Hit Builder.
Отслеживание пользовательского времени
Просмотрите это обращение в инструменте Measurement Protocol Hit Builder.
Отслеживание приложений/экранов
Просмотрите это обращение в инструменте Measurement Protocol Hit Builder.
Использование прокси-сервера
Некоторые среды могут отправлять обращения в Google Analytics только опосредованно, например старые мобильные телефоны, не позволяющие запускать JavaScript или корпоративный интранет из-за брандмауэра. Обычно в таких случаях запросы посылаются на прокси-сервер, который затем отправляет обращения в Google Analytics с помощью протокола Measurement Protocol.
Чтобы получать данные об IP-адресе и агенте пользователя с клиентского устройства, а не прокси-сервера, вы можете указать оба эти значения в протоколе, и они будут использоваться вместо тех, которые Google Analytics обычно получает из заголовков запроса.
Просмотрите это обращение в инструменте Measurement Protocol Hit Builder.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
На Хабре уже есть один обзор Measurement Protocol, но так как есть ряд дополнений и наличие кейсов — решил написать полное руководство.
- Обязательные параметры
- Передача взаимодействия в GA
- Параметры cid, uid, ni
- Стандартный код отслеживания GA
- Интеграция с CRM
- Отслеживание транзакций
- Возврат или частичный возврат средств
- Оффлайн-точки продаж
- Открытие писем
Техническая сторона
Данные можно передавать POST- и GET-запросами.
Обязательные параметры
v — версия протокола на данный момент 1 (v=1).
tid — идентификатор вашего ресурса в GA.
cid — уникальный идентификатор пользователя (его либо проставляет в Cookie стандартный JS-код GA, либо нужно генерировать самостоятельно — ниже рассмотрим подробнее).
t — тип взаимодействия, например pageview/event (t=event).
То есть, запрос будет выглядеть так:
Т.к. мы выбрали тип взаимодействия Event, нужно добавить обязательные параметры, описывающие событие:
ec (event category) — категория события (ec=registration).
ea (event action) — действие события (ea=form).
Передача события в GA
Чтобы не возникло проблем с кешированием, рекомендуется последним параметром добавить z, c уникальным значением для каждого из запросов.
Параметры cid, uid, ni
По этим параметрам нередко встречаются вопросы, поэтому рассмотрим подробнее.
cid
cid — client id, уникальный идентификатор клиентского приложения пользователя (например, веб-браузера), cid хранится в cookie _ga для конкретного домена.
В cookie _ga хранится что-то похожее на: GA1.2.602320690.1474476467
В параметр cid нужно передавать всё, что расположено после второй точки. То есть в данном случае:
Кука _ga проставляется в момент, когда инициализируется Трекер гугл аналитики:
Параметр cid является обязательным для всех запросов в Measurement Protocol. Если у вас будет отложенная отправка событий в GA по MP — нужно сохранять cid пользователя на стороне бекенда.
А что, если cid нет
1) вы ранее не сохраняли cid пользователей
2) у пользователя отключены куки или какие-то расширения браузера блокируют исполнение скрипта google analytics.
Так как параметр cid обязательный для отправки данных в GA, то в таких случаях нужно на стороне бекенда генерировать cid.
Мы генерируем cid таким образом:
Чем грозит самостоятельная генерация cid
Отправляемые данные не свяжутся с пользователем на стороне Google Analytics.
Но вы получите целостную картину по количеству событий. Потому что, если бы вы с бекенда не отправили информацию по Measurement Protocol, она бы вообще прошла мимо статистики.
Уникальный идентификатор пользователя в вашей системе (например, на сайте). Параметр необходим для подключения функции User ID.
Это позволит вам создать отдельное представление со статистикой по всем залогиненным пользователям, где вы сможете отследить последовательность действий(просмотры, страниц, события, оплаты) по каждому из пользователей. Также будет доступен Cross Device отчет.
Данным параметром мы можем сообщить GA, что данное взаимодействие выполнил конкретный пользователь. Параметр может принимать любое строковое значение, но нельзя передавать информацию, которая раскрывает личность пользователя (например, email или фамилию, имя).
Мы подключили User ID для всех залогиненных пользователей. Но прокинули uid не только в базовый параметр, но и продублировали его в Custom Dimension 1 (это позволило использовать сегменты в представлении User ID).
В основном JS-коде GA это делается так:
Через Google Tag Manager это можно делать более элегантно, но это тема отдельной статьи.
Для отправки запросов с бекенда делается добавлением параметров:
Наличие параметра позволит не инициализировать новую сессию.
Если не использовать данный параметр, то при отложенных событиях, при отправке будет создаваться в GA новая сессия с пустыми параметрами (источник трафика уйдет в direct / none, устройства будут в (not set), география будет построена относительно IP вашего сервера). То есть, это будет сессия, которая не несет никакой ценности, накручивает счетчик статистики и ломает отчётность по источникам трафика.
Например, если это отложенное событие — изменение статуса сделки в CRM. Обычно оно происходит, когда у пользователя (который закреплен за этой сделкой) нет активной сессии на сайте. Поэтому без использования &ni=1 будет создаваться новая сессия.
В общем, для отложенных событий используйте &ni=1.
Measurement Protocol на практике
Стандартный код отслеживания GA
Даже самый стандартный JS код GA при исполнении использует Measurement Protocol. Давайте посмотрим, как это работает.
Query String Parameters
Ряд параметров, которые были отправлены в GA. Это стандартный Просмотр страницы. Описание каждого из параметров смотрите в официальной документации.
Интеграция с CRM
Мы столкнулись с ситуацией, что показатель Goal Conversion Rate не дает полноценную картину по качеству источников трафика.
Одна из целей на нашем сайте — Заявка на бесплатный вводный урок. Есть случаи, когда пользователь не понимает, о чём речь, но всё равно заполняет форму. Естественно, все заявки попадают в CRM и нагружают наш отдел продаж.
В GA любая успешно заполненная форма = конверсия, поэтому даже нецелевые заявки будут накручивать счётчик конверсий.
Чтобы более детально оценивать качество каждого из каналов трафика, мы решили ввести дополнительные параметры: Целевая заявка и Проведен вводный урок.
Эти оба параметра мы можем определить по статусу сделки в CRM.
Так как наша CRM при изменении статуса сделки умеет отправлять Webhook на наш сервер, мы настроили:
- Когда сделка переходит в статус Назначен вводный — отправляем событие ”Целевая заявка” (например, ec=Quality&ea=Good_lead)
- Когда сделка переходит в статус Проведен вводный — отправляем событие “Проведен вводный” (например, ec=Quality&ea=1Lesson_done)
Отслеживание транзакций
Мы решили считать не просто выставление счетов, а непосредственно факты поступления денег на счет системы приема платежей.
Довольно часто это отложенное событие: решили оплатить через банковский перевод или платежный терминал. Также в качестве примера может быть “Оплата наличными курьеру”.
Когда система приема платежей сообщила о поступлении средств, мы отправляем Транзакцию в Google Analytics:
Возврат или частичный возврат средств
Для более точной статистики в GA есть возможность оформлять возвраты(отмену транзакций).
Так как у нас это очень редкий кейс, мы это не автоматизировали.
Пример из официальной документации:
Больше информации по ссылке:
Оффлайн-точки продаж
Посещаемость
Существуют счетчики посетителей магазина (оффлайн) с возможностью отправки информации на веб. Используя Measurement Protocol, вы можете прокинуть эту информацию в Google Analytics. Отправляя Pageview в GA, сможете отслеживать как влияют ваши маркетинговые активности на посещаемость оффлайн-точек.
Транзакции
Все оплаты также можно отправлять в GA, причём тут уже можно использовать UserID.
В перспективе вы сможете сегментировать пользователей, которые совершают покупки в оффлайне, а которые — через интернет.
Маркетологи вам скажут Спасибо.
Открытие писем
Так как Measurement Protocol может работать через GET-запросы, то ничего не мешает добавить в рассылку картинку:
Параметры z, uid и cid подставлять в зависимости от пользователя, которому уходит письмо.
dp (Document Path) — чтобы было понятно, какое письмо было открыто.
Дополнительные ресурсы
Выводы
Measurement Protocol довольно мощный инструмент, который дает возможность автоматизировать выгрузку любых взаимодействий в Google Analytics, что поможем вам для аналитики в целом и станет большим бонусом для маркетинговых активностей.
Если вы тоже используется Measurement Protocol — пишите в комментарии свои кейсы!
Бонусы от EnglishDom для читателей Хабра
Онлайн-курсы
Мы дарим вам доступ на год к курсу английского для самостоятельного изучения «Онлайн курс».
Для получения доступа просто перейдите по ссылке.
Индивидуально по Скайпу
Специализированный курс «Английский для IT-специалистов»
Занятия проходят в любое удобное для вас время.
Промокод на 15% скидки: habra215
Действителен до 1 мая. Введите его при оплате или воспользуйтесь ссылкой.
На Хабре уже есть один обзор Measurement Protocol, но так как есть ряд дополнений и наличие кейсов — решил написать полное руководство.
- Обязательные параметры
- Передача взаимодействия в GA
- Параметры cid, uid, ni
- Стандартный код отслеживания GA
- Интеграция с CRM
- Отслеживание транзакций
- Возврат или частичный возврат средств
- Оффлайн-точки продаж
- Открытие писем
Техническая сторона
Данные можно передавать POST- и GET-запросами.
Обязательные параметры
v — версия протокола на данный момент 1 (v=1).
tid — идентификатор вашего ресурса в GA.
cid — уникальный идентификатор пользователя (его либо проставляет в Cookie стандартный JS-код GA, либо нужно генерировать самостоятельно — ниже рассмотрим подробнее).
t — тип взаимодействия, например pageview/event (t=event).
То есть, запрос будет выглядеть так:
Т.к. мы выбрали тип взаимодействия Event, нужно добавить обязательные параметры, описывающие событие:
ec (event category) — категория события (ec=registration).
ea (event action) — действие события (ea=form).
Передача события в GA
Чтобы не возникло проблем с кешированием, рекомендуется последним параметром добавить z, c уникальным значением для каждого из запросов.
Параметры cid, uid, ni
По этим параметрам нередко встречаются вопросы, поэтому рассмотрим подробнее.
cid
cid — client id, уникальный идентификатор клиентского приложения пользователя (например, веб-браузера), cid хранится в cookie _ga для конкретного домена.
В cookie _ga хранится что-то похожее на: GA1.2.602320690.1474476467
В параметр cid нужно передавать всё, что расположено после второй точки. То есть в данном случае:
Кука _ga проставляется в момент, когда инициализируется Трекер гугл аналитики:
Параметр cid является обязательным для всех запросов в Measurement Protocol. Если у вас будет отложенная отправка событий в GA по MP — нужно сохранять cid пользователя на стороне бекенда.
А что, если cid нет
1) вы ранее не сохраняли cid пользователей
2) у пользователя отключены куки или какие-то расширения браузера блокируют исполнение скрипта google analytics.
Так как параметр cid обязательный для отправки данных в GA, то в таких случаях нужно на стороне бекенда генерировать cid.
Мы генерируем cid таким образом:
Чем грозит самостоятельная генерация cid
Отправляемые данные не свяжутся с пользователем на стороне Google Analytics.
Но вы получите целостную картину по количеству событий. Потому что, если бы вы с бекенда не отправили информацию по Measurement Protocol, она бы вообще прошла мимо статистики.
Уникальный идентификатор пользователя в вашей системе (например, на сайте). Параметр необходим для подключения функции User ID.
Это позволит вам создать отдельное представление со статистикой по всем залогиненным пользователям, где вы сможете отследить последовательность действий(просмотры, страниц, события, оплаты) по каждому из пользователей. Также будет доступен Cross Device отчет.
Данным параметром мы можем сообщить GA, что данное взаимодействие выполнил конкретный пользователь. Параметр может принимать любое строковое значение, но нельзя передавать информацию, которая раскрывает личность пользователя (например, email или фамилию, имя).
Мы подключили User ID для всех залогиненных пользователей. Но прокинули uid не только в базовый параметр, но и продублировали его в Custom Dimension 1 (это позволило использовать сегменты в представлении User ID).
В основном JS-коде GA это делается так:
Через Google Tag Manager это можно делать более элегантно, но это тема отдельной статьи.
Для отправки запросов с бекенда делается добавлением параметров:
Наличие параметра позволит не инициализировать новую сессию.
Если не использовать данный параметр, то при отложенных событиях, при отправке будет создаваться в GA новая сессия с пустыми параметрами (источник трафика уйдет в direct / none, устройства будут в (not set), география будет построена относительно IP вашего сервера). То есть, это будет сессия, которая не несет никакой ценности, накручивает счетчик статистики и ломает отчётность по источникам трафика.
Например, если это отложенное событие — изменение статуса сделки в CRM. Обычно оно происходит, когда у пользователя (который закреплен за этой сделкой) нет активной сессии на сайте. Поэтому без использования &ni=1 будет создаваться новая сессия.
В общем, для отложенных событий используйте &ni=1.
Measurement Protocol на практике
Стандартный код отслеживания GA
Даже самый стандартный JS код GA при исполнении использует Measurement Protocol. Давайте посмотрим, как это работает.
Query String Parameters
Ряд параметров, которые были отправлены в GA. Это стандартный Просмотр страницы. Описание каждого из параметров смотрите в официальной документации.
Интеграция с CRM
Мы столкнулись с ситуацией, что показатель Goal Conversion Rate не дает полноценную картину по качеству источников трафика.
Одна из целей на нашем сайте — Заявка на бесплатный вводный урок. Есть случаи, когда пользователь не понимает, о чём речь, но всё равно заполняет форму. Естественно, все заявки попадают в CRM и нагружают наш отдел продаж.
В GA любая успешно заполненная форма = конверсия, поэтому даже нецелевые заявки будут накручивать счётчик конверсий.
Чтобы более детально оценивать качество каждого из каналов трафика, мы решили ввести дополнительные параметры: Целевая заявка и Проведен вводный урок.
Эти оба параметра мы можем определить по статусу сделки в CRM.
Так как наша CRM при изменении статуса сделки умеет отправлять Webhook на наш сервер, мы настроили:
- Когда сделка переходит в статус Назначен вводный — отправляем событие ”Целевая заявка” (например, ec=Quality&ea=Good_lead)
- Когда сделка переходит в статус Проведен вводный — отправляем событие “Проведен вводный” (например, ec=Quality&ea=1Lesson_done)
Отслеживание транзакций
Мы решили считать не просто выставление счетов, а непосредственно факты поступления денег на счет системы приема платежей.
Довольно часто это отложенное событие: решили оплатить через банковский перевод или платежный терминал. Также в качестве примера может быть “Оплата наличными курьеру”.
Когда система приема платежей сообщила о поступлении средств, мы отправляем Транзакцию в Google Analytics:
Возврат или частичный возврат средств
Для более точной статистики в GA есть возможность оформлять возвраты(отмену транзакций).
Так как у нас это очень редкий кейс, мы это не автоматизировали.
Пример из официальной документации:
Больше информации по ссылке:
Оффлайн-точки продаж
Посещаемость
Существуют счетчики посетителей магазина (оффлайн) с возможностью отправки информации на веб. Используя Measurement Protocol, вы можете прокинуть эту информацию в Google Analytics. Отправляя Pageview в GA, сможете отслеживать как влияют ваши маркетинговые активности на посещаемость оффлайн-точек.
Транзакции
Все оплаты также можно отправлять в GA, причём тут уже можно использовать UserID.
В перспективе вы сможете сегментировать пользователей, которые совершают покупки в оффлайне, а которые — через интернет.
Маркетологи вам скажут Спасибо.
Открытие писем
Так как Measurement Protocol может работать через GET-запросы, то ничего не мешает добавить в рассылку картинку:
Параметры z, uid и cid подставлять в зависимости от пользователя, которому уходит письмо.
dp (Document Path) — чтобы было понятно, какое письмо было открыто.
Дополнительные ресурсы
Выводы
Measurement Protocol довольно мощный инструмент, который дает возможность автоматизировать выгрузку любых взаимодействий в Google Analytics, что поможем вам для аналитики в целом и станет большим бонусом для маркетинговых активностей.
Если вы тоже используется Measurement Protocol — пишите в комментарии свои кейсы!
Бонусы от EnglishDom для читателей Хабра
Онлайн-курсы
Мы дарим вам доступ на год к курсу английского для самостоятельного изучения «Онлайн курс».
Для получения доступа просто перейдите по ссылке.
Индивидуально по Скайпу
Специализированный курс «Английский для IT-специалистов»
Занятия проходят в любое удобное для вас время.
Промокод на 15% скидки: habra215
Действителен до 1 мая. Введите его при оплате или воспользуйтесь ссылкой.
Читайте также: