Finding the story in the data.
Hi 👋 I'm Harshvardhan, a B.Tech Electronics & Computer Engineering student who turns raw data into decisions. I work with Python, SQL and Power BI on forecasting, customer analytics and data warehousing, and I'm especially interested in finance analytics and data infrastructure.
| Project | What it covers |
|---|---|
| Financial Operations Analytics | Revenue forecasting, churn prediction and customer clustering on 5 years of simulated SaaS data, with a focus on finding and fixing data leakage |
| Retail & Marketing Analytics | RFM segmentation, customer lifetime value and cohort retention across 10,000 retail orders |
| E-Commerce Data Warehouse | Star schema (1 fact table, 4 dimensions), a validated ETL pipeline and a connected BI dashboard |
End-to-end analytics on a simulated 5-year SaaS business: forecasting, churn, segmentation and retention
| Scope | 5,000 customers and 135,218 transactions (2020 to 2024), synthetic data with a planted usage-score → churn signal so every model could be checked against ground truth |
| Key findings | • $3.5M/year of revenue flagged at risk across 1,166 active customers above a 15% churn-probability threshold • The "At Risk" RFM segment holds $10.4M, more than "Champions" at $8.1M, so the most valuable customers are showing early warning signs • K-Means found behavioral segments that cut across pricing tiers instead of just mirroring plan price |
| Rigor | Caught a data leakage bug: the first churn models scored a suspicious 1.000 ROC AUC because recency_days, lifetime_months and transaction_count encoded the outcome. Rebuilt with genuine leading indicators for an honest 0.756 ROC AUC (Gradient Boosting). Cohort rankings exclude cohorts under 6 months old to avoid survivor bias |
| Forecasting | ARIMA and Prophet models reached 0.77% MAPE on held-out data |
| My contribution | Built the full pipeline in Python (forecasting, churn modelling, RFM, K-Means, cohort retention) and presented it in an interactive 5-page Power BI dashboard |
What a retail business's sales data says about its customers
| Scope | 10,000 orders from 1,986 customers, Jan 2022 to Feb 2023 (synthetic dataset) |
| Business snapshot | $1,078,670.98 revenue at an 18.4% profit margin, with an average order value of $107.87 and 10.9% of customers inactive for 180+ days |
| Key findings | • Identified 14% of customers (278 users) in the "At Risk" segment representing ~$194K in past revenue with average individual spends of $698 • Electronics ($328K) and Office Supplies ($321K) drive ~60% of total revenue • Discounting showed zero correlation with sales or profit (0.00 to 0.02), highlighting ineffective promotion spend |
| My contribution | Cleaned and explored the data, grouped customers by behaviour (RFM segmentation, lifetime value, cohort retention) across 4 notebooks, and built a 5-page Power BI dashboard: Executive Overview, Customer Segmentation, Sales Deep Dive, Cohort & Retention, Customer Value |
Raw Olist e-commerce data to a star schema, ETL pipeline and BI dashboard
| Key findings | • Designed a Star Schema comprising 1 fact table and 4 dimension tables in PostgreSQL • Implemented 12 advanced SQL queries using window functions ( RANK, LAG, NTILE, ROW_NUMBER, FIRST_VALUE) and dynamic SQL for row-count validation and monthly category pivots |
| Outcome | End-to-end Python (Pandas) ETL pipeline executing automated cleaning, deduplication, star schema transformation, and live database load into PostgreSQL, feeding a connected Power BI dashboard |
| My contribution | Designed the star schema in PostgreSQL, built the ETL in Python and SQL, and used RANK, LAG, NTILE, ROW_NUMBER and FIRST_VALUE with PARTITION BY and frame clauses |
Safe money transfers under concurrent load
| Key findings | • Handled atomic debits, credits, and transaction logging inside a single conn.begin() block with automatic rollback on failure• Enforced non-negative balance consistency via database-level CHECK (balance >= 0) constraints |
| Outcome | A robust ledger system preventing race conditions, balance inconsistencies, and negative balances during multi-threaded concurrent transfers across READ COMMITTED and SERIALIZABLE isolation levels |
| My contribution | Wrote the schema (schema.sql), the transfer logic (transfer.py) and a concurrency test (concurrency_test.py) |

