docs(labs): расследования выручки привязаны к задачам DE

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

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

Проверка: SELECT-запросы под analyst, расчеты по сохраненной истории девяти наблюдений, 54 локальные ссылки, git diff --check и независимое техническое ревью.

docs/labs/optional/missing-purchases.md

@@ -1,7 +1,7 @@
 # Куда пропали покупки
 
-**Чему учит:** обнаружить потерю событий при сверке двух источников и
-обосновать, каким данным можно доверять при подсчете покупок.
+**Чему учит:** проверить полноту данных по независимому источнику и выбрать
+источник для витрины заказов.
 
 Факультатив доступен после ступени 1. В DBeaver подключитесь пользователем
 `analyst` по [инструкции](../../../README.md#подключиться-из-dbeaver).
@@ -10,8 +10,9 @@
 
 ## Выберите день
 
-Магазин зарегистрировал заказы, но часть событий покупки не дошла до трекера.
-Найдите след этой потери сначала в событиях сайта, затем в заказах.
+Можно ли построить полную витрину заказов по событиям `purchase`?
+Проверьте это на одном дне: сначала сопоставьте события сайта, затем сверьте
+номера заказов с выгрузкой магазина.
 
 Возьмите день, для которого уже получен последний слепок семидневного окна.
 Запрос показывает самую позднюю подходящую дату:
@@ -46,6 +47,9 @@ FROM ods.order_v;
 В событии номер заказа находится в `purchase_id[1]`, в заказах — в `order_id`.
 Соберите список заказов выбранного дня, для которых нет события покупки.
 Несколько событий с одним номером заказа должны оставаться одной покупкой.
+Сохраните запрос сверки: на каждый такой заказ он должен возвращать дату,
+номер и статус. Дату задавайте в одном месте, чтобы запрос можно было
+повторить для другого дня.
 
 Проверьте два равенства:
 
@@ -67,9 +71,6 @@ FROM ods.order_v;
 к устройству этого стенда; для другого источника его нужно проверять заново.
 
 Если в выбранном дне повторов нет, возьмите другой закрытый день.
-Для оценки доли потерь используйте число заказов магазина. Затем посчитайте
-долю с тем же числителем, но с числом просмотров подтверждения в знаменателе.
-Совпали ли результаты? Свяжите различие знаменателей с найденными событиями.
 
 ## Сопоставьте вывод с готовой сверкой
 
@@ -80,13 +81,22 @@ FROM ods.order_v;
 объясните, почему потеря события не всегда попадает в `lost_event`.
 
 Возьмите один заказ из своего списка и сохраните два запроса: первый находит
-его в магазине, второй показывает отсутствие покупки в трекере. Сформулируйте,
-какой источник нужен для отчета о поведении посетителей, а какой — для денег.
+его в магазине, второй показывает отсутствие покупки в трекере.
+
+## Выберите источник и условие проверки
+
+По результатам сверки укажите источник для витрины, в которой должен быть
+каждый зарегистрированный заказ. Обоснуйте выбор найденными номерами.
+
+Рядом с запросом запишите, когда его результат можно считать окончательным.
+Что изменится, если запустить его до получения всех слепков выбранного дня?
+Позволяет ли отсутствие события в `dds.event_v` установить место потери —
+до приема в хранилище или при обработке? Какие данные нужны, чтобы это выяснить?
 
 ## Что должно получиться
 
-- [ ] сохранены день, счетчики воронки и список заказов без события;
+- [ ] сохранен запрос сверки по дате, возвращающий заказы без события;
 - [ ] оба равенства сходятся, влияние повторного просмотра объяснено;
-- [ ] доля потерь посчитана с обоснованным знаменателем;
 - [ ] один случай подтвержден запросами к обоим источникам;
-- [ ] вы различаете отсутствие события и класс строки в готовой сверке.
+- [ ] источник витрины выбран по результатам сверки;
+- [ ] указаны условие окончательной проверки и границы ее выводов.