What I Look For in a Data Platform Audit

A data platform audit is not just a technical review.

It is a way to understand whether the company's data foundation is helping or slowing down decision-making.

The most important question is not:

"Is the stack modern?"

The better question is:

"Can the company reliably use data to understand customers, product, revenue, risk, and operations?"

A modern data stack can still produce confusion. A simple stack can still support good decisions.

The audit should reveal the difference.

1. Trust in numbers

The first thing I look for is whether people trust the data.

Signs of low trust:

• different teams report different numbers for the same metric;
• executives ask for manual validation before using dashboards;
• analysts spend too much time reconciling definitions;
• business users export data to spreadsheets and rebuild their own views;
• nobody is sure which dashboard is the source of truth.

Data trust is not only a quality issue. It is an operating issue.

If people do not trust the numbers, they will not use them for decisions.

2. Metric definitions

A company can have good pipelines and still have bad metrics.

I look for whether core metrics are clearly defined:

• What exactly is an active user?
• What counts as activation?
• What is the revenue definition?
• What is the difference between gross and net revenue?
• How is churn calculated?
• What is the unit of analysis: user, account, customer, company, transaction?
• Are test/internal users excluded?
• Are definitions versioned and documented?

The most dangerous metrics are the ones that look obvious.

"Revenue," "active user," "conversion," "retention," and "churn" are rarely as simple as they sound.

3. Metric trees and business logic

After definitions, I look for structure.

A company needs to know how its metrics relate to each other.

For example:

• growth depends on acquisition, activation, retention, and expansion;
• revenue depends on customer volume, usage, pricing, mix, and quality;
• product engagement depends on user intent, onboarding, frequency, and feature adoption;
• operational performance depends on volume, capacity, automation, and exceptions.

Without a metric tree, leadership sees numbers but not the system.

A good metric tree makes discussions more precise. It helps people understand whether a problem is caused by demand, conversion, behavior, pricing, retention, operations, or data quality.

4. Data modelling

Then I look at the models underneath the dashboards.

Questions I ask:

• Are models organized around business concepts or source-system tables?
• Is there a clean semantic layer?
• Are facts and dimensions clear?
• Are transformations understandable?
• Can a new analyst safely extend the model?
• Are important assumptions visible?
• Is business logic duplicated across dashboards?

Many BI problems are actually modelling problems.

If every dashboard contains its own hidden logic, the company will eventually lose control of its metrics.

5. Reliability and freshness

Not every dataset needs to be real-time.

But every dataset needs expectations.

I look for:

• freshness requirements;
• pipeline failure rates;
• retry logic;
• alerting;
• data quality checks;
• late-arriving data handling;
• incident history;
• ownership of failures.

A daily executive dashboard does not need streaming infrastructure.

But it does need to be correct when leadership opens it.

6. Ownership

Every important dataset and metric needs an owner.

Not just a technical owner, but a business-aware owner.

I look for whether teams know:

• who owns the metric definition;
• who owns the pipeline;
• who owns the dashboard;
• who approves changes;
• who investigates anomalies;
• who communicates breaks or definition changes.

When ownership is unclear, trust decays slowly.

7. BI usage and decision usage

A dashboard with many views is not automatically useful.

I look for whether dashboards are connected to real decisions.

Useful questions:

• Which dashboards are used in leadership meetings?
• Which ones are ignored?
• Which ones create repeated questions?
• Which ones trigger action?
• Which ones are duplicated?
• Which ones are maintained only because nobody wants to delete them?

The audit should separate reporting inventory from decision infrastructure.

8. Data team workflow

The platform is not only technology. It is also how work moves.

I look at:

• intake process;
• prioritization;
• delivery lead time;
• stakeholder communication;
• ownership between analytics and engineering;
• review process;
• documentation habits;
• change management;
• recurring support load.

A data team can be technically strong but trapped in reactive reporting.

The audit should show whether the team is building leverage or constantly fighting fires.

9. Executive visibility

Finally, I look at what leadership can actually see.

Can the CEO or founder understand:

• what is growing;
• what is declining;
• which customer segments matter;
• where revenue quality is changing;
• where product behavior is improving or worsening;
• which operational constraints are emerging;
• which risks need attention?

If leadership cannot answer these questions from the current reporting system, the platform is not fully doing its job.

The output of a good audit

A useful data platform audit should not end with a long list of technical complaints.

It should produce a practical roadmap.

The output should include:

• current-state diagnosis;
• key trust and reliability issues;
• metric definition gaps;
• BI/reporting problems;
• modelling and platform risks;
• governance and ownership gaps;
• quick wins;
• deeper architectural recommendations;
• a prioritized 30/60/90-day plan.

The goal is not to make the stack more impressive.

The goal is to make the company clearer, faster, and more reliable in how it makes decisions.

Final thought

A data platform is not valuable because it contains data.

It is valuable when it helps the company understand reality and act on it.

That requires more than pipelines and dashboards.

It requires a decision spine: trusted metrics, reliable models, clear ownership, and reporting systems connected to the way the company actually operates.