Как посчитать feature adoption в SQL

Зачем feature adoption

Запустили новую фичу — нужно мерить, кто реально пользуется. Feature adoption rate = доля активных пользователей, попробовавших фичу. Низкий adoption = плохой onboarding, фича не нужна, или функционал спрятан. Высокий adoption + плохой retention = разочаровывает после использования.

Определения adoption

Несколько вариантов, fix one до анализа:

• Ever used: хоть раз попробовал. Простое, но обманчивое.
• Used in last N days: активное пользование.
• Used > X times: «реальное» вовлечение, не случайно.
• Used + retained: вернулся к фиче на следующий день/неделю.

Adoption rate в SQL

«Used in last 30 days» вариант:

WITH active_users AS (
    SELECT DISTINCT user_id
    FROM events
    WHERE event_date >= CURRENT_DATE - INTERVAL '30 days'
),
feature_users AS (
    SELECT DISTINCT user_id
    FROM events
    WHERE event_name = 'feature_x_used'
      AND event_date >= CURRENT_DATE - INTERVAL '30 days'
)
SELECT
    (SELECT COUNT(*) FROM active_users) AS active,
    (SELECT COUNT(*) FROM feature_users) AS adopted,
    (SELECT COUNT(*) FROM feature_users)::NUMERIC * 100
    / NULLIF((SELECT COUNT(*) FROM active_users), 0) AS adoption_rate_pct;

Если active = 10k, adopted = 1.5k → adoption 15%.

По cohort и каналу

WITH cohort AS (
    SELECT user_id, DATE_TRUNC('month', created_at)::DATE AS cohort_month, utm_source
    FROM users
),
adopted AS (
    SELECT DISTINCT user_id
    FROM events
    WHERE event_name = 'feature_x_used'
      AND event_date >= CURRENT_DATE - INTERVAL '30 days'
)
SELECT
    c.cohort_month,
    c.utm_source,
    COUNT(*) AS cohort_size,
    COUNT(*) FILTER (WHERE c.user_id IN (SELECT user_id FROM adopted)) AS adopted,
    COUNT(*) FILTER (WHERE c.user_id IN (SELECT user_id FROM adopted)) * 100.0
    / NULLIF(COUNT(*), 0) AS adoption_pct
FROM cohort c
GROUP BY c.cohort_month, c.utm_source
HAVING COUNT(*) >= 50
ORDER BY adoption_pct DESC;

Время до adoption

Когда юзер встречает фичу:

WITH first_use AS (
    SELECT
        user_id,
        MIN(event_date) AS first_feature_use
    FROM events
    WHERE event_name = 'feature_x_used'
    GROUP BY user_id
)
SELECT
    AVG(EXTRACT(EPOCH FROM (fu.first_feature_use - u.created_at)) / 86400) AS avg_days_to_first_use,
    PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (fu.first_feature_use - u.created_at)) / 86400) AS median_days
FROM first_use fu
JOIN users u USING (user_id);

Если median = 7 дней — фича не обнаруживается в первой неделе. Onboarding нужно фиксить.

Частые ошибки

Ошибка 1. Считать adoption на total registered users. Включает churned юзеров — занижает. Используйте active users в knowledge base.

Ошибка 2. Adoption = 1 раз попробовал. Часто бывает: 80% «попробовали», 5% реально использовали. Used > X times — строже.

Ошибка 3. Игнорировать выборку. Если фича только iOS, считайте adoption среди iOS users, не всех.

Ошибка 4. Считать на короткий period сразу после launch. Adoption растёт со временем. Через неделю 5%, через месяц 25%. Сообщайте period.

Ошибка 5. Не сравнивать с baseline. Adoption фичи без сравнения с похожими фичами — без контекста.

Связанные темы

• Как посчитать engagement в SQL
• Как посчитать DAU в SQL
• Как посчитать time-to-value в SQL
• Как посчитать onboarding completion в SQL

FAQ

Какой adoption «хороший»?

Зависит от фичи. Core фича — 50%+. Power user фича — 5-15%.

Adoption vs activation?

Activation — общая «использовал продукт». Adoption — на конкретную фичу.

Сравнить с конкурентом?

Невозможно — у них другая база юзеров. Сравнивайте со своими предыдущими фичами.

Adoption падает — что делать?

Иногда фича стала ненужной (рынок изменился). Иногда — UX-регрессия. Customer interviews.

Можно ли увеличить через onboarding?

Часто да. In-app tour, tooltip — простые повышения adoption.