Data exploration: turn a spreadsheet into a checkable public table

Before publishing a spreadsheet, answer three questions: What does each row represent? Which values need explanation? Can a reader reproduce your main comparison?

Data exploration means inspecting a dataset’s structure, values and patterns before settling on an interpretation. It includes numerical checks and charts—not just browsing rows. NIST describes exploratory data analysis as an approach to uncovering structure, detecting anomalies and checking assumptions, rather than simply a collection of graphics. NIST’s EDA handbook

The practical output is a reviewed file, a short set of definitions and a public table that preserves the context behind the numbers.

1. Define the rows before comparing values

Suppose you want to publish monthly visits to three library branches. Start with this fictional practice dataset, not real library statistics:

month,branch,visits,reporting_status
2026-01,North,1200,reported
2026-01,South,800,reported
2026-01,East,600,reported
2026-02,North,1350,reported
2026-02,South,0,closed
2026-02,East,,not_reported

Define the structure alongside the file:

• One row: one branch in one calendar month.
• month: reporting month, formatted as YYYY-MM.
• branch: a branch label; its combination with month should be unique.
• visits: recorded visits, not distinct visitors; a non-negative integer when available.
• reporting_status: whether visits were reported, the branch was closed, or the count was not reported. In this example, South was closed for the whole of February.

This makes the key distinction explicit: South’s February zero is a confirmed count, while East’s blank is unavailable data. Do not replace the blank with zero. For more on that distinction, see empty fields, zero and missing values.

2. Profile the file before interpreting it

A data profile is a compact inventory of what the file contains. In your spreadsheet or analysis tool, check:

Check	Expected result for the practice file
Data rows, excluding the header	6
Distinct branches	3
Distinct months	2
Duplicate branch–month pairs	0
Available visit counts	5
Missing visit counts	1
Confirmed zero counts	1
Minimum and maximum available counts	0 and 1,350

Also inspect data types. visits should behave as a number, while branch names remain text. Look for inconsistent labels such as North, north and North, but confirm they refer to the same entity before merging them.

Keep an untouched source copy and record any changes in a working copy. A corrected label and an excluded row are different decisions; both should be explainable.

3. Explore one question at a time

Start with: How did recorded visits change between January and February at each branch?

Filter to each branch and compare the two months:

Branch	January visits	February visits	Interpretation
North	1,200	1,350	Increase of 150 visits, or 12.5%
South	800	0	Down to zero during a full-month closure
East	600	Not reported	Change cannot be calculated

North’s percentage change is (1350 − 1200) / 1200 × 100 = 12.5%. That describes a change in recorded visits; it does not explain why the change happened.

Avoid comparing totals across all three branches as though both months were complete. February lacks East’s count, so the two totals would have different coverage. Either compare a clearly stated matched subset or report the coverage gap alongside the totals.

For a larger dataset, choose a chart to answer a specific question:

• Bar chart: compare branches within a selected month.
• Histogram: inspect the distribution of available branch-month counts.
• Line chart: inspect changes over several months, preserving gaps for unavailable counts.

If a value looks unusual, investigate its source and context before removing it. NIST cautions that outliers can contain useful information about the underlying process or recording process. In this example, zero deserves explanation, not automatic deletion. NIST’s guidance on outliers

4. Publish the data and its interpretation rules

Prepare a release copy containing only information cleared for public sharing. Do not upload sensitive records, private notes or identifiers merely because they helped your analysis.

TablePage’s homepage, checked on October 14, 2026, lists support for CSV, TSV, XLSX and XLS uploads and describes the result as a public dataset page with a shareable link and a filterable table. TablePage

Supply these notes with your public page or accompanying article:

• Dataset title, source and release date. Label this practice file as fictional.
• Row definition, units and reporting period.
• Meaning of blanks, zeros and status values.
• Any corrections, exclusions or incomplete coverage.
• A checkable comparison: “Filter to North: recorded visits rose from 1,200 to 1,350.”

Use a table caption and summary to name the dataset and explain how to read it.

Finally, inspect the published page—not just the source spreadsheet. Confirm that all six rows remain, 1350 is interpreted numerically, South’s zero is retained, and East’s missing count is not displayed as zero. Filter to February and verify that each count still appears beside its reporting status. The reader should be able to explore the numbers without losing the explanation that makes them usable.