Интеграция системы c Universal Analytics. Магия Universal Analytics

Большая часть из тех вопросов, которые я получил за последние дни, касается Google Analytics. А за последний год не стало проще отвечать на вопросы, поскольку ситуация далеко не такая определенная. Но теперь, когда Universal Analytics выходит из статуса бета-версии, становится версией по умолчанию и приобретает поддержку ремаркетинга, демографических данных и других функциональностей, которые мы обсуждали в этих выпусках, она готова выйти в свет, а потому пришло время для обновления. Для начала мне хотелось бы ответить на вопрос, который мне чаще всего задают: Universal Analytics - это не то же самое, что и премиум-версия Google Analytics. Более подробно премиум-версию Google Analytics мы рассмотрим в следующем видео, а сейчас я суммирую все и скажу, что Google Analytics Premium - это платная версия Google Analytics, которая предлагается корпоративным клиентам тогда, когда им нужно анализировать более крупные объемы данных.

Для таких объемов требуется быстрая обработка, более высокие ограничения выборки, большее количество пользовательских переменных или пользовательских параметров, гарантии исполнения обязательств и тому подобное. За некоторыми исключениями эта версия обладает таким же интерфейсом и теми же возможностями, что и стандартная бесплатная версия, но с большей мощностью и скоростью обработки. Как и стандартная бесплатная версия премиум-версия Google Analytics может запускаться в стандартной версии GA или в новой universal-версии. С точки зрения практического применения эти две версии действительно не имеют ничего общего. Проведя аналогию, можно сказать, что премиум-версия - это как гараж на две машины в сравнении с гаражом на одну машины,

а Universal - это тип машины, которую вы помещаете внутрь. Итак, неважно, машину какого типа вы ставите в гараж, Universal или Classic, один из этих вариантов просто предоставляет вам больше пространства для хранения этого автомобиля. Итак, это не Google Analytics Premium. Но что же тогда? Это следующее поколение платформы Google Analytics. Способы сбора и хранения данных в этих версиях сильно различаются. В конечном счете, у вас будет целый набор отчетов для того, чтобы воспользоваться преимуществами этих новых наборов данных. Но на данный момент эти изменения не столь очевидны. На самом деле в основополагающей части того курса, который мы сейчас записываем, вообще не раскрывается эта разница, поскольку те случаи, в которых применяется Universal Analytics, касаются только более продвинутых пользователей. Итак, если мы знаем, что это не премиум-версия, то тогда что это такое? И почему так называется? Мы знаем, что люди пользуются несколькими устройствами. Но на данный момент, если посетители используют разные устройства, то при входе в систему они регистрируются в GA как разные пользователи. Например, как вы сейчас, находясь на сайте lynda.com. Сам по себе сайт знает, что вы - это один человек и один аккаунт, и демонстрирует вашу историю, статус вашего аккаунта и т.д. независимо от того, какое устройство вы используете.

А вот ваша аналитическая система еще не умеет это делать. Она воспринимает вас как разных людей, поскольку не понимает, что все это один человек. При работе с Universal Analytics вы можете приказать системе переопределить тот идентификатор, который был присвоен вам системой Google Analytics, и вместо него использовать тот универсальный, который вы присваиваете всем этим разным устройствам. Эта возможность известна под названием "переопределение ID пользователя" и является одной из тех возможностей, которыми вы можете воспользоваться при работе с Universal Analytics. Более подробно мы расмотрим ее в другом видео, посвященном как раз ей, но вам стоит обдумать эту возможность, если для идентификации пользователя, входящего на сайт с разных устройств, вы применяете логин или другой способ. Следующее преимущество - теперь мы можем объединять оффлайн-конверсии с онлайн-конверсиями.

Очень часто конверсии запускаются в онлайн режиме, а заканчиваются уже оффлайн. Допустим, например, что ваша компания является дилерским центром по продаже автомобилей или call-центром, или даже игровой компанией, разрешающей использовать сервис In-App purchases. Сейчас вы можете связывать первоначальное посещение, которое мы называем "скрытой конверсией", с тем, что будет происходить позднее и часто не в сети интернет. Протокол измерений (measurement protocol) позволяет отправлять данные прямо в Google Analytics. В этом случае вы можете добавлять в систему Google Analytics свои собственные данные. На самом деле мы видели, что люди могут делать все, что угодно, возьмем, например, приготовление кофейных напитков: каждый раз, когда готовится новый напиток, данные отправляются в Google Analytics, или данные отправляются в GA всякий раз, когда в парке отдыха кто-то проходит через турникет.

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

Или вы отслеживаете тот регион продаж, к которому относится местоположение этого магазина. Вы можете добавлять любые виды дополнительных данных с помощью такой функциональности, как "Расширение параметров" (dimension widening). Она позволяет выгружать данные, которые дополняют и расширяют те данные, которые первоначально поступают в Google Analytics. Единственное предупреждение - вы все равно не можете добавлять личную информацию (PII). Вы не можете просто выгрузить всю информацию о взаимодействии с клиентами. Поэтому вам безусловно нужно проконсультироваться со своими юристами. Но на практике, если бы сотрудники Google не просмотрели бы ваш аккаунт, то они не смогли бы определить, кого они отслеживают. Никаких имен, адресов электронной почты, номеров социального обеспечения, никакой такой информации они бы не знали.

Кроме того, на данный момент вы можете выгружать данные о ценах из других рекламных источников. Если вы хотите проследить, сколько вы потратили на эти объявления Bing, теперь вы можете сделать это так же, как делали и для объявлений AdWords. А вот для загрузки данных AdWords эту возможность использовать не нужно, продолжайте пользоваться автоматической пометкой, и эти данные будут автоматически вытаскиваться из AdWords. Еще один момент - Universal Analytics основана на коде. Ранее у нас было несколько JavaScript-версий, которые в некоторой мере считались продуктивными. Даже реально устаревшая версия urchin.js, верите вы тому или нет, тоже была допустима. Синхронная версия ga.js.

Асинхронная версия ga.js. И dc.js, который включает такую функциональность, как ремаркетинг и отчеты по аудитории. Теперь будет еще одна база кода. Это файл analytics.js, и поскольку теперь это уже не бета-версия, в ней поддерживается ремаркетинг, а также все остальные функции. Т.е. это действительно универсальная база кода. Есть еще и universal cookie-файлы. Ранее у нас были все виды различных cookie-файлов, которые контролировали действия Google Analytics. Если бы вы изменили, к примеру, задержки сеанса, то вам пришлось бы изменить описание задачи таким образом, чтобы в нее входил специальный код, который будет модифицировать эти задержки в cookie-файлах.

Теперь все эти вещи отслеживаются посредством настроек в конфигурации аккаунта, поэтому вам не приходится изменять код, что всегда хорошо. Задержки сеансов, кампании, выбор тех сайтов, которые необходимо исключить из пиринга как переходы, иногда называемые самопереходами - все эти моменты будут отслеживаться в самом аккаунте. Подробнее мы рассмотрим это в следующем видео, в котором выполняем апгрейд. А так это тщательные побочные продукты этого упрощенного cookie-файла. Итак, важный вопрос: "Нужно ли запускать переход на другую версию"? Как консультант, я обязан отвечать "Все зависит от ситуации".

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

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

Мы выпустили новую книгу «Контент-маркетинг в социальных сетях: Как засесть в голову подписчиков и влюбить их в свой бренд».

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

Что это такое

Это стандарт систем аналитики, заменивший старую версию Google Analytics. В «бете» его запустили в 2013 году, полноценный переход случился в 2014. Universal Analytics помогает следить за клиентами и посетителями сайта везде: инструмент присваивает каждому пользователю User-ID, который закрепляется за ним навсегда и кочует от устройства к устройству. Если один и тот же человек заходит на сайт с телефона и компьютера, Google Universal Analytics поймет это и учтет.

Дальше – больше. Инструмент отслеживает вообще любую активность вашей аудитории: посещения сайта, действия в мобильных приложениях и даже офлайновые покупки. Он помогает оценить поведение пользователя в целом, а не в рамках одного визита. По-модному это называется «трекингом кросс-платформенного поведения». Теперь можно следить за тем, как ведут себя люди , а не посетители . Раньше приходилось делать выводы об эффективности сайта на основе всех учтенных визитов. При этом один и тот же человек мог сначала найти что-то полезное на телефоне, а потом подробно изучить все из дома и благополучно конвертироваться в покупателя. Но при этом первый визит на сайт учитывался как неконверсионный и бесполезный, хотя по факту это не так.

Как работает Google Universal Analytics

Проще, чем старая версия инструмента. Раньше «Аналитикс» использовал аж 5 разных cookies для сбора данных о посетителе. Они сообщали системе, откуда пришел пользователь, какое ключевое слово он вводил в поиск, и другую важную информацию. Теперь все не так – Universal Analytics использует только специальный User ID. Как только пользователь переходит на сайт, этот идентификатор отправляется на сервера Google, а все остальное подсчитывается уже там.

Не для всех

Схема работает только для зарегистрированных пользователей. По умолчанию все посетители сайта – новые. Но как только человек регистрируется и вводит логин и пароль, система сразу же подтягивает и присваивает ему User ID. Все, что делает залогиненный пользователь записывается на его личный счетчик.

Разберем пример. Представим, что у нас есть интернет-магазин книг

Новый пользователь заходит на сайт с клика по контекстному объявлению, устройство – смартфон. Ему присваивается ID_1. Человек поискал нужную ему книгу, нашел, но сразу заказать не решился – захотел сделать все с домашнего компьютера.
Добравшись до дома он снова заходит на сайт магазина.На этот раз переход прямой а браузер уже обычный, компьютерный. Ему присваивается ID_2. Пользователь регистрируется, выбирает нужную книгу и заказывает ее. Все это записывается на его личный счетчик.
Через неделю наш герой снова заходит на сайт по ссылке из социальных сетей (в прошлый раз он подписался на магазин «Вконтакте»). Изначально ему присваивается ID_3, но потом он заходит в личный кабинет и система подтягивает старый идентификатор – ID_2. Человек оформляет заказ, а все действия на сайте записываются на старый счетчик.

Функцию User ID Можно включить в разделе «Администратор». Нас интересует пункт меню «Код отслеживания» –> User ID.

Окей, а как обстоит дело с остальными функциями? Сейчас разберемся.

Как применять Google Universal Analytics Следить за покупателями в офлайне

Здесь поможет Measurement Protocol – специальный инструмент для связывания данных из разных источников. Информацию о клиентах из CRM можно передавать в систему аналитики в формате CSV. Это может быть пол, возраст и любые другие данные о клиентах.

Measurment Protocol работает с любыми устройствами, способными отправить простой HTTP-запрос, вплоть до терминала и сканера штрих-кодов. Такая функция пригодится если клиенты часто оплачивают покупки наличными при встрече с курьером или в пункте самовывоза. Основная сложность – сделать так, чтобы факт оплаты записывался на User ID конкретного человека, но это вполне возможно сделать средствами самого протокола. Подробнее об этом пишет сам Google .

Создавать собственные отчеты

Эта функция пригодится, если вам нужно что-то особенное. Здесь на помощь придут параметры и метрики пользователей. Первые помогают сортировать пользователей по разным характеристикам: городу, источнику трафика. ключевым словам и так далее. Вторые нужны, чтобы отслеживать какие-либо конкретные показатели с нужными вам параметрами, например, звонки дольше 5 минут или конверсия среди женщин. Главное – наладить отправку этих данных из вашей CRM и обратно.

Устанавливать время ожидания сессии

По умолчанию сессия в Google Universal Analytics длится 30 минут, а кампаний – 6 месяцев. Если для вас это слишком мало, можно настроить время ожидания как душе угодно, хоть на 10 часов. Это может пригодиться, если пользователям приходится подолгу висеть на сайте, чтобы сделать заказ (такое бывает). Настроить параметр можно также в меню Администратора, вот здесь:

Фильтровать брендированные запросы

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

Возвращать пользователей на сайт

В Universal Analytics есть собственный инструмент ремаркетинга. Он помогает запускать рекламные кампании в AdWords для аудитории, которая уже была на вашем сайте. Например, пользователь искал фотоаппарат на вашем сайте, нашел, посмотрел, но не купил. Если таких людей много. можно запустить рекламную кампанию с динамическим атрибутом. В этом случае в объявление будет подтягиваться тот самый некупленный фотоаппарат и говорить «ну купи меня, ты же обещал». Включить ремаркетинг можно все в том же меню Администратора, которое всем надоело:

Оценивать состав целевой аудитории

Можно настроить систему аналитики так, чтобы она собирала данные о поле, возрасте и интересах посетителей (прям как в «Яндекс.Метрике», ага). С их помощью можно сегментировать целевую аудиторию и тут же брать ее в оборот – запускать по сегменту рекламную кампанию в AdWords.

Отследить путь к целевому действию на всех платформах

User ID, прикрепленный к каждому пользователю, помогает определять, какими устройствами пользовался человек перед тем, как совершить покупку – примеры таких ситуаций я уже приводил. С помощью инструментов аналитики можно посмотреть, сколько людей просматривают сайт с телефона, а покупают товары с компьютера или наоборот. Это поможет оценить роль мобильного трафика в вашем случае. Если пользователи гаджетов много у вас покупают, стоит задуматься об улучшении мобильной оптимизации и всем таком.

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

Перевод

Весь бизнес рано или поздно уйдет в интернет, а веб-аналитики станут бизнес-аналитиками. Уже сейчас в бизнес аналитике используются элементы веб.

Диджитал-аналитик - довольно узкая специальность - это всего лишь бизнес аналитик, который в основном работает в диджитал-мире и немного в реальном.

Скоро не будет разделений. Никакого диджитала, никакого веба, оффлайна - только все вместе.

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

User-ID определяется аналитиком и отправляется в GA через параметр в коде. User-ID не содержит персональные данные. Для кодирования юзера можно использовать 64-битный хеш.

Можно увидеть пользователей с User-ID и без него. Со временем синее поле увеличится и позволит лучше изучить поведение. Но даже с таким количеством пользователей User-ID уже может ответить на пару вопросов. Например, сколько людей используют десктопную и мобильную версии. Или узнать действительно ли покупатели ищут с мобильного, а покупают со стационарного?

Даже если сайт не является коммерческим, все-равно важно заставить пользователя зарегистрироваться на сайте. С User-ID это проще проанализировать и прийти к подходящему решению. Это важная маркетинговая задача. Нужно учитывать человеческую психологию.

Очень хорошо это получается у L"Oreal Paris. У них много интересного контента, который заставляет пользователя возвращаться на сайт снова и снова. Каждая статья и продукт оснащены кнопочкой «Сохранить», которая работает даже для незалогиненных юзеров. Но если пользователь не хочет потерять свои закладки - он должен создать аккаунт. Возле каждого продукта есть кнопка «Подобрать», которая позволяет подобрать интересные для покупателя статьи и товары, и это тоже ведет к залогиниванию.

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

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

Всего-лишь пара движений мышкой и вот они, ответы на все вопросы.

Это самое простое представление. Можно отслеживать показатели по доходам и транзакциям. С помощью UA можно увидеть где человек начал свой путь и как взаимодействовал с сайтом с одного или нескольких устройств.

Импорт Любые собранные в оффлайне данные можно импортировать в Google Analytics. Например, данные из CRM значительно расширят представление о клиенте.

Единственное, что нам может рассказать GA о пользователе из первого примера - это уникальный ID.

Увеличив размер базы можно добавить другую полезную информацию о клиенте.

Чем больше информации добавляется, тем больше ее можно дополнить (но без использования персональных данных).

Для этого нужно войти в свой аккаунт и в свойствах нажать «Импорт данных». Также данные можно импортировать с помощью API Google Analytics Management :

Отчеты, которые там можно увидеть будут зависеть от данных, отправленных в GA. Например, информация может выглядеть так:

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

Еще один пример: использование туристической компанией. Разделение на типы путешественников:

Здесь можно посмотреть подробный мануал по импорту данных.

Протокол измерения и передачи данных Когда происходят какие-то действия в оффлайне, есть возможность их передать GA через специальный протокол. Эти данные можно связать с обычной активностью пользователей.

Вот как выглядит отчет:

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

Простой пример кода:

POST /collect HTTP/1.1 Host: www.google-analytics.com v=1 // Version of GA protocol. Constant. &tid=UA-XXXX-Y // Property ID &cid=555 // GA Client ID. Retrieved from tracking code. &ni=1 // Non-interaction hit. &t=event // Event hit type. Required. &ec=ClientOfflineConv //Event Category. &ea=OnlineLead // Event Action Required. &el=OpportunityRegistered // Event Label. &ev=300//Event value (300)

ec (категория): Сгруппирует все оффлайн данные.
ea (действие): Совершённое действие.
el (метка): Название события. Изменится вместе с изменением статуса юзера в базе.
ev (значение): Должно быть установлено, если значение связано с оффлайн данными.

А вот пример интеграции оффлайн данных, использующий server-to-server запрос:

Function gaFireHit($data = null) { if ($data) { $url = "https://ssl.google-analytics.com/collect"; $getString .= "?payload_data&"; $getString .= http_build_query($data); $result = socketPost($url, $getString, $_SERVER["HTTP_USER_AGENT"]); return $result; } return false; } function socketPost($url, $post_string, $ua = null) { $parts = parse_url($url); $port = isset($parts["port]) ? $parts["port"] : 80; $success = $fp = fsockopen($parts["host"], $port, $errno, $errstr, 30); if ($fp) { $output = "POST" . $parts["path"] . " HTTP/1.1\r\n"; if (is_string($ua)) { output .= "User-Agent: " . $ua . "\r\n"; } $output .= "Host: " . $parts["host"] . "\r\n"; $output .= "Content-Type: application/x-www-form-urlencoded\r\n"; $output .= "Content-Length: " . strlen($post_string) . "\r\n"; $output .= "Connection^ Close\r\n\r\n"; $output .= isset($post_string) ? $post_string: ""; $success = fwrite($fp, $output); fclose($fp); } return $success ? true: false; }

Бонусы Есть еще несколько вещей, которые Universal Analytics может упростить. Например,

За несколько лет в вебе наши маркетологи привыкли к системам аналитики, они их понимают, хорошо знакомы с большинством инструментов, знают, как их использовать. Они научились с этим работать за 5-10 лет. А мобильная аналитика пока для них темный лес. Соответственно и функционал немного отстает в развитии от веба, потому что отрасль молодая.

Об этих проблемах мы поговорим со старшим аналитиком Google Analytics, Станиславом Видяевым. Полная аудиоверсия интервью - iTunes , TuneIn .

Я захожу в систему, какой функционал мне нужно освоить в первую очередь, чтобы начать реально работать с вашим продуктом? Может быть, есть какая-то литература, семинары, ваши книги на английском языке?

Google Analytics изначально веб-продукт и в нем хорошо развиты все соответствующие метрики.
Развитие идет таким образом, что изначально веб-продукт начинает приспосабливаться к появлению этого мобильного мира.

Если сказать честно, то компания Google немного опоздала: первые мобильные профили у нас появились 2 года назад (июнь 2012 года), с этого времени мобильное направление развивается, и система пытается освоить мобильный язык. Но все-таки подходит к мобильному миру с точки рения веб-маркетолога.

Маркетолог, который занимался веб-аналитикой, сайтами, он уже более-менее подготовлен, и, приходя к нам за анализом мобильного приложения, он выбирает привычные метрики.
Для мобильного приложения они не сильно применимы, но тем не менее их можно использовать, оценивая эффективность мобильного приложения.

Все метрики, какие там есть и какие видны стразу после установки Analytics. Это количество активных пользователей, новые, возвращающиеся, география использования приложения, популярность отдельных разделов, как люди их смотрят (те же самые конверсии, покупки) - весь тот набор, который изначально нужен для понимания, что в мобильном приложении происходит. Еще какие то вещи можно настраивать - Custom Dimensions.

Что такое Custom Dimensions?

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

Такой конструктор есть и в вебе. Мы переносим веб на мобильные рельсы. Архитекторы считают, что те концепты и принципы аналитики, которые существуют для вебсайтов, применимы и для мобильных приложений

Где мне почерпнуть первичный набор знаний?

Книга - самый неудачный способ описания проблемы, как только она опубликована, она тут же устаревает. Я бы отправил всех на наш ресурс . Единственный недостаток в том, что он только на английском, на русский пока не переведен.
На этом ресурсе самая последняя информация, там делаются все анонсы.

Естественно, интернет необъятный, есть много умных людей, которые пишут от себя что-то стоящее. В основном я бы читал у различных авторов обзоры разных систем и их сравнения. Они не всегда корректные, что-то они упускают, но общая идея хорошая.

Какие реальные проблемы ты сейчас видишь в мобильной аналитике?

Это сложность системы в целом. То есть техническая аналитика в мобильных приложениях. Я не беру сайты, потому что может быть дальше у нас не будет разделения на мобильный и обычный сайт, и такое понятие, как мобильный сайт исчезнет.

Если брать приложение, то это сложность технической имплементации, интеграции пакетов и большие требования по установке к технической подготовке того, кто это делает.

Если на сайт установил код и поехали (есть какие-то данные), то в приложении надо подумать заранее что мы хотим отслеживать, как и в какие моменты, мы хотим запускать те или иные события. То есть это все нужно заранее обдумать и технический специалист должен это дело имплементировать. Опять-таки, если касаться собственно Google Analytics то, как я упомянул, система только привыкает к мобильным определениям.

Есть еще одна тема, которая сегодня развивается (это с одной стороны слабость Google Analytics, но из этой слабости хотят сделать очень сильную сторону) - это объединение двух миров - веба и мобайл.

Вот как раз под «зонтиком» Universal Analytics мы будем в этом направлении двигаться. Universal Analytics - это новая реинкарнация Google Analytics, у которой другой код и архитектура, там используются другие cookies - это новая система. Она называется Google Analytics только потому, что ее видно в интерфейсе.

Когда я подготавливался к интервью, я снова посмотрел документацию на еще один хороший источник - developers.google.com - там техническая информация. В том числе посмотрел SDK, и там уже есть раздел User ID, который можно использовать для отслеживания переходов с разных устройств на сайт (пока только на сайт) одного и того же пользователя.

Какой там принцип?

Пользователь приходит на сайт, ему в браузер загружается client ID - это идентификатор Google Analytics, и он уникален для этого браузера, то есть, сколько браузеров у пользователя, столько и идентификаторов и, соответственно, уникальных посетителей в отчетах Analytics. Если на одном устройстве у него три браузера, то это будет три разных пользователя.

Есть User ID - это параметр владельца бизнеса, владельца сайта. То есть, когда пользователь зарегистрировался, заполнил заявку (как-то идентифицировал себя), то владелец сайта может подгрузить этот User ID.

Так вот в документации для мобильных приложений уже появился User ID. То есть мы можем объединять не только его историю посещений сайта, но и приложений. В данный момент у нас пока четкое разграничение между миром веб и мобайлом. Но потом Universal Analytics будет двигаться в сторону объединения этих двух миров.

Вы активно пропагандируете Google Tag Manager. Что это за штука, как она работает?

Google Tag Manager - это способ работы с трекинговыми кодами. Если брать вебсайты, это код, скрипт - кусочек кода, который мы устанавливаем на сайт, и уже потом в интерфейсе Tag Manager работаем с непосредственными трекинговыми кодами аналитических систем.

И этот код Tag Manager, он выполняет функции других кодов, то есть, он отправляет вызовы, притворяется ими и в данный момент, он может работать как Google Analytics, потом как Яндекс.Метрика, потом как Conversion Tracking - он выполняет функции этих кодов.

Какую проблему он решает?

Проблему установки кодов в исходный код сайта. То есть, у нас нет необходимости каждый раз бежать к техническому специалисту, к веб-программисту и говорить: «Установи вот эту маленькую строчку». А он это ставит в Pipeline, и это дело длится три месяца, это правится, потом выполняется - чем больше компания, тем больше заморочек в этом плане.
С Tag Manager мы имеем один сниппет на сайте, возможно, к нему какие-то дополнительные функции, которые мы продумали заранее, допустим, транзакция. Дополнительные параметры в синтаксисе Tag Manager-а передаются в Data Layer - это способ передачи событий, переменных и транзакций для Google Tag Manager. То есть все параметры прописали, и потом мы можем отслеживать, например, транзакции и в Google Analytics, и в Яндекс.Метрике - везде где нам нужно.

В мобильной аналитике та же история?

История следующая. Создатели и разработчики Tag Manager сделали его следующим образом: для Tag Manager и для Google Analytics единый SDK. То есть, интегрируя в SDK последний Google Analytics с приложением, вы интегрируете и Tag Manager. И наоборот - интегрируя Tag Manager, вы получаете Google Analytics.

То есть управление этим кодом достаточно более простое и эффективное. Дело не только в таких маркетинговых ходах. Допустим, нужно отслеживать какое-то событие в Tag Manager, для этого не надо бежать в разработку и заставлять их делать новую версию приложения, публиковать ее, чтобы этот вызов или событие было включено.

То есть я могу настроить отслеживание любого события без помощи разработчиков?

Да. При условии, что это событие заведено в Tag Manager. То есть если оно там есть, то внутри Tag Manager можно на это событие заводить любые коды, которые надо. Это намного проще.

Есть еще один момент. При интеграции с Analytics появляются возможности, например, по проведению экспериментов.

Что за эксперименты?

Это эксперименты на реальных пользователях. То есть мы не где-то в песочнице тестируем различные цвета, размеры кнопок, картинок, текстов, оформление логотипов и т.д. Все эти элементы дизайна можно динамически менять и проводить эксперименты в Google Analytics.

Это будет выглядеть так. Эксперимент создается и конфигурируется в Tag Manager, а визуализация этого эксперимента и все графики, какой вариант конфигурации приложения победил, они все видны в Analytics. И после завершения этого эксперимента можно будет в Tag Manager сконфигурировать приложение таким образом, чтобы выигравший вариант стал базовым.

Это, например, эксперимент с формой: какая регистрация лучше - только Facebook или Facebook + Email?

Да, в том числе. Элементы, с которыми мы хотим провести эксперимент, мы их оформляем переменными Tag Manager, то есть вызов контейнера.

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

Но есть другой вариант - у вас есть такой инструмент, как Google Developer Console. Почему бы там не выводить больше количество информации по retention, churn rate и т.д.?

Мы движемся в этом направлении, но идеальной ситуации нет, к ней можно только стремиться. Появляются отчеты. Недавно был июньский апдейт - появился ряд отчетов для игровых приложений. То есть там видно количество игроков, retention и т.д. Но опять-таки это достаточно общая информация.

Если ты хочешь увидеть что-то эдакое, например, посмотреть с помощью Google Analytics, как пользователи отваливаются при прохождении различных уровней игры. Например, у тебя 10 уровней, и с помощью аналитики ты выявляешь, что уровень 5 и 6 слишком трудные, пользователи их не проходят и отваливаются. После этого ты делаешь их чуть полегче, и они у тебя доходят до уровня 7-8. То есть длительность взаимодействия с пользователем в одной игрушке увеличивается.

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

Какие базовые возможности Google Developer Console?

Это место, где мы публикуем приложения. То есть заводиться аккаунт разработчика, мы публикуем приложения, оплачиваем $25 и начинаем продвигать его в Google Play (у вас может быть несколько приложений), и там по умолчанию доступна часть статистики. Но опять-таки для серьезной аналитики это не подойдет - это базовый уровень.

Есть ли у вас удобный способ для трекинга источника инсталов, что-то типа аналога того же MAT. То есть для Android он вроде как точно есть, но как это сделать для iOS?

Это вопрос интеграции Google Play с приложением. Если мы это делаем, то у нас видны источники, которые приходят в Google Play (на нашу страничку) и потом превращаются в инсталлы, потом мы можем увязать эту историю с конверсиями.

Говоря на веб-жаргоне - Google Play протягивает referrer. То есть тот referrer, который принес нам трафик (это может быть платный источник, партнерки, социальные сети - что угодно), все эти вещи мы можем видеть внутри аналитики приложения.

Более того, там же дальше тема развивается - трекинг конверсии, чтобы обратно в тот же AdWords отдать конверсию - это тоже все возможно, вплоть до последнего клика показа конкретного объявления в конкретном приложении. Мы видим конверсию.

На основе это аналитики мы видим источник 1, источник 2, инсталы, конверсии. Мы видим, что источник 1 надо отключать, потому что он не конвертируется, а все деньги нести в источник 2, например. Аналитика об этом. Этот как раз объединение маркетинговых действий с поведением пользователя внутри Android-приложения.

iOS не передает, не протягивает referer. Для того чтобы это сделать на developers.google.com/ , есть описание процесса, как этот referrer протащить. То есть там уже серверная интеграция, нужна серьезная техническая настройка.

Как правильно считать время жизни пользователя в приложении?

Наука не знает, что происходит после последнего отслеживаемого события. Пользователь кликнул, открыл страницу - сколько он на ней был? Он ее читал 5 минут или изучал ее 40 минут по диагонали, вверх-вниз и поперек - мы этого не знаем.

У нас есть время нахождения пользователя на сайте или в мобильном приложении - это первое и последнее событие, и мы измеряем период, который прошел между ними. То есть Google Analytics отслеживает какое-то событие, и от этой точки начинается отсчет времени.

Что можно сделать, чтобы это дело сделать более точным?

Был такой прием, для вебсайтов он прокатывал. Например, просмотр страницы: допустим, у нас большой контентный сайт, у нас огромные статьи, люди читают аналитику. Открыл страницу - читаю, больше никаких событий не происходит. То есть, сколько я на этой станице нахожусь, Analytics не знает и не может знать.

Для того чтобы измерить время на этой странице мы запускаем событие. Допустим, каждые 15 секунд, пока пользователь находится на странице, мы отправляем событие или отслеживаем Scroll как событие - получается, мы даем Analytics понять, что пользователь все еще находится на сайте.

Для приложения можно запустить какую-то аналогичную вещь. Не только отслеживать клики по кнопкам, но и такие вещи, как Swipe, Zoom In, Zoom Out - на все эти действия, сугубо применимые для приложения, мы тоже можем отправлять события. То есть на таком экране произошел Zoom In, на другом экране произошел Zoom Out. Все это можно отслеживать, и это увеличит время взаимодействия пользователя с приложением. А если оно открыто и экран темный, то, я думаю, не надо ничего отслеживать.

Такие моменты как виральность, органика и прочее - есть ли возможность отслеживать как минимум виральность приложения или хотя бы оценивать примерное значение?

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

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

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

Или, например, сегодня на TV была новость. Соовтетственно, мы смотрим на органический трафик, на цитируемость бренда в поиске - все эти вещи должны быть в комплексе. Можно разбить это дело по сегментам и смотреть, как рекламный трафик влияет на рост органики.

Органический трафик уже виден в отчетах?

Да. В Analytics это видно, там будет два сегмента - две кривые - идут они друг за другом или не идут. Соответственно, также можно оценивать качество трафика, например, каково время взаимодействия с пользователем, падает оно или увеличивается. То есть ту аудиторию мы приводим или нет. То же самое с конверсиями.

Все эти вещи можно оценивать по ряду косвенных признаков. Естественно, прямого отчета нет.

Есть еще одна проблема - это фрод в мобильном сегменте: наливают некачественный трафик. Если ли возможность этот фрод определять? Я знаю, как это делать в вебе. То есть я вижу источники, даже смотрю ту же сеть Google, то, что он не поймал, я сам долавливаю и смотрю мошенников с промахами кликов, что угодно - вариантов как меня перехитрить много. Я детально отсекаю каждую площадку.

Если ты какие-то механики отсева этого фрода в мобайле при помощи того же Google Analytics?

Analytics не предназначен для ловли воров. Опять-таки, это ряд косвенных признаков.

У меня пока не было кейсов, чтобы я кого-то отловил именно для мобильной аналитики, а вот с вебсайтами были. Обращались клиенты и спрашивали, что это за трафик такой.
Фрод можно увидеть по некоторым специфическим показателям взаимодействия.

Бывает, делают такие баннеры, что при нажатии на крестик я все равно попадаю по рекламному объявлению. Как я пойму, что что-то там не то, по какому событию?

Первый признак - это высокий показатель отказа (bounce rate). Если у нас цель инсталлы и этот трафик дает инсталлы, то тут немного сложнее. Если мы видим большое количество посещения страницы Google Play/App Store и мало установок, а для нас этот трафик платный, то мы можем задуматься, каким образом это происходит.

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

Как вести себя с партнерами - это следующий вопрос, но факт фрода сам Analytics не увидит, а просто подскажет, что здесь видно, что приходят и не инсталлируют.

Вопрос об ограничениях на продукт по объемам, по количествам событий и т.д. - они применимы к мобайлу?

Да. Ограничение общее, как для всего Analytics, так для любого ресурса. И есть несколько ограничений непосредственно для мобильных приложений. Это все описано в документации.
Для стандартного Google Analytics - это 10 миллионов хитов в месяц.

Для одного ресурса это ограничение достаточно растяжимое. То есть если у нас 30-40-50-100, мы работаем нормально. Единственное, что в негатив, который происходит, у нас включается выборка - точность данных страдает. Мы видим те же самые графики, тенденции, но, условно говоря, в отдельных отчетах система берет за основу расчета данного отчета 10% этого трафика, а потом домножает в уме. Это семплирование - выборка.

С появлением в России реселллеров, и с появлением возможности приобрести Google Analytics Premium для тех сайтов, в том числе и приложений, это правило становится более жестким. То есть мы оповещаем: «Дорогой клиент, Вы превзошли лимит во столько-то раз».

Если у вас 10-20-50 миллионов хитов, такого извещения не будет. Если много - 500 миллионов в месяцу, то велика вероятность, что такое оповещение будет получено.

Можно ли хоть забирать сырые данные по мобильному приложению для построения своей аналитики?

Да. Для API мобильных приложений такой возможности сейчас нет, но я полагаю, что под «зонтиком» Universal Analytics она будет. В частности то, что User ID начинают прикручивать к мобильным устройствам, а это ведь тема, приближенная к API. Сервер - это уже работа с Big Data и прочие интеграции.

Я полагаю, что эта тема будет развиваться в ближайшее время и API для мобильных приложений будет либо отдельный, либо в рамках Core Reporting API, который сейчас есть в Analytics. Я не знаю, как это будет архитектурно, но само собой напрашивается, что будет.

Наверняка есть какой-то Road Map, о котором ты слышал и про который вам коллеги разрешают рассказывать. Что будет? Когда появятся такие метрики, как Return Rade, LTV, еще что-то? Когда Google Analytics начнет со мной разговаривать на мобильном языке?

Он как трехлетний ребенок пытается осваивать язык мамы и папы, уже что-то говорит. В данном случае Return Rade в вебе есть отчет по лояльности - новые и вернувшиеся. Аналогичные отчеты есть в мобайл, только они немного по-другому называются, но их там можно смотреть и работать с ними.

Что касается LTV - то этого отчета нет, но с помощью кастомных метрик и параметров его можно собрать. То есть условно мы знаем, что этот пользователь вчера купил у нас что-то на 5 рублей, и мы в переменную ему записываем, что он оставил у нас 5 рублей. Если он завтра еще что-то на 5 рублей купит, мы можем взять те предыдущие 5 рублей и к ним прибавить еще 5 и получится 10 рублей.

Опять-таки, всех случаев не предусмотришь. Мы не всегда можем предусмотреть и предсказать, что данная функция действительно будет пользоваться успехом. А дать возможность конфигурировать самим то, что нужно, с помощью тех же кастомных переменных (пользовательских определений на языке Universal Analytics) можно.

Там есть переменные на уровне хита, сессии и пользователя. И как раз для LTV лучше подходит сессия на уровне пользователя, когда мы присваиваем пользователю какой-то параметр.

Об этом все говорят, но не все это используют, потому что это довольно специфическая функция. А потом сегментировать пользователя, который оставил 10 рублей, против пользователя, который оставил 5 рублей, и сравнивать данные по ним.

В общем, вам не хватает образовательных вещей на простом языке.

На самом деле западный рынок более подготовленный и образованный в этом плане. Они без проблем общаются на более техническом языке. То есть там люди подкованные, и им можно просто сказать: «Вот кастомные переменные». А в ответ: «Окей, пойду делать, все понял».

Может быть, есть еще какие-то, фичи, сюрпризы, обратная связь, push-уведомления?

Внутренняя коммуникация с product-менеджерами строится таким образом, что вещь, которая подходит - нам о ней рассказывают. То, что я рассказывал про объединенный функционал Tag Manager и Google Analytics, о возможностях в этой системе, это как раз вот такой функционал, который прямо сейчас становится доступным.

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

Есть какая-то обратная связь с рынком?

Да. У нас есть разработчики, специалисты, которые общаются внутри Google с продавцами - с нами, мы продаем AdWords и помимо этого у нас есть потребность клиентов в аналитике.

Мы собираемся, и эта коммуникация идет вот таким образом. У нас есть человек по Восточной Европе, мы ему коммуницируем, что у нас есть такие-то сложности, такие-то возможности и замечательные конкуренты - давай вместе посмотрим интерфейс, может, возникнут какие-то идеи.

Мы смотрим вместе, у него появляются идеи и он может коммуницировать их разработчику. Разработчик говорит - «Окей, интересная тема, давай посмотрим». Такая коммуникация есть.

Для отслеживания информации об источниках система использует данные, собранные сервисом Universal Analytics стандартом Universal Analytics.

Также для ознакомления с настройками и подключением Universal Analytics Вы можете .

Добавление сайта в Universal Analytics

Для того, чтобы ваш сайт был зарегистрирован в Universal Analytics, необходимо иметь аккаунт Google.

Если у Вас уже есть аккаунт Google (т.е. если Вы уже используете какую-либо службу Google), войдите в свой аккаунт . Мы не рекомендуем использовать здесь аккаунты, предназначенные для личного пользования (например, ваша личная электронная почта).
Если у вас еще нет аккаунта, перейдите на страницу регистрации в Google, заполните все поля и нажмите Далее . Если данные внесены верно, регистрация пройдет успешно.

Создадим аккаунт Universal Analytics .

Universal Analytics - это расширенный стандарт Google Analytics. Далее под словами «Google Analytics» будет подразумеваться сервис в целом, а «Universal Analytics» - только настраиваемый функционал.

Создание аккаунта Universal Analytics:

Укажите, что желаете отслеживать: веб-сайт или мобильное приложение.

Введите название и URL своего сайта.

Выберите категорию бизнеса, к которой имеет отношение Ваш сайт.

Укажите часовой пояс, по которому будут определяться дни в отчетах.

Введите название нового аккаунта.

Выберите нужные настройки доступа к данным.

Нажмите кнопку Получить идентификатор отслеживания .

После создания аккаунта Universal Analytics Вы автоматически перейдете на страницу своего профиля Google, где будет показано название вашего сайта, который нужно отслеживать, и номер аккаунта Universal Analytics в формате UA-XXXXXXXX-X. Этот код называется «идентификатор веб-ресурса Google Analytics» и является уникальным для каждого отслеживаемого ресурса.

Настройка отслеживания электронной торговли аккаунта Google Analytics

После того, как Вы зарегистрировали аккаунт Universal Analytics, нужно настроить отслеживание электронной торговли.

Примечание: в демо-версии системы загрузка из Universal Analytics не производится.

Настройки в Universal Analytics

Чтобы включить отслеживание электронной торговли в Universal Analytics, проделайте следующие шаги:

Перейдите в раздел Администратор .

В столбце Представление выберите Настройка представления .

В пункте Настройки электронной торговли выберите Отслеживание электронной торговли .

Нажмите кнопку Применить .

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

Получение кода отслеживания

Код отслеживания Universal Analytics - это скрипт на языке JavaScript, который выполняется браузером посетителя Вашего сайта. С помощью кода отслеживания данные о действияx посетителя на вашем сайте будут отправляться в Google Analytics.

Чтобы получить код отслеживания, нужно:

В верхней части любой страницы нажать Администратор .

В столбце Ресурс выбрать Код отслеживания .

Вы увидите такой код:

Нужно будет скопировать с Universal Analytics Ваш код отслеживания целиком. В нём вместо UA-XXXXXXXX-X будет находиться Ваш действительный идентификатор отслеживания.

Настройки на сайте

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

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

Модифицировать код нужно только на страницах, которые пользователь видит после завершения/подтверждения заказа; таким образом, модифицированный код должен выполниться только один раз для каждого заказа.

В отличие от модифицированного, обычный код отслеживания должен исполняться при каждом просмотре любой страницы.

Для Universal Analytics необходимо модифицировать код отслеживания следующим образом:

... ga("send", "pageview"); // здесь оканчивается немодифицированный код отслеживания. Добавляем следующие команды: ga("require", "ecommerce", "ecommerce.js"); // функция, которая подключает модуль электронной торговли. ga("ecommerce:addTransaction", { "id": "1234", // ID транзакции "affiliation": "example.com", // Название магазина "revenue": "1500", // Общая стоимость заказа "shipping": "250", // Стоимость доставки "tax": "" // Налог }); // метод addItem нужно вызвать для каждого товара (позиции) в заказе: ga("ecommerce:addItem", { "id": "1234", // ID транзакции "name": "Mouse Logitech", // Название товара "sku": "AAA000", // Артикул или SKU "category": "Wireless", // Размер, модель, категория или еще какая-то информация "price": "750", // Стоимость товара "quantity": "2" // Количество товара }); ga("ecommerce:send"); // Отправка данных

В этом коде можно указывать поля в любом порядке. Обязательными являются только поля, содержащие ID транзакции и название товара. Названия полей должны быть заданы маленькими английскими буквами, например, category, а не Category, и не CATEGORY.

В коде видны следующие функции:

ga("require", "ecommerce", "ecommerce.js"); - функция, которая подключает модуль электронной торговли.

ga("ecommerce:addTransaction", - функция, которая передает информацию о самом заказе.

ga("ecommerce:addItem", - функция, которая передает информацию о товарах в заказе.

Поля, которые необходимо передать в функцию:

ga("ecommerce:send"); - функция, подтверждающая отправление данных.

С полным списком возможных полей можно ознакомиться в официальной документации

Интеграция с системой

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

Выгружаемые заказы могут содержать:

Внешний ID (externalId);
Внутренний ID (id);
Номер заказа (number).

Из магазина в Universal Analytics данные выгружаются со стороны клиента, то есть непосредственно с компьютера посетителя магазина.

Эти данные состоят из двух частей:

Информация о визитах, полученная благодаря коду отслеживания, который ставится на каждую страницу сайта;
Транзакции, содержащие информацию о заказах.

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

Транзакции содержат уникальный (в пределах магазина) идентификационный номер (ID транзакции). Он должен соответствовать либо внешнему или внутреннему ID, либо номеру заказа в данных, выгружаемых в систему. Это требуется для связи данных транзакций Universal Analytics с данными внутри системы.

Для того, чтобы успешно провести интеграцию системы и вашего аккаунта Universal Analytics необходимо выполнить следующее:

1. Получить идентификатор представления интернет-магазина в Universal Analytics. Для этого нужно в Universal Analytics выбрать Администратор > Настройки представления и скопировать Идентификатор представления.

2. В системе перейти в раздел Администрирование > Интеграция .

3. Выбрать интеграцию с Universal Analytics. Активировать Интеграцию посредством выставления галочки.

4. Указать, каким данным, которые выгружаются из магазина в систему, соответствует ID транзакции.

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

5. Добавить пользовательский параметр/переменную, которая нужна для хранения данных о визитах.

В Universal Analytics - это пользовательский параметр (custom dimension). Нужно зайти в раздел Администратор > Ресурс > Пользовательские определения > Пользовательские параметры и добавить Параметр retailCRMVisitorID . Ему будет соответствовать номер индекса, который следует запомнить.

6. Указать идентификатор профиля/представления Universal Analytics .

Кроме идентификатора профиля/представления Universal Analytics , на странице Интеграции нужно будет ввести номер индекса, который появился при добавлении пользовательского параметра.

Галочка «Переводить распространенные имена источников и каналов» позволяет отображать источники и каналы в общепринятом написании. То есть, вместо mail.yandex.ru, будет отображаться «Яндекс.Почта».

7. Скопировать имя пользователя системы. Это робот, собирающий данные из Universal Analytics для системы.

8. Добавить пользователя в аккаунт Universal Analytics. В Universal Analytics нужно выбрать Администратор > Аккаунт > Управление пользователями . Добавляемый пользователь должен обладать правами «Читать и анализировать» .

9. Добавить в код счетчика в Universal Analytics

/** * Get cookie value by name. retailCRM integration with Universal Analytics uses it. * Name should match pattern + * * @param string name * * @return mixed **/ function getRetailCrmCookie(name) { var matches = document.cookie.match(new RegExp("(?:^|;)" + name + "=([^;]*)")); return matches ? decodeURIComponent(matches) : ""; } ga("set", "dimension1", getRetailCrmCookie("_ga"));

Вставить ее нужно будет перед ga("send", "pageview"); в коде отслеживания на все страницы вашего сайта.

Важно! В последней строке добавляемого кода, ga("set", "dimension1", getRetailCrmCookie("_ga")); , единицу в конце dimension1 нужно заменить на индекс пользовательского параметра в случае, если он не равен 1.

Universal Analytics идентифицирует посетителей сайта при помощи временных файлов - cookie, которые хранятся на компьютере у пользователя. Один из них содержит уникальную метку пользователя. Скрипт, который добавляется в код отслеживания, читает уникальную метку и затем отправляет это значение в Universal Analytics, где она хранится в пользовательской переменной (в пользовательском параметре Client ID в Universal Analytics).

Cookie _ga содержит уникальный идентификатор в формате GA1.2.XXXXXXX.YYYYYY , например, GA1.2.1129978185.1425645525 , где саму метку составляет только значение 1129978185.1425645525 (clientId). В систему можно передавать как полное значение cookie (что произойдет, если вы будете использовать вышеуказанный код), так и только clientId без префикса.

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

источников,
визитов,
событий воронки.

Загрузка данных по событиям

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

В случае, если Вы выбрали вариант связывания заказов через события, ниже появятся два поля ввода данных для загрузки событий: «Категория» и «Действия».

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

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

Как создавать, изменять и публиковать цели Вы можете прочитать в справке Google .

Выгрузка данных из системы в Universal Analytics

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

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

Дополнительная информация по параметру Client ID и сценарии его использования

Метки клиентов (Client ID) - это служебная информация, которую вручную специально указывать не надо. Они автоматически генерируются на компьютере пользователя и сохраняются со всей информацией в Universal Analytics.

В этом случае могут быть такие сценарии использования:

1. В связке с CallTouch. Заказ создается по телефону, при этом CallTouch через свои системы передает некоторые данные (Client ID, источник) в системе, и мы отправляем их в Universal Analytics.

2. По уже известному Client ID. Например, есть стандартная интеграция с Universal Analytics и клиент, оформлявший заказы на сайте. Тогда в системе есть его Client ID, полученный из Universal Analytics. После этого новый заказ этого клиента создается по телефону, но за счет знания Client ID мы можем отправить его в Universal Analytics, как если бы он был создан на сайте.

Во втором случае неважно, откуда был получен Client ID - из GA или из первого случая, хотя в последнем варианте будут также получены данные из CallTouch.

Если Client ID приходит к клиенту не из Universal Analytics, а, например, из CallTouch, то при очередной загрузке данных из Universal Analytics система попробует подтянуть данные по этому клиенту.

Например, клиент бродил по магазину и визиты зафиксировались в Universal Analytics, сделал заказ по телефону и данные передались в систему через CallTouch, тогда и визиты должны подтянуться в систему.

Загрузка в Universal Analytics задним числом

Данная настройка позволяет указать, насколько давние записи будут считываться при загрузке за более короткий срок. Это необходимо для аккаунтов Universal Analytics с большими нагрузками, данные в которые попадают с запаздыванием.

Чтобы включить данную настройку, необходимо перейти в раздел Администрирование > Интеграция > Universal Analytics . В поле «Запаздывание данных» выставляете нужное Вам время считывания.

Особенности настройки интеграции с InSales

InSales, наверное, самая удобная CMS для интеграции с точки зрения настройки клиентского сайта. Для этого нужно зайти в Настройки. Код отслеживания добавляется в поле javascript-код для вывода на всех страницах магазина. Пример (во всех примерах UA-XXXXXXXX-X нужно будет заменить на реальный идентификатор ресурса!):

Так как InSales помещает этот код не в начало страницы, то нужно его дублировать. Поэтому код выгрузки транзакции нужно поместить в поле javascript-код для вывода на странице успешного оформления заказа, добавив в его начало вышеприведенный код (и, по сути, продублировав его в пределах страницы). Пример:

Внимание! При интеграции с InSales в настройках аналитики нужно указать "Связывать транзакции через Номер заказа ", что не совпадает с настройкой по умолчанию. В настройках InSales есть также поле Код Google Analytics для анализа посетителей на сайте . Его заполнять не нужно: во-первых, будет сгенерирован GA-, а не UA-код; во-вторых, код будет генерироваться "из коробки" и не позволит вам добавить в него запись уникальной метки из cookie в custom dimension.