Framing business questions & KPIs

Most failed analytics projects fail at the start, not in the code. A manager says "sales are down, look into it" and the analyst spends a week producing charts nobody uses. The fix is to frame the question and agree on how success will be measured before you open a notebook.

From vague request to sharp question

A good analytical question is specific, measurable, tied to a decision and bounded in time. Compare:

Vague request	Sharp question
"Why are sales down?"	"Which stores and categories explain the 12% drop in July revenue versus July last year?"
"Are customers happy?"	"Did repeat-purchase rate within 60 days change after we raised delivery charges on 1 May?"
"Should we do a Diwali offer?"	"Did last year's 15% Diwali discount increase profit, or only shift purchases earlier?"

Always ask the stakeholder one follow-up: "What will you do differently depending on the answer?" If no decision changes, the question is not worth a week of work.

KPIs: metrics that matter

A metric is any number you can compute. A KPI (Key Performance Indicator) is a metric the business has agreed to steer by. Good KPIs are:

• Clearly defined — "revenue" net of GST and returns, or gross? Write it down.
• Owned — someone is responsible for moving it.
• Actionable — a team can influence it.
• Balanced — pair a growth KPI with a guardrail (orders up, but refund rate must not rise).

Build a KPI tree

Break a top-level goal into drivers you can actually investigate:

Monthly revenue
├── Number of orders
│   ├── Footfall / app sessions
│   └── Conversion rate
└── Average order value (AOV)
    ├── Items per order
    └── Average selling price (after discount)

If revenue falls, the tree tells you where to look first: fewer visitors, lower conversion, or smaller baskets.

Leading vs lagging indicators

Lagging KPIs (monthly profit, churn) tell you what already happened. Leading KPIs (cart additions, trial sign-ups, enquiries) move earlier and give you time to react. A good dashboard shows both.

Write the KPI as a query

A definition is only real once it is code that everyone runs the same way:

-- Average order value per month, excluding cancelled orders
SELECT DATE_FORMAT(order_date, '%Y-%m') AS month,
       COUNT(*)                          AS orders,
       SUM(net_amount)                   AS revenue,
       ROUND(SUM(net_amount) / COUNT(*), 2) AS aov
FROM orders
WHERE status <> 'CANCELLED'
GROUP BY month
ORDER BY month;

Keep a small metric dictionary (name, formula, source table, owner, refresh frequency) in your team wiki so the finance and marketing teams stop arguing over two different "revenue" numbers.

Common mistakes

• Starting with the data you have instead of the decision you need to support.
• Vanity metrics such as total app downloads, which rarely drive decisions.
• Comparing periods unfairly — a 31-day month against a 28-day month, or Diwali week against a normal week.
• Too many KPIs: if everything is key, nothing is.