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

Зачем: дать практику сверки событий покупки с заказами магазина. Что: задания о потерях событий, повторах покупок и расхождении состава корзин. Проверка: запросы под analyst на ClickHouse 26.3.17.56; счетчики, суммы и точный разбор JSON сошлись. make lint и независимая техническая проверка пройдены.
2026-09-22 03:46:45 -04:00
1 parent ddb186f841
commit 2502277af1
@@ -0,0 +1,65 @@
+# Почему повтор покупки завышает выручку
+
+**Чему учит:** отличать повторную доставку строки от повторного события об
+одной покупке и выбирать ключ, по которому считать деньги.
+
+Факультатив доступен после ступени 1. Работайте в DBeaver пользователем
+`analyst` по [инструкции](../../../README.md#подключиться-из-dbeaver).
+Дождитесь завершения `etl_pipeline`; оставьте `world_live` на паузе и
+дождитесь уже начатых прогонов, чтобы данные не менялись между запросами.
+
+## Посчитайте клиентскую сумму двумя способами
+
+Возьмите один закрытый день: его дата должна быть не позднее
+`max(snapshot_date) - 6` из `ods.order_v`. Во всех запросах к `dds.event_v`
+отбирайте этот `event_date` и `event_type = 'purchase'`.
+
+Номер заказа находится в `purchase_id[1]`, заявленная сумма — в
+`purchase_revenue[1]`. По формату источника у события покупки один номер заказа.
+
+Сначала посчитайте число событий и сумму всех заявленных сумм. Затем найдите
+номера заказов, которые встречаются несколько раз. Если таких нет, выберите
+другой закрытый день.
+
+Для двух повторившихся покупок выпишите `event_id`, `client_id`, `event_time`,
+номер заказа и сумму. Сопоставьте число событий и заказов в `dds.order_v`.
+
+Теперь рассчитайте клиентскую сумму, учитывая каждый номер заказа один раз.
+До выбора одной суммы на заказ проверьте, что во всех его событиях она
+одинакова. Объясните, почему удалять одинаковые денежные значения вместо
+повторных номеров заказов было бы ошибкой.
+
+## Объясните разницу
+
+Для каждого повторившегося заказа определите число лишних событий и их
+вклад в завышение. Сложите эти вклады и сверьте с разностью двух расчетов.
+Равенство должно выполняться до копейки.
+
+Слой ODS убирает повторную доставку одного события по его идентификатору;
+`dds.event_v` читает уже это состояние. Объясните по своим строкам, почему
+повтор покупки сохранился. Какие поля совпадают и какие различаются?
+Какой ключ отвечает на вопрос «это то же событие», а какой — «это тот же заказ»?
+
+После собственного расчета найдите эти заказы в `dm.purchase_vs_orders_v`.
+Если у повторившегося заказа класс отличается от `duplicate_event`, проверьте
+его статус и [порядок присвоения классов](../../architecture/dm.md#dmpurchase_vs_orders_v).
+Класс витрины не заменяет поиск всех повторов в событиях.
+
+## Сравните с выручкой магазина
+
+Сложите `revenue` из `dm.revenue_daily_v` за тот же `report_date` по всем
+категориям. Эта витрина считает стоимость позиций оплаченных заказов,
+без скидки и доставки.
+
+Сравните результат с исправленной клиентской суммой. Совпадение не требуется:
+удаление повторов устраняет одну причину расхождения. Найдите хотя бы один
+заказ, который объясняет, почему деньги трекера и магазина все еще могут
+различаться. Для этого сопоставьте события, заказ и готовую сверку.
+
+## Что должно получиться
+
+- [ ] сохранены две клиентские суммы и строки повторившихся покупок;
+- [ ] разность сумм полностью объяснена вкладом лишних событий;
+- [ ] выбор ключа для устранения повторов подтвержден данными;
+- [ ] вы можете объяснить, почему устранение повторов не завершает сверку
+      выручки с магазином.