Mao dao что это

Процесс UX/UI редизайна Maps.me в колаборации British Higher School of art & design и Mail.ru Group

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

Считается, что классическая модель UX процесса выглядит примерно так.

Почти во всех школах дизайна учат примерно такой последовательности:��

Категоризируем и приоритезируем проблемы, которые выявили
Создаём персоны и карты путешествий
Генерируем идеи
Создаём прототип на основе гипотез
Делаем предварительные тестирования прототипа
Делаем UI для протестированного прототипа
Передайте финальную версию разработчикам
Контролируем реализацию и запускаем продукт или флоу
Делаем все сначала, отталкиваясь от фитбека пользователей

В крупных компаниях, процесс чаще происходит примерно так��

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

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

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

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

Как вообще так получилось?

В 2017 году, во время обучения в «британке», я принял участие в так называемом «интенсиве — практикуме» по направлению « UX & UI : Продуктовый дизайн».

В рамках данного практикума, и благодаря моему наставнику и куратору курса Юрию Ветрову, «британка» делала коллабы с известными продуктами корпорации Mail.ru и не только, о чем он написал отдельную статью.

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

1 — главная страница Mail.ru2 — почта Mail.ru3 — приложение Delivery Club4 — приложение MAPS.ME5 — главная страница Альфабанка6 — мессенджер «там там»

Задача для студентов была классической:

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

В итоге мы должны были предоставить презентацию процесса и результатов нашей работы в следующем формате:

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

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

Наша экскурсия в Mail.ru и встреча с продакт овнером MAPS.ME.

То ли сердцем, то ли логикой я сразу отмёл все страницы mail.ru, понимая, что независимо от качества дизайна, шансы, что наш концепт попадёт на продакшн, минимальны (и я не ошибся).

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

Для меня оставалось всего 2 приемлемых варианта: Delivery Club или MAPS.ME.

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

Мой выбор пал на MAPS.ME по 4 причинам:

MAPS.ME — единственный из вышестоящих сервисов с юзерами по всему миру. Это было сложнее, но интереснее!
Продуктовнер MAPS.ME обещал поделиться аналитическими данными, раскрыв команде немного метрик по запросу, а также хорошие показатели DAO и MAO (около 10 тыс. юзеров в сутки).

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

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

4. Я сам путешественник, поэтому неоднократно юзал maps.me при поездках в разные страны, видел ценность в концепте оффлайн карт, но признаюсь, меня всегда раздражал дизайн приложения и словно сама Вселенная дала мне шанс все исправить)

Ключ к успеху — ответственность! Вперёд.

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

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

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

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

Как проходили этапы работы?

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

Этап № 1: UX Research

Чтобы процесс дизайна сразу не ушёл в полную субъективность, а команда выстраивала гипотезы без типичных ошибок, таких как:

1 — Примерка роли юзера на себя,

2 — Cтроение гипотез и выводов на основе «экспертности» дизайнеров,

3 — Типичной «ошибки выжившего» или невалидности аудитории.

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

Для этого мы решили сделать 4 простых действия:

1 — Изучить функционал приложения;

2 — Изучить все возможные отзывы о приложении в интернете (AppStore, Play Маркет, тематические форумы и все возможные упоминания, на которые приведёт Гугл или Яндекс);

3 — Выписать список наиболее частотных проблем, с которыми сталкиваются пользователи, и приоритизировать их;

4 — Провести опрос среди пользовалей, задав следующие вопросы:

«‎В каких ситуациях вы используете приложение чаще всего?»«‎Какие функции приложения самые ценные для вас?»«‎Какие проблемы вы испытываете в работе с приложением?».

Этап № 2: Персоны и юзерстори

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

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

1 — Провели дополнительные опросы среди пользователей:“Кто и как юзает продукт?”;

2 — Приоритизировали контексты использования;

3 — Воспользовались предварительными исследованиями и здравым смыслом.

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

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

1 — �� Используют Maps.me здесь и сейчас (Больше Online)

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

2 — ✏�� Планировщики (больше Оffline)

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

3 — �� Автомобилисты (больше Оffline)

Составляют сложные маршруты и хотят подробную навигацию(смотрят текущую локацию и прокладывают маршруты от неё).

4 — �� Домашние пользователи (больше Online)

Ищут интересные события рядом с собой и ожидают высокую информативность сервиса (ищут места и локации по карте в своём районе и прокладывают маршруты).

Этап № 3: Проверка юзабилити

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

Выяснив основные контексты использования, мы попросили респондентов выполнить самые популярные сценарии и задачи, например: «‎найдите ближайший банкомат или ресторан» или «‎проложите маршрут к найденой локации»….

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

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

Полет нормальный, летим дальше…

Этап № 4: Бизнес-модель и UX стратегия

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

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

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

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

Этап № 5: Разработка гипотез

Итак, мы точно выяснили 3 самые важные вещи для первых гипотез:

1 — Аудитория и контексты использования;

2 — Наиболее частые проблемы при использовании;

3 — Самые релевантные воркфлоу.

Совокупность этих данных позволила выяснить и приоритизировать недостатки и преимущества приложения.

Нам удалось получить какие-то количественные статистические данные (но они были очень общими, и мы их почти не использовали)

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

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

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

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

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

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

Каждый из нас накидал от 3 до 5 самых важных по его мнению проблем и идей, после чего мы их обсуждали и голосовали — какие гипотезы мы точно берем в работу.

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

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

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

В конце, у нас получился такой прототип, который мы собрали в Marvel.
Этап № 6: Проверка гипотез

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

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

Тут есть видео, как это приблизительно происходило. Для тех, кто случайно забыл, напомню, что UX тесты мы делали с помощью сервиса lookback.io

Результаты:

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

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

1 — Редизайн категорий.

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

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

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

Здесь вы найдете статью о правилах применения сенсорного дизайна

Также были изменены кнопки категорий в более комфортные размеры
2 — Апгрейд поиска

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

Конечно же, можно забить в гугле, но тогда зачем пользоваться MAPS.ME? А если нет интернета? Для чего тогда нужны оффлайн карты?

Здесь мы добавили умные теги, привязанные к запросам. Например, по запросу «‎еда», можно показывать такие теги, как «‎японская кухня» или «‎здоровая еда» и подобные. Также можно сразу посмотреть места по тегам на карте или воспользоваться умным фильтром.

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

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

3 —Редизайн карточек заведений

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

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

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

Пример карточки до и после.

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

4 — Переработка таб меню

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

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

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

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

5 — Мультимаршрут

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

6 — Функция прогулки

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

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

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

Этап № 7: Стратегия монитезации и продвижения

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

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

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

Например, если у пользователя по пути есть Макдональдс, можно предложить ему зайти.

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

В конце, мы тезисно дополнили нашу презентацию краткими идеями, которые мы не успели реализовать, но тоже считали полезными)

Спасибо всем, кто прочитал этот немаленький текст!Надеюсь, он будет хоть кому-то полезен)

Это моя первая статья на Medium, так что не судите строго ��Вместе мы сделаем мир лучше! ��

LTV, CAC и другие ключевые метрики продукта

Марина Михеева, ментор ProductStar и тимлид команды продуктовой аналитики в DiDi, ex-AliExpress, ex-ЦИАН (ну вы поняли, доверять можно!), простыми словами рассказала про LTV и CAC, Retention и аудиторные метрики, фреймфорки AARRR, HEART и PULSE. В общем статья вышла обширная, да еще и с реальными кейсами.

50 показов
4.2K открытий
Марина Михеева

Team Lead Product Analyst DiDi, ex-Lead Product Analyst, AliExpress, ex-Lead Product Analyst, ЦИАН, ex-Business Analyst, Авито

Что такое продукт?

Под продуктом в IT зачастую понимается приложение, мобильный или web-сайт. Например, поговорим о приложении. Что мы делаем? Для начала, закупаем трафик, т.е. приглашаем пользователей скачать наш продукт. Это этого этапа может зависеть наша конечная цель — получение денег. Если мы ошибемся с закупкой (например, выстроили неверный таргет или ошиблись с product market fit), то часть пользователей может “не зацепиться” и уйти, так и не заплатив.

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

Мы тратим деньги на трафик = привлекаем пользователей = CAC (Customer Acquisition Cost)
Получаем с них прибыль = количество денег, которые пользователь принесет за все время взаимодействия с нашим продуктом = LTV (Lifetime Value)

Логично, что для положительной прибыли расходы должны быть меньше доходов, поэтому CAC

Что может влиять на CAC и LTV.

“Траты” на привлечения пользователя могут включать в себя:

реферальные программы (например, приведи друга в приложение и получи скидку)
таргет (прямая закупка определенного сегмента аудитории)
PR (пресса, тг-каналы, посты в пабликах, Reddit — все, что помогает рассказать о продукте)
Yandex.Direct (контекстная реклама)

Как зарабатывать с пользователей?

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

Соотношение LTV и CAC

Как уже упоминали, для положительной прибыли LTV необходимо быть больше CAC, однако существует такое негласное правило, что для жизнеспособности бизнеса неравенство должно иметь вид LTV > 3*CAC, то есть доходы должны превышать расходы в 3 раза. В этом случае продукт будет окупаться меньше, чем за год.

Иными словами — …

Соотношение LTV/CAC — это устойчивость нашей бизнес-модели …
… и в идеале, на 100 потраченных долларов мы зарабатываем 300
Есть исключительные примеры (Salesforce (CRM услуги)), у которых соотношение = 5/1
Все потраченные деньги мы “отбиваем” в течение года (а еще лучше — в течение 6-ти месяцев)

LTV (Lifetime Value)

Life-time value или пожизненная ценность клиента — сколько мы зарабатываем с 1 платящего пользователя за все время его пользования/нахождения в нашем продукте. Допустим, мы выяснили, что среднее время пользования продуктом — один год, тогда LTV в этом случае — сколько денег приносит клиент в течение года.

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

Зачем считать LTV?

Узнать, сколько можно потратить на пользователя и при этом остаться прибыльными, т.е. определяем “допустимый предел”
Определить ценность пользователя — т.е. сколько зарабатываем с одного пользователя (для OKR, например)
Определить подходящий (выгодный) источник трафика. Так мы поймем, из какого канала приходит самая платежеспособная аудитория, а от каких источников можем отказаться.
Точка роста — LTV можно постоянно увеличивать за счет большого количества инструментов: SEO, тарифные линейки, встроенные покупки, новые модели монетизации и т.д. По сути, LTV — бескрайнее поле для деятельности.

Как посчитать LTV?

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

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

3. Простым способом, LTV = Lifetime x ARPPU (для понимания, ARPPU — средняя выручка с каждого платящего пользователя)

Пример с когортой

Наша задача — посчитать LTV для какой-то когорты пользователей. Обычно, когда в анализе появляются когорты, мы делаем расчеты по данным пользователей, которые “зашли” в продукт в определенный период, т.е. разделяем их на временные когорты. В нашем случае мы рассматриваем платящих пользователей с 1 декабря 2021 по 1 декабря 2022.

Немного поясним написанное на скрине выше:

Channel — канал — источник трафика
Paying users — количество платящих пользователей в когорте
ARPPU — average revenue per paying user — средняя выручка на каждого платящего пользователя
Lifetime — сколько времени пользователь “провел” в продукте

Вопрос на засыпку: какой канал оставляем?

На самом деле, корректно будет обратить внимание на отсутствие данных по CAC. Так, хотя мы и много зарабатываем с одного YouTube-пользователя, мы не знаем, сколько он “стоит” и какую сумму нам нужно потратить на его привлечение в продукт.

Как еще можем посчитать LTV?

Если продукт позволяет совершать несколько покупок, то будет уместно усложнить формулу и добавить компонент “частота покупок”:

LTV = Средний чек × Частота повторных покупок × Lifetime

Пусть в среднем клиент делает 10 покупок, каждая из которых — на сумму $10, а его lifetime — 6 месяцев.

LTV = $10 × 10 × 6 = $600

CAC (Customer Acquisition Cost)

Как уже сказали, CAC (кстати, кто-то говорит “си-эй-си”, кто-то “как”, так что правил особо нет) — стоимость привлечения клиента.

Обычно в расчете учитываются затраты на маркетинг и продажу (например, агентство недвижимости оплачивает вам такси в офис):

CAC = (Затраты на маркетинг + продажи)/Количество новых клиентов.

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

Что влияет на CAC?

Чем дешевле стоимость перехода по объявлению, тем меньше CAC = чем ниже стоимость клика (CPC, Cost per Click), тем лучше.
С ростом узнаваемости бренда пользователи чаще ищут его и приходят сами. Это приводит к росту органики и снижению CAC.
Чем лучше мы знаем свою ЦА, тем и кампании будут успешнее. Например, можно точнее настроить показатели по географии, демографии, интересам и т.д

Пример расчета CAC

Затраты на рекламу = 200 тыс, новые платящие клиенты = 100 человек.

CAC составляет 2 тыс.

А если добавим 100 к на сопровождение продаж? В этом случае CAC = 3к.

А если добавим ФОТ (фонд оплаты труда)? Учитываем в CAC? Тут уже сложнее, в некоторых случаях учитывают (например, если на рекламу привлекаем стороннее агентство), но в целом это неверно — практически невозможно “вычленить” из ФОТ затраты именно на привлечение пользователей.

Еще один пример

Посетители — 10000 (увидели баннер)
Стоимость клика — 35 р.
Зарегистрированные в пробную версию продукта — 5% — 500 чел.
Купили полную версию продукта (из пробной) — 10% — 50 чел.
Стоимость продукта — 500 рублей
Время пользования продуктом — 10 месяцев
Затраты на рекламу — 350 000 (10000*35)

Чему равен CAC? Считаем.

CAC = 350 000 : 50 = 7000

Используем формулу: LTV = (средняя стоимость продажи) x (среднее число продаж в месяц) x (среднее время удержания клиента в месяцах).

LTV = 500 x 1 x 10 = 5000 рублей. 5000 рублей зарабатываем с одного пользователя, а САС у нас 7000 рублей.

Что по соотношению LTV/CAC?

Уже точно не соблюдается 3 LTV=1 CAC
LTV/CAC = 5000/7000 ~ 0,71 🙁

Что можем посоветовать такому стартапу?

Снижать CAC за счет анализа текущих источников трафика
Растить LTV — делать дополнительные продажи, увеличивать цены

Для тех, кому интересна тема метрик и data-driven решений, советуем статью по “Unit-экономике” от Дмитрия Сапрыкина, Senior Product Manager of Alice в Яндексе.

Retention и churn

Retention — это показатель возвращаемости пользователей в продукт. Считается, как отношение активных за период пользователей к количеству пользователей на начало периода. Показатель Retention можно считать на определенный день/месяц, а в отчетах встретить формулировку n-day retention, то есть возвращаемость пользователей на день n.

Например: на начале курса было 100 учеников, через месяц продолжили обучение 40 из них, а еще через месяц — 35 учеников. Таким образом, retention 1-го месяца будет рассчитываться как: 40/100 = 40%, а retention 2-го месяца — 35/100 = 35%.

Метрика возвращаемости — retention и оттока — churn в сумме дают единицу, таким образом, мы понимаем, что в 1-ом месяце отток 60%, а во втором- 65%. Растущий тренд оттока пользователей — тревожный звоночек! Будем возвращать пользователей, например, push-сообщениями, скидками, подарками или другими эксклюзивными офферами.

Аудиторные метрики

MAU/WAU/DAU — это уникальная активная аудитория продукта за определенный промежуток времени — день/неделю/месяц. Важно, что именно «уникальная», т. е. каждый пользователь, который пришел в продукт за месяц/неделю/день хотя бы один раз — учитывается в метрике активной аудитории. Повторные заходы пользователя в продукт не учитываются! Эти метрики позволят нам узнать, насколько продукт интересен, как он растет и развивается, есть ли у нас прирост новых пользователей или компания ушла в “зрелость”. Особенно важно это понимание для стартапов.

Например: в мобильное приложение зашло 10 тысяч уникальных пользователей. Общее количество сессий (или заходов в приложение) — 20 млн. Значит, какие-то пользователи заходили в продукт 2 и более раз, но в MAU/WAU/DAU мы учитываем только 1-ую сессию пользователя + пользователей, которые вернулись в продукт из предыдущего месяца/недели/дня в зависимости от того, какую метрику считаем.

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

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

Негласное правило работы воронкой конверсии — работаем с ней с конца.

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

Фреймворки

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

AARRR (Pirate Metrics)

Первая метрика в этом фреймворке — Acquisition, когда мы позволяем пользователю себя найти или “зазываем” его в продукт, закупая трафик. Замерять здесь можем CAC, количество новых пользователей и различные конверсии.

Далее — Activation. Теперь нам нужно понять, как “активировать” пользователя, чтобы он совершил какую-либо покупку. Метрики этого этапа: количество пользователей, которые прошли онбординг/зарегистрировались в продукте/оставили каку-то заявку, т.е. “зацепились” за продукт.

Метрика Retention — то, что позволяет “вернуть” пользователя в продукт. Анализировать можно по показателям retention (что в целом очевидно :)), churn и sticky factor (= отношение DAO к MAO)

Referral — все, что относится к реферальным программам: как часто наш продукт и целевые страницы отправляются знакомым (share rate), сколько пользователей проходят и “закрепляются” по реферальной ссылке (adoption rate).

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

Фреймворк HEART от Google

A glimpse into MAO DAO

MAO DAO has been shaped in the last months to shade the light into the eastern community in the Metaverse revolution.

Over the last 6 months we have seen the foundational thesis for NFTs playout, and the desire from everyone for games, art, and the most important part, “culture”, to be embedded into the blockchain.

As such, we have also seen most of the attention set on very few voices, and we want for a broader community to emerge and take the lead in shaping the play-to-earn space, by joining existing games, as it is by bringing different and innovative ideas with another point of view.

First Play-to-earn DAO in China

MAO DAO is at a stage where we are nurturing a community, onboarding people to the Metaverse space, and sharing with them the latest news and games in the industry. Currently, we focus on building a Chinese community and then expand to some other South-East Asian communities from where some of our existing members belong to.

At the same time, we have started with more experienced community members to build different teams and join existing play-to-earn games to disrupt the space with a newborn and strong gaming community as has never been seen. And for the immediate future, we will onboard hundreds of players into different existing games like Axie Infinity, League of Kingdoms, Alien Worlds, and many others that successfully brought the play-to-earn concept into existence.

Broader NFT Community & Incubator

Besides taking a leap into the play-to-earn space, MAO DAO, serving as an incubator, aims to help build a broader NFT community and to make community-driven projects come into existence through an incubator.

We use a DAO structure to lift up the most promising creators and projects (NFT & Metaverse) especially in the eastern communities. In the coming months, we plan to launch some special NFTs and a platform to make a better coordination mechanism between NFT creators and the community.

Как создавать и зарабатывать на SaaS (Часть 10 / Метрики бизнес модели)

Не перестал, как обещал, не писать про SaaS по простой причине — упустил несколько вещей, которые являются базовыми- юридические аспекты в SaaS и метрики, которые помогут сделать бизнес прогнозируемым. Cегодня исправляюсь и порассуждаю о метриках, применимых в SaaS модели предоставления ПО. Да и выбранная тематика оказалось интересной для читателей и логично продолжить ее не смотря на сезон отпусков.

Что я подразумеваю под SaaS

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

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

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

На что важно ориентироваться SaaS сервисам (#SaaS метрики)

В привлечении клиентов:

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

В практике вендоров стоимость лицензии, предоставляемой по схеме SaaS — это 3 года рассрочки от стоимости «коробочной» схемы лицензирования без учета затрат на сервера и 5 лет с ними. В практике Quickme мы делали стоимость ящика электронной почты такой, чтобы она была в пределах понимания ARPU нашими потенциальными партнерами — облачными провайдерами, хостинг провайдерами, телеком компаниями и не отличалась сильно от их мироощущения. Когда у вас нет с чем сравнить и вы делаете новый продукт, как например нишевой сервис автоматизации стоматологических клиник Dental-Cloud, то можно руководствоваться логикой «мы снимаем сливки» и делать стоимость сервиса выше.

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

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

В удержании клиентов:

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

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

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

Как у других (ниша Интернет сервисов для бизнеса)

Я не большой специалист по проектам из сегмента и по-этому обратился к своим коллегам с просьбой поделиться их опытом. Для понимания ситуации я задаю вопросы по использованию метрик специалистам из сервиса создания витжетов Witget.com и сервиса тестирования юзабилити сайтов «Фабрика юзабилити»

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

CEO Witget Вячеслав Давиденко

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

Сейчас нам интересны следующие метрики:
— CPA — стоимость клика в рекламе и стоимость регистрации в сервисе,
— ARPU и ARPPU — нам необходимо определить средний доход на одного пользователя. Это важная метрика для нас особенно на этапе внедрения монетизации, когда мы должны понимать, покрывает ли над доход с пользователя затраты на его привлечение.
— Retention — большинство SaaS построено по модели подписки. Это значит, что нужно предпринять все возможные усилия, чтобы клиент заплатил за второй месяц, за третий и так далее.
— Life Time Value, показывающая какой доход мы ожидаем получить в среднем от клиента за все время пользования нашим сервисом.
— Также в связи со спецификой бизнеса для нас важно время от момента регистрации на сайте до момента активации продукта и начала его использования. Если регистрация занимает больше времени, то есть большая вероятность потерять клиента на одном из шагов. Поэтому в случае с долгой активацией клиента нужно улучшать сервис и упрощать работу с ним, чтобы клиент быстрее переходил из интересанта в активного пользователя.
— среднесуточное количество показов витжетов на сайтах клиентов — чем больше витжетов использует клиент, тем больше его вовлеченность.
Aquisition cost — не столь важная для SaaS-метрика, так как расходы связаны только с содержанием команды программистов.

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

Часть I / убрать все лишнее, попасть в цель, экспериментировать
Часть 2 / бесценный опыт российских ISV
Часть 3 / продажи через партнерский канал, который, возможно, и не нужен
Часть 4 / cтартап Quickme – коммуникации и совместная работа небольших команд
Часть 5 / повсеместная интеграция SaaS, как милая угроза остальному бизнес ПО или как 1+1 превращается в 3
Часть 6 / Quickme история для партнеров или 7 причин делать дела вместе
Часть 7 предфинал / почему же не продается SaaS?
Часть 8 — ФИНИШ / SaaS — реалии российского рынка
Случайно забытая Часть 9 / Юридический туман SaaS
Часть 10 / Метрики бизнес модели
Часть 11 / Обзоры облачных сервисов / UX и юзабилити тестирование

Блог компании Quickme
SaaS / S+S