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`. Как связаны эти суммы? Объясните, почему клиентскую
+`delivery` и `total`. Запишите равенство, связывающее эти четыре значения,
-`declared_revenue` нужно сравнивать с `items_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`, и ноль в остальных
+из `paid` в `cancelled`. Разложите изменение выручки по заказам.
-случаях, включая отсутствие заказа. Разность вкладов объясняет, сколько
+Составьте таблицу: номер заказа, прежний и новый статусы, вклад в выручку
-каждый заказ добавил к отчету или убрал из него. Сумма этих изменений должна
+до и после изменения. Вклад определите по правилу расчета витрины, указанному
-совпасть с изменением `revenue` до копейки.
+выше; учтите и заказы, которых еще не было в первом наблюдении. Сумма
+изменений вкладов должна совпасть с изменением `revenue` до копейки.
 
-Запишите даты, между которыми выручка выросла или уменьшилась. Отдельный
+Для одного из этих отмененных заказов сравните изменение его вклада
-отмененный заказ мог убрать деньги, даже если итог дня вырос: покажите это
+с изменением общей выручки между теми же наблюдениями. Совпало ли
-по его вкладу. Одна общая сумма скрывает встречные изменения.
+направление изменений? Найдите в своей таблице заказы, определившие общий итог.
 
 ## Что известно об отменах
 
 Возьмите отмененный заказ, у которого в вашей истории был статус `paid`.
 Укажите два наблюдения, доказывающих, что он был оплачен, а затем отменен.
 
-Для отмененного заказа без наблюдаемой оплаты сформулируйте предел вывода.
+Теперь возьмите отмененный заказ, для которого ни в одной вашей выгрузке
-Дневные слепки могли не застать промежуточное состояние: оплата и отмена
+нет `paid`. Проверьте утверждение «этот заказ никогда не был оплачен»:
-могли произойти между ними. Поэтому отсутствие `paid` в выгрузках не
+что известно о его состоянии между двумя слепками? Достаточно ли сохраненных
-доказывает, что оплаты не было. Не заменяйте недостающие данные догадкой.
+наблюдений для такого вывода? Укажите, какие данные позволили бы его проверить.
 
 ## Когда день закрыт
 
 Сравните сохраненные состояния при S = D + 6 и S = D + 7: состав заказов,
-их статусы, суммы и выручку. Объясните, почему отчет за D теперь окончательный.
+их статусы, суммы и выручку. Какой слепок последним мог изменить заказы дня D
-Основание — получен и обработан последний слепок окна изменяемости;
+и каким прогоном он доставлен? Укажите наблюдение, после которого отчет
-одно совпадение сумм в соседних наблюдениях этого не доказывает.
+можно считать окончательным. Было бы достаточно совпадения двух соседних
+сумм, если бы окно еще не закончилось?
 
 После собственных выводов сверьтесь с описанием
 [слепка и его доставки](../../architecture/orders/snapshot.md#слепок-и-его-доставка)