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

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

docs/labs/optional/missing-purchases.md

@@ -0,0 +1,79 @@
+# Куда пропали покупки
+
+**Чему учит:** обнаружить потерю событий при сверке двух источников и
+обосновать, каким данным можно доверять при подсчете покупок.
+
+Факультатив доступен после ступени 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`.
+
+Возьмите один заказ из своего списка и сохраните два запроса: первый находит
+его в магазине, второй показывает отсутствие покупки в трекере. Сформулируйте,
+какой источник нужен для отчета о поведении посетителей, а какой — для денег.
+
+## Что должно получиться
+
+- [ ] сохранены день, счетчики воронки и список заказов без события;
+- [ ] оба равенства сходятся, влияние повторного просмотра объяснено;
+- [ ] доля потерь посчитана с обоснованным знаменателем;
+- [ ] один случай подтвержден запросами к обоим источникам;
+- [ ] вы различаете отсутствие события и класс строки в готовой сверке.