What Is Data Analytics?

This topic follows Kestrel Energy, a fictional Dutch energy supplier. Every month its chief financial officer, Margriet de Wit, receives a KPI pack: a workbook with active contracts, kilowatt-hours (kWh) delivered per tariff, the amount billed, overdue invoices, new customers and churn. Lucía Romero in the billing team builds it by hand from the nightly 02:30 export of KBS (Kestrel Billing System). Over the next pages that export is cleaned, analyzed in a spreadsheet, in SQL and in Python, charted, and finally moved by Joost Bakker, who owns KBS, into an automated pipeline and a business intelligence tool.

The examples run on a small sample of Kestrel's data, kestrel.sql: 12 customers, 14 contracts, daily meter readings for September 2026 and four months of invoices. They use DuckDB 1.5, an analytical database that runs as a single program (as of October 2026; DuckDB 2.0 is scheduled for 21 October 2026).

What data analytics is

Data analytics is the practice of examining data to answer questions and support decisions: finding the right data, checking and cleaning it, summarizing and modeling it, and explaining the result to the people who have to act on it. The output is not a table or a chart; it is a better-informed decision.

The systems that run a business are built to record what happens: KBS creates an invoice, meter-api stores a reading. Those are online transaction processing (OLTP) systems. Analytics asks questions about what was recorded, over many rows and long periods, which is a different workload with different tools (see OLTP and OLAP). That is also why Hamid Rahimi, Kestrel's database administrator, does not want analysis queries on the production database db01 (why analytics doesn't run on production).

Much analytics work ends in a few agreed numbers that are watched over time: key performance indicators (see CSFs and KPIs). The analytics is the work that makes those numbers correct, explains them when they move and suggests what to do about it.

Four kinds of analytical question

A common way to sort analytical work is by the question it answers. The four names below were popularized by the research firm Gartner in the early 2010s and are now used everywhere. They are not strict categories: a single analysis often moves through several of them, and each one builds on the one before.

Margriet's question for this month runs through all four: "Are customers on dynamic contracts more likely to stay, and do they use less energy?"

Descriptive: what happened?

Descriptive analytics summarizes what has already happened: totals, counts, averages and trends over a period. It is the bulk of everyday reporting, and everything else depends on it being right. The first step for Margriet is simply: how much energy did each tariff deliver in September?

SELECT c.tariff,
       count(DISTINCT r.meter_id) AS meters,
       sum(r.kwh_import) AS kwh_september
FROM daily_readings r
JOIN meters m USING (meter_id)
JOIN contracts c USING (contract_id)
GROUP BY c.tariff
ORDER BY kwh_september DESC;

┌───────────┬────────┬───────────────┐
│  tariff   │ meters │ kwh_september │
│  varchar  │ int64  │ decimal(38,3) │
├───────────┼────────┼───────────────┤
│ dynamic   │      3 │      2057.276 │
│ day_night │      3 │      1828.518 │
│ fixed     │      3 │      1074.240 │
│ variable  │      3 │       597.561 │
└───────────┴────────┴───────────────┘

DuckDB prints each column's type under its name. The answer looks clear: the three dynamic contracts used the most energy. Read literally, dynamic customers use more, not less. That is a description, and it immediately raises the next question.

Diagnostic: why did it happen?

Diagnostic analytics looks for the reasons behind a result: it breaks a number down by other attributes, compares groups and periods, and tests possible explanations. Here the obvious suspect is the kind of customer: Kestrel supplies households and businesses, and a bakery uses far more than a flat.

SELECT c.tariff, cu.segment,
       count(DISTINCT r.meter_id) AS meters,
       round(sum(r.kwh_import) / count(DISTINCT r.meter_id), 1) AS kwh_per_meter
FROM daily_readings r
JOIN meters m USING (meter_id)
JOIN contracts c USING (contract_id)
JOIN customers cu USING (customer_id)
GROUP BY c.tariff, cu.segment
ORDER BY cu.segment, c.tariff;

┌───────────┬───────────┬────────┬───────────────┐
│  tariff   │  segment  │ meters │ kwh_per_meter │
│  varchar  │  varchar  │ int64  │    double     │
├───────────┼───────────┼────────┼───────────────┤
│ day_night │ business  │      1 │        1195.5 │
│ dynamic   │ business  │      1 │        1555.0 │
│ fixed     │ business  │      1 │         463.3 │
│ day_night │ household │      2 │         316.5 │
│ dynamic   │ household │      2 │         251.2 │
│ fixed     │ household │      2 │         305.5 │
│ variable  │ household │      2 │         188.1 │
└───────────┴───────────┴────────┴───────────────┘

One of the three dynamic contracts belongs to a bakery that used 1,555 kWh in September, more than the other two together. Per household meter, dynamic customers used less than households on a fixed or day/night tariff. The total in the first query was driven by the mix of customers, not by the tariff. With two meters per group, both of them with solar panels, this is a hint, not proof; the Exploratory Data Analysis page returns to this kind of hidden third factor.

Predictive: what will probably happen?

Predictive analytics uses patterns in historical data to estimate what is likely to happen next: next month's consumption, or the chance that a given customer cancels within a year. The output is a probability or a forecast with uncertainty, never a certainty. Most predictive work uses statistics and machine learning, from a simple linear regression to more complex models.

For Margriet this is the "more likely to stay" half of the question: which customers are at risk of leaving? A model trained on past contracts can score each customer, but only as well as the history allows. Kestrel's sample has one customer who changed contract in four months, which is not enough to learn from.

Prescriptive: what should we do?

Prescriptive analytics recommends an action. It combines a prediction with the options, their costs and the constraints: which customers should get a retention offer, and which offer, given a fixed budget? It often uses optimization or simulation on top of a predictive model.

Prescriptive does not mean "the computer decides". Under Article 22 of the General Data Protection Regulation (GDPR), people have the right not to be subject to a decision based solely on automated processing that has legal or similarly significant effects on them. The UK GDPR replaced that rule on 5 February 2026 with safeguards (Articles 22A to 22D), with stricter limits for special category data, and in the US, California's privacy rules give consumers notice and, with some exceptions, an opt-out from automated decision-making technology for significant decisions from 1 January 2027. Using billing data to target offers at individual customers also raises a purpose question: the data was collected to bill, not to market. Both are covered on Data Governance and Privacy; the basics of the GDPR are on Privacy and Data Protection.

Who does the work

Analytics is a team sport, and job titles vary a lot between organizations. Three roles are found almost everywhere:

• A data analyst answers business questions with data: writes SQL queries, builds spreadsheets, reports and dashboards, and explains what the numbers mean to the people who asked. Most descriptive and diagnostic work is done here.
• A data engineer builds and runs the systems that move and store data for analysis: pipelines that copy data out of source systems, checks that catch bad loads, and the warehouse or lake where the data lands. Their work is closer to software and operations than to statistics.
• A data scientist uses statistics, programming and machine learning to build models, usually for predictive and prescriptive questions, and to run experiments such as A/B tests.

Two newer titles sit in between. An analytics engineer writes and tests the SQL transformations that turn raw data into clean, documented tables for analysts; the title grew up with tools such as dbt. A BI developer builds the data models, measures and dashboards inside a business intelligence tool. On the business side, a data owner decides who may use a dataset and for what, and data stewards look after its definitions and quality (see Data Governance and Privacy).

Kestrel has no analytics department. Lucía does analyst work in a spreadsheet as part of her billing job, and Joost takes on the data engineer's role when he automates the KPI pack. That is normal in smaller organizations, and it is why the practical skills on these pages matter to people whose job title has nothing to do with data.

From question to decision

Whatever the tools, analytical work follows roughly the same steps. The order matters less than the first and the last: start from a question someone needs answered, and finish by checking whether the decision it supported had the intended effect.

1. Question. What decision does this support, who makes it, and by when?
2. Data. Which sources hold the answer, and may we use them for this purpose?
3. Clean. Find and fix duplicates, gaps, impossible values and inconsistent codes, and record every change. This step often takes more time than the analysis itself.
4. Analyze. Summarize, break down, compare, model.
5. Communicate. A clear chart or a short written answer, with its assumptions and limits stated.
6. Decide. Someone acts, or decides not to.
7. Measure. Did the action have the expected effect? That answer is the next question.

Start with the question

"Let's see what the data tells us" is a weak start: a large dataset always contains some pattern, and without a question there is no way to tell a useful one from noise. A good analytical question names the decision, the measure and the period.

Can you look into dynamic contracts?

For the October tariff review: did household customers on a dynamic
contract use less electricity per meter in September 2026 than household
customers on other tariffs? Businesses separately.

The second version says who needs it (the tariff review), what to compare (kWh per meter), which customers (households, with businesses apart), and which period. It already contains the lesson of the diagnostic query above.

Define the measure before you count

"How many active contracts did we have at the end of September?" sounds like one number. On Kestrel's data it is three, depending on what "active" means:

SELECT
  count(*) FILTER (WHERE end_date IS NULL) AS no_end_date,
  count(*) FILTER (WHERE end_date IS NULL
                     AND start_date <= DATE '2026-09-30') AS started_by_30_sep,
  count(*) FILTER (WHERE end_date IS NULL
                     AND start_date <= DATE '2026-09-30'
                     AND customer_id IN (SELECT customer_id FROM customers))
    AS with_known_customer
FROM contracts;

┌─────────────┬───────────────────┬─────────────────────┐
│ no_end_date │ started_by_30_sep │ with_known_customer │
│    int64    │       int64       │        int64        │
├─────────────┼───────────────────┼─────────────────────┤
│          13 │                12 │                  11 │
└─────────────┴───────────────────┴─────────────────────┘

FILTER (WHERE …) is standard SQL: it lets each count(*) count only the rows that match its own condition. Thirteen contracts have no end date; one of them only starts on 1 October, and one belongs to a customer number that does not exist. Lucía's old spreadsheet KPI pack counted every contract without an end date: 13. The middle column, 12, is only a step on the way, started and not ended but with an unknown customer still allowed. Femke Jansen, head of billing, owns the definition that goes into Margriet's pack, and her approved version is "has started, has not ended on that date, and belongs to a known customer": 11 on 30 September 2026. It is written down once instead of being reinvented in every spreadsheet (see Data Modeling for Analytics).

Analytics, statistics and AI

The four kinds of analytics overlap with fields that have their own topics on this site:

• Statistics supplies the methods for describing data and for judging whether a difference is real or chance. The basics (mean, median, spread, percentiles) are on Statistics for IT; Statistics for Analysts adds samples, confidence intervals and A/B tests.
• Machine learning, a part of AI, supplies most predictive models. Everything about data quality on these pages applies there with extra force: a model learns whatever is in its training data, errors included (see garbage in, garbage out).
• Business intelligence is the tooling for descriptive and diagnostic analytics at scale: shared data models, dashboards and reports (see Business Intelligence Tools).

Common pitfalls

• Starting from the data. Searching a dataset for "insights" finds patterns that are often coincidence. Start from a decision.
• Trusting a number without its definition. "Active contracts" was 13, 12 or 11 above. Ask how a figure is defined before comparing it with another.
• Trusting a number without checking the data. Duplicates, gaps and typing errors survive into totals unnoticed. A row count that matches what you expected proves nothing, as the next page shows.
• Reading a cause into a difference. The dynamic tariff did not make the bakery use more energy. Breaking a total down by other attributes is the first defense; see Exploratory Data Analysis.
• Automating a decision about people without safeguards. A churn score is a prediction, not a verdict. Keep people in the loop and check the legal basis first.

How this topic is organized

The pages follow the KPI pack from raw export to governed pipeline:

• Data: Data Types and Data Quality and CSV, JSON and Parquet.
• Spreadsheets: Spreadsheets Done Right, Spreadsheet Formulas, Pivot Tables and Summaries and When a Spreadsheet Is Not Enough.
• Analysis: Analytical SQL, Data Analysis with Python, Exploratory Data Analysis and Statistics for Analysts.
• Communication: Choosing the Right Chart, Honest and Accessible Visualization and Business Intelligence Tools.
• Platform and governance: Data Pipelines, Warehouses, Lakes and Lakehouses, Data Modeling for Analytics and Data Governance and Privacy.