ddadmin
bb087f4477
Зачем: учащемуся нужен понятный путь от наблюдений к выводу без готового ответа в задании. Что: уточнены сравнения в четырех расследованиях; готовые объяснения заменены вопросами к строкам, расчетам и сохраненным состояниям. Проверка: проверены 54 локальные ссылки и git diff --check; формулировки сверены с устройством источников и витрин.
70 lines
5.5 KiB
Markdown
70 lines
5.5 KiB
Markdown
# Почему повтор покупки завышает выручку
|
|
|
|
**Чему учит:** отличать повторную доставку строки от повторного события об
|
|
одной покупке и выбирать ключ, по которому считать деньги.
|
|
|
|
Факультатив доступен после ступени 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` читает уже это состояние. Сравните число разных `event_id`
|
|
и число разных номеров заказа в выбранных строках. Почему устранение
|
|
повторов по первому ключу не дало тот же результат, что по второму?
|
|
Подтвердите ответ конкретными идентификаторами.
|
|
|
|
После собственного расчета найдите эти заказы в `dm.purchase_vs_orders_v`.
|
|
Если у повторившегося заказа класс отличается от `duplicate_event`, проверьте
|
|
его статус и [порядок присвоения классов](../../architecture/dm.md#dmpurchase_vs_orders_v).
|
|
Класс витрины не заменяет поиск всех повторов в событиях.
|
|
|
|
## Сравните с выручкой магазина
|
|
|
|
Сложите `revenue` из `dm.revenue_daily_v` за тот же `report_date` по всем
|
|
категориям. Эта витрина считает стоимость позиций оплаченных заказов,
|
|
без скидки и доставки.
|
|
|
|
Сравните результат с исправленной клиентской суммой. Совпадение не требуется:
|
|
удаление повторов устраняет одну причину расхождения. Найдите хотя бы один
|
|
заказ, который объясняет, почему деньги трекера и магазина все еще могут
|
|
различаться. Для этого сопоставьте события, заказ и готовую сверку.
|
|
|
|
## Что должно получиться
|
|
|
|
- [ ] сохранены две клиентские суммы и строки повторившихся покупок;
|
|
- [ ] разность сумм полностью объяснена вкладом лишних событий;
|
|
- [ ] выбор ключа для устранения повторов подтвержден данными;
|
|
- [ ] вы можете объяснить, почему устранение повторов не завершает сверку
|
|
выручки с магазином.
|