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

Что такое Feeds Fun

Feeds Fun — это моя читалка новостей, которая с помощью LLM прикрепляет теги к каждой новости, а пользователи могут создавать правила в духе elon-musk + mars => -100, nasa + mars => +100. Это позволяет очень эффективно фильтровать поток новостей, сокращая его процентов на 80-90% (мой личный опыт) и при этом никаких секретных алгоритмов Google или Facebook — всё прозрачно и под вашим контролем.

Поэтому встречайте вольное сочинение на тему монетизации 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 в будущем, просто надо выбирать приоритеты.

Я открыт для контактов на тему B2B

Представьте, что у вас есть поток протеганных обновлений со всего вашего бизнеса: чатов, коммитов, документации, таск-трекеров, email-рассылок, etc. И вы хотите приоритетно видеть длинные сообщения от лида Васи, но не хотите видеть ничего от маркетолога Пети, но только если Петя не пишет про планирование кампаний в LinkedIn на тему Fusion energy.

Выглядеть правила для такой приоритезации будут примерно так:

• lead-vasya + long-text => +1000
• marketer-petya => -100
• marketer-petya + notion-docs + linked.in + fusion => +1100

Пощупать, как работают теги, можно на готовых стендах:

• Последние статьи с ArXiv.org
• Новости на тему стартапов

Пишите в личку, покажу что-как прямо на своих новостях.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А, собственно, зачем монетизировать?

Без ответа на этот вопрос не получится определить успешность монетизации.

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

Включение монетизации в данном случае — это:

1. отличный milestone зрелости продукта;
2. возможность организовать небольшой сторонний доход;
3. возможность наконец стать независимым от найма, организовать свой свечной заводик;
4. крутой пункт в резюме;
5. всё равно нужно разбираться с бухгалтерией в Германии, почему бы не начать с монетизации пет-проекта;
6. интересный и полезный опыт.

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

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

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

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

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

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

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

Важные термины

Cost of Goods Sold (COGS) — себестоимость проданных товаров/услуг — в нашем случае это стоимость LLM запросов, инфраструктуры, комиссия платёжных провайдеров, etc.

Gross Margin (GM) — валовая маржа — разница между доходами и COGS.

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

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

Классическая Gross Margin не включает в себя маркетинг и Налог на Добавленную Стоимость (НДС), поэтому для целей поста мы будем использовать собственный термин — Modified Margin.

Customer Acquisition Cost (CAC) — стоимость привлечения клиента — сколько денег в среднем уходит на маркетинг, чтобы получить одного платящего клиента.

Cancellation Rate (CR) — процент оттока клиентов — сколько процентов платящих клиентов отваливается за определённый период времени, обычно за месяц.

Modified Margin (MM) — маржа модифицированная на маркетинг и налог на добавленную стоимость (НДС). В этом посте MM = GM - CAC * число новых клиентов в месяц - VAT, даже более точно MM = GM - N * CR * CAC - VAT, где N — текущее число подписчиков, VAT — налог на добавленную стоимость. N * CR * CAC говорит о том, что мы докупаем столько подписчиков, сколько отваливается.

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

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

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

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

Оставим за скобками процесс анализа

Не буду описывать, как я пришёл к этим осям — это результат размышлений над проектом во время разработки, гугления, чтения, общения с ИИ, etc. То есть это скорее концентрация накопленного опыта, чем проделанная единоразовая работа.

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

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

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

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

Варианты:

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

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

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

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

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

Комментарии

«Без бесплатного тарифа» проигрывает «ограниченным коллекциям». Коллекции позволяют пользователям пощупать всю функциональность читалки без фрустрации.

«Ограниченные коллекции» выигрывают у «ограниченных коллекций + новости без тегов» по кажущейся простоте реализации и понятности, но начинают проигрывать, если вдаваться в детали:

1. Возможность добавлять свои источники — это ключевая функциональность любой читалки новостей. Не иметь её — значит сильно фрустрировать пользователей.
2. Появляется много вопросов о поведении в частных случаях. Например, что делать, если подписчик отменил подписку, — должны ли его новости «пропасть»?

Мы отбрасываем «бесплатную разметку с квотами» по «критерию путаницы», так как либо квоты будут слишком маленькие и пользователи не смогут пощупать продукт, либо слишком большие и мы будем нести убытки на старте.

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

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

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

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

Примечания

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

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

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

Логика токенов предполагает простую конверсию: 1 токен = 1 обработанная новость. БОльшая детализация слишком сложна для восприятия, непрозрачна и затрудняет модификацию алгоритмов разметки в будущем, так как любая модификация изменяет траты ресурсов на обработку новости.

Говоря о докупке токенов, я имею в виду автоматическую докупку с лимитами на количество докупаемых токенов в день/месяц, так как ручная докупка слишком неудобна.

Варианты:

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

Комментарии

«Подписка без токенов» — самый простой вариант. Может быть в разных видах от «несколько радикально отличающихся по квотам» до «сотня подписок с шагом квот в 100 новостей/день».

«Только токены» мы отбрасываем по «критерию путаницы» — считать токены никто не любит. Чистая токенная модель больше подходит для сервисов с непериодическим использованием или меняющейся нагрузкой, например, для продажи API.

«Подписка + докупка токенов» позволяет пользователю быть более гибким. Например, некоторые источники новостей проявляют цикличность с пиками нагрузки (по рабочим дням, по выходным, в последний день квартала и etc.). В такие периоды докупить токены пользователю будет удобнее, чем потерять новости.

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

Есть ещё немного семантически отличающийся вариант «единственная базовая подписка + токены», когда мы подчёркиваем, что пользователь платит фиксированную сумму за доступ к сервису и отдельно платит за обработанные новости. Этот вариант мы рассматривать не будем, так как сервис не предоставляет большой ценности без тегов и правил, а значит базовая подписка будет выглядеть странно.

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

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

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

Учёт квот

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

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

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

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

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

Комментарии

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

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

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

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

Классическое изображение одного из аспектов вопроса.

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

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

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

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

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

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

Маржа

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

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

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

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

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

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

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

Повторяем материал

Тут вы можете захотеть вернуться в начало поста и перечитать блок «Важные термины», содержащий определения для Gross Margin (GM) и Cost of Goods Sold (COGS).

Формировать цены мы будем исходя из возможной доли 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, так как любая ошибка в расчётах или в коде может моментально обнулить проект.

Комментарии

Это очень грубый расчёт, есть множество нюансов, которые он упускает. Например, 1000500 пользователей с маржей в 1$ и 10 пользователей с маржей в 100000$ — это совершенно разные ситуации.

Вот интересный практический разбор влияния цены на продажи и доходы.

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

Повторяем материал

Тут вы можете захотеть вернуться в начало поста и перечитать блок «Важные термины», содержащий определения для Customer Acquisition Cost (CAC) и Cancellation Rate (CR).

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

• Стоимость привлечения пользователя (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 критически важно количество новостей, а для всех прочих читалок — количество источников, то найти объективную релевантн