Mart Layer

Before stores were split into layers, everyone queried the source tables themselves. Anyone curious about paid revenue for the month joined the payments table to the accounts table and did the math. The trouble was that the rules for that math lived in people's heads. Whether to subtract refunds, whether charges during a trial count, whether to keep last month's payment from an account that has since cancelled — each person decided on the spot.

So three versions of the same month's revenue would show up at the Monday meeting: $37,000 from one person, $39,000 from another, $36,000 from finance. None of them were wrong. They had simply counted by three different rules. Half the meeting went to deciding which number to believe, and since nothing about the setup changed, the following month produced three numbers again.

The mart layer exists to nail that calculation down in one place. Put the revenue rule into a single table and the dashboard, the weekly report, and the investor deck all read from that table. Nobody recalculates, so nothing diverges. That is the main reason to divide a store into layers at all.

It sits furthest from the source data, which is exactly why it looks closest to the questions people ask. Tables in the raw layer keep whatever shape the source system produced, which is hard for a person to read. Tables in the staging layer are an intermediate state where formats have been reconciled but nothing has been reorganized. Mart layer tables are regrouped on top of that, one question at a time.

Tables here generally share four traits.

1. One row corresponds to one thing being analyzed. In an accounts table, a row is an account, and signup date, plan, lifetime revenue, and last login all sit in that single row.
2. Sources are already joined. Nobody using the table has to combine payments with session logs themselves.
3. The calculations are done. Values requiring a rule — lifetime revenue, months active — are already sitting in columns.
4. Columns are named in business language: account_status, not usr_stat_cd.

That's why this layer doesn't require a data analyst to touch. A marketer who wants retention by plan can filter the accounts table instead of joining five tables. The analyst's time then goes to questions nobody has asked before, rather than to reassembling the same joins for a different person each week.

What this layer is not is a source of record. It gets called a single source of truth, and that phrase means it's the reference for metric definitions — not that the values originate here. When a transformation rule turns out to be wrong, the place to go back to is the raw layer. Mart layer tables should be safe to drop and rebuild at any time.

Three things need to exist before tables here can carry real work.

First, metric definitions written down. A metric definition is the rule pinning down what gets counted and how. If "paid account" isn't documented as either an account with any payment ever or an account with a payment this month, whoever builds the table decides in the moment, and the three conflicting numbers come right back.

Second, visible freshness and failure. A mart table is usually rebuilt once a day, and when the overnight job fails, yesterday's values stay on screen looking perfectly normal. Showing the last refresh time next to the numbers and alerting on failure is the minimum condition for anyone to depend on this layer.

Third, a way to find what already exists. With forty tables and no catalog, a new person builds a forty-first. Near-duplicate tables erase the benefit of having layers in the first place. A one-line description per table and a named owner is usually enough to prevent that — the catalog does not have to be a tool.

Once those three hold, the next step is restructuring with dimensional modeling — splitting tables into a fact table that accumulates measurements and dimension tables holding the attributes you slice them by. Building one table per question works until the questions pass roughly twenty, and that's the point where teams move to this structure.

"Where did that number come from? Did you use the accounts table in the mart?"

Checking whether the reference table was used, to explain why two figures disagree.

"That isn't in the mart layer yet. You'll have to pull it from staging."

No curated table exists, so the calculation has to be done on intermediate data.

"Put that calculation in the mart table, not in the dashboard."

Write the rule once in a shared place instead of rebuilding it inside each screen.

At Pagedeck, Theo maintains the overnight refresh and Mia works from the accounts table it produces. In a month when a new plan launched, Mia reported that the plan wasn't showing up in the table, so Theo fixed the transformation rule in staging and rebuilt the mart table. The fix always lands on the rule that builds the table, never on the table itself — edit a table by hand and the next refresh erases it.

One common objection is that a separate mart layer doubles storage and work. The same data does get copied across layers, so it looks wasteful. What actually shrinks is human time. Five people rewriting the same joins and then reconciling results that came out different costs more than rebuilding one table once a day. Storage is also the cheapest thing in the stack, while the meeting spent arguing about which figure is correct is the most expensive.

The other mistake is treating more tables as better. Creating a table per request feels efficient for the first few months. The problem arrives with near-duplicates: account_summary, account_summary_v2, and account_summary_marketing sitting side by side, each defining paid accounts slightly differently, which lands the team back where it was before layers existed. The habit that keeps this layer usable is checking whether an existing table can be widened before adding a new one.