Data and Statistics: From Spreadsheet to Public Summary

Suppose you want to publish this statement: “80% of completed requests were handled within three days.” A useful public page should show more than the percentage. It should let readers inspect the supporting records—or a safe aggregate table—and understand which requests counted.

Here is a small, fictional spreadsheet example showing how to turn data into statistics and publish both clearly.

Data is the input; statistics summarize it

Data consists of recorded values, such as a request’s completion time. Statistics are calculated summaries, such as the median completion time or the percentage meeting a target. Michigan State University Libraries describes this distinction as raw information versus the results of analysis.

The distinction is about what the numbers represent, not their file format. A spreadsheet can contain individual observations, calculated statistics, or both. An official table of annual rates is a dataset you can reuse, even though its values are already statistical summaries.

For publication, distinguish three things:

• Observations: what each row records.
• Calculations: how you turn those rows into a summary.
• Interpretation: what the summary does—and does not—tell readers.

Start with a checkable example

The following records are synthetic, not real service data. Each row represents one request completed during a fictional September reporting period. For this example, turnaround_days is the difference between the completion date and the receipt date, measured in calendar days.

request_id	turnaround_days
R001	1
R002	2
R003	2
R004	3
R005	12

Set the target explicitly: three calendar days or fewer. All five requests have known turnaround times and belong in the denominator—the total against which the qualifying count is divided.

Statistic	Calculation	Result
Completed requests with known turnaround	Count the records	5
Mean turnaround	(1 + 2 + 2 + 3 + 12) / 5	4 days
Median turnaround	Middle value after sorting	2 days
Share within target	4 / 5 × 100	80%

The mean and median answer different questions. The mean uses every value; the median identifies the middle of the ordered values. Here, the 12-day request pulls the mean above the median. NIST’s statistical handbook explains why extreme values affect the mean more than the median.

A suitable summary is:

In this fictional example, four of five completed requests with known turnaround times met the three-calendar-day target. Median turnaround was two days; mean turnaround was four days.

That wording names the denominator and avoids treating five fictional records as evidence of wider performance.

Prepare the public table without losing meaning

Keep observation rows separate from summary rows. Adding “Average” beneath R005 in the same numeric column creates a row that is not a request and can be counted or averaged again by mistake.

For a reusable summary table, use one row per reporting period and explicit fields such as:

• period
• completed_requests_known_turnaround
• requests_within_3_days
• within_target_pct
• mean_turnaround_days
• median_turnaround_days

Document whether a percentage field stores 80 or 0.8. Keep numbers numeric rather than adding “days” inside each cell; put units in the header and field definitions.

For real data, define the eligible population before calculating. Do open requests belong in a separate measure? How are unknown completion times handled? Do not silently convert unknown values to zero. See the guide to empty fields, zeros and missing values for that distinction.

Add context, then publish a reviewed copy

Prepare a short note alongside the table containing:

• Scope: the period, population and meaning of one row.
• Definitions: start and end points for turnaround, calendar versus business days, target threshold and denominator.
• Provenance: original source links, retrieval date and transformations.
• Limitations: missing records, exclusions and any source-provided uncertainty.
• Release information: publication date or version, plus applicable reuse terms.

These are practical applications of W3C’s Data on the Web Best Practices, which recommends descriptive metadata, licensing information, provenance, quality information and version indicators. For this example, the source note should simply identify the records as synthetic.

Never upload sensitive information to a public dataset page. Removing names alone is not enough: W3C warns that combining data from multiple sources can identify individuals. Use only records cleared for public release or appropriately reviewed aggregates.

As of October 11, 2026, TablePage accepts CSV, TSV, XLSX and XLS files and generates a public, shareable dataset page with a filterable table. Upload the reviewed release copy, then compare the published row count, headers and representative values against your file. Keep the definitions and source note available in the accompanying article or documentation.

Before sharing the link, verify that a reader can reproduce the headline statistic from the public table. In this example, that means finding both the four qualifying requests and the five-request denominator—not just seeing “80%.”