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

Летом 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 тестирование – это инструмент, а не стратегия разработки. Оно должно использоваться для того, чтобы приносить еще большее удовольствие тем пользователям, которые уже наслаждаются продуктом, а не убеждать их, что игра гораздо лучше, чем им кажется.