Салют! 🖖 P.P.S. Такие и многие другие вопросы разбираем на Product Heroes. Старт следующего сезона — 4 августа по 2 сентября 🔥 __Забирай свое место на сайте ____heroes.camp____ и пиши в Ботика, если возникли вопросы: ____@RuleThem_bot__ Один из вопросов на разборах последние месяцы: «У нас Яндекс Плюс / VK Music+ / Сбер Прайм / любая мультипродуктовая подписка. Внутри 5-10 сервисов. Acq Costs общие. Как считать юнит-экономику каждого продукта?» Дальше команда обычно делает то, что мозг 🧠 любит больше всего, делает простое объяснение: берет общие расходы на привлечение, делит на всех подписчиков, получает один CPUser. И вот тут начинается магия объяснительной модели ☠️. На таких данных все продукты выглядят либо одинаково окупаемыми, либо одинаково убыточными. Решения принимаются на основе этой средней температуры по больнице. Развивают не тот продукт, режут бюджет не тем. И через полгода смотрят на печальную картину. [ 1 ] Корневая ошибка: подписчик ≠ пользователь продукта. Человек оплатил Плюс ради скидки на такси и ни разу не открыл Музыку — логично, что он не должен попадать в знаменатель CPUser Музыки. Иначе вы распределяете расходы по людям, которые ваш продукт в глаза не видели. Юнит-экономика, как нас учил Шелдон, бессердечная сука 😈. Она не прощает усреднения. Но есть нюанс: в реальности продукт редко живет в вакууме. Он влияет на удержание, возвращаемость и общее потребление подписки — и это часто не видно в простом CPUser. [ 2 ] Поэтому что делают чаще всего. Раскладывают косты на: — product-specific Acq Costs — то, что вы потратили на привлечение конкретно в Кинопоиск, конкретно в Музыку. Это часто видно по utm и креативам. — subscription-wide Acq Costs — то, что вы тратили на саму подписку (Плюс как продукт). Дальше формулы из курса Product Heroes: CPUser = Acq Costs / Users Acq Costs = Users × CPUser Где Users — это пользователи именно этого продукта внутри подписки. Это не подписчики и не MAU всей подписки, а конкретные люди, которые в этом периоде активировались в JTBD-сценарии продукта (послушали трек, посмотрели фильм, прочитали книгу). Subscription-wide часть привязываем к продукту через долю активированных пользователей этого продукта от общей базы подписки. [ 3 ] Что сделать, чтобы разобраться: — разложить Acq Costs на product-specific и subscription-wide — по каждому продукту определить Users по активации в JTBD-сценарии — посчитать CPUser отдельно по каждому продукту — дальше стандартное дерево: AMPU = AMPPU × C1 — и обязательно строить и смотреть на когорты — для подписочной модели без этого CPUser не дает ответа на вопрос, окупается ли — сравнить CPUser продукта внутри подписки с CPUser аналогичного продукта вне подписки Самое интересное⚱️, у вас почти гарантированно найдется 1-2 продукта, которые живут за счет остальных. И 1-2 продукта, которые вытягивают всю экономику подписки на себе. Это видно в разрезе по CPUser продукта сразу. [ 4 ] И главное, ради чего это все. Когда CPUser посчитан правильно, разговор с CEO/CPO/инвестором меняется. Объяснительная модель руководства начинает опираться на данные, а не на ощущение, что «Плюс же популярный, значит все ок». А это, как я писал раньше, и есть главное узкое место роста бизнеса — это голова менеджеров и собственников. P.S. Если у вас в подписке 3+ продукта и вы до сих пор считаете один общий CPUser — попробуйте на этой неделе разложить хотя бы по топ-3. Картина мира поменяется 🙂