Data analytics is the process of examining data to answer questions and support decisions. Begin with 4 questions: what happened, why it happened, what might happen next and what action is worth considering. These correspond to descriptive, diagnostic, predictive and prescriptive analysis. They are different kinds of reasoning; buying a dashboard does not automatically provide all of them.
For a business, the useful starting point is a decision that someone actually owns. “Understand sales” is too broad to guide a report. “Identify which enquiry sources produce completed orders” is more useful because it identifies records to connect and a decision to revisit. This article explains the basic concepts and provides a practical reporting brief rather than recommending a tool without knowing the data.
What do the main types of data analytics mean?
AWS’s data analytics explanation distinguishes description, investigation, prediction and recommended responses. Treat those categories as a way to frame questions. A historical pattern can support an investigation, but it does not establish the cause of a change or guarantee that a forecast will be accurate in your business.
| Analysis type | Business question | Useful output | Important limit |
|---|---|---|---|
| Descriptive | What happened to completed orders? | A reconciled summary by period | A total does not explain its cause |
| Diagnostic | Where did the difference arise? | Breakdowns and records to investigate | Association is not proof of causation |
| Predictive | What outcome might follow? | A forecast with assumptions and uncertainty | Historical conditions may change |
| Prescriptive | Which response should be evaluated? | Options against stated constraints | The recommendation still needs accountable judgement |
These examples are an original teaching framework, not findings from a Spout customer dataset. A useful analytics project may remain descriptive if the immediate problem is inconsistent reporting. Building a complex prediction on unreliable totals would make uncertainty less visible rather than solving it.
Imagine an enquiries report that counts website submissions and completed orders. The first question is whether those records refer to the same enquiry journey. A customer may submit twice, call later and place an order under a different contact name. Decide how records will be linked before comparing channels. Otherwise the report may reward the channel with the most duplicate activity.
Choose the period carefully. A report of enquiries received this month differs from a report of orders completed this month. Linking those totals directly can make a long sales process look unsuccessful. A cohort view follows a defined group of enquiries over time; a period view describes activity inside a calendar window. Label the choice so readers do not interpret one as the other.
How do you prepare data that can support a decision?
Write a definition for each measure. “Completed order” might mean an accepted order, a delivered order or an order whose payment has been reconciled. None should be silently substituted for another. Record the source system, inclusion rule, relevant date and handling of cancellations alongside the label shown in the chart.
Microsoft’s Power BI modelling guidance separates dimension tables, which describe entities and support filtering, from fact tables, which record observations and support summarisation. It also emphasises consistent grain. In ordinary terms, know what one row represents before adding it to another table. An order line, an order and a customer are different units.
This distinction matters when joining records. If a customer has several contacts and several transactions, an unsuitable join can repeat a transaction across contacts. The resulting total may look professionally presented while being wrong. Compare the joined result with an independent source total, and inspect a small set of records manually to explain the relationship.
Deal explicitly with missing and corrected information. A blank channel should remain identifiable rather than being silently assigned to a convenient category. A corrected order should not become a second order merely because the file was imported again. Record what the system does with absent values, duplicates and changed records before asking users to rely on a trend.
Restrict access according to the question. A channel-performance report may need an enquiry reference and outcome without exposing private message content to every viewer. Use redacted examples for early discussions, and determine what individual-level information is necessary. Product documentation about modelling does not establish that a particular collection or disclosure meets Zambian legal requirements.
What should a practical analytics brief contain?
Use this original decision-report worksheet before commissioning a dashboard. Each row connects an analytical choice to a check that a business owner can understand.
| Brief field | Example entry to adapt | Acceptance question |
|---|---|---|
| Decision | Decide which enquiry journeys need investigation | Who will act on the result? |
| Population | Enquiries received during the selected period | Which records are excluded and why? |
| Unit | One identifiable enquiry journey | Can repeated submissions be distinguished? |
| Outcome | A separately defined completed order | Which event establishes completion? |
| Timing | Enquiry date plus later outcome date | Are cohorts being confused with period totals? |
| Reconciliation | Compare report totals with source records | Can differences be traced to individual records? |
| Limitations | Missing channel values remain visible | What cannot responsibly be concluded? |
Test the brief with a deliberately awkward example: a repeated enquiry, a cancelled order and a transaction corrected after the report was first produced. Ask the analyst to show where each record appears. The purpose is to understand the rules, not to demand that every exception disappears into a tidy chart.
Keep a distinction between a finding and a proposed explanation. “The count changed” can be supported by reconciled records. “The campaign caused the change” needs a stronger basis. State competing explanations such as changed classification, different reporting periods or a process interruption, and identify what evidence would help distinguish them.
Choose presentation after the definitions are agreed. A table may answer a reconciliation question better than a large collection of charts. A trend chart should make its period, unit and missing information visible. Use descriptive labels and include an explanation of any break in the series caused by a definition or source change.
Finish with a decision note: what was observed, what remains uncertain, what action was agreed and when its result will be checked. That makes the report part of a working process. Repeating an attractive dashboard without revisiting its question can preserve yesterday’s assumptions long after the business has changed.
For the systems connecting source records, see web development. To describe an analytics requirement, get started with a redacted sample, the decision you need to support and the definitions currently used. Do not send live customer data merely to explain the reporting problem.
By Spout Team. AI-assisted drafting by Codex using the linked primary sources.