Hi, I'm Victoria — welcome to my portfolio.

01 The business problem

Apex Trust Bank processes thousands of transactions across mobile, internet banking, ATM, POS, USSD and branch channels. Every channel that makes banking more convenient also opens another door for fraud. Management needed a way to monitor transactions continuously and spot suspicious activity early, rather than reviewing it after the fact.

The brief wasn't just "build a dashboard." It was to turn raw, uncleaned transaction records into something reliable enough for the bank to act on.

02 Objectives

• Clean and validate the raw banking transaction data in SQL
• Identify fraudulent transactions and calculate core fraud KPIs
• Analyze fraud trends over time, by channel, account type and state
• Build an interactive Tableau dashboard for ongoing monitoring
• Turn the findings into concrete, actionable recommendations

03 Cleaning the data in SQL

The dataset came in with the usual real-world problems: inconsistent text formatting, missing values in fields like merchant category and channel, transaction IDs that looked duplicated, and dates in mixed formats. Rather than deleting anything by default, each issue was investigated first.

-- Flag invalid ages as NULL rather than deleting the record
UPDATE apex_bank
SET customer_age = NULL
WHERE age_flag = 'invalid_age';

-- Sanity-check the cleaned range
SELECT MIN(customer_age), MAX(customer_age)
FROM apex_bank
WHERE customer_age IS NOT NULL;

-- Catch inconsistent spacing before standardizing text fields
SELECT DISTINCT customer_gender
FROM apex_bank
WHERE customer_gender != TRIM(customer_gender);

04 Dashboard & KPIs

KPI cards sit at the top for a five-second read on bank health, with charts arranged to guide a reviewer from "how much fraud" down to "where, how, and when."

05 Key insights

06 Recommendations

• 01 Increase fraud monitoring on high-risk channels and transaction types, especially Mobile App and Internet Banking.
• 02 Deploy automated alerts for transactions with unusually high risk scores.
• 03 Run periodic reviews of states with consistently high fraud activity, starting with Lagos and Abuja.
• 04 Improve transaction validation to bring down the 16% failure/reversal rate.
• 05 Keep the dashboard live for continuous monitoring rather than periodic snapshots.
• 06 Update fraud detection rules regularly as fraud patterns shift.

07 Reflection

The real lesson from this project wasn't Tableau's chart library — it was patience with the cleaning stage. Every shortcut I was tempted to take (deleting the "duplicate" IDs, dropping rows with missing values) would have quietly distorted the fraud numbers downstream. Effective analytics isn't about a dashboard that looks good; it's about giving decision-makers a number they can trust enough to act on.

01 The business problem

Emerald Properties has six sales agents splitting leads across Residential, Commercial and Industrial listings in two branches. Management could see leads coming in, but they couldn't easily answer the questions that actually matter for running the sales team: which agents are converting, which property type is worth the marketing spend, and why so many leads stall out at "too expensive."

The brief was to build something the sales manager could open every month, filter by agent or branch, and get a straight read on performance without waiting on a manual report.

02 Objectives

• Consolidate monthly lead records into one clean, structured dataset
• Track lead volume and conversion rate by sales agent and branch
• Break down leads by property type, gender and inspection status
• Build an interactive Excel dashboard with slicers for ongoing use
• Surface patterns the sales team could actually act on

03 Preparing the data

The raw lead log came in as a flat list — client ID, gender, sales agent, date given, sales status, state, property type and inspection outcome — with 778 rows across several months. Before anything went near a chart, I pulled it through Power Query to standardize it: consistent date formatting, trimmed text fields, and status values that matched exactly across the sheet (so "Paid" and "paid " didn't get counted as two different things).

Power Query — cleaned lead dataset before load 778 rows loaded

Once the fields were clean, I loaded the query into the data model and built the dashboard on top of PivotTables, so every card and chart updates together when a slicer changes.

04 Dashboard & KPIs

The dashboard opens on total leads, then lets the manager slice by sales person, sales status or state without touching a formula. Cards sit up top for the numbers that matter first — volume and conversion — with the breakdowns underneath.

05 Key insights

06 Recommendations

• 01 Push inspection bookings harder at the point of first contact — it's the strongest predictor of a closed sale in this data.
• 02 Revisit Commercial and Industrial pricing before investing more marketing spend there; the "too expensive" objection is concentrated in these categories.
• 03 Give agents below the team average targeted coaching on negotiation, since lead volume across agents is fairly even but conversion isn't.
• 04 Dig into why female leads convert at a lower rate than male leads — this looks like an engagement gap, not a demand gap.
• 05 Keep doubling down on Residential while treating Industrial as a lead-generation problem, not a sales-execution one.
• 06 Re-run this dashboard monthly rather than as a one-off report, so trends show up before they become a full quarter's problem.

07 Reflection

This project was less about the dashboard and more about the plumbing underneath it. Getting six months of loosely-formatted lead entries into one query that actually matched on gender, status and property type consistently took longer than building every chart combined — and it's exactly the part that doesn't show up in the final screenshot. If that step is sloppy, every slicer on top of it is just filtering bad data faster.

01 The business problem

Healthcare data can contain useful information about patient outcomes, treatment patterns, and resource use, but raw records are difficult to interpret without proper cleaning and visualization. This project transformed breast cancer patient data into an interactive dashboard to make key outcome, demographic, treatment, and insurance patterns easier to monitor.

02 Objectives

• Clean and validate the raw patient dataset using SQL/MySQL
• Prepare an analysis-ready dataset for Power BI
• Monitor patient outcomes and survival status
• Analyze tumour-stage and age-group patterns
• Understand surgery-type distribution
• Track insurance expenditure
• Build an interactive dashboard for easier analysis and monitoring
• Translate findings into practical healthcare planning recommendations

03 Preparing the data

The raw dataset contained 1,338 patient records across 16 fields. Work in MySQL Workbench covered exploring the raw data, inspecting the table structure, checking for duplicate records, validating patient IDs, checking for missing values, standardizing categorical and date fields, and preparing the insurance-paid figures for analysis. The final analytical dataset was reduced to 334 unique patient records across 9 analysis-ready fields, validated for completeness before moving into Power BI.

MySQL — cleaned, analysis-ready dataset 334 rows

The original SQL script used during this workflow is no longer available, but the screenshot above shows the structured result of that cleaning process, ready for Power BI.

04 Dashboard & KPIs

The dashboard opens on six KPI cards covering patient volume, survival, average age, and insurance cost, then breaks the data down by tumour stage, patient status, surgery type, and age group, with filters for surgery type, patient status, age group, tumour stage, and date of surgery.

05 Key insights

06 Recommendations

• 01 Track survival and mortality trends regularly to identify changes in patient outcomes.
• 02 Use age-group and tumour-stage patterns to support screening and early-detection planning.
• 03 Monitor surgery-type patterns to support surgical capacity and resource planning.
• 04 Use insurance expenditure patterns to support healthcare budgeting and resource allocation.
• 05 Refresh the dashboard regularly as new patient records become available.

07 Reflection

The findings here point to opportunities to monitor rather than firm conclusions — the dashboard highlights where Stage II diagnoses and the 50–59 age group concentrate, but it doesn't establish why, and it doesn't predict outcomes for any individual patient. As with the other projects in this portfolio, most of the real effort went into the SQL stage: getting 1,338 raw records with duplicates, inconsistent categories, and messy dates down to 334 validated, analysis-ready rows before a single visual was built in Power BI.

01 Project overview

NexaTel Communications is a fictional Nigerian telecom operator built for this portfolio project to reflect realistic telecom market dynamics. The project follows the full analytics workflow — from raw, messy multi-table data through SQL cleaning to a four-page Power BI dashboard — covering customer churn, revenue impact, and retention campaign performance. It is intended as the flagship project in this portfolio, demonstrating data modeling, DAX measure design, and business-focused dashboard storytelling.

02 Business problem

NexaTel is losing a significant share of its customer base to churn, which directly erodes revenue and increases the cost of acquiring replacement customers. Leadership needed a clear, data-driven view of who is churning, why they are churning, how much revenue is at stake, and whether the retention campaigns already running are actually working — so that retention budget could be focused on the segments and interventions with the best return.

03 Business questions

• What is the overall customer churn rate, and how has it moved month over month?
• Which customer tenure stage, contract type, and internet service carry the highest churn risk?
• Which customer segment (Consumer, SME, Enterprise) is losing the most revenue to churn?
• What are customers most commonly citing as their reason for leaving?
• How much revenue has churn cost the business, and what is the customer lifetime value by segment?
• Are the retention campaigns generating a positive return, and which campaign types perform best?

04 Dataset & data sources

The project uses a synthetic four-table relational dataset built specifically for this case study, grounded in Nigerian geography and realistic telecom pricing and usage patterns, totaling 400,000+ rows:

• Customer_Master — customer profile, segment, contract type, internet service, and churn status
• Monthly_Customer_Activity — monthly billing and usage records per customer
• Customer_Support_Interactions — support tickets and reported churn reasons
• Retention_Campaigns — campaign type, cost, customer response, and retention outcome

These four tables were linked together to support cross-table analysis of churn drivers, revenue impact, and campaign effectiveness.

05 Data cleaning & preparation

All four tables were cleaned in MySQL Workbench before any visual was built in Power BI. Cleaning work included:

• Standardizing mixed date formats across tables into a consistent format
• Fixing inconsistent text casing in categorical fields (segment, contract type, churn reason, etc.)
• Stripping currency symbols and correcting billing fields that had been stored as text
• Identifying and removing duplicate records
• Handling structural nulls left by the original data generation process

As with the other projects in this portfolio, this stage took up most of the effort — validating and reshaping four linked tables before they were analysis-ready in Power BI.

06 SQL analysis

With MySQL Workbench, the cleaned tables were queried to validate row counts, check referential integrity across the four tables, and confirm that churn status, billing figures, and campaign outcomes were consistent before the data was loaded into Power BI.

-- Standardize casing and trim whitespace on categorical fields
UPDATE customer_master
SET customer_segment = TRIM(UPPER(customer_segment)),
    contract_type   = TRIM(UPPER(contract_type)),
    internet_service = TRIM(UPPER(internet_service));

-- Remove duplicate customer records, keeping the first occurrence
DELETE c1 FROM customer_master c1
INNER JOIN customer_master c2
WHERE c1.customer_id = c2.customer_id
  AND c1.row_id > c2.row_id;

07 Power BI data modeling & DAX

In Power BI, the four cleaned tables were connected through a star-style model, with a dedicated Dim_Date table built for consistent time-intelligence across all four dashboard pages, and a standalone _Measures table used to hold every DAX measure separately from the data tables. Measures were built to cover churn rate, retention rate, revenue lost to churn, customer lifetime value (CLV), average revenue per user (ARPU), monthly recurring revenue (MRR), campaign success rate, and retention ROI.

08 Dashboard

The final dashboard is built across four pages — Executive Overview, Customer & Churn Drivers, Revenue & Customer Value, and Retention Campaign Performance — using a dark design system for readability and a consistent visual identity across the portfolio.

Page 2 — Customer & Churn Drivers Understanding the factors influencing customer churn

Page 3 — Revenue & Customer Value Understanding revenue impact and customer value across segments

Page 4 — Retention Campaign Performance Evaluating campaign effectiveness to guide future retention strategy

09 Key insights

10 Business recommendations

• 01 Focus retention efforts on customers in their first 0–6 months, since this group carries by far the highest churn risk (82.77%).
• 02 Scale up High Value, Loyalty, and Contract Renewal campaigns, which are delivering the best success rates of all campaign types.
• 03 Address billing transparency directly, since unexpected and high billing charges are the top reported reasons customers leave.
• 04 Prioritize the Consumer segment in retention planning, as it accounts for the largest share of revenue lost to churn.

11 Tools & technologies

12 Project outcome

The result is a four-page, business-ready Power BI dashboard that gives NexaTel leadership a clear, at-a-glance view of churn, revenue impact, and retention campaign performance — grounded in a fully cleaned and modeled four-table dataset. It stands as the most complete end-to-end project in this portfolio, spanning raw multi-table data through SQL cleaning, Power BI data modeling, DAX measure design, and final dashboard delivery.

13 Project files

The full project write-up, cleaning documentation, SQL scripts, and Power BI file for this case study will be published to GitHub shortly.

01 Project overview

VertaMart is a modelled Nigerian e-commerce retailer built for this portfolio project as its capstone case study. The project follows the full analytics workflow — from a nine-table relational schema through SQL cleaning to a three-page Tableau dashboard — connecting profitability, inventory, supplier, and fulfilment data that most retail dashboards report separately. It is intended as the most operationally complete project in this portfolio, demonstrating schema design, multi-table SQL cleaning, and cross-functional business analysis.

02 Business problem

Is VertaMart actually capturing the profit its revenue suggests, or are operational issues across fulfilment, delivery, inventory, suppliers, and returns quietly working against reported performance? Most retail dashboards stop at revenue and order counts. This project connects the full operational chain back to profitability to answer that question for leadership.

03 Business questions

• How is profit and revenue distributed across products, categories, and warehouses?
• How healthy is inventory across the network, and where is stockout risk concentrated?
• How reliable are suppliers, and how do lead times vary across the supplier base?
• How well is each warehouse fulfilling and delivering orders on time?
• Which return patterns are affecting the most profitable product categories?

04 Dataset & data sources

The project uses a synthetic nine-table relational dataset designed specifically for this case study, modelling five distribution centres, nine departments, and 40 suppliers across three years, totaling 396,000+ rows:

• Customers — customer profile, segment, and acquisition channel
• Orders & Order Items — order-level and line-level sales, delivery, and profit data
• Products — department, category, subcategory, supplier, and inventory thresholds
• Suppliers & Purchase Order Items — supplier reliability and purchase order fulfilment
• Warehouses & Inventory Snapshots — warehouse-level stock and stockout tracking
• Returns — return reasons, quantities, and refund values

These nine tables were linked together to support cross-table analysis of profitability, inventory health, supplier reliability, and fulfilment performance.

05 Data cleaning & preparation

All nine tables were cleaned and validated in MySQL using an Identify → Investigate → Validate → Fix → Document workflow before any visual was built in Tableau. Cleaning work included:

• Fixing a stockout flag that hadn't been set correctly wherever closing stock reached zero
• Standardizing inconsistent state and city name casing across customer and order records
• Resolving a duplicate category label caused by inconsistent naming
• Backfilling missing first-order dates for customers, while correctly distinguishing "never ordered" from a genuine data gap
• Investigating and documenting flagged anomalies — such as safety stock exceeding reorder level for some products — that turned out to be reasonable variation, not errors

The cleaned tables were joined and exported into a flat file for Tableau, with a separate pre-aggregated export built to support accurate inventory turnover calculations without row-level duplication from the join.

06 SQL analysis

With MySQL, the cleaned tables were queried to validate stockout logic, standardize categorical fields, backfill missing dates from source data, and confirm the profit formula held across the order table before the data was exported for Tableau.

-- IDENTIFY: rows where closing_stock = 0 but stockout_flag was still 0
SELECT
    SUM(CASE WHEN closing_stock = 0 AND stockout_flag != 1 THEN 1 ELSE 0 END) AS stock_zero_flag_not_set
FROM inventory_snapshots;

-- FIX: set stockout_flag = 1 wherever closing_stock is 0
UPDATE inventory_snapshots
SET stockout_flag = 1
WHERE closing_stock = 0 AND stockout_flag != 1;

07 Tableau dashboard build

In Tableau, the pre-joined dataset was used to build calculated fields, LOD expressions, and an interactive Year Selector parameter across three connected pages. The build includes custom 3D polygon bar charts, lollipop charts for lead time by supplier, and KPI tiles styled to a consistent navy-and-amber brand identity built for VertaMart.

08 Dashboard

The final dashboard is built across three pages — Operations & Profitability Overview, Inventory & Supply Performance, and Fulfilment & Returns — using a dark navy-and-amber design system for readability and a consistent visual identity across the portfolio.

Page 2 — Inventory & Supply Performance Stockout rate, supplier lead time, and turnover by department

Page 3 — Fulfilment & Returns Fulfilment rate, delivery on-time rate, and return rate by category

09 Key insights

10 Business recommendations

• 01 Audit delivery promise-setting and carrier performance at the network level, since every warehouse underperforms by a similar margin rather than one outlier site.
• 02 Open a focused operational review of Ibadan DC — the only warehouse weak on both inventory and delivery at once.
• 03 Reconcile profit-by-category figures against return rates before reporting them as standalone wins, particularly for TVs & Audio and Laptops.
• 04 Investigate Skincare (10.9%) and Toys (9.8%) return rates specifically, since both run roughly double the next-highest category.

11 Tools & technologies

12 Project outcome

The result is a three-page, business-ready Tableau dashboard that gives VertaMart leadership a connected view of profitability, inventory, supplier, and fulfilment performance — grounded in a fully designed and cleaned nine-table dataset. As the capstone project in this portfolio, it spans schema design, multi-table SQL cleaning, Tableau dashboard development, and business analysis that ties operational execution back to the profit figures leadership cares about most.

13 Project files

The full project write-up, cleaning documentation, and SQL scripts for this case study are available on GitHub.