E-Commerce Finance Analytics: XGBoost Revenue Forecasting and Random Forest Churn Prediction
TL;DR: A complete e-commerce financial operations analytics pipeline: synthetic relational data generation (inspired by the Olist Brazilian e-commerce dataset), XGBoost-based 30-day revenue forecasting with lag and rolling-mean features, and Random Forest churn prediction built on RFM (Recency, Frequency, Monetary) customer features. Single-command pipeline, Docker support, all code open on GitHub.
1. The problem: forecast revenue, keep customers
Two questions dominate e-commerce finance operations: what revenue is coming next month? and which customers are about to leave? Answering both from the same transactional data requires the same foundation — clean relational tables — but different modeling strategies: a time-series regression for revenue, and a classification model for churn. This project implements both, end to end, on a realistic multi-table dataset.
The business stakes are straightforward. Revenue forecasts drive inventory purchasing, staffing, and cash-flow planning; a forecast that's systematically off by 10% is a planning disaster. Churn is the silent killer of e-commerce: acquiring a new customer costs multiples of retaining one, and customers who stop buying rarely announce it. A model that flags at-risk customers while they can still be won back is worth far more than a dashboard that merely reports them as gone.
2. What the project is
financial-operations-analytics is a Python pipeline that generates a synthetic Olist-style relational dataset, trains a revenue forecasting model, trains a churn classifier, and saves the resulting plots and artifacts — orchestrated by a single main.py entry point, containerized with Docker and docker-compose. The README badges read "Production," but let's be precise about what that means here: the code is a complete, runnable, reproducible pipeline; the data is synthetic, generated to mimic real e-commerce transaction patterns. It's a portfolio-grade demonstration of a real analytics workflow, not a system connected to a live store.
Project structure (verified from the repo tree):
| File | Role |
|---|---|
data_generator.py | Generates the synthetic relational dataset |
revenue_forecast.py | XGBoost 30-day revenue forecasting model |
churn_prediction.py | Random Forest churn classifier |
main.py | Pipeline entry point (matches the Dockerfile CMD) |
Dockerfile / docker-compose.yml | Containerized execution |
orders.csv, order_items.csv, customers.csv, payments.csv | Generated relational tables |
revenue_forecast.png, forecast_feature_importance.png, churn_confusion_matrix.png | Generated outputs |
3. The data layer: a synthetic relational schema
The pipeline starts with data_generator.py, which simulates the full lifecycle of an e-commerce order — purchase, approval, delivery — across five relational tables: Orders, Order Items, Payments, Customers, and Sellers. The design is inspired by the well-known Olist Brazilian e-commerce public dataset, which makes the schema realistic enough for the modeling techniques to mean something. Faker generates the customer and seller records with a fixed seed (reproducible), and roughly two years of order history provide the temporal depth the forecasting model needs.
The important design choice: main.py checks for the CSV files and only generates data when they're missing. That means the pipeline is idempotent — run it once, it generates and models; run it again, it skips generation and re-runs the models. Small detail, big reproducibility win.
4. Revenue forecasting: XGBoost on engineered time-series features
revenue_forecast.py aggregates transactional data into a daily revenue series, then engineers the features that make tree-based models competitive at time-series forecasting:
- Calendar features: day of week, month, day of year — capturing weekly and seasonal structure.
- Lag features: revenue at lags of 1, 7, 14, and 30 days — yesterday matters, last week matters, last month matters.
- Rolling features: 7-day and 30-day rolling means (shifted by one day to avoid lookahead bias) — smoothing the noise out of the signal.
The modeling itself is careful about the classic time-series trap: no random train/test shuffling. The data is split chronologically (80/20 time-based split), the XGBRegressor is configured with 1000 estimators, a low 0.01 learning rate, and early stopping (50 rounds) against the test set. Evaluation reports MAE and RMSE in dollars, and the script plots the forecast against history into revenue_forecast.png, plus a feature-importance chart.
The time-based split is the single most important correctness decision in this file. Shuffling a time series before splitting leaks the future into training — every "impressive" metric that follows is a lie. This pipeline doesn't make that mistake.
The 30-day forecast horizon matches the business planning cadence: next month's revenue, in one number, with a model that degrades gracefully because it's built on lagged history rather than fragile assumptions about external drivers.
5. Churn prediction: RFM features with a time-window label
churn_prediction.py builds customer-level features in the classic RFM mold — Recency (days since last purchase), Frequency (order count), Monetary (total spend) — then faces the central methodological question of churn modeling honestly, in comments: what exactly are we predicting?
The naive approach — "churn = recency > 90 days" — labels the present, not the future; a model trained on it is just learning to restate its own features. The code comments walk through this explicitly and choose the better approach: split time into an observation window and a performance window. Features are computed from orders before October 1, 2023; the target is whether the customer bought during the subsequent performance window (October–December 2023). The model predicts a genuine future event, not a restatement of its inputs.
The classifier is a RandomForestClassifier (a solid, interpretable baseline for tabular churn), evaluated with a full classification report, ROC-AUC, and a confusion matrix saved as churn_confusion_matrix.png. Random Forests handle the non-linear, threshold-heavy structure of RFM data well, and the feature importances double as business intelligence — which behaviors actually precede churn.
6. The artifacts tell the story
Three PNGs ship with the repo, and they're worth a look. revenue_forecast.png overlays the 30-day predicted revenue against the training history — the visual check every forecaster should run, because a model with decent MAE can still be structurally wrong (flat when reality is seasonal, lagging when reality leads). forecast_feature_importance.png ranks which inputs the XGBoost model actually leans on; in practice with this feature set, the 7-day lag and 30-day rolling mean dominate, which is the model rediscovering that retail revenue is mostly momentum plus weekly seasonality. churn_confusion_matrix.png shows where the Random Forest's errors concentrate — and in churn models, the error pattern matters more than the headline accuracy, because misclassifying an at-risk customer as safe costs more than the reverse.
7. How to run it
git clone https://github.com/Shivay00001/financial-operations-analytics.git
cd financial-operations-analytics
pip install -r requirements.txt # pandas, numpy, faker, scikit-learn, xgboost, matplotlib, seaborn
python main.py
That's it. main.py generates the data if absent, runs the revenue forecast, runs the churn model, and prints MAE/RMSE plus the classification metrics. Or use Docker: the Dockerfile's CMD is python main.py, so docker-compose up runs the whole pipeline in a container. Everything runs locally on synthetic data — no credentials, no API keys, no cost.
8. Honest status and roadmap
What this is: a complete, working, containerized analytics pipeline demonstrating production-shaped ML workflows — data generation, feature engineering, time-aware validation, two complementary models, and saved artifacts. The code is real and runs.
What it isn't: it trains on synthetic data, not a live store's transactions; no real-world performance numbers are claimed. One honest caveat: the README lists a broad BI ecosystem (R, PowerBI, Tableau, Qlik Sense, BigQuery, Talend, SAS) that isn't exercised by the Python code in the repo — the actual stack is pandas, scikit-learn, XGBoost, and matplotlib/seaborn. Treat the BI list as planned or adjacent tooling, not implemented functionality.
Sensible next steps for this project: backtest the revenue forecast with a rolling-origin evaluation across multiple 30-day windows; calibrate the churn classifier's probabilities (they drive retention-campaign spend); add promotion features from the payments table; and validate the pipeline on a genuinely live dataset, where the observation/performance-window churn framing will face its first honest test.
Operationally, the repo also ships a Dockerfile whose CMD is python main.py plus a docker-compose.yml, so the entire pipeline — data generation, both models, all artifacts — runs reproducibly in a container. That's the detail that turns a notebook into something a team can actually adopt: same code, same environment, same outputs, on any machine.
Frequently asked questions
What does the financial-operations-analytics repo do?
It's an open-source Python pipeline that generates synthetic e-commerce data, forecasts 30-day revenue with XGBoost, and predicts customer churn with a Random Forest trained on RFM features — all runnable with one command or via Docker.
How does the revenue forecast avoid lookahead bias?
Daily revenue is aggregated from transactions, features use only lagged and shifted-rolling values, and the train/test split is chronological (80/20) — the model never sees the future during training.
How is churn defined in the project?
Honestly: features come from an observation window (orders before October 1, 2023) and the target is whether the customer purchased in the subsequent performance window — a true future event, not a restatement of recency.
Is the data real?
No — the dataset is synthetic, generated with Faker to mimic the Olist e-commerce schema. The value is the methodology: the pipeline patterns transfer directly to real transactional data.
The bottom line
Forecast revenue like a time-series problem (lags, rolling means, chronological splits) and predict churn like a future-event problem (observation vs. performance windows) — this repo demonstrates both, cleanly, on one codebase. The methodology is the product; the synthetic data is just the rehearsal space.
Repo: github.com/Shivay00001/financial-operations-analytics — MIT licensed. Want this kind of analytics built on your real data? VisionQuantech builds revenue and churn analytics for e-commerce businesses. Contact: [email protected]