clickstream-data-platform/docs/labs/optional/revenue-over-time.md

Почему вчерашняя выручка меняется сегодня

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

Факультатив доступен после ступени 1. Понадобятся Airflow и DBeaver с подключением analyst по инструкции. Вы будете наблюдать один день оформления заказов, продвигая мир по одному модельному дню. Новые данные останутся в стенде.

Подготовьте первое наблюдение

Поставьте world_live на паузу. Дождитесь завершения начатых прогонов генерации и обработки, затем запустите etl_pipeline и дождитесь успеха. Так исходное наблюдение будет снято после обновления витрин.

Узнайте последний день событий и дату последнего полученного слепка:

SELECT
    (SELECT max(event_date) FROM dds.event_v) AS event_day,
    (SELECT max(snapshot_date) FROM ods.order_v) AS snapshot_day;

День event_day обозначим D. Наблюдайте именно его до конца работы. Дата слепка, по которому сделано очередное наблюдение, будет S. Это модельные даты магазина. Календарная дата запуска Airflow день D не задает.

Слепок снимается к концу суток и доставляется следующим прогоном. Поэтому покупки последнего сыгранного дня уже видны в событиях, а их заказов в хранилище еще нет. Проверьте это для D в dds.order_v и dm.purchase_vs_orders_v.

Подготовьте запросы и сохраняйте результаты

Напишите запросы для следующих наблюдений:

Что сохранить	Откуда взять
Дату полученного слепка S	max(snapshot_date) из ods.order_v
Номер, статус и items_total каждого заказа дня D	dds.order_v, отбор по order_date
Число заказов в каждом статусе и сумму items_total только у paid	те же заказы дня D
Выручку дня D	сумма revenue из dm.revenue_daily_v, отбор по report_date
Номера покупок, еще ожидающих заказ	строки awaiting_order из dm.purchase_vs_orders_v, отбор по order_day

Выручку складывайте по всем категориям. В этой витрине она означает стоимость позиций оплаченных заказов, без скидки и доставки, поэтому должна сходиться с суммой items_total у заказов в статусе paid.

Сохраняйте результаты запросов отдельными файлами, например выгрузками CSV из DBeaver. Подписывайте D и S. До поступления первого слепка список заказов пуст, а выручка равна нулю; сохраните и это наблюдение.

Публичное представление заказа показывает текущее состояние, а сырые слепки хранятся ограниченное время. Сохраненные выгрузки — история для расследования.

Продвигайте мир по одному дню

Для каждого следующего наблюдения:

1. Запустите world_next_day с days = 1 и дождитесь успеха.
2. Запустите etl_pipeline и дождитесь успеха: world_next_day сам витрины не обновляет.
3. Повторите свои запросы и сохраните новый комплект результатов с датой S.

Во всех запросах остается прежний день D. За один запуск проигрывайте один день, чтобы сохранить промежуточные состояния. Пакетный world_next_day отправляет события без пауз; ждать 24 минуты живого дня здесь не нужно.

Продолжайте до слепка D + 7 включительно. У заказов дня D окно состоит из семи дней, от D до D + 6. Последний шаг нужен для сравнения состояния в конце окна и за его пределами. От исходного наблюдения потребуется восемь однодневных запусков.

Объясните изменения отчета

После каждого шага сравнивайте заказы по order_id, а не по положению строк в выгрузке. Найдите:

• заказы, отсутствовавшие в первом слепке D, но появившиеся в следующем;
• переходы из created в paid;
• отмены заказов, для которых раньше был виден статус paid.

Первый слепок, полученный на следующий день, — обычная доставка заказов. Опоздавшими здесь считаются те, которых не было уже в этом слепке. Покажите на нескольких номерах, как они исчезают из awaiting_order.

Выберите два соседних наблюдения, между которыми хотя бы один заказ перешел из paid в cancelled. Разложите изменение выручки по заказам. Составьте таблицу: номер заказа, прежний и новый статусы, вклад в выручку до и после изменения. Вклад определите по правилу расчета витрины, указанному выше; учтите и заказы, которых еще не было в первом наблюдении. Сумма изменений вкладов должна совпасть с изменением revenue до копейки.

Для одного из этих отмененных заказов сравните изменение его вклада с изменением общей выручки между теми же наблюдениями. Совпало ли направление изменений? Найдите в своей таблице заказы, определившие общий итог.

Что известно об отменах

Возьмите отмененный заказ, у которого в вашей истории был статус paid. Укажите два наблюдения, доказывающих, что он был оплачен, а затем отменен.

Теперь возьмите отмененный заказ, для которого ни в одной вашей выгрузке нет paid. Проверьте утверждение «этот заказ никогда не был оплачен»: что известно о его состоянии между двумя слепками? Достаточно ли сохраненных наблюдений для такого вывода? Укажите, какие данные позволили бы его проверить.

Когда день закрыт

Сравните сохраненные состояния при S = D + 6 и S = D + 7: состав заказов, их статусы, суммы и выручку. Какой слепок последним мог изменить заказы дня D и каким прогоном он доставлен? Укажите наблюдение, после которого отчет можно считать окончательным. Было бы достаточно совпадения двух соседних сумм, если бы окно еще не закончилось?

После собственных выводов сверьтесь с описанием слепка и его доставки и границ истории отмен.

Что должно получиться

• сохранена последовательность наблюдений одного дня D с датами слепков S;
• найдены опоздавшие заказы и изменения статусов;
• изменение выручки между двумя наблюдениями объяснено вкладами заказов;
• оплата одной из последующих отмен подтверждена двумя наблюдениями;
• вы различаете доказанную оплату и отсутствие сведений о ней;
• состояние дня за пределами окна совпало с окончательным, а момент закрытия обоснован правилом доставки слепков.

После работы оставьте world_live на паузе либо верните автоматическое продвижение, если пользовались им до наблюдения.