Привет Хабр! Я — Вадим, и жить не могу без запуска своих пет-проектов. Делаю их из любопытства, чтобы лучше изучить какой-то продуктовый вопрос.
Ещё люблю играть на гитаре, и недавно мы с друзьями запустили тг-бота, чтобы придуманные в процессе игры идеи не терялись в диктофоне, а сразу превращались в готовые песни.
На его примере и расскажу о том, как собираю дашики, чтобы получать ответы на те самые продуктовые вопросы.
Интро
Ещё пяток лет назад тема управления продуктом на основе данных была окружена каким-то магическим ореолом. Но сейчас про DAU, MAU и C0 знают даже продавцы на Wildberries, а Михаил Гребенюк на ютюбе топит за рост продуктовых метрик.
Одна из базовых задач менеджера продукта — собрать дашборд, который отражает вверенный ему участок пользовательского опыта. Тем не менее, вижу на собесах ребят, которым не так уж и легко сформулировать структуру дашборда.
Давайте навалим базы и разберёмся с этим на живом примере аналитики нашего ботика, который превращает гитарные риффы в полноценные аранжировки: https://t.me/intnekotechbot
На его технике останавливаться не буду — это агрегатор готовых сервисов. С максимально простым UX, без регистрации и смс. И даже без установки приложений.
Рассказываю, чтобы передать контекст — зачем вообще городить дашборд, ведь всё вроде понятно. Кстати, давайте разберёмся, что значит «понятно», и что значит «всё».
Зачем это всё
Cамая важная часть (без шуток) — это разобраться, зачем же мы вообще что-то делаем. Зачем продукт нужен пользователю, и зачем он нужен нам самим?
Любой продукт — это идея ценности, заключённая в техническую систему. Служит она, как минимум, двум персонажам: пользователю и разработчику. Пользователь приходит в продукт и платит деньги за ценность. А разработчик на эти деньги приводит следующего пользователя и круг повторяется.
Но сложность в том, что БУКВАЛЬНО в таком виде работают только очень простые системы. В реальности всё сложнее, и зависимость между фактами прихода пользователя и оплатой возникает куча факторов: от UX и багов, до погоды и дня недели.
Именно поэтому важно выделить конкретные продуктовые метрики, на которые мы можем повлиять со стороны продукта. Давайте прикинем, какие задачи должен решать бот, и какими метриками его снабдить.
Задачи бота
Перед тем как строить даш, прям сильно чётко поймём, зачем мы вообще делаем продукт. В случае ботика задач две — продуктовая и бизнесовая:
Продуктовая
Идея ценности — дать музыкантам способ быстро и просто превращать риффы в полноценные аранжировки. UX должен быть лёгким, результат — быстрым.
Хотим понять, насколько эта идея вообще интересна.Бизнесовая
Запромптить готовые сервисы (Suno, Udio или что-то ещё) для генерации аранжировок — норм идея. Но работают они не во всех случаях хорошо. Клёво было бы сварить свою модель, но это дорого и тяжело.
Давайте прикинем, сможем ли (и за какой ресурс) мы ботом собрать и разметить целевые данные для обучения, чтобы наша модель начала решать задачу лучше остальных.
Хотим понять, насколько хорошо мы сможем собирать данные, сколько это стоит и где узкие места.
Отлично, цели сформулированы, 90% работы сделаны. Осталось всего лишь проделать вторые 90% работы — выбрать систему аналитики, расписать события и накликать дашборд.
Система аналитики
Все системы аналитики то и дело подвирают, плюс у них разные ограничения. Я в своих проектах использую 2 системы аналитики, особенно если это приложения:
Amplitude, как основную. Самая удобная система. Must have для микропроектов, но становится очень дорогой по мере их роста
Firebase, как вторичную, чтобы иной раз проверить не врёт ли Амплитуда. Ну и потому что Firebase очень легко добавить вместе с трекером крешей Crashlytics и другими полезными гугло-сервисами
Все примеры ниже буду показывать на примере Amplitude.
Что можно делать в боте
Чтобы написать события, нужно понимать, какие вообще есть функции — по какому пути проходит пользователь, чтобы получить ценность.
В ботике путь до ценности прост:
Играешь рифф и загружаешь его как файл или голосовуху (или выбираешь из списка загруженных, как на картинке)
Выбираешь стиль и настроение аранжировки, нажимаешь «Generate!»
Если результат нравится — можно распилить его на стемы (мультитрек)
Вот и весь UX. Запустили, попробовали сами, показали первым пользователям, исправили детские ошибки. Теперь — как на него навесить аналитику.
События: как логировать
Событий можно налепить сколько угодно. Но если делать это без системы — дашборд превратится в мусор, события будет сложно найти, легко ошибиться. Вот моя логика именования:
<экран / сущность><тайминг (did/will)><действие>
Примеры:
bot_did_start — пользователь стартанул бота
riff_did_upload — загрузил файл или голосовуху
generation_did_success — генерация завершилась успешно
generation_menu_add_mood_did_tap — в меню генерации ткнули в кнопку добавления настроения
Мне так удобно именовать и потом искать события.
В каждой событие можно добавить параметры, по которым можно будет настраивать разные операции в аналитике:
смотреть распределение параметров (например, логируем параметр выбранного настроения и смотрим распределение выбранных настроений),
подсчитывать среднее (логируем длину загруженного риффа в секундах и потом смотрим медиану)
ну и так далее
Также полезно при регистрации нового пользователя добавить параметры пользователя (это отдельный метод в Amplitude), типа источника трафика, контакт, язык и т.д.
Обычно я собираю события в таблице — чтобы было понятно, что мы логируем, какие параметры у события, и как они связаны с воронкой.
Вот эта таблица, я все проекты собираю по одному шаблону: https://docs.google.com/spreadsheets/d/1cCgYT8lkHSBd0eBi-_m3R-tXC983Y_habY4hNFE4640/edit
В ней всё понятно. Программируем, отмечаем события, уже добавленные в код, чтобы ничего не пропустить. Тестируем через инструмент live events — все события должны приходить и равно столько раз, сколько отправили.
Наливаем сотню-другую пользователей забесплатно. Для этого рассказываем о боте в соц сетях, бложике, профильных пабликах.
Ну ура, графики и выводы
События полетели, теперь у нас есть зрение в продуктовом смысле. Давайте прикинем, какие графики нам нужны и сделаем какие-то выводы. Как вы помните, задачи у нас две — продуктовая и бизнесовая.
Продуктовая: Воронка ценности
Чтобы понять, норм ли продукт, важно понять, какая доля аудитории получила ценность. Это наша воронка:
Шаг 1: зашёл в бота (100%)
Шаг 2: начал генерить (45% от Шага 1)
Шаг 3: сгенерил аранжировку (41% от Шага 1)
Шаг 4: замультитречил аранжировку (14% от Шага 1)
Вывод: половина пользователей не доходит до генерации. Скорее всего, это связано с привлечением — с наших соц сетей зашли нецелевые ребята просто из любопытства. Найдём пяток никнеймов из тех, кто сервисом не воспользовался и спросим.
А дальше всё в норме — почти все, кто начал генерить заканчивают, а треть ещё и пользуются мультитреком. Вроде огонь!
Продуктовая: retention, или удержание
Главный продуктовый грааль — насколько ценность зашла пользователям ≈ насколько хорошо они к ней возвращаются.
Наш сервис для музыкантов, которые занимаются музыкой ежедневно, поэтому и retention будем смотреть по дням (а можно ещё по неделям и месяцам).
Сегменты пользователей разделим по получению ценности:
Синий. Вообще все, кто зашёл в сервис (угадывается плато 10-15%). Initial event — New User. Retention event — any active event
Зелёный. Получившие ценность генерации (плато 20-25%). Initial event — generation_did_success. Retention event — any active event
Фиолетовый. Получившие ценность мультитрека (плато 45-50%). Initial event — multitrack_did_success. Retention event — any active event
Плато на этом графике (когда линия идёт параллельно оси X и не пересекает её) означает, что пользователи регулярно возвращаются в продукт. То есть, продукт действительно обладает ценностью, способен накапливать аудиторию.
В нашем случае угадывается плато до 10 дня, а дальше тренд на исход аудитории. Связано это скорее с таймингами закупки ауитории (на момент скрина ещё не прошло 2 недели с набора первичной аудитории). Ну и продукт не идеален конечно.
Вывод: график, на котором угадывается плато — это отлично. Чем глубже человек дошёл до ценности — тем выше его возвращаемость. А мультитрек — вообще жир. Кажется, сервис работает.
А где же DAU/WAU/MAU?
А это не совсем, в общем-то, продуктовые метрики. На них влияют не только, как хорош сам продукт (какая в DAU доля пользователей, вернувшихся в продукт), но и насколько хорошо мы привлекаем новых пользователей.
На дашборд их выведем, но относиться будем, как к метрикам здоровья продукта (насколько там вообще есть жизнь).
А заодно добавим график новых пользователей, чтобы понимать, как отдельно работает привлечение. В идеале добавить источник трафика, но пока можно и без него.
Выводы: несмотря на не самые плохие продуктовые метрики, абсолютные значения ежедневной активности слабоваты, хочется на порядок больше.
Бизнесовая: Data Performance и Generations Total Funnel
Ну хорошо, ценность вроде есть. Дело за малым — понять насколько бот хорош, как сборщик данных.
— Data Performance. Сколько у нас генераций, загрузок и мультитреков — по дням. Видим спады, всплески, оцениваем эффективность маркетинга и обновлений.
— Generations Total Funnel. Общее число попыток. Отсюда понятно, когда пора собирать партию для обучения своей модели.
Вывод: тысяча собранных треков — это, конечно, капля в море, но уже что-то. Обучать модель рано, но принцип сбора данных может и сработать. Пора эти собранные данные учиться размечать в датасеты.
Бизнесовая: Разнообразие загружаемых и генерируемых данных
Надо, чтобы генерации шли от разных пользователей, в разных жанрах. Разнообразие = качество будущей модели.
Смотрим на столбики, должны быть разноцветными. Если не разноцветные — что-то надо придумывать для ограничения действий конкретных пользователей.
Вывод: загрузки достаточно разноцветные, проблем нет. А вот в генерациях есть всплески от топ-перформеров. Чтобы не получить при обучении модели домейн шифт в их данные, придётся снижать их долю. Это удорожает датасет.
Бизнесовая: Genres Distribution
Топ самых важных жанров, в которых наша модель должна работать хорошо.
Вывод: ТОП-7 жанров в целом похож на наше представление о фокусных срезах для модельки. Но статистическая значимость на таком объёме, конечно, минимальная. Хотелось бы выборку побольше.
Итог
Вот так всё просто. Но, конечно, это только начало.
На этих графиках мы видим только базовые метрики. Но чтобы делать продукт лучше, важно углубляться:
разбираться почему именно такое падение в trial нашего бота,
хорошо ли подходит система промптинга через жанры / настроения,
и так далее.
На каждом из продуктовых этапов неплохая идея — выбрать единственную ключевую метрику, под которую подстраивать продукт: NSM (North Star Metric).
Например, прямо сейчас в боте я смотрю на среднее количество сгенерированных треков на пользователя.
Но дальше NSM может меняться, исходя из задач бизнеса (здесь бизнес — обобщённое название для разработчика продукта, никакого бизнеса за ботом нет, есть я). Может быть, в какое-то время начну смотреть на total количество сгенерированных минут или ещё чего.
А ещё нужно углубляться в метрики качества генеративки. Но это вообще другая история, которую мы как-нибудь рассмотрим в другой статье, иншалла ^__^
В заключение
Спасибо, что читаете это! Инфа очень базовая, но надеюсь, что пример применения в реальном проекте был полезен.
А вообще ботик — это кусочек более крупного, но всё ещё пет-проекта, который мы делаем с небольшой командой. Это Neko — hardware-гаджет для гитаристов и музыкантов.
Если вам интересна тема разработки железок, AI, или просто понравилась коробочка, забегайте и в канальчик, я там пишу о проекте: https://t.me/smirnov_ceo
Спасибо! \m/