What is branching logic in a lead generation quiz?
Branching logic is a deterministic rule that uses a prior answer or calculated state to select the next question, section, result, or handoff. It changes the route through the quiz. Scoring is different: it accumulates or compares values. One quiz may use branching, scoring, both, or neither.
A branch should have a named input, an exact rule, a destination, a fallback, and an owner. Without those elements it is an undocumented exception, not a reproducible decision.
Related: Trace questions to their outcomes and actions · Use transparent scoring when the route does not need to change
Use this five-step branching decision tree
Evaluate the branch before implementing it. Stop at the first defensible reason, then record the exact claimed benefit and the path evidence needed for release.
| Decision | Branch when… | Otherwise… |
|---|---|---|
| 1. Relevance | A prior answer makes a later question irrelevant or inappropriate | Keep the shared question |
| 2. Result evidence | Different results require different evidence to remain correct | Use one common evidence path |
| 3. Next action | Consent, review, handoff, or follow-up genuinely changes | Keep one operational route |
| 4. Participant benefit | The branch removes work or prevents a misleading question | Do not branch for visual novelty |
| 5. Testability | Every route, boundary, fallback, and payload can be inventoried and tested | Simplify or split the experience |
Choose the smallest branching pattern that solves the problem
A skip branch removes questions that no longer apply. A diagnostic branch collects a different evidence set for a different result. A routing branch sends an answer to a different review, consent, or follow-up path. These patterns may be combined, but each added decision expands the state that must be explained and tested.
| Situation | Default design | Reason |
|---|---|---|
| Everyone needs the same inputs | Linear | One route is easier to understand, measure, and maintain |
| A prior answer makes later items irrelevant | Skip branch | Removes avoidable effort |
| Different results require different evidence | Diagnostic branch | Protects result correctness |
| A response needs distinct consent or review | Routing branch | Aligns handling with the supplied answer |
| Only the visual order changes | Linear | Complexity rises without a defined decision benefit |
Estimate branching complexity before building
Draw every decision node and terminal result. Count reachable paths rather than multiplying every answer combination. For each route, record the shortest and longest question count, the boundary that selects it, the visible result, stored state, analytics sequence, and downstream action.
Complexity is not inherently defective; unowned complexity is. If a reviewer cannot enumerate the routes, explain tie and missing-answer behavior, or reproduce the payload sent downstream, simplify the model or separate it into distinct experiences.
| Inventory field | Record | Release question |
|---|---|---|
| Route ID | Stable name for the reachable path | Can tests and analytics use the same identifier? |
| Entry rule | Exact answer, state, or boundary | Are gaps, overlaps, ties, and unknown values defined? |
| Path length | Minimum and maximum questions shown | Does progress remain truthful on this route? |
| Terminal state | Result, fallback, or handoff | Is every terminal state supported by collected evidence? |
| Recovery | Back, reload, resume, and stale-state behavior | Can the participant recover without a silent route change? |
Worked example: branch only when the evidence changes
A readiness quiz asks whether the participant already uses a documented process. A “no” answer skips three performance questions and asks two setup-constraint questions. A “yes” answer skips the setup questions and asks about performance. The routes produce different next-step guidance because they rely on different evidence.
This branch is defensible: it removes irrelevant work and protects result meaning. A rule that shows the same questions and result but changes only the background color does not meet the decision tree. The example is illustrative, not a benchmark or a claim about an ideal number of paths.
How should a team test the claimed branching benefit?
Define the benefit before release: fewer irrelevant question views, lower consecutive-step loss on the affected route, more stable result assignment, or a more accurate handoff. Validate the event implementation before comparing versions. Record eligible starts, branch decisions, question views, valid answers, result views, and the downstream quality measure with stable definitions.
If the team tests a new branching model, change only that model where practical, keep assignment stable, predeclare the primary metric and guardrails, and document the decision rule. Do not attribute a lift to branching when instrumentation, audience, or follow-up changed at the same time.
Related: Use stable quiz-funnel measurement denominators · Plan a controlled quiz experiment
Sources: Google Analytics, Funnel exploration · NIST, Choosing an experimental design
Keep branched paths understandable and recoverable
W3C guidance recommends dividing long forms into logical stages, repeating overall instructions, making optional stages recognizable, and communicating progress. It specifically notes that the number of steps may depend on earlier survey answers. For every branch, test the page title or step heading, progress language, keyboard order, focus destination, instructions, validation, back navigation, reload, and resume behavior.
Do not announce a fixed total that becomes false after a route decision. Instructions must remain available to assistive technology and should identify required or optional input and relevant formats without relying on placeholder text alone.
Related: Run the full accessibility checklist
Sources: W3C, Multi-page forms · W3C, Form instructions
Use this blocking release checklist
Release the branch only when its purpose, reachable paths, fallbacks, and evidence are reviewable by someone other than the builder.
- Every branch removes irrelevant effort, changes required evidence, or changes a meaningful next action
- A diagram and inventory cover every reachable and intentionally unreachable route
- Shortest and longest paths, boundaries, ties, missing answers, back, reload, and resume pass
- Progress and instructions remain accurate on every route
- Visible result, stored state, analytics event, and downstream payload agree
- Unknown or stale rule values reach a neutral fallback without inventing an answer
- The branch owner, rule version, verification date, and correction path are recorded
- Monitoring uses stable denominators and an explicit downstream-quality guardrail
Related: After choosing to branch, run the implementation QA matrix
Evidence
How to reproduce the method
Reproduce the method with the five-step branching decision tree, pattern table, reachable-path complexity inventory, worked example, measurement specification, and blocking release checklist. It makes the pre-build branching decision separately from the implementation QA process.
Limitation
Where this conclusion stops
Branching may reduce irrelevant effort but increases design, testing, analytics, and maintenance cost. This decision tree does not guarantee higher completion, better leads, or fair and lawful routing. High-stakes decisions require appropriate subject-matter, privacy, legal, and fairness review. No product capability, live campaign, or performance benchmark was tested for this guide.
Sources and verification
What this guide relies on
- The Lead Quiz Review editorial methodology
- W3C, Multi-page forms
- W3C, Form instructions
- Google Analytics, Funnel exploration
- NIST, Choosing an experimental design
Sources and method checked September 18, 2026. External standards are linked to their primary publishers. Request a factual correction.