tgoop.com/zasql_python/339
Create:
Last Update:
Last Update:
Предположим, у нас есть таблица с заказами и пользовательскими событиями (по последнему мы получаем данные по DAU / WAU / MAU, например).
1) orders:
user_id | order_id | gmv | date
user_id - id пользователя
order_id - id заказа
gmv - стоимость заказа (для пользователя)
date - дата оплаты заказа
2) actions:
user_id | action_name | date
user_id - id пользователя
action_name - обычно таблица с событиями (сюда льются любые заходы пользователя в приложении)
date - дата экшна
-- Считаем ARPU и ARPPU за март 2025 года
WITH
-- Количество уникальных активных пользователей (по действиям)
active_users AS (
SELECT COUNT(DISTINCT user_id) AS active_user_count
FROM actions
WHERE date BETWEEN '2025-03-01' AND '2025-03-31'
),
-- Количество уникальных платящих пользователей (по заказам)
paying_users AS (
SELECT COUNT(DISTINCT user_id) AS paying_user_count
FROM orders
WHERE date BETWEEN '2025-03-01' AND '2025-03-31'
),
-- Общая выручка за период
total_revenue AS (
SELECT SUM(gmv) AS gmv_total
FROM orders
WHERE date BETWEEN '2025-03-01' AND '2025-03-31'
)
-- Финальный расчёт метрик ARPU и ARPPU
SELECT
ROUND(gmv_total * 1.0 / active_user_count, 2) AS arpu, -- Средняя выручка на активного пользователя
ROUND(gmv_total * 1.0 / paying_user_count, 2) AS arppu -- Средняя выручка на платящего пользователя
FROM total_revenue
CROSS JOIN active_users
CROSS JOIN paying_users;
Например, ARPU = 100 ₽, ARPPU = 500 ₽ => платит только каждый 5-й.
Если рассматривать их в связке, можно понять за счёт чего растёт выручка: за счёт увеличения числа платящих (растёт ARPU, ARPPU на месте) или за счёт того, что каждый платящий стал платить больше (растут оба).
Обычно, при проведении экспериментов смотрят за ARPU (так как принимается решения по внедрению фичи не на срезе платящих, а не срезе всего приложения).
ARPU чувствительнее к изменениям в конверсии в оплату, а ARPPU — к изменениям в поведении уже платящих.
#дляначинающих@zasql_python