Project 1: E-Commerce Profitability Diagnostic

Revenue held steady all year. Profit nearly disappeared. This project finds out why.

Overview

An 18,000-order e-commerce dataset (Sept 2025–Aug 2026) looked healthy on the surface — revenue stayed strong, month after month. But contribution profit told a different story, collapsing to under 1% margin for the year. This project traces that gap back to its root causes using a full Python → SQL → Power BI pipeline.

The question: revenue looks fine, so where did the profit go?

Dataset

Source: E-commerce transaction data (Orders, Customers, Products, Marketing, Targets)

Size: 18,000 rows

Period: Sept 2025 – Aug 2026

Format: Excel / CSV

Data quality: No nulls, no duplicates, no broken references — every formula checked out. A clean dataset, which meant the profit collapse was real, not a data error.

Methodology

Python → cleaned and validated the raw data, then rebuilt it as a proper star schema.

MySQL → independently verified every finding with SQL — joins, CTEs, and window functions (LAG, RANK, NTILE, running totals) — cross-checked against the Python results.

Power BI → built the final diagnostic dashboard on the verified model, with 12 custom DAX measures for margin, discount rate, return rate, and channel ROI.

Dashboard Features

• KPI cards — Contribution Profit, Realized Revenue, Return Rate %, Margin %

• Time trend — revenue vs. contribution profit by month

• Category breakdown — profit by product category

• Channel efficiency — profit per marketing naira by acquisition channel

• Regional drill-down — profit by customer segment and region

• Discount & return trend — discount rate and return rate by month

Key Insights

• Margin collapsed from 13.2% to under 1% for the year, even though revenue held steady at ₦200–300M a month

• Average discount rate roughly doubled, from ~10% to ~22-23%, starting Nov 2025, and never came back down — company-wide, across every channel and category

• Electronics alone erases ₦100M in profit; its 22% base margin can't absorb the discount rate every other category tolerates fine

• Marketplace and Instagram lose money on every naira of marketing spend; Website is the only channel with strong, reliable ROI

• Just 6.9% of orders are returned, but they wipe out 87% of the profit the remaining orders generate

• Delta is the only region operating at a loss, despite solid revenue (₦198M) — the cause traces specifically to its Consumer segment, where the return rate runs a full point above every other region's consumer base

Recommendations

• Cap discount rate by category — thin-margin categories like Electronics need a lower ceiling than high-margin ones like Fashion

• Reassess spend on Marketplace and Instagram, or renegotiate their cost structure, given consistently negative ROI

• Investigate the Nov 2025 discount policy change specifically — that's the exact point where company-wide margin turned negative

• Audit return drivers by channel — Instagram and Marketplace also carry the highest return rates

• Investigate Delta's Consumer segment specifically — elevated returns there, not category mix or discounting, are driving the region's loss

Limitations

• No product-level detail on why individual SKUs get returned (defect, sizing, wrong item, changed mind) — return rate is visible, root cause per return is not

• Revenue targets provided in the source data appear mis-scaled relative to actual revenue every month, so the Targets table was treated cautiously rather than as a reliable benchmark

• Region and customer-segment sample sizes vary — Delta's finding is based on its full order volume for the year, but smaller regions in general should be read with that in mind

Expected Impact

Turns a vague "profit feels low" concern into a specific, evidenced diagnosis — pinpointing the exact lever (discounting), category (Electronics), channels (Marketplace, Instagram), and region (Delta) driving the gap between healthy revenue and near-zero profit.

Tools

Python Pandas SciPy MySQL Power BI DAX

Project 2:  Interactive Real Estate Analytics

🌐 Live Demo

Overview

A Streamlit dashboard analyzing 7,999 UK property transactions (2010–2025), with a regression model that estimates property prices from district, property type, tenure, and year.

This project finds out what actually drives property prices in this market, and whether they can be predicted.

Dataset

Provided by client (proprietary UK property data) containing 7,999 rows × 12 columns from 2010–2025 ·

CSV Fields: Price, Date of Transfer, Property Type, Tenure, New Build Status, District, Town/City, County

Data quality: 984 missing District values, 35 duplicate rows, 529 outlier transactions above £671,500 (max £26.7M). No negative/zero prices; categorical fields were clean.

Methodology

Removed rows outside the analysis scope, converted Date of Transfer into proper date fields (year, month), and encoded categorical variables (property type, tenure, build status) for the regression model.

Key Findings

• Location leads. Crawley tops average price, alongside London-adjacent districts (Camden, Westminster, Hammersmith & Fulham). Top-district prices are spiky, not steady 

• Property type moves price. Detached (£412K) vs. Terraced (£255K)/Flat (£257K); too wide a gap to blend into one average.

• Tenure matters. Freehold averages ~£320K vs. ~£250K for Leasehold, a consistent ~25% gap.

• Price ≠ volume. Price dipped sharply around 2020 and recovered by 2025, but transaction volume stayed flat (approximately 450–500/year) throughout — the swings are about what's selling, not how much.

Model

· Regression (Scikit-learn) 

· Inputs: District, Property Type, Tenure, Year 

· Output: Estimated price 

· Performance: [add R² / RMSE]

Recommendations

• Segment pricing by property type, not one blended average

• Make tenure a primary filter, not secondary

• Pair every price chart with transaction volume

• Flag low-volume districts so a "top price" isn't mistaken for a stable trend

Expected Impact

Gives buyers and sellers a data-backed reference point instead of relying on asking prices alone — surfacing what actually drives value (location, type, tenure) rather than guesswork.

Tools

Python · Pandas · Scikit-learn · Streamlit · Plotly

Project 3: Real Estate Market Intelligence Dashboard

Overview

An interactive Power BI dashboard that turns raw UK property transaction records into a clear view of where value sits in the market, priced by district, property type, tenure, and build status, built for investors and stakeholders who need signal, not spreadsheets.

Business Problem

Investors rarely lack data; they lack a fast way to read it. Raw transaction records don't tell you which districts are worth watching or whether tenure and property type actually move the price. This dashboard closes that gap.

Objective

Build a single interactive view of the UK property market that surfaces the real drivers of price and lets users filter by Year, Property Type, and District to spot investment opportunities in seconds, not hours.

Dataset

Provided by the client, just over 1 million property transaction records (1,048,575 rows, 8 columns). Fields include price, transfer date, postcode, property type, tenure, new-build status, town/city, and district.

Data Preparation

The dataset was cleaned in Power Query before modeling. Standard checks for missing values, duplicate records, and formatting inconsistencies were applied so the numbers in the dashboard reflect real transactions rather than data noise.

Dashboard Features

• KPI cards: Average Price, Total Transactions

• Time trend: transaction volume and price by year and month

• Market comparison: property type, tenure, new-build vs. existing

• Geographic ranking: top districts by average price

• Filters: Year, Property Type, District

Key Insights

• Kensington & Chelsea leads the market at £270.75K average, nearly 50% above City of Westminster in second place (£183.77K)

• Detached homes are the clear value driver, averaging £105.90K against £51.71K for Terraced properties, roughly double

• Freehold carries a 26% premium over Leasehold (£72K vs £57K)

• New builds price ~21% higher than existing stock (£81K vs £67K)

• Seasonality is real: prices peak in August, dipping through the winter months

• Market volume dropped sharply, down 68.5% from 1995 to 1996, a shift worth investigating before drawing pricing conclusions from the later period

Recommendations

• Weight district selection heavily in investment screening: location alone explains a wide part of the price spread

• Treat tenure and new-build status as standard filters, not secondary detail, given their consistent price effect

• Read year-over-year price changes alongside transaction volume; a sharp drop in the second year of the dataset means fewer sales are setting the average, which can distort trend lines

Limitations

• No data on property condition, floor area, or bedroom count; factors that meaningfully affect price beyond location and type

• 673 records were missing postcode data, and a small number of duplicate entries existed before cleaning

• District-level rankings can be skewed where transaction counts are low

Project 4: Retail Sales Performance Analysis

Overview

A SQL-driven analysis of retail transaction data, digging into what actually generates revenue, who the highest-value customers are, and how performance differs across branches. No dashboard here, just queries doing the heavy lifting: joins, aggregates, and CASE logic turning raw transaction rows into answers a business can act on.

Business Problem

Retail businesses generate transaction data constantly, but raw rows in a sales_transactions table don't tell you which products are carrying the business, which customers are worth retaining, or which branches need attention. This project uses SQL directly against the data to answer those questions.

Tools Used

• MySQL

• SQL

Dataset

Retail Sales Dataset; transactional data spanning three related tables: sales_transactions, customers, and products.

What I Did

• Queried transactional sales data directly in MySQL

• Joined sales_transactions with customers and products to combine sales, customer, and product-level detail

• Used aggregate functions (SUM), GROUP BY, and ORDER BY ... LIMIT to rank performance

• Segmented transactions into spending bands using CASE logic to identify top-performing customers and products

• Broke down revenue by branch, category, and customer to surface where value is concentrated

Key Insights

Revenue is heavily concentrated in Electronics. Electronics generated £800,000 in revenue — more than six times Fashion (£115,000) and Food (£114,000), and over 30x Home Care (£23,000). Category performance here isn't close; Electronics is carrying the business.

A handful of customers drive most of the value. The top 3 customers by revenue show a steep drop-off: Customer 3 at £550,000, Customer 2 at £250,000, and Customer 1 at £90,000. The top customer alone generated more than the second and third combined — a strong signal for where a loyalty or retention program would pay off first.

Sample Queries

• -- Top 3 Customers by Revenue

• SELECT c.customer_id, SUM(unit_price * quantity) AS revenue

• FROM sales_transactions s

• JOIN customers c ON c.customer_id = s.customer_id

• GROUP BY c.customer_id

• ORDER BY revenue DESC

• LIMIT 3;

• -- Revenue by Category

• SELECT p.category, SUM(s.unit_price * s.quantity) AS revenue

• FROM sales_transactions s

• JOIN products p ON s.product_id = p.product_id

• GROUP BY p.category

ORDER BY revenue DESC;

Why Spreadsheets

Not applicable here — this project intentionally works directly against structured data in SQL rather than a spreadsheet layer, since multi-table joins and aggregate logic at this scale are a better fit for a query engine than pivot tables.

Project 5: Retrieval-Augmented Generation (RAG) Research System

Overview

AI models are confident even when they're wrong; that's the problem this project sits inside. I tested how much retrieval actually helps by running the same questions through a base model and a RAG-augmented one across datasets in different languages and subject areas, and measured how often each one told the truth.

Problem

Left to their own memory, language models hallucinate they answer fluently whether or not they actually know the answer. This project asks a direct question: does grounding a model in retrieved source data measurably fix that, or is it overstated?

Tools

• Python

• AI models 

What I Did

• Loaded multiple datasets across different languages and subject domains

• Asked the same set of questions against both a base model and a RAG-augmented pipeline

• Built retrieval workflows to pull relevant source context into each response

• Compared answers against the source data to measure real accuracy, not just fluency

Key Insight

Grounding beats memory. The base model hallucinated frequently — confident, well-written answers that simply weren't true. The RAG-augmented version hit roughly 90% accuracy across the datasets tested, holding up consistently across languages and subject areas rather than just one narrow case.

The gap wasn't subtle. It's the difference between a model guessing well and a model actually checking its work.

Project 6: Business Analytics Solutions

Overview

Most businesses don't need a data team; they need someone who can look at a messy sheet and make it make sense.

That's what this repo is: five independent Google Sheets builds, each one solving a different everyday operations problem: sales, spending, payroll, stock, performance. No shared codebase, no single "system" tying them together. Just five snapshots of the same core skill applied to five different rooms in the business: pull the numbers together, find what actually matters, and hand back something a non-technical stakeholder can read in under a minute.

Tools Used

• Google Sheets

• Pivot Tables

• Charts & Visualizations

• Formulas & Functions

• Conditional Formatting

• Dashboard Design

1. Sales Performance Analysis

Objective: Track revenue by product, region, and sales rep to spot performance patterns.

What I Did: Built a pivot-table-driven dashboard summarizing sales by product and region, with rep-level performance broken out separately.

Key Insights:

• Laptops drove the bulk of revenue; over half of total sales (£1.08M of £1.985M)

• The North region outperformed every other territory (£610K), narrowly ahead of South (£570K)

• Aisha was the top-performing rep by total sales, slightly ahead of John

2. Expense Tracker

Objective: Track spending by category and simplify budget monitoring.

What I Did: Built an automated, category-based expense log with a donut chart that breaks down where money actually goes each month.

Key Insights:

• Food accounted for nearly half of January spending (£8,000 of £18,100 total)

• Transport and Data were the next largest categories, both in the £2,800–£3,000 range

• Entertainment was the smallest spending category by a wide margin

3. Payroll Management System

Objective: Automate salary calculations and flag payroll issues before they become problems.

What I Did: Built a payroll calculator from daily rate and days worked, with conditional formatting to flag employees needing review.

Key Insights:

• Total payroll cost across the tracked team: £598,000

• Average salary sat at £149,500, with a £93,000 spread between the highest and lowest paid employee

• Two of four employees were automatically flagged "Needs Review" — the system catches outliers without manual checking

4. Inventory Management System

Objective: Monitor stock levels and flag reorder needs before items run out.

What I Did: Built a stock tracker comparing stock in vs. stock out against reorder thresholds, with automatic status flags.

Key Insights:

• 4 of 5 tracked items dropped below their reorder level — a stock position that needs urgent attention

• Equipment items (syringes, gloves) saw the heaviest stock movement, signaling high demand

• Vitamin C had the lowest stockout rate, suggesting it's overstocked relative to actual use

5. Student Performance Analysis

Objective: Track academic performance and identify students who need support.

What I Did: Built a scoring system across three subjects with automated grading, cross-validated using both VLOOKUP and XLOOKUP formulas.

Key Insights:

• Class average landed at 71.33, with scores ranging from 47.67 to 92.33

• 5 of 6 students passed (≥50 average); one student scored an F and stands out as needing follow-up

• The top and bottom performers differed by nearly 45 points — a gap worth investigating at the individual level

Key Skills Demonstrated

• Data Cleaning & Organization

• Dashboard Development

• Business Reporting

• Data Visualization

• Spreadsheet Automation

• Analytical Problem Solving

• Performance Monitoring

Why Spreadsheets?

Not every business problem needs a full BI stack. For teams tracking a handful of products, a small headcount, or a single department's spending, Google Sheets and Excel remain some of the fastest, most accessible tools for turning raw numbers into a working report — no infrastructure, no setup cost, no learning curve for the people who actually have to use it day to day.

These five projects show that approach in practice: pivot tables, conditional formatting, and formulas doing real analytical work without needing a heavier platform. As data volume or complexity grows, that same logic scales naturally into Power BI, Tableau, or a SQL-backed system — but for a huge range of small and mid-sized business problems, a well-built spreadsheet is the right tool, not a placeholder for one.

Project 7: University Student Performance Analysis

Overview

SQL against real academic records to identify who is excelling, which departments are pulling weight, and where the administrative cracks actually are. No dashboard, just queries doing the digging.

Problem

Universities sit on years of student data that rarely gets looked at as a whole. This project queries it directly to surface GPA trends, department performance, and registration gaps that would otherwise stay buried in individual records.

Tools

• MySQL 

•  SQL

Dataset

University Student Records Dataset.

What I Did

• Queried student performance data directly in SQL

• Used aggregate functions to compare GPA trends across departments and gender

• Joined tables to trace course registration patterns

• Flagged students with no course registration and evaluated performance against those gaps

Key Insights

• Performance varies by department and demographic group. GPA trends were not uniform across the dataset; certain departments and student groups consistently outperformed others, indicating that academic support may need to be targeted rather than applied uniformly.

• Incomplete course registration signals a process gap. A subset of students had no course registration on record. This pattern is more consistent with an administrative or data-entry gap than with genuine non-enrollment, and warrants further review.

• Top performers are identifiable at both the student and department level. The analysis produced a clear, data-backed ranking of high-performing students and departments, providing a defensible basis for recognition or resource allocation decisions.