From Business Question to Data-Driven Decision

Hello! This is the first lesson in your Data Analyst transition course. We’ll begin with the shape of an analysis project before opening Excel or writing SQL. Your experience building storefronts gives us a useful setting: when a site change affects sales, the analyst’s job is not simply to produce a chart, but to help someone make a sound decision.

By the end of this lesson, you should be able to map a business question through data planning, preparation, analysis, communication, and action. We’ll use a Shopify checkout scenario to make each step concrete.

Start with the decision, not the dataset

Imagine a product manager says, “Sales look weaker since we changed mobile checkout. Should we roll it back?” The temptation is to open a dashboard immediately. First, though, you need to establish what decision is pending, who will make it, and what evidence would help. “Sales” might mean revenue, number of orders, or the share of shoppers who complete checkout. Those are different questions.

Watch this short explanation of the analyst’s workflow. Notice that it ends with action: sharing a finding is not the same as deciding what to do.

Here is a practical map to keep beside you throughout the course. The names vary across organizations, but the work is recognizable:

This is a workflow, not a guarantee that every project moves neatly through six boxes. You may discover during analysis that an important event was not recorded correctly. In that case, you return to data preparation—or even to the original question—rather than presenting a confident but unreliable answer.

What happens between a question and a finding?

The preparation phase often gets skipped because a dataset is already available. Yet having data is not the same as having the right data. For the checkout request, you would need to know when the redesign launched, whether it affected mobile only, how checkout starts and purchases are recorded, and whether you can compare periods using consistent definitions. If purchase events stopped being recorded for some browsers, a fall in recorded orders could be a measurement problem.

Georgia Tech Library’s guide expands the middle of the workflow: it separates planning and collecting data from cleaning it, and distinguishes initial exploration from analysis directed at the question.

Exploration is your first inspection of the available evidence: Are there missing dates? Do mobile and desktop behave differently? Are some daily values unusually high? Analysis uses those observations to address the agreed question—for example, comparing mobile checkout completion before and after a release. Exploration can reveal a better question or a data defect; it should not become an endless search for an interesting-looking number.

Likewise, a hypothesis can give the work direction without predetermining its answer. “The new mobile checkout introduced friction” is a possible explanation to investigate, not a conclusion. A simultaneous change in advertising traffic or purchase tracking could also explain an apparent decline. Your responsibility is to report what the evidence supports and what it cannot establish.

A checkout decision, mapped end to end

Let’s follow the product manager’s request as a small analyst project. The numbers below are illustrative, not findings from a real store.

Ask. The product manager owns the rollout decision and wants to know whether to keep the new mobile checkout live. You agree to investigate whether shoppers who start checkout are less likely to place an order after the release. That narrower question is useful to the decision; a site-wide sales total alone could move because of traffic volume, promotions, or other changes.

Prepare. You identify the release date and request checkout-start and purchase records, including a way to recognize the same shopping session in both. You plan comparable periods before and after the release and check which devices received the change. You also ask whether tracking or marketing campaigns changed at the same time. At this stage you are specifying the evidence needed, not yet claiming that it is reliable.

Process. You inspect the records. Are events missing on particular dates? Are purchases duplicated? Do mobile and desktop use the same event definitions across both periods? Suppose these checks pass. You can now calculate a consistent completion rate: the proportion of checkout-starting sessions that subsequently placed an order. If the checks do not pass, the right output may be “we cannot yet make this comparison reliably,” together with a plan to repair or replace the data.

Analyze. Suppose 600 of 1,000 mobile checkout-starting sessions placed an order before the change, compared with 520 of 1,000 afterward. That is 60% versus 52%, a decline of 8 percentage points. You inspect the pattern by day and relevant traffic source, and check desktop as additional context. The change is worth investigating, but a before-and-after comparison by itself does not prove that the redesign caused it.

Share. A useful update to the product manager leads with the decision-relevant finding: “Mobile checkout completion was lower in the period after launch, using consistent event definitions. The redesign is one plausible cause, but changes in traffic mix may also matter.” Show the comparison, state the periods and checks, and make the uncertainty visible. A long export of every row would make the decision harder, not easier.

Act. You recommend pausing further rollout while the team investigates, with a limited rollback if feasible and appropriate. The product manager decides what to implement. The team then watches the same completion measure and checks whether the result changes as expected. If it does not, that new evidence informs the next investigation.

Notice the distinction between three outputs: a finding describes the evidence; a recommendation proposes a response; a decision belongs to the person accountable for acting. A strong analyst connects all three without treating an observed pattern as proof of its cause.

Put the map to work

Brief practice activity (about 8 minutes): Think of a storefront, landing page, or campaign change you know well. Choose a plausible stakeholder concern, such as “Leads fell after the page redesign.” Draft six short lines headed Ask, Prepare, Process, Analyze, Share, Act. For each, write the one thing you would need to clarify, check, produce, or decide before moving on. You do not need a dataset or a tool.

Review your draft for two common gaps: Did you identify who owns the decision? Did you include a way to tell whether the data is trustworthy before drawing a conclusion? If either is missing, revise the relevant line. This six-line brief is a reusable starting point for later Excel, SQL, and Power BI projects.

Key takeaways

A data analysis workflow begins with a business decision and ends with an action that can be checked. Between those points, the analyst plans the evidence, verifies the data, investigates the question, and communicates both the finding and its limits. When the evidence is inadequate, revisiting an earlier phase is part of doing the work well.

Next, we’ll focus more closely on the first phase: turning a stakeholder’s broad request into a measurable analytical question.