Analytics foundations framework explained with examples

Most analytics frameworks are lists of components. That is not very useful, because knowing you need a warehouse and a BI tool does not tell you what to do on Monday.

The framework here is about order. It has one central claim: you design top-down from the decision, and you build bottom-up from the data. Teams that get this backwards (building upward from whatever data they happen to have, and only later asking what it is for), end up with a stack that works and a business that ignores it.

What to take away

• Read the middle column downward when you are planning.
• Each gate is a question with a yes-or-no answer.
• Take a support team deciding weekly where to put coverage.

The six layers

Layer	Design question (asked first, top-down)	Build artifact (delivered last, bottom-up)
Decision	What recurring choice does someone make, and how often?	A named decision with a named owner
Definition	What would have to be true or false to change that choice?	A precise metric definition, written down
Collection	Where does the underlying fact get created, and is it captured?	Instrumentation or a source-system connection
Storage and model	How do raw records become one clean, tested table?	A modeled table with tests and documentation
Delivery	How does the answer reach the person at the moment they decide?	A dashboard, report, alert, or system integration
Feedback	Did the decision actually change?	An observed behavior change, or a decision to stop

Read the middle column downward when you are planning. Read the right column upward when you are building. Every project passes through all six, whether or not you name them.

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.

Layer by layer

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.

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.

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.

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.

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.

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.

1. Decision gate. Can you name the person, the choice, and the cadence?
2. Definition gate. Would two people, given only your written definition, produce the same number?
3. Collection gate. Can you point at real rows in a real system that contain the fact, at the right grain?
4. Model gate. Does the table have tests that would fail loudly if the data broke?
5. Delivery gate. Does the answer reach the person without them having to remember to go and get it?
6. Feedback gate. Can you describe something that is now done differently?

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:

• "Nobody uses what we build." Decision layer. You built for a topic instead of a choice.
• "Two numbers disagree." Definition layer.
• "We cannot answer that with what we have." Collection layer.
• "Every analysis takes days and starts from scratch." Storage and model layer.
• "The answer exists but people did not see it in time." Delivery layer.
• "We ship a lot and nothing changes." Feedback layer.

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 six

Take a support team deciding weekly where to put coverage.

Decision: the support lead reallocates staffing each Monday. Definition: contacts received per hour-of-week, counting only customer-initiated conversations, excluding internal test accounts, in the team's local timezone, from the ticketing system's created-at timestamp. Collection: the ticketing system already records this; confirm the timestamp is creation rather than first-response, and confirm test accounts are identifiable. Model: one table, one row per hour-of-week per queue, with tests for uniqueness and freshness. Delivery: a single view the lead opens before Monday's planning, plus the prior four weeks for comparison. Feedback: after a month, ask whether the schedule changed and whether wait times moved.

The whole thing is small. That is the point. A narrow pass through all six layers produces a working loop; a broad effort at one layer produces inventory.

Related reading on this site

For the failure modes that show up when the order is ignored, see analytics foundations mistakes. For writing the definition layer properly, see analytics foundations metrics. The pillar overview is analytics foundations. For the analysis sequence that runs inside the definition and delivery layers, see how to work through a question, and for the function these six layers are usually being 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 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.