What Data Actually Is (And Three Myths About It)

Everyone in your organisation says "data". Very few agree on what they mean. Here is the version that lets you follow a technical conversation.

Data is a table

In its most common form, data is a spreadsheet. Rows are the individual things — one customer, one transaction, one patient visit. Columns are the facts about each thing.

Property size (sqft)	Bedrooms	Postcode	Age (years)	Sold price
850	2	641004	12	₹42,00,000
1,400	3	641004	4	₹78,00,000
620	1	641012	25	₹28,50,000

To build a model that estimates a property's price, the first four columns are the input and the bold column is the label — the thing you want predicted. Which column is the label is a choice, not a property of the data. The same table could predict the postcode from the price, if anyone wanted that.

This is worth internalising, because it demystifies a lot of vendor language. When someone says "our AI ingests your operational data and surfaces predictive insight", they mean: we put your table into a model and pick a column to predict.

Structured and unstructured

Structured data fits the table above: numbers and categories in labelled columns. Sales records, sensor readings, transaction logs.

Unstructured data is everything else: emails, photos, PDFs, audio recordings, free-text notes, video. It does not have neat columns.

For decades unstructured data was nearly useless to statistical systems. The big change of the past fifteen years is that machine learning got good at it — which is why AI suddenly became relevant to functions that never had "data" in the spreadsheet sense. A law firm has enormous data. It is all prose.

Three myths worth killing

Myth 1: "Collect data first, figure out what to do with it later."

This is the single most expensive mistake non-technical leaders make, and it sounds prudent, which is why it survives. The trouble is that data collected without a purpose is usually missing the one column that would have made it useful. A retailer logs every transaction for three years, then asks whether AI can reduce returns — and discovers nobody ever recorded why an item was returned. Three years of data, no label.

Work in the other direction. Decide what you want predicted, then check whether the input and the label exist. If they do not, the first project is to start capturing them, and you will have useful data in months rather than a warehouse of the wrong thing.

Myth 2: "More data is always better."

More relevant data is better. More data of the wrong kind is a storage bill. Ten thousand well-labelled examples of the exact thing you care about will beat ten million rows of loosely related logs.

There is a sharper version of this: data has a shelf life. Customer behaviour from before a pricing change, or before a pandemic, may actively mislead a model about today.

Myth 3: "We have lots of data, so we must be sitting on value."

Data has value when it is relevant to a decision somebody makes, labelled, and accessible. Miss any of the three and the value is theoretical. The most common failure is the third: the data exists, but in four systems that do not talk to each other, owned by three departments with different definitions of "customer".

In 2008 Google launched Flu Trends, which estimated flu prevalence from what people searched for. The idea was elegant, and early results were genuinely impressive — search behaviour tracked official surveillance data closely, and did it faster.

Then it drifted. Researchers writing in Science in March 2014 — Lazer, Kennedy, King and Vespignani, in a paper titled "The Parable of Google Flu: Traps in Big Data Analysis" — found that between August 2011 and September 2013, Flu Trends over-predicted flu prevalence in 100 out of 108 weeks. At points it estimated more than double the proportion of flu-like doctor visits that the CDC reported, despite having been built specifically to predict the CDC's own numbers.

What went wrong is instructive and has nothing to do with the algorithm being weak. The relationship between searching for flu symptoms and having flu is not a law of nature. It shifts with media coverage, with Google's own changes to autocomplete and suggested searches, and with how anxious people are. The model had learned a correlation that was real when it was trained and less real afterwards.

The authors' phrase for the underlying error was "big data hubris" — the assumption that enough data substitutes for understanding the thing you are measuring.

Two lessons for a non-technical reader. First, a proxy is not the thing. Searches are a proxy for illness, clicks are a proxy for interest, timesheets are a proxy for effort. Models trained on proxies inherit every way the proxy can come apart from reality. Second, a model that worked is not a model that works. Anything trained on the past needs someone checking whether the past still resembles the present.

❓ Knowledge Check

A hospital administrator says: "We have twenty years of patient records, so we should be able to predict readmissions." What is the most important thing to check first?

📚 Flashcards1 / 6

Term

Row and column

Click to flip

Definition

A row is one thing (a customer, a transaction); columns are the facts about it. Which column is the label — the thing to be predicted — is a decision, not a property of the data.

Click to flip back

💡Key Takeaway

Data is a table: rows are things, columns are facts, and one chosen column is the label you want predicted. Unstructured data — text, images, audio — is now usable too, which is why AI reaches functions that never kept spreadsheets. Resist the three myths: do not collect before deciding what to predict, do not confuse volume with relevance, and do not assume stored data is valuable until it is labelled, relevant and actually accessible.