Почему одной формулы мало
Формула revenue = GMV × take rate полезна как грубая идентичность только после определения обеих величин. В публичной отчётности GMV, GMS, GOV и GBV включают и исключают разные элементы; take rate может использовать разные числители и разные базы. Совпадающее название не создаёт сопоставимость.
Для управления важен не только расчёт, но и место изменения. Одинаковая выручка может возникнуть из большего объёма с более слабой монетизацией, меньшего объёма с другим mix, роста цен при падении завершения или временных incentives. Эти сценарии требуют разных решений.
Четыре слоя карты
Рыночная активность
Вопрос: состоялся ли релевантный обмен и на какой документированной базе измеряется объём?
Здесь фиксируются eligible demand, completed outcomes и платформенная величина объёма. Название берётся из учётной и продуктовой системы компании. Налоги, доставка, возвраты, чаевые, подписки и off-platform элементы должны быть явно включены или исключены.
Монетизация
Вопрос: какую часть документированной базы платформа признала или реализовала как выручку?
Нужно разделить список цен, фактически применённые ставки, mix платных продуктов, incentives, contra-revenue и сегменты. Realised monetisation rate в worksheet — нейтральное рабочее название. Называть его take rate можно только после фиксации числителя и базы.
Надёжность
Вопрос: какая часть начатой или подтверждённой активности дожила до terminal success?
Отмены, payment failures, refunds, disputes и fulfilment failures нельзя сначала смешивать в одну долю. У них разные механизмы и владельцы. Общий net bridge строится только после раздельной taxonomy.
Переменная стоимость обслуживания
Вопрос: какой экономический результат остался после затрат, которые одобренная управленческая политика связывает с активностью?
Это не универсальное бухгалтерское определение. Набор payment, support, fulfilment, trust или других cost pools зависит от модели. Любой contribution-view должен примиряться с Finance и документировать распределение общих затрат.
Revenue bridge
Рабочая последовательность:
qualified demand → eligible match → completed activity → documented volume → reconciled platform revenue → variable service cost → contribution-view
Стрелки важнее формулы. На каждом переходе фиксируются событие, единица, окно, источник истины, владелец и версия. Если одно число строится из другой базы, bridge должен содержать явную reconciliation, а не скрытый коэффициент.
Как диагностировать изменение
Шаг 1. Разложить на price, volume и mix
Сначала проверить, изменились ли число завершённых исходов, средняя документированная база на исход, доля платных продуктов и распределение по сегментам. Средний take rate способен измениться без изменения ставок — только из-за mix.
Шаг 2. Проверить потери после намерения
Падение объёма не обязательно означает меньше спроса. Сравниваются unmet demand, fill rate, time to match, completion, cancellations, payments и refunds. Это локализует, исчезло ли намерение или не дожило до учитываемого события.
Шаг 3. Разделить цену и сбор
Опубликованная ставка, начисленная сумма и фактически признанная выручка могут различаться из-за incentives, refunds, waivers и учётных правил. Владелец каждой reconciliation должен быть назван.
Шаг 4. Проверить cost-to-serve
Рост выручки не гарантирует роста contribution-view. Изменение способа исполнения, платежного mix или support load может менять переменную стоимость. Здесь особенно опасны средние по платформе: микрорынки и продукты могут иметь разную стоимость обслуживания.
Шаг 5. Поставить guardrails рынка
Монетизация не оценивается отдельно от liquidity. Минимальные guardrails: unmet demand, zero exposure, transaction completion и удержание обеих сторон. Иначе краткосрочный рост capture может ухудшить последующую активность.
Матрица решений
| Изменение | Возможный механизм | Что проверить |
|---|---|---|
| Volume растёт, revenue rate падает | mix, incentives или другая база | сегменты, продукт монетизации, reconciliation |
| Revenue rate растёт, completion падает | цена или friction после match | cancellations, payment failures, retention |
| GMV стабилен, contribution-view падает | cost-to-serve или refunds | cost pools, fulfilment mix, refund taxonomy |
| Supply растёт, volume не меняется | отсутствующий спрос или allocation | unmet demand, exposure, matching по микрорынкам |
| Revenue растёт, обе стороны удерживаются хуже | краткосрочный capture или ухудшение качества | cohort retention и повтор по сегментам |
Это список гипотез. Он не заменяет причинный анализ.
Иллюстративный пример
Средний realised monetisation rate снизился, хотя тарифы не менялись. До вывода о проблеме pricing нужно проверить mix: доля сегмента с другой монетизационной базой могла вырасти. Если внутри каждого стабильного сегмента ставка не изменилась, агрегатное падение объясняется составом, а не ценовым решением. Пример не содержит реальных данных.
Антипример
Поставить команде единственную цель GMV и считать рост экономически полезным по определению. Команда может субсидировать объём, переносить отмены за окно, привлекать предложение без спроса или наращивать дорогой в обслуживании mix. GMV остаётся важной величиной, но не отвечает на вопрос о capture, надёжности и стоимости.
Как пользоваться worksheet
CSV содержит пять строк-кандидатов: activity, monetisation, reliability, service cost и contribution-view. Названия намеренно нейтральны. Их нужно заменить на термины компании, примирить с financial source of truth и одобрить у Finance до внешней публикации.
Сильнейший контраргумент
Карта избыточна: финансовая отчётность уже определяет выручку. Для внешнего признания это верно. Но отчётность не обязана объяснять операционной команде, на каком переходе изменился результат и какое действие доступно. Revenue Architecture Map не создаёт альтернативную бухгалтерию; она соединяет утверждённое финансовое число с проверяемыми операционными переходами и обязана в конце примириться обратно.