Воронка в SQL: почему наличие трёх событий ещё не означает прохождение

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

Как разобрать ситуацию

В учебной модели один пользователь имеет не более одной попытки каждого шага. Сравниваем временные отметки: оформление должно быть после просмотра, а оплата после оформления. Для реального продукта с несколькими попытками придётся выбирать допустимую цепочку событий; независимый MIN для каждого типа способен соединить чужие попытки и исказить результат.

Пример и ожидаемый результат

У первого пользователя просмотр был в минуту 1, оформление в 3, оплата в 5. У второго оплата стоит в 2, а оформление в 4. Полностью прошёл только первый, несмотря на одинаковый набор названий событий.

WITH attempts(user_id,view_t,checkout_t,pay_t) AS(VALUES(1,1,3,5),(2,1,4,2),(3,1,2,NULL)) 
SELECT user_id 
FROM attempts 
WHERE checkout_t>=view_t AND pay_t>=checkout_t 
ORDER BY user_id;

Запрос возвращает только пользователя 1. Контрольный набор показывает, что проверяется порядок, а не простое присутствие всех событий.

Проверка перед применением

• Добавьте пользователя без оплаты: он должен остаться на предыдущем шаге.
• Определите, допускаются ли события с одинаковым временем и как разрешаются такие совпадения.
• Проверьте, не объединяете ли вы шаги разных заказов одного пользователя.

Попросите аналитика вручную восстановить путь нескольких клиентов с неуспешной конверсией. Это полезнее сверки только общего процента: одна ошибочная цепочка может компенсировать другую. Также зафиксируйте, измеряете ли вы людей, сессии или заказы, иначе разные команды получат несопоставимые воронки.

Границы решения

Этот пример намеренно хранит одну попытку в строке. Для событийного журнала нужны явные правила окна конверсии, повторных попыток и связывания по session_id или order_id.

Если запросы уже пишутся, а уверенности в кардинальности, оконных рамках и проверке результата не хватает, продолжить практику можно в нашем платном курсе

Продвинутый SQL: сложные запросы и задачи для собеседований. Перед записью сравните программу со своей задачей и подготовкой.

Техническая справка: www.sqlite.org: документация.

Следующий шаг: Сложные SQL-запросы: разборы расчётов и ошибок. По смежным вопросам: Поздние события в SQL: почему вчерашний отчёт меняется сегодня, Просроченные заявки в SQL: почему открытые тикеты нельзя выбрасывать из SLA.