Conceptual architecture · implementation details pending
Offline data and modelling boundary
Transaction data → RFM features → K-Means segments
Interaction data → collaborative filtering
Compatible model → SHAP explanations (target unverified)
Application boundary
Model outputs → FastAPI → Streamlit dashboard
User input → API validation → model request
Proposed evaluation boundary
Held-out data → baseline and ranking evaluation
Segments + explanations → separate quality review
- Security controls
- Proposed controls: exclude direct identifiers from public datasets, validate API input, and restrict access if customer data is used. Authentication and deployment controls are unverified.
- Failure handling
- Proposed handling: reject invalid input; surface missing model/API failures; return an explicit no-result state for unknown users.
Conceptual overview. Boundaries and arrows describe the intended flow; they do not establish a production deployment.
Evidence you can inspect
Repository, report and demo evidence have not yet been supplied for public review. The text distinguishes confirmed scope from proposed design and evaluation.
Problem and constraints
This MSc project explored how to combine customer segmentation with recommendations and explanations that a user can inspect. Recommendation quality and interpretability need separate evaluation. The final dataset source, split and report are awaiting verification, so this case study does not publish performance or commercial-impact figures.
My personal contribution
I explored RFM, K-Means, collaborative filtering and SHAP, with FastAPI and a Streamlit dashboard, as part of my MSc project. These are the confirmed project components. The repository, final evaluation artefacts and exact component-level implementation details are still to be supplied.
Architecture and data flow
The diagram is a conceptual reconstruction from the confirmed component list, not a verified implementation diagram. Transaction data supports RFM features and customer segmentation; interaction data supports collaborative recommendations. FastAPI and Streamlit provide application interfaces. The final report must establish the exact model explained by SHAP and how those explanations connect to recommendations.
Alternatives and trade-offs
Retrospective design analysis: a popularity-based recommender is a useful simple baseline but provides less personalisation. Collaborative filtering can exploit interaction patterns but needs a cold-start strategy. K-Means offers a compact segmentation approach but depends on feature scaling and the choice of cluster count. SHAP can aid inspection of a compatible predictive model, but its outputs should not be presented as causal explanations.
Evaluation and failure handling
Proposed evaluation: establish data provenance, prevent train/test leakage and compare ranking quality with a popularity baseline. Assess cluster quality separately from recommendation quality and test whether explanations help users interpret outputs. Proposed application behaviour: reject malformed inputs, return an explicit no-result state for unknown users and show a clear error if model or API execution fails. These checks are not claimed as completed tests.
Outcome and evidence limits
The project scope brings segmentation, recommendation methods, explanation techniques and an API/dashboard interface together. Runtime behaviour and final results have not been independently verified for this portfolio. The previously discussed silhouette score and conversion increase are intentionally omitted. No public repository or demo is linked until the correct artefact is confirmed.
What I would improve next
I would publish a reproducible README, a small redistributable sample dataset, split definitions, baseline comparisons and API tests. A short recorded walkthrough should show both a successful request and a failure state. The relationship between this project and the separately described space-data dissertation also needs confirmation before making a dissertation claim.