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 установить место потери — до приема в хранилище или при обработке? Какие данные нужны, чтобы это выяснить?

Результат работы

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