Data & Analytics

03

Data analytics is engineering, not just charts

Too many analytics projects start at 'what chart do we want?' instead of 'what decision must this enable?'. A beautiful chart built on stale, duplicated or untraceable data will be ignored the moment someone spots a mismatch. We treat analytics as a data product: defined by the decision it enables, measured by whether it changes behaviour, and engineered with the same discipline we apply to money-moving systems.

• Decision-first, not chart-first — every report starts from the specific decision and the moment it must be made; if we cannot name the action it triggers, we do not build it.
• One source of truth — pipelines feed a single warehouse so finance, operations and management see the same number, never three versions of 'revenue'.
• Timely beats perfect — we aim for current enough to decide, with clear freshness indicators, rather than perfect-at-month-end that arrives too late to act.
• Trust is provable — every metric must be explainable to its source; lineage is not 'nice to have', it is how trust survives scrutiny.
• Built for owners, not only analysts — dashboards are designed for managers and staff who need answers in seconds, not for a single power user.
• Garbage-in prevented, not just cleaned — validation and deduplication happen at the pipeline, not at the display layer.

We bring the same rigour from our live payments platform: when a number might feed a financial decision, it must be traceable, testable and correct. That discipline is the floor for every analytics build we deliver.

04

Pipelines: extract, transform, load with integrity

The pipeline is where truth is either preserved or lost. Data from apps, payment callbacks from every rail (M-Pesa/Daraja, PayPal, Stripe, PayStack, cards, bank transfers), ledgers, CRMs and files must land cleanly, transform deterministically and load idempotently. We design pipelines that survive retries, partial failures and schema drift without corrupting the warehouse.

• Extract with resilience — incremental pulls, watermarking and backfills; network drops or partial batches never create phantom duplicates.
• Transform deterministically — SQL-based transformations are versioned, tested and reproducible; business logic lives in the pipeline, not scattered in charts.
• Load idempotently — upserts, merge strategies and deduplication keys ensure that re-running a failed batch does not multiply rows.
• Schema evolution handled — additive changes preferred, breaking changes versioned, with automated checks that catch feed drift before it reaches dashboards.
• Lineage tracked end-to-end — every transformed column traces back to its source tables and the transformation that produced it.
• Batch and near-real-time where it matters — use batch for heavy reconciliation, and near-real-time for operational alerts that must fire while action is still possible.

Idempotency and lineage are non-negotiable for us because we have seen retries and callback replays across every payment rail in production, and each one carries the same verification and reconciliation discipline. The same discipline applies to analytics pipelines: the warehouse must remain correct no matter how many times a job runs.

05

Warehouse vs lake: choosing the right foundation

We choose the storage model by the decisions you need to make, not by trend. A data warehouse is optimised for governed, structured reporting; a data lake is optimised for raw, varied inputs; most production systems benefit from a pragmatic warehouse-first approach with a raw layer for auditability.

• Warehouse-first for decisions — structured facts and dimensions optimised for fast, consistent reporting across the business.
• Raw/landing layer preserved — keep immutable raw extracts for reprocessing, audits and investigations without losing the original source.
• Facts and dimensions modelled — star/snowflake modelling keeps metrics consistent (revenue, collections, float, churn) across every dashboard and report.
• Slowly changing dimensions (SCD) — history preserved correctly when entities (properties, tenants, paybills) change over time.
• Partitioning and clustering — large tables (ledgers, transactions, payment callbacks from M-Pesa/Daraja and partner gateways) partitioned by date or business key to keep queries fast and costs controlled.
• Pragmatic, not over-engineered — start from the questions that matter most; grow the model only when the next decision demands it.

With Kenya's mobile-first scale and cost realities, we optimise for query performance and predictable spend — ensuring the warehouse answers in seconds without runaway cloud bills.

06

Data quality: trust enough to decide on

Trust is earned at the pipeline, not asserted on the dashboard. We bake data quality checks into every stage so the number you see has been validated against reality before it reaches a decision-maker.

• Validation at ingestion — nulls, types, ranges, required fields and referential integrity checked as data lands.
• Deduplication by keys — transaction IDs, STK CheckoutRequestIDs, callback references and payment references deduplicated deterministically.
• Freshness SLAs — dashboards show data freshness clearly; alerts fire when a critical feed exceeds its SLA.
• Row-level tests — unit tests for transformations (e.g. rent collected = sum of confirmed payments for that period) catch regressions early.
• Anomaly guards — sudden spikes/drops in volume/value trigger alerts before the number becomes 'the official figure'.
• Lineage auditability — any number can be traced back to source rows in minutes, not reconstructed over days.

For a platform handling real money (wallets, floats, fees), these checks are not optional — they are the difference between a report you act on and one you argue about.

07

Dashboards: answers, not artefacts

Dashboards succeed when they answer the question in under five seconds and point to the next action. We design for the person who needs the answer at 8:01am, on a mobile device, with limited time.

• Role-specific views — owners see collections, float and revenue; managers see arrears and occupancy; staff see operational queues — each sees only what they need to act.
• Mobile-first — responsive layouts that work well on phones (critical in Kenya, where decisions often happen on mobile).
• Single-number clarity — the primary KPI is obvious at a glance; drilldowns exist for investigation, not to bury the answer.
• Context with the number — show target, trend, variance (absolute and %) and data freshness so interpretation is immediate.
• No vanity metrics — every tile must answer a decision; decorative counters are removed unless they drive action.
• Consistent definitions — 'collected', 'arrears', 'balance due', 'revenue' are defined once in the warehouse and reused everywhere.

We build dashboards that save time, not create more tabs. If a user has to export to Excel to answer 'why?', the dashboard has failed.

08

Reporting: land without being chased

Reports should arrive on time, in the right format, to the right people — automatically. We automate scheduled reports (PDF/CSV/Excel) with consistent filters and branding, so nobody is chasing someone for 'last month's collections' every first week.

• Scheduled delivery — daily/weekly/monthly reports emailed or pushed to recipients on schedule, with retry on failure.
• Recipient scoping — property managers see only their properties; finance sees company-wide; each gets exactly what they need.
• Parameterised and consistent — same filters, same period definitions and same column names across every run.
• Export-ready, audit-ready — CSV/Excel for analysis, PDF for sharing; every export includes generated-at timestamp and source reference.
• Drillable references — report lines include transaction/property IDs so recipients can jump to the underlying record.
• Failure alerts — if a scheduled report fails, the owner is alerted before the deadline passes.

Automated, reliable reporting frees people to act on numbers instead of assembling them every cycle.

09

Forecasting: see what is likely, act while there is time

Descriptive analytics tells you what happened; predictive analytics tells you what is likely to happen while you still have room to influence it. We build forecasts grounded in your actual history, not optimism.

• Grounded in history — models trained on real transaction, collection and occupancy history, not assumptions.
• Collections forecasting — projected rent collections by property/portfolio with confidence ranges, to plan cash flow.
• Churn and arrears risk — leading indicators flag tenants at risk of falling behind, enabling early intervention.
• Demand and occupancy — forecast vacancies and lease expiries to time marketing and reduce voids.
• Explainable, not black-box — we favour simple, explainable models so stakeholders trust and can reason about predictions.
• Human-in-the-loop — forecasts inform decisions; owners can adjust assumptions and see the impact transparently.

Our approach is pragmatic: forecast what matters for cash flow and operations, with clear uncertainty ranges — because 'likely KES 2.1M–2.3M' is more useful than a single precise number pulled from thin air.

10

Anomaly detection and alerting: catch drift early

The best analytics do not wait for month-end review — they flag the moment something drifts. We detect unusual patterns in volumes, values and success rates and alert the right person before variance becomes a surprise.

• Volume and value anomalies — sudden drops/spikes in payments, top-ups, withdrawals or collections flagged automatically.
• Success-rate drift — STK success rates, callback completion rates or pipeline job failures detected against recent baselines.
• Time-series baselines — compare to same-day-of-week, seasonality and rolling averages to reduce false positives.
• Alert routing by role — finance alerted on float/collection anomalies, ops on pipeline/feed failures, owners on material variances.
• Actionable alerts — alerts include what changed, by how much, when it started and a link to the relevant dashboard for investigation.
• Alert fatigue controlled — thresholds tuned to materiality; alerts are actionable or they are suppressed.

These alerts mirror how we monitor money paths on KodiiPay: catch the drift early, reach the owner before it becomes an incident, and give them the context to act immediately.

11

Metrics, KPIs and definitions that do not drift

If 'revenue' means three different things across three reports, decisions fracture. We treat metric definitions as code: versioned, documented and enforced in the warehouse so every surface uses the identical calculation.

• Canonical metrics — core KPIs (Gross Collections, Net Collections, Arrears, Float, Platform Revenue, Churn, Occupancy) defined once in dbt/transform layer.
• Documented definitions — every metric includes formula, filters (what is excluded/included), effective date and owner.
• Versioned changes — definition changes are versioned with a changelog so historical reports remain comparable.
• Time-period consistency — billing month, calendar month, rolling 30/90 days defined uniformly across dashboards.
• Avoid double-counting — idempotent aggregations and distinct-by-reference prevent inflating numbers on retries or replays.
• Finance-grade accuracy — metrics that touch money follow the same reconciliation discipline: tie back to ledger/transactions.

Consistent definitions mean finance, ops and management argue about actions, not about which spreadsheet column was used.

12

Data governance, privacy and access control

Analytics must be useful without becoming invasive. We design with least privilege, PDPA-aligned principles and auditability so access is appropriate and data use is transparent.

• Least privilege by role — Row-Level Security (RLS) and column-level restrictions ensure staff see only the properties/tenants relevant to them.
• PII minimisation — expose aggregates where possible; mask or omit PII on broad operational dashboards; grant granular access only when necessary.
• Audit trails for access — data exports, sensitive report views and permission changes are logged for auditability.
• Data retention policy — define retention by data class; purge or archive in line with policy and legal requirements.
• PDPA/ Kenya context awareness — respect consent, purpose limitation and data subject access considerations in reporting design.
• Secure sharing — report links expire, require auth where sensitive, and scheduled exports go only to authorised recipients.

We treat governance as an enabler of trust — not bureaucracy — so stakeholders can rely on data without compromising privacy or security.

13

Search, segmentation and slicing

Good analytics lets you slice by what matters to your business. We build flexible filtering and segmentation so owners can answer 'by property, by manager, by ward, by month' in a couple of clicks.

• Faceted filtering — slice by property, portfolio, manager, unit type, status, payment method (M-Pesa/Daraja, PayPal, Stripe, PayStack, card, bank transfer, wallet) and time period.
• Dynamic date ranges — preset ranges (Today, This Month, Last 30/90/365, YTD) plus custom ranges that behave consistently.
• Cross-filtering — selecting a segment updates related charts to the same filtered set (one source of truth per view).
• Cohort analysis — track tenant cohorts (move-in month) for arrears/retention trends over time.
• Geographic slicing — county/sub-county/ward where relevant for portfolio performance (Kenya context).
• Saved views — power users can save filtered views and share them with their team.

Slicing must be instant. We model dimensions to keep filter responses sub-second, even as portfolios and transaction volumes grow.

14

Cost, performance and scale

Analytics that are correct but slow or prohibitively expensive will not be used daily. We engineer for predictable performance and cost from day one — especially important in Kenya's cost-conscious operating environment.

• Incremental models — transform only new/changed data to cut compute time and cost.
• Materialisations chosen by usage — tables/views/materialised views chosen per query pattern (tables for heavy reads, views for light drilldowns).
• Query result caching — cache expensive dashboard queries with appropriate freshness windows.
• Partitioning/clustering — prune large fact tables by date/business key so scans stay small.
• Cost visibility — track warehouse spend per environment/project; alerts on unexpected spikes.
• Scale to millions — design for ledger/transaction volumes in the millions without dashboard response times degrading.

Performance and cost are design outputs. We right-size compute, avoid full-table scans on hot dashboards and keep monthly spend predictable as usage grows.

15

Integration: analytics that plugs into your stack

Analytics must integrate cleanly with the systems that act on it — CRMs, accounting, payment platforms, property management and messaging. We expose data where it is useful, without breaking governance.

• BI tool flexibility — support Metabase, Power BI, Superset, Looker Studio or embedded charts without re-engineering the warehouse.
• API access to metrics — serve key KPIs via read-only, rate-limited APIs for embedded dashboards or mobile surfaces.
• Exports and webhooks — push alerts/reports to Slack/Email/Teams or trigger workflows when thresholds are crossed.
• Accounting alignment — structure revenue/fee/float metrics to reconcile cleanly with accounting exports (no orphan numbers at month-end).
• Payments-aware joins — natively relate transactions across every rail (M-Pesa/Daraja, PayPal, Stripe, PayStack, cards, bank transfers) to wallet ledgers, billers and payouts without manual stitching.
• Zero-copy where possible — read from governed warehouse/models to avoid duplicating truth across systems.

Because we live inside a payments platform, our analytics integrate naturally with ledgers, floats and reconciliation — reducing the manual reconciliation work that plagues many businesses.

16

How we build analytics projects

We follow a pragmatic, decision-first process that ships usable analytics quickly and hardens trust over time — without boiling the ocean.

• 01 · Discovery — identify the 3–5 decisions that matter most this quarter and the metrics that must change behaviour.
• 02 · Data audit — map sources (DB, files, payment callbacks from M-Pesa/Daraja and partner gateways, ledgers), identify quality gaps and required lineage.
• 03 · Modelling — design facts/dimensions, define canonical KPIs and document each definition.
• 04 · Pipelines — build incremental, idempotent ELT with validation, tests and lineage.
• 05 · Warehouse — model cleanly, partition/clustering, add quality checks and freshness SLAs.
• 06 · Dashboards & reports — role-based, mobile-first, with context (target/trend/variance/freshness).
• 07 · Forecasting & alerts — add baselines, anomaly detection and actionable alert routing.
• 08 · Governance — RLS, PII minimisation, audit logs, retention and access reviews.
• 09 · Testing & QA — reconciliation checks (tie numbers to ledger), transformation tests, end-to-end freshness.
• 10 · Rollout & training — onboard owners, document usage, embed into weekly rhythms.
• 11 · Cost/perf tuning — incremental builds, caching, right-sizing and spend monitoring.
• 12 · Iterate by decisions — measure whether dashboards changed decisions; prune unused tiles and add only what drives action.

We ship the smallest slice that changes a decision this week, then iterate. This keeps value visible early while building the governed foundation that scales.

17

Honest limits of analytics

Analytics is powerful — and we are transparent about what it can and cannot do. These honesty points keep expectations realistic and the solution useful:

• Bad source data stays bad until fixed — no dashboard can magically correct broken upstream systems; we fix at source or validate hard at ingestion.
• Prediction has uncertainty — forecasts are ranges with confidence; we never present a precise point forecast as certainty.
• Not every question needs ML — simple SQL aggregations answer most operational questions faster, cheaper and more explainably.
• Alerts create noise if untuned — alert fatigue is real; we tune thresholds to materiality and require alerts to be actionable.
• Timeliness costs money — near-real-time costs more than batch; we choose freshness by the decision's urgency, not defaulting to streaming.
• Data quality is continuous — definitions drift, feeds break, schemas evolve; governance and tests must run continuously, not once.
• Dashboards decay — unused tiles accumulate; we prune regularly so the view stays focused on decisions that matter.

We will tell you when a question does not need a new model or real-time pipeline — and give you the simplest, correct answer. When it does need depth, we build it to the standard above.

The toolchain

The data analytics toolchain

The tools we use are chosen for correctness, auditability, cost control and maintainability — the same priorities we apply to our live payments platform. We favour tools that keep business logic testable and lineage clear.

Lifecycle

Data analytics lifecycle

We ship decision-changing analytics in small slices, then harden for trust, performance and scale.

Closing

More than development

We build analytics that drive action, not decoration — engineered with the same discipline we apply to money-moving systems in production:

Analytics is only valuable when it changes a decision. Everything above exists to make that true — consistently, traceably and affordably.

Trust the number, trace the number, act on the number — in time to matter.