Many analysis tasks begin with “take a look at the data.” The issue is not that the request sounds informal. It is that the request does not identify the decision the result must support. Moving directly into queries and charts can create many pages without answering the user’s real question.
1. State the decision first
Rewrite the request as a specific sentence: who needs to make which decision, in what time frame, and with what evidence? For example: “The sales lead needs to identify where conversion declined during the monthly review and decide which channel to investigate next.”
The sentence does not guarantee a correct conclusion, but it makes usefulness testable.
2. Define the subject and grain
A “customer count” might refer to accounts, contacts, orders, or devices. Identify the business subject and record what one row represents. Unclear grain is a common cause of duplication after joins and aggregation.
3. Document the metric definition
A metric definition should identify the population, time window, filters, numerator and denominator, and treatment of missing values. Terms such as conversion, active, and repeat purchase need reproducible rules—not names alone.
4. Record scope and limitations
State the sources, the latest included date, and known gaps. Limitations are part of the conclusion. If one channel is missing, the result cannot be generalized to every channel.
5. Sketch the deliverable
Before transforming data, sketch the conclusion, evidence, and detail areas. Every chart should answer a named question. If a chart has no decision role, leave it out for now.
Once these five elements are clear, the analysis blueprint exists. SQL, Python, and BI tools implement that blueprint; they do not replace problem definition.
For tools, platforms, or regulations, verify the latest official information before applying the method.