Принципы работы Universal Analytics отличаются от принципов работы предыдущей версии системы. Если вам интересно, что представляет из себя обновление Google Analytics и что полезного появилось в данной системе, вы наткнулись на нужную статью.
Занимаясь сбором информации при подготовке данной статьи, я потратил немало времени на то, чтобы найти что-то полезное (под полезным я подразумеваю кейсы использования данной системы), однако, оказалось, что найти практические советы в интернете (как западном, так и нашем) не так уж и просто – их просто нет (за редким исключением).
Так как прошло уже почти полгода с момента выхода Universal Analytics в режиме Beta (система продолжает работать в данном режиме и сейчас, но для Google долгий период тестирования – это обычная ситуация), возникает закономерный вопрос «почему?». Неужели компании не видят смысла в том, чтобы сейчас инвестировать (несмотря на «бесплатность» системы, инвестировать все же придется, так как все настройки, которые вы имплементировали в предыдущую версию, в новую автоматически не перенесутся) в процесс перехода с Google Analytics на Universal Analytics? Забегая немного вперед, выражу свое мнение: во многих случаях стоит.
Что же нового появилось в UniversalAnalytics?
Будет правильно обозначить в самом начале, что пользовательский интерфейс Universal 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 представит обширные возможности для его использования.
Имея доступ к уникальному ID посетителя, становится возможным кросс-платформенное отслеживание одного и того же посетителя. Если раньше, посетитель, переходя на сайт сначала с домашнего компьютера, а потом, например, с мобильного устройства был по факту для нас сразу двумя посетителями, то сейчас у нас появляется возможность в тот момент, когда посетитель авторизуется на сайте, сообщить системе аналитики, что на сайт вернулся тот же самый посетитель и привязать всю информацию о втором посещении к тому же самому посетителю (читай, переписать его единственную Coookie).
Более того, благодаря новому протоколу измерения и передачи данных (newmeasurementprotocol), становится возможным не только перезаписывать Client ID, но и самостоятельно генерировать различные типы хитов, которые потом передаются с любых устройств имеющих доступ в интернет и способных отправить стандартный HTTP-запрос.
Приведу пример использования такой технологии: посетитель переходит на сайт интернет-магазина, оформляет покупку через корзину и выбирает способ доставки – самовывоз, а способ оплаты – оплата при получении товара. Находясь в «стадии Google Analytics» у вас не было бы возможности в момент получения денег передать на сервер Google, что посетитель, которой несколько дней назад сделал заказ на сайте, все-таки забрал его из пункта самовывоза и оплатил наличными. А сейчас такая возможность есть: вам достаточно сделать так, чтобы одно из ваших устройств, использующихся для оформления покупки в пункте самовывоза (например, сканер штрихкода), генерировало несложный HTTP-запрос, передающий информацию о совершенной сделке прямиком на сервера Google, присваивая этот хит тому самому посетителю, который несколько дней назад оформил покупку.
Еще одно новая функция из списка самых важных функций – это создание собственных параметров и метрик. Источник трафика, браузер, разрешение экрана – всё это примеры стандартных параметров, которые сейчас доступны в Google Anaytics. Показатель отказов, коэффициент конверсии – все это примеры предустановленных метрик.
Представим, что вы, например, храните в вашей CRM-системе пол (М или Ж) каждого клиента. Вас может заинтересовать возможность узнать коэффициент конверсии в покупки или регистрации представителей каждого пола. Эта информация может оказаться полезной для оптимизации сайта и рекламных кампаний. Для этого Вам достаточно создать в Google Analytics новый параметр – пол, а далее научить Вашу CRM-систему генерировать хит, содержащий в себе информацию о новом показателе, созданном внутри Universal Analytics.
Стоит еще, пожалуй, упомянуть про миграцию некоторых базовых настроек системы, которые раньше «жили» в обители разработчиков и требовали изменений кода отслеживания, а теперь существуют непосредственно внутри интерфейса Universal Analytics и их настройка доступна там же. К ним относятся время жизни сессии и кампании, аттрибуция ключевых запросов, содержавших в себе название бренда, к прямому трафику, исключения переходов с определенных доменов из трафика переходов и некоторые другие.
Далее, на мой, взгляд, было бы правильным привести пример использования новых возможностей Universal Analytics. В нашей компании, как и, мне кажется, в большинстве других компаний, использующих платные каналы привлечения посетителей на сайт, не существовало до сего момента инструмента, позволяющего удобно и в автоматическом или полуавтоматическом режиме сегментировать, пожалуй, самую важную для бизнеса метрику, объем продаж, по множеству интересных бизнесу показателей. Понятное дело, что в Google Analytics существовал и существует отчет по электронной торговле, но данные в этот отчет при этом возможно было передавать только в момент оформления заказа на сайте, а не в момент поступления денег на счет компании, что, безусловно, несколько искажало реальные результаты деятельности компании в интернете. Далее описание того, как мы решили эту задачу у себя.
Шаг 1. Установка и настройка UniversalAnalytics и GoogleTagManager
Несмотря на то, что статья не об этом, я не могу не написать пару вступительных слов про Google Tag Manager, так как при решении задачи мы использовали данной инструмент, а некоторые читатели данной статьи могли о нем не слышать.
Диспетчер тегов Google позволяет легко управлять тегами (предназначенными для отслеживания или оптимизации маркетинга) на сайте. Чтобы понять предназначение Google Tag Manager, приведу такой пример: допустим, сейчас на вашем сайте используется Google Analytics, используется Google Adwords для привлечения посетителей, и, нарпимер, используются эксперименты Google для проведения 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 www.google.com/tagmanager/ (далее – GTM) и регистрируем новый аккаунт:
В поля Account name и Container name вводим адрес сайта (или название домена). Нажимаем кнопку Create account. Далее GTM предложит Вам специальный код, который необходимо расположить на всех страницах вашего сайта непосредственно после тега
.
После того, как предложенный GTM код размещен в нужном месте на всех страницах вашего сайта, переходим на сайт Google Analytics, авторизуемся под своим существующим логином и паролем от Google аккаунта (в котором в данный момент отслеживается посещаемость вашего сайта) и создаем новый веб-ресурс специально под Universal Analytics (далее – UA):
В настройках нового веб-ресурса выбираем метод отслеживания – Universal Analytics, вводим название и адрес сайта, а также TimeZone:
Нажимаем кнопку «Получить идентификатор отслеживания» и сервис перенаправляет нас на страницу с кодом UA, который нам рекомендуют разместить также как и код контейнера GTM сразу после тега
:
Далее возвращаемся на сайт 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].
Шаг 2. Интеграция UniversalAnalytics с CRM-системой
Для управления взаимоотношениями с клиентами в WebProfiters используется CRM-система HighRise (37signals.com). Как уже говорилось в начале статьи, основная задача, которую требуется решить с помощью UA – это корректная передача данных о доходах компании внутрь интерфейса UA для дальнейшего подсчета ROI рекламных (и не рекламных) каналов, а также сегментирования этой метрики по различным предустановленным параметрам.
Так выглядит стартовое окно системы HighRise:
Основной объект в данной системе – это контактное лицо (представитель) компании, с которой ведутся переговоры о сотрудничестве.
Новые контактные лица в HighRise создаются автоматически (с использованием API HighRise) при заполнении одной из контактных форм на сайте WebProfiters.ru:
Далее для каждого контактного лица консультанты WebProfiters уже вручную указывают тип, а также дедлайн задачи, которую необходимо выполнить.
Если опуститься на уровень ниже, то можно увидеть, что для каждого контактного лица создаются и хранятся типы сделок (deals), которые предстоит осуществить (или уже были осуществлены):
У каждой сделки есть 3 статуса: Lost (сделка проиграна, оплаты не будет), Pending (сделка в процессе обсуждения), Win (сделка состоялась, на счет организации поступила оплата).
Учитывая всю перечисленную выше информацию об особенностях CRM системы HighRise, основную задачу можно переформулировать следующим образом:
Когда статус сделки меняется с Pending на Win, в UA необходимо передавать информацию о сумме сделки в привязке к тому посетителю, который оставил заявку на сайте.
Данная задача реализуется в 2 этапа:
- При занесении нового контактного лица в HighRise, необходимо в отдельное поле сохранять его уникальный Client ID
- Когда статус сделки меняется с Pending на Win необходимо генерировать хит, который будет передавать информацию об объеме сделке внутрь UA, при этом корректно аттрибутируя объем сделки соответствующему посетителю.
Первый этап реализуется относительно просто. В справке для разработчиков UA приводится JS-код, который позволяет определить уникальный идентификационный номер посетителя, который находится на сайте. Выглядит он следующим образом:
ga(function(tracker) {
var clientId = tracker.get('clientId');
});
Переменной Clientid будет присвоен уникальный номер посетителя сайта. Вызывая данный метод в тот момент, когда посетитель заполняет форму заявки на услугу, находясь на сайте webprofiters.ru, появляется возможность сохранить ClientId посетителя в одно из доступных для нового контактного лица полей (например, для этих нужд можно использовать всегда свободное поле «Факс»).
Таким образом, мы заносим в свою CRM систему уникальный идентификационный номер посетителя, который в UA привязан к параметрам «Источник трафика», «Город», «Рекламная кампания» и другим.
Переходим ко второму шагу. Как я уже упоминал в начале статьи, одно из основных нововведений в UA (и одновременно отличий от Google Analytics) – это возможность передавать хиты внутрь UA, используя обычные HTTP-запросы. То есть, по сути, любое устройство, имеющее доступ в интернет, может передать информацию внутрь системы UA.
Пример 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 – ClientID посетителя
t=event – тип хита, который мы передаем (для передачи данных по пользовательским показателям и метрикам, лучше использовать или события (event), или транзакции (transaction). Полный список возможных для передачи параметров доступен тут
eс=transaction – категория события
ea=Xenia - действие по событию (в данном случае можно использовать имя человека или название компании, перечислившей деньги)
cm1=500000 – объем сделки (в заданной в настройках профиля валюте)
Возвращаемся в созданный нами пользовательский отчет, чтобы проверить, что данные о совершенных транзакциях начали передавать из CRM-системы:
Задача решенаJ
Надеюсь, материал будет вам полезен!
Всем хорошей аналитики и высоких ROI.
Ждите новых кейсовJ
Сноски
1) При создании нового веб-ресурса автоматически создается 1 профиль по умолчанию, в который передается вся статистика посещений сайта. Об структуре данных, отличии профилей от веб-ресурсов и аккаунтов читайте в справке Google Analytics
Орфография и пунктуация в данном тексте сохранены в том виде, в котором они были предложены автором.
