Как посчитать Tutorial Completion в SQL

Зачем Tutorial Completion

Туториал — это первые шаги пользователя в продукте, часть онбординга. Tutorial Completion Rate показывает, какая доля новых пользователей прошла туториал до конца. Метрика важна, потому что каждый шаг, на котором люди отваливаются, — это точка потери (leak point): чем раньше человек застрял, тем меньше шанс, что он вернётся.

Прямой связи «прошёл туториал → останется навсегда» нет, но эмпирически высокий completion почти всегда идёт рука об руку с активацией: пользователь, дошедший до ценности продукта, чаще возвращается и приносит больше LTV. На собесе продуктового аналитика по этой метрике проверяют, умеете ли вы разложить воронку по шагам, найти узкое место и не спутать корреляцию с причинностью.

Формула

Tutorial Completion = users_finished_step_N / users_started_tutorial × 100%

Числитель — число пользователей, дошедших до финального шага; знаменатель — число тех, кто вообще начал туториал. Важно считать по уникальным пользователям (DISTINCT user_id), а не по событиям, иначе повторные заходы раздуют цифры.

Базовый расчёт

WITH starts AS (
    SELECT DISTINCT user_id
    FROM events
    WHERE event_name = 'tutorial_started'
      AND event_time >= CURRENT_DATE - INTERVAL '30 days'
),
completions AS (
    SELECT DISTINCT user_id
    FROM events
    WHERE event_name = 'tutorial_completed'
      AND event_time >= CURRENT_DATE - INTERVAL '30 days'
)
SELECT
    COUNT(s.user_id) AS started,
    COUNT(c.user_id) AS completed,
    COUNT(c.user_id)::NUMERIC * 100 / NULLIF(COUNT(s.user_id), 0) AS completion_rate_pct
FROM starts s
LEFT JOIN completions c USING (user_id);

Берём уникальных пользователей, начавших туториал, и уникальных завершивших за последние 30 дней. LEFT JOIN сохраняет всех, кто начал, а NULLIF(..., 0) защищает от деления на ноль, если стартов не было.

Drop-off по шагам

Общий completion говорит «сколько дошло», но не «где отваливаются». Чтобы найти узкое место, разложите воронку по шагам и посчитайте конверсию каждого перехода:

WITH steps AS (
    SELECT
        user_id,
        MAX(CASE WHEN event_name = 'tutorial_step_1' THEN 1 ELSE 0 END) AS step1,
        MAX(CASE WHEN event_name = 'tutorial_step_2' THEN 1 ELSE 0 END) AS step2,
        MAX(CASE WHEN event_name = 'tutorial_step_3' THEN 1 ELSE 0 END) AS step3,
        MAX(CASE WHEN event_name = 'tutorial_step_4' THEN 1 ELSE 0 END) AS step4,
        MAX(CASE WHEN event_name = 'tutorial_step_5' THEN 1 ELSE 0 END) AS step5
    FROM events
    WHERE event_name LIKE 'tutorial_%'
      AND event_time >= CURRENT_DATE - INTERVAL '30 days'
    GROUP BY user_id
)
SELECT
    SUM(step1) AS reached_step1,
    SUM(step2) AS reached_step2,
    SUM(step3) AS reached_step3,
    SUM(step4) AS reached_step4,
    SUM(step5) AS reached_step5,
    -- Конверсия перехода шаг N → N+1
    SUM(step2)::NUMERIC * 100 / NULLIF(SUM(step1), 0) AS step1_to_2_pct,
    SUM(step3)::NUMERIC * 100 / NULLIF(SUM(step2), 0) AS step2_to_3_pct,
    SUM(step4)::NUMERIC * 100 / NULLIF(SUM(step3), 0) AS step3_to_4_pct,
    SUM(step5)::NUMERIC * 100 / NULLIF(SUM(step4), 0) AS step4_to_5_pct
FROM steps;

MAX(CASE ...) схлопывает события пользователя в флаги «дошёл до шага N», а отношения соседних сумм дают конверсию каждого перехода. Шаг с самым большим падением конверсии чините первым — это даёт максимальный прирост общего completion.

Time to complete

Одна цифра completion не показывает, сколько усилий стоило пройти туториал. Время прохождения ловит скрытое трение: если медиана в минутах, а p90 в десятках минут — часть людей мучается.

WITH tutorial_times AS (
    SELECT
        user_id,
        MIN(event_time) FILTER (WHERE event_name = 'tutorial_started') AS start_time,
        MIN(event_time) FILTER (WHERE event_name = 'tutorial_completed') AS complete_time
    FROM events
    WHERE event_name IN ('tutorial_started', 'tutorial_completed')
      AND event_time >= CURRENT_DATE - INTERVAL '30 days'
    GROUP BY user_id
)
SELECT
    AVG(EXTRACT(EPOCH FROM (complete_time - start_time))) AS avg_seconds,
    PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (complete_time - start_time))) AS median_seconds,
    PERCENTILE_CONT(0.9) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (complete_time - start_time))) AS p90_seconds
FROM tutorial_times
WHERE complete_time IS NOT NULL;

Смотрите на медиану и p90, а не только на среднее: среднее легко смещается длинным хвостом (кто-то открыл туториал и вернулся через день). Медиана показывает типичный опыт, p90 — насколько тяжело худшим 10%.

Связь прохождения и активации

Completion интересен не сам по себе, а тем, ведёт ли он к активации. Проверить это можно, сравнив долю активации у тех, кто прошёл туториал, и у тех, кто нет:

WITH tutorial_status AS (
    SELECT
        user_id,
        EXISTS (
            SELECT 1 FROM events
            WHERE user_id = u.user_id AND event_name = 'tutorial_completed'
        ) AS completed_tutorial,
        EXISTS (
            SELECT 1 FROM events
            WHERE user_id = u.user_id AND event_name = 'activation_event'
            AND event_time <= u.created_at + INTERVAL '7 days'
        ) AS activated_7d
    FROM users u
    WHERE u.created_at >= CURRENT_DATE - INTERVAL '90 days'
)
SELECT
    completed_tutorial,
    COUNT(*) AS users,
    SUM(CASE WHEN activated_7d THEN 1 ELSE 0 END) AS activated,
    SUM(CASE WHEN activated_7d THEN 1 ELSE 0 END)::NUMERIC * 100 / COUNT(*) AS activation_pct
FROM tutorial_status
GROUP BY completed_tutorial;

Обычно прошедшие туториал активируются в 2–3 раза чаще. Но помните про ловушку причинности: это может значить не «туториал вызывает активацию», а «изначально мотивированные пользователи и туториал допроходят, и активируются». Чтобы проверить реальный эффект туториала, нужен A/B-тест, а не корреляция.

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

Не определить, считается ли пропуск за прохождение. Пользователь нажал «Пропустить» — это completed или нет? Правило нужно зафиксировать заранее, иначе метрика неоднозначна.

Не заметить потерю событий трекинга. Баг в трекинге теряет события шагов, и completion выглядит искусственно низким. Прежде чем чинить продукт, проверьте, что данные вообще доходят.

Не решить, как считать вернувшихся. Пользователь сбросил и перепрошёл туториал спустя недели — засчитывать один раз или два? От этого зависит и знаменатель, и трактовка.

Игнорировать дрейф когорт. Если туториал переделали, старая и новая когорты несравнимы напрямую — сравнивать completion нужно внутри однородных когорт.

Путать корреляцию с причинностью. Вовлечённые пользователи чаще допроходят туториал, но это не значит, что туториал сделал их вовлечёнными. Реальный эффект показывает только эксперимент.

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

• Как посчитать activation rate в SQL
• Как посчитать funnel в SQL
• Как посчитать aha moment в SQL
• Activation framework для продукта

FAQ

Какой Tutorial Completion считается нормальным?

Ориентиры зависят от типа продукта: в мобильных играх это часто 60–80%, в SaaS — 40–60%, в сложных продуктах может быть и 20–40%. Абсолютное число само по себе мало значит — важнее динамика и разрез по шагам.

Обязательный туториал или необязательный?

Обязательный (mandatory) искусственно завышает completion, потому что пройти его вынуждают. Необязательный (optional) точнее отражает реальную вовлечённость, но его завершают меньше. При сравнении метрик важно учитывать, какой у вас тип.

Туториал слишком длинный — как понять?

Косвенный признак — растущий drop-off ближе к концу и большой time-to-complete (медиана выше 3–5 минут). Чаще всего короткий туториал работает лучше, но не в ущерб ключевым концепциям, которые пользователю действительно нужны.

Оптимизировать ли время прохождения?

Обычно быстрее — лучше: меньше трения, меньше шансов отвалиться. Исключение — когда ускорение достигается за счёт пропуска важных шагов, из-за чего страдает последующая активация. Смотрите на связку «время + активация», а не на время в вакууме.

Tutorial Completion и активация — это одно и то же?

Нет. Прохождение туториала — механический факт «докликал до конца». Активация — момент, когда пользователь прочувствовал ценность продукта (aha moment). Пройденный туториал не гарантирует активацию, поэтому мерить и оптимизировать нужно обе метрики.