Цена одного заказа в инфраструктуре интернет-магазина

MAATRIX

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

Почему для интернет-магазина считают заказ, а не пользователя

Метрика «себестоимость активного пользователя» отвечает на вопрос «сколько стоит удержание и обслуживание одного клиента в системе за период». Для подписочного сервиса это осмысленно: пользователь платит регулярно, его активность более-менее равномерна, и инфраструктурная нагрузка от него тоже более-менее стабильна месяц к месяцу.

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

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

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

Из чего складывается инфраструктурная цена заказа

Прежде чем считать, нужно определить, что вообще входит в «инфраструктурные расходы» магазина за период. Типичный состав:

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

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

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

Методика расчёта: от счетов к одной цифре

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

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

Разберём по шагам.

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

Шаг 2. Соберите числитель — все инфраструктурные расходы за период. Пройдитесь по каждой статье из списка выше и возьмите фактические суммы по счетам:

• аренда серверов и хостинга — по счёту провайдера за период;
• трафик и CDN — либо отдельная строка в счёте, либо расчёт по тарифу за использованный объём;
• плата за операции платёжного шлюза (если применимо) — из отчёта платёжного провайдера за период, отдельно от суммы самого оборота;
• вызовы API логистики и склада — из биллинга интеграции, если он потранзакционный, или доля фиксированной подписки за период;
• антифрод и уведомления — из соответствующих счетов.

Здесь важно не путать инфраструктурные расходы с прямой себестоимостью товара (закупка, упаковка) и с процентной комиссией эквайринга от оборота — это отдельные статьи P&L, а не инфраструктура. Смешивание этих категорий — самая частая причина, по которой метрика получается бессмысленной: если в числитель попадает комиссия эквайринга 2,5% от оборота, цена заказа начинает расти вместе со средним чеком, а не с реальной нагрузкой на инфраструктуру.

Шаг 3. Возьмите знаменатель — число оформленных заказов за тот же период. Здесь тоже есть нюанс: считать нужно именно оформленные (подтверждённые, оплаченные или переданные в обработку) заказы, а не количество визитов в корзину или брошенных корзин. Если ваша CMS или CRM различает «заказ создан» и «заказ оплачен», для расчёта инфраструктурной цены логичнее брать оплаченные — они точнее отражают реальную нагрузку на платёжный шлюз, склад и логистику, которую вы и оплачиваете.

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

Зачем это интернет-магазину: сопоставление с маржой

Главная практическая польза метрики — не сама цифра, а её сопоставление со средней маржой на заказ.

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

Доля маржи, которую съедает инфраструктура = Инфраструктурная цена заказа / Средняя маржа на заказ × 100%

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

• При планировании юнит-экономики нового направления. Если вы запускаете новую товарную категорию или отдельный региональный магазин, прикидочная инфраструктурная цена заказа (по аналогии с текущим бизнесом или по тарифам провайдеров) сразу показывает, при какой марже направление вообще может быть прибыльным.
• При выборе между «доработать своё» и «подключить ещё один платный сервис». Каждая новая интеграция — антифрод, дополнительный канал уведомлений, отдельный сервис аналитики заказов — добавляет строку в числитель. Сопоставление с маржой на заказ даёт рамку: интеграция, которая стоит условные 3–5% маржи на заказ, требует более серьёзного обоснования пользы, чем интеграция за десятые доли процента.
• При переговорах с провайдерами инфраструктуры и интеграций. Когда вы можете показать не абстрактный счёт, а долю от маржи на заказ, легче аргументировать смену тарифа, поставщика платёжного шлюза или логистической интеграции — особенно если конкурентные варианты вы уже прикинули заранее, например через конфигурацию и цену выделенного сервера для обработки платежей.

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

Эффект масштаба: снижается ли цена заказа с ростом объёма

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

Статьи, которые обычно дают эффект масштаба:

• аренда сервера и хостинг — если объём заказов растёт, а мощности сервера хватает без апгрейда, цена заказа по этой статье падает почти линейно;
• фиксированные лицензии и подписки на панели управления, мониторинг, часть SaaS-инструментов — тот же эффект, пока не упёрлись в лимиты тарифа.

Статьи, которые масштабируются хуже или не масштабируются вовсе:

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

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

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

Типичные ошибки при расчёте метрики

• Смешивание инфраструктурных расходов с комиссией эквайринга от оборота. Как уже отмечалось выше — это разные категории затрат, и их смешение делает метрику непригодной для сравнения периодов.
• Учёт визитов вместо оформленных заказов. Число заказов и число визитов в корзину — разные величины, и подстановка не той цифры в знаменатель искажает результат в разы.
• Сравнение сезонных и несезонных месяцев без пометки. Без разметки на «обычный» и «пиковый» период динамика метрики будет выглядеть как хаотичный шум, хотя на деле это регулярная сезонность.
• Игнорирование скрытых потранзакционных платежей в API-интеграциях. Часть тарифов на интеграцию со складом или логистикой прячет плату за вызов API глубоко в документации — стоит один раз внимательно прочитать договор и тарифный план, а не полагаться на «базовую» подписочную сумму. Даже технический сбой стороннего API (например, изменение формата данных на его стороне) может привести к незапланированным издержкам на срочные доработки — такие изменения полезно фиксировать в той же таблице, где вы считаете инфраструктурную цену заказа.
• Расчёт по валовому обороту вместо валовой маржи при сопоставлении. Сравнивать инфраструктурную цену заказа нужно именно с маржой на заказ, а не с выручкой — иначе доля будет искусственно занижена и создаст ложное ощущение, что инфраструктура почти ничего не стоит.

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