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

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

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

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

docs/labs/optional/duplicate-purchases.md

@@ -1,14 +1,17 @@
 # Почему повтор покупки завышает выручку
 
-**Чему учит:** отличать повторную доставку строки от повторного события об
-одной покупке и выбирать ключ, по которому считать деньги.
+**Чему учит:** выбрать зерно и ключ расчета, чтобы повторные события
+не умножали денежную сумму.
 
 Факультатив доступен после ступени 1. Работайте в DBeaver пользователем
 `analyst` по [инструкции](../../../README.md#подключиться-из-dbeaver).
 Дождитесь завершения `etl_pipeline`; оставьте `world_live` на паузе и
 дождитесь уже начатых прогонов, чтобы данные не менялись между запросами.
 
-## Посчитайте клиентскую сумму двумя способами
+## Проверьте расчет по событиям
+
+В ODS уже устранены повторные доставки событий. Достаточно ли этого,
+чтобы сложить суммы всех `purchase` для витрины заказов? Проверьте на данных.
 
 Возьмите один закрытый день: его дата должна быть не позднее
 `max(snapshot_date) - 6` из `ods.order_v`. Во всех запросах к `dds.event_v`
@@ -24,10 +27,16 @@
 Для двух повторившихся покупок выпишите `event_id`, `client_id`, `event_time`,
 номер заказа и сумму. Сопоставьте число событий и заказов в `dds.order_v`.
 
-Теперь рассчитайте клиентскую сумму, учитывая каждый номер заказа один раз.
-До выбора одной суммы на заказ проверьте, что во всех его событиях она
-одинакова. Проверьте свое решение на случае двух разных заказов с одинаковой
-суммой: сколько денег оно учтет?
+## Соберите расчет по заказам
+
+Напишите запрос с одной строкой на номер заказа. Сохраните в результате
+номер, число исходных событий и одну заявленную сумму. До выбора суммы
+проверьте, что во всех событиях заказа она одинакова. Затем посчитайте итог
+дня по результату этого запроса и сравните с расчетом по событиям.
+
+Проверьте, что номера в результате уникальны, а число строк совпадает с числом
+разных номеров в исходных событиях. Отдельно проверьте свое решение на случае
+двух разных заказов с одинаковой суммой: сколько денег оно учтет?
 
 ## Найдите заказы, из-за которых сумма завышена
 
@@ -49,7 +58,7 @@
 его статус и [порядок присвоения классов](../../architecture/dm.md#dmpurchase_vs_orders_v).
 Класс витрины не заменяет поиск всех повторов в событиях.
 
-## Сравните с выручкой магазина
+## Определите границы расчета
 
 Сложите `revenue` из `dm.revenue_daily_v` за тот же `report_date` по всем
 категориям. Эта витрина считает стоимость позиций оплаченных заказов,
@@ -60,10 +69,14 @@
 заказ, который объясняет, почему деньги трекера и магазина все еще могут
 различаться. Для этого сопоставьте события, заказ и готовую сверку.
 
+Рядом со своим запросом укажите его зерно и ключ. Обоснуйте, где нужна одна
+строка на событие, а где — одна на заказ: следует ли ради этого расчета
+удалять повторные покупки из `dds.event_v`? Используйте найденные `event_id`.
+
 ## Что должно получиться
 
-- [ ] сохранены две клиентские суммы и строки повторившихся покупок;
+- [ ] сохранен запрос с одной строкой на заказ, числом событий и суммой;
+- [ ] уникальность ключа и полнота набора номеров проверены по источнику;
 - [ ] разность сумм полностью объяснена вкладом лишних событий;
-- [ ] выбор ключа для устранения повторов подтвержден данными;
-- [ ] вы можете объяснить, почему устранение повторов не завершает сверку
-      выручки с магазином.
+- [ ] обоснованы ключ расчета и место устранения повторов;
+- [ ] найден случай, показывающий границы расчета денег по трекеру.