How a datum is built, and what happens before a chart exists

The chart is the last object, not the first. When someone looks at an occupancy of 72% or an average daily rate (ADR) of 148 euros — Invented example, not real data — that number has already passed through sources, filters, joins and, above all, through someone who decided what counts as “a night,” “a booking,” or “a guest.” The chart summarizes a set of rows. It is not a photograph of the world. It is a claim about a set that someone built.

Put another way: the dashboard does not measure the hotel. It measures the table it was handed. If that table mixed nights with bookings, or treated a cancellation as a stay, the chart will repeat it with false confidence. That is why it pays to ask not only what the bar says, but which set it is talking about.

Two people usually show up on that path, and they are often folded into the same name: “the data person.” The data engineer works on the sources, the pipelines, the grain, the contracts, the freshness, and the reproducibility: that the same question returns the same rows tomorrow. The analyst (or the data scientist, when the job is called that) works on the question, the comparison, what would change the decision, and what the chart hides. They pass work to each other. Neither of them should pretend to own the other’s stretch. We will come back to them later, but not as hiring cards: as two distinct points in the evolution of one and the same datum.

Phase 1 Origin: the fact is not yet a datum

Before any table there is a fact: someone booked, someone cancelled, a sensor measured a temperature, a cashier recorded a charge. That fact is not yet a datum. A datum is a record: a representation that someone (or a system) decided to keep, in a certain form. The science of measurement has known this for a long time: to measure is not only to look; it is to choose what counts, and in which units.

In a hotel, the occupied night does not “exist” in nature as a number. There is a guest who slept, or a booking that was cancelled, or a room that stayed empty. The datum is born when the reservation system writes a row. If that distinction is skipped, the number on the dashboard is treated as if it were the fact itself. It is not. It is a representation, and representations fail.

If this phase is skipped: no one can say which fact the number is talking about, or whether the fact happened outside the system that measured it.

Phase 2 Capture: someone writes something down

Capture is the moment the fact becomes bits. It can be automatic (a PMS that stores every change of status) or human (a receptionist who corrects a date by hand). What matters is not the technology. It is that capture fixes an instant, an identifier, and a set of fields. What is not captured cannot be analyzed later. And what is captured badly travels intact all the way to the chart.

Invented example, not real data: if the booking channel marks “cancelled” and the hotel, at the same time, leaves the room marked “occupied” because nobody updated the status, there are two captures of the same fact. The analysis that follows will inherit the contradiction. Capture is not an administrative detail. It is the first measurement.

If this phase is skipped: the fact happened and the set does not contain it, or it contains it twice, with opposite meanings.

Phase 3 Landing: a copy you can work on

Source systems are not built so that someone can ask long questions of them. They are built to operate: to sell, to charge, to open the door. Landing is the step in which those records arrive at a stable place — a warehouse, a lake, an analysis database — where they can be read without breaking the production system.

This is where reproducibility enters, a simple idea and a hard one: if the same question is asked tomorrow, the same rows should come back, unless the facts have changed. Without a controlled landing, each person downloads a different CSV, applies a different filter, and argues over figures that never measured the same set. The fight is not about the business. It is about two copies.

If this phase is skipped: the analysis lives in loose files; tomorrow the figure can no longer be repeated, and no one can explain where it came from.

Phase 4 Definition: the measure includes the rule

A definition is not a documentary luxury. It is part of the measurement. “Guest” may be the person who booked, the person who paid, the person who stayed, or the loyalty account. “Night” may be the calendar night, the night of arrival, or each unit of inventory sold. “Cancellation” may mean a cancellation before arrival, a no-show, or a modification that leaves the room free.

Without a written definition, two teams can look at the same dashboard and talk about different things. The chart does not warn you. It only draws. That is why a metric without the phrase “this counts as…” is not a complete metric. It is a number with a gap. The reader fills the gap with intuition, and each reader’s intuition is a different one.

Put another way: the definition does not sit beside the datum; it constitutes it. Changing the definition is changing the measurement, even when the raw rows do not move.

If this phase is skipped: the same name measures different things depending on who asks, and no one notices the disagreement until the decisions collide.

Phase 5 Cleaning: several crafts under one verb

“Cleaning” sounds like a single gesture. Under that verb sit different crafts, each one with a decision. This is not about brushing away dust. It is about choosing what to do when the record does not fit the rule. The tables that follow are invented examples; they are not real data from any hotel.

Invented example, not real data — kinds of dirt

Type	What shows up	The decision it forces
Duplicate	Two rows with the same stay id and the same nights.	Keep one, merge them, or look into whether they were two charges?
Status	A night with status “cancelled” that is still in the occupancy sum.	Does occupancy count only arrivals, or active bookings as well?
Format	The date “03/10/2026” beside “2026-10-03”.	Day/month or month/day? A wrong parse moves the night into another month.
Null	An empty revenue field.	Empty is not zero. Zero means “we charged nothing.” Null means “we do not know.”
Identity	Hotel “HTL-12,” which came to be called “HTL-12B.”	Link them as the same place, or split the series in two?
Type	A rate stored as text: “148.50 €”.	It has to be turned into a number; otherwise it cannot be summed or averaged.

The null case deserves one more sentence. In the arithmetic of tables, treating a missing value as zero pushes the mean downward and pretends to certainty. Treating it as missing forces a decision: drop the row, impute it, or leave it out of the average? All three options are legitimate. What is not legitimate is failing to say so. In the same way, a cancelled night does not automatically imply that “every cancelled booking leaves the room unoccupied in the operational sense of that day”: it depends on when it was cancelled, on whether the room was resold, and on how occupancy is defined. Cleaning forces that precision; it does not replace it with a slogan.

If this phase is skipped: the error disguises itself as a business pattern, and the chart displays it with the same confidence as a true signal.

Phase 6 Grain: one row is a what

Grain is the answer to a short question: what does one row stand for? A row per night is not the same thing as a row per booking. Mixing them gives no warning. It only changes, in silence, the average daily rate, the occupancy, and the average length of stay.

The idea underneath is arithmetic. An average depends on the denominator. If the denominator shifts from “nights” to “bookings” without anyone saying so, the quotient is talking about something else. This is not a nuance. It is a different measurement.

Invented example, not real data — the grain trap

Three bookings in an example hotel. Illustrative figures; they are not industry figures. Invented example, not real data.

Booking	Nights	Total revenue	Revenue per night
A	1	100 €	100 €
B	3	240 €	80 €
C	2	200 €	100 €

If the grain is the booking (three rows): “average” ADR = (100 + 80 + 100) / 3 = 93.33 €.

If the grain is the night (six rows: 100; 80, 80, 80; 100, 100): ADR = (100+80+80+80+100+100) / 6 = 90 €.

Same operational reality, two different averages. The short booking at 100 € weighs the same as the three-night booking when the average is taken by booking; when the average is taken by night, the three nights at 80 € pull the mean down. Occupancy and average length of stay move by the same logic: the denominator decides.

If this phase is skipped: the metrics move because the denominator changed, not because the business changed, and no one sees it in the title of the chart.

Phase 7 Checking: is the set still true?

Before the chart, a short list helps, almost boring, and useful for that reason. Freshness: how far do the data reach? A count of rows against the source: did everything arrive? A known total: does the sum of revenue match the close the business already trusts? The written definition beside the metric. And what changed since yesterday: a sharp jump is usually a pipeline failure before it is a commercial miracle.

One of the quietest breaks is fan-out: a join on a key that is not unique. If a booking is joined to a charges table that has three lines per booking, the booking is tripled. Revenue is summed three times. The chart of “occupancy” or of “ADR” inherits the error and still looks clean.

Invented example, not real data — fan-out in a join

Before the join	After (key not unique)
Bookings: 1 row (R1, 2 nights, 200 €). Charges: 3 rows (R1 room, R1 minibar, R1 parking).	Result: 3 rows of R1. If “booking revenue” is summed without care: 200 + 200 + 200 = 600 €. Nights counted: 2 + 2 + 2 = 6 instead of 2.

The arithmetic did not lie. The join multiplied the grain. The check on counts (“do we still have one row per booking?”) would have caught it before the chart.

If this phase is skipped: the failure travels to the dashboard, where it already looks like a business conclusion.

Phase 8 Analysis: the question, asked of a set that already exists

Only here does the chart come in with a point. Analysis does not begin by drawing. It begins with a question that could change a decision: is this week’s drop in occupancy a channel, a segment, or an error of definition? Does the rise in ADR come from fewer cheap nights, or from more expensive ones? The chart is a way of seeing a set that has already been filtered and already defined. Use it to explore without having built that set, and you are asking the drawing to do the work of the earlier phases.

In 2012, Kandel, Paepcke, Hellerstein, and Heer presented at IEEE VAST a study based on interviews with 35 data analysts from 25 organizations. One analyst placed the work of integrating, cleaning, and transforming data at more than half of their time. Six of the more technical analysts used interactive charts only to lay out a story they already knew: they did not explore with those charts, because they could not work the data inside those tools. The chart was the slide, not the place where the thinking happened.

The idea that matters does not need industry percentages. It is the same idea we opened with: do not start with the chart. Ask the question of the data the company already has, in the place where that data already sits. If the tool demands a separate copy merely so that it can draw, the slow part gets done twice.

Two people on the same path

The data engineer usually lives between origin and checking: sources, landing, column contracts, freshness, a stable grain, reproducibility. They build the set so that tomorrow it is the same set. The analyst usually lives between definition and analysis: they form the question, choose the comparison, notice what the chart does not show, and hand back to the engineer whatever the table still cannot answer.

What one hands the other fits in a few lines. The engineer passes along a table with its grain declared, a dictionary of columns, a mark of freshness, and a note of what was left out. The analyst returns a question that table does not yet answer, a definition that ought to become a column, or a break that looks like a change in the business and is a pipeline failure. Neither should pretend that the other stretch “is already solved” merely because the dashboard looks clean.

What is left when you read a number

Whoever runs a hotel, or some other operational business, ends up reading figures that have already traveled this path, even if they never see the path. That is why a pricing dashboard, or a reporting one, is not a mirror: it is the end of a chain of decisions about what was captured, what was defined, and what was left out. Before arguing over whether the rate “is right,” then, it helps to know which grain it answers to, and which nights went into the average. The useful question is therefore not only “what does the chart say,” but “which set is it talking about, and who built it.”

A datum is not found. It is built. The chart arrives at the end, once that construction has already happened — or once someone pretended it was not required.