Юнит-экономика, монетизация, метрики: информация из учебников vs личные кейсы

Юнит-экономика изучает прибыль и затраты на каждого конкретного пользователя продукта: сколько денег мы потратили на привлечение пользователя (юнита) и сколько денег мы с него заработали.

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

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

Поговорили об этом с Егором Кургузовым — Co-founder в Custle, занимал должность Head of Product в Hurma, спикер курса в IAMPM, сейчас развивает новый продукт. У Егора более 7 лет в Product Management. За это время он запустил два своих продукта: Custle — ML-маркетплейс и Casers — ed-tech платформа, и работал над B2B и В2С software и hardware-продуктами.

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

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

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

Над каким продуктом ты работаешь сейчас?

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

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

Избыток информации — это проблема любого анализа. Оптимальнее выбрать 5 метрик, которые будут соответствовать запросам, чем 20, и не знать, на чем фокусироваться.

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

Одной из методик определения стратегической приоритизации является фреймворк ex-VP/CPO в Netflix, которую он назвал GEM (growth, engagement, monetization). Её суть заключается в том, чтобы в каждой из этих трёх категорий прорабатывать разные метрики, а позже приоритезировать эти группы в зависимости от цели на данном этапе — рост, вовлеченность, монетизация, а после выбрать метрики, основываясь на целях и стратегиях.

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

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

Такие нерезультативные метрики называются vanity metrics — «метрики тщеславия», потому что они поднимают ЧСВ продакт менеджеров или фаундеров, но они никак не связаны с тем, на чем компания фокусируется в данный момент.

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

Если говорить о времени, которое пользователь проводит на странице, это зависит от jobs-to-be-done и от типа продукта. Если человек хочет намеренно совершить какое-то действие (купить, например), то длина сессии должна стремиться к минимуму. Если это entertainment-продукт, то длина сессии должна расти, ведь чем больше контента потребляется, тем выгоднее это можно монетизировать за счет рекламы. В случае с Youtube, метрика, о которой мы говорим, прямо влияет на их revenue. Скорее всего у них на анализ и проработку этой метрики даже выделена отдельная команда.

Кстати, у компаний, в которых 100+ человек, это распространенная практика — «вешать» отдельную команду на каждую из метрик, если они критично важны, или работать с ними по этапам воронки жизненного цикла продукта. Например, в Facebook для отслеживания активации пользователей считали количество юзеров, которые добавили первых 10 друзей в течение 3 дней с момента регистрации. Если человек этого не делал, они его теряли. И я на 90% уверен, что на работу с этой метрикой у них были брошены отдельные силы.

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

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

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

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

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

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

У Youtube это entertainment: происходит монетизация того времени, за которое пользователь потребляет контент, посредством рекламы. Это рекламная модель монетизации. Чем больше времени и контента пользователь потребляет, тем больше рекламы можно показать.

Есть subscription-based, in-app purchases, а есть смешанные модели. Я не осуждаю рекламную модель и может быть мы сами к ней придем, если увидим, что наш продукт отлично подходит для браузинга контента, а не для его создания, но на данном этапе мы хотим лимитировать определенный сет фич и в премиум-пакете раздавать эти фичи полностью. Рекламная монетизация может работать довольно бездумно и неосознанно, если не понимать, где ценность продукт; наша же модель (фримиум) и ей подобные (ин-апы, например) выстраиваются вокруг ключевой ценности продукта.

Ещё один пример — Fortnite — free-to-play игра на плейстейшен и не только, где монетизация происходит за счет продаж скинов. Пользователи хотят выделяться, и Fortnite покрывает эту потребность.

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

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

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

Если же вспомнить прошлое… Был кейс, где мы пытались придумать, как увеличить average revenue B2B Saas-продукта. Проблема была в том, что пользователи юзали систему очень по-разному. Я хотел как-то это провалидировать, чтобы понять, можем ли мы раскидать наши «фичи» по разным пакетам и продавать их отдельно друг от друга разным пользователям. Эта гипотеза была звучала очень здраво, и мы все в нее верили. Факап был в том, что мы решили проверять её слишком досконально. Я углубился в подготовку A/B-тестов, которые мы в итоге не провели. У нас был довольно маленький рынок аудитории, и чтобы собрать репрезентативную выборку по этому A/B-тестированию, нам нужно было проводить его где-то полгода, и он бы стоил нам очень много денег, времени и усилий. Если бы к этому эксперименту из прошлого присоединился я-настоящий, то я бы проверял всё уже в продакшене, на живых людях.

Говорят, что менять модель монетизации в текущем продукте — это одна из худших идей. Пользователи начинают ненавидеть компанию и уходить. Как понять, когда от A/B-тестов нужно перейти к тестам на живой аудитории?

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

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

В одной из предыдущих компаний мы делали персонализированный software для машин. Нашими клиентами были в основном производители автомобилей. Суть модели монетизации в данном кейсе — лицензирование machine learning модулей, которые мы предоставляли. Мы не аутсорсили эту разработку в целом, а приносили «куски» machine learning-а и платформы, в которые их можно было интегрировать.

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

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

На просторах интернета слишком много информации, связанной с юнит-экономикой, монетизацией. Что лично ты чаще всего встречаешь по этим темам и как к этому относишься?

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

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

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

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

Всё зависит от уровня. Для новичка в профессии базовые знания важны. Для тех, кто уже имеет «костяк», информация на общедоступных ресурсах будет повторяться. Таким специалистам нужны узкопрофильные знания.

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

А еще более ценны те кейсы, которые ты сам создаешь в компании, потому что именно они подходят лучше всего конкретному продукту. И очень важно работать над скоростью создания этих кейсов. Time To Market для экспериментов — очень болезненный вопрос для компаний Украины и СНГ, все как правило делают это очень долго.

Где черпать знания начинающим продактам? Как понять: то, что они изучают, — полезно или нет?

Отталкиваться от применимости в своих кейсах! Я и сам так делаю. Если бы я был продактом с опытом примерно год, то собрал бы все гипотезы по своему продукту, разобрался, в какой плоскости они лежат (юнит-экономика, маркетинг и т.д.) и декомпозировал бы их до того момента, пока не вырисуется конкретный вопрос, который непонятен мне или компании в целом. И уже на него искал бы ответ.

Получается, что теоретические знания — не универсальны, и учиться на кейсах гораздо эффективнее?

Да. Во-первых, из кейсов можно узнать довольно креативные пути поиска решения. «10 стандартных способов повлиять на MRR или retention» — как правило, вещи использованные-переиспользованные, и они могут создать какие-то ограничения в креативности. Их уже даже пользователи могут понять со стороны front-end. Во-вторых, кейсы показывают, что и как сработало с учетом контекста. В универсальных чек-листах, например, всё расписано без него, просто шаблонный набор действий.

Ты сторонник какого подхода: проверить, ошибиться и сделать по-другому или тщательно изучить информацию, и только потом делать?

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

А как относишься к продуктовым симуляторам?

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

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

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

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

А еще в реальной жизни может и не быть правильного ответа. Или у тебя может быть два варианта, в которых ты уверен, но всё же нужно сделать между ними wild-ass guess. Поэтому тем, кто хочет разобраться с юнит-экономикой, метриками и моделями монетизации, я бы посоветовал: