From Scattered Field Records to County-Wide Intelligence: Building a Data System for Aquaculture in Makueni County
Jacobs Ladder Africa
Jacob’s Ladder Africa (JLA) operates as a Pan-African catalytic integrator focused on accelerating the continent’s economic transformation through youth-led green enterprises. The organisation supports these enterprises as they grow, helping them generate employment, deliver climate-focused solutions, and build economic resilience across the region. This work happens through partnerships with governments, investors, and local ecosystems, enabling young entrepreneurs to turn their skills and ideas into sustainable businesses and livelihoods across multiple countries and sectors.
One of those programmes is an aquaculture project in Makueni County, Kenya, which equips young people with fish farming skills by providing fingerlings, feed, pond infrastructure and supports them through the growing cycle toward harvest and sales.
By late 2024, the programme had run two cohorts across 18 beneficiaries in multiple wards, with field teams logging daily monitoring data on fish health, feed usage, water quality and mortality. The data existed. The problem was that it existed everywhere and nowhere useful at the same time.
The Problem
The raw monitoring records for Cohorts 1 and 2 were spread across separate spreadsheets with no shared structure. Field entries used mixed units, some recorded feed in kilograms, others in spoons. Date formats varied. Cells were merged, duplicated or left blank. Beneficiary names were inconsistent across files with no unique identifier linking a person’s monitoring record to their pond, their cohort or their ward.
There were over 30,000 records from 18 programme sites. None of them could talk to each other.
The programme team was looking to answer basic questions: Which cohort was performing better? Were water quality issues improving or worsening? Was the feed being supplied actually being consumed? Were fish dying because of water quality, feeding problems or something else entirely?
Without answers to those questions, the programme team was flying blind. And so were its partners.
JLA engaged Data Tree to help answer these questions and to develop the required infrastructure for a strong data first foundation going forward.
The Approach
First step: split the work into four phases.
Phase 1: Clean the foundation.
Before any analysis or visualisation, the data had to be trustworthy. All raw monitoring files across both cohorts were reviewed, date inconsistencies corrected, duplicates removed and every field standardised: column names, units, formats and value categories. Feed measurements were converted from inconsistent units to kilograms. Water quality comments were classified into structured categories: Bad, Moderately Bad, Moderately Good and Optimal.
A consistent beneficiary ID system was introduced to link records across all datasets and everything was codified in a data dictionary, a single reference document, defining every field, every unit and every KPI formula, so that anyone joining the project later would inherit a system, not a guessing game.
Phase 2: Define what matters.
Not all metrics behave the same way in operational data. Mortalities are event-based: they accumulate, so you sum them. Fish remaining is a state: it reflects a point in time, so you take the latest value. Getting this wrong produces dashboards that look plausible but are factually incorrect. Aggregation logic was defined for every KPI before building anything visual: mortality rate, feed conversion ratio, engagement score, PWD participation rate and gender distribution.
Phase 3: The Build Stage: Dashboards for different audiences.
Four Looker Studio dashboards were built, each designed to answer a different set of questions for a different audience:
Monitoring Overview: operational dashboard tracking fish health, feed efficiency, water quality trends and pond locations on a live map
Programme Monitoring: cohort-level performance comparison with mortality trends and remaining fish over time
Sales Overview: revenue and volume tracking for fish and produce sales with product-level breakdown and traceability records
Livelihoods Impact: beneficiary view combining production data with gender and disability inclusion metrics for donor reporting.
Phase 4: Handover and capacity building.
A dashboard is only as useful as the people who use it. The final phase focused on ensuring the programme team could read, interpret and update the system independently, not just receive outputs from it.
What the Data Revealed
The dashboards provided insights across both cohorts that the programme team could now act on.
The programme was generating income: The team was able to get granular on fish sales and produce sales including tomatoes, pawpaw and watermelon.
Inclusion indicators were visible for the first time: 12 male and 6 female beneficiaries, with 2 participants living with disability. These figures, previously buried in raw files, were now surfaced automatically in every report, giving the programme a live inclusion metric without manual counting.
Feed supply and consumption were misaligned: The feed supplied versus consumed chart revealed specific months where consumption significantly exceeded supply, suggesting stockpile drawdowns or data entry gaps, and other months where supply was abundant but consumption was low, raising questions about fish health or beneficiary engagement.
The Impact
The new data infrastructure was integrated into JLAs the programme’s annual impact reports. What had been a collection of unconnected spreadsheets became a shared system that programme teams, M&E officers, and stakeholders could access, interpret and act on.
The dashboards are designed to grow with the programme and as new data fields are added, the system accommodates them without requiring a full rebuild.
Key Lessons Learned
Data structure matters more than dashboard complexity: The majority of the work happened before a single chart was built. A well-structured, trustworthy datamart is the foundation that makes everything else possible.
Operational data requires contextual aggregation logic: Understanding the difference between event-based and state-based metrics is the difference between a correct dashboard and a misleading one.
Visualisation problems are usually data problems: When charts behaved unexpectedly, the root cause was almost always in the data structure or aggregation logic, not the visualisation layer.
Simple, interpretable KPIs outperform sophisticated models on incomplete data: Trends were aligned, risks were identified, for programme decisions making than any predictive modelling would have been on data this incomplete.
Capacity building is as important as system delivery: A dashboard that only the data consultant can read is not a programme asset, it is a dependency.
Scalable systems should anticipate growth: The DataMart and dashboard architecture were designed to accommodate future additions without requiring a full redesign. Building for future scale at the outset costs very little extra and saves significant rework later.
This project was delivered by Data Tree Africa. The data infrastructure was subsequently adopted by JLA programme teams.
By Mariam Haji | Data and Business Intelligence Consultant