Types of data analysis: what each one answers and which to start with

Most requests for "analytics" arrive without a type attached. A finance lead wants to know why margin dropped, a sales director wants next quarter's forecast, and an operations manager wants to know how many people to schedule. Each is a different kind of analysis with different data needs, tools and risks. Naming the type first prevents the common mistake of buying a forecasting tool when the real gap is a reliable weekly report.

What are the types of data analysis?

Four types form the core: descriptive, diagnostic, predictive and prescriptive. They answer progressively harder questions and usually depend on each other, so a weak layer underneath weakens everything above it. Three more methods support them: exploratory, inferential and causal analysis.

What do the four core types look like day to day?

Descriptive analysis is the foundation, and most operational reporting lives here. It summarizes what happened: orders shipped last week, days sales outstanding, tickets closed by team. Its value depends entirely on whether everyone agrees what the numbers mean.

Diagnostic analysis breaks a result into parts to find where it came from. If gross margin fell two points, the question is which products, customers, regions or discounts account for the movement. A good diagnostic report lets someone ask a second and third question without a new request to the data team.

Predictive analysis uses history to estimate what is likely next: demand next month, which invoices will be paid late, which customers may leave. It produces a probability or a range, never a certainty. Our guide to machine learning vs deep learning covers which methods suit tabular business data.

Prescriptive analysis turns a forecast into a recommended action under constraints: how many drivers to schedule, which orders to ship first, how to split inventory between warehouses. It needs a trustworthy forecast and an honest list of constraints and costs, and a named person should approve the action before it runs.

Where do exploratory, inferential and causal analysis fit?

They support the core four. The NIST/SEMATECH handbook describes exploratory data analysis as an approach, mostly graphical, for revealing structure, finding outliers and testing assumptions. Run it on any new dataset before building on it, because the missing values and odd categories you find there are the ones that would otherwise corrupt a report or a model later.

Inferential analysis asks whether what you see in a sample probably holds for the whole population, which matters when you test a change on a subset of customers or sites. Causal analysis asks what an action would change. It usually needs a designed test, such as giving a discount to a random half of customers, or a carefully controlled comparison, and it is the only type that can support a claim of "this caused that".

Which types matter most for finance, operations, sales and supply chain?

Start with descriptive and diagnostic work in every function, and add predictive work where a decision repeats and the data is clean.

• Finance. Descriptive: close-cycle reporting, aged receivables, budget against actual. Diagnostic: variance analysis by account, cost center and vendor. Predictive: cash flow and collections forecasts. Prescriptive: choosing which invoices to pay early to capture discounts, within a cash floor.
• Operations. Descriptive: throughput, backlog, first-pass yield, cycle time. Diagnostic: where work waits and why. Predictive: staffing needs and equipment failure risk. Prescriptive: schedules and routing within capacity limits.
• Sales. Descriptive: pipeline by stage, win rate, average deal size. Diagnostic: why deals stall or are lost, by segment and source. Predictive: lead scoring and churn risk. Prescriptive: which accounts a rep should contact this week.
• Supply chain. Descriptive: on-time delivery, fill rate, inventory days. Diagnostic: which suppliers or lanes cause delays. Predictive: demand forecasts and lead time estimates. Prescriptive: reorder points and allocation across locations.

Why should reliable reporting come before prediction?

Because a predictive model learns from your records, including their mistakes. If "active customer" means one thing in the CRM, another in the billing system and a third in the finance spreadsheet, a churn model trained on any of them will answer a question nobody agreed on. The prediction can look accurate in testing and still be useless, because the definition it learned does not match how the business uses the word.

Most companies at this size get more return from fixing the foundation first: one definition per metric, one owner per source system, and a report that finance and operations both trust. Predictive work then starts from a base that holds up.

Illustrative example: A distributor with 80 employees asks for a model to forecast which customers will reduce orders. Before building anything, an analyst compares the CRM, the ERP and the finance workbook and finds three definitions of "active": ordered in 90 days, ordered in 12 months, and has an open account. The team spends six weeks agreeing one definition, correcting duplicate customer records and publishing a weekly report that both sales and finance accept. The report alone reveals that most of the order decline comes from two product lines, which changes what the company decides to do before any model exists.

A practical sequence works for most teams:

1. Pick the five to ten metrics leaders actually use and write one definition for each.
2. Name an owner for each source system and each metric.
3. Build the descriptive report from one governed source, as a dashboard or portal. Our guide to planning the first release of internal tools and portals covers how to scope it.
4. Add diagnostic drill-downs for the questions that come up most.
5. Add predictive work only for a repeated decision where the data has a long, accurate history.

Our data readiness check can show how a single workflow scores on availability, quality, access, governance and integration, and where connecting the ERP and CRM data is the first job.

How do you avoid reading correlation as cause?

A correlation means two things move together. It does not tell you that one produces the other, and acting on it can backfire. In their textbook Causal Inference: What If, Hernán and Robins make this point with a hypothetical medical example: aspirin can look harmful in the raw data because doctors prescribe it to patients already at high risk of cardiovascular death, even though its causal effect in the example is protective. The authors use the adage "association is not causation" to describe the gap between the two.

Business data has the same trap. Customers who receive more sales calls may churn less, because reps call the accounts they already expect to keep. Stores with larger promotions may sell more, because the biggest stores get the biggest promotions. Before acting on a pattern, ask these questions:

1. Which way could the arrow run? Perhaps sales calls follow loyalty instead of creating it.
2. What else could drive both? Account size, region, season and product mix are common hidden drivers.
3. Can you test it? Apply the change to a random subset, compare against the rest, and measure the outcome you care about.
4. Is the sample large and representative enough? Two weeks at three sites does not describe the company.
5. What would change your mind? Decide in advance what result would show the pattern is not causal.

Where does AI help with data analysis, and where does it mislead?

AI helps most with the mechanical parts: drafting SQL, summarizing a table in plain language, explaining a chart, and proposing which columns to inspect. It can shorten the time from question to first draft.

It misleads when it is trusted without checking, especially in natural language querying over messy data. The BIRD benchmark, published in 2023, tests text-to-SQL on realistic databases and highlights dirty database contents as a challenge: in its results the most effective model, ChatGPT, reached 40.08% execution accuracy against 92.96% for humans. A later benchmark, Spider 2.0 (November 2024), uses 632 enterprise workflow problems, and its authors report that an agent based on OpenAI's o1-preview solved only 21.3% of them, compared with 91.2% on the older Spider 1.0 and 73.0% on BIRD. Models have improved since, so treat these as a warning about messy data and not a score for any current product.

Three controls keep AI helpful. Define each metric once, in a place the tool must use. Show the generated query next to every answer so an analyst can read it. And keep a set of questions with known answers, rerunning it whenever the model, schema or definitions change. A natural language question that returns a plausible number from the wrong table is harder to catch than an error message.

How Kastling approaches this

Reliable reporting is often the right first deliverable in Custom Solutions: internal tools, dashboards and portals built on the systems a business already runs. Kastling's approach is to understand how the work is done first, connect the existing sources instead of replacing them, agree one definition for each metric, and agree how success will be measured.

Prediction and AI features come later, where a repeated decision and a trustworthy history justify them. They are tested against real business scenarios, a named person stays in control of consequential decisions, and data access and ownership are agreed up front. The scope and operating costs are set out in the proposal.