Себестоимость одного активного пользователя: считаем по счетам за месяц

MAATRIX

Когда продукт растёт, рано или поздно кто-то — инвестор, финансовый директор или вы сами в три часа ночи — задаёт вопрос: сколько нам стоит один пользователь? Ответ часто пытаются получить через сложную модель распределения затрат: аллокации по командам, амортизация, доля общих расходов на маркетинг. Это отдельная и полезная задача, но для быстрой и честной прикидки она избыточна. Есть способ проще: взять реальные счета за инфраструктуру за конкретный месяц, разделить на число активных пользователей за тот же месяц — и получить рабочую цифру, с которой можно сравнивать выручку и отслеживать тренд.

Почему считать по счетам, а не по модели

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

Расчёт по счетам — другое дело. Вы берёте только то, что напрямую тратится на то, чтобы продукт работал и отдавал ответы пользователям: сервер, трафик, хранилище, платные API. Это узкая себестоимость — инфраструктурная, а не полная. Она не заменяет юнит-экономику продукта целиком, но даёт быструю и честную цифру, которую можно посчитать за час, а не за неделю согласований с финансами. И именно потому что она узкая и механическая, её легко считать каждый месяц — а регулярность и делает метрику полезной, а не разовый снимок.

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

Шаг 1: собрать все инфраструктурные счета за месяц

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

Базовый список статей:

• Аренда серверов и виртуальных машин — то, на чём крутится бэкенд, база данных, очереди задач.
• Трафик (исходящий, egress) — если считается отдельно, часто одна из самых недооценённых статей, особенно у продуктов с большим объёмом ответов API или медиаконтентом.
• Хранилище — объектное хранилище для файлов, диски под базу данных, бэкапы, если тарифицируются отдельно от аренды сервера.
• Сторонние API с оплатой по использованию — LLM-провайдер, отправка писем и SMS, платёжный шлюз с комиссией за транзакцию, геокодирование, распознавание изображений — любой внешний сервис, счёт за который растёт вместе с активностью.
• CDN, если оплачивается отдельно от хостинга и зависит от объёма трафика.
• Managed-сервисы — управляемая база данных, очередь, Kubernetes, если это отдельная строка счёта.

Практический совет: заведите таблицу со столбцами «поставщик — статья — сумма за месяц — валюта» и пройдитесь по всем платёжным письмам и биллинговым панелям за нужный месяц. Отдельно отметьте статьи, которые платятся не помесячно, а, например, раз в год (некоторые лицензии, резервирование мощностей) — их нужно поделить на 12 и включить пропорциональную долю, иначе метрика будет скакать от месяца оплаты к остальным.

Таблица счетов за месяц (пример структуры, не реальные цифры)
Поставщик         Статья                    Сумма
-----------------------------------------------------
Хостинг сервера    Аренда VPS/выделенного    ...
Хостинг сервера    Исходящий трафик          ...
Объектное хранилище Хранение файлов          ...
CDN                 Раздача статики          ...
LLM-провайдер       API-запросы              ...
Email-сервис        Отправка писем           ...
Платёжный шлюз      Комиссия за транзакции   ...
-----------------------------------------------------
Итого за месяц                              СУММА

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

Ещё одна ловушка — счета с задержкой выставления. Провайдер трафика или LLM-API может выставить счёт за август только в начале сентября. Если считаете себестоимость «по месяцу оказания услуги», а не «по месяцу оплаты», нужно либо дождаться финального счёта, либо взять данные из биллинговой панели провайдера за нужный период, а не из платёжной истории карты.

Шаг 2: определить и посчитать активных пользователей

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

Зафиксируйте одно чёткое и, желательно, самое простое определение — и не меняйте его без веской причины. Рабочие варианты, от простого к более строгому:

• Залогинился хотя бы раз за месяц (MAU в классическом понимании) — легко посчитать по логам аутентификации, наименее спорный вариант.
• Совершил хотя бы одно значимое действие (создал документ, отправил запрос, сделал заказ) — точнее отражает реальную нагрузку, но требует договориться, что считать «значимым».
• Активен N дней из месяца — более строгий порог, отсекает случайные заходы, но требует хранить историю визитов.

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

-- Пример: число уникальных пользователей, залогинившихся
-- хотя бы раз за календарный месяц (упрощённо, под свою схему БД)
SELECT COUNT(DISTINCT user_id) AS active_users
FROM login_events
WHERE login_at >= '2026-08-01'
  AND login_at <  '2026-09-01';

Зафиксируйте определение письменно, одной строкой в той же таблице: «активный = залогинился хотя бы раз за календарный месяц по UTC». Звучит как формальность, но именно она спасает метрику через полгода, когда её будет пересчитывать другой человек или вы сами, но уже забыв нюансы.

Шаг 3: разделить и получить себестоимость

Сама арифметика — самая простая часть:

Себестоимость одного активного пользователя за месяц =
    Сумма всех инфраструктурных счетов за месяц / Число активных пользователей за тот же месяц

Пример структуры расчёта (без реальных цифр, только логика):

Итого счетов за август:           X (валюта)
Активных пользователей за август: Y (человек)
Себестоимость на пользователя:    X / Y

Здесь уместны две оговорки. Первая: если у продукта есть сезонность или скачки нагрузки не от пользователей (например, ночной batch-процесс), расчёт всё равно валиден — он просто покажет, что в такие месяцы себестоимость выше не потому что пользователи «подорожали», а потому что выросла база расходов. Метрика измеряет фактическую себестоимость, а не «справедливую» её часть.

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

Зачем это вообще считать: сравнение с выручкой на пользователя

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

Важно не путать это сравнение с полным расчётом маржинальности продукта: инфраструктурная себестоимость — только часть расходов на пользователя, полная картина требует добавить поддержку, маркетинг привлечения (CAC), зарплаты команды. Но именно потому что инфраструктурная часть считается быстро и механически, её удобно смотреть каждый месяц как индикатор — не заменяющий полную модель, а предупреждающий заранее, что с ней стоит разобраться подробнее.

Практически это выглядит как таблица, которую можно вести из месяца в месяц:

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

Зачем отслеживать метрику во времени: сигнал о масштабировании

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

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

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

Тренд стоит смотреть на достаточном числе точек — минимум 3-4 месяца подряд, по возможности исключая месяцы с разовыми выбросами расходов. Одна точка — не тренд; два соседних месяца с небольшим ростом ещё не повод для паники, это может быть шум.

Практические нюансы и ограничения метрики

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

• Чувствительна к структуре продукта. Продукт с тяжёлыми вычислениями на бэкенде (обработка видео, инференс модели) естественно будет иметь более высокую себестоимость на пользователя, чем простое CRUD-приложение. Сравнивать её между разными продуктами напрямую бессмысленно — метрика полезна прежде всего в динамике одного продукта.
• Резкие скачки числа пользователей искажают месяц. Всплеск регистраций в середине месяца (например, после публикации в СМИ) может занизить себестоимость этого месяца — новые пользователи ещё не успели создать нагрузку, а в знаменатель уже попали. Это не ошибка расчёта, а особенность того, что счета и активность не всегда синхронны во времени.
• Разделяйте фиксированные и переменные статьи. Аренда сервера — во многом фиксированная статья: она не подешевеет вдвое, если пользователей стало вдвое меньше, пока вы не уменьшите конфигурацию. Трафик и сторонние API — куда более переменные. Это помогает понять, почему себестоимость падает или растёт: рост базы размывает фиксированную часть, а переменная растёт почти пропорционально.
• Не единственный критерий для решений о ценах. Метрика даёт быструю прикидку маржинальности, но решение об изменении тарифов должно учитывать конкурентную среду, восприятие ценности, эластичность спроса.
• Фиксируйте валюту и курс. Если счета в одной валюте, а выручка в другой, фиксируйте курс на момент расчёта — иначе его колебания замаскируются под изменение реальной себестоимости.

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

Частые вопросы