A Field Guide to Reading a Data Profile Report

The dataset someone else built

A colleague hands off a dataset — theirs, or one that's been sitting in a shared folder for a year — and asks you to build this month's report on it. You open it, it looks reasonable, and you start building. Three days later, someone asks why 400 orders are missing a sales rep, and the honest answer is that you didn't check, because nothing prompted you to.

This isn't a story about carelessness. It's what happens by default: a spreadsheet or a table doesn't come with a trust score attached. Either you take the time to manually audit it — scrolling, sorting, spot-checking columns — or you don't, and you find out about the gaps from whoever notices them in your finished report.

Why this keeps happening

Checking a dataset properly before building on it takes real effort if there's no tool doing it for you: sort by every column that matters, look for blanks, check whether a "number" column actually contains numbers throughout, count how many distinct values show up somewhere you'd expect just a few. Most people do a partial version of this — eyeball a few hundred rows and call it good — because the full version is tedious enough that skipping it is the path of least resistance, until it isn't.

What a data profile actually does instead

DataQloo profiles every column automatically — during the Import Wizard's flow, and again in a Browse node's Profile tab for any workflow's result. Five things, computed for every column, before you build anything on top of it:

Fill rate and null percentage

What it is: the percentage of rows that have a real value in this column, versus the percentage that are blank.

How to read it: in the canonical Sales Orders dataset, sales_rep profiles at roughly 98.4% filled — about 1.6% of rows have no rep recorded. That's not necessarily a problem; it might mean those orders came through a channel with no assigned rep. What matters is whether the number matches what you'd expect. If a column you assumed was always populated shows up at 92% instead of 100%, that's the moment to ask why before building a report that quietly excludes or mis-groups the missing 8%.

Rule of thumb: a fill rate below 100% isn't automatically bad. A fill rate that's lower than you expected is the actual signal.

Unique count and distinct values

What it is: how many distinct values actually appear in a column, versus the total row count.

How to read it: a region column with 4 unique values across 10,000 rows is exactly what you'd expect from a fixed, small category — a healthy, boring number. A customer column with close to 10,000 unique values, on the other hand, would be a red flag in a dataset that's supposed to represent a customer base of a few dozen repeat buyers — it would suggest the same customer is being recorded under slightly different names or formatting, not that there are genuinely that many distinct customers.

Rule of thumb: for a column that should be a small, fixed category (status, region, product), the unique count should be small and stable. For a column that should have real repeats (customer, sales rep), a unique count close to the total row count is worth a second look before trusting it.

Inferred type

What it is: what DataQloo determined the column's actual data type to be — integer, decimal, date, text, and so on — based on the real values in it, not a label someone assigned.

How to read it: a revenue column inferred as text instead of a number almost always means something's mixed into it that shouldn't be — a stray currency symbol, a thousands separator that didn't parse, or a handful of rows where the field wasn't populated the way the rest of the column was. This is one of the fastest ways to catch a formatting problem before it turns into a silently wrong sum three steps later.

Rule of thumb: if a column's inferred type doesn't match what the column is supposed to hold, stop and check it before doing anything else with that column.

Average or top value

What it is: for a numeric column, the average; for a categorical column, the most common value.

How to read it: this is the fastest sanity check available — an average revenue per order that's off by an order of magnitude from what you'd expect usually means a units problem (cents vs. dollars, or a decimal that didn't parse correctly) rather than a genuine business change. For a categorical column, a "top value" that dominates far more than expected — say, one status value accounting for far more rows than it should — is worth a second look too.

Reading a profile as a decision, not a report

None of these five stats need to be memorized in isolation — read together, they answer one question: is this dataset shaped the way I think it is? A profile that matches expectations across all five means it's safe to build on. A profile that surprises you on even one of them is worth five minutes of investigation before the report built on top of it goes anywhere.

Under the hood, these stats are themselves the result of straightforward aggregate queries — fill rate, for instance, is close to:

SELECT
  count(sales_rep) AS filled,
  count(*) AS total,
  round(100.0 * count(sales_rep) / count(*), 1) AS fill_rate_pct
FROM sales_orders

Nothing about profiling is a black box — it's the same kind of query anyone would write by hand to check a column, run automatically for every column, every time.

Key takeaways

• A data profile answers one practical question — is this dataset shaped the way you think it is — across five specific stats: fill rate, unique count, inferred type, and average/top value.
• A "concerning" number isn't a fixed threshold — it's a number that doesn't match what you expected for that specific column.
• Profiling happens before you build, not after something looks wrong — the entire point is catching a mismatch while it's a five-minute check, not after it's baked into a report someone already trusted.
• The same profile appears whether the data came from a file import or a live PostgreSQL connection — see how to check fill rate and null percentage for it in context of an actual import.

Next

Once you know what a profile is telling you, the natural next step is acting on it — see how to clean a messy spreadsheet without writing formulas for turning a profile finding into an actual Filter condition. For the broader concept behind this page, see what data profiling actually is.