"Подводные камни" A/B-тестирования

Почему не стоит зацикливаться на сборе и анализе данных, в своем блоге рассказал директор по маркетингу компании Wooga Эрик Сёрферт.

Летом 2013 года компания Zynga уволила 520 человек. Один из бывших сотрудников компании на следующий день после увольнения запустил тред на Reddit. Два поста в обсуждении привлекли мое внимание.

Пост 1

Я считаю, что сама идея — собирать всю информация о том, что делает пользователь в игре – замечательная. Но чрезмерная зависимость от этих данных – уже не так замечательно. Это делает разработку в большей степени аналитической работой, лишая ее наглядности . Когда игра приносит удовольствие и радость – можно легко сказать о том, что игра клевая. По аналитике об этом так однозначно не скажешь.

Пост 2

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

Эти посты навели меня на мысль, что Zynga несет «скрытые расходы» от A/B тестирования. Иными словами, компании налетела на подводные камни подобного тестирования.

Явные издержки A/B тестирования очевидны: A/B тесты требуют времени на создание, внедрение и оценку, а ведь это время могло было быть потрачено на завершение продукта. По сути, во время подобного теста разработка отдельных составляющих игры приостанавливается. Зачастую явные издержки на A/B тестирование оправдывают отказом от участия в комплексном тестировании в будущем. Но я считаю, что эти траты переоценивают.

Если на создание и внедрение A/B тестов требуется больше 30 минут, это просто значит, что компания не выделяет достаточных ресурсов на аналитику инфраструктуры A/B тестирования с помощью внутренних средств. Но это не проблема, ведь существуют сервисы, вроде Swerve, предоставляющие такие услуги.

Они постоянно что-то тестируют и оптимизируют. И затраты на подобные тесты в подобных компаниях минимальны.

А вот «подводные камни» A/B тестирования – совсем другое дело. Они рождены постоянной зависимостью от непрекращающихся, инкрементных изменений. Эта чрезмерная зависимость ослепляет, из-за нее компания может перестать замечать фундаментальные недостатки в своих продуктах.

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

Прямая чуть ниже отображает 10% рост показателей конкретного процесса.

Но одержимость подобными незначительными улучшениями может отвлечь команду от реальных проблем продукта. И это не альтернативная стоимость, зачастую вопрос может ставиться даже так: «должны ли мы выбрать между A/B тестированием или устранением структурных недостатков в нашем продукте». И это ошибка – считать исправление инкрементных недостатков – панацеей от всех бед.

На графике чуть ниже можно увидеть, что 10% рост показателей конкретного процесса протекал на фоне 20% падения суммарных показателей продукта.

Но будьте осторожны. Последствием применения A/B тестирования может оказаться не только неправильное распределение ресурсов и усилий. Реальные проблемы начинаются, если поверить, будто бы будто бы работа над мелкими улучшениями может заменить собой разработку самого продукта. A/B тестирование слабого продукта – это то же самое, что поход с огнестрельной раной в качалку.

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

A/B тестирование – это инструмент, а не стратегия разработки. Оно должно использоваться для того, чтобы приносить еще большее удовольствие тем пользователям, которые уже наслаждаются продуктом, а не убеждать их, что игра гораздо лучше, чем им кажется.