What is survey logic?
Survey logic uses conditions to determine which questions a respondent sees or where they go next. It can make a questionnaire more relevant by showing follow-up questions only when they apply. The design should also preserve enough information to interpret the results correctly.
For example, someone who did not attend an event should not be asked to rate its sessions. They may still have useful feedback about why they did not attend. Those two paths answer different questions and should remain distinguishable in the analysis.
Logic does not require a persistent personal record. It can operate within an anonymous survey. If a later survey uses earlier information, the design needs an appropriate way to connect that information and respect the intended privacy arrangement.
Common types of survey logic
Product terminology varies, and some platforms combine these functions. Check the rules and precedence in the tool you use.
Scroll horizontally to see all columns →
| Type | Purpose | Example |
|---|---|---|
| Display logic | Show or hide a question when a condition is met | Ask which session was attended only when attendance is confirmed |
| Skip logic | Move to another question, page or endpoint | Send a non-attendee past the session-rating section |
| Branching | Route respondents through different groups of questions | Give members and event partners different relevant sections |
| Answer piping | Reuse a prior answer in later wording or choices | Ask a follow-up about the service selected earlier |
| Validation | Check whether an entered answer meets a rule | Require a whole number where the question asks for a count |
Validation is related to form behavior, but it is not the same as routing. A value can pass a format check and still be inaccurate. Likewise, a well-routed respondent can still misunderstand a question.
Example: an event feedback survey
Start with the question: “Did you attend any part of the event?” Give clear options that cover the intended audience. Then map the paths before configuring the form.
- Attended: ask which sessions they attended, then show relevant experience questions.
- Did not attend: ask an optional question about the reason and skip experience ratings.
- Not sure or unable to classify: provide an appropriate route without forcing a false answer.
- All relevant respondents: offer a final optional comment and explain any follow-up choice.
If respondents can attend several sessions, account for more than one selected option. Decide whether they will rate each attended session or only a specified one. The resulting ratings will have different denominators.
Keep a common question visible to every group you intend to compare. If only dissatisfied attendees receive a question about improvements, the answers describe that selected group, not everyone who attended.
For practical wording, use the event feedback survey guide.
Write conditions so someone else can check them
Use a short logic table with the question, condition, destination and fallback. Distinguish conditions that all must be true from conditions where any one is sufficient.
Scroll horizontally to see all columns →
| Rule | Meaning | Test case |
|---|---|---|
| Attended AND selected workshop A | Both conditions must be true | A person who attended only workshop B should not see A’s rating |
| Selected workshop A OR workshop B | Either condition can satisfy the rule | A person selecting both should still follow a defined route |
| No relevant option selected | A fallback needs to be specified | A blank answer must not accidentally lead to an irrelevant required question |
Test how the software handles missing values, multiple selections and overlapping rules. Do not rely on the order you happened to enter conditions. A hidden required question, conflicting route or return to the same page can prevent completion.
Keep the simplest logic that serves the research question. Every additional branch creates another path to test and another population to explain in the results.
Keep “not asked” separate from “unanswered”
A blank cell can have several meanings. The respondent may never have seen the question, may have declined to answer, may have left the survey early or may have encountered a technical issue. Those situations should not be treated as zero.
Plan how you will identify each relevant state using the instrument, branch conditions and available response metadata. Some tools preserve useful status information; others require additional configuration or careful interpretation. Inspect an actual export rather than assuming all platforms behave the same way.
Scroll horizontally to see all columns →
| State | Interpretation |
|---|---|
| Not asked by design | The branch excluded the question |
| Asked but unanswered | The respondent had the opportunity but supplied no answer |
| Not applicable | An explicit answer indicating the question does not apply |
| Zero | An actual numeric answer, where zero is valid |
| Not reached | The respondent did not progress to that part of the questionnaire |
If the captured data cannot reliably distinguish two states, report that limitation rather than inventing a reason for each blank. Better planning for the next wave may be more defensible than retroactively assigning categories.
How branching changes the denominator
In a fictional survey, 100 people respond. Sixty report attending the event and are eligible to see a session question. Fifty answer it, and 40 give a positive rating under the stated definition.
- The positive share is 40 ÷ 50 = 80% of valid answers to that question.
- The answer coverage is 50 ÷ 60 = 83.3% of the attendee group eligible for the question, assuming they all reached it.
- The 40 non-attendees are excluded by design, not dissatisfied attendees or missing attendee ratings.
Label the chart with the question’s eligible group and valid-answer count. If respondents abandoned the survey before reaching the question, distinguish eligibility from actual exposure where the data allows it.
A filtered question cannot establish a result for people who were never asked. For a wider analysis process, see how to analyze survey data.
Using prior information in a follow-up survey
Reusing appropriate context can reduce repeated questions. First decide which information is stable and which needs confirmation. Membership status, job, location or service use may have changed since the earlier response.
If a previous answer controls a branch, retain the relevant source and date. Let the respondent correct current information where appropriate. An outdated record should not silently exclude someone from a question that now applies.
For anonymous repeated surveys, compare group results without claiming that the same individuals changed. For identified follow-up, verify matching, permissions and which earlier information may be reused. The data model should serve the measurement purpose.
Use local questions with shared reporting definitions
A membership network or multi-site program may need different local questionnaires. Agree the small set of common measures required for shared decisions, then allow relevant branches and local detail.
The data dictionary should define the shared question or measure, eligible population, reporting period, response values and treatment of missing data. Two sites asking similarly named questions are not automatically comparable if different groups reach them.
For example, one site may ask every active member about access, while another asks only event attendees. The resulting percentages describe different populations. Align the intended coverage or keep the results separate with accurate labels.
Test every meaningful path before launch
Use a test register that includes expected answers, expected path and expected data output. The form looking correct on one successful journey is not enough.
- Each main branch and the fallback route.
- Multiple selections and overlapping conditions.
- Blank or declined answers where allowed.
- Back navigation and a changed earlier answer.
- Mobile use, language versions and relevant accessibility checks.
- Save-and-return behavior, if supported and required.
- The exported or reported distinction between ineligible and unanswered items.
After changing an earlier answer, check whether a previously entered downstream answer remains, clears or is excluded from analysis. Document the intended behavior. Retained answers to newly hidden questions can otherwise confuse reporting.
Run a small pilot with people who resemble the intended respondents. Ask where a question felt irrelevant or where the path was unclear. Keep test submissions separate from the live dataset.
Govern changes after the survey starts
Record the version and effective date of important logic changes. If a rule was wrong, identify the affected responses and decide whether they can be used, need follow-up or must be excluded from a specific analysis.
Do not silently combine results from incompatible paths. A corrected form improves future collection but does not retroactively ask a question that earlier respondents never saw.
Sopact’s focus on collection, analysis and governance is relevant here: the useful outcome is a team that can manage definitions, understand the included records and review findings. Test the particular logic and export behavior in the proposed setup rather than assuming validation eliminates all cleanup.
Choose software by the full path
Bring a realistic branching example to the demo. Ask the team to configure it, submit several paths, change an answer and explain the resulting dataset. Then calculate one branched result with its denominator.
The survey software guide covers buying requirements and implementation cost. For multi-source collection, read mixed-mode data collection.
Frequently asked questions
What is the difference between skip and display logic?
Display logic controls whether an item appears; skip logic changes where a respondent goes next. Exact terminology and behavior vary by product.
Does branching improve data quality automatically?
No. It can make questions more relevant, but incorrect rules can exclude respondents or create misleading missing data. Test both the experience and the resulting analysis.
Does survey logic require personal identifiers?
No. Logic can use answers within an anonymous survey. Reusing information across waves requires an appropriate connection and privacy arrangement.
Should a skipped answer count as zero?
No. A question not asked by design is different from a valid numeric zero. Preserve that distinction in calculations.
Can we change logic after launch?
Sometimes, but record the change and assess which responses are affected. A corrected path does not fill evidence that earlier respondents were never asked to provide.
What should a logic test include?
Main branches, missing answers, multiple selections, changed earlier answers, fallback behavior and the final export. Check the denominator for each reported question.
