How to write a one-page analytics brief

Someone pings you: “Can you pull the numbers on churn for the board deck?” You open three systems, invent a definition under pressure, and ship a chart that answers a question nobody agreed on. The meeting argues about the number instead of the decision. Everyone leaves tired. You get another Slack at 6:40 p.m.

This post is a practical companion to What problem are we actually solving? in Analytics foundations. You will leave with a one-page analytics brief you can paste into a ticket, a doc, or a sticky note, plus the scripts to get stakeholders to fill it without a fight.

What you’ll learn

Example:

• Why vague asks create expensive “analysis theater”
• The eight fields of a one-page brief (steal the template)
• How to run a five-minute intake when someone is in a hurry
• A filled example you can copy for board, product, and ops asks
• What “done” looks like before you write a single query

Why a one-pager beats a kickoff meeting

Meetings feel responsible. One-pagers feel bureaucratic. In practice the opposite is true. A short written brief forces the hard parts into the open: who decides, by when, what “good” looks like, and what you will ignore. If you cannot finish the page, you do not have an analytics problem yet. You have a vibe.

The brief is not paperwork for its own sake. It is a contract for uncertainty reduction. Your job is to make a decision clearer, cheaper, or safer. The page is how both sides agree what “clearer” means before you burn two days in the warehouse.

The one-page template

Copy this into Notion, Google Docs, Jira, or a paper notebook. Keep it to one screen. If it grows past one page, you are designing a research program, not a request.

Field by field, in plain English

1. Decision owner

Name a human, not a committee. If three people must agree, list the final caller and the consultees separately. Analysis without an owner becomes decoration.

2. Decision

Write the choice as options. “Fund redesign / don’t,” “Prioritize segment A vs B,” “Investigate pipeline this sprint / next.” If there is no choice, you may be in curiosity work (fine), but label it that way and time-box it. See problem framing in foundations part 1.

3. Deadline

Two clocks matter: the decision clock and the analysis clock. Always anchor to the decision. “Need a first look by Monday so we can decide Thursday” is healthier than “need everything by Monday.”

4. Question

One sentence. Prefer a question you could, in theory, falsify. “Is after-hours share up more than 2 points vs last quarter?” beats “Tell me about tickets.”

5. Success shape

Describe the deliverable shape, not the tool: ranked list, before/after with caveats, forecast vs target, single metric with range. “A Tableau” is not a success shape. “A ranking of territories by cancel rate with revenue at risk” is.

6. Grain and window

Grain means what one row represents: one order, one customer-day, one ticket. Wrong grain creates fake trends. Window means which dates count, time zone, and lag. If you cannot finish these two lines, stop. This is where most “the numbers don’t match” fights begin.

7. Exclusions

Write the boring filters: test accounts, refunds, free trials, internal employees, bot traffic. Silent exclusions are how two honest analysts get two honest, different answers.

8. Confidence needed

Borrow language from Good enough vs perfect data: directional, good enough with caveats, or high trust. Match confidence to how reversible the decision is.

The five-minute intake (when they are in a hurry)

You will not always get a filled form. Run this verbally and type as you go:

1. “What will you do differently if the answer is A vs B?”
2. “When is that choice locked?”
3. “Who else must trust this number?”
4. “What does a good enough answer look like if perfect data is impossible this week?”
5. “What should we deliberately ignore?”

If they cannot answer (1), you are not late on analysis. You are early on product management. Offer to help name the decision, then schedule the data work.

Worked example: three briefs from one vague ask

Example:

Vague ask: “How are sales?” Three possible briefs. Same warehouse. Completely different work.

Writing the brief is how you discover which of these three worlds you are in before you open a SQL client.

Copy-paste blank (text version)

ANALYTICS BRIEF (1 page)
Owner: _______________
Decision (options): _______________
Deadline: _______________
Question (1 sentence): _______________
Success shape: _______________
Grain (one row = ): _______________
Time window + lag: _______________
Exclusions: _______________
Confidence needed: directional / good enough / high trust
Risk if wrong: _______________
Out of scope (explicit): _______________
Next check-in: _______________

How the brief feeds the analytics loop

In The analytics loop, you move question → data → transform → answer → decision → measure again. The brief is the entrance ticket to that loop. It also sets up better numbers reading later: rates vs counts and baselines from Reading a number like an adult only matter once the question is sharp.

Common mistakes with briefs

• Filling the template alone and never confirming with the owner
• Writing “dashboard” as the decision
• Skipping grain because “we all know what an order is” (you do not)
• Demanding high trust for a reversible test
• Leaving exclusions blank, then arguing about them in the results meeting

How to practice this week

1. Take the last three analysis requests you got. Retroactively fill the brief. Notice the blanks.
2. Pick one upcoming ask. Fill the brief with the stakeholder in five minutes.
3. Save a blank brief as a team template. Put the link in your Slack status if you are brave.
4. After you deliver, write one line: “Did the decision change?” That is your quality score.

When the stakeholder pushes back on process

You will hear: we do not have time for a form. Translate that honestly. Sometimes they mean the decision is on fire. Sometimes they mean they have not thought about the decision yet and hope the data will invent one. Your job is not to be difficult. Your job is to protect both of you from a rework loop.

Try this script: I can start pulling in ten minutes. I just need four answers so I do not pull the wrong thing: who decides, what the options are, when it locks, and what a good enough answer looks like. If we skip that, we usually redo the work after the meeting. Most people will fill four fields when the alternative is a redo. The rest of the brief you can draft and confirm later.

If they still refuse, document the refusal in one line on the brief: Owner declined to specify decision; treating as exploratory, two-hour cap. That sentence is not passive-aggressive. It is scope control. Curiosity projects are allowed. Unbounded mystery work dressed up as a board deliverable is not.

From brief to first query without losing the plot

Once the page is full, your first technical moves are boring on purpose. Confirm the table and grain exist (or note that they do not). Write the exclusion filters as comments in SQL or a checklist in the notebook. Produce the success shape only (ranking, trend, before/after), not twelve extra tabs. Attach the brief to the deliverable so the room cannot forget the decision.

-- Brief: after-hours ticket share, last 12 complete weeks
-- Grain: one support ticket
-- Decision: night-shift coverage yes/no (owner: Sam)
-- Exclusions: spam, internal test accounts
SELECT
  DATE_TRUNC('week', created_at) AS week_start,
  COUNT(*) FILTER (WHERE EXTRACT(HOUR FROM created_at) >= 20) AS after_hours,
  COUNT(*) AS all_tickets,
  ROUND(
    100.0 * COUNT(*) FILTER (WHERE EXTRACT(HOUR FROM created_at) >= 20)
      / NULLIF(COUNT(*), 0),
    1
  ) AS after_hours_pct
FROM support.tickets
WHERE created_at >= CURRENT_DATE - INTERVAL '12 weeks'
  AND is_spam = false
  AND is_internal_test = false
GROUP BY 1
ORDER BY 1;

Notice how much of the query is comments that came from the brief. That is the point. The brief becomes documentation that travels with the code, not a sticky note you lose. Over a quarter, teams that insist on briefs ship fewer charts and more decisions. That is the only scoreboard that matters for an analytics function that wants to keep its reputation.

Team habits that make the template stick

Put a blank brief link in your team wiki and in the analytics request form. Refuse priority P0 labels without a decision deadline. Review one shipped analysis per month: did the decision change? Was the brief accurate? Celebrate shorter scopes. We killed a vague ask in twelve minutes is a win, not a failure to be helpful. The template only works if the social contract around it is real.

Quick recap

A one-page analytics brief turns fuzzy asks into decision-ready work. Name the owner, the choice, the deadline, the question, the success shape, the grain, the exclusions, and the confidence. If the page will not fill, do not open the warehouse yet. Talk first. Query second.

Related: foundations series, All About KPIs, and the traps companion post if you want a short list of ways clean numbers still mislead.

Sources

• Hubbard, Douglas W. How to Measure Anything (measurement as reducing uncertainty for decisions): https://www.howtomeasureanything.com/
• Analytics Made Simple, Analytics foundations (problem framing, loop, good enough data, reading numbers)
• DAMA-DMBOK concepts of data ownership and definition (why “who owns the metric” belongs on the brief): https://www.dama.org/cpages/body-of-knowledge

Merch on Etsy

Open store →

Data Science T-Shirt View on Etsy → Mean Squared Error Shirt View on Etsy → Y-Hat Coffee Mug View on Etsy → Sigmoid Function Shirt View on Etsy →