0 Fork 0

Files

T

ddadmin 2502277af1 docs(labs): добавлены три расследования расхождений выручки

Зачем: дать практику сверки событий покупки с заказами магазина.
Что: задания о потерях событий, повторах покупок и расхождении состава корзин.
Проверка: запросы под analyst на ClickHouse 26.3.17.56; счетчики, суммы и точный разбор JSON сошлись. make lint и независимая техническая проверка пройдены.

2026-09-22 03:46:45 -04:00

5.6 KiB

Raw Blame History

Куда пропали покупки

Чему учит: обнаружить потерю событий при сверке двух источников и обосновать, каким данным можно доверять при подсчете покупок.

Факультатив доступен после ступени 1. В DBeaver подключитесь пользователем analyst по инструкции. Дождитесь завершения etl_pipeline; на время расследования оставьте world_live на паузе и дождитесь уже начатых прогонов.

Выберите день

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

Возьмите день, для которого уже получен последний слепок семидневного окна. Запрос показывает самую позднюю подходящую дату:

SELECT max(snapshot_date) - 6 AS last_closed_day
FROM ods.order_v;

Используйте выбранный день во всех запросах. События отбирайте по dds.event_v.event_date, заказы — по dds.order_v.order_date. Сравнивайте все заказы дня, включая отмененные: сейчас вопрос в том, зарегистрировал ли магазин заказ, а не в том, был ли он оплачен.

Найдите разрыв в событиях

Посчитайте просмотры страницы подтверждения и события покупки:

у просмотра event_type = 'pageview', а url заканчивается на /confirmation;
у покупки event_type = 'purchase'.

Запишите оба числа и разность. Какую потерю она позволяет заподозрить? Достаточно ли этих двух чисел, чтобы назвать пропавшие покупки?

Сверьте с магазином

В событии номер заказа находится в purchase_id[1], в заказах — в order_id. Соберите список заказов выбранного дня, для которых нет события покупки. Несколько событий с одним номером заказа должны оставаться одной покупкой.

Проверьте два равенства:

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

Первое равенство проверяет полноту сопоставления источников. Второе относится к устройству этого стенда. Найдите покупку с повторным событием и посмотрите соседние события того же client_id по времени: что произошло со страницей подтверждения? Объясните, почему повтор не скрыл разрыв воронки.

Если в выбранном дне повторов нет, возьмите другой закрытый день. Для оценки доли потерь используйте число заказов магазина и объясните, почему число просмотров подтверждения может дать другую долю.

Сопоставьте вывод с готовой сверкой

Найдите свои заказы без события в dm.purchase_vs_orders_v по order_id. Сравните их status и mismatch_class. Витрина присваивает заказу один класс, хотя причин расхождения может быть несколько. По правилу классификации объясните, почему потеря события не всегда попадает в lost_event.

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

Что должно получиться

сохранены день, счетчики воронки и список заказов без события;
оба равенства сходятся, влияние повторного просмотра объяснено;
доля потерь посчитана с обоснованным знаменателем;
один случай подтвержден запросами к обоим источникам;
вы различаете отсутствие события и класс строки в готовой сверке.

5.6 KiB Raw Blame History Unescape Escape