clickstream-data-platform/docs/labs/optional/missing-purchases.md

Куда пропали покупки

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

Факультатив доступен после ступени 1. В DBeaver подключитесь пользователем analyst по инструкции. Дождитесь завершения etl_pipeline; на время расследования оставьте world_live на паузе и дождитесь уже начатых прогонов.

Выберите день

Можно ли построить полную витрину заказов по событиям purchase? Проверьте это на одном дне: сначала сопоставьте события сайта, затем сверьте номера заказов с выгрузкой магазина.

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

SELECT max(snapshot_date) - 6 AS last_closed_day
FROM ods.order_v;

Используйте выбранный день во всех запросах. События отбирайте по dds.event_v.event_date, заказы — по dds.order_v.order_date. Сравнивайте все заказы дня, включая отмененные: сейчас вопрос в том, зарегистрировал ли магазин заказ, а не в том, был ли он оплачен.

Найдите разрыв в событиях

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

Посчитайте просмотры страницы подтверждения и события покупки:

• у просмотра event_type = 'pageview', а url заканчивается на /confirmation;
• у покупки event_type = 'purchase'.

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

Сверьте с магазином

В событии номер заказа находится в purchase_id[1], в заказах — в order_id. Соберите список заказов выбранного дня, для которых нет события покупки. Несколько событий с одним номером заказа должны оставаться одной покупкой. Сохраните запрос сверки: на каждый такой заказ он должен возвращать дату, номер и статус. Дату задавайте в одном месте, чтобы запрос можно было повторить для другого дня.

Проверьте два равенства:

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

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

Найдите номер заказа с несколькими событиями purchase. Для его client_id выведите события рядом с этими покупками по времени: event_time, event_type и url. Найдите просмотры /confirmation перед первой и повторной покупкой. Посчитайте, сколько повтор добавил просмотров подтверждения и сколько — покупок. Изменилась ли от этих добавлений разность счетчиков? Подтвердите ответ найденными строками. Второе равенство относится к устройству этого стенда; для другого источника его нужно проверять заново.

Если в выбранном дне повторов нет, возьмите другой закрытый день.

Сопоставьте вывод с готовой сверкой

Найдите свои заказы без события в dm.purchase_vs_orders_v по order_id. Сравните их status и mismatch_class. Витрина присваивает заказу один класс, хотя причин расхождения может быть несколько. По правилу классификации объясните, почему потеря события не всегда попадает в lost_event.

Возьмите один заказ из своего списка и сохраните два запроса: первый находит его в магазине, второй показывает отсутствие покупки в трекере.

Выберите источник и условие проверки

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

Рядом с запросом запишите, когда его результат можно считать окончательным. Что изменится, если запустить его до получения всех слепков выбранного дня? Позволяет ли отсутствие события в dds.event_v установить место потери — до приема в хранилище или при обработке? Какие данные нужны, чтобы это выяснить?

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

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