Прозрение по метрикам: как я понял, что такое метрики и в чём их главная прелесть / Хабр

Содержание
  1. Введение
  2. Что ещё почитать на эту тему
  3. Как определить, что метрика плохая?
  4. 100 км/ч ?
  5. Ltv и cac — две ключевые метрики продукта
  6. Omtm (one metric that matters)
  7. Qa и бизнес
  8. Unit-экономика — это продукт
  9. А какие метрики тогда хорошие?
  10. Дашборды
  11. Для чего нужна маркетинговая аналитика?
  12. Еще несколько лайфхаков по unit-экономике
  13. Иерархия метрик в организации
  14. Как выбирать метрики
  15. Как подступиться к метрикам в целом?
  16. Как составить свой набор метрик?
  17. Как структурировать показатели?
  18. Ключевые принципы построения правильной аналитики в маркетинге
  19. Ключевые продуктовые метрики
  20. Когда качество и бизнес не дружат
  21. Критерий “слащавости” метрик
  22. Летим дальше
  23. Лечим грусть
  24. Метод aarrr / pirate metrics
  25. Метрики и дашборды устаревают
  26. Метрики на разных стадиях проекта
  27. Много багов в биллинге
  28. Монетизация
  29. Обрастаем жиром
  30. Оповещения
  31. Падение количества звонков в колл-центре
  32. Пирамида метрик для метрики роста (north star) на примере ozon
  33. Привлечение
  34. Пример метрик в команде online
  35. Примеры оповещений
  36. Растём
  37. Рекомендации
  38. Сколько нужно оповещений и как часто?
  39. Стартап
  40. Трудности
  41. Удержание
  42. Упала конверсия
  43. Ценность inside
  44. Итоги
  45. Заключение

Введение

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

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

Что ещё почитать на эту тему

Тема метрик стала популярна на волне движения Lean Startup, поэтому лучше всего начать чтение с первоисточников — книг “Lean Startup” (перевод на русский — “Бизнес с нуля. Метод Lean Startup” на Ozon) и “Lean Analytics” (перевода нет, но книга на английском продается на Ozon).

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

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

На этом всё.

Если статья помогла Вам лучше понять суть вопроса, автор будет признателен за “лайк” и перепост.

Как определить, что метрика плохая?

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

Скажите, пожалуйста, что обозначает скорость…

100 км/ч ?

Хм…

Хм…

Так что же она обозначает?

Думаю, Вы, наверное, и сами догадались, что… ничего не обозначает!

Ок. Теперь второй вопрос:

100 км/ч это хорошо или плохо?

Хм…

Ни то ни другое?

Верно!

Скорость — совершенно бесполезная и бестолковая метрика. Если, конечно, её использовать саму по себе. В купе с другими метриками она, конечно, может что-то сказать, но сама по себе — точно нет.

Посещаемость сайта — ровно та же самая скорость.

Именно поэтому зависать перед графиком посещаемость сайта нет совершенно никакого смысла. Он не раскроет Вам тайну жизни. Понимаете теперь?

Ltv и cac — две ключевые метрики продукта

В отличие от метрик роста LTV и CAC — метрики, которые в конечном итоге определяют финансовую успешность продукта.

LTV (Live Time Value) — деньги, которые средний пользователь тратит в вашем продукте за все время его использования.

CAC (Customer Acquisition Cost) — ваши затраты на привлечение среднего пользователя.

Вовлеченность описывается следующими этапами в жизненном цикле пользователя:

  1. Активация в приложении
  2. «Залипание» в приложении, или активность использования
  3. Возвращаемость, т.е. сколько пользователей продолжают использовать продукт спустя месяц, два и так далее после регистрации

Монетизация же описывается следующей последовательностью этапов жизненного цикла пользователя:

  1. Активация в приложении
  2. Увидел продающий экран
  3. Совершил 1 покупку
  4. Совершил 2 покупку и т.д.

Omtm (one metric that matters)

Давайте рассмотрим пример.

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

Качество — это не только количество ошибок. Если смотреть на качество в целом, то это:

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

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

Такой подход называется OMTM (One Metric That Matters) — Одна (Единственная) Важная Метрика.

ОМТМ качества ПО логично выбрать количество серьезных (важных и критических) инцидентов в промышленной среде.

Для интернет-магазинов над OMTM вообще думать не надо — это объем продаж или прибыль (в зависимости от Вашего решения).

Эта Одна Важная Метрика и будет основной ценностью для Вашего набора метрик. И именно от неё будет зависеть их финальный набор.

Qa и бизнес


Наконец, рассмотрим на кейсах связку QA и бизнеса.

Unit-экономика — это продукт

Существует простая формула для расчета выгодности продукта:

А какие метрики тогда хорошие?

Например, Churn rate. Эта метрика говорит сколько клиентов ушло из компании/сайта навсегда с течением времени.

Churn rate = 1% говорит, что мы теряем всего 1% клиентов. Т.е. почти никого не теряем.

Если же Churn rate = 90%, то это означает, что мы теряем почти всех своих клиентов. Это ужасно!

Видите отличие этой метрики от скорости?

Churn rate — наполненная смыслом метрика, которая отвечает на вопрос, хорошо это или плохо. И Вам не нужно гадать, что она обозначает.

Это метрика, говорящая сама за себя!

И теперь мы готовы предпринять срочные действия, чтобы уменьшить отток клиентов.

Именно поэтому такие метрики называют действенными. Потому что они побуждают к действию.

Дашборды


У нас множество дашбордов, только активных технических сейчас около 30, а общих около 100.

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

Разбивка багов по критичности

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

Разбивка багов по собственным полям

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

Есть такой же срез по командам, людям, направлениям. Это позволяет смотреть самые разные срезы.

Соотношение новых и закрытых багов

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

Тренд по багам за период

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

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

Этапы нахождения багов

Если раньше мы измеряли только баги в бою, то сейчас стремимся, чтобы багов в бою не было совсем, и строим срезы на разных этапах: бой, релиз, тестирование, автоматизация, ревью, требования.

Дашборд автоматизации

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

Здесь отражается количество пропущенных багов. Если у вас покрытие 90%, но на самом деле половина из багов просто закомментирована или пропущена, то это весьма критично, потому что в действительности верно работает только 50% функциональности.

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

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

Кроме того здесь отражаются данные по срезу статусов:

  • New — новая функциональность.
  • Need correction — нужно апдейтить кейс.
  • Not need — не хотим покрывать автоматизацией.
  • Done — покрыто.

На критичность тоже есть свой срез.

Дашборд Performance

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

Это все накладывается на различную функциональность, разные страницы сайта.

Для чего нужна маркетинговая аналитика?

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

  • Насколько эффективно расходуется маркетинговый бюджет?
  • Какой ROMI дают разные маркетинговые каналы?
  • Какая целевая аудитория наиболее эффективно конвертируется?
  • Какие каналы коммуникаций наиболее / наименее прибыльны?
  • Что является наибольшим источником дохода компании?

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

Еще несколько лайфхаков по unit-экономике

Готовые сервисы

. Если Вы введёте в Яндексе “Unit-экономика калькулятор”, то легко найдёте сайты, где Вам нужно будет вбить только цифры для подсчёта маржинальной прибыли.

Отдельные каналы

Иерархия метрик в организации

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

Для решения этой задачи имеет смысл декомпозировать цели компании и соответствующие им метрики на разные уровни. Зачастую каждый следующий уровень соответствует отделу компании и является KPI этого отдела. Упрощенно, мы можем представить главную верхнеуровневую цель компании — Прибыль и декомпозировать ее на составные части: Выручка, Расходы.

Хороший пример — школа английского языка SkyEng, на видео можно ознакомиться с детально проработанной структурой метрик SkyEng.

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

Как выбирать метрики

Выбирать метрики можно по трем принципам.

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


При

целевом подходе

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

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

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

Дополнительный анализ:  Гуманитарий и технарь: профессии для разных типов мышления

Как подступиться к метрикам в целом?

Первым делом нужно перевернуть мозг.

Без шуток.

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

Метрики — это просто как обычная линейка с помощью которой мы измеряем все, что хотим.

Вы же не ищете причину бытия в обычной деревянной линейке, верно?

Поиск смысла жизни в линейке — это то, что называется “подход снизу-вверх”.

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

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

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

Вдумайтесь в эти слова.

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

Такой подход ещё называют “Гипотеза->Измерение”.

Ок, с этим понятно.

Вопрос № 2: “А что именно измерять? Как найти правильные метрики?”

Как составить свой набор метрик?

Полазив по Интернету Вы наверняка найдете десятки, а то и сотни различных метрик на одну и ту же тему.

Например, метрик качества ПО можно найти около сотни. Это и стандарты ГОСТР-ИСО, и метрики, рассчитываемые в SonarQube, и какие-то самописные варианты, и даже “качественные” метрики, основанные на отзывах пользователей.

Так какие же стоит использовать, а какие нет?

Самый лучший подход — руководствоваться “основной ценностью”.

Как структурировать показатели?

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

В жизненном цикле клиента можно выделить основные этапы:1) Охват аудитории — работа маркетолога начинается еще до того момента, как потенциальная аудитория становится клиентами компании2) Вовлечение — этап конверсии зашедших пользователей на сайт / в мобильное приложение в зарегистрированных клиентов3)

Ключевые принципы построения правильной аналитики в маркетинге

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

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

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

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

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

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

Ключевые продуктовые метрики


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

На что должен смотреть Product-менеджер:

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

Одна из ключевых задач Продакт менеджера — правильно определить из метрик главные. Например, задачка — есть 2 проекта:

  • Проект А принесет 100 MNU
  • Проект B сократит MCU на 100
  • Мы ожидаем, что пользователи схожие: те же привычки, те же объемы потребления
  • Проекты одинаковы по сложности, стоимости, времени и рискам.


Какой проект вы выберите и почему?

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

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

Когда качество и бизнес не дружат


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

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

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

Во-вторых, бывает другой случай —

бизнес без качества

. В IT-компании может даже быть отдел тестирования, но если QA имеет слабый вес или существует в виде monkey testing, который просто подчищает регрессию и на этом останавливается, то качество это не особо повысит.

NB: QA на самом деле — это не тестирование, а общий подход на уровне компании к тому, как вы делаете хорошие продукты.


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

Для объективной оценки нужны метрики, которые бы показывали:

  • Факт проблем. Что у вас в принципе есть проблемы, а если проблем нет, надо их поискать более тщательно. Скорее всего, они где-то есть, просто вы их еще не видите.
  • Факт результатов. Проекты создаются, чтобы заработать денег, выйти на рынок, увеличить конверсию. Эти результаты нужно отслеживать.
  • Текущее состояние. Где вы находитесь на пути к поставленным целям, сколько у вас в текущий момент багов, успеваете ли вы в спринт, с какой скоростью двигаетесь.

Критерий “слащавости” метрик

Есть очень простой способ определить, что метрика “слащавая / тщеславная” (англ. vanity).

Большинство абсолютных метрик, таких, например, как посещаемость, количество скачиваний, количество ретвитов, количество email-ов/подписчиков, количество лайков и т.д. являются слащавыми.

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

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

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

Летим дальше

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

Но по дороге встречаются новые проблемы. Графиков слишком много, и поэтому их реже смотрят. Когда графиков 5, их легко проверять каждый день. С увеличением их количества получается режим раз в неделю — тоже хорошо. А потом внезапно 3 дня назад случился факап, который никто не заметил.

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

Мы разделяем: бизнес-метрики, метрики процессов, QA-метрики (Web / Mobile, Ручное / Автоматизация, Performance).

Так выглядит агрегированный график (NPS, CSAT).

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

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

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

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

Лечим грусть

Можно уехать на море, отдохнуть, вернуться и посмотреть на опыт других компаний.


Логичное решение — собрать всё вместе с точки зрения данных и преобразовать в метрики.

Мы сформулировали следующие критерии:

  • Собирать автоматически, чтобы руками никто ничего никуда не подгружал.
  • Реализовывать различные представления данных.
  • Должна быть связка систем: если половина данных берется из Jira, половина из TestRail, они должны попасть в одну копилку, из которой потом получится уникальный отчет.
  • Все должно быть управляемым и легко поддерживаемым. Это значит, что люди сами могут на основе системы построить нужные отчеты, сами её поддерживать.

Метод aarrr / pirate metrics

В 2007-ом году Дейвом МакКлюром был разработан и предложен метод AARRR — система метрик, помогающая стартапам разобраться в бизнес-показателях. Другое название метода, которое также можно встретить, — “пиратские метрики” из-за того, что название произносится на пиратский лад: “ааррр!”.

  • Аcquisition — привлечение (соответствует п. 1 выше)
  • Аctivation — активация (соответствует п. 2 выше)
  • Retention — удержание (соответствует п. 4 выше)
  • Revenue — доход / монетизация (соответствует п. 3 выше)
  • Referral — рекомендации (нововведенный этап)

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

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

Метрики и дашборды устаревают

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

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

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

Дать инструмент, научить им пользоваться, а дальше отпустить в самостоятельное плавание. Это даст несколько преимуществ. Во-первых, команда изнутри, скорее всего, видит больше, чем вы сверху, особенно если у вас 15 команд, и вы пытаетесь всеми ими управлять.

Дополнительный анализ:  Прогнозы на матчи Лигу чемпионов УЕФА

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

Метрики на разных стадиях проекта

Расскажу, какие метрики мы измеряли, когда были стартапом, а потом стали расти и расширяться.

Много багов в биллинге

Эксперты говорят:

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

Проверяем: баги были по «спящим клиентам». Это те клиенты, которые или не платили деньги, или не собираются платить, или платили, но очень мало. Это явно не было каким-то блокером. Соответственно не все из этих багов напрямую влияли на деньги.

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

Монетизация

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

Обрастаем жиром


Растем дальше, «обрастаем жиром» — не влезаем в офисы, в которых сидели, и начинаем периодически переезжать.

Что важно для бизнеса?

  • LTV. Нужно удерживать клиентов. Если раньше клиент записывался один раз и уходил, то сейчас, очевидно, что нужно его удерживать, строить пользовательский сервис.
  • Бренд / Репутация. Если раньше люди обращаясь в DocDoc, могли думать, что это клиника, теперь они знают, что попали именно в сервис, который им помогает.
  • SLA. Так как люди начинают пользоваться сервисом постоянно, доступность сервиса становится критичной, потому что любой простой напрямую влияет на деньги.
  • Данные. Появляются первые данные, причем как продуктовые, так и технические и пользовательские, которые нужно уметь обрабатывать и хранить. Встает вопрос безопасности.
  • Конверсия. На этапе масштабирования не создается принципиально новый продукт, а улучшается созданный.

В QA уже входит примерно 30-50 метрик. Мы измеряем:

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

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

Оповещения

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

  • Performance.
  • Автотесты. Например, если слишком повышается процент пропущенных багов или если слишком много новой функциональности не покрыто тестами.
  • Входящие баги. У нас в компании любой человек может завести баг в тикет-системе. Раньше это сопровождалось сообщением в личку, а теперь есть канал оповещений о новых багах, мало того, баги автоматически назначаются на исполнителя по очереди. Назначенный человек должен разобрать баг, иначе бот будет каждые 15 минут ему напоминать.
  • Скорость тестирования/ожидания тестирования. Если видно, что человек закопался в задачу — неважно, он ее кодировал, делал ревью, тестировал — должно прилететь оповещение: «Ты уже три занимаешься одной задачей, возможно, ты закопался, попроси помощи».
  • Дефекты на задачу/команду.
  • Ревью тест-кейсов. Это просто автоматизация процесса, чтобы не делать это руками.

Падение количества звонков в колл-центре

Эксперты говорят:

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

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

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

Есть график по звонкам. Если видим падение, должен сработать алертинг, что звонков стало меньше обычного.

Суть этих примеров в том, что ответы не в ветвях, а у корней, поэтому нужно всегда проверять экспертов. Что бы ни казалось на интуитивном уровне, что бы эксперт не говорил, надо всегда докопаться до сути через метрики. Есть техника «5 почему», которая позволяет это сделать.

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

Пирамида метрик для метрики роста (north star) на примере ozon

Обратите внимание, что на разные KPI влияют разные продуктовые инициативы.

Выявить метрику роста поможет чек-лист вопросов:Ценность: Отражает ли эта метрика опыт пользователя в отношении основной ценности продукта?AHA-Момент: Отражает ли она тот момент, когда пользователи впервые ощущают основную ценность продукта?

Бизнес: Это единственное, что показывает, что бизнес движется в правильном направлении?Аналитика: Метрика показывает уровень фактического взаимодействия и активности?Стратегия: Связана ли метрика с долгосрочной ценностью вашего продукта?

Таблица ниже — метрики роста, которые описал Сергей Колосков для широко известных продуктов (в telegram-канале Fresh Product manager):

Whatsapp
Messenger.

среднее
Количество активных чатов на юзера
(активных — обновленных не более месяца
назад), количество отправленных писем

Instagram.

Ежедневная
пользовательская активность, время,
проведенное в ленте

Youtube.

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

Telegram
messenger.

Дневное,
недельное и месячное количество
отправителей сообщений.

«Яндекс.Такси».

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

Facebook

Время
пользователей, проведённое в ленте,
ежедневная пользовательская активность,
связь с 7 друзьями в течение первых 10
дней пользования соцсетью

Facebook
Messenger

Количество
входов, количество отправленных писем

Booking

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

Spotify

Время
прослушивания музыки

Wildberries

Конверсия
в покупку, процент брошенных корзин,
средняя стоимость заказа

Netflix

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

Яндекс.Музыка

Количество
прослушанных треков на юзера

Airbnb

Количество
забронированных ночей в день/месяц/год

Medium

Время,
проведенное за чтением на ресурсе

Bookmate

Количество
прочитанных страниц на юзера

Skyeng

Конверсия
в следующее обучение в течение месяца

Uber

Количество
поездок за неделю/месяц/год, время подачи

Ozon.Travel

Количество
регистраций, заказов и конверсию из
регистраций в покупку.

Amazon

Количество
покупок на подписчика prime

Walmart

Количество
покупок на пользователя

Dropbox

Кол-во
free-аккаунтов с более чем 3 активных
пользователей в неделю

Slack

Количество
коллег, коммуницирующих в течение
дня/недели/месяца

Quora

Количество
вопросов, на которые пользователь
отвечает

Twitter

Время
пользователей, проведённое в ленте,
ежедневная пользовательская активность

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

Следующая задачка: выявить метрику роста Google Drive. Согласно концепции продукта, пользователь бесплатно может хранить до 15 GB. Дополнительный объем в облаке уже платный. Поэтому, можно сказать однозначно, что здесь метрика роста — количество аккаунтов с файлами общим весом в 15 GB.

Аналогичная задача для соц.сети TikTok. Только здесь нужно учесть другой вид монетизации — просмотр рекламы. В данном случае метрика роста — количество просмотров, время, проведенное пользователем в день. Иногда ВЫХОДные метрики путают с ВХОДными метриками вроде количества создаваемого контента в соц.сети, удобства загрузки видео и т.д.

Метрики роста бессмысленны без финансовой успешности.Если посмотреть полную воронку каналов продаж и коммуникаций E-commerce продукта, то можно увидеть, что она состоит из нескольких крупных блоков:

  • Осведомленность
  • Отношение
  • Желание
  • Покупка
  • Лояльность


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

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

Привлечение

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

Пример метрик в команде online

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

Примеры оповещений


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

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

Здесь указано, какие кейсы на кого назначены, с каким статусом и кому надо посмотреть.

Еще один пример — бот Ябеда, который следит за процессами.

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

Растём

На следующем этапе мы уже научились стоять на ногах, немножечко ходим.


Нужды бизнеса эволюционируют, становится важно измерять:

  • Трафик. Когда стало понятно, что продукт нужен пользователям, генерируется как можно больше трафика, например, появляются партнерские программы.
  • Масштабирование — насколько возможно вырасти как со стороны продукта, так и со стороны разработки.

QA уже становится больше: 10-15 метрик. Если в стартапе мы создавали продукт по нашим ощущениям, например, основатель говорил: «Хочу синюю кнопку», и все делали ее, то теперь есть первая статистика. Можно пропускать фичи через

A/B-тесты

и не забывать измерять результаты.

Появляется автоматизация. Monkey testing уже недостаточно, и есть смысл вкладываться в расширение. На этом этапе появляется автоматическое тестирование, которое должно помочь сделать регрессионное тестирование быстрее. Соответственно, измеряется скорость тестирования релиза: насколько автоматизация оправдана. Печально, когда на автоматизацию ушло полгода, а релизы почему-то не ускорились.

Также измеряется объем релиза, чтобы видеть, если, например, разработчиков вместо 5 стало 15, но почему-то объем релиза не вырос.

Для сбора метрик на этапе роста кроме рук и Excel появляются специализированные системы. Системы — это любые инструменты, которые помогают создавать продукт. Если раньше те же тест-кейсы писались в Google docs, здесь появляются:

  • менеджер-системы, например, TestRail;
  • Google Analytics для сбора данных о пользователях;
  • Report portal, Allure для автоматизации.

Система строит внутри себя еще дополнительные метрики и отчеты.

Рекомендации

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

Количество активированных рекомендаций позволяет увеличить CAC / CPI. К примеру, мы привлекаем пользователя за $1 и хотим сохранить такую тенденцию. Мы разработали механику реферальных ссылок и выявили, что теперь после внедрения средний пользователь приглашает двух других.

Дополнительный анализ:  Резюме Аналитик DP / Ассистент исследователя, ресерчера, Москва, по договоренности - найти Аналитика на SuperJob

NPS (Net Promote Score) — метрика, которая показывает уровень потребительской лояльности. Механика расчета подробна описана на Википедии, не будем на ней останавливаться. Скажем лишь о том, что рекомендуем регулярно замерять NPS, используя директ-маркетинговые каналы коммуникаций.

Сколько нужно оповещений и как часто?

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

Слишком много оповещений — перестаем реагировать. 500 оповещений в день вы совершенно точно перестанете успевать просматривать, а значит можете пропустить важное.

Слишком мало — не видим проблем. Если сообщений слишком мало, например, просто половину выкинуть, можно не увидеть какую-то проблему.

Нет проблем — сводка по фактам. В случае отсутствия проблем оповещения тоже нужно посылать, но в виде сводки: что произошло за день, что работало, какие были задачи, что случилось. Если не делать сводку, можно подумать, что просто все сломалось и надо искать, какие оповещения отвалились.

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

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

Кроме того, мы ввели

уровни оповещений:

  • Исполнитель — первый, кого будет бить бот, если задача горит.
  • Команда / общий чат. Если исполнитель не реагирует, подключается команда или чат, в котором собраны люди по релизам или по перформансу.
  • Лид. Если исполнитель или команда не реагируют, сообщение получит лид.
  • Руководитель. Если и лид не среагировал, сообщение прилетит уже к руководителю. Плюс, обычно мы отправляем руководителю ставим сводку. Он не видит обычных оповещений, но получает результат, как идут дела.

Стартап

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


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

time-to-market

— скорость доставки идеи до пользователей (именно до продакшна, а не просто до релиза) и

количество клиентов

В части QA у нас было всего 3-5 метрик:

  • количество багов с боя;
  • количество багов, которые доходят до релиза;
  • критичность багов.

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

Трудности


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

Систем стало очень много

, появилась необходимость ими как-то управлять. Смотреть в каждую систему — это, как минимум, много времени.

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

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

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

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

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

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

Удержание

Любая организация хотела бы, чтобы у нее существовала активная база лояльных клиентов, которые регулярно делают повторные заказы. В этой связи, очень важно отслеживать несколько ключевых метрик: Retention rate (или Rolling retention), Churn. Подробно я разбирал построение retention и rolling retention отчетов в одном из прошлых выпусков блога.

Упала конверсия

Эксперты говорят:

это эффект сезонности, просто люди сейчас не болеют, поэтому не звонят.

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

Но при этом есть график связки релиза и конверсии:

Здесь узлы — это релизы, по оси X конверсия в запись (фиолетовая линия), в заявку (синяя) и в открытие формы (зеленая). Когда мы видим, что график где-то проседает, обращаемся к релизу (на него можно кликнуть) и видим связанную задачу: когда она была, кто накатывал.

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

Ценность inside

Составлять набор метрик часто начинают “от балды”, порывшись в Интернете и выбрав из найденного лучшие варианты по принципу: “О! Это нам подойдет!”

Как Вы понимаете, это не лучший способ, верно?

Но как решить, какую метрику брать, а какую нет?

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

Но почему измеряют именно пользователей, а не что-нибудь еще? Вы не задумывались над этим вопросом?

Естественно, ответ есть.

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

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

Есть один простой, логичный и работающий способ. Всё встаёт на свои места, когда Вы отвечаете на вопрос:

КТО ПРОИЗВОДИТ ЦЕННОСТЬ?

Мы ведь работаем надо объемом продаж, так? Хотим его увеличить, верно?

На кого и на что нужно повлиять, чтобы увеличить объем продаж?

Конечно,

нужно влиять на причину — на того, кто “производит” ценность.

Кто производит деньги в интернет-магазине? Откуда появляются деньги?

Очень просто: от клиентов.

Где именно в интернет-магазине можно повлиять на клиентов?

Да где угодно!Верно. На каждом этапе жизненного цикла клиента.

Для представления жизненного цикла удобно строить т.н. “воронку” движения клиента по процессу.

Пример воронки интернет-магазина:

Почему именно так? Потому что клиенты теряются именно при переходах с одного шага воронки на другой.

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

Простой пример.

Метрика “Процент брошенных корзин” по сути показывает конверсию при переходе от товарной корзины к оформленному заказу.

Допустим, при первом замере Вы обнаружили, что теряется 90% корзин, т.е. из 10 корзин делается только 1 заказ.

С товарной корзиной явно что-то не так, верно?

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

В результате доработки корзины, процент брошенных корзин уменьшился на 10%, до 80%. Как это выглядит в цифрах?

Из 10 корзин стали оформлять 2 заказа. 100 руб * 2 = 200 руб.

Но это же увеличение объема продаж на 100%! Бинго!

Увеличив конверсию шага всего на 10% Вы увеличили объем продаж на 100%.

Фантастика!

Но именно так это и работает.

Понимаете теперь в чём прелесть правильно построенных метрик?

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

С интернет-магазином всё довольно просто, а вот как это всё переложить, например, на качество программного продукта? Да точно также:

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

Вот, например, какие метрики качества могли бы получиться (на вскидку)…

Показатель ценности:

  • плотность дефектов прома на 1000 строк кода

Метрики исходя из жизненного цикла исходного кода:

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

Метрики исходя из жизненного цикла дефектов:

  • динамика обнаружения дефектов,
  • динамика исправления,
  • динамика переоткрытий,
  • динамика отклонений дефектов,
  • среднее время ожидания исправления,
  • среднее время исправления.

Итоги

Как видите, тема метрик реально очень важная, нужная и интересная.

Как правильно подобрать метрики:

Выбирайте OMTM, продумывайте её основную ценность и измеряйте производителей этой ценности.

Метрики стройте на основании воронки жизненного цикла производителя.

Старайтесь не использовать абсолютные метрики.

Итоги

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

Нет универсального набора метрик:

  • есть разные стадии проекта;
  • есть разные цели, которые вы для себя ставите;
  • есть разные проблемы, которые вы хотите решить.

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

Метрики — это не решения. Это всего лишь показатели здоровья проекта, которые говорят о текущем состоянии и о его динамике. Оповещения как раз являются индикаторами, которые помогут не пропустить, если что-то случится.

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

Что получилось у нас:

  • ~ 50 метрик QA и более 100 остальных.
  • ~ 30 активных дашбордов.
  • Разные уровни погружения — можно быстро посмотреть, где проблема.
  • Обязательные оповещения на метрики.
  • Создание и поддержку мы отдали в сами команды.
  • Связка QA и бизнеса must have.

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

Заключение

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

Оцените статью
Аналитик-эксперт
Добавить комментарий

Adblock
detector