Numbers the whole company agrees on.
A warehouse, a metrics layer where every definition is written down once, and dashboards built around the question somebody actually asked in the meeting.
- One definition
- per metric, written down
- Self-serve
- answers without a ticket
- Checked
- quality tests in the pipeline
Who this is for
You probably need this if…
01
Every question becomes a ticket
Somebody wants a number, an engineer writes a query, and three days later the meeting it was for has already moved on without it.
02
Two dashboards disagree
Both are technically correct, because the same word was defined differently in each, and now nobody trusts either of them.
03
The report is a month behind
By the time the number arrives, the decision it was meant to inform has already been made on somebody's instinct.
What this covers
The work, in detail.
7 capabilities
01
Data warehousing
A single place the reporting reads from, so an expensive analytical query cannot slow down the software people are trying to use.
02
Metrics layer
Every definition written once and shared. “Active customer” should not quietly mean three different things in three departments.
03
Dashboards
Built around the decision somebody makes weekly, rather than around every column that happened to be available in the table.
04
Self-serve analytics
Models and documentation that let a non-engineer answer their own question without opening a ticket and waiting two days for it.
05
Pipeline quality
Freshness, volume and null checks that fail loudly, because silently wrong data is considerably worse than no data at all.
06
Experimentation
A/B infrastructure with the sample size worked out beforehand, so that results are conclusions rather than encouragement.
07
Executive reporting
The four numbers that genuinely run the business, delivered on a schedule, with a sentence on why each of them moved.
How we approach it
Positions we actually hold.
Opinions cost something to have. These are the ones we would argue for on your project, including where they make the work slower.
01
Define the metric before you chart it
Most disagreements about data turn out to be disagreements about definitions. Write them down first and the dashboards stop contradicting each other.
02
Analytics reads from a copy
Reporting never queries the production tables customers depend on. One heavy query at month end should not be able to slow down checkout.
03
Data quality checks are tests
Freshness, row counts and nulls get asserted in the pipeline. Data that fails should stop rather than flow through and quietly get charted.
04
Fewer dashboards, used more
Forty unopened dashboards are worse than four that get used. We build for the decision and then delete the rest without ceremony.
Technology
What we work with.
Defaults, not requirements. If you already run something else and have a team who knows it, we work in yours.
- Warehouse
- PostgreSQL, BigQuery, DuckDB
- Modelling
- dbt, SQL, versioned definitions
- Visualisation
- Metabase, Looker Studio, embedded charts
- Quality
- Freshness and volume tests, alerting on failure
Where this shows up in delivery
- Reporting on live usage runs through a read model rather than querying the tables that serve customers.
- Metric definitions on our software live in version control beside the code, so a change to one is reviewed like any other change.
- We have replaced manual monthly spreadsheets with scheduled, checked reporting on delivery work.
Bought as part of
This practice is never sold on its own. It is quoted inside one of the engagements above, as part of a single number.
Proof
Where we have actually done this.
Projects we designed, shipped and wrote up. Each one names the decision that was genuinely hard to get right.
Questions
What people ask about analytics & insight.
- Do we need a warehouse, or is our database enough?
- At your size the database is usually enough, with a read replica for reporting. A warehouse earns its place when you need to join data across several systems, and not before that.
- Can you connect data from different systems?
- That is most of the work. The extraction is straightforward; agreeing what a customer is across four systems is the hard part and the valuable one.
- Who maintains the dashboards afterwards?
- You can, and we build so that you can: documented models, plain SQL, no proprietary layer in the middle. If you would rather we kept them, that sits in a retainer.
- How do you handle sensitive data in reporting?
- Masked or aggregated at the model layer, with access granted by role. Analysts see what they need for the question and not a row more than that.
Related reading
Written on this, by us.
Data & Integration · 7 min read
The Same Number in Two Places
Your POS says one thing and your accounting package says another. Reconciling them is somebody's entire Monday. Here is why systems drift apart, and the boring job that keeps them together.
Data & Integration · 6 min read
Every Metric Means Three Things, and That Is Why Your Dashboards Disagree
Two reports, two answers, both technically correct. The problem is almost never the data. It is that nobody wrote down what the words mean.
Tell us what you’re trying to build.
Describe the problem in your own words. We’ll come back within one business day with a scope, a number and a date.
Phone
+1 (407) 796-2376Reply time
One business day, from an engineer
Based in
Orlando, Florida · serving the United States
What happens next
- A reply within one business day, from an engineer
- A thirty-minute call, with no qualifying call before it
- A written scope and a fixed number, if it fits