docs(labs): уточнены вопросы для самостоятельного расследования

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

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

Проверка: проверены 54 локальные ссылки и git diff --check; формулировки сверены с устройством источников и витрин.

docs/labs/optional/duplicate-purchases.md

@@ -26,19 +26,23 @@
 
 Теперь рассчитайте клиентскую сумму, учитывая каждый номер заказа один раз.
 До выбора одной суммы на заказ проверьте, что во всех его событиях она
-одинакова. Объясните, почему удалять одинаковые денежные значения вместо
-повторных номеров заказов было бы ошибкой.
+одинакова. Проверьте свое решение на случае двух разных заказов с одинаковой
+суммой: сколько денег оно учтет?
 
-## Объясните разницу
+## Найдите заказы, из-за которых сумма завышена
 
-Для каждого повторившегося заказа определите число лишних событий и их
-вклад в завышение. Сложите эти вклады и сверьте с разностью двух расчетов.
-Равенство должно выполняться до копейки.
+Возьмите один повторившийся номер заказа. Сколько денег он добавил в первый
+расчет и сколько — во второй? Подтвердите разность его событиями.
+
+Повторите расчет для остальных повторившихся номеров. Сохраните таблицу:
+номер заказа, число событий и вклад в разность сумм. Проверьте, объясняют ли
+эти заказы все расхождение за день до копейки.
 
 Слой ODS убирает повторную доставку одного события по его идентификатору;
-`dds.event_v` читает уже это состояние. Объясните по своим строкам, почему
-повтор покупки сохранился. Какие поля совпадают и какие различаются?
-Какой ключ отвечает на вопрос «это то же событие», а какой — «это тот же заказ»?
+`dds.event_v` читает уже это состояние. Сравните число разных `event_id`
+и число разных номеров заказа в выбранных строках. Почему устранение
+повторов по первому ключу не дало тот же результат, что по второму?
+Подтвердите ответ конкретными идентификаторами.
 
 После собственного расчета найдите эти заказы в `dm.purchase_vs_orders_v`.
 Если у повторившегося заказа класс отличается от `duplicate_event`, проверьте

docs/labs/optional/missing-purchases.md

@@ -28,13 +28,18 @@ FROM ods.order_v;
 
 ## Найдите разрыв в событиях
 
+При оформлении заказа посетитель видит страницу подтверждения, а трекер
+отправляет событие покупки. Просмотр страницы и покупка — отдельные события.
+
 Посчитайте просмотры страницы подтверждения и события покупки:
 
 - у просмотра `event_type = 'pageview'`, а `url` заканчивается на `/confirmation`;
 - у покупки `event_type = 'purchase'`.
 
-Запишите оба числа и разность. Какую потерю она позволяет заподозрить?
-Достаточно ли этих двух чисел, чтобы назвать пропавшие покупки?
+Вычтите число событий покупки из числа просмотров подтверждения. Сохраните
+оба счетчика и разность. Как соотносились бы эти числа, если бы для каждого
+заказа пришло ровно по одному событию каждого вида? Что можно предположить
+по вашему результату и чего эти два числа еще не доказывают?
 
 ## Сверьте с магазином
 
@@ -49,14 +54,22 @@ FROM ods.order_v;
 - разность просмотров подтверждения и событий покупки равна числу заказов
   без события.
 
-Первое равенство проверяет полноту сопоставления источников. Второе относится
-к устройству этого стенда. Найдите покупку с повторным событием и посмотрите
-соседние события того же `client_id` по времени: что произошло со страницей
-подтверждения? Объясните, почему повтор не скрыл разрыв воронки.
+Первое равенство проверяет полноту сопоставления источников. Второе связывает
+разность счетчиков с найденными заказами без события. Проверьте, как на него
+влияют повторные покупки.
+
+Найдите номер заказа с несколькими событиями `purchase`. Для его `client_id`
+выведите события рядом с этими покупками по времени: `event_time`,
+`event_type` и `url`. Найдите просмотры `/confirmation` перед первой
+и повторной покупкой. Посчитайте, сколько повтор добавил просмотров
+подтверждения и сколько — покупок. Изменилась ли от этих добавлений разность
+счетчиков? Подтвердите ответ найденными строками. Второе равенство относится
+к устройству этого стенда; для другого источника его нужно проверять заново.
 
 Если в выбранном дне повторов нет, возьмите другой закрытый день.
-Для оценки доли потерь используйте число заказов магазина и объясните,
-почему число просмотров подтверждения может дать другую долю.
+Для оценки доли потерь используйте число заказов магазина. Затем посчитайте
+долю с тем же числителем, но с числом просмотров подтверждения в знаменателе.
+Совпали ли результаты? Свяжите различие знаменателей с найденными событиями.
 
 ## Сопоставьте вывод с готовой сверкой
 

docs/labs/optional/order-amount-difference.md

@@ -16,9 +16,10 @@
 `order_day`, `declared_revenue` и `items_total`.
 
 Найдите этот заказ в `dds.order_v`. Сопоставьте `items_total`, `discount`,
-`delivery` и `total`. Как связаны эти суммы? Объясните, почему клиентскую
-`declared_revenue` нужно сравнивать с `items_total`, чтобы искать разницу
-именно в составе корзины.
+`delivery` и `total`. Запишите равенство, связывающее эти четыре значения,
+и проверьте его на заказе. С какой суммой магазина следует сравнивать
+`declared_revenue`, если мы ищем расхождение именно в составе корзины?
+Проверьте свой выбор после разбора позиций.
 
 ## Разберите позиции с двух сторон
 
@@ -37,9 +38,9 @@
 к одной позиции; при разворачивании сохраняйте эту связь.
 
 Сопоставьте позиции по артикулу так, чтобы остались видны товары,
-присутствующие только с одной стороны. Покажите, какие позиции совпали,
-а какая объясняет разницу. В результате нужны строки товаров, а не только
-две итоговые суммы.
+присутствующие только с одной стороны. Для каждой позиции сравните наличие,
+цену и количество. Что различается и сколько это добавляет к расхождению
+сумм? В результате нужны строки товаров, а не только две итоговые суммы.
 
 ## Проверьте объяснение
 
@@ -47,19 +48,19 @@
 
 - сумма стоимостей клиентских позиций равна `declared_revenue`;
 - сумма стоимостей позиций магазина равна `items_total`;
-- стоимость отсутствующей у магазина позиции равна
+- сумма расхождений по позициям равна
   `declared_revenue - items_total`.
 
 Затем сравните точные цены из JSON с готовым массивом `productPrice`
-события. По [формату выгрузки](../../formats/clickstream-event.md) цены в нем
-округлены до целых рублей. Покажите на своей корзине, что потеряется при
-расчете по этому массиву. Если все цены выбранной корзины целые, возьмите
-еще один заказ с расхождением и дробной ценой.
+события. Пересчитайте стоимость клиентской корзины по этому массиву:
+сойдется ли она с `declared_revenue` до копейки? Найдите цены, на которых
+результаты различаются, и сверьте наблюдение с
+[форматом выгрузки](../../formats/clickstream-event.md). Если все цены
+выбранной корзины целые, возьмите еще один заказ с расхождением и дробной ценой.
 
 В коротком объяснении назовите заказ, товар, количество, цену и разницу.
-Отделите то, что подтверждают данные, от причины, которую по ним установить
-нельзя: отсутствие позиции в заказе видно, а причину ее удаления источник
-отдельным полем не сообщает.
+Какие строки подтверждают найденное расхождение? Есть ли в источниках
+сведения о том, почему оно возникло? Отделите наблюдения от предположений.
 
 ## Что должно получиться
 

docs/labs/optional/revenue-over-time.md

@@ -69,8 +69,8 @@ SELECT
 отправляет события без пауз; ждать 24 минуты живого дня здесь не нужно.
 
 Продолжайте до слепка **D + 7** включительно. У заказов дня D окно состоит
-из семи дней, от D до D + 6. Слепок D + 6 содержит окончательное состояние,
-а еще один шаг позволит проверить, что оно сохранилось за пределами окна.
+из семи дней, от D до D + 6. Последний шаг нужен для сравнения состояния
+в конце окна и за его пределами.
 От исходного наблюдения потребуется восемь однодневных запусков.
 
 ## Объясните изменения отчета
@@ -86,32 +86,34 @@ SELECT
 Опоздавшими здесь считаются те, которых не было уже в этом слепке.
 Покажите на нескольких номерах, как они исчезают из `awaiting_order`.
 
-Для двух соседних наблюдений разложите изменение выручки по заказам.
-Вклад заказа — его `items_total`, если статус `paid`, и ноль в остальных
-случаях, включая отсутствие заказа. Разность вкладов объясняет, сколько
-каждый заказ добавил к отчету или убрал из него. Сумма этих изменений должна
-совпасть с изменением `revenue` до копейки.
+Выберите два соседних наблюдения, между которыми хотя бы один заказ перешел
+из `paid` в `cancelled`. Разложите изменение выручки по заказам.
+Составьте таблицу: номер заказа, прежний и новый статусы, вклад в выручку
+до и после изменения. Вклад определите по правилу расчета витрины, указанному
+выше; учтите и заказы, которых еще не было в первом наблюдении. Сумма
+изменений вкладов должна совпасть с изменением `revenue` до копейки.
 
-Запишите даты, между которыми выручка выросла или уменьшилась. Отдельный
-отмененный заказ мог убрать деньги, даже если итог дня вырос: покажите это
-по его вкладу. Одна общая сумма скрывает встречные изменения.
+Для одного из этих отмененных заказов сравните изменение его вклада
+с изменением общей выручки между теми же наблюдениями. Совпало ли
+направление изменений? Найдите в своей таблице заказы, определившие общий итог.
 
 ## Что известно об отменах
 
 Возьмите отмененный заказ, у которого в вашей истории был статус `paid`.
 Укажите два наблюдения, доказывающих, что он был оплачен, а затем отменен.
 
-Для отмененного заказа без наблюдаемой оплаты сформулируйте предел вывода.
-Дневные слепки могли не застать промежуточное состояние: оплата и отмена
-могли произойти между ними. Поэтому отсутствие `paid` в выгрузках не
-доказывает, что оплаты не было. Не заменяйте недостающие данные догадкой.
+Теперь возьмите отмененный заказ, для которого ни в одной вашей выгрузке
+нет `paid`. Проверьте утверждение «этот заказ никогда не был оплачен»:
+что известно о его состоянии между двумя слепками? Достаточно ли сохраненных
+наблюдений для такого вывода? Укажите, какие данные позволили бы его проверить.
 
 ## Когда день закрыт
 
 Сравните сохраненные состояния при S = D + 6 и S = D + 7: состав заказов,
-их статусы, суммы и выручку. Объясните, почему отчет за D теперь окончательный.
-Основание — получен и обработан последний слепок окна изменяемости;
-одно совпадение сумм в соседних наблюдениях этого не доказывает.
+их статусы, суммы и выручку. Какой слепок последним мог изменить заказы дня D
+и каким прогоном он доставлен? Укажите наблюдение, после которого отчет
+можно считать окончательным. Было бы достаточно совпадения двух соседних
+сумм, если бы окно еще не закончилось?
 
 После собственных выводов сверьтесь с описанием
 [слепка и его доставки](../../architecture/orders/snapshot.md#слепок-и-его-доставка)