Ценообразование на старте монетизации Feeds Fun

Начал рассчитывать цены для пользователей Feeds Fun и понял, что надо это делать в блоге: работы почти столько же, идеологически верно и, что важно, должно быть интересно. Всё равно бы писал RFC — вопрос сугубо в публичности. Заодно проведу для себя некоторую ретроспективу по проекту.

Поэтому встречайте вольное сочинение на тему монетизации B2C SaaS, зависимого от LLM, — актуальнее некуда :-D

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

В целом, по здравому рассуждению, выбор подхода к монетизации на старте проекта — это больше про пользовательский опыт, чем про конкретные суммы. Конкретные числа (включая цены для пользователей) куда проще оптимизировать итерационно, когда есть реальная статистика поведения пользователей. А вот изменить базовое предложение ценности и пользовательский опыт — гораздо сложнее. Разница примерно как между «поменять пару чисел в конфигах» vs «переписать здоровый кусок бизнес-логики и UI».

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

Специфика продукта

Feeds Fun выглядит как «классическая» онлайн читалка новостей — пользователь подписывается на потоки новостей, сервис скачивает новости себе на сервер и показывает их пользователю. Сейчас поддерживаются только RSS и Atom, но в будущем будут и другие источники: соцсети, email-рассылки, автоматический парсинг сайтов, etc.

Самые известные аналоги: Google Reader (ныне почивший), Feedly, Inoreader.

Общая черта всех SaaS читалок — относительно дешёвая серверная инфраструктура:

• Если 100500 пользователей подписано на одну ленту новостей, то вам достаточно одного запроса к этой ленте, чтобы скачать новости для всех пользователей.
• Вам достаточно хранить только одну копию новости.
• Ваш трафик — это текстовые данные небольшого размера без медиа-контента. Медиа обычно хранится на стороне источника новостей или в вашем CDN, если вы боретесь за скорость загрузки.

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

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

Поддержка инфраструктуры дёшева, поэтому большая часть суммы подписки идёт в компанию (разработка, маркетинг, вывод в прибыль). У Feedly, возможно, чуть более сложная ситуация, но эта сложность, скорее всего, проистекает из ориентированности на B2B — не наш случай, позже объясню, почему.

Feeds Fun плохо вписывается в подобную картину. Ключевая функциональность — теги и правила — без них продукт вщент проигрывает более зрелым конкурентам и с одним разработчиком никогда их не догонит.

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

• расходы значительно растут с ростом количества новостей;
• onboarding пользователя через бесплатный тариф стоит денег.

Соответственно, нельзя просто так взять и скопировать подход конкурентов — нужно убедиться, что сервис не обанкротится на первом же пользователе, который подпишется на 100000 новостей в день с какого-нибудь китайского портала. Кстати, это реальный пример из первого года жизни Feeds Fun.

Одна из задач этого поста — вывернуться из этой ситуации самым хитрым образом.

Ограничения

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

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

Путь B2C я выбрал по следующим причинам:

• Я понимаю потоки денег в B2C, а как они ходят в B2B вообще не представляю.
• B2C и B2B предполагают очень разные «вторичные» наборы функциональности. Feeds Fun изначально разрабатывался под мои конкретные нужды и они B2C-ориентированы.
• В перспективе я хочу поэкспериментировать с некоторыми интересными социальными фичами, что предполагает B2C-модель. Google Reader пытался в социализацию, но с ним случился Google.

Это не значит, что я не рассматриваю B2B в будущем, просто надо выбирать приоритеты.

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

Теги и правила — это сложная логика, которая требует сложных интерфейсов.

Тут нет сюрприза. Feeds Fun — это софт для профессионалов, которые хотят осознанно и прозрачно управлять потоком новостей; не хотят доверять ИИ лентам; не хотят читать тонны мусора и AI slop.

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

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

Из этого следует, что:

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

Отдельно замечу, что правила для Feeds Fun обходятся дёшево, поэтому вопрос сугубо в стоимости тегов.

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

Был бы условный Tinder для новостей: свайп влево, свайп вправо, подарок контент-мейкеру. Кстати, берите идею в работу, думаю она вполне годная.

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

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

Критерий будет использоваться в следующем виде: «мы отбрасываем вариант по «критерию путаницы», так как …».

В-пятых, мы будем считать пессимистичные сценарии, так как по ним проще делать оценки, а если пессимистичный сценарий проходит, то оптимистичный пройдёт тем более.

Это значит, что:

• Траты мы будем предполагать максимально возможные по сценарию.
• Доходы мы будем предполагать минимально возможные по сценарию.

Как будем оценивать монетизацию

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

Свойства устойчивого свечного заводика:

• Устойчивость — поток новых пользователей равен потоку уходящих.
• 1000 подписчиков — хороший стабильно работающий инди SaaS. Большинство до этого уровня не доживает.
• 20000 $/месяц Modified Margin — уровень дохода, при котором можно как комфортно работать в одиночку, так и искать напарников за долю и деньги. См. термины ниже.

Иными словами: мы будем искать логику монетизации и цены, при которых сервис приносил бы 20000$ modified margin при 1000 подписчиках.

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

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

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

Пространство вариантов монетизации

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

Что должен включать в себя наш подход к монетизации:

1. Тип бесплатного тарифа — как мы убедим пользователя заплатить.
2. Наличие классической подписки — будем ли мы продавать доступ к сервису за фиксированную плату.
3. Наличие токенов — будем ли мы продавать токены на обработку новостей.
4. Политика учёта квот — как мы будем считать потребление квот подписки и токенов.
5. Место маржи в ценообразовании — куда мы заложим маржу и в каком объёме.
6. Доля Gross Margin в ценах — какую долю от цены будем отдавать на обслуживание (COGS), какую оставлять себе (GM).

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

Бесплатный тариф

Варианты:

Без бесплатного тарифа — никакого freemium, только платная подписка. Как бы это странно ни звучало, но есть много аргументов «за»: от мощной экономии на инфраструктуре, до подчёркивания профессиональности/ценности продукта.

Доступ к ограниченной коллекции протеганых новостей — Пользователь может подписываться на любые потоки новостей, но без подписки нельзя добавить свои источники. В Feeds Fun сейчас есть две коллекции: статьи с ArXiv.org и новости на тему стартапов.

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

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

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

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

Подписка и токены

Объединим эти две оси в одну, так как они тесно связаны между собой.

Варианты:

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

Я остановился на варианте «подписка + докупка токенов» с двумя вариантами подписок:

1. Подписка для начинающих пользователей.
2. Подписка для продвинутых пользователей.

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

Учёт квот

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

Более того, Feeds Fun сейчас эту фичу использует. Пользователи могут ввести OpenAI/Gemini API ключ, чтобы размечать свои новости. Если два пользователя подписаны на один и тот же источник новостей, то их ключи будут использоваться по очереди, а значит, каждый потратит в два раза меньше денег.

Поэтому, в теории возможны два подхода к квотам:

• От реально потреблённых ресурсов — одна новость засчитывается как один токен для одного из подписчиков на её источник.
• От принесённой ценности пользователю — одна новость засчитывается как один токен для каждого подписчика на её источник.

Подавляющее большинство SaaS продают именно ценность для пользователя.

Комментарии

Организация оплаты от реально потреблённых ресурсов выглядит привлекательной и «справедливой», но у неё есть ряд серьёзных минусов.

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

Люди разные, не все люди морально готовы по умолчанию делиться профитом, который они получили за собственные деньги. Особенно, если правила разделения профита не кристально чёткие и прозрачные.

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

Поэтому мы отбрасываем этот вариант по «критерию путаницы».

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

Квоты от потреблённых ресурсов были бы интересным вариантом для общественного сервиса вроде Wikipedia, но я не того масштаба деятель :-D

В то же время, хочется наносить общественное благо и помогать пользователям делать это. Для этого я вижу следующие инструменты:

1. Инвестирование в официальные доступные для всех коллекции новостей. Например, я бы хотел предоставлять бесплатный доступ ко всем научным новостям на планете. Было бы круто.
2. Функциональность для шаринга коллекций через осознанный выбор подписчика. Хочешь — шаришь для друзей, хочешь — для всех, не хочешь — не шаришь.

Соответственно, наш вариант — это отдельно рассчитывать квоты для каждого пользователя.

Маржа

Маржа может быть:

• в подписке;
• в токенах;
• и в подписке и в токенах.

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

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

Получается что-то вроде цена токена базовой подписки > цена докупки токена на базовой подписке > цена токена продвинутой подписки > цена докупки токена на продвинутой подписке.

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

Доля Gross Margin в ценах

Формировать цены мы будем исходя из возможной доли GM по отношению к COGS на одного пользователя. Соответственно, цену можно задавать напрямую как COGS * N, где N = 1 / (1 - GM%).

Будем рассматривать следующие варианты для N:

• x2 — GM = 50% — высокие траты на обслуживание, низкие доходы, любая ошибка и ты ошибся.
• x3 — GM = 66% — пациент скорее жив.
• x4 — GM = 75% — пациент жив и даже может ходить, этот уровень добавлен постфактум, так как на него интересно смотреть на стенде внизу поста.
• x5 — GM = 80% — нижняя планка стандартной SaaS маржи. Да, интернеты говорят, что самая распространённая наценка для SaaS — это x5-x10 к затратам.
• x6-x9 — здоровые промежуточные значения, добавлены постфактум, так как на них интересно смотреть на стенде внизу поста.
• x10 — GM = 90% — верхняя планка стандартной SaaS маржи.
• x20 — GM = 95% — очень хорошая маржа. Если мы тут и у нас есть пользователи, то всё в шоколаде.

Выбирать на старте маржи x2-x3, на мой взгляд, выглядит очень опасным решением для проекта вроде Feeds Fun, так как любая ошибка в расчётах или в коде может моментально обнулить проект.

Стоимость привлечения пользователя и доля отмены подписок

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

• Стоимость привлечения пользователя (Customer Acquisition Cost — CAC).
• Доля отмены подписок (Cancellation Rate — CR).

Я не выделил их в оси, так как:

1. Это внешние параметры — мы можем их оптимизировать, но не можем задавать напрямую.
2. Их значение сейчас неизвестно. Тестовая закупка пользователей показала хорошую цену клика, но очень плохую конверсию в регистрации. Я это связываю с неудобным интерфейсом (который надо дорабатывать) и сложностью получить пользу от читалки (надо было вводить API ключи).

Поэтому будем использовать пессимистично-средние значения (выбраны на глаз после гугления и общения с ChatGPT):

• CAC = 100$ (пессимистичное значение для среднего SaaS — 50$, но поскольку у нас сложный продукт, то я решил взять x2).
• CR = 5%

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

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

Модель свечного заводика

Чтобы рассчитать экономику, нам нужно:

• Знать часть Cost of Goods Sold, которая уходит на обработку одной новости.
• Знать часть Cost of Goods Sold, которая уходит на поддержание всего сервиса (сервера, привлечение новых пользователей, НДС, etc.).
• Оценить целевую аудиторию — какое потребление новостей мы можем ожидать от пользователей.

Оценка количества новостей

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

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

Вот статистика по каналам и новостям (за 30 дней) для активных пользователей с API ключами. Из статистики исключены официальные коллекции, так как они доступны всем. Всего таких пользователей 11 человек, включая меня и жену :-D

Обратите внимание, количество новостей не коррелирует с количеством каналов.

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

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

1. Начинающие — до 100 новостей в день.
2. Продвинутые — от 100 до 1000 новостей в день.
3. Хардкорные — от 1000 новостей в день и больше.

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

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

1. 80% начинающих — 0-99 новостей в день.
2. 16% продвинутых — 100-1000 новостей в день.
3. 4% хардкорных — 1000-… новостей в день.

Это довольно сильное допущение, но лучших альтернатив у нас нет.

Стоимость обработки новости

Стоимость обработки новости состоит из:

1. Стоимость скачивания новости — часть потоков можно нормально получать только через прокси.
2. Стоимость исходящих токенов для LLM (размер тела новости).
3. Стоимость входящих токенов для LLM (размер ответа с тегами).

Прокси очень дешёвые. Сейчас они выходят где-то $0.000004 за новость.

Размер новостей сильно варьируется. Более того, полное тело новости не всегда попадает в RSS поток. Однако, поскольку мы следуем пессимистичному сценарию, то давайте считать новостями половину большого эссе (10000 символов) — 5000 символов. Брать целое эссе рука не поднимается — это слишком много даже для моих подписок. 5000 английских символов — это примерно 1250 токенов.

На текущий момент на одну новость в среднем приходится 50 тегов. Большинство тегов меньше 33 символов (95% из них) — значит в «чистом» ответе будет примерно 1650 символов. Проблема в том, что текущий промпт предполагает дополнительный текст в ответе, поэтому умножим это число на 2. Получается 3300 символов, что примерно равно 825 токенам.

По ценам на gpt-4o-mini-2024-07-18 (используется сейчас):

• Входящие токены: 1250 tokens * $0.15 / 1M = $0.0001875 за новость.
• Исходящие токены: 825 tokens * $0.60 / 1M = $0.000495 за новость.

Итого, стоимость обработки одной новости составляет

+ $0.0000040
  $0.0001875
  $0.0004950
  ----------
  $0.0006865

Стоимость поддержки сервиса

Стоимость поддержки сервиса состоит из:

1. Стоимости аренды сервера. Сейчас 75$ / month, пусть будет 200$ / month с запасом на рост.
2. Суммарной стоимости возмещения убывших пользователей — 1000 (subscribers) * 0.05 (CR) * 100$ (CAC) = 5000$ / month.
3. Комиссии платёжных провайдеров. Мы будем ориентироваться на самую большую комиссию Stripe: 2.5% + 0.30$ per transaction, без учёта меньших комиссий в некоторых локациях. Stripe умеет агрегировать все платежи в один инвойс за период, поэтому нам не нужно моделировать несколько транзакций на одного пользователя.
4. Стоимости дефолтных коллекций новостей. Сейчас это 50$ / month, пусть будет 500$ / month с запасом на рост.

Прочие затраты

1. Налог на добавленную стоимость (НДС) — величина зависит от страны пользователя, но пессимистично его можно оценить в 25% от доходов.

Сценарий монетизации

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

1. Пользователи могут использовать Feeds Fun без подписки, но теги будут только у дефолтных коллекций новостей.
2. Два тира платной подписки с докупкой токенов сверх квот подписки.
3. Мы строим оплату сервиса на основе принесённой ценности пользователю, поэтому квоты рассчитываются отдельно для каждого пользователя.
4. Наша аудитория — это 80% начинающих пользователей (до 100 новостей в день), 16% продвинутых (100-1000 новостей в день) и 4% хардкорных (больше 1000 новостей в день).
5. Плюс все параметры, которые мы определили ранее.

Модель ценообразования

Параметры

• Cost of Goods Sold per news — цена обработки одной новости.
• Server cost — стоимость аренды сервера.
• Default collections cost — стоимость дефолтных коллекций.
• News size (chars) — размер одной новости в символах.
• Input price (1M) — цена входных токенов за 1 млн.
• Output price (1M) — цена выходных токенов за 1 млн.
• Customer Acquisition Cost — стоимость привлечения одного пользователя.
• Cancellation Rate — доля отмены подписок в месяц.
• VAT — налог на добавленную стоимость.
• Audience size — размер аудитории.
• Beginner min consumption — минимальное потребление новостей новичками (в день).
• Beginners (fraction) — доля новичков.
• Beginners (max news) — максимальное потребление новостей новичками (в день).
• Advanced (fraction) — доля продвинутых пользователей.
• Advanced (max news) — максимальное потребление новостей продвинутыми (в день).
• Base subscription quota — квота базовой подписки в новостях в день.
• Professional subscription quota — квота продвинутой подписки в новостях в день.
• Base token price margin — маржа на токен базовой подписки.
• Token price discount — шаг скидки на каждый следующий уровень подписки.

Распределение пользователей по подпискам и потреблению новостей

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

Мы будем использовать следующие допущения:

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

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

В-третьих, чтобы исключить совсем халявные сценарии (вроде 1 новость в день), мы зададим минимальное потребление новостей для «начинающих» пользователей.

Определение количества новостей для пользователя:

1. Распределим пользователей по группам (начинающие, продвинутые, хардкорные).
2. Для каждой группы зададим минимальное и максимальное потребление новостей в день.
3. Для каждого пользователя в группах «начинающие» и «продвинутые» зададим конкретное потребление новостей в день с помощью лог-равномерного распределения между минимальным и максимальным потреблением.
4. Для всех пользователей группы «хардкорные» зададим конкретное потребление новостей в 1000 новостей в день. Предполагая, что сверх этого они докупать токены не будут (мы считаем пессимистичную оценку).

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

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

Моделируем

Тепловая карта Modified Margin

Цены подписок

Таблица для быстрой оценки стоимости подписок в зависимости от маржи и шага скидки.

Стоимость новостей

Таблица для быстрой оценки стоимости обработки новостей для пользователей с разным потреблением.

Выводы

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

VAT и CAC доминируют в потерях

VAT и CAC больше, чем стоимость токенов. Для меня это главное открытие.

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

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

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

Доминируют доходы от начинающих пользователей

И это сказывается на оценке суммарного дохода.

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

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

Большая неопределённость

Полученная модель имеет огромное количество свободных параметров — 19!

Поэтому:

1. Уточнить её без реальных данных от реальных пользователей Feeds Fun не получится.
2. Оптимизация монетизации (после включения до приемлемого состояния) может занять очень большое время и потребовать существенное количество денег.

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

Пойти, что ли, инвесторов поискать.

20000$/месяц не достижим при разумных параметрах

Зато достижим 10000$/месяц — тоже неплохо и всё ещё оптимистичная цель.

20000$ можно получить выкручивая маржу, но одновременно это выкручивает стоимость подписок до VIP уровня, качество сервиса для которого в одиночку у меня вряд ли получится обеспечить.

Выбираем цены

Для выбора ориентировочных цен я сформировал ряд эвристик:

1. Понижать цены значительно проще, чем повышать. Поэтому лучше выбрать завышенные цены, чем заниженные.
2. Маржа x2-x3 выглядит очень рискованно для проекта типа Feeds Fun.
3. Иметь цену базовой подписки x2-x4 от цены конкурентов нормально для нашего случая. Иметь бОльшую разницу выглядит рисковано.
4. Я попадаю в категорию «хардкорных пользователей» и мне комфортно платить 50$-100$ / месяц за свои 500-1000 новостей в день. Комфортнее, конечно, 50$.

Итоговые параметры:

• Квота базовой подписки — 100 новостей / день.
• Квота профессиональной подписки — 500 новостей / день.
• Маржа — x9.
• Скидка шага — 20%.

Это даёт нам:

• Цена базовой подписки — ~18.5$/месяц, можно устанавливать в 20$/месяц.
• Цена профессиональной подписки — ~55.5$/месяц, можно устанавливать в 50$/месяц.
• Мои траты как хардкорного пользователя будут в пределах 50$-100$/месяц, скорее около 70$/месяц, что ок.
• Modified Margin — ~11000$/месяц — не 20000, но жить можно.