Branching logic (skip logic)

Picture this: a company is running a customer survey. The first question is "Have you used our delivery service?". The customer answers "No" — and immediately sees the next question: "Rate the delivery speed from 1 to 5".

The respondent is confused: they just said they hadn't used the delivery service, and now they're being asked to rate it. The options: give a random rating (and pollute the data), abandon the survey (and leave for good), or pick "N/A" — if such an option even exists. All three scenarios are easy to avoid if the survey can react to answers — that is, if branching logic is set up in it. Answer "No" and you move on to the next block, skipping irrelevant questions. Answer "Yes" and you land on the delivery questions. Each respondent sees only what is relevant to their experience.

What is branching logic

Branching logic (skip logic, conditional logic, branching) is a mechanism in which the next question or page of a survey is determined by the answer to the previous question (or by a set of conditions). Instead of a linear sequence of "question 1 → question 2 → question 3", the survey becomes adaptive: the respondent's path depends on what they answer.

Other names for this mechanism: skip logic, conditional logic, branching, routing. The essence is the same: the survey "understands" answers and adjusts to the respondent. This is one of the key tools that sets a professional survey apart from a primitive paper form.

Why you need branching logic

Shortening the survey for each respondent. A survey may contain 40 questions, but a particular respondent will see only 15 — the ones relevant to their experience. This sharply reduces the abandonment rate: people don't quit out of fatigue, because the survey feels short and relevant.

Higher data quality. When people answer questions that apply to them, their answers are more meaningful and accurate. Irrelevant questions provoke random answers that pollute the data and distort the statistics.

A personalized experience. The respondent feels that the survey is "listening" to them. This boosts engagement and trust. "You indicated that you use the 'Business' plan — tell us more about working with integrations" — a transition like that feels like a conversation rather than an interrogation off a checklist.

One survey instead of several. Without branching, you have to create separate surveys for different segments: one for new customers, another for long-standing ones, a third for those who have left. With branching, a single survey with different paths is enough — easier to create, distribute and analyze.

Types of branching logic

Question skip

The simplest type: if the answer is X, skip question Y and move to Z. "Do you have children?" — No → skip the block of questions about children's products. This is enough for most basic scenarios.

Page skip (page branching)

The respondent is redirected not to a specific question but to an entire page (or block). The survey is divided into thematic sections: delivery, support, product quality, payment. The respondent only reaches the sections that match their experience.

Branching on multiple conditions

The path is determined not by a single answer but by a combination: "If they are on the 'Business' plan AND have contacted support in the past month → show the block about support quality". This lets you build complex decision trees within a single survey.

Branching on hidden variables

The path is determined not by the respondent's answers but by data passed through the URL. If the link contains ?role=hr, the respondent sees the HR block of questions. If ?role=dev, the block for developers. For more on the mechanism, see the article "Hidden variables".

Jumping to the end screen

A special case of branching: if an answer does not meet the criteria, the survey ends. It is used in screening questions: "Have you purchased our product in the last 3 months?" — No → "Thank you, this survey is intended for recent buyers". The respondent doesn't waste time on an irrelevant survey, and the data isn't polluted.

Use cases

A satisfaction survey with branching by score. The first question is an NPS: "How likely are you to recommend us?". If 0–6 (detractor) → "What could we improve?" (open-ended question). If 9–10 (promoter) → "What do you like most?". If 7–8 (passive) → "What would raise your score?". Each group gets a question that matches its mood.

A marketing quiz with different outcomes. In a quiz, each path leads to its own results screen. "Which learning format suits you?" — answers to 5 questions determine: "An intensive is right for you" or "A self-paced course is right for you". The result is personalized, and conversion into a lead is higher.

An HR survey for different roles. One survey for the entire company. The first question: "Your department?" — Sales, Development, Marketing, Support. Each department sees a common block (10 questions) + a specific block (5 questions for its own department). The total: 15 questions instead of 30, while all the data lands in a single report.

A post-event feedback survey. "Did you attend the workshop?" — Yes → questions about the workshop. "Were you at the evening networking session?" — Yes → questions about networking. The respondent rates only what they took part in.

How to set up branching in SurveyNinja

In the SurveyNinja builder, branching logic is set up visually — without any coding. A detailed guide is in the help center.

A condition on a question. Choose the trigger question, set the condition ("answer equals", "answer contains", "answer is greater than N"), and specify the action: go to a question, go to a page, finish the survey. Conditions can be combined with "AND" / "OR".

A condition on a hidden variable. If the variable tariff equals business, show the block of questions for business customers. This lets you route respondents before they have even answered the first question.

A visual map of paths. SurveyNinja shows a logic tree: which questions are linked to which, and where each answer option leads. This helps you avoid getting lost in complex surveys with many branches.

Common mistakes

"Dead" paths. A branch leads to a question that has been deleted or moved. The respondent hits a dead end — the survey freezes or jumps unpredictably. Always check the logic after every change to the survey structure.

An overly complex tree. 15 levels of nesting, conditions at every step, intersecting paths — and within a week even the author doesn't remember how it works. If the logic can't be explained to a colleague in two minutes, it's too complex. Simplify: group questions into thematic pages, use branching at the page level rather than at the level of individual questions.

Not testing every path. You checked the main path — but you didn't check what happens when a respondent picks "Other" in question 3 and "No" in question 7. Every combination of answers is a potential path, and each one needs to be walked through. Use the preview and go through the survey 5–10 times, choosing different options.

Branching with no visible reason. A respondent answers a question — and suddenly skips past three screens. They don't understand what happened and may think the survey is broken. If the jump is significant, add a short explanation: "Based on your answers, the next block of questions does not apply — we're moving on to the final part".

Forgetting about analytics. If some respondents see 10 questions and others see 20, a direct comparison of "number of answers per question" will be incorrect. Keep in mind that in a branching survey the answer bases for different questions are different.

Branching logic is the difference between a monologue survey and a dialogue survey. The monologue asks everyone the same questions without listening to the answers. The dialogue adjusts: it hears that the respondent hasn't used the delivery service — and doesn't ask about it. The result: shorter, more accurate, more pleasant for the respondent and more useful for the analyst.