ddadmin
4693bc5af9
- Зачем: начинающим трудно читать задания из-за необъясненных терминов и неестественных формулировок. - Что: переработаны вводная и 21 задание, названы темы разделов, объяснены термины и сокращены повторы; согласованы правила учебного текста и ссылки. - Проверка: сохранены 25 блоков SQL и команд и таблицы состава колонок; проверены 153 локальные ссылки и 32 входящие ссылки на разделы; git diff --check прошел.
106 lines
7.9 KiB
Markdown
106 lines
7.9 KiB
Markdown
# Куда пропали покупки
|
||
|
||
Вы сравните покупки из событий сайта с заказами магазина. Найденные
|
||
расхождения помогут выбрать источник для полной витрины заказов.
|
||
|
||
Факультатив доступен после ступени 1. В DBeaver подключитесь пользователем
|
||
`analyst` по [инструкции](../../../README.md#подключиться-из-dbeaver).
|
||
Дождитесь завершения `etl_pipeline`; на время расследования оставьте
|
||
`world_live` на паузе и дождитесь уже начатых прогонов.
|
||
|
||
## Выбор дня
|
||
|
||
Можно ли построить полную витрину заказов по событиям `purchase`?
|
||
Проверьте это на одном дне: сначала сопоставьте события сайта, затем сверьте
|
||
номера заказов с выгрузкой магазина.
|
||
|
||
Слепок заказов содержит их состояние на конец модельного дня. Состояние
|
||
заказа может меняться семь дней, поэтому для окончательного сравнения нужны
|
||
все слепки за этот период. Возьмите день, для которого уже получен последний
|
||
из них. Такой день называется закрытым. Запрос показывает самую позднюю
|
||
подходящую дату:
|
||
|
||
```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`.
|
||
Соберите список заказов выбранного дня, для которых нет события покупки.
|
||
Несколько событий с одним номером заказа должны оставаться одной покупкой.
|
||
Сохраните запрос сверки: на каждый такой заказ он должен возвращать дату,
|
||
номер и статус. Дату задавайте в одном месте, чтобы запрос можно было
|
||
повторить для другого дня.
|
||
|
||
Проверьте два равенства:
|
||
|
||
- число заказов магазина равно числу разных заказов из событий плюс число
|
||
заказов без события;
|
||
- разность просмотров подтверждения и событий покупки равна числу заказов
|
||
без события.
|
||
|
||
Первое равенство проверяет полноту сопоставления источников. Второе связывает
|
||
разность счетчиков с найденными заказами без события. Проверьте, как на него
|
||
влияют повторные покупки.
|
||
|
||
Найдите номер заказа с несколькими событиями `purchase`. Для его `client_id`
|
||
выведите события рядом с этими покупками по времени: `event_time`,
|
||
`event_type` и `url`. Найдите просмотры `/confirmation` перед первой
|
||
и повторной покупкой. Посчитайте, сколько повтор добавил просмотров
|
||
подтверждения и сколько — покупок. Изменилась ли от этих добавлений разность
|
||
счетчиков? Подтвердите ответ найденными строками. Второе равенство относится
|
||
к устройству этого стенда; для другого источника его нужно проверять заново.
|
||
|
||
Если в выбранном дне повторов нет, возьмите другой закрытый день.
|
||
|
||
## Сравнение с готовой витриной
|
||
|
||
Найдите свои заказы без события в `dm.purchase_vs_orders_v` по `order_id`.
|
||
Сравните их `status` и `mismatch_class`. Витрина присваивает заказу один класс,
|
||
хотя причин расхождения может быть несколько. По
|
||
[правилу классификации](../../architecture/dm.md#dmpurchase_vs_orders_v)
|
||
объясните, почему потеря события не всегда попадает в `lost_event`.
|
||
|
||
Возьмите один заказ из своего списка и сохраните два запроса: первый находит
|
||
его в магазине, второй показывает отсутствие покупки в трекере.
|
||
|
||
## Выбор источника для витрины
|
||
|
||
По результатам сверки укажите источник для витрины, в которой должен быть
|
||
каждый зарегистрированный заказ. Обоснуйте выбор найденными номерами.
|
||
|
||
Рядом с запросом запишите, когда его результат можно считать окончательным.
|
||
Что изменится, если запустить его до получения всех слепков выбранного дня?
|
||
Позволяет ли отсутствие события в `dds.event_v` установить место потери —
|
||
до приема в хранилище или при обработке? Какие данные нужны, чтобы это выяснить?
|
||
|
||
## Результат работы
|
||
|
||
- [ ] сохранен запрос сверки по дате, возвращающий заказы без события;
|
||
- [ ] оба равенства сходятся, влияние повторного просмотра объяснено;
|
||
- [ ] один случай подтвержден запросами к обоим источникам;
|
||
- [ ] источник витрины выбран по результатам сверки;
|
||
- [ ] указаны условие окончательной проверки и границы ее выводов.
|