diff --git a/docs/labs/optional/duplicate-purchases.md b/docs/labs/optional/duplicate-purchases.md index 38f860e..2e93d7f 100644 --- a/docs/labs/optional/duplicate-purchases.md +++ b/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`, проверьте diff --git a/docs/labs/optional/missing-purchases.md b/docs/labs/optional/missing-purchases.md index 75528d3..7e783f2 100644 --- a/docs/labs/optional/missing-purchases.md +++ b/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` перед первой +и повторной покупкой. Посчитайте, сколько повтор добавил просмотров +подтверждения и сколько — покупок. Изменилась ли от этих добавлений разность +счетчиков? Подтвердите ответ найденными строками. Второе равенство относится +к устройству этого стенда; для другого источника его нужно проверять заново. Если в выбранном дне повторов нет, возьмите другой закрытый день. -Для оценки доли потерь используйте число заказов магазина и объясните, -почему число просмотров подтверждения может дать другую долю. +Для оценки доли потерь используйте число заказов магазина. Затем посчитайте +долю с тем же числителем, но с числом просмотров подтверждения в знаменателе. +Совпали ли результаты? Свяжите различие знаменателей с найденными событиями. ## Сопоставьте вывод с готовой сверкой diff --git a/docs/labs/optional/order-amount-difference.md b/docs/labs/optional/order-amount-difference.md index 7a4973b..a728fd4 100644 --- a/docs/labs/optional/order-amount-difference.md +++ b/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). Если все цены +выбранной корзины целые, возьмите еще один заказ с расхождением и дробной ценой. В коротком объяснении назовите заказ, товар, количество, цену и разницу. -Отделите то, что подтверждают данные, от причины, которую по ним установить -нельзя: отсутствие позиции в заказе видно, а причину ее удаления источник -отдельным полем не сообщает. +Какие строки подтверждают найденное расхождение? Есть ли в источниках +сведения о том, почему оно возникло? Отделите наблюдения от предположений. ## Что должно получиться diff --git a/docs/labs/optional/revenue-over-time.md b/docs/labs/optional/revenue-over-time.md index a11d017..5fef588 100644 --- a/docs/labs/optional/revenue-over-time.md +++ b/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#слепок-и-его-доставка)