Recording speaker demographics: fields, granularity, and where the privacy line sits

Why per-speaker records, not a summary line

It is tempting to record demographics once, as an aggregate in the dataset description: ages from 18 to 65, balanced gender, twelve regions. Aggregates cannot be recomputed, filtered, or re-sliced, and every serious downstream use eventually wants exactly that — evaluate on older speakers, shift a fine-tuning set toward one region, check whether accuracy differs across accents.

A per-speaker record keeps those options alive. The rule that makes it work: one row per speaker, a stable pseudonymous id, and each fact stored at the finest granularity the consent covers, with banding applied at analysis time rather than at collection time. Bands chosen during collection freeze every future analysis to the bands someone picked in week one.

The field list that earns its keep

Every field costs money to collect and carries a little risk, so the list should be short and deliberate.

• Speaker id: pseudonymous, stable across sessions, and never the legal name in the working table.
• Age: year of birth or age at first session, where the consent covers it, banded only at analysis time.
• Gender: a category scheme chosen on purpose, with a stated option for declined, and a note on whether the value was self-reported or assigned by the recordist. Those are different facts.
• Language background: native language or languages, other languages spoken, and the variety the speaker identifies with.
• Region: where the speaker grew up and where they live now, as two fields, because they answer different questions about accent.
• Session facts: dates, device, environment, and the guideline version in force. Not demographics, but they belong in the same row, because later analyses slice on both.
• Consent linkage: which consent version was signed and when, so the record can be checked against the basis for holding it at all.

Self-reported and judged are two different fields

Two of these fields are identity facts and two are perceptual judgments, and conflating them counts among the most frequent defects in a demographic table. Age, gender, and language background are things a speaker states about themselves. Accent labels assigned by a listener are the recordist's impression of the speech. Both are useful, and they disagree — a speaker may identify with a variety that a listener does not hear, and a listener may hear a variety the speaker does not claim.

Keep the two kinds in separate columns and label which is which, or downstream work will treat one as the other. The same discipline applies when the dataset will be used to evaluate accent handling: the evaluation label describes the speech as heard, while the speaker's own identification describes the person. A table with only one of the two can answer only half of the questions that will be asked of it.

The privacy boundary

A demographics table is personal data even with names removed, because a combination of region, age, gender, and a rare language can point at a handful of people — and in a small speaker pool, at exactly one row. Three rules keep the table defensible.

• Collect only what the consent covers. If the form never mentioned occupation, occupation does not get collected, however useful it looks in the analysis plan.
• Keep the mapping between pseudonymous ids and identities in a separate store, under separate access, with the same deletion clock as the audio. Removing a speaker has to remove the row too.
• Treat special categories — health, ethnicity, precise location — as opt-in with an explicit basis, and first ask whether the project can proceed without them. Often the analysis can use a coarser field that carries far less risk.

Common defects in demographic data

The defects below are cheap to prevent before the first session and expensive to fix afterwards, which is the entire argument for settling the schema in advance.

• Blanks that mean different things: unknown, declined, and not asked are three distinct facts, and a single empty cell merges them into one.
• Free-text regions and languages: the same region spelled four ways cannot be grouped without a cleanup pass that guesses.
• Estimated values mixed with reported values, with nothing recording which is which.
• Aggregates computed once and the raw rows discarded, which freezes every future analysis to the bands someone chose at the start.

The test to apply before storing a field

One question settles most borderline cases: could this table, on its own, identify a speaker or expose a fact about them they did not agree to share? If a combination of fields narrows to one person, the combination is the problem, and the fix is coarsening at the storage layer — storing age in five-year bands for the smallest pools, collapsing rare regions into larger ones — rather than hoping nobody ever joins the tables.