Lean Analytics: MustApp

Структура

  1. Lean Analytics
  • непрерывное изучение того что работает и что не работает
  • проверка гипотез
  • поиск сегментов целевой аудитории
  1. Что считаем
  • типы стартапов
  • этапы развития стартапа
  • ключевые метрики на каждом из этапов
  • глобальные метрики проекта (стартапа)
  • метрики эффективности функционала
  1. Как считаем
  • Существующие инструменты
  • плюсы и минусы каждого из них
  • Агрегация данных из различных источников
  • Отчеты и Дашборды
  1. Исследования
  • сегментация пользователей
  • потоки поведения пользователей (behaviour flows, screens, events, goal flow, funnels, user explorer)
  1. Процесс
  • требования к идеям про новую фичу (for product-owners, designers, etc)
  • определять на какие параметры направлен функционал (retention, stickiness, enrollment, virality, etc)
  • требования к разработке новой фичи
  • конвенции к именованию событий
  1. Acquisition & Revenue
  • ...


Lean Analytics

tldr;

  • непрерывное изучение того что работает и что не работает
  • проверка гипотез
  • поиск сегментов целевой аудитории


Lean Analytics — это:

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

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

Lean Analitycs в этом как раз и помогает: Build/Develop ideas → Measure → Learn (цикл)





Что считаем


Чтобы разобраться с тем, что мы хотим считать, разберемся сначала какие метрики бывают и от чего они зависят. 


Если коротко, то зависят от:

  • типа проекта
  • жизненного этапа на котором проект находится


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

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

 

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


Типы стартапов

Каждая бизнес модель состоит из следующих аспектов: the acquisition channel, selling tactic, revenue source, product type, and delivery model.


В зависимости от параметров данных аспектов выделают следующие виды бизнес моделей:

  • E-commerce
  • Software as a Service (SaaS, PaaS, IaaS, etc)
  • Free Mobile App 
  • Media Site 
  • User-Generated Content
  • Two-Sides Marketplace


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

Этапы развития стартапа

Существуют различные представления развития стартапа:


Но в целом они все свободятся к одним и тем же фазам (возможно просто что с различной детализацией):

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


Рассмотрим более подробно одну из них, состоящую из этапов: EmpathyStickinessViralityRevenueScale


  1. Первое, нам нужно “сопереживание” (empathy). Нам нужно забраться в головку рынка на котором мы хотим быть, чтобы быть уверенными в том, что мы решаем проблему пользователей, на которую им не пофиг, от которой они страдают и за решение которой они готовы платить. 
  2. Второе, нам нужно “цеплять” пользователя (stickiness) (привязываемость? / вырабатывание у пользователя привычки?). Хорошее приложение будет “цеплять”. И здесь нам нужно выяснить можем ли мы построить решение проблемы, которые мы обнаружили на первом этапе. Нет смысла промотировать что-то ужасное, если пользователи отваливаются с отвращением. 
  3. Третье, нам нужна “вирусность” (virality). Когда у нас появился продукт, который цепляет (stickiness) то самое время использовать word of mouth. Т.е. здесь можно проверять процессы приобретения и размещения на новых пользователях, которые мотивированны попробовать продукт, потому что мы заручились поддержкой уже существующих пользователей. Вирусность сильно увеличивает прирост при платных продвижениях. Поэтому важно иметь хорошие показатели органической вирусности прежде чем начнем тратить деньги на платные неорганические способы приобретения пользователей (например, реаклама и т.п.)
  4. Четвертео, нужен доход. На этом этапе мы захотим монетизации. Это не означает, что раньше мы не брали за что-то денег или не зарабатывали на чем-то. Это означает, что раньше мы были сконцентрированны на чем-то другом (например на: stickiness, virality и тп.) нежели на росте. Например, выбрасываете (?) бесплатные триалки и полностью фокусируетесь на максимизации и оптимизации прибыли. 
  5. Пятое, нам нужно масштабироваться. С приходом прибыли самое время двигаться от роста своего бизнеса к росту своего рынка. Необходимо приобритать потребителей из новых вертикалей и географий. … тут главное кмк видеть высокоуровневые и амбициозные цели, во что будет развиваться продукт (не только на ранних этапах, но и что дальше).



Ключевые метрики 

Итак, высокоуровнево для аналитического мониторинга продукта обычно выделяют следующие метрики:

  • retention/engagement/stickiness (на сколько цепляет пользователя приложение, как часто они возвращаются, как много времени за ним проводят, т.е. на сколько они показывают что приложение из зацепило/вовлекло и т.д.)
  • time spent interacting
  • time since last visit 
  • daily and monthly active use (dau, mau)
  • частота использования (часто эту метрику пишут как stickiness)
  • daily-active-users / monthly-active-users (% месячных активных пользователей, которые пользуются приложением каждый день)
  • weekly-active-users / montly-active-users (сколько пользователей из тех кто пользуется приложением, пользуется им каждую неделю)
  • churns (пользователи которые не вернулись)
  • enrollment (или conversion rate по каждой фиче)
  • завершили регистрацию
  • добавили в want/watched
  • virality (верусность продукта: может быть — неотъемлемая, искуственная и word-of-mouth)
  • viral coeficient (число новых пользователей, которых способен успешно привлечь текущий существующий пользователь)
  • viral cycle time (время за которое пользователь привлекает других пользователей — день, месяц и т.д.)
  • reliability (надежность)
  • как много жалоб, инцидентов, или простоев было 
  • acquisition (приобритение пользователя)
  • trafic, mentions, cost per click, search results, cost of acquisition, open rate
  • revenue (business outcomes which vary by your business model: purchases, ad clicks, content creation, subscriptions, etc.)
  • сustomer lifetime value, 
  • shopping cart size, 


Сейчас я пришел к тому, что 2 типа метрик:

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


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


Выделяю следующие глобальные метрики проекта:

  • downloads 
  • launch rate 
  • percent of active users  (% от общего числа пользователей)
  • number of new users (over a specic time period)  (поможет в трекинге различных маркетинг подходов)
  • churns (те, которые ушли)
  • которые отвалились сразу (%)
  • отвалились через какое-то время (день, неделя, месяц и т.д.)
  • virality (социальщина)
  • viral coefficient (the number of people a user successfully invites to your service) 
  • viral cycle time (how long it takes them to invite others) drive your adoption rate 


Метрики по каждой фиче (per feature/action)

  • conversion rate (конверсия) процент новыйх людей, которые сделали это действие (% of users) (еще бывает называют click-through-rate) — done_action_users / new_users
  • ctr
  • funnels
  • time to do this action (нужен percentile) — как долго заняло времени сделать это действие
  • retention — как много/часто/сколько пользовался этой фичей
  • % of users — % от всех активных пользователей, которые пользуются данной фичей (не путать с конверсией или ctr — здесь от всех активных пользователей, а в conversion rate от новых)
  • dau / mau — frequency (stickiness): как часто пользуется данной фичей
  • count per user (percentile): сколько раз за интервал (сессию, неделю, месяц) пользователь выполнил данное действие 
  • reliability — тоже самые параметры что и у retention'а, но означает обратное — если часто пользуются, то есть проблема (например: частые логины, частая отправка репорта и т.п.)
  • % of users: % пользователей использующих этот функционал
  • count per user: quantitive usage (count / duration) of usage

Как считаем


Существующие инструменты

Рассматривал следующие инструменты:

  • Google Analytics
  • Mixpanel
  • Faceebook analytics
  • ELK (kibana)
  • Собственные разработки


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


Fabric

На данный момент туда отсылаются только старые метрики связанные с авторизацией.

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


Faceebook analytics

Тоже самое что и с fabric’ом — отправляли только данные с формы account’кита. Поэтому выглядит что там все должно быть некорректным.


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


ELK (kibana)

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

Нужно прикинуть и попробовать:

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


Возможно нужно будет делать 2 разных индекса:

  • один для сырых данных (event’ов) 
  • поскольку событий будет много, то у этого индекса будет свой срок жизни
  • второй для агрегированных данных 
  • этих событий должно быть сильно меньше и их хранить мы можем сильно дольше


Задача которая тогда встает, кто и как будет перекидывать агрегированную инфу во второй индекс?

Нужны какие-то кастомные обработчики писать? или что-то из коробки есть?


Что насчет воронок? — на сколько это там все норм можно будет отобразить? (хотя для воронок вполне можно и сторонние типа гугла использовать сервисы)


в общем глянуть: 


Google Analytics

<TBD>


MixPanel

<TBD>


Собственные разработки


Агрегация данных из различных источников

Есть проблема, что не все (ни один?) инструменты из коробки не дают то, что мы хотим считать. В основном данное ограничение связано с тем, что какие-то данные считают эти сервисы, какие-то у нас есть на бэкенде (различные total’ы) — и вот чтобы считать конверсии, необходимо агрегировать данные с различных источников (либо считать все у себя, к чему мы придем по всей видимости не быстро)

Отчеты и Дашборды


Исследуем поведение


Сегментация пользователей

Когда мы получим фича метрики (conversion, stickiness (dau/mau), retention, engagement, etc), то сможем начать с них, чтобы понять что общего между пользователями, которые активно и часто используют приложение, либо наборот ушли (churns)


Здесь уже помогут такие инструменты как: 

  • behaviour flows (sankey diagram)
  • screens
  • events 
  • goal flow 
  • funnels
  • user explorer


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



Процесс


Требования к идеям про новую фичу (for product-owners, designers, etc)

  • определять на какие параметры направлен функционал (retention, stickiness, enrollment, virality, etc)


ответить на вопросы:

  1. Почему данная фича улучшить ретеншн?
  2. Можем ли мы померить эффект от фичи?
  3. Как долго разрабатывать фичу?
  4. Переусложняет ли она весь продукт?
  5. Какие риски в этой фиче
  6. Насколько фича инновационна


Требования к разработке новой фичи

конвенции к именованию событий


Acquisition & Revenue


<TBD>

не занимался пока этим вопросом, но сюда будет входить все вот это:

  • acquisition
  • trafic, mentions, cost per click, search results, cost of acquisition, open rate
  • customer acquisition cost (CAC) 
  • Ratings click-through 
  • Top keywords driving trafic to the site
  • Top search terms
  • revenue
  • customer lifetime value
  • ad clicks
  • monthly average revenue per user (ARPU)