Как не налажать с опросом: собираем мнения клиентов на международном рынке

Привет, меня зовут Костя Платонов, в Garage Eight я занимаюсь аналитикой партнёрских программ, а в бэкграунде долгое время – социсследованиями: от сопровождения опросов на десятки тысяч респондентов до мониторинга инфополя в соцсетях.

В продуктовых исследованиях рано или поздно любой бизнес идёт в опросы. Только так можно завалидировать фидбэк от пользователей в формализованные показатели для принятия data-driven решений. В этой статье мы посмотрим на типичные сценарии, когда опрос – это хорошая идея, а также разберем лучшие практики и антипаттерны.

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

Кажется, сейчас наиболее логичный ответ – ничего не читать (рынок меняется слишком быстро), а просто посмотреть примеры хороших анкет. Например, те, что предлагает у себя Survey monkey, – в качестве шаблонов. Плагиатить их никто не заставляет, просто имейте в виду, что все корректные формулировки (в рамках соответствующих методик) уже придумали за вас.

Если вы совсем не сталкивались с опросами на практике, то советую заглянуть в пару книжек.

Вчера, прямо сейчас и завтра основополагающий принцип построения вопросов о продукте – ポカヨケ (poka-yoke – «защита от дурака») – вы должны быть уверены, что ваши вопросы понятны всем и будут поняты одинаково. Самое стрёмное в формулировании вопросов – состояние «curse of knowledge», когда вам кажется, что клиент знает о продукте столько же, сколько и вы. Уберите термины, раскройте аббревиатуры, спросите лаконичнее, укоротите витиеватое и т.д.

Здесь и далее я буду приводить примеры вопросов: что-то непосредственно из нашей практики, что-то из реальных анкет других компаний, авторов оставим за кадром, дабы не делать (анти)рекламы.

Что не так? – Пользователь не обязан знать, что значит «кобрендовый» (и, скорее всего, не знает) – лучше ему объяснить заранее.

Дайте почитать вопросы коллегам, сделайте пилотаж на 5-10 человек. Такой способ позволяет превентивно выявить большинство косяков.

Самое важное лучше поместить ближе к началу, потому что определённая доля респондентов неизбежно будет дропаться по мере прохождения.

В целом, лучше задавать вопросы о прошлом, чем о будущем, однако важно трезво подойти к оценке лимитов памяти респондента.

Что не так? – Респондент, скорее всего, не помнит, а на выходе вы получаете мало чего значащее случайное распределение ответов.

Не бойтесь добавлять открытый вопрос в конце, так вы не рискуете сильно повысить дроп рейт (доля анкет, брошенных в процессе), но сможете собрать дополнительную ценную информацию.

Что хорошо? – Мы не закрывали этот вопрос и узнали, что в некоторых сегментах значительная доля респондентов указали, что «доверяют только себе» – это важно.

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

Что не так? – Здесь респондент не просто не помнит, но, наверное, и не знает, да и вообще напрашивается какой-то другой метод: в русле UX research.

Современные опросные конструкторы очень хорошо продвинулись за последние несколько лет. Мы пользуемся в основном Survey Monkey, иногда Typeform и Google Forms для чего-то очень простого. В целом, все эти решения функциональны, из продвинутых опций стоит присмотреться к доступным вариантам кастомизации ссылок, в том числе «протаскивания» всякого рода идентификаторов и меток в ссылку для дальнейшего обогащения данных.

Я сталкивался с историей, когда команда делает выбор в сторону своего опросного конструктора или даже целой инфраструктуры с мониторингом в виде BI-решений. Если рисёч — не ваша основная деятельность, и вы проводите не больше 100 опросных исследований в год, разрабатывать и держать у себя собственную опросную платформу, как правило, нерентабельно. Это достаточно сложный сервис и сделать его лучше, чем у лидеров рынка, – сложно.

Один из недавних опросов, который я запускал, переводился на 6 языков: от малайского до урду. Конечно, здесь ни о каких автоматических переводчиках не может быть и речи: всё должно быть не просто правильно, а выдержано в единой стилистике, с чем пока что не особо справляются даже хвалёные нейросети. Поэтому флоу такой: рисёчер делает анкету на английском, её смотрит команда, потом копирайтер, потом ещё один копирайтер и только потом переводят переводчики.

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

Ещё одна часть работы, по которой мы, прямо скажем, заморачиваемся – процесс доставки. Цепочкой коммуникаций для оптимальной доставки опроса, как правило, занимается CRM-маркетолог: в зависимости от специфики сегмента используются письма, пуши, различные баннеры, ремайндеры в personal area и другие каналы в разных сочетаниях.

Еще один ключевой момент – то, как мы работаем со шкалами и данными. Мы используем обогащение данных везде, где это возможно. Кроме того, в каждый опрос мы методично и компактно внедряем всевозможные шкалы и фреймворки: от семантических дифференциалов и maxdiff до CSI и модели Кано.

Несмотря на все нюансы, у нас получилось сделать опросы мощным инструментом для бизнес-решений на всех этапах: от выхода на новые рынки до анализа потребностей уже лояльных клиентов.

Чтобы повысить качество заполнения, мы собираем обратную связь и чекаем время прохождения в разные временные промежутки после запуска опроса. Мы стараемся добавлять один открытый вопрос – в моём последнем исследовании на открытый вопрос (который был 13ым и последним в списке) ответило большинство опрошенных: это хороший маркер вовлечённости аудитории.

Мы мучительно продумываем логику опроса, чтобы несильно надоесть респонденту, делаем формулировки короткими и чёткими, а если респонденты начинают бросать анкету на определённом вопросе, анализируем это как иницидент и быстро исправляем причины.