~/teaching · data analytics · session 1, wednesday 9 december 2026

From data to decisions: the analytics ladder, KPI trees and honest data cleaning

Ask a precise question, break the goal down, then clean the data with every choice written down.

Sitraka Forler, Université Catholique de Lille

Revision 16 October 2026 · about 10 minutes

Abstract

This is the opening session of Data Analytics for Business, a course of the M2 International Management at Université Catholique de Lille (2026-2027). It is written for future managers, not for future data scientists: people who will commission analyses, question the figures put in front of them, and take decisions that others have to carry out.

The session follows one thread. Most data projects that disappoint fail before any analysis starts, because nobody named the decision, the question was vague, the numbers were not trusted, or nobody owned the follow-up. So the deck starts with the kind of question analytics can answer, turns a vague goal into a precise question, breaks that goal into a tree of measurable indicators, and only then opens the data: about 100,000 real orders from Olist, a Brazilian marketplace, published as open data.

After this session you can place a business question on the analytics ladder, rewrite a goal so that it states the decision at stake, the measure of success, its boundaries and whoever must follow up, draw a KPI tree whose leaves someone can act on, and clean a spreadsheet in a way another person can reproduce. The next step, choosing and drawing the chart, is in data visualisation and storytelling.

The slides

From data to decisions

Session 1, Wednesday 9 December 2026. Data Analytics for Business, Université Catholique de Lille, M2 International Management, 2026-2027.

Open the slides (password from your teacher)

The deck itself is encrypted for the students of the course; this page summarises it for everyone.

The course page

Plan of the deck

From data to decisions. Why the bottleneck is now judgement rather than technology, and the four types of analytics.
KPI trees. Breaking a strategic goal into drivers until every leaf is measurable and owned, with leading and lagging indicators.
Meet the case. The Olist marketplace, its nine linked tables, the life of an order and what one row of each table means.
Clean and summarise. Duplicates, gaps, outliers and messy formats, a cleaning log, then pivot tables and four checks before trusting them.
The management briefs. Eight decisions a manager at Olist could face, each one the starting point of a group project.
Wrap-up. Three ideas to keep, one per objective, and the principle that the decision comes before the data.

The analytics ladder: four kinds of question

Analytics answers four different questions, from what happened to what we should do, and each step is harder and more valuable.

Storage is cheap, dashboards take minutes and AI assistants write queries for you. What a company still lacks is judgement: someone who can phrase a precise question, decide whether a figure deserves trust, and turn evidence into a decision people will follow. These three abilities are managerial, not technical, and they are what the course trains.

The deck organises analytics as a ladder, after Gartner's maturity model. Each rung answers a different question. Recognising the rung of a question tells you what kind of work, data and time it needs.

**Table 1:** The four rungs, with questions one could ask of the Olist orders.
Rung	Question it answers	Olist example
Descriptive	What happened?	Share of 2017 orders that arrived after the promised date
Diagnostic	Why did it happen?	Whether distance between seller and buyer explains weaker reviews
Predictive	What will happen?	Which orders placed this week are at risk of arriving late
Prescriptive	What should we do?	Which delivery date to display to each customer at checkout

Remark (Where the value is). The upper rungs are not automatically better. In most companies the bulk of the value still comes from descriptive and diagnostic work done carefully. A careful account of the right problem beats a sophisticated forecast that answers a poorly posed one.

Back to contents.

From a vague goal to a precise question

A goal such as improving satisfaction cannot be analysed until it names a decision, how success is measured, what is in scope, and who will act.

The deck lists four recurring reasons why data projects let people down: no decision attached (a dashboard requested for its own sake), a question too vague to measure, two reports giving two different numbers, and a correct finding that nobody is responsible for acting on. None of them is technical, and all four are fixed by whoever commissions the work, before the analysis begins.

Worked example from the deck

Start vague. Improve customer satisfaction.
Name the decision. Which fix to fund first.
Name the measure. The share of reviews with one or two stars.
Fix the scope. The delivery experience, for orders placed in 2018.
Name the owner. The Head of Customer Experience. The owner rarely appears in the sentence itself, but it sets how much detail the answer needs.
Result. Which part of delivery drives one- and two-star reviews in 2018, and which fix should be funded first?

A useful self-check: if the question does not fit in two lines, it probably mixes two decisions. The session then asks students to sharpen goals of their own choosing, such as making customers come back, and to say on which rung the result sits.

Remark (Principle 1.1, decision first). Begin with the decision you must take, then look for the evidence that could change it. Opening the data to see whether something interesting turns up is the tempting route, and the costly one.

Back to contents.

KPI trees: breaking a goal into measurable drivers

A KPI tree splits a goal into the things that move it, and keeps splitting until each end point can be measured and has someone responsible for it.

Three rules hold the tree together: every branch must explain the box above it, every leaf must be computable from data that exist, and every leaf needs an owner who can act. The tree also gives a dashboard its skeleton, with the goal as the headline figure and the leaves as the numbers people work on.

Revenue, read from left to right

\text{Revenue} = \text{Orders} \times \text{Average order value}

(1)

\text{Orders} = \text{Active customers} \times \text{Orders per customer}, \quad \text{Active} = \text{New} + \text{Returning}

(2)

Each leaf lands on a team: marketing acquires new customers, CRM brings them back, the catalogue team works on basket size. Every one of these leaves can be computed from the Olist tables.

Late deliveries

An order is late when the time it actually took exceeds the time promised at checkout. The actual time splits into three stages (payment approval, seller dispatch, carrier transit), each measured between two timestamps of the orders table. The tree points to where time is lost, and to whom to talk, before a single chart is drawn.

\text{late} \iff T_{\text{approval}} + T_{\text{dispatch}} + T_{\text{transit}} > T_{\text{promised}}

(3)

Remark (Missing data is a finding). When a leaf cannot be computed from the tables, the deck suggests marking it with a question mark rather than deleting it. A gap in the data tells the decision owner something too.

Back to contents.

Leading and lagging indicators, and Goodhart's law

Some indicators only confirm the result after the fact, others warn you early enough to act, and any indicator turned into a target can be gamed.

A lagging indicator reports the outcome once it is known: monthly revenue, average review score, late delivery rate. A leading indicator moves first, early enough to intervene: for instance the number of orders still sitting with the seller two days after purchase, or the share of new sellers who make a first sale within a month. By the time a review score falls, the late parcels have already been delivered. A sound tree keeps lagging indicators near the top and leading ones near the leaves.

It can be measured with data you actually hold.
A named person owns it and can act on it.
It responds when that person acts.
It is hard to game.

The last criterion becomes critical once the indicator is a target. The deck quotes Goodhart's law in Marilyn Strathern's 1997 wording: a measure that becomes a target stops being a good measure. On Olist, a delivery indicator can be made to look better on paper while customers wait no less. The defence is to pair any indicator that can be gamed with a second one that exposes the side effect.

Back to contents.

Meet the data: what does one row mean?

Before counting anything, know what a single row of each table stands for, because mixing tables of different detail is the commonest source of wrong numbers.

The case is the order history Olist released as open data: roughly 100,000 orders placed between 2016 and 2018, spread over nine related tables (orders, items, payments, reviews, customers, sellers, products, a category translation and geolocation), anonymised and published under the CC BY-NC-SA 4.0 licence. The orders table sits at the centre; an order can have several items and several payments, and usually one review.

Granularity, what a row represents, is called in the deck the most underrated question in analytics. In order_items a row is an item, not an order; in the payments table a card plus a voucher gives two rows; the geolocation table repeats each postcode prefix many times, so joining on it multiplies rows unless it is summarised first (the subject of SQL for managers).

**Table 2:** Counting rows of the items table counts items, not orders (the deck's illustration).
Order	Item number	Rows in order_items
A	1, 2, 3	3
B	1	1
Total	2 orders	4 rows

The data stop in 2018 on purpose. Payment habits, delivery networks and customer expectations have moved since, and part of the exercise is to say which findings one would still trust today and which would need fresh data.

Back to contents.

Every cleaning choice changes the answer

Cleaning data is a series of decisions, not a button, and the same file can give different results depending on what you decide and write down.

Four problems turn up in every real dataset, and Olist has all of them: duplicates, missing values (undelivered orders have no delivery date, some products have no category), outliers (an item with an extreme price or freight charge: real, or a typo?) and inconsistent formats (Portuguese categories, city names spelt several ways, dates stored as text). No tool settles them alone, because the right treatment depends on the question.

**Table 3:** Four illustrative orders, one with no delivery date yet. One late order is certain; order 4 is the open question.
Treatment of order 4	Late orders	Orders counted	Late delivery rate
Counted as late	2	4	50%
Silently read as on time	1	4	25%
Left out of the count	1	3	33%

Same data, three answers. Counting the open order as late can suit a study of lateness; leaving it out suits a study of delivered orders. The dangerous line is the middle one: a spreadsheet formula that compares an empty cell with a date returns zero, so the order counts as on time without anyone having decided it.

A cleaning log, as the deck asks for it

Work on a copy. The original file is never edited.
One line per step. What was done, why, and how many rows it added or removed.
Fix what matters for the question. Everything else is logged as a known limitation rather than silently patched.
Keep it with the result. When two people get different numbers, the explanation is almost always in a cleaning choice.

Pivot tables, and four checks before trusting one

A pivot table should answer one question, stated aloud before it is built: what goes in rows, what is measured, what is filtered out. A ranking of revenue by customer state mostly shows where customers live. Before quoting a pivot, the deck runs four quick checks: compare its grand total with the source file, make sure the unit counted is the order and not the row, prefer rates to raw counts when groups differ in size, and look at the spread before quoting any average.

Back to contents.

Key takeaways

Name the decision before opening the data; a dashboard that answers no question is wasted effort.
Place every question on the ladder (descriptive, diagnostic, predictive, prescriptive) to know what it will cost and what it can deliver.
A precise question states the decision at stake, how success is measured, what falls in scope, and who acts on the answer.
A KPI tree stops only when each leaf is measurable and owned; keep leading indicators near the leaves and pair the ones that can be gamed.
Know what one row of each table means before you add or count anything.
Each cleaning choice changes the result, so write it down with its reason and the number of rows it touched.

Glossary

Descriptive analytics: Analysis that reports what happened, such as a rate or a total over a period.
Diagnostic analytics: Analysis that looks for the causes of an observed outcome.
Predictive analytics: Analysis that estimates what is likely to happen, usually with a model.
Prescriptive analytics: Analysis that recommends an action, often for each case separately.
KPI tree: A diagram that splits a goal into its drivers until each leaf can be computed and is assigned to someone.
Leading indicator: An indicator that moves before the outcome, early enough to act on.
Lagging indicator: An indicator that reports the outcome once it is known.
Goodhart's law: The observation that a measure used as a target tends to lose its value as a measure.
Granularity: What a single row of a table represents: an order, an item, a payment, a customer.
Outlier: A value far from the others, to be checked before it is kept, corrected or excluded.
Missing value: An empty cell; how it is treated must be decided according to the question.
Cleaning log: A record of each cleaning step: what, why and how many rows it affected.
Pivot table: A spreadsheet summary that groups rows by one field and aggregates a measure.

The other notes of the course

One public summary per deck, in the order of the course.

Session 1From data to decisions
Session 2Data visualisation and storytelling
Session 3SQL essentials for managers
Session 4Predictive analytics for decision-makers
Session 5Generative AI, GDPR and the AI Act
Session 6Pitching data insights

All the notes, as a reading list

About these notes

Written by the lecturer from the slides of the deck, as a public summary: the key ideas, the formulas and one worked example. The exercises, their solutions, the tests and the grading stay in the deck, for the students of the course.

Revision: 16 October 2026.