Как посчитать actions per session в SQL

Зачем actions per session

В отличие от session depth (все events), actions per session считает только meaningful interactions: click, submit, share, save. Это «полезный output» сессии. Падение actions per session при росте traffic — flag: новые юзеры менее вовлечены или UX усложнился.

Что считать action

• Click on CTA, button
• Form submit
• File upload, download
• Like, comment, share
• Save, bookmark

НЕ считайте: page_view, scroll, hover, session_start. Это passive события.

Формула в SQL

WITH session_events AS (
    SELECT
        session_id,
        SUM(CASE WHEN event_name IN ('click', 'submit', 'share', 'save') THEN 1 ELSE 0 END) AS actions,
        COUNT(*) AS total_events
    FROM events
    WHERE event_timestamp >= CURRENT_DATE - INTERVAL '30 days'
    GROUP BY session_id
)
SELECT
    AVG(actions) AS avg_actions,
    AVG(total_events) AS avg_events,
    AVG(actions::NUMERIC / NULLIF(total_events, 0)) AS action_ratio,
    COUNT(*) AS sessions
FROM session_events;

action_ratio 0.2 означает 1 действие на каждые 5 событий — типично для browse-flow продукта.

По типу действия

SELECT
    event_name,
    COUNT(*) AS total_occurrences,
    COUNT(DISTINCT session_id) AS sessions_with_event,
    COUNT(*)::NUMERIC / NULLIF(COUNT(DISTINCT session_id), 0) AS avg_per_session
FROM events
WHERE event_timestamp >= CURRENT_DATE - INTERVAL '30 days'
  AND event_name IN ('click', 'submit', 'share', 'save', 'comment', 'LIKE')
GROUP BY event_name
ORDER BY total_occurrences DESC;

Видно, какие действия частые, какие редкие. Если comments per session = 0.05, фича почти не используется.

Динамика после релиза

WITH release_date AS (
    SELECT DATE '2026-04-15' AS release_date
),
weekly AS (
    SELECT
        DATE_TRUNC('week', event_timestamp)::DATE AS week,
        AVG(actions) AS avg_actions_per_session
    FROM session_actions
    GROUP BY DATE_TRUNC('week', event_timestamp)
)
SELECT
    week,
    avg_actions_per_session,
    CASE WHEN week >= (SELECT release_date FROM release_date) THEN 'post' ELSE 'pre' END AS period
FROM weekly
ORDER BY week;

Если post-release avg растёт — фича работает. Падает — что-то стало хуже.

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

Ошибка 1. Считать все events. Page views и scrolls раздувают numerator. Только meaningful actions.

Ошибка 2. Bots не отфильтрованы. Bot session с 500 events перекосит average.

Ошибка 3. Сессии разной длины. Сессия 5 минут vs 60 минут — actions в них разные. Нормируйте по minutes.

Ошибка 4. Не различать types. Click on FAQ ≠ click on Buy. Сегментируйте по weight (revenue per action).

Ошибка 5. Только session-aggregate. Per-user может показать другую картину — top юзеры делают 10x больше actions.

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

• Как посчитать session depth в SQL
• Как посчитать sessions в SQL
• Как посчитать engagement в SQL
• Как посчитать time-on-site в SQL

FAQ

Какие events считать action?

Те, что меняют state (submit, save, like, share). Не view, scroll, hover.

Какой бенчмарк?

E-com: 2-5 actions/session. SaaS: 5-15. Социалка: 10-50.

Action ratio низкий — плохо?

Зависит. Поисковая страница в большинстве случаев — passive scroll, низкий ratio норма.

Можно ли использовать как North Star?

Иногда. Slack использовал «messages per user per day» — близкая идея.

Action vs interaction?

Synonym. Interaction иногда шире (includes hover/scroll).