Universal analytics – веб-аналитика нового поколения

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

Занимаясь сбором информации при подготовке данной статьи, я израсходовал много времени на то, дабы отыскать что-то нужное (под нужным я подразумеваю кейсы применения данной совокупности), но, оказалось, что отыскать практические рекомендации в сети (как западном, так и отечественном) не так уж и просто – их нет (за редким исключением). Так как прошло уже практически полгода с момента выхода Universal Analytics в режиме Beta (совокупность работаетв данном режиме и по сей день, но для Гугл продолжительный период тестирования – это простая обстановка), появляется закономерный вопрос «из-за чего?».

Неужто компании не видят смысла в том, дабы на данный момент инвестировать (не обращая внимания на «бесплатность» совокупности, инвестировать все же придется, поскольку все настройки, каковые вы имплементировали в прошлую версию, в новую машинально не перенесутся) в процесс перехода с Гугл Analytics на Universal Analytics? Забегая мало вперед, выражу собственный вывод: во многих случаях стоит.

Что же нового показалось в Universal Analytics?

Будет верно обозначить в начале, что интерфейс пользователя Universal Analytics фактически аналогичен интерфейсу прошлой версии. Другими словами Universal Analytics – это не новая совокупность веб-аналитики, это прежде всего в далеком прошлом назревавшее обновление подхода работы с данными в Гугл Analytics.

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

В Universal Analytics пара второй подход к исполнению той же самой задачи. В браузере визитёра сохраняется лишь одна Cookie, которая содержит в себе практически один единственный неповторимый идентификационный номер визитёра сайта (client ID). Обновленный код отслеживания считывает эту Cookie и передает на сервера Google далеко не весь громадный массив показателей, перечисленный в прошлом абзаце, а лишь неповторимый номер визитёра, что данный хит совершил. В чем отличие?

На серверы Universal Analytics передается намного меньший количество данных. Потом Гугл уже на собственных серверах подсчитывает, какая эта по счету страница в пользовательской сессии, был ли визитёр на сайте раньше, присвоена ли этому визитёру какая-нибудь пользовательская переменная либо нет и без того потом. По заверениям Гугл полный переход на Universal Analytics разрешит на 5% расширить среднюю скорость работы мирового интернета (принимая к сведенью тот факт, что на 80% всех сайтов в мире установлен Гугл Analytics).

Имея в руках неповторимый ID визитёра (доступ к нему вероятно взять стандартными JS-способами, любезно предоставленными Гугл) логичным было бы высказать предположение, что Гугл представит широкие возможности для его применения.

Имея доступ к неповторимому ID визитёра, делается вероятным кросс-платформенное отслеживание одного и того же визитёра. В случае если раньше, визитёр, переходя на сайт сперва с домашнего компьютера, а позже, к примеру, с мобильного устройства был по факту для нас сходу двумя визитёрами, то на данный момент у нас появляется возможность в тот момент, в то время, когда визитёр авторизуется на сайте, сказать совокупности аналитики, что на сайт возвратился тот же самый визитёр и привязать все данные о втором посещении к тому же самому визитёру (просматривай, переписать его единственную Coookie).

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

Приведу пример применения таковой технологии: визитёр переходит на сайт вебмагазина, оформляет приобретение через корзину и выбирает метод доставки – самовывоз, а метод оплаты – оплата при получении товара. Пребывав в «стадии Гугл Analytics» у вас не было бы возможности в момент получения денег передать на сервер Гугл, что визитёр, которой недавно сделал заказ на сайте, все-таки забрал его из пункта самовывоза и оплатил наличными. А на данный момент такая возможность имеется: вам достаточно сделать так, дабы одно из ваших устройств, употребляющихся для оформления приобретения в пункте самовывоза (к примеру, сканер штрихкода), генерировало несложный HTTP-запрос, передающий данные о идеальной сделке прямиком на сервера Гугл, присваивая данный хит тому самому визитёру, что недавно оформил приобретение.

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

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

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

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

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

Понятное дело, что в Гугл Analytics существовал и существует отчет по электронной торговле, но данные в данный отчет наряду с этим вероятно было передавать лишь в момент оформления заказа на сайте, а не в момент поступления денег на счет компании, что, непременно, пара искажало настоящие результаты деятельности компании в сети. Потом описание того, как мы решили эту задачу у себя.

Ход 1. настройка и Установка Universal Analytics и Гугл Tag Manager

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

Диспетчер тегов Гугл позволяет без проблем руководить тегами (предназначенными для отслеживания либо оптимизации маркетинга) на сайте. Чтобы выяснить назначение Гугл Tag Manager, приведу таковой пример: допустим, на данный момент на вашем сайте употребляется Гугл Analytics, употребляется Гугл Adwords для привлечения визитёров, и, нарпимер, употребляются опыты Гугл с целью проведения a|b-тестов на страницах сайта, то практически это указывает наличие 3-х различных типов кодов отслеживания на сайте. Добавьте ко мне еще вероятной переход на Universal Analytics, и коды событий (events) и электронной торговли, и у вас окажется долгий перечень тегов, разбросанных по вашему сайту.

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

Также, Гугл Tag Manager разрешает снизить риск недобросовестного применения вашего неповторимого номера аккаунта, к примеру, вашими соперниками. В случае если на сайте установлен «обнажённый» код Universal Analytics, кто угодно может послать в вашу статистику хит с информацией о случившейся транзакции, зная идентификационный номер вашего аккаунта Universal Analytics (UA-XXX-YY), что сломает вашу статистику и может создать неверное представление о итогах деятельности вашей компании.

Итак, для ответа отечественной задачи, в первую очередь устанавливаем Гугл Tag Manager.

Переходим на сайт Гугл Tag Manager www.гугл.com/tagmanager/ (потом – GTM) и регистрируем новый аккаунт:

Universal analytics – веб-аналитика нового поколения

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

.

По окончании того, как предложенный GTM код размещен в нужном месте на всех страницах вашего сайта, переходим на сайт Гугл Analytics, авторизуемся под своим паролем и существующим логином от Гугл аккаунта (в котором сейчас отслеживается посещаемость вашего сайта) и создаем новый веб-ресурс намерено под 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:

Поздравляю, код UA удачно внесен в контейнер GTM на вашем сайте.

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

Ход 2. Интеграция Universal Analytics с CRM-совокупностью

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

Так выглядит стартовое окно совокупности HighRise:

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

Новые контактные лица в HighRise создаются машинально (с применением API HighRise) при заполнении одной из контактных форм на сайте WebProfiters.ru:

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

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

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

Учитывая всю перечисленную выше данные об изюминках на данный момент совокупности 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 (и в один момент отличий от Гугл Analytics) – это возможность передавать хиты вовнутрь UA, применяя простые HTTP-запросы. Другими словами, по сути, любое устройство, имеющее выход в интернет, может передать данные вовнутрь совокупности UA.

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

www.google-analytics.com/collect?v=1tid=UA-xxxxcid=555otherparameters

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

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

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

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

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

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

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

Создаем новый пользовательский показатель, показывая тип – Валюта, и минимальное и большое значения:

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

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

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

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

www.google-analytics.com/collect?v=1tid=UA-XXXX-YYYcid=1161411544.1373152807t=eventec=transactionea=Xeniacm1=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.

Случайные статьи:

Семинар \


Подборка похожих статей:

admin