Условие

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

Чтобы смотреть видео или получать эксклюзив в чате (бесплатно или за деньги), потребитель должен подписаться на автора/продакшн.

Задача:

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

Решение

Подход

FriendsOnly — это подписочная платформа с фокусом на отношения автор-потребитель. Метрики должны отражать:

Привлечение потребителей.
Активацию: открытие первого автора / первой подписки.
Engagement: чат, просмотры, повторные визиты.
Монетизация: платная подписка, чаевые, разовые покупки.
Удержание: продолжают ли подписки.
Контент-сторона: какие категории / форматы работают.

Воронка потребителя контента

Install / Visit
   ↓
Sign-up
   ↓
Browse content (без подписки)
   ↓
Subscribe to first author (free)
   ↓
Engagement (smotrelo / chat / likes)
   ↓
Subscribe paid (PLN / discover / автор-pull)
   ↓
Renewal / churn
   ↓
Tips / one-off purchases

Главные метрики

#	Метрика	Зачем	Связь
1	DAU / WAU / MAU	объём аудитории	top of funnel
2	% activated (≥1 free subscribe)	активация	leading к paid
3	% paying users	конверсия в платное	главная к LTV
4	ARPPU (average revenue per paying user)	средний чек	× paying = ARPU
5	Subscription retention M1 / M3	удержание	напрямую × ARPPU = LTV
6	LTV (gross / net)	юнит-экономика	= ARPPU × avg duration
7	Subscriptions per paying user	глубина монетизации	растёт = больше cross-sell
8	Avg sessions per active user	engagement	leading к retention

Вторичные / диагностические

Метрика	Зачем
Time to first subscribe	UX onboarding
% subscriptions to top-1 author	концентрация audience на «звёздах»
Chat messages per user per day	engagement в diff-ed канале
Tips per paying user	дополнительная монетизация
Notifications click-through	health re-engagement канала
Search-to-subscribe rate	discovery
Categories explored per user	breadth of taste
Cancellation reasons (опрос)	что чинить

Связи метрик (формулы)

Revenue
  = MAU × % paying × ARPPU
  ≈ MAU × % activated × (paid|activated) × ARPPU

LTV
  = ARPPU × avg_subscription_duration
  ≈ ARPPU / monthly_churn_rate (если стационар)

Retention M3
  = subscribers in month N / subscribers in month N-3

ARPU
  = Revenue / MAU
  = % paying × ARPPU

Декомпозиция позволяет понять, что чинить:

Падает Revenue → смотрим на каждый множитель: MAU? % paying? ARPPU?
LTV не растёт → ARPPU стагнирует или churn растёт?

Логика сбора и сборки метрик

Какие события нужны

Событие	Параметры
`app_open` / `web_visit`	user_id, ts, source (organic / paid_X / referral)
`signup`	user_id, ts, country, age, signup_method
`view_author_profile`	user_id, author_id, ts
`subscribe`	user_id, author_id, plan_type (free/paid), price, ts
`unsubscribe`	user_id, author_id, ts, reason (если опросом)
`view_content`	user_id, author_id, content_id, content_type, duration_watched, ts
`chat_message`	user_id, author_id, message_id, ts
`tip`	user_id, author_id, amount, ts
`one_off_purchase`	user_id, content_id, amount, ts
`paywall_view`	user_id, author_id, ts
`notification_received` / `notification_clicked`	user_id, type, ts

Архитектура

Client-side SDK (mobile + web) шлёт события в Kafka.
Kafka → ClickHouse (для фактов).
DWH (BigQuery / Snowflake) для агрегаций и BI (Tableau / Looker).
Облачный feature store / behavioural taxonomy (Amplitude / Mixpanel / самописное) — для self-serve аналитики продакт-менеджеров.
Когортные таблицы материализуются ежедневно: cohort × week × metric.
Real-time дашборды для критичных метрик (DAU, новые подписки).

Срезы

Категория автора (мужской / женский / увлечения).
Тип контента (видео / аудио / стрим).
Платформа (mobile / web).
Гео.
Источник трафика.
Возраст подписки (новые / устоявшиеся).
Кит / minor (по revenue).

Анализ / интерпретация

Хороший ответ:

Связывает метрики в иерархическую структуру с формулами.
Различает leading (paywall_view, time_to_first_subscribe) и lagging (LTV, M3 retention) метрики.
Привязывает каждую метрику к продуктовому действию: «если drop view-of-paywall — копаем UX».
Учитывает специфику платформы: подписки, не покупки; категории контента; чаты как engagement-канал.

Подводные камни

MAU без сегментации. Показывает «общий объём», но скрывает, кто платит.
ARPU vs ARPPU. ARPU усредняет по всем (включая non-payers), ARPPU — только по платящим. Разные сигналы.
«Подписка» != «оплата». Free-подписка тоже — это активация, а не выручка.
Churn vs cancellation. Юзер может «забыть» подписку без активной отмены. Auto-renewal маскирует churn.
Tips не предсказуемы. ARPPU за счёт tips может скачкообразно расти после стрима — это не тренд.
Спорные категории. Аудитория «мужских» и «женских» каналов — разное; усреднение метрик скрывает реальность.
Network effects. Подписка на автора может зависеть от соц-связей; чистая воронка её не учитывает.
Платёжные провайдеры. Refunds, cancelled-but-not-refunded — нужно очищать revenue.

Эталонный ответ

Главные метрики (4-5 штук): DAU/MAU, % activated (first free sub), % paying, ARPPU, M3 retention, LTV.

Вторичные: time-to-first-subscribe, subscriptions per paying user, chat engagement, tips per paying user.

Связь: Revenue = MAU × % paying × ARPPU; LTV ≈ ARPPU / monthly churn. Декомпозиция помогает локализовать проблемы.

События: app_open, signup, subscribe (free/paid), view_content (с duration), chat_message, tip, paywall_view, unsubscribe (с причиной).

Архитектура: Client SDK → Kafka → ClickHouse (raw) → DWH (агрегации) → BI (self-serve).

Главное — связать метрики в иерархию с формулами и специализировать под подписочную платформу с категориями автор-потребитель, не давать generic-ответ.

FriendsOnly — метрики для направления потребителей контента