Методика · 19 июля 2026 г.

Логика переходов в анкете: ветвление вопросов

Логика переходов (ветвление, skip logic) — это правила, по которым следующий вопрос анкеты зависит от предыдущего ответа. Настраивается она как набор условий вида «если на вопрос 3 выбран вариант А — показать вопрос 4, иначе перейти к вопросу 7». Смысл прост: человек видит только те вопросы, которые к нему относятся, анкета становится короче и релевантнее, а завершаемость растёт. Плата за это — сложность: каждое ветвление создаёт новый путь, который нужно протестировать, и в анкете с десятком условий легко получить респондента, застрявшего в тупике или получившего вопрос не по адресу. Ниже — как проектировать ветвление, где ставить условия, как считать ответы по ветвям и как всё это проверять перед запуском.

Что такое логика переходов и зачем она нужна

В простой анкете все идут одним маршрутом: вопрос 1, вопрос 2, вопрос 3 — и так до конца. Логика переходов ломает эту прямую линию: маршрут человека зависит от того, как он отвечает. Спросили «пользовались ли вы нашей поддержкой за последние три месяца» — тем, кто ответил «да», показываете блок из пяти вопросов про качество поддержки, остальных отправляете дальше. В результате те, кто в поддержку не обращался, не мучаются вопросами «насколько быстро вам ответили», на которые честного ответа у них нет, а вы не собираете мусорные оценки от людей, которым нечего оценивать.

Это второй, более важный эффект. Очевидная польза ветвления — короче анкета и выше завершаемость. Неочевидная и более ценная — чистота данных. Человек, которому задали вопрос не по адресу, редко пропускает его: он что-нибудь отвечает. Ставит «нормально», выбирает средний вариант, кликает первое попавшееся. Эти ответы неотличимы от настоящих и разбавляют вашу статистику ровно посередине шкалы, притягивая любые метрики к нейтральной середине. Ветвление не даёт таким ответам появиться — и это его главная функция, а не экономия минуты респондента.

Виды логики: переход, показ, отсев

Под «логикой» в разных инструментах имеют в виду несколько разных механик. Полезно их различать, потому что они решают разные задачи и по-разному ведут себя при анализе.

Отдельно про пайпинг: формально это не ветвление, но работает он в связке с ним и заметно улучшает восприятие. Вопрос «Почему вы выбрали доставку курьером?» вместо «Почему вы выбрали этот вариант доставки?» читается как разговор, а не как форма. Цена — риск нелепости: если подставляемый текст пришёл из открытого поля, вы можете получить вопрос вида «Почему вы выбрали не знаю?». Подставляйте только из закрытых вариантов, где текст контролируете вы.

Сначала схема, потом настройка

Главная практическая рекомендация: не настраивайте ветвление сразу в интерфейсе. Сначала нарисуйте маршрут — хоть на бумаге, хоть в любом редакторе схем. Каждый вопрос — прямоугольник, каждое условие — стрелка с подписью. Занимает это пятнадцать минут и экономит часы отладки, потому что на схеме сразу видно то, что в списке настроек невидимо: вопрос, к которому не ведёт ни одна стрелка, ветка, которая никуда не приходит, и условие, покрывающее не все варианты ответа.

1. Выпишите все вопросы списком и пометьте, какие из них нужны всем, а какие только части людей.
2. Для каждого условного вопроса запишите условие явно: «показывать, если в В3 выбрано А или Б».
3. Проверьте покрытие: для каждого вопроса-развилки перечислите все варианты ответа и убедитесь, что для каждого определён следующий шаг. Вариант «другое» и «затрудняюсь ответить» — тоже варианты.
4. Найдите на схеме самый длинный маршрут и посчитайте, сколько на нём вопросов. Это и есть реальная длина вашей анкеты для самого невезучего респондента.
5. Найдите самый короткий маршрут. Если по нему человек отвечает на три вопроса и уходит — проверьте, достаточно ли этого для ваших выводов.
6. Убедитесь, что каждая ветка приходит либо к финалу, либо к общему блоку. Ветка, ведущая в никуда, — самый частый баг ветвления.

Где ветвление нужно, а где мешает

Ветвление оправдано там, где часть анкеты объективно неприменима к части людей. Не пользовался поддержкой — не спрашивайте про поддержку. Не покупал за последний год — не спрашивайте, что понравилось в покупке. Ответил, что недоволен — уточните чем, а довольного не заставляйте объяснять, что не так. Это честная логика: она убирает вопросы, на которые у человека нет ответа.

А вот там, где ветвление используют, чтобы «персонализировать» опрос без реальной необходимости, оно начинает вредить. Каждое условие делает сравнение сегментов сложнее: если одну группу вы спросили про цену, а другую нет, вы не можете сравнить их по этому вопросу — данных просто нет. Чем больше веток, тем меньше вопросов, на которые ответили все, и тем меньше у вас общей базы для сравнения. Доходит до анекдотичного: анкета с десятком развилок собирает по 20 ответов на каждый уточняющий вопрос, и ни один из них не годится для выводов.

• Ветвите, когда вопрос физически неприменим: у человека нет опыта, о котором вы спрашиваете.
• Ветвите на уточнениях: «почему вы поставили низкую оценку» показывайте только тем, кто её поставил.
• Не ветвите ради вежливости: если вопрос применим ко всем, задайте его всем — так у вас будет общая база.
• Считайте n на конце каждой ветки заранее: если ожидается меньше 30–50 ответов, ветка бессмысленна.
• Ключевые метрики (NPS, общая оценка) держите вне ветвления — они должны быть у всех, иначе динамику не посчитать.

Как ветвление ломает аналитику

Это то, о чём почти не говорят в руководствах по настройке. Как только в анкете появляется ветвление, у каждого вопроса становится своя база респондентов. Вопрос 1 видели все 400 человек. Вопрос 8 видели только те 120, кто на вопросе 3 ответил «да». Вопрос 12 — только 40 человек, прошедших через две развилки подряд. И если вы считаете проценты от общего числа участников опроса, все ваши цифры по условным вопросам занижены — иногда в разы.

Числа условные, но посмотрите на две последние колонки. «28% оценили скорость ответа поддержки» и «95% тех, кто обращался, оценили скорость ответа» — это про одно и то же, но первая формулировка выглядит как провал, а вторая как норма. Правильная база для условного вопроса — те, кто его видел, а не все участники. И это надо явно писать в отчёте: у каждой таблицы своя n, и читатель должен её видеть, иначе он сравнит несравнимое.

Вторая проблема — последняя строка таблицы. 27 ответов. Это конец двойной развилки, и на таком количестве людей никакие проценты не имеют смысла. Причём заметьте: анкета спроектирована абсолютно правильно, вопрос задан ровно тем, кому он адресован, — и всё равно данных не хватает. Это не ошибка настройки, это математика: каждая развилка режет выборку, и глубокие ветки почти всегда упираются в малые числа. Планируйте это заранее: если вам нужны выводы по глубокой ветке, вам нужен опрос в несколько раз больше, чем кажется.

Тестирование: единственный способ поймать баги

Ветвление невозможно проверить чтением настроек. Его можно проверить только прохождением. Причём не одним прохождением «как задумано», а прохождением по каждой ветке. Возьмите свою схему и пройдите анкету столько раз, сколько на ней конечных маршрутов, каждый раз выбирая ответы так, чтобы попасть в новую ветку. Занудно, но других вариантов нет: ошибка в логике не выдаёт себя никак до тех пор, пока в неё не попадёт живой респондент — а тогда уже поздно, данные испорчены.

1. Пройдите каждую ветку целиком, включая ту, где человек выбирает «другое» и «затрудняюсь ответить» на каждой развилке.
2. Пройдите «худший маршрут» — тот, где человек получает максимум вопросов. Засеките время: это реальная длина вашей анкеты.
3. Пройдите «кратчайший маршрут» и проверьте, не вылетает ли человек из опроса раньше, чем вы успели спросить главное.
4. Проверьте возврат назад: если респондент вернулся и поменял ответ на развилке, что происходит с уже данными ответами в старой ветке? Многие инструменты их сохраняют, и в данных остаются ответы на вопросы, которых человек в итоге не должен был видеть.
5. Проверьте пайпинг во всех вариантах: подставляемый текст должен читаться грамматически в каждом.
6. Прогоните пилот на пяти-десяти живых людях и посмотрите на распределение по веткам: если в какую-то ветку не попал никто, скорее всего, туда невозможно попасть.

Четвёртый пункт — самый коварный и его почти всегда пропускают. Человек ответил «да, обращался в поддержку», прошёл пять вопросов про поддержку, потом вернулся и передумал: «нет, не обращался». Он пошёл по другой ветке, но пять ответов про поддержку уже записаны. В выгрузке появляется респондент, который одновременно не обращался в поддержку и оценил скорость её ответа на 4. Таких записей немного, но они портят кросс-таблицы совершенно необъяснимым образом, и найти причину постфактум крайне трудно.

Типичные ошибки логики переходов

• Не покрыты все варианты ответа на развилке: для «другое» и «затрудняюсь ответить» маршрут не определён.
• Ветка ведёт в никуда: человек упирается в пустой экран или проваливается к финалу, минуя нужные вопросы.
• Условие ссылается на вопрос, который в этой ветке не задавали, — оно никогда не сработает или сработает неправильно.
• Слишком много развилок: анкета обрастает ветками, на конце каждой по 20 ответов, и выводов не получается ни по одной.
• Ключевая метрика спрятана внутри ветки — сравнить с прошлым периодом невозможно.
• Проценты по условным вопросам считаются от всех участников, а не от тех, кто вопрос видел.
• Логика настроена, но не протестирована по каждой ветке — самая частая и самая дорогая ошибка.
• Отсеянные скринером считаются как «бросившие опрос» — метрика завершаемости обваливается на ровном месте.

Есть ещё один класс проблем, о котором стоит знать: ветвление, видимое респонденту. Если после ответа «да» человек получает пять дополнительных вопросов, а после «нет» — сразу финал, то на второй-третий раз он поймёт механику. И в следующий раз ответит «нет», чтобы закончить быстрее. Это та же логика, что и с угадыванием скринеров: как только человек понимает, что его ответ управляет длиной опроса, он начинает управлять ею сознательно. Ничего радикального с этим не сделать, но не стоит делать разницу в длине веток слишком уж драматичной — и точно не стоит показывать прогресс-бар, который прыгает на 40% вперёд при «правильном» ответе.

Прогресс-бар и ветвление

Отдельная техническая головная боль. Прогресс-бар обещает человеку, сколько осталось. В линейной анкете это честно: десять вопросов, третий — значит 30%. В разветвлённой анкете инструмент не знает, сколько вопросов вам ещё достанется, потому что это зависит от будущих ответов. Поэтому бар либо считает от максимального маршрута (и тогда почти все видят, как он рывками прыгает вперёд), либо от среднего (и тогда он врёт в обе стороны).

Практическое решение: в сильно разветвлённых анкетах прогресс-бар либо убирают вообще, либо заменяют на честную формулировку «осталось 2–3 вопроса». Рывки прогресса раздражают сильнее, чем его отсутствие: человек видит, что 60% превратились в 35%, и делает вывод, что его обманывают — что, в общем-то, правда. В сервисе «До Сути» ветвление задаётся условиями на уровне вопроса, а анкету можно пройти в режиме предпросмотра по любой ветке до публикации — но проверять маршруты по своей схеме всё равно придётся вручную: инструмент покажет, что происходит, но не знает, что вы задумали.

И общий принцип напоследок: ветвление — это про уважение к респонденту и чистоту данных, а не про инженерную красоту. Если можно обойтись одним условием вместо трёх — обойдитесь. Каждая развилка, которую вы не сделали, — это маршрут, который не надо тестировать, база, которая не раскололась, и метрика, которую можно сравнить с прошлым кварталом. Самая надёжная логика — та, которой нет.