Data vs Information vs Insight

Someone drops a spreadsheet in the channel and says, “Here’s the data.” Another person replies with a chart and says, “Here’s the insight.” A third person, who has to make a budget call by Friday, still feels weirdly uninformed.

They are not being difficult. They are reacting to three different things that people keep calling by the same casual names. In this post we separate data, information, and insight in plain language, with workplace examples you can reuse in meetings without sounding like a textbook.

This is part 2 of Analytics foundations. Part 1 covered what problem you are actually solving. Here we talk about what you are holding in your hands once the problem is clear: raw facts, organized facts, or something that actually changes a decision.

What you’ll learn

• Clear definitions of data, information, and insight (no jargon tax)
• One running workplace example at each layer
• How to tell which layer a slide or dashboard is stuck on
• A simple ladder you can climb on purpose (not by accident)
• How this fits roles, literacy, and the rest of the foundations series

Why the mix-up costs real money

Teams ship “data dumps” and call them insights. Leaders ask for “more data” when they already have more rows than they can read. Analysts feel pressure to decorate tables until they look smart. None of that is evil. All of it burns calendar time.

If you only remember one idea from this article, make it this: more data is not the same as better understanding, and better understanding is not the same as a decision you trust. Each step up the ladder needs different work, different skills, and a different definition of “done.”

For how analytics sits next to BI and data science as job labels, see Analytics, BI, Data Science, and More. That post is about roles and disciplines. This one is about the raw material those roles shape.

Data: the raw stuff

Data is recorded facts or measurements, still close to how they were captured. A row in a database. A sensor reading. A form submission. A line in a log file. On their own, data points do not argue for a plan. They just exist.

Everyday examples:

• A list of order IDs with timestamps and dollar amounts
• Support tickets exported to CSV
• Pageview events from your site
• Survey answers sitting in a form tool

Data can be correct and still useless for a decision if nobody has organized it, defined it, or asked a question of it. Data can also be messy: missing fields, wrong types, duplicate keys. Messy data is still data. Cleaning it is work you do on data so you can build information later.

Workplace example (data layer)

Ops exports last month’s shipments: 12,441 rows, one per package, with columns for warehouse, carrier, ship date, and delivery date. That export is data. Opening it and scrolling is not analysis yet. It is inventory of facts.

Information: data with structure and meaning

Information is data that has been cleaned, labeled, filtered, summarized, or placed in context so a human can understand what is going on. Information answers “what happened?” and often “how much?” or “where?” It still might not tell you what to do next.

You create information when you:

• Agree on definitions (what counts as a “late” shipment?)
• Pick a grain (one row = one package, not one order)
• Filter noise (test accounts, cancelled orders)
• Aggregate (late rate by warehouse and week)
• Present a clear table or chart with labeled axes and units

A dashboard full of accurate KPIs is usually information, not insight, until someone ties a number to a choice. That is fine. Organizations need reliable information every day. The mistake is calling the dashboard “insights” and then wondering why nobody acts.

Workplace example (information layer)

From the same shipment export, you compute: percent of packages delivered more than two days after ship date, by warehouse, for the last eight complete weeks. You show a small table and a line chart. Viewers can see Warehouse B’s late rate climbed from 4% to 11%. That is solid information. People now know what happened. They still need a next step.

Insight: understanding that changes a decision

Insight is a specific understanding, grounded in information, that reduces uncertainty about a decision. Insight is not a vibe, a hot take, or a slide title with a lightning bolt emoji. Insight answers “so what?” and points toward “now what?”

Good insight usually includes:

• A claim a skeptic could check against the information
• A link to a decision owner and a real choice
• Caveats (what you do not know yet)
• A suggested action or experiment, even if the action is “investigate X first”

Insight is rarer than information because it requires judgment, domain knowledge, and the problem framing from part 1. Two analysts can share the same information and disagree on insight. That disagreement is healthy if it is about interpretations and tradeoffs, not about whether the table was built correctly.

Workplace example (insight layer)

You dig one level deeper into Warehouse B. The rise in late packages lines up with a carrier change for ground shipping on the west region, not with staffing hours. You recommend: (1) keep the new carrier for two more weeks on a small SKU set only, (2) compare late rate and cost per package against the previous carrier on a fair sample, (3) decide go or no-go at next ops review. The decision owner is Ops. The number is no longer “interesting.” It is a lever.

That package (claim + evidence + decision + next step) is insight. A chart alone was not.

Side-by-side: same story, three layers

If your meeting ends with “interesting, thanks” and no owner takes an action item, you probably delivered information (or even raw data) dressed as insight.

A tiny worked example with numbers

Imagine five support tickets (data):

Information: After-hours tickets (hour ≥ 20 or hour < 8) are 3 of 5. Billing tickets average much longer resolution than login tickets.

Insight (example): If the decision is whether to staff a night billing specialist, the pattern that matters is not “we have tickets at night.” It is “billing issues created at night sit almost a full day.” Recommendation: pilot one after-hours billing responder two nights a week for a month, measure median resolve time for night billing tickets, then expand or stop.

Same five rows. Three different levels of usefulness. The jump from information to insight needed a decision (staffing), not a fancier chart.

Optional SQL: from rows to information

You do not need SQL to understand the ladder. When you implement, SQL is a common way to turn data into information. A sketch for the ticket idea:

-- Information: ticket counts and avg resolve time by daypart and category
-- Grain: one row per ticket (assumed in support_tickets)
SELECT
  CASE
    WHEN EXTRACT(HOUR FROM created_at) >= 20
      OR EXTRACT(HOUR FROM created_at) < 8
    THEN 'after_hours'
    ELSE 'business_hours'
  END AS daypart,
  category,
  COUNT(*) AS tickets,
  ROUND(AVG(resolve_hours), 1) AS avg_resolve_hours
FROM support_tickets
WHERE created_at >= CURRENT_DATE - INTERVAL '30 days'
  AND is_spam = FALSE
GROUP BY 1, 2
ORDER BY 1, 2;

That query produces information. The insight still lives in the sentence you write for the staffing decision, plus the caveats (seasonality, product launches, incomplete resolve timestamps). For checking machine-written SQL before you trust it, see How to Check AI-Written SQL Before You Ship It.

How to tell what you are looking at

Use this quick self-check on any slide, thread, or dashboard tile:

• Mostly data: raw tables, “here’s the extract,” no definitions, no summary of what changed
• Mostly information: clean metrics, trends, comparisons, clear labels, still no recommendation tied to an owner
• Insight: “Because of X, we recommend Y for owner Z by date D, assuming A and B; next check is C.”

If your organization loves the word “insights” in folder names, translate in your head: “Is this folder full of charts (information) or decisions (insight)?” Rename your own work honestly. Clarity beats branding.

Climbing the ladder on purpose

A practical sequence for almost any request:

1. Frame the problem (part 1): decision, owner, deadline, success shape.
2. Locate data that could speak to it. List fields and grain. Note what is missing.
3. Build information: definitions, filters, summaries, one clear view.
4. Draft insight: one paragraph recommendation with caveats. If you cannot write it, you are not done, or the decision was never real.
5. Decide and learn: record what was chosen and what you will measure next (foreshadows part 3, the analytics loop).

Skipping steps is how you get beautiful information nobody uses, or “insight” that is actually someone’s opinion with a chart wallpaper.

Common mix-ups (and kinder fixes)

1. Calling a data dump “analysis”

Fix: Always add definitions and a one-screen summary of what moved. If you only have time for one chart, make it the one tied to the decision.

2. Calling every chart an insight

Fix: Reserve “insight” for the sentence that connects evidence to a choice. Charts are information vehicles.

3. Demanding insight with no decision owner

Fix: Go back to framing. Without an owner, the best you can do is information. That can still be valuable, but label it honestly.

4. Insight without checkable evidence

Fix: Point to the table, metric definition, and time window. Insight that cannot be audited becomes politics.

5. Stopping at information because insight feels “subjective”

Fix: Insight is judgment plus evidence, not pure opinion. Write the recommendation as a proposal: “Based on X, I recommend Y; risks are Z.” Invite challenge. That is adult collaboration, not soft science.

How this shows up in roles and literacy

Different jobs live on different rungs more of the time:

• Data engineering often ensures data is available, reliable, and movable.
• Analytics / BI often turns data into trusted information (metrics, self-serve, reports).
• Decision owners (PMs, marketers, ops leads, founders) need insight, even if an analyst drafts it with them.
• Data science may push into prediction and experiments, still worthless without a decision frame.

Everyone benefits from data literacy: knowing which layer you are on and what question it can honestly answer. For career maps, see Data Jobs Demystified.

Practice: label last week’s work

Take three deliverables from your last week (Slack answers count). For each, write one of: data / information / insight. Then ask:

• If it is data, what would it take to make information?
• If it is information, what decision could it serve, and who owns that decision?
• If it is insight, did anyone actually decide something?

Fifteen minutes of labeling will tell you whether your team is drowning in extracts, swimming in dashboards, or occasionally changing the business on purpose.

What’s next in this series

Part 3 covers the analytics loop: question to data to transform to answer to decision to measure again. That loop is how data, information, and insight keep cycling instead of dying in a slide archive. Later parts tackle “good enough” data and how to read numbers without fooling yourself.

When you are ready to build information with queries, the SQL series and Learn hub are waiting. Foundations first so the tools have somewhere useful to point.

FAQ

Is a KPI insight?

Usually no. A KPI is a carefully defined piece of information. Insight is what you conclude and recommend because of how that KPI (and related context) looks. See All About KPIs for metric design.

Can insight exist without new data?

Yes. Sometimes the breakthrough is connecting information you already have to a decision you were avoiding. New data is optional. New clarity is not.

Isn’t “insight” just a buzzword?

It became one because people overused it. You can still use the word if you back it with evidence and a decision. If that feels too loaded, say “recommendation with evidence” instead. The ladder matters more than the branding.

Where does machine learning fit?

Models consume data and produce scores or predictions, which are a form of information (or proposed insight if they directly drive a choice). Without a decision frame, a model is an expensive way to generate more numbers.

Quick recap

• Data = recorded facts, still raw.
• Information = structured, defined, summarized facts that answer “what happened?”
• Insight = understanding that reduces uncertainty for a real decision.
• Climb the ladder on purpose: frame, then data, then information, then insight.
• Label your work honestly so meetings stop rewarding decoration over decisions.

In one sentence: Data is what you captured, information is what you can understand from it, and insight is what you are willing to decide because of it.

Sources

Research and further reading used for this article:

• CMC Canada: Are you solving the right analytics problem? (problem clarity before methods)
• Indiana Wesleyan University: Data-driven decision-making overview (goals, quality, common pitfalls)
• AMS: What problem are we actually solving? (part 1 of this series)
• AMS: Analytics, BI, and data science differences
• AMS: What is data literacy?
• AMS: Data jobs demystified
• AMS: All about KPIs
• AMS: Learn hub

More definitions in Key Terms →

Merch on Etsy

Open store →

Y-Hat Coffee Mug View on Etsy → Excel is NOT a Database T-Shirt View on Etsy → Sigmoid Function Shirt View on Etsy → Mean Squared Error Shirt View on Etsy →