E-kereskedelmi vásárlói szegmentáció és churn-elemzés

Magyar | English

---

Adathalmaz • Eredmények • Elemzési lépések • Dashboard • Setup • Architektúra • Mappastruktúra • GYIK • Kapcsolat

🛒End-to-end data product interaktív dashboarddal.

🌐 Látogasd meg a portfóliómat (külső weboldal)

Adathalmaz

Az elemzés alapja egy Kaggle-ről (eredeti: UCI Machine Learning Repository) származó valódi, ~1 millió soros tranzakciós adathalmaz 2009 és 2011 közti, Egyesült Királyságban működő kereskedő tranzakcióival.

Az adathalmazban B2B és B2C ügyfelek vegyesen szerepelnek. Ez különösen indokolja az RFM-alapú szegmentációs megközelítést, ahol a visszatérő vásárlók azonosítása és a churn előrejelzése üzletileg kritikus..

Eredmények

Adattisztítás

Az 1 067 371 nyers sorból 6 lépéses pipeline után 793 900 sor maradt elemzésre kész állapotban (az eredeti adathalmaz 74,4%-a):

Szűrési lépés	Eldobott sorok
Anonim tranzakciók (hiányzó Customer ID)	−243 007
Érvénytelen ár (≤ 0)	−71
Adminisztratív kódok (BANK CHARGES, C2, stb.)	−3 709
Fejlesztői tesztkódok	−14
Duplikátumok	−26 402
Technikai outlierek (>10 000 db-os tételek)	~−268
Elemzésre kész sorok	793 900

A visszáru/sztornó sorok (C prefix az Invoice oszlopban) szándékosan megmaradtak – return_ratio feature-ként épültek be a modellbe.

---

Ügyfélszegmentáció (K-means, K=4)

Bár matematikailag 2 klaszter lett volna indokolt, üzletileg a 4 jobban szegmentálja a vásárlókat és meg tudtam indokolni mint másodlagos optimum (lásd 02-es notebook).

5 243 ügyfelet sorolt 4 szegmensbe a modell:

Szegmens	Ügyfelek	Átl. vásárlások	Átl. bevétel / fő	Utolsó vásárlás	Return ratio
🏆 VIP Bajnokok	861 (16%)	19,5 alkalom	£10 391	30 napja	~15,9%
💤 Lemorzsolódó / Alvó	1 624 (31%)	5,1 alkalom	£1 888	195 napja	~14,3%
👻 Elvesztett / Inaktív	2 098 (40%)	1,4 alkalom	£330	340 napja	~8,0%
🌱 Új / Ígéretes	660 (13%)	2,8 alkalom	£758	30 napja	~8,8%

A VIP szegmens az ügyfelek 16%-a, de fejenként ~31-szeresét költi az Elvesztett szegmenshez képest. A legmagasabb visszaküldési aránnyal (~15,9%) szintén a VIP-ek rendelkeznek – ez tipikus B2B viselkedés, nem lemorzsolódási jel, amit a SHAP-elemzés is megerősít.

ℹ️ A szegmensenkénti teljes bevételarány a dashboard aggregált nézetében olvasható.

---

Churn-előrejelzés (XGBoost + A/B pipeline)

Az ügyfelek 55,7%-a lemorzsolódott a 2011-09-09-es cutoff után – az osztályok közel kiegyensúlyozottak, de a PR-AUC így is informatívabb, mint az Accuracy vagy ROC-AUC.

A/B modellválasztás – 5-fold CV (X_train-en):

Pipeline	PR-AUC	F1	Recall
A – Csak RFM (5 feature)	0,8098	0,740	0,734
B – RFM + K-Means OHE (9 feature)	0,8098	0,743	0,738

A két pipeline CV PR-AUC-ja negyedik tizedesjegyig azonos – a klasztercímkék nem adnak hozzá prediktív erőt. Az A pipeline a nyertes: nemcsak egyszerűbb, hanem stabilabb is, a B pipeline PR-AUC szórása fold-ok között lényegesen nagyobb, ami élesben kiszámíthatatlanabb teljesítményt jelent.

RandomizedSearchCV hangolás után (100 iteráció, X_train-en): CV PR-AUC → 0,8121, holdout teszt PR-AUC → 0,8253, overfitting rés → 0,0017 (hangolás előtt: 0,0504).

Teljesítményértékelés:

A pipeline két PR-AUC értéket produkál, amelyek különböző célokat szolgálnak:

	PR-AUC	Mire vonatkozik
Fejlesztési modell (X_train-en tanult)	0,8253	Konzervatív holdout becslés – a modell valódi általánosítási képessége
Produkciós modell (teljes X+y-on retanítva)	0,8322	Visszaellenőrzési szám – a végleges exportált modellé

Az iparági best practice szerint a hiperparaméterek és az architektúra validálása után a produkciós modell a teljes adathalmazon kerül betanításra a maximális prediktív erő érdekében. A konzervatív holdout becslés (0,8253) az érvényes generalizációs metrika; a 0,8322 a retanított modell visszaellenőrzési értéke.

Produkciós modell metrikái (threshold-optimalizálás a holdout szetten):

Metrika	Érték
F1-score (opt. threshold)	0,785
Recall	0,856
Precision	0,724
Brier-score	0,1824
Optimális küszöb	0,419 (F1-maximalizáló, nem hardcoded 0,5)

Threshold trade-off: a 0,5 → 0,419 váltás csökkenti az elszalasztott churnöket (FN: 149 → 84), de növeli a téves riasztásokat (FP: 111 → 191) – churn-megelőzési kontextusban szándékos döntés.

Kalibráció: a Brier-score elfogadható, de a reliability diagram jelzi, hogy 0,6 feletti becsléseknél a modell alábecsüli a tényleges churn-arányt (0,60-os becslésnél ~78%, 0,75-ösnél ~90% a tényleges arány). A szürke zónában (0,30–0,70) elhelyezkedő ügyfelekre érdemes kiegészítő üzleti szabályokat alkalmazni.

Feature fontosság – SHAP és XGBoost Gain Spearman ρ = 0,900 egyezéssel:

Feature	SHAP-fontosság
recency_days	~55,7%
frequency	~20,8%
monetary_total	~19,2%
return_ratio, monetary_avg	~4,3%

ℹ️ Baseline: PR-AUC véletlen alapvonal ~0,557 (osztályarány); a fejlesztési modell (0,8253) közel 1,48×-es javulást jelent.

Elemzési lépések

A dokumentációnak ez a része automatikusan frissül új notebookok és új H2 headerek hozzáadásakor az update_docs.py segítségével! Ennek feltétele, hogy a fejléc a ## {szám}. {cím} formátumot kövesse (pl. ## 14. Export – Előrejelzések mentése) — csak az így strukturált fejlécek kerülnek be a táblázatba és lesznek kattinthatók GitHub-on.

#	Lépés	Notebook	Lefutott eredmények megtekintése (ugrás adott részhez)
0	Adatbetöltés és Parquet-konverzió	01_data_preparation.ipynb	📊 Megtekintés
1	Adattisztítás	01_data_preparation.ipynb	📊 Megtekintés
2	Feature Engineering és az adatszivárgás megelőzése	02_customer_segmentation.ipynb	📊 Megtekintés
3	Statisztikai Outlier-kezelés és skálázás	02_customer_segmentation.ipynb	📊 Megtekintés
4	K-means Klaszterezés	02_customer_segmentation.ipynb	📊 Megtekintés
5	Kiterjesztett EDA	02_customer_segmentation.ipynb	📊 Megtekintés
6	Adatbetöltés, Time-Split és Célváltozó (Churn) kialakítása	03_churn_prediction.ipynb	📊 Megtekintés
7	A/B Modellezés: Pipeline-ok felépítése	03_churn_prediction.ipynb	📊 Megtekintés
8	Keresztvalidáció és modellek összehasonlítása	03_churn_prediction.ipynb	📊 Megtekintés
9	Végleges modell exportja	03_churn_prediction.ipynb	📊 Megtekintés
10	Modell betöltése és adatok előkészítése	04_model_evaluation.ipynb	📊 Megtekintés
11	Modell kiértékelése	04_model_evaluation.ipynb	📊 Megtekintés
12	Modell magyarázata, SHAP elemzés	04_model_evaluation.ipynb	📊 Megtekintés
13	Üzleti kiértékelés és akciótervek	04_model_evaluation.ipynb	📊 Megtekintés
14	Export, előrejelzések mentése	04_model_evaluation.ipynb	📊 Megtekintés

Dashboard

Az alábbi animáció a vásárlási tranzakciók időbeli dinamikáját és a projekt interaktív felületét mutatja be.

Lokális futtatás és környezet beállítása (Setup)

💡 Megjegyzés: A projekt alapértelmezett bemeneti/kimeneti fájlútvonalait és a főbb paramétereket (pl. CUTOFF_DATE) a config.py fájl tartalmazza. Az útvonalakat itt lehet módosítani eltérő mappastruktúra használatához.

A projekt futtatásához javasolt egy izolált virtuális környezet (pl. Conda) használata:

1. Klónozd a repót és navigálj a mappába:

git clone https://github.com/csabatatrai/ecommerce-customer-segmentation
cd ecommerce-customer-segmentation

2. Hozz létre egy új környezetet:

conda create --name ecommerce_env python=3.10
conda activate ecommerce_env

3. Telepítsd a függőségeket:

pip install -r requirements.txt

4. A nyers adathalmazt a 01_data_preparation.ipynb notebook automatikusan letölti, de beszerezhető innen is: online-retail-II letöltése . A data/raw/ mappában lesz megtalálható az első notebook futtatása után!

5. Indítsd el a Jupytert:

jupyter notebook

6. Futtasd a notebookokat sorrendben:

   • 01_data_preparation.ipynb – Adatelőkészítés: Data Preparation (Adattisztítás és Parquet Pipeline)
   • 02_customer_segmentation.ipynb – Ügyfélszegmentáció: Customer Segmentation (RFM Elemzés és K-means)
   • 03_churn_prediction.ipynb – Prediktív Modellezés: Churn Prediction (XGBoost Klasszifikáció)
   • 04_model_evaluation.ipynb – Modell Kiértékelés: Kalibráció, SHAP, Threshold & üzleti akciótervek

7. A Streamlit dashboardok lokális megnyitásához navigálj terminállal a gyökérkönyvtárba, és használd a streamlit run app.py parancsot!

---

Mappastruktúra

A notebookok futtatásakor a kód automatikusan létrehozza a teljes szükséges mappastruktúrát.

ecommerce-customer-segmentation/
│
├── LICENSE                           # MIT – szabadon tanulmányozható és futtatható
├── config.py                         # közös útvonal-konstansok és pipeline paraméterek
├── requirements.txt
├── .gitignore
│
├── data/                             # 🚨 notebook hozza létre config.py segítségével
│   ├── raw/                          # 🚨 notebook hozza létre, ide tölti le a nyers datasetet
│   └── processed/                    # 💾 notebook hozza létre, tisztított, parquet fájlok
│
├── sql/
│   └── eda_exploratory_analysis.sql  # SQL szkriptek
│
├── 01_data_preparation.ipynb         # adattisztítás
├── 02_customer_segmentation.ipynb    # RFM feature engineering és K-means klaszterezés
├── 03_churn_prediction.ipynb         # XGBoost churn predikció – modellépítés, holdout split, export
├── 04_model_evaluation.ipynb         # kalibráció, SHAP, threshold optimalizálás, üzleti akciólista
│
├── models/                           # 🚨notebook hozza létre, szerializált modell- és transzformátor-objektumok (joblib)
│
├── app.py                            # Streamlit dashboard főfájl
├── pages/                            # Streamlitnek további dashboardok
│
├── docs/                             # 🟢 Lefuttatott notebookok markdownban
│   ├── images/
│   │   ├── 01_data_preparation/
│   │   ├── 02_customer_segmentation/
│   │   ├── 03_churn_prediction/
│   │   └── 04_model_evaluation/
│   ├── 01_data_preparation.md
│   ├── 02_customer_segmentation.md
│   ├── 03_churn_prediction.md
│   └── 04_model_evaluation.md
│
└── update_docs.py                    # 💡 dokumentáció-automatizáló szkript (részben dokumentálja magát a kód)

Architektúra

flowchart TD
    CSV[("📂 online_retail_II.csv\nKaggle / UCI · ~1M sor")]
    SQL["🔍 SQL EDA\nSQLite / DB Browser"]
    CFG(["⚙️ config.py\nÚtvonalak · paraméterek"])

    SQL -.->|feltárás| CSV
    CFG -.-> PREP
    CFG -.-> SEG
    CFG -.-> CHURN
    CFG -.-> EVAL
    CSV --> PREP

    PREP["📋 01 Adatelőkészítés\nParquet konverzió · tisztítás · outlier szűrés"]
    SEG["🎯 02 Ügyfélszegmentáció\nRFM Feature Engineering · K-means K=4"]
    CHURN["🤖 03 Churn Prediction\nXGBoost · Holdout split · A/B pipeline"]
    EVAL["🔍 04 Modell Kiértékelés\nKalibráció · SHAP · Threshold · Akciólista"]
    DASH["📊 Streamlit Dashboard"]

    PREP --> SEG --> CHURN --> EVAL --> DASH

    PREP -.->|kimenet| P1[("💾 Parquet fájlok\nraw · cleaned · rfm_ready")]
    SEG  -.->|kimenet| M1[("🧩 Modellek × 2\nscaler · kmeans_rfm .joblib")]
    CHURN-.->|kimenet| P2[("🤖 Modell + teszt szett\nxgboost.joblib · test_set.parquet")]
    EVAL -.->|kimenet| P3[("📈 Előrejelzések\nchurn_predictions.parquet")]

Loading

GYIK

💡 Hogyan használtam AI-eszközöket a projekt során?

Kifejezett célja volt a projektnek tesztelni, hogy az LLM-ek nyújtotta lehetőségek által magasabb absztrakciós szinten dolgozva milyen összetettségű data product elkészítése lehetséges viszonylag rövid idő alatt egyedül. A projekt tervezési döntései, az elemzési logika és a pipeline-architektúra saját munkám. AI-eszközöket (főként Claude) a következőkre használtam: kódgenerálás, dokumentáció és kommentek megfogalmazása, hibakeresés iteratív módszerrel, visszajelzések kérése. A modellek kiválasztása és az üzleti értelmezés emberi döntés maradt.

---

💡 Milyen módszerrel történt az adatfeltárás (EDA)?

Az elsődleges adatfeltárás (EDA) ebben a projektben SQLite-ban történt (DB Browser for SQLite), nem közvetlenül Pandasban. A futtatott lekérdezések megtalálhatók a sql/eda_exploratory_analysis.sql fájlban; az itt szerzett felismerések épültek be a Python pipeline tisztítási és szegmentációs logikájába.

---

💡 Miért Parquet fájlokban van a kimenet?

A Parquet fájlok legnagyobb előnye az oszlopos tárolási formátum, gyorsabb I/O, típusbiztos séma, kisebb méret.

---

💡 Hogyan biztosítja a projekt a notebookok tiszta verziókövetését?

A projekt az nbstripout eszközt használja Git pre-commit hook formájában. Ez automatikusan megtisztítja a notebookok (.ipynb) JSON struktúráját a futtatási kimenetektől (output cellák) és a metaadatoktól, megelőzve a repo indokolatlan méretnövekedését és a felesleges merge konfliktusokat.

Használat: A fejlesztői környezetben a terminálból kiadott nbstripout --install paranccsal konfigurálható a lokális hook.

---

💡 Ajánlott Visual Studio Code bővítmény

Better Comments: A forráskódban tudatosan használok színkódolt kommenteket a fontos megjegyzések, összefüggések és kiemelések jelölésére, így a bővítmény használatával átláthatóbbá válik a kód logikája.

---

Kapcsolat

Ha kérdésed van a projekttel kapcsolatban, vagy szívesen beszélgetnél hasonló témákról, keress bátran az alábbi elérhetőségeken:

• Weboldal: csabatatrai.hu
• LinkedIn: linkedin.com/in/csabatatrai-datascientist
• E-mail: tatraicsababprof@gmail.com

---

© 2026 Tátrai Csaba Attila · MIT licensz