Выручка в отчётах

Отдельного раздела «Выручка» в кабинете нет — и не нужно. Деньги в ActionPulse — это одно свойство события: revenue. Как только оно начинает приходить, суммы появляются сразу в нескольких отчётах: на обзоре, в аналитике, в удержании, в воронках и в каналах.

Одно свойство: revenue

Выручка — это числовое свойство revenue внутри props события, в рублях.

{
  "event": "order_paid",
  "user_id": "YOUR_USER_ID",
  "props": { "revenue": 1490, "plan": "pro" }
}

Что важно знать про это свойство:

• Оно платформенное. revenue описано в реестре событий как глобальное свойство типа «число», необязательное, с ограничением «не меньше нуля». Переопределить его своей схемой нельзя — попытка задать revenue другого типа в схеме события отклоняется.
• Его можно приложить к любому вашему событию. Отдельного «события оплаты» платформа не требует: отчёты суммируют revenue по тем событиям, которые попали в выборку.
• Имя ровно revenue, в нижнем регистре, на верхнем уровне props. Никакие amount, total, sum, price выручкой не считаются.
• Отсутствующее или нечисловое значение читается как ноль в суммах.

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

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

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

Более того, имена событий, которые описывают деньги и доступ, вообще принимаются только серверным ключом:

registered, subscription_started, trial_started, trial_activated, trial_converted, trial_expired, payment_succeeded, payment_attached, order_created, first_order_created, order_paid, invoice_paid, refund.

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

Где выручка видна

Экран	Что показывает
Мониторинг → Обзор	карточки «Выручка за 30 дней» и «ARPU за 30 дней»
Анализ → Аналитика	метрики «Выручка, ₽» и «Средняя выручка на событие, ₽»
Анализ → Удержание	режим «Доход на пользователя, ₽» — накопленная выручка когорты
Анализ → Воронки	режим «Потери, ₽» — оценка потерь на переходе между шагами
Анализ → Каналы	колонка «Выручка» по каждому UTM-источнику
Профиль человека	карточка «Выручка» за выбранный период
Еженедельный дайджест	раздел «Revenue», если он включён в настройках дайджеста

Карточки выручки и ARPU появляются на обзоре сами, без добавления блока: пока сводка загружается, пока она вернула ошибку и пока выручка за период не равна нулю. Если запрос успешно вернул ноль, обе карточки скрываются — обзор не показывает пустые деньги. Добавить их обратно вручную можно кнопкой «Добавить блок».

Выгрузка результата в CSV несёт денежные колонки как обычные поля: revenue_rub и revenue_avg_rub в аналитике, revenue_ltv_rub в удержании, est_monthly_loss_rub в воронке, revenue_rub в выгрузке списка событий.

Как считаются средний чек и выручка на пользователя

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

Показатель	Как считается
Выручка	сумма revenue по всем событиям выборки, со знаком
Средняя выручка на событие	выручка ÷ число событий, у которых свойство revenue есть
ARPU на обзоре	выручка за 30 дней ÷ уникальные активные пользователи за те же 30 дней
Доход на пользователя (удержание)	накопленная выручка когорты к периоду N ÷ исходный размер когорты
Оценка потерь (воронка)	разница пользователей между соседними шагами × средняя выручка на плательщика финального шага × 30 ÷ дней периода

Несколько важных деталей этих формул.

Средняя выручка на событие — это средний чек, если одно событие равно одной покупке. В знаменателе только события, у которых свойство revenue присутствует; явный нуль в знаменатель попадает (бесплатный заказ — это тоже заказ), а событие без свойства — нет. Поэтому имеет смысл считать эту метрику с выбранным событием оплаты, а не с «любым событием».

ARPU считается по всем активным, а не только по плательщикам. Знаменатель — уникальные пользователи, совершившие в окне хоть какое-нибудь событие, и пользователь, активный несколько дней, попадает в него один раз. Окно — 30 дней включая сегодня, календарные даты в часовом поясе проекта.

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

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

Возвраты

Отчёты считают выручку со знаком: отрицательное значение revenue уменьшает и сумму, и среднее. Именно поэтому карточка на обзоре подписана «Возвраты учитываются как отрицательная выручка».

При этом платформенный контракт свойства требует revenue ≥ 0. Как это сочетается:

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

Если выручки в отчётах нет

Симптом	Обычная причина
Все суммы нулевые	свойство названо иначе — amount, total, sum вместо revenue
Суммы нулевые, событие приходит	revenue лежит рядом с props, а не внутри него
Суммы не сходятся, в проверке интеграции есть нарушения	сумма приходит строкой "1490", а не числом: revenue обязан быть числом
Карточек выручки нет на обзоре	за последние 30 дней выручка равна нулю — карточки скрываются, добавьте их кнопкой «Добавить блок»
Выручка меньше, чем в вашей платёжной системе	часть оплат отправляется из браузера и отклоняется как credential_event_forbidden
В воронке нет режима «Потери, ₽»	воронка считается по событиям, а не по уникальным пользователям
По каналам выручка есть, а по импортированной истории нет	импорт не заполняет UTM-колонки, поэтому импортированные события в отчёте по каналам не видны

Быстрая проверка одного события: Данные и сбор → События, нажмите на строку события оплаты и посмотрите его JSON целиком — там сразу видно, есть ли revenue внутри props и число ли это. Если события нет вообще — начните с проверки интеграции.

В разделе Данные и сбор → Запросы к данным сумму можно посчитать самостоятельно: она лежит в колонке props, платформа читает её выражением JSONExtractFloat(props, 'revenue').