7 things to weigh up on analytics foundations framework

Most analytics frameworks are lists of components. That is not useful on its own. Knowing you need a warehouse and a BI tool does not tell you what to do on Monday.

The analytics foundations framework here is about order. Its central claim: you design top-down from the decision, and you build bottom-up from the data.

Teams that reverse this, building upward from whatever data they have and only later asking what it is for, get a stack that works and a business that ignores it.

Seven things to weigh up when you adopt it: decision clarity, definition precision, collection feasibility, storage and model ownership, delivery fit, feedback discipline, and scope or sequence.

What to take away

The seven things to weigh up

Read the middle column downward when you are planning. Read the right column upward when you are building. Every project passes through all six layers, and the seventh thing to weigh up is how much of each layer to build now.

A worked support-team pass through all seven things appears later in this article, with a finance example alongside.

Why the direction matters

Design top-down because every layer below the decision exists only to serve it. If you start at collection, you get a schema that reflects how your systems happen to be built rather than how your business makes choices, and translating between the two becomes a permanent tax.

Build bottom-up because each layer inherits everything wrong with the one beneath it. A dashboard built on an unmodeled table inherits its duplicates. A modeled table built on incomplete collection inherits the gap. You cannot fix a collection problem in the visualization layer, though many teams spend months trying.

The practical consequence: the first thing you produce for a stakeholder should be small and complete through all six layers, not a full build of one layer. One decision, served end to end, teaches you more than a comprehensive data model serving nothing.

What each of the seven things requires

Decision. Write it as a sentence with a verb and a frequency. 'Each week, the support lead decides where to move staffing.' Not 'we want visibility into support.' If you cannot write the sentence, you are not ready, and discovering that early is the highest-value output of this layer.

A marketing variant: 'Each Friday, the demand generation manager decides where the next test budget goes.'

Zendesk and Salesforce Service Cloud both store ticket data, but neither tells you which staffing decision matters.

Definition. State the metric fully enough that two people would compute it identically: the entity counted, the qualifying condition, the window, the timezone, the exclusions, and the source it must come from. This is where most later disputes are prevented, and it costs an hour. A written definition in dbt or LookML can enforce it.

Collection. Confirm the underlying fact is actually recorded somewhere, at the grain you need, with a reliable timestamp and a key you can join on. Half of all analytics projects die here, quietly, when someone discovers the event was never captured or cannot be attributed to an account. Check this before promising anything.

Storage and model. Land the raw data centrally, in a warehouse or its equivalent, then build one modeled table that implements the definition, with tests on it: unique keys, no unexpected nulls, row counts within a plausible range, freshness. The model is where the logic lives so that no consumer has to reimplement it.

Google BigQuery gives 1 TiB of query per month free, then on-demand queries typically cost $6.25 per TiB in US regions. Snowflake bills per second after one minute, with Standard edition around $2 per credit in AWS US East. dbt Core is free and open source, and dbt Cloud has a free Developer plan plus paid Team seats.

Delivery. Match the mechanism to the decision. A weekly decision needs a report or a page someone visits weekly. A decision that must happen within minutes of a threshold being crossed needs an alert, not a dashboard: nobody watches a screen reliably. A decision made inside another system needs the number pushed into that system.

Looker Studio is free for dashboards. Tableau Creator typically costs $75 per user per month. Microsoft Power BI Pro is $14 per user per month.

Feedback. Return a few weeks later and check whether the decision changed. This is the layer that is almost always skipped, and it is the only one that tells you whether the previous five were worth doing.

A decision log in Notion gives you something to check against.

Scope and sequence. This is the seventh thing. Ask what the smallest complete loop is. A support team can start with one queue, one metric, one weekly report, and four weeks of history.

Gates: how to know a layer is done enough

Each gate is a question with a yes-or-no answer. Do not proceed on a maybe.

Failing an early gate is cheap. Failing a late one means rework through every layer above it, which is why the gates get progressively more expensive to ignore.

Diagnosing where you actually are

Teams rarely fail evenly. Find your weakest layer by matching the symptom:

Fix the weakest layer rather than the most interesting one. Investment above a broken layer does not compound; it just accumulates.

A worked pass through all seven things

Take a support team deciding weekly where to put coverage.

A finance team runs the same loop for a monthly reforecast. The controller decides each month where to shift spend, the definition fixes net revenue recognition, the model lands one tested table, and delivery is a page the controller opens before the close. Effort is comparable to the support case, typically two to four weeks for a first pass.

Zendesk or Freshdesk can be the source, BigQuery or Snowflake can hold the table, and Looker Studio or Power BI can show the view. The whole thing is small. That is the point.

Related reading on this site

For failure modes when order is ignored, see analytics foundations mistakes, and for writing the definition layer properly, see analytics foundations metrics.

The pillar overview is analytics foundations.

For the analysis sequence inside the definition and delivery layers, see how to work through a question, and for the function these six layers are usually built for, see business intelligence.

Common questions

Does every project need all six layers?

Every project passes through them; not every project needs new work at each one. A second decision served from an existing model skips most of the middle. That is exactly the compounding you are building toward.

What is the seventh thing to weigh up?

Scope. Ask how little you can build and still serve one decision end to end. A weekly support staffing decision needs one queue, one metric, four weeks of history, and a page the lead opens Monday.

What if the decision-maker cannot articulate the decision?

Watch them work instead of asking. Sit through the meeting where the choice gets made and note what people argue about. The argument is the decision, and the thing they lack evidence for is your metric.

How does this fit with a formal maturity model?

Maturity models describe where an organization sits; this describes what to do next. Use whichever helps, but be wary of any effort that spends more time assessing the stage than serving a decision.