Isaac Ochieng
I work out why the numbers don’t add up — then build the process that keeps them adding up.
I work with messy data — spreadsheets, exports, records from systems that were never meant to talk to each other — and turn it into numbers a business can trust. Cleaning what’s inconsistent, reconciling what disagrees, building reports that answer a real question, and setting up the pipelines that keep those reports running without someone rebuilding them by hand every month.
| status | orders | late | % late |
|---|---|---|---|
| delivered | 96,478 | 7,826 | 8.1% |
| shipped | 1,107 | — | — |
| canceled | 625 | — | — |
| processing | 301 | — | — |
Projects
SQL projects — the work, and the code behind it.
Everything below is portfolio work — the brief, the method, and the mistake I nearly shipped. Each one links straight to the repository and the full write-up.
Ranking sellers by average delay almost made me miss the real problem.
A delivery-performance audit of a 100,000-order marketplace, and the ranking that pointed the wrong way.
Nearly one in three sellers on this marketplace had shipped at least one late order. The obvious first move was to rank sellers by average delivery delay and start at the top of that list.
That ranking was misleading. It surfaced low-volume sellers with a single bad month, while the high-volume sellers responsible for most of the actual late deliveries sat well down the list. Average delay answers a different question than the one that matters operationally.
The repository holds the full query set, including the row fan-out and inner-join traps that quietly drop unreviewed orders out of the count before you’ve noticed the totals stopped reconciling.
Delivery performance across ~100,000 orders, seller-level ranking, and a reconciliation check at every join.
StackAn A/B test where the winning variant wasn’t the winner.
Experiment analysis from raw event data — assignment, exposure, and the checks that decide whether a result is real.
Building an end-to-end experiment analysis: pulling assignment and event tables, checking for sample-ratio mismatch before touching the metric, then testing the difference and stating the uncertainty honestly rather than reporting a lift and stopping.
The interesting part is everything that happens before the significance test. Most bad experiment calls are made in the setup, not the statistics.
Segmenting customers without inventing groups that don’t exist.
RFM segmentation on transaction data, and the discipline of checking a segment is real before naming it.
Scoring customers on recency, frequency and monetary value, then testing whether the resulting groups actually behave differently or just look tidy on a scatter plot.
Segments are easy to produce and hard to justify. This one is built to be argued with — the cut points are stated, and so is what happens to the picture when you move them.
Skills
Skills — what I reach for, and what I reach for it to do.
Listed by how much I actually use each one, rather than by how impressive it looks in a list.
SQL
Joins, window functions and CTEs — plus the reconciliation checks that catch a wrong number before it reaches a dashboard. Most of my time is spent here.
Tableau & reporting
Dashboards built to answer a specific question rather than to fill a canvas. If a chart isn’t changing a decision, it’s costing attention for nothing.
Cleaning & reconciliation
Finding where two systems disagree and working out which one is right. Unglamorous, and usually where the real problem turns out to be hiding.
Python
Cleaning, reshaping and automating the steps that would otherwise be repeated by hand every month. The point is that it stops being a monthly job.
Spreadsheets
Excel and Google Sheets — still where most organisations keep the numbers that matter. Worth doing properly rather than migrating away from on principle.
Data modelling
Structuring tables so the same question gives the same answer regardless of who asks it. This is the bridge into the analytics engineering work I’m growing into.
Writing
Writing — a working log, kept in public.
Write-ups of the projects on this site — the method, the checks I ran, and the approaches I threw away before landing on the one that held. New pieces land here first.
Olist SQL Project: Why Average Delay Rankings Can Be Misleading
The full method behind the delivery-performance audit — and why the first ranking I built pointed at the wrong sellers.
Three join mistakes that quietly changed my totals.
Row fan-out, inner joins that drop rows you needed, and the reconciliation check I now run before trusting any aggregate.
Data problems costing Kenyan SMEs money in 2026.
M-Pesa records that never match the books, stock counts nobody trusts, and reports rebuilt from scratch every month.
FAQ
Data analyst FAQ — the questions I get asked most.
Project 01 is complete and the repository is public. Projects 02 and 03 are in progress and labelled that way — they’ll appear with their code when they’re done, not before. I’d rather this page stay short and true than fill up with work I can’t stand behind.
Analyst today, deliberately. SQL, reporting and making messy data trustworthy is where I’m most useful right now, and it’s what most small organisations actually need. I’m building toward analytics engineering — transformation modelling, warehouse design — and I’d rather state that as a direction than dress it up as a credential I don’t yet hold.
Yes — every finished project links to its repository, queries and all. The write-ups in Writing go through the reasoning, including the versions I threw away. If you want a walkthrough rather than a read, ask and I’ll take you through it.
Yes. I’m based in Nairobi and set up to work remotely — most of this kind of work doesn’t need me in the room, and calls happen when they’re useful rather than on a fixed schedule. If you’re nearby and would rather meet in person, that’s fine too.
Yes, alongside freelance and contract work. If you’re hiring for a data analyst or analytics engineering role and this way of working looks like a fit, get in touch — the projects on this site are the clearest picture I can give you of how I think.
Hire a data analyst — something not adding up?
If your reports take too long to build, your numbers don’t reconcile, or there’s a repetitive data task eating a day every month — I’d like to hear about it. The first conversation is free and usually takes about thirty minutes. If you’re hiring for a data analyst or analytics engineering role, that’s welcome too.
isaacochieng@chuiassistant.com