Трафик растёт быстрее выручки: как заранее посчитать порог боли

MAATRIX

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

Почему рост трафика — не всегда хорошая новость

В классической подписной модели рост числа пользователей почти линейно ведёт к росту выручки: пришёл новый клиент — заплатил, инфраструктура под него масштабируется пропорционально деньгам, которые он приносит. У freemium-продукта эта связь разорвана. Бесплатный пользователь потребляет инфраструктуру ровно так же, как платящий — грузит файлы, делает запросы к API, смотрит видео, гоняет трафик через CDN — но платит редко, и обычно далеко не сразу.

Проблема усугубляется тем, что бесплатные пользователи почти всегда составляют подавляющее большинство базы. Типичная воронка freemium-продукта — это несколько процентов конверсии в платный тариф, а остальные 90+% продолжают пользоваться бесплатной версией месяцами или годами, каждый день потребляя ресурсы. Если у продукта нет жёстких лимитов на бесплатном тарифе, каждый новый бесплатный пользователь — это гарантированная статья расходов и негарантированная статья доходов.

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

Из чего складывается счёт, который растёт вместе с трафиком

Прежде чем строить модель, нужно понимать, какие именно статьи расходов у большинства облачных провайдеров масштабируются вместе с трафиком, а не с числом купленных серверов:

• Исходящий трафик (egress) — плата за каждый гигабайт, покидающий облако в сторону пользователя. Это часто самая незаметная и при этом самая быстрорастущая строка счёта, особенно если отдаёте видео, изображения или большие API-ответы. Подробный разбор механики — в статье про egress-трафик как статью счёта, о которой узнают поздно.
• Вычислительные ресурсы под запросы — CPU и память, которые тратятся на обработку каждого запроса, независимо от того, платящий это пользователь или нет. Если у бесплатного тарифа нет лимита запросов в секунду, эта статья растёт линейно с числом активных бесплатных аккаунтов.
• Хранилище и операции с диском — загруженные бесплатными пользователями файлы, логи их активности, кэш их сессий.
• Управляемые сервисы, тарифицируемые по объёму — очереди сообщений, базы данных как сервис, CDN, где счёт растёт не за ядра, а за количество запросов или переданных байт.
• Служебная нагрузка — мониторинг, логирование, алертинг, которые тоже масштабируются вместе с объёмом трафика и часто выпадают из расчёта, пока не сложатся в заметную сумму.

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

Модель: разделите рост на трафик бесплатных и рост выручки

Первый шаг методики — перестать смотреть на общий рост как на одну цифру и разложить его на две независимые кривые:

1. Темп роста инфраструктурных расходов, привязанных к трафику и активности бесплатных пользователей. Обозначим его как r_cost — процент прироста за период (например, за месяц или квартал).
2. Темп роста выручки от конвертированных платящих пользователей за тот же период — r_revenue.

Дальше вводится ключевое соотношение — коэффициент опережения:

K = r_cost / r_revenue

Пока K < 1, расходы на инфраструктуру растут медленнее выручки — модель постепенно становится эффективнее по мере масштаба (эффект масштаба работает на вас). Когда K приближается к 1 — рост становится нейтральным: каждый новый виток масштаба не улучшает и не ухудшает unit-экономику. Когда K устойчиво больше 1 в течение нескольких периодов подряд — это и есть сигнал, что продукт входит в зону структурно убыточного роста: чем больше он растёт, тем больше теряет в абсолютных числах, даже если валовая выручка при этом тоже растёт.

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

Как вывести формулу порога боли

Порог боли — это не просто «когда K больше 1». Это конкретная точка на кривой роста, после которой предельная (marginal) единица нового трафика начинает стоить дороже, чем предельная единица нового дохода, который она в среднем приносит. Чтобы её найти, нужно смотреть не на общие темпы роста, а на предельные величины.

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

• Предельная стоимость трафика бесплатного пользователя (MC) — сколько в среднем стоит облачная инфраструктура на одного дополнительного бесплатного пользователя за период. Считается как прирост инфраструктурных расходов, делённый на прирост числа бесплатных пользователей за тот же период.
• Предельный доход от конверсии (MR) — сколько в среднем приносит один новый пользователь с учётом реальной конверсии в платный тариф. Считается как прирост выручки, делённый на прирост общего числа пользователей (не только платящих — именно общего, потому что именно на общий приток вы и тратите инфраструктуру).

MC = Δ(инфраструктурные расходы, привязанные к трафику) / Δ(число активных пользователей, включая бесплатных)
MR = Δ(выручка от подписок/платежей) / Δ(число активных пользователей, включая бесплатных)

Порог боли — это точка, где MC начинает превышать MR:

MC > MR  →  каждый новый пользователь в среднем стоит дороже, чем приносит

Это и есть формальное определение структурно убыточного масштабирования: не разовый месяц с плохими цифрами, а устойчивое состояние, при котором рост базы пользователей уменьшает, а не увеличивает операционную прибыль. Отличие от простого сравнения «выручка минус расходы» в том, что MC/MR считаются именно по приростам, а не по абсолютным суммам — это позволяет увидеть проблему до того, как она проявится в итоговом P&L, потому что абсолютная прибыль может ещё оставаться положительной за счёт накопленной базы платящих клиентов, даже когда каждый новый пользователь уже приносит убыток.

Как собрать данные и посчитать порог по своим цифрам

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

1. Выгрузите историю облачного счёта постатейно. У большинства провайдеров есть экспорт биллинга в CSV или доступ через API/CLI — важно получить не одну итоговую сумму, а разбивку по категориям (compute, storage, egress, managed-сервисы), чтобы отделить расходы, растущие вместе с трафиком, от фиксированных.

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

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

4. Посчитайте MC и MR за каждый период по приведённым выше формулам и постройте их как две линии на одном графике. Разрыв между линиями наглядно показывает динамику — сходятся они, расходятся или уже пересеклись.

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

Не выдумывайте точность там, где её нет: если данных мало (продукт молодой, истории меньше 4-6 месяцев), не стройте точный прогноз даты — считайте только направление тренда (K растёт, стабилен или падает) и держите вопрос на контроле каждый месяц, пока данных не накопится достаточно для более уверенного вывода.

Что делать, если порог близко или уже пройден

Обнаружение того, что MC приближается к MR или уже превышает его, — это не повод паниковать и резать всё бесплатное подряд. Это сигнал выбрать один или несколько инструментов и оценить их эффект тем же способом, каким считался порог:

• Лимиты для бесплатного тарифа, привязанные именно к дорогим статьям расходов — не общий лимит «действий в месяц», а конкретно лимит на трафик, число запросов к тяжёлым эндпоинтам, объём хранимых файлов. Лимитировать нужно то, что реально стоит денег, а не то, что легче всего измерить.
• Оптимизация стоимости единицы трафика без изменения продукта: сжатие и оптимизация изображений и видео перед раздачей, включение CDN для статики, пересмотр формата API-ответов. Конкретный расчёт эффекта такой оптимизации разобран в статье про то, как оптимизация картинок экономит на трафике — важно, что эффект здесь считается в тех же единицах MC, что и общий порог, поэтому легко сравнить, насколько мера отодвигает точку пересечения.
• Изменение модели монетизации — от точечных платных функций (usage-based add-on именно на дорогие ресурсы вроде хранилища или пропускной способности) до пересмотра порога, после которого бесплатный пользователь обязан либо ограничить активность, либо перейти на платный тариф.
• Повышение конверсии в целевой группе, а не общей конверсии — если основная масса расходов приходится на конкретный сегмент бесплатных пользователей (например, тех, кто активно грузит большие файлы), точечная работа над конверсией именно этого сегмента даёт больше эффекта на MR, чем общая маркетинговая кампания.
• Архитектурные изменения, снижающие MC напрямую: собственный кеширующий узел вместо стороннего CDN там, где объём оправдывает это решение, перенос части статики на более дешёвый по трафику тип хостинга, пересмотр того, какие данные вообще нужно отдавать по сети, а какие можно обрабатывать иначе.

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

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