e_commerce_project

Проект был реализован в рамках курса Дата Аналитик на платформе karpov.courses. 63/70 баллов

Проект e-commerce

Продакт-менеджер Василий попросил вас проанализировать совершенные покупки и ответить на следующие вопросы:

1. Сколько у нас пользователей, которые совершили покупку только один раз? (7 баллов)

2. Сколько заказов в месяц в среднем не доставляется по разным причинам (вывести детализацию по причинам)? (10 баллов)

3. По каждому товару определить, в какой день недели товар чаще всего покупается. (7 баллов)

4. Сколько у каждого из пользователей в среднем покупок в неделю (по месяцам)? Не стоит забывать, что внутри месяца может быть не целое количество недель. Например, в ноябре 2021 года 4,28 недели. И внутри метрики это нужно учесть. (8 баллов)

5. Используя pandas, проведи когортный анализ пользователей. В период с января по декабрь выяви когорту с самым высоким retention на 3й месяц. Описание подхода можно найти тут. (15 баллов)

6. Часто для качественного анализа аудитории использую подходы, основанные на сегментации. Используя python, построй RFM-сегментацию пользователей, чтобы качественно оценить свою аудиторию. В кластеризации можешь выбрать следующие метрики: R - время от последней покупки пользователя до текущей даты, F - суммарное количество покупок у пользователя за всё время, M - сумма покупок за всё время. Подробно опиши, как ты создавал кластеры. Для каждого RFM-сегмента построй границы метрик recency, frequency и monetary для интерпретации этих кластеров. Пример такого описания: RFM-сегмент 132 (recency=1, frequency=3, monetary=2) имеет границы метрик recency от 130 до 500 дней, frequency от 2 до 5 заказов в неделю, monetary от 1780 до 3560 рублей в неделю. Описание подхода можно найти тут. (23 балла)

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

Ревью:

В целом, довольно неплохая работа. Очень радуют попытки делать в каждом задании больше того, что требуется. Но не хватает учёта бизнес-логики в решениях.

Задание 1. 7/7

Задание 2. 6/10 Не доставленными вы считаете все заказы, которые не имеют соответствующего статуса, считая это проблемой, это некорректно. Есть заказы, у которых ещё не завершён жизненный цикл. В нормальном e-com они есть всегда, не бывает момента времени, когда все заказы доставлены и нет заказов в других статусах. Недоставленные заказы могут быть доставлены в дальнейшем, кроме двух статусов. Именно эти статусы нужно было рассматривать. Если предполагать именно проблемные ситуации в других статусах, тогда нужно было на основе анализа дат отсекать те, которые действительно могут их иметь.

Задание 3. 4/7 Используем дату подтверждения оплаты заказа (order_approved_at), т.к. именно тогда происходит покупка - подтверждение оплаты выполняется менеджером в компании, и это может происходить в день, отличный от дня, когда покупатель произвёл заказ. Причём необязательно это может происходить даже на следующий день (если менеджер, к примеру, не дозвонился до покупателя). Вам нужно определить популярность товара по дню недели, эта характеристика должна быть завязана исключительно на действии клиента. Кроме того, в расчёте вы не учитываете, что разные товары могут быть одинаково популярны в разные дни и для таких товаров хорошо бы вывести все эти дни.

Задание 4. 8/8 Аналогичная ошибка, как и в предыдущем задании относительно даты, здесь не буду снижать балл.

Задание 5. 12/15 • Снова пропускаю ошибку про дату покупки. • Отбираем покупки по статусу заказа и по дате (т.к. в условии задан период с января по декабрь, в наших данных полный год только 2017, его и берем) - по заданию вам нужно рассчитать retention на 3-й месяц, соответственно для когорт ноября-декабря 3-го месяца в таком случае у вас существовать не будет. Нужно было фильтровать по дате только когорты. • В задании указано, что нужно провести когортный анализ. Вы построили таблицу, но не дали к ней никаких комментариев, т.е. как таковой анализ не проведён.

Задание 6. 23/23 • Снова пропускаю ошибку про дату покупки. • В остальном замечаний нет. Правильно, что решено делать ручную сегментацию, а не по квантилям. Понятно, на чём она основана, и есть аналитика сформированных сегментов.

По критериям доп. баллов - готов добавить 3 балла из 5: • есть дополнительные расчёты и аналитику в каждом задании и наличие предварительного анализа (хотя его следовало делать глубже). • по части оформления все описания написаны в формате комментариев к коду через #, markdown отсутствует. Таким образом не разделяется описание манипуляций с данными и сами выводы; • местами есть избыточный вывод данных, когда output'ы или графики не сопровождаются комментариями. Итого: 60/70 + 3 балла = 63. Проект сдан.

Файлы:

• olist_customers_datase.csv — таблица с уникальными идентификаторами пользователей

customer_id — позаказный идентификатор пользователя

customer_unique_id — уникальный идентификатор пользователя (аналог номера паспорта)

customer_zip_code_prefix — почтовый индекс пользователя

customer_city — город доставки пользователя

customer_state — штат доставки пользователя

• olist_orders_dataset.csv — таблица заказов

order_id — уникальный идентификатор заказа (номер чека)

customer_id — позаказный идентификатор пользователя

order_status — статус заказа

order_purchase_timestamp — время создания заказа

order_approved_at — время подтверждения оплаты заказа

order_delivered_carrier_date — время передачи заказа в логистическую службу

order_delivered_customer_date — время доставки заказа

order_estimated_delivery_date — обещанная дата доставки

• olist_order_items_dataset.csv — товарные позиции, входящие в заказы

order_id — уникальный идентификатор заказа (номер чека)

order_item_id — идентификатор товара внутри одного заказа

product_id — ид товара (аналог штрихкода)

seller_id — ид производителя товара

shipping_limit_date — максимальная дата доставки продавцом для передачи заказа партнеру по логистике

price — цена за единицу товара

freight_value — вес товара