How to Name Spreadsheet Columns Before Publishing a Public Dataset

Before publishing a spreadsheet, rename its columns so every header answers one question: what does this value mean?

A clean result might start like this:

station_id,observation_date,rainfall_mm,max_air_temperature_celsius,quality_status

Each label identifies one concept, measurement columns carry their units, and no name appears twice. That makes the public table easier to scan, filter and reuse without requiring readers to reverse-engineer the source workbook.

Use specific, units-bearing labels

Replace broad labels such as value, amount, rate, date and name with the measured concept and its context.

Avoid	Prefer	Why
temp	air_temperature_celsius	Names the subject and unit
rate	unemployment_rate_percent	Identifies the statistic and percentage convention
amount	grant_amount_usd	Identifies the measure and currency
date	observation_date	Distinguishes it from publication or update dates
name	station_name	Identifies the entity being named
status	quality_status	Identifies what the status describes

Put the unit in the header when all values in a measurement column use the same unit. Keep the cells numeric: use 14.2, not 14.2 mm. If values currently mix metres and feet, dollars and euros, or percentages and decimal shares, normalize or separate them before naming the column. The workflow is covered in preparing a public data table with consistent units.

A unit-bearing name is especially useful in CSV. A CSV header row supplies human-readable column titles; richer details such as expected datatypes, required values and uniqueness rules can be supplied through separate metadata, as the W3C CSV on the Web primer explains. A clear header does not replace metadata, but it prevents the most immediate ambiguity for people viewing the table.

For percentages, make the stored scale explicit:

• response_rate_percent for values such as 82.5
• response_rate_decimal for values such as 0.825

Do not call both versions response_rate. If the choice is still open, settle the representation before export using the percentages-versus-decimals workflow.

Replace duplicate headers with meaning, not suffixes

Duplicate names often appear after joining worksheets or exporting a report:

site,name,temperature,temperature,date,date

Do not resolve this as temperature_1, temperature_2, date_1 and date_2. Those names are technically distinct but still force readers to guess. Name the role of each field instead:

site_id,site_name,air_temperature_celsius,water_temperature_celsius,observation_date,publication_date

Research-data guidance from NJIT recommends that every heading in a file be unique, treating names as case-insensitive, and that units appear in headings as well as metadata where possible. It also recommends a single header row because import tools may not parse multirow headings reliably (NJIT tabular-data guidelines).

Treat Total, total and TOTAL as duplicates. Case-only differences are easy to overlook and may collapse in downstream software.

When two columns genuinely represent repeated periods or groups, include that dimension:

• population_2024 and population_2025
• origin_country_code and destination_country_code
• planned_cost_usd and actual_cost_usd

If years will keep accumulating, consider a long table instead: use one year column and one population_count column, with a separate row for each place-year observation. That avoids changing the schema for every release.

Keep one stable naming convention

For a downloadable file or API-facing dataset, a conservative convention is:

• lowercase letters, numbers and underscores;
• a letter at the beginning;
• no leading or trailing spaces;
• no line breaks or merged header cells;
• one unique name per column;
• the same name in every release unless the field’s meaning changes.

For example, choose publication_date rather than alternating among Publication Date, pub_date and datePublished. Stability matters when readers build filters, scripts or comparisons around a published schema.

Do not force the entire definition into the header. Keep the label concise, then document the details in a spreadsheet data dictionary. The W3C tabular-data model similarly distinguishes column titles in the header row from richer annotations that can be supplied in separate metadata files (W3C tabular data model).

Run a final header audit

Before publishing, inspect the exported CSV or spreadsheet—not only the working sheet—and confirm:

1. There is exactly one header row.
2. Every header is populated and unique without relying on capitalization.
3. Each label identifies one concept.
4. Every measurement label states its unit or scale.
5. Dates distinguish observation, coverage, publication and update events.
6. Codes and IDs identify the system or entity they belong to.
7. Headers contain no accidental spaces, line breaks or spreadsheet-generated suffixes.
8. The data dictionary uses the exact published names.

Finally, sort and filter the prepared file using the same headers readers will see. If a filter named amount or date_2 still needs explanation before anyone can use it, rename it before the dataset becomes public.