What Is Data Analytics? A Practical Workflow from Questions to Decisions
June 10, 2026
Author: Shusaku Yosa
Data analytics turns relevant data into evidence for a decision. It involves defining a question, checking the data, choosing an appropriate method and explaining what the result can support. A sophisticated model is not the objective. A clear, repeatable answer with explicit limitations is often more useful. This guide follows fictional enquiry data from definitions to a practical next step.
What data analytics is and which decision it supports
Analytics and analysis overlap in everyday use; the useful distinction is the question you are answering. “How many requests were accepted?” needs a reliable count. “Which channels differ?” needs comparable groups. “Did our change cause the increase?” needs a design that addresses causal inference. These are different tasks even when they use the same underlying data.
Descriptive, diagnostic, predictive and prescriptive categories can help organise questions, but they are not a universal ladder of business value. If accepted requests are being counted twice, a simple reconciliation is more valuable than a more complex forecast. NIST’s introduction to exploratory data analysis emphasises examining structure, unusual observations and assumptions before committing to a model.
Define the population, unit of analysis and metric
A row might represent a page view, a session, a request or a customer. These units are not interchangeable. Define the population and counting unit before writing a formula, then confirm them with the person responsible for the operational process. The following requirements sheet describes a fictional enquiry website.
Item | Definition for this example | Check before analysis |
|---|---|---|
Decision | Understand acceptance after arrival on enquiry pages | Who will use the result, and what decision will change? |
Scope and dates | The same production host and page group in equal-length periods | Align time zone, acquisition scope and test exclusions |
Raw request record | A received log entry associated with a request ID | Distinguish repeated log delivery from another request |
Comparison unit | Sessions landing on the defined page group | Count the numerator within that same session population |
Success | An acceptance condition verified against the business system | Separate starting, attempting and successfully completing the operation |
Source and owner | Approved measurement and acceptance records, reconciled by the owner | Use only required information with appropriate access and retention |
Unknown values | Retain an unknown channel as unknown | Do not replace missing attribution with zero or organic search |
A data dictionary records meaning, units, source and update timing, not just column names. An event called “success” is not sufficient evidence that a business operation completed. When that condition has not been validated, mark the outcome as unmeasured and report only the actions you can verify.
Audit missing values, duplicates and unusual observations
Keep source data under the organisation’s access and retention rules, and maintain a separate transformation record. A missing value may mean not provided, not collected or not applicable. The pandas missing-data guide treats detecting, dropping and filling missing values as different operations. Software can perform a transformation without making that transformation appropriate for the business question.
These six rows are an independent fictional receiving-log example. Request IDs and acceptance states have been checked against the operational record for this example. They are not the source data for the later session comparison.
Row and request ID | Record | Treatment in the analysis copy |
|---|---|---|
1: Q101 | Production; search; accepted | Keep one accepted request |
2: Q101 | A repeated delivery of row 1 | Confirm the key and content; do not count the same receipt again |
3: Q102 | Test environment; accepted | Exclude from production totals and log the exclusion |
4: Q103 | Production; unknown channel; accepted | Keep the accepted request; retain the unknown channel |
5: Q104 | Production; search; not accepted | Keep separately; do not count as success |
6: Q105 | Production; referral; accepted | Keep one accepted request |
After these rules, there are four distinct production request IDs, of which three—Q101, Q103 and Q105—were accepted. That is a request count, not a count of registered people. The table contains no landing-session denominator, so it cannot establish a visitor-to-acceptance rate.
An unusual value also needs investigation before removal. It might be a genuine large transaction, a mixed unit or an input error. Record the reason and number of exclusions, and check whether the conclusion changes when questionable observations are retained. Do not remove inconvenient observations simply to improve the result.
Choose a method that fits description, comparison or prediction
Start with counts and distributions, then add the method required by the question. None of the methods below automatically fixes a biased population or missing measurement. Complexity can make an unsupported answer look more precise.
Question | Possible method | Assumption or inference limit |
|---|---|---|
What happened, and how much? | Counts, averages, medians and distributions | Align units and denominators; inspect variation as well as the average |
Do groups differ? | Cross-tabulation or group comparison | Check group sizes and composition; a difference is not automatically a cause |
Are two quantities related? | Scatter plot or regression | Investigate unusual values and model assumptions; a coefficient alone is not causal |
What changed over time? | A time-series table or chart | Check dates, seasonality, definition changes and other interventions |
How well can we predict an unknown outcome? | A predictive model evaluated on unused data | Reserve evaluation data; future accuracy is not guaranteed |
Did a change produce an outcome? | A designed comparison or experiment | Consider assignment and alternative explanations; before/after differences alone are insufficient |
Regression fits a model to observed data. NIST’s least-squares regression guidance describes fitting and the importance of model validation. If advertising expenditure and enquiries rise together, a period of stronger demand may contribute to both. Do not present an advertising coefficient as the incremental effect of spending more without a defensible causal design.
Work through a fictional business-data example
Now use a separate fictional dataset for a session-level comparison. Assume the production hostname, landing-page group, time zone and period length are aligned. Measurement and the acceptance condition have been validated and have not changed. The denominator is sessions landing on that page group. The numerator is sessions from that population containing at least one validated success within the same session.
Measure | Earlier period | Later period |
|---|---|---|
Sessions landing on the defined pages | 200 | 300 |
Sessions containing at least one validated success | 10 | 12 |
Share of those landing sessions with success | 10 ÷ 200 × 100 = 5% | 12 ÷ 300 × 100 = 4% |
Change from the earlier period | Baseline | Two more successful sessions; one percentage point lower |
Both statements are true: successful sessions increased from 10 to 12, and their share fell from 5% to 4%. The population grew, so the count and rate moved differently. Three success events in one session still contribute one session to this numerator. Do not substitute event counts, people or the separate GA4 Entrances metric into this calculation.
The result does not yet show that the form became worse. Investigate channel mix, devices, landing pages, acceptance errors, seasonality, other work and measurement changes. With few successful sessions, a small number of observations can noticeably change the rate. If success has not been validated, do not insert an event count into the formula and call it a business outcome; record the outcome comparison as unmeasured.
Separate association, prediction and causality, then document the next test
Association describes quantities moving together. Prediction estimates an unknown value. Causality concerns a change producing an outcome. NIST’s discussion of experimental design explains that correlation does not establish causality and that another factor may explain an observed relationship. A sales increase alone also cannot establish that new customers caused it; examine customer counts, purchase frequency and transaction value before narrowing the explanation.
Analysis note | Completed example |
|---|---|
Observation | Successful sessions changed from 10 to 12; their share changed from 5% to 4% under the same counting conditions |
Possible explanations | A different acquisition mix, more errors on a particular device, or random variation |
Additional evidence | Channel-level denominators and successes, error records, measurement history and approved interaction checks |
Next action | Investigate the candidate explanation, then consider one specific change to instructions or inputs |
Evaluation conditions | Define the population, success, exclusions, dates and decision criterion in advance |
Limits and reproducibility | Record the small success count, missing information, processing rules, extraction date and calculation method |
A forecast does not prevent churn or stock shortages by itself. Someone must be able to act on the result and evaluate that action. Begin with one useful question and a small calculation whose population, denominator and processing rules another person can reproduce. Before sharing it, check that observed facts and untested explanations remain distinct in the written conclusion.
Related guides for the next step:
