Веб аналитика что это такое

Веб-аналитика – совокупность действий и инструментов для измерения, сбора и анализа данных о работе сайта и поведения пользователей на нем.

Больше видео на нашем канале - изучайте интернет-маркетинг с SEMANTICA

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

Веб-аналитика: что это такое и какие задачи она выполняет

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

Цели веб-аналитики

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

1. На основе данных можно грамотно создать продающую страницу с указанием наиболее популярных товаров.
2. Анализируя поведение пользователей, владелец информационного веб-ресурса может оптимизировать структуру сайта, изменить внутренние ссылки на страницах и т. д.
3. У SEO-специалиста есть возможность проверять поисковый трафик, убирать лишние ключевые запросы, добавлять новые или корректировать существующие.

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

• Комплексное изучение сайта. Основа веб-аналитики состоит в проведении статистических исследований. Она позволяет изучать как обобщенную информацию о веб-ресурсе, так и детализированную, с уточненными данными, детально разработанную по каждой отдельной странице. Сайт изучают при помощи счетчиков трафика. Они собирают сведения о посещаемости ресурса. Чтобы получить более точные данные применяют анализаторы лог файлов (файлов регистрации) сайта. С их помощью выявляются ошибки в работе сервера, анализируется поток трафика. Комплексное изучение сайта позволяет специалистам узнать, почему на сайте мало трафика, причины низких позиций в выдаче и плохих показателей конверсии. Эти данные не просто собирают и анализируют, а решают с их помощью, как исправить недочеты и улучшить ситуацию.
• Сквозная веб-аналитика. Данный метод анализа позволяет веб-мастерам проследить полный путь посетителя сайта: просмотр рекламного объявления, переход на целевую страницу, выполнение действия (покупка, подписка, заполнение формы обратной связи и т. д.), повторное возвращение. Это дает возможность устанавливать точки контакта и отслеживать, какой канал привлечения посетителей наиболее эффективен.

Задачи, которые может решить веб-аналитика

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

1. Сбор и анализ информации о посетителях и их активности: количество просмотренных страниц, время, проведенное на сайте, географическое расположение.
2. Выявление источников трафика: из поискового запроса, рекламных блоков или посредством ввода прямой ссылки ресурса.
3. Аудит семантического ядра. Здесь оценивается, какие ключевые запросы были использованы, отражают ли они потребностям целевой аудитории.
4. Детальная оценка посещаемости ресурса. На этом этапе оценивается, какие страницы наиболее популярны, что привлекает пользователей больше всего: контент, контактные данные, товар. Специалист также узнает, сколько времени посетители проводят на страницах, анализирует глубину просмотра сайта, показатели отказов, маршрут по страницам и т. д.
5. Действия посетителей – какая часть пользователей последовала призыву к действиям: совершила переход по ссылке, оформила покупку, подписалась на рассылку уведомлений.

К изучению технической составляющей сайта относятся:

1. работы по определению того, какие страницы сайта были проиндексированы поисковыми роботами, а какие проигнорированы;
2. выявление наиболее успешных ключевых слов и частоты их употребления;
3. неработающие ссылки, которые ведут на несуществующую страницу или возвращают код ошибки 404.

Инструменты веб-аналитики

Основа веб-аналитики — инструменты и программы, позволяющие собрать подробную информацию и статистические данные о работе ресурса для дальнейшей интерпретации. Для сбора статистики применяются два вида инструментов: программы анализа логов и системы интернет-статистики.

• Программы лог-анализаторы. Они устанавливаются на компьютер и накапливают журнальные файлы и информацию обо всех обращениях к серверу. Задачи веб-мастера – собрать все данные и проанализировать их. Наиболее популярные лог-анализаторы: Webalizer, WebTrends.
• Системы интернет-статистики. Они представлены в виде внешних сервисов. Чтобы получить данные, нужно установить на сайт счетчик. Этот вариант сбора и анализа информации более распространен благодаря простоте и удобству использования, а также возможности получения результатов в виде графиков. Среди наиболее популярных систем интернет-статистики можно отметить Google Analytics и Яндекс.Метрику. Если вы не знаете, с чего начать работу с этими системами веб-аналитики, мы рекомендуем вам прочитать наши статьи об отчетах Метрики и GA.

Что такое веб-аналитика и зачем она вам нужна?

Несмотря на обилие технических терминов и внутренню сложность, веб-аналитика — простой и понятный в использовании инструмент. Как автомобиль: он сложно устроен, чтобы им было просто пользоваться.

Смотрите...

ПРОБЛЕМА

У вас есть сайт. Вы или продвигаете с его помощью какой-то товар/услугу, или это просто информационный ресурс. В любом случае, вам нужны качественные потенциальные клиенты (если вы что-то продаёте), или качественные посетители, если вы даёте им хороший вкусный контент.

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

Но почему-то, несмотря на ваши усилия, товар или услуга не покупается так, как вам хотелось бы. При этом вы чётко понимаете, что «это» людям надо. Или с вашего интересного инфоресурса люди быстро уходят. А если вы торгуете рекламным местом, то клиенты не платят вам за него столько, сколько могли бы.

Почему так происходит? Как определить, что «они» делают на сайте? Сколько проводят времени в том или ином разделе? Что читают внимательно, а что — нет? Откуда приходят? Когда приходят? И так далее. Вопросов много. Что, как, почему, зачем, куда, откуда... А главное — где деньги? :)

Вопросы совсем не праздные, как вы понимаете. Ответы на них жизненно важны. Зная их (ответы), вы можете чётко определить эффективность ваших рекламных действий.

Стоит ли, например, вкладывать в SEO. Стоит ли продвигаться в соцсетях. Стоит ли покупать ссылки (мы, например, их принципиально не покупаем). Работает ли в вашем случае контекстная реклама. Нужно ли участвовать в обменах баннерами. И т.д.

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

Но знаете что? Есть одна ловушка. Она называется

ЛОВУШКА ПРИВЫЧКИ

Это вот что...

Между пониманием того, что «это важно» и практическим действием — пропасть. Люди часто делают не то, что надо, а то, что привыкли. Понаблюдайте за собой. Вы (как и я) часто совершаете какие-то шаблонные действия. Когда-то это работало, а теперь вот не работает. Но мы продолжаем это делать. Привычка.

Например, вы думали, что Twitter – это какая-то игрушка. Между тем, есть огромное количество сайтов, которые прекрасно продают ТОЛЬКО через Twitter.  Или вы считали, что SEO – это очень нужно, а оказалось, что 80% ваших клиентов приходят на ваш сайт вовсе не из-за SEO, а потому что один из ваших сотрудников использует «правильную» подпись на каком-то тематическом форуме. А вы и не знали этого.

В то же время, для кого-то SEO – единственный работающий способ привлечения качественных клиентов (вот такая аудитория у них). А кто-то «выезжает» за счёт контекстной рекламы и не использует больше вообще ничего. А ещё кто-то выстраивает поток на свой сайт ТОЛЬКО через рассылку. По-всякому бывает...

А ведь ещё есть юзабилити, о котором столько говорят в последнее время. Только говорят многие (тема просто модная), а вот понимают, что и как делать — единицы. Между тем, просто изменение цвета кнопки заказа и смещение её на один (!) сантиметр может в десятки раз увеличить конверсию в покупателей. И это не шутка.

А карточка товара в интернет-магазине?.. Знаете ли вы, НАСКОЛЬКО важно соблюдать определенные правила при её оформлении? Или вы думаете, что возьмёте копи-паст описания товара с сайта производителя, и этого хватит? Пора взрослеть :). Всё гораздо сложнее.

Или вы заказали тексты на сайт, и вам (!) они нравятся — но люди их не читают. Но вы об этом можете даже не подозревать. Более того, для вас может оказаться большой неожиданностью, что КАРТИНКИ НЕ ПРОДАЮТ. Но помогают продавать (если их правильно использовать, конечно).

И так далее, и тому подобное. Мелочей здесь нет. Важно ВСЁ.

ВАЖНОСТЬ МЕЛОЧЕЙ

Сайты — это та область деятельности, гдё всё решают мелочи. Те самые «дьявольские» мелочи. Если вы уделяете им внимание, анализируете, тестируете, пробуете — у вас всё будет хорошо. Если нет — то ваш сайт превратится (если уже не превратился) в никому ненужную страницу, которая может выглядеть красиво, радовать глаз — но не продавать.

Так вот всё непросто. Но жизнь вообще сложная и несправедливая штука. Нравится нам это или нет.

И вот определением того, как работает ваш сайт, где у вас хорошо, а где плохо, почему люди уходят или остаются, откуда и как они приходят (или не приходят), что они делают у вас на сайте — как раз и занимается веб-аналитика.

РЕШЕНИЕ (и некоторые заблуждения)

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

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

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

А знаете, почему это пока что «не принято» (помимо того, что это вредная привычка)?

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

Как бы не так!

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

Подумайте об этом. Прямо сейчас.

И перейдём к вопросу

КАК ЭТО РАБОТАЕТ

Веб-аналитика — это способ понять, где и как у вас на сайте происходит «утечка» посетителей. Поняв это, заделать течь несложно. Также веб-аналитика анализирует эффективность каналов привлечения людей на сайт. Всё это даёт возможность макимально эффективно использовать сайт как канал донесения информации.

Если вы хотите, чтобы сайт приносил вам деньги, а не просто «висел» в сети — у вас нет другого пути, кроме как проанализировать его, как и любой другой канал.

Собственно, мой отдел и занимается таким анализом.

Мы используем нехитрые по сути (но технически весьма изощрённые) инструменты — юзабилити-анализ и анализ показаний счётчиков, таких как Google Analytics и Яндекс.Метрика.

Юзабилити-анализ, например, даёт нам понимание того, как человек воспринимает сайт в целом: на что он смотрит сначала, на что через три секунды, как вообще движется его взгляд (в особо «тяжёлых» случаях цепляем сотрудникам на голову датчики движения глаз — это очень помогает оперативно выяснить «утечки взгляда»).

Google Analytics позволяет нам понять источники трафика на сайт: другие сайты, рассылки, баннерообменные сети, географию, операционную систему посетителей, и т.д. Зная, как смотреть на эти чисто технические метрики, мы можем определить ОЧЕНЬ многое. Иногда даже можно определить возраст и пол пользователя (да-да, часто можно сказать это с высокой долей вероятности!). Не конкретного пользователя, конечно, но общий срез, так сказать, за какой-то промежуток времени.

Яндекс.Метрика позволяет отследить движение курсора мыши и выделить «горячие» и «холодные» зоны на сайте. Юзабилити-анализ тесно связан с показаниями Яндекс.Метрики.

Вообще говоря, это всё немного похоже на работу детектива. Есть набор метрик, понимание психологии и умение выслеживать закономерности. Используя всё это, можно поставить «диагноз» весьма точно. Как ни странно, в нашей работе немало психологии. Не глубокой психологии (научной, что ли...), а такой «поп-психологии».

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

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

И предложенный нами вариант не всегда нравится заказчику. Но тогда мы спрашиваем — вам чтобы нравилось, или чтобы деньги зарабатывало? И в 98% случаев — угадайте, что люди говорят? :)

ЧТО ДАЛЬШЕ

Надеюсь, я донёс до вас суть: что такое аналитика, зачем она нужна (как постоянный процесс, между прочим!) и что клиент получит в результате правильного анализа данных.

Теперь вы можете сделать следующее:

Ничего. Многие так и поступают. Сидеть в привычном болоте приятно. Зачем дёргаться?
Заняться аналитикой самому. Это вариант. Материалов в сети хватает, бери и пользуйся. Вопрос только в том, чтобы времени и других ваших ресурсов хватило ещё и на это. Аналитика — это ведь не «прикрутить код Google Analytics», как многим кажется.
Поручить сбор и анализ сведений кому-то другому, а потом последовать рекомендациям. На мой взгляд, самый правильный вариант. Не потому, что я хочу на вас заработать :). Просто каждый должен заниматься своим делом, только и всего.

Как поступать — решать вам.

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

Собственно, вот и всё, что я хотел сказать о веб-аналитике.

Подытожу одной фразой: веб-аналитика — это диагностика болезней, которыми болеет ваш сайт. Если хотите, чтобы он не болел — идите к доктору. Доктор принимает каждый день, тарифы внизу :).

Удачи вам, и помните: эффективная работа сайта зависит от «дьявольских мелочей». Не стоит ими пренебрегать.

Красюк Иван

Руководитель отдела коммерческой аналитики

App + Web / Habr

Ниже – перевод статьи Симо с его оценками и впечатлениями от использования.

Несмотря на неуклюжее название, это действительно отличный инструмент для всех целей и задач Google Analytics V2 или Firebase Analytics for Web. Здесь мы не говорим об очаровательном способе создания сводных отчетов между Google Analytics для Firebase и Universal Analytics, или об усовершенствовании Universal Analytics.

Нет, мы говорим о новой модели измерения веб-трафика, удачно совместимой с Google Analytics для Firebase.

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

Название Google Analytics: App + Web несколько неловкое. Мне кажется, что это просто вопрос времени, когда мы назовем его Firebase для Web или как-то в этом духе, ведь это то, чем он является по сути. В этой статье я буду называть его GAv2 в тех местах, где мне будет просто неохота печатать название полностью (да, я ленивый).

Прежде чем начать, откройте замечательный блог Кристы Сейден в новой вкладке и обратите особое внимание на три статьи, которые она опубликовала о возможностях отчетности Google Analytics: App + Web.

1. New App + Web Properties in Google Analytics
2. Pathing in Google Analytics
3. Streamview в Google Analytics.

Я начну с пары вступительных слов, поэтому, если хотите, просто пропустите их и переходите сразу к шагам по внедрению.

Предостережения

Вот некоторые моменты, которые я нашел в UI отчетов и в настройках Google Tag Manager:

• Нет специализированных отчетов, например «Отчет о поиске по сайту» или «Ecommerce»
• Нет способа различать автоматически собранные, рекомендуемые и настраиваемые события в пользовательском UI отчетов.
• Вы можете настроить ресурс пользователя, см. ниже как это сделать.
• Невозможно отправить items массив (или любой другой многомерный объект) в качестве параметра события в Google Analytics при использовании GTM.
• Задать постоянные значения в теге конфигурации в GTM, похоже, невозможно.
• Вы можете обновить существующие ресурсы Firebase Analytics в соответствии с этим документом поддержки. Когда вы откроете ресурс в Google Analytics (при условии, что вы привязали это ресурс в Google Analytics), вы увидите синий баннер в верхней части экрана, предлагающий выполнить обновление.

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

Вот, на мой взгляд, основные отличия Universal Analytics от новой платформы.

Universal Analytics:
Все строится вокруг понятия сессии
Кастомные определения hit-, session-, и user-scoped.
Поверхностные отчеты в реальном времени.
Сегменты.
Нет семантического структурирования.
Довольно благоприятные квоты и лимиты (кроме выборки).

Google Analytics V2:
Все строится вокруг понятий «пользователь» и «событие»
Пользовательские свойства и кастомные параметры событий
StreamView и DebugView обеспечивают более всестороннюю детализацию.
Аудитория.
Автоматически собираемые и рекомендуемые события.
Строгие квоты и ограничения (без выборки).

Ограничения особенно болезненны, если сравнивать их с тем, что было в Universal Analytics.

В любом случае, я уверен, что эти проблемы будут решены до того, как Google Analytics: App + Web выйдет из бета-тестирования, но одно можно сказать наверняка: это не Universal Analytics. Попробуйте взглянуть на новую модель измерений, как на возможность выйти за рамки того, что когда-либо могло предложить Universal Analytics, а не просто как на способ заполнить древнюю модель данных GA.

В связи с этими предостережениями я настоятельно не рекомендую прекращать сбор данных в Universal Analytics и собирать данные исключительно в Google Analytics: App + Web. Во всяком случае, эту новую модель измерения лучше запускать параллельно с любой настройкой, которая уже была на сайте, чтобы можно было сравнить паритет между двумя наборами данных.

Создаем новые настройки Google Analytics: App + Web

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

Шаг 1: Создайте новый проект Firebase

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

Прочитайте и примите условия Firebase, затем нажмите Сontinue.

На следующем шаге убедитесь, что установлен флажок «Set up Google Analytics for my project», и нажмите Continue.

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

После того, как вы нажмете Create project и обработка завершится, вы можете перейти в Google Analytics и найти новый ресурс App + Web в выбранной вами учетной записи.

Шаг 2. Создайте новый веб-поток

В любом случае, выберите параметр Data Streams в столбце ресурсов и выберите Web.

Чтобы настроить поток, введите URL своего сайта и дайте потоку описательное имя. Затем нажмите на маленькую шестеренку, чтобы настроить расширенные параметры измерения (the Enhanced Measurement).

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

Список вещей, которые можно автоматически отследить, довольно понятен и хорошо объяснен в конфигурации Enhanced Measurement (см. скриншот выше).

Как только вы будете готовы, создайте поток данных, и вы увидите на экране кучу инструкций по тегированию и другие моменты. Самая важная вещь, которую нужно отметить — это Measurement ID. Держите эту вкладку открытой, чтобы при необходимости вы могли скопировать ID измерения в теги Google Tag Manager.

Готово? Хорошо, теперь давайте перейдем к Google Tag Manager.

Создаем тег базовой конфигурации

Google Analytics: App + Web Configuration аналогична команде config, используемой в реализации gtag.js. Вы используете его для настройки трекера, отправки начального просмотра страницы и настройки постоянных значений для всех ваших событий.

Когда вы открываете шаблон, вас точно не приветствует множество вариантов. По сути, у вас есть поле для определения Measurement ID, переключатель для выбора, отправлять ли начальный просмотр страницы или нет, и поля конфигурации, которые вы можете установить в теге.

Чтобы настроить базовый тег, задайте его в поле Measurement ID из веб-потока, созданного в предыдущей части. Вы можете установить в поле user_id какое-то значение, которое связано с ID аутентификации пользователя, в случае, если хотите проложить путь для измерения между устройствами и приложениями.

Согласно документации, вы должны иметь возможность определять любые параметры события в полях для установки (Fields to set) тега конфигурации, если вы хотите, чтобы эти параметры события отправлялись при каждом последующем обращении, в котором используется тот же ID измерения. К сожалению, на момент написания не похоже что это работает.

Устанавливаем пользовательские свойства

Далее, перейдите в вашей конфигурации в Fields to Set и добавьте новое поле. Имя поля должно быть user_properties.

В качестве значения поля необходимо использовать пользовательскую переменную JavaScript (или шаблон пользовательской переменной), которая возвращает объект, где каждый ключ объекта соответствует имени User Property, которое вы создали в UI создания отчетов, а значение равно тому, что вы хотите отправить в качестве пользовательского свойства в вопросе.

Например, чтобы установить свойство user_type (см. скриншот выше), я могу создать переменную Custom JavaScript, которая выглядит следующим образом:

"function() { return { user_type: 'Premium user' }; }" 

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

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

Тестируем!

Файл cookie _ga почти такой же, как и в Universal Analytics, с одним небольшим отличием. _ga cookie кодирует количество частей домена в значении cookie как число после GA1. Например, если cookie записывается на simoahava.com, домен состоит из двух частей, а префикс значения cookie будет GA1.2.

Однако, с GAv2, это не похоже на использование значения cookie_domain по умолчанию (автоматическая настройка).
Я думаю, что это может быть упущение, как если бы вы вручную установили домен, например, www.simoahava.com, cookie имеет обычный GA1.3. префикс.

Другой файл cookie, _ga_MEASUREMENT-ID **, похоже, поддерживает состояние сеанса. Первое длинное число — это временная метка (в секундах), когда был создан файл cookie, а второе длинное число — это временная метка, когда в последний раз хит был отправлен в GA.

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

Для файлов cookie используется JavaScript, поэтому на них влияют меры по снижению эффективности файлов cookie на стороне клиента, такие как интеллектуальное отслеживание Safari (Safair's Intelligent Tracking Prevention).

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

Прежде всего, вы можете увидеть, что запрос отправляется на знакомую конечную точку, /collect, за исключением того, что вместо этого он находится в пути /g/.

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

API-интерфейс Beacon защищает асинхронные запросы, отправляемые при выгрузке страницы, что позволяет выполнять их, даже если браузер закрыт. Это позволяет избежать неприятностей, связанных с пропуском обращений (например, событиями, связанными с кликом на ссылку), поскольку пользователь ушел со страницы до того, как запрос был выполнен.

Если посмотреть на фактические параметры, отправленные в GA, то здесь есть много знакомых вещей, если вы помните, как строятся запросы протокола измерений.
Параметр v имеет значение 2, тогда как в Universal Analytics он равен 1. Это версия протокола.
Параметр tid установлен на ваш ID измерения.
Параметр gtm хэшируется из ID вашего контейнера GTM.
Параметр cid — это идентификатор клиента, который хранится в файле cookie _ga.

Другие параметры, которые остались практически неизменными, включают в себя такие вещи, как uid (идентификатор пользователя), dl / dr / dt (метаданные документа) и sr (разрешение экрана).

Больше нет измерения «Hit Type», вместо этого используется параметр en (event name/имя события), чтобы отличать разные типы хитов друг от друга. Это является основным отличием от Universal Analytics, поскольку в GAv2 у вас есть один единственный поток событий, где параметры события, которые вы отправляете вместе с именем события, определяют, как именно данные отображаются в отчетах.

Параметры события имеют префикс ep. или epn. для текстовых параметров и числовых параметров соответственно. На cкриншоте я создал параметр события с именем country и установил для него значение US.

Свойства пользователя имеют префикс up. или upn. для пользовательских свойств в текстовом или числовом формате соответственно. На скриншоте показано одно текстовое свойство пользователя с именем user_type, для которого установлено значение Premium user.
Наконец, параметр sid, похоже, содержит метку времени, когда начался текущий сеанс (взятый из cookie _ga_MEASUREMENT-ID).

До сих пор неясно, что делают другие параметры.

Одна вещь, которую вы могли заметить, это задержка отправки хита. Когда вы загружаете страницу, вы можете увидеть, как браузер подождет несколько секунд, прежде чем отправлять хит в GA. Это связано с тем, что GAv2 автоматически группирует запросы, что, опять же, является отличным обновлением функции.

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

Перед созданием вашего первого тега события, посмотрите, как работает Enhanced Measurement. Сначала прокрутите вниз до конца текущей страницы и взгляните на событие, отправленное в Google Analytics.

Затем кликните на ссылку, которая ведет от вашего сайта (используйте CTRL/CMD + клик, чтобы открыть ее в новой вкладке). Взгляните на параметры.

Наконец, если на вашем сайте встроен YouTube с параметром enablejsapi = 1, проверьте автоматическое отслеживание видео!

Это все невероятно круто, но я надеюсь, что мы еще получим некоторые элементы управления для настройки работы Enhanced Measurement.

Теперь, давайте создадим наш собственный тег события!

Создаем тег события

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

При создании новых событий сначала убедитесь, что событие еще не собрано автоматически.

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

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

Давайте начнем с простого пользовательского события.

Создайте новый Google Analytics: App + Web Event teg и заполните его следующим образом:

Установите для параметра Configuration Tag значение, созданное в предыдущей части. Это работает аналогично переменной настроек Google Analytics, так как вам нужно настроить параметры трекера только один раз, после чего они будут применяться ко всем тегам, которые используют тег конфигурации.

Дайте событию произвольное имя (то есть не одно из автоматически собранных или рекомендуемых событий). В этом случае мы используем data_loaded в качестве имени события.

Затем добавьте некоторые параметры:

• all_data – это пользовательский текстовый параметр, для которого установлено значение true.
• debug_mode – это параметр, который при установке в теге отображает хит в потоке DebugView UI создания отчетов (подробнее об этом ниже).

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

Как видите, в первом ряду есть хит page_view, а во втором ряду пользовательское событие data_loaded.

Теперь перейдите в UI отчетов Google Analytics и выберите DebugView в навигаторе отчетов.

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

В селекторе Debug Device в верхней части экрана вы сможете увидеть, сколько устройств (например, экземпляров браузера) в данный момент отправляют debug-хиты в GA. С помощью селектора просмотрите перечисленные устройства, пока не найдете то устройство, что недавно отправило событие data_loaded.

Этот селектор Debug Devices в настоящий момент непригоден. Надеюсь, в ближайшем будущем будет легче найти debug-устройства.

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

Вы можете кликнуть на параметры в событии data_loaded, чтобы увидеть, какой тип информации отправляется в Google Analytics с хитом.

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

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

Как видите, я просто жестко закодировал поисковое слово в параметрах события. Я запускаю тег с Custom Event Trigger, установленным для события именем search.

После обновления режима предварительного просмотра и перезагрузки моего веб-сайта я могу запустить событие с помощью простого window.dataLayer.push ({event: 'search'}), выполняемого в JavaScript-консоли страницы.

В DebugView я вижу, что событие было зарегистрировано:

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

Итоги

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

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

Я рад осторожно представить Firebase в интернете. Это то, чего я с нетерпением ждал с тех пор, как начал работать с Firebase (и Firebase Analytics) очень давно. Я думаю, что модель измерения пользователей и событий превосходит сильно агрегированную и сессионную модель, используемую Google Analytics.

Тем не менее, еще предстоит выяснить, какую часть переключения контекста нам нужно выполнить мысленно, чтобы понять, как варианты использования, рассматриваемые Google Analytics: App + Web, сопоставимы с вариантами использования Universal Analytics.

Я определенно выделю больше ресурсов для написания контента для Firebase, поскольку этот новый способ объединения аналитики приложений и веб-сайтов слишком интересен, чтобы его игнорировать.

Давайте обсудим Google Analytics: App + Web в комментариях, но помните, что мы говорим о бета-продукте. Вы можете свободно высказывать свое разочарование по поводу решений по разработке и отсутствующих функциях, но учтите, что предоставление вашей критики конструктивным образом может привести к изменениям, направленным на устранение этих критических замечаний в конечном продукте, поскольку цель бета-версии состоит в том, чтобы получить обратную связь от сообщества.

зачем она нужна вашему бизнесу?. Читайте на Cossa.ru

Сегодня мы поговорим о том, зачем сайту веб-аналитика, и что она способна изменить. Что теряют интернет-магазины, у которых не настроена электронная торговля? Что упускают сайты услуг, у которых нет интеграции с call-tracking? Итак, что же теряет или недополучает сайт в отсутствие аналитики?

Рассмотрим три наиболее распространенные ситуации, которые чаще всего встречаются на рынке.

• Вообще нет системы аналитики, или она неправильно настроена.

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

• Аналитика есть, но некому анализировать.

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

• Разовая аналитика под какие-то задачи или проекты.

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

Существует огромное множество систем аналитики, но в 90% случаев достаточно функционала Google Analytics и «Метрики» Яндекса. Лишь для очень специфических сфер бизнеса и задач могут потребоваться какие-то специализированные системы аналитики.

Например, для мобильных приложений может использоваться Google Analytics, он умеет отслеживать мобильный трафик, там также можно настроить цели и события, но все равно это неполноценная система аналитики. На помощь придут такие системы, как Kissmetrics, Flurry, MixPanel.

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

Возможности веб-аналитики

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

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

При этом на конверсию влияет множество факторов. Но аналитик может повлиять только на два их них:

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

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

Аналитика для интернет-магазина

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

Что это дает? В первую очередь так можно оценить, насколько эффективны платные рекламные каналы. Зная расходы на рекламу в Яндекс.Директе, количество полученных заказов и средний чек, можно, например, посчитать ROI и определить, окупается ли этот канал рекламы или нет. Но оценка по источникам трафика — это лишь самый верхний уровень.

Копнув глубже, можно посмотреть, какие ключевые слова приводят к продажам. По опыту 80% ключевых слов из всех рекламных кампаний на рынке вообще никак не способствуют продажам. При помощи аналитики можно выявить те самые 20% ключевиков, которые влияют на прямые продажи, и сильно сократить рекламные бюджеты, сохранив эффективность. Но не все так просто, всегда необходимо учитывать взаимосвязь каналов («ассоциированные конверсии»).

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

Для оценки влияния канала трафика на продажи существуют так называемые «Модели атрибуции». Например, у сайта три канала трафика: контекстная реклама, SEO и баннерная реклама. Каждый канал по-разному влияет на продажи. Например, баннерная реклама не приносит прямых конверсий, но в 50% случаев она участвует как источник убеждения клиентов для конечной продажи. Без нее эта цепочка разорвется, и продажи, например, в контексте упадут. При оценке стоимости привлечения клиента и стоимости конверсии можно учитывать влияние каналов с учетом различных коэффициентов. Наличие всех этих данных и специалиста, который будет регулярно их отслеживать и анализировать, позволит правильно настроить эффективное взаимодействие всех рекламных каналов.

Аналитика для сайта услуг

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

Это косвенно покажет эффективность трафика, но каждый канал конвертируется по-разному, поэтому этих данных явно недостаточно. Например, контекстная реклама может давать большое количество заявок, но с низкой конверсией, а ретаргетинговая кампания может приносить аналогичное количество заявок, но с конверсией уже не 10%, а 60%. Без более глубокой аналитики в связке с данными по продажам сложно оценить, какой канал работает эффективнее. Ведь бизнес измеряется не заявками, а продажами. Существует несколько решений для сбора подобных данных. Наиболее простой — интеграция Google Analytics с внутренней CRM/ERP-системой. Фактически любые системы, которые хранят информацию о продажах, можно интегрировать с Google Analytics.

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

Неправильные настройки

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

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

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

Автор: Дмитрий Колотов, эксперт в области стратегического развития интернет-проектов, поискового продвижения, веб-аналитики и интернет-маркетинга.

Еще больше материалов по теме в блоге iSEO.

Веб-аналитика для новичков - базовые понятия за 15 минут

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

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

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

Базовые понятия

Начнем с основных параметров аналитики. В отчётах Яндекс Метрики или Google Analytics вы регулярно будете сталкиваться с такими понятиями, как «визиты», «посетители», «просмотры», «отказы», «глубина просмотра», «достижения цели», «конверсии». Разберем, что всё это означает.

Но начнем мы с понятия трафик.

Трафик — это поток посетителей на ваш сайт.

Именно поток, как поток реки. Когда говорят, что «идет большой трафик» или про «рост трафика» — значит, на сайт приходит много посетителей, или их количество заметно выросло. Если говорят, что идет некачественный трафик, имеется ввиду, что посетители не совершают необходимых целевых действий, либо процент ошибочных переходов на сайт (показатель отказов) сильно завышен.

Просмотром (pageviews, hit) называется открытие или обновление (F5) одной любой страницы сайта.

Человек попал на ваш сайт — 1 просмотр. Крутит колесико мыши и листает эту страницу вверх-вниз — всё ещё 1 просмотр. Нажал F5 на клавиатуре или «Обновить» в браузере — это уже будет 2 просмотра. Щёлкнул на меню и попал на другую страницу вашего сайта — это 3 просмотра. Щёлкнул на внешнюю ссылку и ушёл на другой сайт — по прежнему 3 просмотра.

Кроме просмотров, посетитель может совершать на сайте определенные события (hit) — нажать кнопку «Положить в корзину», загрузить прайс-лист, отправить форму заказа или регистрации.

Чтобы система аналитики узнала о совершении события, элемент сайта (кнопка, ссылка, форма) должны с помощью JavaScript-кода отправить сообщение счётчику о наступлении такого события. То есть, для каждого события в коде сайта должны быть прописаны необходимые «тригеры», которые будут срабатывать, когда посетитель выполняет нужное действие.

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

Пока посетитель как-то взаимодействует с контентом вашего сайта, все просмотры и события записываются в один визит. Заканчивается визит, когда от посетителя не поступает новых событий в течение 30 минут. Время бездействия перед завершением сеанса можно изменить. Это бывает необходимо в тех случаях, когда на сайте длинные статьи или видео, просмотр которых занимает больше 30 минут. При стандартном тайм-ауте в 30 минут, если посетитель закрыл сайт, но вернулся на него через 20 минут — все новые просмотры и действия будут добавлены к предыдущему визиту. Исключение составляют переходы с рекламы. При каждом новом переходе с рекламы — вне зависимости от того, сколько времени прошло с последней активности этого посетителя на сайте — будет зафиксирован новый визит.

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

Посетитель — это не какой-то определенный человек, а браузер. В Google Analytics посетитель называется пользователем (User).

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

Важные показатели трафика

Как Яндекс и Гугл считают отказы

Прежде, чем идти дальше, необходимо рассказать про различия в интерпретации действий посетителей в Яндекс Метрике и Google Analytics.

Почти во всех отчётах Метрики и Analytics есть важный показатель — показатель отказов (bounce rate) в Analytics или просто отказы в Метрике. Это один из основных критериев оценки качества приходящего на сайт трафика. Хоть и называются они, практически одинаково, считаются эти показатели совершенно по-разному:

• Яндекс.Метрика считает отказом визит, который длился менее 15 секунд и за это время произошел только один просмотр. Человек перешел на сайт, понял, что это не то, что он искал, и ушёл с сайта.
• Analytics считает отказом посещение только одной страницы, без выполнения каких либо других действий. Время нахождения на странице роли не играет. Чувствуете разницу? Если у вас одностраничный сайт, то львиную долю посетителей Analytics посчитает отказом.

Изменить эту особенность Analytics нельзя. Но можно сделать событие с помощью JavaScript, которое будет через 15 секунд опрашивать браузер посетителя, и отправлять событие в Analytics. В этом случае, показатель отказов будет работать более корректно.

Что такое глубина просмотра

Второй важный показатель качества трафика — это глубина просмотра. Он показывает количество просмотров страниц в одном визите. В сводных отчётах глубина просмотра будет показывать отношение количества визитов к количеству просмотров.

Если ваш сайт состоит всего из одной страницы, то логично было бы, что глубина просмотров всегда равнялась 1. Но на практике, вы, скорее всего,будете видеть значения 1,1 – 1,3. Не удивляйтесь — это означает, что кто-то из посетителей нажимал на обновление (F5) страницы.

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

Самые важные понятия в аналитике: цели и конверсии

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

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

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

Конверсия, буквально — это переход из одного состояния в другое. В контексте аналитики конверсией называется выполнение каких-то целевых действий. Конверсии, обычно, делятся на два типа:

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

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

Те данные, которые нам интересно узнать о выбранном параметре, называются метрикой (в Яндекс Метрике) или показателем (в Google Analytics). Метрики содержат числовые значения. На скриншоте ниже, в качестве метрик, выбраны «Конверсии», «Достижения цели», «Целевые визиты», «Целевые посетители», а параметром являются страны.

Как системы аналитики собирают данные

Чтобы Яндекс Метрика или Google Analytics «увидели» ваших посетителей, необходимо в HTML-код сайта вписать код счётчика Метрики или Analytics. Можно вписать счётчики обеих систем, они не помешают работе друг друга. Код счётчика генерируется системой аналитики после регистрации и выполнения основных настроек. Регистрация и дальнейшая работа с аналитикой в Яндексе и Google бесплатны.

Сбор данных

Когда посетитель попадает на ваш сайт, браузер загружает код сайта и отображает страницу. Вместе с кодом сайта загружается и выполняет свою работу счётчик аналитики. Он записывает информацию об идентификаторе браузера из файлов куки, а также, об адресе сайта, с которого посетитель попал на страницу, и типе перехода: переход из результатов поиска, или с рекламного объявления, или из соцсетей, или прямой заход на сайт (посетитель ввел адрес сайта вручную или вызвал его из «Избранного»). Это называется источником перехода и типом источника (каналом).

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

Счётчик, также, собирает информацию обо всех действиях посетителя на сайте, считает время пребывания на каждой странице. А Яндекс Метрика может даже записывать движения мыши и скроллинг колесом и потом показывать в Вебвизоре видео действий посетителя на сайте. Это очень полезно, когда необходимо проанализировать удобство работы с сайтом. Кроме этого, счётчики собирают техническую информацию о браузере посетителя, операционной системе, разрешении экрана и т. п. Эта информация может быть полезна при анализе каких-либо проблем на сайте.

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

Обработка данных и построение отчётов

Следующее серьёзное отличие между системами аналитики Яндекса и Google заключается в структуре аккаунта и обработке данных, поступающих от счётчиков.

Аккаунт Google Analytics имеет иерархическую древовидную структуру, может объединять в себе несколько ресурсов с разными счётчиками. Внутри каждого ресурса может быть несколько, так называемых, «представлений», т.е., вариантов настройки и фильтрации данных с сайта.

После создания аккаунта в Analytics у вас будет один ресурс и одно представление «Все данные». Это представление крайне не желательно трогать. В случае необходимости внесения каких-то изменений в базовые настройки представления, лучше создать новое и сделать все изменения в нём.

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

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

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

Как анализировать информацию

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

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

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

Работа с отчётами

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

Щёлкнув по нужному счётчику, вы попадете в основной интерфейс Метрики. По умолчанию, открывается отчёт «Сводка».

1. Меню
2. Название счётчика и его номер
3. Выбирайте нужный период времени
4. Кнопки добавления виджетов в Сводку
5. Блоки самих виджетов
6. Настройка виджетов
7. Второй вариант настройки  — возможность перетащить блок в другое место, захватив маленький квадратик мышкой

Клиентские системы аналитики / Habr

Представьте, что вы начинающий предприниматель, который только что сделал сайт и мобильное приложение (например, для магазина пончиков). Вы хотите подключить пользовательскую аналитику с небольшим бюджетом, но не знаете как. Все вокруг пользуются Mixpanel, Facebook analytics, Яндекс.Метрику и другими системами, но непонятно, что выбрать и как пользоваться.

Что такое системы аналитики?

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

Зачем это нужно?

Пользовательская аналитика нужна:

• чтобы мониторить, что происходит при использовании сервиса;
• чтобы менять контент, и понимать, куда развиваться, какие фичи добавлять/убирать;
• чтобы найти, что не нравится пользователям, и менять это.

Как это работает?

Чтобы изучать поведение пользователей, нужно собирать историю этого поведения. Но что именно собирать? Этот вопрос составляет до 70% сложности всей задачи. На него должны вместе ответить многие участники продуктовой команды: продакт менеджер, программисты, аналитики. Любая ошибка на этом шаге стоит дорого: можно не собрать то, что нужно, и собрать то, что не позволит сделать значимые выводы.

После того, как определились, что собирать, нужно продумать архитектуру того, как это собирать. Основной объект, с которым работают аналитические системы — это ивент. Ивент — это описание того, что произошло, которое отправляется в систему аналитики в ответ на действие пользователя. Как правило, для каждого из действий, выбранных для треккинга на предыдущем шаге, ивент выглядит как JSON-пакет с полями, которые описывают совершенное действие.

JSON-пакет это текстовый файл, который описывает, что произошло. Например, JSON-пакет может содержать информацию о том, что пользователь Mary совершил действие Started game в момент времени 23:00 15 ноября. Как описать каждое действие? Например, пользователь нажимает на кнопку. Какие свойства нужно собрать в этот момент? Они делятся на два вида:

• super properties — свойства, характерные всем ивентам, которые присутствуют всегда. Это время, девайс айди, версия апи, версия аналитики, версия ОС;
• event specific properties — эти свойства произвольны и основная сложность в том, как их подобрать. Например, для кнопки «купить монетки» в игре такими свойствами будут «сколько монеток купил пользователь», «сколько стоили монетки».

Пример JSON-пакета в сервисе по изучению языков:

Но почему бы просто не собирать все подряд?

Потому что все ивенты создаются вручную. В системах аналитики нет кнопки «сохранить все» (и это было бы бессмысленно). Собираются только те действия из логики сервиса, которые интересны какой-то части команды. Даже на каждое состояние кнопки или окошка обычно интересуют не все ивенты. Для длительных процессов (например, уровень игры) могут быть важны только начало и конец. Что происходит в середине, при этом может не собираться.
Как правило, логика сервисов состоит из объектов — сущностей. Это могут быть сущность «монетка», сущность «уровень». Поэтому можно составлять ивенты из сущностей, их состояний и действий. Примеры: «уровень начался», «уровень закончился», «уровень закончился, причина — съеден драконом». Желательно, чтобы все сущности, которые могут быть «открыты», закрывались, чтобы не нарушать логику и не усложнять себе дальнейшую работу с аналитикой.

Сколько ивентов в сложной системе?

Сложные системы могут обрабатывать несколько сотен ивентов, которые собрали со всех заказчиков (продакт менеджера, программистов, аналитиков) и аккуратно (!) занесли в табличку, а потом в логику сервиса. Подготовка ивентов — это большая междисциплинарная работа, требующая от всех понимания того, что нужно собрать, внимательности и аккуратности.

Что дальше?

Допустим, мы придумали все интересные ивенты. Пришло время их собирать. Для этого нужно подключить клиентскую аналитику. Заходим в гугл и ищем mobile analytics (или выбираем из известных: Mixpanel, Яндекс.Метрика, Google Analytics, Facebook analytics, Tune, Amplitude). Берем с сайта SDK и встраиваем в код своего сервиса (отсюда же название «клиентская»‎ — потому что SDK встраивается в клиент).

И куда собирать ивенты?

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

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

Сколько займет подключение?

Самую простую аналитику можно подключить за час: это будет App Metrika, которая покажет самые простые вещи без анализа кастомных ивентов. Время настройки более сложной системы зависит от выбранных ивентов. Возникают сложности, которые требуют дополнительной разработки:

• Есть ли очередь ивентов? Например, как зафиксировать, что один ивент не может прийти раньше другого?
• Что делать, если пользователь перевел время? Сменил часовой пояс?
• Как быть, если нет интернета?

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

Как выбрать, какая нужна мне?

Общая статистика во всех аналитических системах работает отлично. Хорошо подходит для маркетологов и продажников: можно посмотреть ретеншн, сколько пользователи провели в приложении, все базовые высокоуровневые метрики. Для самой простой landing page будет достаточно Яндекс метрики.

Когда дело доходит до нестандартных задач, выбор зависит от вашего сервиса, аналитических задач и ивентов, которые нужно обрабатывать для их решения.

• В Mixpanel, например, можно проводить A/B тесты. Как это сделать? Создаешь эксперимент, в котором будет несколько выборок и делаешь селекцию (относишь в А таких-то пользователи, в B — других). Для A кнопка будет зеленой, для B — голубой. Так как Mixpanel собирает все данные, она может найти device id каждого пользователя из A и B. В коде сервиса, используя SDK, создаются tweaks — это места, в которых что-то может меняться для тестирования. Далее, для каждого пользователя значение (в нашем случае цвет кнопки) подтягивается из Mixpanel. Если подключения к интернету нет, будет выбран дефолтный вариант.
• Нередко хочется не просто складировать и изучать ивенты, но и агрегировать пользователей. Та же Mixpanel делает это автоматически, во вкладке Users. Там можно просмотреть все постоянные user данные (имя, email, facebook профиль) и историю логов пользователя. Можно посмотреть на данные пользователя как статистику: 100 раз съел дракон, купил 3 цветочка. В некоторых системах агрегацию по пользователям можно скачать.
• В чем основная крутость Facebook analytics? Она объединяет посетителя сервиса с его фейсбук профилем. Поэтому можно узнать свою аудиторию, а главное, затем конвертировать ее в рекламную аудиторию. Например, если я 1 раз зашел на сайт, и его владелец включил рекламу (autofillable audience в фейсбук аналитике) на посетителей, то в будущем я увижу в фейсбуке рекламу этого сайта. Для владельца сайта это работает просто и удобно, нужно лишь не забыть поставить daily cap на рекламный бюджет. Минус фейсбук аналитики в том, что она не особенно удобная: довольно сложный, не сразу понятный сайт, работает не очень быстро.

Почти ничего не нужно делать и все работает! Наверное, есть и минусы?

Да, и один из них в том, что обычно, это дорого. Для стартапа может быть около $50k в месяц. Но есть и бесплатные варианты. Яндекс App Метрика бесплатна и подходит для самых базовых метрик.

Однако, если решение недорогое, то аналитика будет не подробной: можно будет посмотреть тип девайса, ОС, но не конкретные ивенты, и нельзя будет создавать воронки. Mixpanel может стоить 50к долларов в год (например, приложение с Ам Нямом, может столько съедать). В целом, во всех доступ к данным довольно часто ограничен. Свои модели не попридумываешь и не позапускаешь. Оплата обычно проводится помесячно / попериодно.

Еще какие-то?

Но самое плохое, что даже Микспанель объемы данных, свойственные активному мобильному приложению, считает как приближение (открыто указано прямо в документации). Если сравнить результаты с серверной аналитикой, значения будут расходиться. (О том, как создать собственную серверную аналитику, читайте в нашей следующей статье!)

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

Также, часто не хватает возможности сложных агрегаций и сегментаций. Например, хитрый групбай «объединить пользователей, которые родились в 1990 году и купили не меньше 50 пончиков каждый»‎ может быть недоступен.

Facebook аналитика имеет очень сложный интерфейс и работает медленно.

А если включу все системы сразу?

Отличная идея! Нередко бывает так, что в разных системах получаются разные результаты. Разные числа. К тому же, в одних есть один функционал, во вторых — другой, третьи бесплатные.
Помимо этого, несколько систем можно включить параллельно для тестирования: например, чтобы ознакомиться с интерфейсом новой и постепенно перейти на неё. Как и в любом деле, здесь нужно знать меру и подключать аналитику в таком объеме, за которым можно будет уследить (и который не будет тормозить сетевой коннекшн).

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

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

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

Смотрите также

• 
  Арматура 25г2с что это такое
• 
  С2Н5Он что это такое
• 
  Гипохромия эритроцитов что это такое причины
• 
  Био пух что это такое
• 
  Лаунчер что это такое на компьютере
• 
  Цимес что это такое в переносном
• 
  Потрафлять что это такое
• 
  Дамп карты что это такое
• 
  Дискорд что это такое
• 
  Мезоботокс что это такое
• 
  Погибшее плодное яйцо и непузырный занос что это такое