Prepare survey response tables for public sharing without exposing respondents

Do not publish a lightly edited export in which each row still represents a respondent. Build a separate publication table from aggregated results, then check that neither its cells nor its labels expose personal information.

The finished file should let a reader answer three questions without opening the original questionnaire: What was asked? Who or what does each figure cover? How was the figure calculated?

Use one row per result, not one row per person

A practical long-format publication table looks like this:

question_id	question_label	response_option	subgroup	count	denominator	percent	status
Q01	How satisfied were you with the service?	Very satisfied	All respondents	84	200	42.0	published
Q01	How satisfied were you with the service?	Satisfied	All respondents	66	200	33.0	published
Q01	How satisfied were you with the service?	Neither satisfied nor dissatisfied	All respondents	28	200	14.0	published

This is illustrative data, not a real survey result.

Keep the stable question_id for joins and updates, but give readers the full, readable question_label. Do not make them decode headers such as Q1_2 or sat_a. Put answer options in their own column rather than spreading them across dozens of cryptic fields.

Long format also works well for sorting, filtering and charting. If readers mainly need a compact comparison, you can create a wide presentation table later; retain the long table as the documented source.

Build the public table in a separate workflow

Keep the identifiable response file in its controlled environment. Produce a new public-output file containing only the fields needed for publication.

Removing names is not enough. Demographics and answer combinations can still identify a respondent, while replacing a name with a respondent code usually leaves pseudonymised personal data rather than anonymous information. The UK Information Commissioner’s Office says pseudonymous information remains personal data when people can be identified using separately held information (ICO).

Before publishing:

1. Remove direct identifiers, contact details, respondent IDs, timestamps precise enough to identify someone and collection metadata such as IP addresses.
2. Exclude raw free-text answers unless they were explicitly cleared for publication. Free text can disclose a workplace, rare condition, family relationship or other identifying detail.
3. Inspect combinations of indirect identifiers such as age, occupation, location and ethnicity—not just each field alone.
4. Review small cells and outliers. Merge categories, reduce precision or suppress results where the combination could expose a person.
5. Recheck the finished table against information already public or likely to be known by readers.

UK Data Service guidance specifically recommends checking frequencies for small counts, examining outliers and reviewing string variables for disclosive information; its listed techniques include aggregation, broader categories and suppression (UK Data Service). There is no context-free cell-size rule that makes every table safe. Set a rule appropriate to the population, subject and plausible outside knowledge, record it, and apply it consistently. If the result cannot be made genuinely anonymous without becoming misleading, do not put it on a public page.

Make every number interpretable

For each result, publish both the value and its base:

• Count: number of responses in the displayed category.
• Denominator: number included in that calculation.
• Percent: count ÷ denominator × 100 for unweighted results.
• Status or note: published, suppressed, not applicable or insufficient base.

Do not encode a suppressed value as zero. Do not merge a skipped question with “None,” “Do not know” or “Prefer not to answer.” AAPOR recommends representing no response separately from substantive answer options and reporting the statistical adjustments used (AAPOR). For ambiguous source values, use the checks in Empty CSV Field vs Zero vs Missing Value.

If percentages are weighted, label them weighted_percent and state the unweighted base. If respondents could select more than one option, add a note that percentages may total more than 100%. If rounding causes 99.9% or 100.1%, say so rather than altering a category to force the total.

Preserve question context

Alongside the table—or in a separate data dictionary—include:

• exact question wording;
• answer options and their order;
• who was eligible to answer;
• routing or skip logic that changes the denominator;
• fieldwork dates and collection mode;
• target population and sampling method;
• achieved sample size and response-rate definition, when applicable;
• whether figures are weighted and, at a useful level, how;
• missing-value, rounding and suppression rules;
• source, publisher, release date, licence and contact route;
• known limitations.

These details prevent a clean-looking table from implying more than the survey supports. AAPOR’s transparency recommendations include the sample size, weighting attributes, full question and answer text, survey mode, population, sample construction and recruitment method (AAPOR).

Validate the file as data

Use one header row, one meaning per column and consistent value types. Confirm that:

• every row has the expected number of fields;
• question IDs map to exactly one question version unless versioning is explicit;
• each count is a non-negative integer or a documented suppression marker;
• denominators match the stated inclusion rule;
• recomputed percentages match the published values within the rounding tolerance;
• category totals reconcile where the question permits one answer;
• subgroup labels and time periods use consistent spelling;
• formulas have been replaced by final values before export.

A CSV header can carry human-readable column titles, but CSV itself has no built-in mechanism for declaring column types or uniqueness constraints. W3C’s tabular-data primer therefore describes separate metadata and schemas for documentation and validation (W3C). At minimum, publish a data dictionary listing each column’s meaning, type, allowed values, unit and missing-value convention. Check the distinction between headers and observations in CSV Header Row vs Data Row.

Check the public presentation

Give the table a concise caption and a nearby note explaining its scope, denominator, units, weighting and suppression marks. Use real row and column headers rather than relying on bold text or colour. W3C’s accessibility tutorial says accessible data tables need markup that identifies header cells, data cells and their relationships; captions help readers find and understand a table (W3C WAI).

Finally, test the published page as a reader would: sort counts numerically, filter every categorical field, search for a question phrase, inspect the smallest subgroups and download the public file. The publication copy—not the private workbook—is the artifact that needs to pass the privacy, arithmetic and documentation checks.

A defensible release contains aggregated results, readable questions, explicit bases and enough methodology to interpret the numbers. It contains no respondent-level rows “just in case.”