Software & TechnicalFree
Analytics Requirements vs Your Schema
River checks every question inside a request against the schema that exists, then marks each one answerable, answerable from a date, or not at all.
River's specification reads the request ticket beside your table definitions, column history and event catalogue, then splits the ask into the separate questions hiding inside it. Each one gets a verdict against the data that exists rather than the data somebody assumed. Out comes a document with the clarified question, the metric definitions it needs and the part that cannot be answered, plus a sheet holding the field-level specification: table, column, grain, filter and the check that proves it.
Page one for this query is nine blank forms. Problem statement, objective, audience, business questions, data sources, metric definitions, assumptions, out of scope, sign-off. Every section is a box for the analyst to fill in from the conversation, and the two boxes that matter, assumptions and out of scope, are filled in from memory by the person least likely to know. None of them opens the warehouse. A form cannot tell you that the column you are about to group by was overwritten last March.
Built for the analytics engineer holding a ticket that says build me a dashboard, the analyst who has been burned by shipping the wrong grain, and the data lead who wants the no said early and in writing. Run it when the request arrives, before any modelling, and again when a schema change lands underneath a dashboard somebody already trusts. Whether the request is worth specifying at all is a call the request intake process prices first. The definitions it settles on belong in a data dictionary, and the models behind them in pipeline documentation.
A column can read correctly and answer wrongly
The most expensive answer in analytics is the one that runs. A query grouping churn by onboarding path returns a tidy table whether or not the path column still holds the value it held when the account onboarded. Kimball's own description of the technique that overwrites it is blunt: a type 1 attribute always reflects the most recent assignment, and therefore this technique destroys history. Nothing in the result set says so. The numbers are the right shape and the wrong answer.
dbt's documentation shows the same loss in miniature. An order row whose status is rewritten from pending to shipped leaves you holding only the current state. In their words, we've lost the information about when the order was last in the pending state, and working out how long shipping took becomes impossible. Snapshots are the fix going forward. Going backward, the recovery is whatever audit or activity log happens to have kept the old value, and finding out which one is a twenty-minute job that saves a week.
Sometimes the history is not overwritten but deleted. A standard Google Analytics property lets you keep user-level data for two months or fourteen and nothing longer; the twenty-six, thirty-eight and fifty month settings are available only to 360 customers. A stakeholder asking for a two-year trend on pre-signup behaviour is asking for ten months that no longer exist on anybody's servers. That is not a modelling problem and no amount of engineering will fix it.
How it works
Paste the request
The ticket or the transcript, in whatever shape it arrived, including the parts that contradict.
Add the schema
Table definitions, column descriptions and the event catalogue. Partial is fine and gets said.
Read the verdicts
One row per question: answerable, answerable from a date, or not with what exists.
Send the no early
The document is written to be forwarded to the requester without a covering translation.
What you get
- Every question in the ticket separated out and given its own verdict against your schema
- Dimension columns checked for overwrite, because a grouped column can be current and wrong
- The date each unanswerable question becomes answerable, computed from when the event first fired
- A cell count for the requested slice, against the events available to fill it
- Words with two definitions in the warehouse flagged with the gap between them
- A field-level sheet: table, column, grain, filter and the check that proves each one
Common questions
We do not have documentation of our schema.
Table definitions and a column list are enough, and a warehouse can produce both in one query. Where a column's meaning is unclear the spec says so rather than guessing, and that line becomes the question to ask its owner. The unclear ones are usually the same columns the request depends on.
How would it know a column was overwritten?
From the shape of the table and the load pattern. A dimension with no valid from and valid to columns, loaded by merge, holds one row per key and therefore one version of the truth. Where an audit table or a snapshot exists, the spec names it as the recovery route and says how far back it goes.
Is this not just scope reduction with extra steps?
It cuts the opposite thing. A scoping pass drops what is expensive, and this drops what is not supported by the data, which is a different set. Time to first value survived the Bramfield spec because one unbuilt join answers it. The segment split was cut because 576 cells over 210 events is not a dashboard.
Our stakeholder will not accept no for an answer.
Which is why three of the four verdicts are not no. Two definitions with a 29% gap is a decision they get to make. A grain that cannot render is a coarser chart they still get. An event that started firing in August is a date, and a date is something a person can plan around. Specifying events before they are built is an instrumentation spec.
What about the questions nobody wrote down?
Those get pulled out too. One ticket is usually three to six questions wearing a single sentence, and the unstated ones carry the assumptions. Kill the paths that do not work assumes path is stable, churn has one meaning, and both hold for two years. All three were wrong at Bramfield.
What comes out at the end?
A document with each question, its verdict, the definitions it needs and what is not answerable, written to be forwarded rather than translated. Then a sheet giving table, column, grain, filter and validation check per field. The finished numbers go into an analysis write-up.
How does this differ from a metric definition?
A metric definition settles what a word means across the company and is owned by the business, which is a dashboard requirements spec. This settles whether your warehouse can compute one, and reports the gap when the same word already resolves two ways in two tables.
Analytics Requirements vs Your Schema
Fill in the form and your workspace opens with the work already underway.