1.1 Questions, Evidence, and Decisions

You already know enough Python to calculate a mean, filter a list, or print a result. Data analysis begins one step earlier: deciding what should be calculated and why. A flawless program can still answer the wrong question. This section turns a vague request into a defensible chain:

Imagine that a neighborhood delivery company says, “Analyze our deliveries.” That request names a topic, not a question. Should the company add riders, redraw delivery zones, change its promised time, or investigate complaints? Each decision requires different evidence.

Turn a topic into an analytical question

An analytical question is a question that available or obtainable data can answer through a defined calculation or comparison. A useful question usually names five elements:

• Decision: What choice will the result inform?

• Population: Which people, orders, places, or events are in scope?

• Metric: What measurable quantity represents the concept of interest?

• Comparison: Across which groups, periods, or conditions will the metric be compared?

• Time window: Which dates belong in the analysis?

“Are deliveries slow?” leaves every element unclear. A better version is: “Across the last eight weeks, how did the on-time delivery rate differ among the North, Central, and South zones during the evening shift, so the operations manager can decide where to add rider capacity?”

The improved question still contains choices. On-time delivery rate must be defined—for example, the percentage of completed orders delivered within 40 minutes. “Evening” might mean orders accepted from 17:00 through 21:00. Writing these definitions before computing prevents the analyst from moving thresholds until the result looks interesting.

A metric is a model of a concept

A business concept such as “service quality” cannot be placed directly into a table. We represent it with measurable variables: delivery minutes, on-time rate, cancellation rate, complaint rate, or repeat orders. Each is a partial model of quality.

Suppose average delivery time improves from 39 to 35 minutes. That sounds favorable, but the average can hide a worse experience for a small zone. A robust analysis checks whether the chosen summary represents the decision:

Metrics are not facts handed down by the dataset. They are definitions chosen by people. Record the numerator, denominator, exclusions, units, and time boundary. If cancelled orders are excluded from the on-time rate, say so—and ask whether excluding them makes performance look artificially strong.

Match the claim to the evidence

Data can support claims of different strength. A descriptive claim states what was observed: “The South zone had a lower on-time rate in this dataset.” An associational claim states that two variables move together: “Rainy periods were associated with longer delivery times.” A causal claim says changing one factor would change another: “Rain caused the delay” or “adding riders will improve the rate.”

The final claim is strongest and requires the strongest design. An ordinary operational table often contains confounding variables—other factors related to both the proposed cause and the outcome. Rainy evenings may also have more orders, slower traffic, different rider availability, and longer-distance deliveries. A large number of rows reduces some random uncertainty, but it does not make these alternative explanations disappear.

Write findings with an evidence boundary

A useful result has four layers:

• Finding: What calculation or comparison was observed?

• Scope: Which population and time period does it describe?

• Uncertainty and limitations: What measurement problems, missing groups, or alternative explanations remain?

• Decision implication: What action is reasonable now, and what should be investigated next?

For example: “Among completed evening deliveries recorded during the last eight weeks, the South zone’s on-time rate was 71%, compared with 86% elsewhere. Because cancelled orders are absent and route distance differs by zone, this does not establish that rider staffing caused the gap. Operations should audit cancellation capture and distance distribution before changing staffing.”

This wording is not timid. It separates what the evidence shows from what the organization hopes to know. That separation is the foundation of trustworthy analysis.

In the next section, you will turn this reasoning into an iterative workflow. The question is not a decorative sentence at the top of a report: it controls which data to acquire, which defects matter, which comparisons to make, and which claims are allowed at the end.