Glossary · Logic & flow
Hidden field
A hidden field is a value stored alongside a response that the respondent never sees and never types. It is declared on the survey, read from the query string of the link they followed, and saved with their answers. It is the standard way to record which channel, campaign or list a response came from — and the standard way to destroy anonymity by accident, because anything you put in the link ends up in the data.
Also called: URL parameter, query string field.
How it works
You declare the field on the survey — say source — and then
distribute different links:
…/s/abc123?source=leaflet…/s/abc123?source=email-reminder…/s/abc123?source=library-poster
The respondent sees an identical survey in every case. The value is read from
the query string and stored with their response, so the export has a
source column you can split every other answer by. A respondent
who arrives on the bare link with no parameter simply has an empty value
there.
What it is good for
- Channel attribution. Which route actually brought people in — the thing you need in order to spend next year's outreach budget sensibly, and the thing almost nobody records at the time.
- Splitting analysis by cohort. Site, ward, cohort, event date. One survey instead of six near-identical copies, which also means one export instead of six.
- Context you already know. If the link goes out from a system that knows the service area, passing it in saves asking a question the respondent would have to answer worse than your database can.
- Keeping a survey short. Every fact you can carry in the link is a question you do not have to ask, and question count is what respondents judge a survey by.
A worked example
A charity runs one feedback survey across nine services. Rather than nine
surveys, it declares two hidden fields, service and
region, and gives each service manager a pre-built link. The
export then supports "satisfaction by service", "satisfaction by region" and
the overall figure, from one set of questions asked identically everywhere —
which is the only way those comparisons are valid in the first place.
The trap
Anything you put in the link ends up in the data.
Hidden means hidden from the respondent's screen. It is not hidden from the respondent — the value is in the URL in their address bar, visible to anyone they forward the link to — and it is certainly not hidden from your export.
Put a staff number, a case reference, an NHS number or an email address in a hidden field and your survey is no longer anonymous, no matter what the introduction says. If you have promised anonymity, only pass values that describe a channel or a group, never a person.
Common mistakes
- Trusting the value. Anyone can edit the query string. A hidden field records what the link said, not a verified fact, so never use one as an access control or a proof of eligibility.
-
Inconsistent values.
source=Email,source=emailandsource=e-mailare three categories in your pivot table. Write the links from one list. - Forgetting the bare link. Someone always shares the URL without the parameter. Decide in advance whether blank means "unknown" or "direct", and label it that way in the report.
- Not declaring the field before you send. A parameter the survey does not know about is discarded, and responses collected before you added the field cannot be back-filled.
In NumoForms
Hidden fields are declared per survey, read from the query string, and stored with the response. They appear in the CSV export alongside the answers. Note that conditional logic rules read respondents' answers, so if you want a hidden value to change which questions appear, ask the equivalent question instead — or use separate surveys. Hidden fields pair naturally with response rate work — tag each channel, then compare what each one actually returned — and they are the first thing to audit when someone asks whether a survey is genuinely anonymous.
Related terms
Anonymous survey
An anonymous survey collects nothing that can identify a respondent. How it differs from a confidential survey, and the details that quietly break anonymity.
Piping
Piping inserts an answer a respondent already gave into later question text. The token syntax, the unanswered-token failure case, and when to stop piping.
Conditional logic
Conditional logic shows or hides a survey question based on an earlier answer. How any/all matching works, and what it does to exports and scoring.
Data Protection Impact Assessment (DPIA)
A DPIA is a documented assessment of privacy risk, required by Article 35 UK GDPR for high-risk processing. What must be in one, when, and who has to write it.
Back to the survey glossary, or read the product overview to see how these ideas map onto the builder.
One survey, every channel tagged.
Declare a field on the survey, put the value in the link, and it is stored with the response without appearing on the respondent's screen. Nine services or six leaflets then share one set of questions and one export, which is the only way those comparisons hold.
- Values read from the query string on arrival
- Their own columns in the CSV, beside the answers
- Every fact carried in the link is a question saved