Universal Analytics: веб-аналитика нового поколения и ее возможности для e-commerce

Universal Analytics – новая версия системы веб-аналитики Google Analytics, которую сейчас "обкатывает" Google. Если вам интересно, что представляет собой обновление Google Analytics и что полезного для e-commerce появилось в новой системе, то вам сюда. Один из первых русскоязычных кейсов по Universal Analytics для нас любезно подготовил гендиректор консалтингового агентства WebProfiters – Александр Кузьмин.

Занимаясь сбором информации для этой статьи, я потратил немало времени на то, чтобы найти что-то полезное (под полезным я подразумеваю кейсы по использованию Universal Analytics ). Однако оказалось, что найти практические советы в Интернете (как западном, так и нашем) не так-то просто.

А ведь прошло уже почти полгода с момента выхода Universal Analytics в режиме Beta (система продолжает работать в данном режиме и сейчас, но для Google долгий период тестирования – это обычная ситуация). Возникает закономерный вопрос "почему?". Неужели компании не видят смысла в том, чтобы сейчас инвестировать в переход с Google Analytics на Universal Analytics?(Несмотря на "бесплатность" системы, инвестировать все же придется, так как все настройки, которые вы имплементировали в предыдущую версию, в новую автоматически не перенесутся) Забегая немного вперед, выражу свое мнение: во многих случаях это стоит сделать.

Что нового появилось в Universal Analytics?

Принципы работы Universal Analytics отличаются от принципов работы предыдущей версии системы. И в то же время интерфейс Universal Analytics покажется вам очень знакомым. Он почти идентичен интерфейсу Google Analytics . То есть Universal Analytics – это не новая система веб-аналитики, это давно назревавшее обновление подхода работы с данными в Google Analytics.

Первое, что изменилось– это процесс сбора данных. В Google Analytics для сбора информации о посетителях использовались 5 разных cookies. Каждая из них содержала информацию о посетителе: ключевое слово, источник трафика, название кампании, номер страницы в сессии на сайте и некоторые другие показатели. Всякий раз, когда посетитель переходил на страницу вашего сайта, код отслеживания Google Analytics считывал этот огромный массив информации из cookies и передавал ее на сервер сбора данных.

В Universal Analytics несколько другой подход к выполнению той же самой задачи. В браузере посетителя сохраняется только одна cookie, которая содержит в себе один-единственный уникальный идентификационный номер посетителя сайта (Client ID). Обновленный код отслеживания считывает эту Cookie и передает на сервера Google не весь огромный массив показателей, который я перечислил выше, а только уникальный номер посетителя. В чем разница? На серверы Universal Analytics передается гораздо меньший объем данных. Далее Google уже на своих серверах подсчитывает, какая эта по счету страница в пользовательской сессии, был ли посетитель на сайте раньше, присвоена ли этому посетителю какая-нибудь пользовательская переменная или нет и так далее. По заверениям Google, полный переход на Universal Analytics позволит на 5% увеличить среднюю скорость работы мирового Интернета (учитывая тот факт, что на 80% всех сайтов в мире установлен Google Analytics).

Доступ к уникальному ID посетителя можно получить стандартными JS-методами, любезно предоставленными Google. И далее Google дает обширные возможности для его использования.

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

Более того, благодаря новому протоколу измерения и передачи данных (new measurement protocol), становится возможным не только перезаписывать Client ID, но и генерировать для него различные типы хитов, которые потом передаются с любых устройств, имеющих доступ в Интернет и способных отправить стандартный HTTP-запрос.

Зачем это нужно в e-commerce?

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

Еще одна очень важная новая функция– это создание собственных параметров и метрик. Источник трафика, браузер, разрешение экрана – всё это примеры стандартных параметров, которые сейчас доступны в Google Anaytics. Показатель отказов, коэффициент конверсии – это примеры предустановленных метрик.

Представим, что вы, например, храните в вашей CRM-системе информацию о гендерной принадлежности (М или Ж) каждого клиента. Вас может заинтересовать коэффициент конверсии в покупки или регистрации для представителей каждого пола. Эта информация важна для оптимизации сайта и рекламных кампаний. Чтобы ее получить, вам достаточно создать в Universal Analytics новый параметр – пол, а далее научить вашу CRM-систему генерировать хит, содержащий в себе информацию о новом показателе.

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

Далее я приведу практический пример использования новых возможностей Universal Analytics. В нашей компании (как, скорее всего, и в большинстве других компаний, использующих платные каналы привлечения посетителей на сайт), до этого момента не существовало инструмента, позволяющего удобно, в автоматическом или полуавтоматическом режиме сегментировать, пожалуй, самую важную метрику – объем продаж – по множеству интересных бизнесу показателей. Да, в Google Analytics существовал и существует отчет по электронной торговле. Но данные в этот отчет передавались в момент оформления заказа на сайте, а не в момент поступления денег на счет компании. Безусловно, это несколько искажает реальные результаты деятельности компании в Интернете.

Опишу, как как мы решили эту задачу у себя – средствами Universal Analytics .

Шаг 1. Установка и настройка Universal Analytics и Google Tag Manager

Несмотря на то, что статья не об этом, я не могу не написать пару слов про Google Tag Manager, так как при решении задачи мы использовали данной инструмент, а некоторые читатели данной статьи могли о нем не слышать.

Диспетчер тегов Google позволяет управлять тегами, предназначенными для отслеживания или оптимизации маркетинга на сайте. Допустим, сейчас на ваш сайт подключен к Google Analytics, вы размещаете объявления в Google Adwords, и иногда используете эксперименты Google Analytics для a/b-тестирования разных вариантов страниц сайта. Итак, на вашем сайте работают 3 разных кода отслеживания. Добавьте сюда еще возможной переход на Universal Analytics, а также коды событий (events) и электронной торговли, – и у вас получится длинный список тегов, разбросанных по вашему сайту.

Работа Диспетчера тегов Google основана на использовании одного тега – так называемого контейнера, который размещается на всех страницах сайта вместо отдельных тегов AdWords, Google Analytics, Floodlight и прочих. После того как вы разместите на сайте фрагмент контейнера, добавление, обновление и управление тэгами будет идти через один веб-интерфейс – Диспетчера тегов Google.

Кроме этого, Google Tag Manager позволяет снизить риск недобросовестного использования вашего уникального номера аккаунта, например, вашими конкурентами. Если на сайте установлен "голый" код Universal Analytics, любой желающий может отправить вам хит с информацией о произошедшей транзакции, зная идентификационный номер вашего аккаунта Universal Analytics (UA-XXX-YY), что испортит вашу статистику и может создать неверное представление о результатах деятельности вашей компании.

Итак, для решения нашей задачи, первым делом устанавливаем Google Tag Manager.

Для этого переходим на сайт Google Tag Manager (далее – GTM) и регистрируем новый аккаунт.

В поля Account name и Container name вводим адрес сайта (или название домена). Нажимаем кнопку Create account. Далее GTM предложит вам специальный код, который нужно разместить на всех страницах вашего сайта непосредственно после тега .

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

В настройках нового веб-ресурса выбираем метод отслеживания – Universal Analytics, вводим название и адрес сайта, а также TimeZone.

Нажимаем кнопку "Получить идентификатор отслеживания" – и сервис перенаправляет нас на страницу с кодом UA, который нам рекомендуют разместить (так же, как и код контейнера GTM) сразу после тега body.

Далее возвращаемся на сайт GTM для того, чтобы в ранее созданный нами контейнер добавить новый тег с кодом UA. Для этого жмем на кнопку New Tag.

Указываем название тега (например, Universal Analytics Code), выбираем из предложенного списка тип создаваемого тега (Tag Type) и после этого в соответствующее поле (Tracking Id) вносим идентификатор вашего аккаунта.

Дальше необходимо указать правило (Add Rule to Fire Tag), при котором код UA будет срабатывать. Выбираем опцию All Pages (нам необходимо, чтобы код отслеживания UA выполнялся на всех страницах сайта).

Больше никаких изменений на данной странице вносить не нужно – жмем кнопку Save.

Для того чтобы внесенные в контейнер GTM изменения вступили в силу (и код UA начал выполняться), надо нажать кнопку Create Version.

И далее – кнопку Publish.

Код UA успешно внесен в контейнер GTM на вашем сайте.

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

Шаг 2. Интеграция Universal Analytics с CRM-системой

Дальше нужно "связать" Universal Analytics с вашей CRM. Расскажу, как мы решали эту задачу. Мы пользуемся достаточно популярной облачной CRM-системой HighRise (37signals.com). Как уже говорилось, основная задача, которую требуется решить с помощью UA, – это корректная передача данных о доходах компании внутрь интерфейса UA для дальнейшего подсчета ROI рекламных (и не рекламных) каналов, а также сегментирования этой метрики по разным параметрам.

Основной объект в нашей CRM– это контактное лицо (представитель) компании, с которой ведутся переговоры о сотрудничестве.

Для каждого контактного лица создаются и хранятся типы сделок (deals), которые предстоит осуществить (или уже были осуществлены):

У каждой сделки есть 3 статуса: Lost (сделка проиграна, оплаты не будет), Pending (сделка в процессе обсуждения), Win (сделка состоялась, на счет организации поступила оплата).

Итак, задачу можно переформулировать следующим образом:

Когда статус сделки в CRM меняется с Pending на Win, необходимо передавать в Universal Analytics информацию о сумме сделки в привязке к тому посетителю, который оставил заявку (заказ) на сайте.

Задача решается в 2 этапа:

1. При занесении нового контактного лица в HighRise, необходимо в отдельном поле сохранять его уникальный Client ID.
   

2. Когда статус сделки меняется с Pending на Win необходимо генерировать хит, который будет передавать информацию о сделке в UA, при этом корректно аттрибутируя объем сделки соответствующему посетителю.

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

ga(function(tracker) {

var clientId = tracker.get(`clientId`);

});

Переменной Clientid будет присвоен уникальный номер посетителя сайта. Вызывая данный метод в тот момент, когда посетитель заполняет форму заявки, мы получаем возможность сохранить ClientId посетителя в одно из доступных для нового контактного лица полей (например, для этих нужд можно использовать всегда свободное поле "Факс").

Итак, мы занесли в CRM уникальный идентификационный номер посетителя, который в UA будет привязан к параметрам "Источник трафика", "Город", "Рекламная кампания" и другим.

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

Пример http-запроса:

http://www.google-analytics.com/collect?v=1&tid=UA-xxxx&cid=555&otherparameters

v: версия (всегда по умолчанию равно 1);

tid: идентификационный номер веб-ресурса UA;

cid: идентификационный номер пользователя.

При использовании своей собственной server based CRM-системы можно было бы просто доработать CRM так, чтобы при изменении статуса сделки с Pending на Win отправлялся HTTP запрос с нужными нам параметрами.

Наша компания, как и многие бизнесы, использует web based CRM. Менять код такой системы,мы не можем. Задача, однако, при этом не сильно усложняется. Ведь у нас есть возможность использовать богатые возможности API HighRise. Нужно написать небольшой скрипт, который выделяет все последние "выигранные" (win) сделки и передает информацию по ним в Universal Analytics.

Казалось бы, вот и решение задачи. Однако в этом момент мы вспоминаем, что в UA (как и в Google Analytics) нет метрики, позволяющий собирать в одном месте информацию о доходах. Тут нам на помощь приходит еще одно полезное нововведение в Universal Analytics – возможность создавать собственные параметры и метрики (нас в данном случае интересуют метрики).

Возвращаемся на сайт Google Analytics, выбираем из списка аккаунтов и ресурсов созданный нами ранее веб-ресурс Universal Analytics и нажимаем кнопку Администратор в правом верхнем углу. Далее переходим на вкладку Пользовательские определения, далее – Пользовательские показатели.

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

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

Нажимаем кнопку Создать отчет и получаем на выходе следующую таблицу.

Итак, мы создали пользовательскую метрику и простой пользовательский отчет, в который далее можно передавать данные о сделках.

Процесс написания скрипта и его код я описывать не буду, так как статья не об HighRise API, а перейду к формату HTTP-запроса. HTTP-запрос выглядит следующим образом:

http://www.google-analytics.com/collect?v=1&tid=UA-XXXX-YYY&cid=1161411544.1373152807&t=event&ec=transaction&ea=Xenia&cm1=500000,

где

v=1 – версия (всегда по умолчанию равно 1);

tid= UA-XXXX-YYY – идентификатор аккаунта Universal Analytics:

cid=1161411544.1373152807 – Client ID посетителя;

t=event – тип хита, который мы передаем (для передачи данных по пользовательским показателям и метрикам, лучше использовать или события (event), или транзакции (transaction). Полный список возможных для передачи параметров доступен тут;

eс=transaction – категория события;

ea=Xenia – действие по событию (в данном случае можно использовать имя клиента, перечислившего вам деньги);

cm1=500000 – объем сделки (в заданной в настройках профиля валюте).

Возвращаемся в созданный нами пользовательский отчет, чтобы проверить, что данные о совершенных транзакциях начали передаваться из CRM-системы:

Задача решена.

Надеюсь, материал будет вам полезен! Всем хорошей аналитики и высоких ROI. Ждите новых кейсов.

С уважением, Александр Кузьмин, генеральный директор консалтингового агентства WebProfiters.