...

вторник, 18 апреля 2017 г.

GA Measurement Protocol — полное руководство


На Хабре уже есть один обзор Measurement Protocol, но так как есть ряд дополнений и наличие кейсов — решил написать полное руководство.

Содержание

  • Техническая сторона
    • Обязательные параметры
    • Передача взаимодействия в GA
    • Параметры cid, uid, ni

  • Measurement Protocol на практике
    • Стандартный код отслеживания GA
    • Интеграция с CRM
    • Отслеживание транзакций
    • Возврат или частичный возврат средств
    • Оффлайн-точки продаж
    • Открытие писем

  • Дополнительные ресурсы
  • Выводы

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

Техническая сторона


Протокол работает по HTTP, имеет единую точку входа: http://ift.tt/1bgZ9jH

Данные можно передавать POST- и GET-запросами.

Обязательные параметры


v — версия протокола на данный момент 1 (v=1).
tid — идентификатор вашего ресурса в GA.
cid — уникальный идентификатор пользователя (его либо проставляет в Cookie стандартный JS-код GA, либо нужно генерировать самостоятельно — ниже рассмотрим подробнее).
t — тип взаимодействия, например pageview/event (t=event).

То есть, запрос будет выглядеть так:

v=1&tid=UA-123456-1&cid=1482535147.1490885188&t=event

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

ec (event category) — категория события (ec=registration).
ea (event action) — действие события (ea=form).

v=1&tid=UA-123456-1&cid=1482535147.1490885188&t=event&ec=registration&ea=form

Полный перечень параметров

Передача события в GA

Можно отправить запрос одним из методов:

POST

User-Agent: user_agent_string // http://ift.tt/2pOY26Z
POST /collect HTTP/1.1
Host: http://ift.tt/rzP4g5
v=1&tid=UA-123456-1&cid=1482535147.1490885188&t=event&ec=registration&ea=form

GET

Чтобы не возникло проблем с кешированием, рекомендуется последним параметром добавить z, c уникальным значением для каждого из запросов.

GET /collect?v=1&tid=UA-123456-1&cid=1482535147.1490885188&t=event&ec=registration&ea=form&z=12345 HTTP/1.1
Host: http://ift.tt/Ny4coo
User-Agent: user_agent_string

Сервис для проверки корректности отправляемых данных

Параметры cid, uid, ni


По этим параметрам нередко встречаются вопросы, поэтому рассмотрим подробнее.

cid
cid — client id, уникальный идентификатор клиентского приложения пользователя (например, веб-браузера), cid хранится в cookie _ga для конкретного домена.

В cookie _ga хранится что-то похожее на: GA1.2.602320690.1474476467

В параметр cid нужно передавать всё, что расположено после второй точки. То есть в данном случае:

&cid=602320690.1474476467

Кука _ga проставляется в момент, когда инициализируется Трекер гугл аналитики:
Параметр cid является обязательным для всех запросов в Measurement Protocol. Если у вас будет отложенная отправка событий в GA по MP — нужно сохранять cid пользователя на стороне бекенда.

А что, если cid нет

Примеры случаев:

1) вы ранее не сохраняли cid пользователей
2) у пользователя отключены куки или какие-то расширения браузера блокируют исполнение скрипта google analytics.

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

Мы генерируем cid таким образом:

$cookieId = rand(1000000000, 2147483647) . '.' . time();

Чем грозит самостоятельная генерация cid
Отправляемые данные не свяжутся с пользователем на стороне Google Analytics.

Но вы получите целостную картину по количеству событий. Потому что, если бы вы с бекенда не отправили информацию по Measurement Protocol, она бы вообще прошла мимо статистики.

uid

Уникальный идентификатор пользователя в вашей системе (например, на сайте). Параметр необходим для подключения функции User ID.

Это позволит вам создать отдельное представление со статистикой по всем залогиненным пользователям, где вы сможете отследить последовательность действий(просмотры, страниц, события, оплаты) по каждому из пользователей. Также будет доступен Cross Device отчет.

Подробнее о User ID: http://ift.tt/2pOJVOT

Данным параметром мы можем сообщить GA, что данное взаимодействие выполнил конкретный пользователь. Параметр может принимать любое строковое значение, но нельзя передавать информацию, которая раскрывает личность пользователя (например, email или фамилию, имя).

Мы подключили User ID для всех залогиненных пользователей. Но прокинули uid не только в базовый параметр, но и продублировали его в Custom Dimension 1 (это позволило использовать сегменты в представлении User ID).

В основном JS-коде GA это делается так:

ga('create', 'UA-XXXXX-Y', 'auto', {
  userId: USER_ID,
  'dimension1':  USER_ID
});
ga('send', 'pageview');

Через Google Tag Manager это можно делать более элегантно, но это тема отдельной статьи.

Для отправки запросов с бекенда делается добавлением параметров:

&uid=USER_ID&cd1=USER_ID

ni

Наличие параметра позволит не инициализировать новую сессию.

Если не использовать данный параметр, то при отложенных событиях, при отправке будет создаваться в GA новая сессия с пустыми параметрами (источник трафика уйдет в direct / none, устройства будут в (not set), география будет построена относительно IP вашего сервера). То есть, это будет сессия, которая не несет никакой ценности, накручивает счетчик статистики и ломает отчётность по источникам трафика.

Например, если это отложенное событие — изменение статуса сделки в CRM. Обычно оно происходит, когда у пользователя (который закреплен за этой сделкой) нет активной сессии на сайте. Поэтому без использования &ni=1 будет создаваться новая сессия.

В общем, для отложенных событий используйте &ni=1.

Measurement Protocol на практике


Стандартный код отслеживания GA


Даже самый стандартный JS код GA при исполнении использует Measurement Protocol. Давайте посмотрим, как это работает.
  1. Открываем окно Google Chrome с панелью Developer Tools (CTRL + Shift + I или F12).
  2. В адресную строку вводим habrahabr.ru.
  3. В панели для разработчиков нам интересна вкладка Network. Если вы сначала открыли панель для разработчиков, далее открыли сайт — в этой вкладке будет информация. Если другая последовательность, то вкладка будет пустая, нажмите F5, чтобы переоткрыть страницу.
  4. В строке Filter пишем http://ift.tt/1bgZ9jH
  5. Открываем подробности запроса.

Вы увидите похожую информацию:

Request URL:

http://ift.tt/2pvY7ji

Query String Parameters
v:1
_v:j50
a:643761009
t:pageview
_s:1
dl:https://habrahabr.ru/
ul:en-us
de:UTF-8
dt:Лучшие публикации за сутки / Хабрахабр
sd:24-bit
sr:1920x1080
vp:1109x966
je:0
fl:25.0 r0
_u:QCCAgEAB~
jid:1630561303
cid:774042187.1492148509
tid:UA-726094-1
cd1:guest
cd4:no
cd5:other
z:1998272259

Что мы тут видим?

Ряд параметров, которые были отправлены в GA. Это стандартный Просмотр страницы. Описание каждого из параметров смотрите в официальной документации.

Интеграция с CRM


Мы столкнулись с ситуацией, что показатель Goal Conversion Rate не дает полноценную картину по качеству источников трафика.

Одна из целей на нашем сайте — Заявка на бесплатный вводный урок. Есть случаи, когда пользователь не понимает, о чём речь, но всё равно заполняет форму. Естественно, все заявки попадают в CRM и нагружают наш отдел продаж.

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

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

Эти оба параметра мы можем определить по статусу сделки в CRM.

Так как наша CRM при изменении статуса сделки умеет отправлять Webhook на наш сервер, мы настроили:

  • Когда сделка переходит в статус Назначен вводный — отправляем событие ”Целевая заявка” (например, ec=Quality&ea=Good_lead)
  • Когда сделка переходит в статус Проведен вводный — отправляем событие “Проведен вводный” (например, ec=Quality&ea=1Lesson_done)

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

Отслеживание транзакций


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

Довольно часто это отложенное событие: решили оплатить через банковский перевод или платежный терминал. Также в качестве примера может быть “Оплата наличными курьеру”.

Когда система приема платежей сообщила о поступлении средств, мы отправляем Транзакцию в Google Analytics:

v=1&tid=UA-12345678-1&cid=455045511.1409504244&uid=12345&t=event&tr=225&pa=Transaction&ec=Oplata&ea=Individ&ev=225&ni=1&pr1id=12345_individual_id&pr1nm=Individ&pr1pr=225&pr1qt=1

Возврат или частичный возврат средств


Для более точной статистики в GA есть возможность оформлять возвраты(отмену транзакций).
Так как у нас это очень редкий кейс, мы это не автоматизировали.

Пример из официальной документации:

 // Refund an entire transaction and send with a non-interaction event.
v=1                                   // Version.
&tid=UA-XXXXX-Y                       // Tracking ID / Property ID.
&cid=555                              // Anonymous Client ID.
&t=event                              // Event hit type.
&ec=Ecommerce                         // Event Category. Required.
&ea=Refund                            // Event Action. Required.
&ni=1                                 // Non-interaction parameter.

&ti=T12345                            // Transaction ID. Required.
&pa=refund                            // Product action (refund). Required.

Больше информации по ссылке:

http://ift.tt/2pw7gsg

Оффлайн-точки продаж


Посещаемость
Существуют счетчики посетителей магазина (оффлайн) с возможностью отправки информации на веб. Используя Measurement Protocol, вы можете прокинуть эту информацию в Google Analytics. Отправляя Pageview в GA, сможете отслеживать как влияют ваши маркетинговые активности на посещаемость оффлайн-точек.

Транзакции
Все оплаты также можно отправлять в GA, причём тут уже можно использовать UserID.
В перспективе вы сможете сегментировать пользователей, которые совершают покупки в оффлайне, а которые — через интернет.
Маркетологи вам скажут Спасибо.

Открытие писем

Так как Measurement Protocol может работать через GET-запросы, то ничего не мешает добавить в рассылку картинку:



Параметры z, uid и cid подставлять в зависимости от пользователя, которому уходит письмо.
dp (Document Path) — чтобы было понятно, какое письмо было открыто.

Дополнительные ресурсы


Официальная документация
Подробное описание параметров
Сервис для проверки корректности отправляемых данных

Библиотеки:
PHP: http://ift.tt/2pw97xf
Python: http://ift.tt/2pw1W86
NodeJS: http://ift.tt/2pvZYER
Ruby: http://ift.tt/2pwbDmY

Выводы


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

Если вы тоже используется Measurement Protocol — пишите в комментарии свои кейсы!

Бонусы от EnglishDom для читателей Хабра


Онлайн-курсы
Мы дарим вам доступ на год к курсу английского для самостоятельного изучения «Онлайн курс».
Для получения доступа просто перейдите по ссылке.

Индивидуально по Скайпу
Специализированный курс «Английский для IT-специалистов»
Занятия проходят в любое удобное для вас время.
Промокод на 15% скидки: habra215
Действителен до 1 мая. Введите его при оплате или воспользуйтесь ссылкой.

Среди наших студентов уже есть ученики с Хабра, GeekBrains, ITVDN, GoIT, BrainBasket, Softengi, Нетологии. Присоединяйтесь!

Комментарии (0)

    Let's block ads! (Why?)

    Комментариев нет:

    Отправить комментарий