E-Commerce Lakehouse Purchase Prediction

Projektüberblick

Dieses Projekt zeigt einen vollständigen Lakehouse-Workflow für E-Commerce-Verhaltensanalyse und sessionbasierte Purchase Prediction. Rohdaten im Clickstream-Stil werden in AWS S3 gespeichert, mit Amazon Athena abgefragt und transformiert, als Parquet materialisiert und anschließend in Databricks für PySpark-basierte Analyse, Feature Engineering, Train/Test-Vorbereitung und Machine Learning genutzt.

Das Projekt wurde als professionelles Portfolio-Projekt für Data-Engineering- und Cloud-Data-Engineering-Rollen konzipiert. Es kombiniert Cloud Data Lake Design, SQL-basierte Transformation, Spark Processing, Machine Learning, Dokumentation und kostenbewusste Architekturentscheidungen.

Zielsetzung

Das Hauptziel ist vorherzusagen, ob eine User Session in einem Kauf endet. Grundlage sind Verhaltenssignale wie Views, Cart-Aktivität, Session-Dauer, Produktdiversität, Preisstatistiken und weitere engineered Session Features.

Zentrales Engineering-Ziel: Aufbau einer reproduzierbaren End-to-End-Pipeline von rohen E-Commerce-Events bis zu einem ML-ready Curated Dataset und evaluierten Purchase-Prediction-Modellen.

Architektur

Das Projekt trennt den Workflow in Raw-, Processed-, Curated- und Machine-Learning-Layer. AWS stellt Storage, serverless SQL und Catalog-Grundlage bereit. Databricks stellt die PySpark- und ML-Umgebung für EDA, Feature Engineering und Modellevaluation bereit.

Raw CSV Events in S3 gespeichert.

Athena External Table und SQL Views für Cleaning, Validation und Transformation.

Processed und Curated Layer als Parquet-Dateien materialisiert.

Databricks/PySpark für EDA, ML Feature Engineering, Train/Test Split und Spark ML Modelle.

Pipeline Flow

Raw E-Commerce Event Data nach Amazon S3 hochladen.
Athena External Table über den rohen CSV-Daten erstellen.
Data Quality prüfen und Clean/Processed Athena Views erstellen.
Events zu sessionbasierten Behavioral Features aggregieren.
Processed und Curated Datasets als Parquet in S3 materialisieren.
Curated ML-ready Dataset in Databricks importieren.
PySpark EDA, Funnel Analysis, Feature Engineering und Train/Test Split durchführen.
Baseline- und Leakage-aware-Logistic-Regression-Modelle trainieren.
Modelle mit ROC-AUC, Accuracy, Precision, Recall, F1 und Confusion Matrices evaluieren.

Datensatz und Data Quality

Die Quelldaten enthalten E-Commerce-Event Records mit Zeitstempeln, Event Types, Produkt-IDs, Kategorie- und Brand-Metadaten, Preis, User ID und User Session ID. Gültige Event Types sind view, cart und purchase.

Die Data-Quality-Schritte umfassten Trimming von Strings, Entfernung ungültiger Zeilen, Standardisierung fehlender Produktmetadaten, Timestamp-Konvertierung, Erstellung von Purchase-Indikatoren auf Event-Ebene und Filterung unrealistischer Sessions länger als 24 Stunden vor dem Modeling.

884K+

Processed e-commerce events

480K+

ML-ready user sessions

4.71%

Purchase rate

Metric	Value	Interpretation
Processed Events	884.964	Bereinigte Event-Level Records nach Validierung und Session-Filterung.
ML-ready Sessions	480.036	Finaler One-row-per-session-Datensatz für das Modeling.
Purchased Sessions	22.601	Sessions mit mindestens einem Purchase Event.
Non-purchased Sessions	457.435	Sessions ohne Purchase Event.
Purchase Rate	4,71%	Anteil der positiven Klasse im ML-ready Dataset.

Explorative Analyse und Funnel Insights

Die Funnel Analysis zeigte eine starke verhaltensbezogene Entwicklung von Product Views zu Cart-Aktivität und Käufen. Cart-Aktivität war das stärkste direkte Kaufsignal, während Session Engagement und Dauer ebenfalls relevante Informationen lieferten.

Funnel Metric	Value
Total Sessions	480.036
Sessions mit View	478.004
Sessions mit Cart	38.544
Sessions mit Purchase	22.601
View Rate	99,58%
Cart Rate	8,03%
Purchase Rate	4,71%

Sessions mit Cart-Aktivität hatten eine Purchase Rate von 49,62%.
Sessions ohne Cart-Aktivität hatten nur eine Purchase Rate von 0,79%.
Purchase Sessions hatten mehr Events, längere Dauer und höhere Produktdiversität.
Preisbezogene Features waren weniger einflussreich als verhaltensbezogene Features.

Feature Engineering

Mit PySpark wurden sessionbasierte Features entwickelt, um Verhaltensintensität, Produktdiversität, Preisexposition, Cart/View Ratios, binäre Aktivitätsflags, logarithmierte numerische Variablen und gebuckettete Duration-/Price-Features abzubilden.

Feature Group	Examples
Behavioral Counts	total_events, view_events, cart_events, purchase_events
Session Timing	session_start_ts, session_end_ts, session_duration_seconds, log_session_duration
Diversität	distinct_products, distinct_categories, distinct_brands
Preisstatistiken	min_price, max_price, avg_price, log_avg_price, log_max_price
Ratios und Flags	cart_event_ratio, view_event_ratio, cart_to_view_ratio, has_cart, has_multiple_events
Buckets	duration_bucket_id, price_bucket_id

Machine-Learning-Modelle

Zwei Logistic-Regression-Modelle wurden trainiert, um sowohl einen leistungsstarken retrospektiven Klassifikator als auch eine defensiblere leakage-aware Evaluation zu zeigen.

Baseline Full-Session Model

Nutzt Full-Session Behavioral Features inklusive Cart-bezogener Signale. Dieses Modell performt sehr stark, sollte aber als retrospektiver Session Classifier interpretiert werden.

Leakage-Aware Model

Entfernt direkte Cart-bezogene und Full-Session-Aggregat-Features wie cart_events, has_cart, cart_event_ratio, cart_to_view_ratio und total_events, um eine realistischere Evaluation zu ermöglichen.

Model	ROC-AUC	Accuracy	Precision	Recall	F1
Baseline Full-Session LR	0.9995	0.9963	0.9896	0.9315	0.9597
Leakage-Aware LR	0.9973	0.9872	0.9312	0.7868	0.8530

Business Interpretation

Die Ergebnisse zeigen, dass User Behavior sehr prädiktiv für Session Purchase Outcomes ist. Cart-Aktivität ist das stärkste direkte Signal. Selbst nach Entfernen direkter Cart-Features bleiben Session-Dauer, Engagement und Produktdiversität starke Prädiktoren.

Cart-Aktivität ist der klarste Behavioral Indicator für Kaufintention.
Längere und aktivere Sessions konvertieren häufiger.
Produktdiversität hilft, Purchase Sessions von Non-Purchase Sessions zu unterscheiden.
Eine leakage-aware Evaluation ist wichtig, wenn man von retrospektiver Analyse in Richtung früherer Vorhersage geht.

Cloud- und kostenbewusstes Design

Das Projekt wurde bewusst ohne Always-on-Infrastruktur konzipiert. AWS S3 und Athena wurden für günstigen Storage und serverless SQL genutzt, während Databricks nur für interaktive PySpark-Analyse und ML-Arbeit verwendet wurde.

Kein dauerhaft laufender EC2- oder EMR-Cluster war erforderlich.
Kein Redshift Cluster oder Always-on Warehouse wurde genutzt.
Athena CTAS wurde verwendet, um effiziente Parquet Layer zu erzeugen.
Der finale Workflow dokumentiert eine praktische Databricks-Serverless-Limitierung: Direkter S3-Zugriff war eingeschränkt, daher wurde das Curated Dataset in Databricks importiert.

Ausgewählte Projektnachweise

Die folgenden Screenshots werden angezeigt, wenn die entsprechenden Bilddateien im Assets-Ordner der Website hochgeladen wurden.

AWS-S3-Lakehouse-Struktur mit raw-, processed-, curated- und Athena-Ergebnis-Layer.

Curated ML-ready Parquet-Output, materialisiert in Amazon S3.

Databricks/PySpark-Validierung des sessionbasierten ML-Datensatzes.

Funnel-Analyse von Product Views über Cart-Aktivität bis zum Kauf.

Vergleich des Baseline- und Leakage-aware-Logistic-Regression-Modells.

Limitationen und Future Work

Die aktuellen Modelle basieren auf Full-Session-Aggregaten und eignen sich eher für retrospektive Session Classification als für Echtzeitvorhersage.
Future Work sollte Features nur aus Pre-Purchase- oder Early-Session-Events bauen.
MLflow könnte für Experiment Tracking und Model Registry ergänzt werden.
AWS Glue, Step Functions oder Databricks Workflows könnten die Pipeline automatisieren.
Ein Dashboard in Power BI oder QuickSight könnte Funnel- und Modellergebnisse für Business-Nutzer kommunizieren.

Outcome

Dieses Projekt hat meine praktische Erfahrung mit Cloud Data Lake Design, Athena SQL, Parquet-Materialisierung, Databricks, PySpark, Feature Engineering und Spark-ML-Modellevaluation gestärkt.

Es ist eines meiner stärksten Portfolio-Projekte für Data-Engineering- und Cloud-Data-Engineering-Bewerbungen, weil es sowohl Infrastrukturdenken als auch praktische Machine-Learning-Workflow-Kompetenz zeigt.