Technical note
What Analytics Engineering Is Really For
Analytics engineering is often explained through tools.
dbt. Dataform. Snowflake. BigQuery. Airflow. Git. CI/CD. Semantic layers.
Those tools matter, but they are not the point.
The point is business logic that can be trusted.
When a leadership team asks for revenue, margin, churn, pipeline, conversion, cost to serve, or forecast accuracy, the business needs more than a query that runs. It needs a number with enough trust signals around it to be safe for a decision.
That is what analytics engineering is really for.
It turns raw operational data into governed, tested, documented, and reviewable reporting assets. The purpose is not prettier dashboards. The purpose is less decision drag, fewer repeated reconciliations, and a lower Invisible Data Tax.
In the Brightside Bikes case study, this is the difference between having Shopify, Stripe, HubSpot, GA4, ad-platform exports, inventory files, and a board spreadsheet, and having a weekly operating report that leadership can actually use without relitigating the numbers.
The symptom: technically live, commercially untrusted
Many growing companies already have a modern data stack.
They have a warehouse. They have dashboards. They have a BI tool. They may have pipelines, scheduled refreshes, and analysts writing SQL.
But the numbers still do not match.
Finance has one version of revenue. Growth has another. The board pack has a manually adjusted version. Shopify has a trading view. Stripe has a settlement view. The dashboard has a number that looks official but is quietly ignored in the meeting.
The data platform is technically live.
The reporting system is commercially untrusted.
This is the gap analytics engineering should close.
Analytics engineering is the industrialisation of business logic
In a small company, business logic often lives in people’s heads, spreadsheets, saved BI calculations, and one-off SQL queries.
That can work for a while.
Then the business grows. Systems multiply. Definitions change. Teams specialise. Leaders need the same metric in multiple contexts. Manual adjustments become normal. The person who understands the caveat is not always in the room.
At that point, informal logic becomes expensive.
Analytics engineering takes that logic and gives it an operating model:
- Business definitions are translated into explicit models.
- Source systems are declared rather than assumed.
- Transformations are version controlled.
- Tests catch common failures before users do.
- Documentation explains meaning, grain, caveats, and ownership.
- Deployment makes changes reviewable instead of accidental.
- Lineage shows how a number moved from source to report.
That is the difference between a dashboard that happens to work today and a reporting asset the business can keep trusting.
The Reporting Trust test
A useful analytics engineering asset should pass a simple Reporting Trust test.
For an important metric, can the business explain:
- Where the number starts?
- Which definition is being applied?
- What grain the model uses?
- Which transformations change the number?
- Who owns the business meaning?
- Who owns the technical path?
- Which tests protect the number?
- When the number is fresh enough to use?
- Where similar numbers appear elsewhere?
If the answer is no, the issue is not just technical debt.
It is decision debt.
The business is carrying uncertainty into meetings. That uncertainty becomes checking, challenge, rework, and delay. In the language of the book, the company is paying the Invisible Data Tax.
Where the tools fit
The tools each handle part of the trust problem.
SQL expresses the logic. It joins, filters, groups, calculates, and reshapes operational records into business measures.
Data modelling decides what the business is measuring. It defines facts, dimensions, grain, time logic, and the boundaries between raw data, cleaned data, and decision-ready data.
dbt or Dataform makes transformation logic modular, documented, tested, and reviewable. Instead of logic being hidden in dashboards or copied across scripts, it becomes part of a managed project.
Airflow, Dagster, Prefect, dbt Cloud jobs, or warehouse schedulers make the timing and dependencies explicit. They help answer whether the number is complete, fresh, failed, late, or safe.
Git gives changes a history. It lets a team see when a metric changed, why it changed, who reviewed it, and how to revert if needed.
CI/CD checks whether a change should be allowed to reach production reporting. It moves quality control earlier, before the leadership meeting finds the issue.
None of these tools guarantee trust by themselves.
They are useful when they support a clear reporting contract: what the metric means, when it should be used, who owns it, and which caveats matter.
What analytics engineering should remove
Good analytics engineering removes avoidable ambiguity.
It should reduce the number of places where the same business rule is manually recreated. It should make it harder for two dashboards to use different definitions without anyone noticing. It should make freshness, lineage, and ownership visible enough that users do not need to chase analysts in Slack before every meeting.
It should also reduce shadow reporting.
Shadow reporting appears when people quietly rebuild reports outside the trusted system because the official system is too slow, unclear, incomplete, or hard to reconcile. It is a trust signal in reverse. It tells you the current reporting path is not meeting the decision need.
The fix is rarely “ban spreadsheets”.
The fix is to understand why the spreadsheet is trusted and the dashboard is not.
Analytics engineering should then move the useful logic upstream, make the caveats visible, and protect the metric with tests and review.
What to inspect first
Start with one disputed metric.
Do not begin by documenting the entire warehouse or debating the ideal architecture. Pick the number that creates the most meeting friction.
Ask:
- How many places define this metric?
- Is the definition written down in business language?
- Does the SQL match that definition?
- Is the grain explicit?
- Are manual adjustments part of the official path or a workaround?
- Are tests checking the failure modes that would mislead users?
- Can someone trace the number from source system to final report?
- If the definition changed tomorrow, how many places would need updating?
The last question is especially revealing.
If changing one definition requires edits across dashboards, spreadsheets, SQL files, and manual pack adjustments, the company does not have one reporting contract. It has many fragments of logic.
That is where analytics engineering earns its place.
What good looks like
Good analytics engineering does not mean every metric needs a complex platform.
It means the important numbers have a reliable path.
For a high-value KPI, good looks like this:
- The business meaning is agreed.
- The source system and timing rules are known.
- The model grain is explicit.
- Transformations are version controlled.
- Tests protect obvious failure modes.
- Documentation explains caveats and intended use.
- The dashboard uses governed logic rather than recreating it.
- Changes are reviewed before they affect decision workflows.
That is not bureaucracy. It is the practical infrastructure behind Reporting Trust.
For Brightside Bikes, that might mean separating Shopify Net Revenue from Finance Revenue, keeping a visible revenue bridge between them, and making sure the Weekly Operating Performance Report says which number is safe for which decision.
The real purpose
Analytics engineering is not about replacing analysts with software engineering rituals.
It is about giving business logic enough structure to survive growth.
As companies scale, the cost of unclear reporting rises. More teams depend on the same numbers. More tools consume the same models. More leaders use metrics to make faster decisions. AI and automation raise the stakes again, because weak definitions can be repeated at machine speed.
The role of analytics engineering is to make that logic inspectable, testable, and safe enough to use.
If your business numbers do not match, analytics engineering is not the whole answer. You still need ownership, agreement, and decision context.
But it is the technical operating discipline that keeps those agreements alive in the data.