Школа аналитиков, урок 2: разработка и внедрение системы метрик

Материалы для скачивания

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

Помимо разработки собственного продукта, OWOX BI занимается консалтингом в сфере аналитики и созданием индивидуальной системы метрик. Мы изучим ваши бизнес цели, составим список необходимых параметров и показателей, а также техническое задание для их внедрения. Поможем правильно настроить Google Tag Manager и Google Analytics.

Содержание

бонус для читателей

Видео докладов с конференций: Analyze, GoAnalytics и Ecommerce

Скачать материал

Что такое система метрик и зачем она нужна

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

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

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

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

Какие бывают взаимодействия с сайтом

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

Пример Ecommerce-сайта

Условно все взаимодействия пользователей с сайтом можно разделить на две группы:

  • Загрузка страницы либо экрана в мобильном приложении.
  • Какие-либо события (клик, прокрутка страницы, нажатие на кнопки и т. д.).

Как подготовить систему метрик

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

  1. Собрать бизнес-требования. То есть узнать, для чего заказчик (или ваш работодатель) хочет внедрить систему метрик и какая у него основная бизнес-задача.
  2. Определить основные признаки и KPI бизнеса, для которого вы создаете систему метрик.
  3. Сгруппировать страницы сайта по типам.
  4. Составить список событий, которые будут отслеживаться на каждом типе страниц.
  5. Сгруппировать однородные события.
  6. Определить и подсчитать пользовательские параметры.

Рассмотрим детальнее каждый этап.

1. Сбор бизнес требований

Бизнес-требования могут звучать примерно так: «Хотим увеличить доход с сайта в 5 раз», «Хотим снизить стоимость привлечения пользователей» или «Хотим увеличить LTV пользователя». После того, как выяснили бизнес-требования, необходимо преобразовать их в аналитические задачи, решив которые, можно сформулировать гипотезу, проверить ее и выдать рекомендации.

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

Вопросы, которые помогут собрать бизнес-требования, и примеры ответов:

Какие задачи бизнеса решаем? Оценить эффективность рекламных кампаний, увеличить бюджет, сократить расходы, оптимизировать работу сайта
Как будем оценивать результат?Сравнение до и после, A/B тест
Какие ожидаемые сроки реализации?Неделя, месяц, год...

Далее нужно выяснить тип и этап развития бизнеса. От этого зависят метрики, которые необходимо собирать. К примеру, для Ecommerce важны покупки, для банков — заявки на сайте, а для игровых бизнесов — время, которое пользователь провел на каждом уровне.

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

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

2. Определение основных признаков и KPI

Разобравшись с особенностями бизнеса, переходим к определению основных KPI, которые будем отслеживать в будущем, и под которые нам нужны те или иные параметры.

Какую информацию можно и нужно собирать для более детального анализа?

  • Тип страницы.
  • Категория.
  • Количество товаров на странице.
  • Цена.
  • Сумма скидки.
  • Стоимость доставки.
  • Номер позиции товара в блоке.
  • Производитель товара.
  • Цвет.

Для каждого типа бизнеса на каждом этапе важны разные KPI. Их условно можно разделить на 4 основных группы:

  • Маркетинговые KPI — сюда относятся все метрики, которые показывают стоимость и эффективность привлечения пользователей (ROAS, CPC, CPA, LTV).
  • KPI по продажам, если мы говорим о Ecommerce-сайте — количество продаж, прибыль и т. д.
  • Продуктовые KPI, то есть взаимодействие с сайтом, приложением, продуктом — глубина просмотра, время на сайте и пр.
  • Технические KPI важны, например, для онлайн-бирж, бизнесов, которые работаю со ставками — скорость загрузки страниц, показатель отказов, время, когда сайт не работает и т. д.

3. Группировка страниц сайта по типам

Следующий этап подготовки системы метрик — это группировка страниц сайта по типам. Зачем выделять типы страниц в системе метрик, если у нас есть URL-адреса, которые передаются и по которым можно строить отчеты? Так гораздо проще систематизировать данные.

Например, если говорить о карточках товаров, то для каждой карточки это будет уникальный URL, где мы должны будем какими-то изощренными скриптами выделять «URL содержит то-то», чтобы понять, что это карточка товаров, а не каталог. А благодаря группировке аналитикам, которые строят отчеты и SQL-запросы, гораздо проще обращаться к данным по отдельным типам страниц.

Пример группировки страниц для Ecommerce-бизнеса:

  • Main — главная страница (пример: http://www. site. com/).
  • Portal — узловая страница, портал (пример: http://www. site. com/phones).
  • Catalog — каталог (пример: http://www. site. com/phones/mobile).
  • ProductPage — карточка товара (пример: http://www. site. com/phones/mobile/74643).
  • Checkout — оформление заказа (пример: http://www. site. com/checkout)
  • ThankYouPage — страница «Спасибо за заказ» (пример: http://www. site. com/checkout/success/).
  • ComparisonList — страница сравнения (пример: http://www. site. com/comparison/).
  • WishList — лист желаний (пример: http://www. site. com/wishlist/).
  • Profile — личный кабинет (пример: http://www. site. com/search/profile/account/).
  • InfoPage — информационная страницы (пример: http://www. site. com/delivery/)
  • ErrorPage — страница ошибки (пример: http://www. site. com/%D0%B0%D0%B2%D1%8B/).

4. Список событий по типам страниц

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

Разработчику нужна четкая структура и понятное ТЗ. Если ему сказать: «Отправь мне событие по клику на кнопку „Оставить отзыв“», он не будет искать по всему сайту эту кнопку. Он спросит, где ее найти.

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

Какие бывают события

При разработке системы метрик важно помнить, что есть два основных типа событий:

  • Активные — требуют взаимодействия пользователя с сайтом (клики, скролл страницы, заполнение формы).
  • Неактивные — не требуют действий пользователя, возникает по внутреннему сценарию, который заложил программист (например, всплывающие окна).

5. Группировка однородных событий

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

Основные примеры событий, которые можно и нужно «схлопнуть»:

  • Добавление товара в корзину.
  • Добавление в список желаний.
  • Клик по товару.

6. Определение и подсчет пользовательских параметров

И последнее, что мы делаем при подготовке системы метрик — определяем и подсчитываем пользовательские параметры.

Какие бывают параметры в Google Analytics:

  • Стандартные параметры, которые собираются по умолчанию. Как правило, это геоданные (страна, город, регион), названия товаров, тип пользователя (новый или вернувшийся) и т. д.
  • Пользовательские параметры, сбор которых необходимо настраивать дополнительно. В бесплатной версии GA можно собирать 20 кастомных параметров и 20 показателей, а в GA 360 — 200 параметров и 200 показателей. Это как правило более специфические параметры, характерные для конкретного бизнеса, например, тип страницы, атрибуты товаров, их наличие на складе и т. д.

Примеры собираемых параметров:

СтандартныеПользовательские
'name': 'T-Shirt',
'id': '12345',
'price': '15.25',
'brand': 'Google',
'category': 'Apparel',
'variant': 'Gray'
'pageType': 'ProductPage','
productId': 209044,
'productPromo': 'none',
'productPriceLocal':1368,
'productCategoryName': 'Минеральные вещества',
'productAvailability': 'есть на складе'

RoadMap внедрения системы метрик на сайт

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

RoadMap внедрения системы метрик на сайт

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

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

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

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

Преимущества такого подхода к внедрению аналитики

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

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

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

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

Нужно ли собирать все-все действия пользователя?

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

  • Технически сайт будет работать медленнее и бизнес будет терять пользователей.
  • В бесплатной версии GA данные в отчетах могут семплироваться. То есть вместо 100% данных система анализирует, допустим, только 20% и говорит что полученные результаты релевантны для всех данных. Чем ниже процент выборки, тем сложнее доверять таким отчетам. Поэтому мы не советуем перегружать бесплатную версию GA не очень нужными событиями.

Не пропустите! В следующей статье мы расскажем о модуле расширенной электронной торговли (Enhanced Ecommerce) в Google Analytics. Вы узнаете, как подготовить ТЗ для сбора данных через DataLayer, а также какие есть способы передачи данных в GA.

Если вам нужна помощь с созданием системы метрик и настройкой веб-аналитики, специалисты OWOX BI готовы вам помочь!

Заказать настройку аналитики