ddadmin
2502277af1
Зачем: дать практику сверки событий покупки с заказами магазина. Что: задания о потерях событий, повторах покупок и расхождении состава корзин. Проверка: запросы под analyst на ClickHouse 26.3.17.56; счетчики, суммы и точный разбор JSON сошлись. make lint и независимая техническая проверка пройдены.
80 lines
5.6 KiB
Markdown
80 lines
5.6 KiB
Markdown
# Куда пропали покупки
|
||
|
||
**Чему учит:** обнаружить потерю событий при сверке двух источников и
|
||
обосновать, каким данным можно доверять при подсчете покупок.
|
||
|
||
Факультатив доступен после ступени 1. В DBeaver подключитесь пользователем
|
||
`analyst` по [инструкции](../../../README.md#подключиться-из-dbeaver).
|
||
Дождитесь завершения `etl_pipeline`; на время расследования оставьте
|
||
`world_live` на паузе и дождитесь уже начатых прогонов.
|
||
|
||
## Выберите день
|
||
|
||
Магазин зарегистрировал заказы, но часть событий покупки не дошла до трекера.
|
||
Найдите след этой потери сначала в событиях сайта, затем в заказах.
|
||
|
||
Возьмите день, для которого уже получен последний слепок семидневного окна.
|
||
Запрос показывает самую позднюю подходящую дату:
|
||
|
||
```sql
|
||
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`. Витрина присваивает заказу один класс,
|
||
хотя причин расхождения может быть несколько. По
|
||
[правилу классификации](../../architecture/dm.md#dmpurchase_vs_orders_v)
|
||
объясните, почему потеря события не всегда попадает в `lost_event`.
|
||
|
||
Возьмите один заказ из своего списка и сохраните два запроса: первый находит
|
||
его в магазине, второй показывает отсутствие покупки в трекере. Сформулируйте,
|
||
какой источник нужен для отчета о поведении посетителей, а какой — для денег.
|
||
|
||
## Что должно получиться
|
||
|
||
- [ ] сохранены день, счетчики воронки и список заказов без события;
|
||
- [ ] оба равенства сходятся, влияние повторного просмотра объяснено;
|
||
- [ ] доля потерь посчитана с обоснованным знаменателем;
|
||
- [ ] один случай подтвержден запросами к обоим источникам;
|
||
- [ ] вы различаете отсутствие события и класс строки в готовой сверке.
|