MVP. Как выводить на рынок товары и услуги, которые нравятся покупателям

Тесты «Фальшивая дверь» или «Страница 404» являются хорошим способом выяснить уровень спроса на новую функцию, которую вы планируете создать. Идея состоит в том, чтобы предложить пользователям ссылку или кнопку для перехода на страницу новой функции и, таким образом, на основе количества осуществленных переходов оценить ее востребованность (в %). Это позволяет понять, действительно ли клиентам нужна данная функция, прежде чем вы потратите ресурсы на ее создание. Поскольку на момент проведения теста самой функции еще не существует, при переходе по ссылке пользователи обычно попадают на веб-страницу, где размещена благодарность за проявленный интерес и сообщение о том, что функция еще не готова для использования. Вы также можете добавить на эту страницу специальную форму для заполнения, чтобы посетитель мог поделиться своим мнением о том, почему он считает эту функцию полезной.

Крайний вариант теста данного типа применяется теми разработчиками, кто не утруждает себя даже созданием простейшей целевой страницы, поскольку технически все попытки перехода по ссылке можно отслеживать и при отсутствии самой веб-страницы. В этом случае, кликнув на ссылку, пользователь попадает на «страницу 404» (где 404 – это код ошибки, означающий, что «страница не найдена»).

Компания Zynga, являющаяся разработчиком игр и имеющая большой опыт в области количественного тестирования продуктов, часто использует метод «фальшивых дверей». В своем выступлении на конференции Stanford Technology Ventures соучредитель Zynga, Марк Пинкус, рассказал, что его команда. собираясь протестировать новые игровые идеи, придумывает для каждой из них короткий питч из пяти слов. Затем эти питчи используются для создания рекламных ссылок, которые компания на некоторое время встраивает в свои уже существующие игры, чтобы увидеть, насколько большой интерес каждая из них вызвала у геймеров.

Стоит отметить необходимость постоянного отслеживания частоты и продолжительности применения метода «фальшивых дверей», чтобы не огорчать своих клиентов. Подобные «обманки» не должны использоваться в течение длительного срока. Не стоит допускать ситуаций, когда «фальшивая дверь» продолжает существовать уже после того, как вы достигли нужного вам размера статистической выборки.

Аналитика продукта и A/B-тесты

Аналитика продукта сама по себе не является тестом, но она может помочь в получении представления о том, как клиенты на самом деле используют продукт. Например, вы можете узнать, какие функции используют чаще всего и на каких веб-страницах проводят больше времени. При внедрении в продукт каких-либо усовершенствований вы можете отследить соответствующие изменения ключевых метрик продукта, чтобы проверить свои гипотезы. Аналитика продукта также является основой для A/B тестирования, поскольку аналитические методы используются для расчета метрик и сравнения результатов тестирования. Наиболее востребованными решениями для анализа продуктов являются такие инструменты, как Google Analytics, KISSmetrics, Mixpanel и Flurry.

A/B-тесты продукта или сплит-тесты используются для сравнения производительности двух альтернативных пользовательских интерфейсов (A и B), являющихся составной частью продукта. Например, предположим, что вы разработали новый процесс регистрации для своего веб-приложения, который, по вашему мнению, будет иметь более высокий процент завершений, чем прежний вариант. Вместо того чтобы просто заменить существующий процесс на новый, вы могли бы провести следующий A/B-тест: случайным образом разделить напополам поток пользовательского трафика, отправив одну половину на прежнюю версию страницы регистрации (A), а другую – на новую (B), после чего сравнить количество завершенных регистраций. Существует несколько популярных инструментов для проведения A/B-тестов: Optimizely, KISSmetrics, Visual Website Optimizer и Google Content Experiments (входит в состав Google Analytics).

Для маркетингового A/B-тестирования большинство компаний используют инструменты сторонних разработчиков. Однако, когда дело доходит до A/B-тестирования продукта, многие в конечном итоге предпочитают создавать и использовать собственные решения, чтобы добиться большей гибкости за счет совместимости программного кода. Одна из основных причин такого подхода заключается в том, что большинство инструментов для проведения A/B-тестирования написаны с использованием JavaScript, что позволяет им прекрасно взаимодействовать с клиентской частью продукта. Однако эти инструменты оказываются не столь полезны в тех случаях, когда необходимо протестировать продукт в его серверной части. Стоит отметить, что ведущие инструменты для проведения A/B-тестирования, такие как KISSmetrics, предлагают способы интеграции с вашей внутренней серверной A/B-платформой.