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

**Чему учит:** проверить полноту данных по независимому источнику и выбрать
источник для витрины заказов.

Факультатив доступен после ступени 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` установить место потери —
до приема в хранилище или при обработке? Какие данные нужны, чтобы это выяснить?

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

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