Создание отчета по группе счетчиков

В этой статье мы научимся объединять созданные счетчики в Яндекс.Метрике по определенным типам с использованием меток (прошу не путать с UTM-метками).

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

Создание

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

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

1. Создание новой метки для выбранного счетчика. Выполняется нажатием на кнопку +Новая метка с указанием названия новой метки.
2. Объединение выбранного счетчика с уже созданной меткой. Для объединения присвоения счетчика к метке достаточно поставить галочку напротив уже созданной метки.

Статистика

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

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

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

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

Для удобства маркетологов и аналитиков в интерфейсе Метрики доступна кнопка Быстрый доступ. Кнопка позволяет создать отдельную вкладку для определенной метки и в один клик вызывать информацию по группе счетчиков.

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

Вопросы

1. Какая функция позволяет создать метку в отдельную вкладку?

а. Быстрое размещение;
б. Быстрый доступ;
в. Добавить в панель.

Посмотреть ответ

Правильный ответ: б.

2. Какой стандартный отчет не доступен в сводных отчетах по счетчикам объединенных одной меткой?

а. Посещаемость;
б. Конверсии;
в. Поисковые системы.

Посмотреть ответ

Правильный ответ: б.

3. Возможно ли восстановить удаленную метку?

а. Да, возможно;
б. Да, если метка объединяет более 10 счетчиков;
в. Нет, после удаления восстановление невозможно.

Посмотреть ответ

Правильный ответ: в.

Остались вопросы по настройке Яндекс.Метрики? Задавайте в комментариях ниже или пишите мне на личную почту [email protected]. С удовольствием готов обсудить и помочь с решением вопроса.

Что важного в диджитал на этой неделе?

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

Узнать подробнее →

Метки #аналитика

Опубликовано 13/03/201810/07/2022

Яндекс‑метрика для анализа посещаемости и посетителей сайта

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

• Яндекс‑метрика

• Гугль‑аналитика

Для сбора статистики на сайт встраиваются счётчики — маленькие кусочки кода, которые собирают статистику и показывают её владельцу сайта. Самые популярные счётчики — это Яндекс‑метрика и Гугль‑аналитика.

• Яндекс‑метрика

• Гугль‑аналитика

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

Установка Яндекс‑метрики

Счётчик устанавливается на сайт за несколько шагов:

Использование

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

Сразу после установки счётчика все значения будут нулевые, информация появится по мере посещения сайта людьми

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

Сразу после установки счётчика все значения будут нулевые, информация появится по мере посещения сайта людьми

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

В левом меню есть отчёты по всей статистике, которую соберёт счётчик. Там много интересного, от источников трафика до демографии и интересов ваших посетителей.

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

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

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

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

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

Карта скроллинга страницы школы. Посетители задерживаются на отзывах и изучают студентов рейтинг внизу страницы

Школа Яндекс‑метрики. Видеоуроки

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

Школа Яндекс‑метрики. Видеоуроки

ГТМ — менеджер тегов Гугля

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

ГТМ — менеджер тегов Гугля

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

P. S. Это был совет о веб‑разработке. Хотите знать всё о коде, тестах, фронтенд‑разработке, цеэсэсе, яваскрипте, рельсах и джейде? Присылайте вопросы.

Веб‑разработка

Отправить

Поделиться

Поделиться

Запинить

Твитнуть

Свежак

Метрики успеха против встречных метрик: зачем вам и то, и другое

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

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

Метрики счетчика гарантируют, что этого не произойдет. Вот как.

Показатели успеха определяют наши усилия

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

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

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

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

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

Кажется разумным, не так ли? Но что, если все это обернется против вас?

Приоритизация метрик всегда имеет последствия

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

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

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

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

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

Это может быть огромной победой, а может быть и катастрофой.

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

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

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

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

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

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

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

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

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

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

Всегда помните о продукте в целом

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

О Джозефе Пачеко

Джозеф является основателем App Boss, источника знаний для людей с идеями (с небольшим или нулевым техническим образованием), чтобы превратить свои приложения в жизнеспособный бизнес. Он занимается разработкой приложений почти столько же, сколько существует App Store, — он носил все шляпы от штатного инженера до менеджера по продукту, UX-дизайнера, основателя, создателя контента и технического соучредителя. Он также дал технические интервью 1400 инженерам-программистам, которые впоследствии заняли должности в Apple, Dropbox, Yelp и других крупных компаниях Bay Area.

---

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

Преимущества счетчиков Prometheus

Цзя Сюй

21 января 2022 г. • 4 мин чтения

Prometheus имеет четыре метрических типа, среди которых два основных — счетчик и калибр.

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

Когда вы начнете запрашивать счетчики, вы сразу заметите, что вам всегда нужно применять функцию rate() , чтобы использовать их. Grafana даже пытается напомнить вам об этом.

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

 rate(http_request_total[5m]) 

Для задержки вам нужно написать еще более длинное выражение:

 rate(http_request_duration_microseconds_sum[5m])
/
скорость (http_request_duration_microseconds_count [5 м]) 

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

В этом блоге мы попытаемся ответить на этот вопрос и объяснить, почему мы рекомендуем использовать счетчики Prometheus для вашего решения по мониторингу.

Как известно, система мониторинга обычно состоит из клиентов и серверов. Клиенты собирают метрики по отслеживаемым программным или аппаратным компонентам. Серверы собирают метрики от клиентов и выполняют агрегирование по клиентам и времени. Связь клиент-сервер может быть либо проталкиванием от клиента, либо получением от сервера.

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

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

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

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

Во-первых, это упрощает работу с клиентами. Все, что делает клиент, — это увеличивает значение счетчика для каждого события. Он не делает никаких других расчетов.

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

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

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

Например, если нам нужно знать частоту запросов для каждого задания, мы можем сделать:

 суммировать по (задание) (скорость(http_request_total[5m])) 

Если нам нужно знать частоту запросов для каждого URL-адреса endpoint для конкретного задания, мы можем сделать:

 sum by (url) (rate(http_request_total{job=”foo”}[5m])) 

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

 sum by (job) (rate(http_request_duration_microseconds_sum[5m]))
/
сумма по (работе) (скорость(http_request_duration_microseconds_count[5m])) 

Для коэффициента ошибок сервера мы можем написать:

 сумма по (работе) (скорость(http_request_total{status_code="5.*"}}[1h]))
/
sum by (job) (rate(http_request_total[1h])) 

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

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

 гистограмма_квантиль (
   0,99,
   sum(rate(http_server_requests_seconds_bucket[1m]) > 0) по (le, job)
) 

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

Хотя реализация клиента значительно упрощена, некоторые сложности ложатся на сервер. В частности, как обработать случай, когда клиент перезагружается и счетчик сбрасывается в 0?

Функция Prometheus rate() автоматически обрабатывает это путем экстраполяции. Не вдаваясь в подробности, можно предположить, что он обнаруживает снижение счетчика и экстраполирует промежуточный курс, что, однако, подразумевает, что:

• Реализация rate() не может напрямую использовать разницу между начальным значением и конечное значение.