Требования для запуска серьезных экспериментальных программ

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

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

Неизбежный предшественник создания программы экспериментов, которая сделает вас или сломает: предварительные расчеты

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

Прежде чем делать что-либо, связанное с экспериментами, убедитесь, что у вас достаточно данных для этого. Посмотрите, сможете ли вы вообще протестировать с помощью предварительных расчетов. Под объемом данных я подразумеваю посетителей и конверсии. Посетителями могут быть все, что вы обычно используете (например, сеансы, пользователи, MAU и т. д.). Конверсии — это основная метрика, которую вы собираетесь использовать в своих тестах. Знаю это:

1. Не каждый бизнес имеет достаточный объем данных для проведения экспериментов с любой емкостью.
2. Если вы можете это сделать, знайте, что вы не можете просто взять желаемую скорость из воздуха. Он основан на расчетах.

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

Я подробно освещал эту тему несколько месяцев назад для Experiment Nation. Знайте, что если вы не разберетесь в этой теме и не начнете заниматься ею с первого дня, это будет преследовать вас и в конечном итоге обязательно приведет к каким-то нежелательным результатам. Еще одно очень важное замечание: знайте, основан ли ваш инструмент тестирования (или тот, который вы планируете использовать) на основе тестирования с фиксированным горизонтом или последовательного тестирования. Это влияет на расчеты и на то, как вы запускаете свою программу.

Шаг 1 (после предшественника): измерение и качество данных

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

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

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

Если измерения и/или качество данных катастрофичны, просто остановитесь. Остановите все и направьте все свои усилия на то, чтобы все исправить. Думайте об экспериментах как о пирамиде. Эти две вещи являются фундаментальными слоями пирамиды. Если он треснет в любой момент времени, все остальное рухнет поверх него. Я обещаю.

Я скажу, что знаю, что это может быть трудно. Чтобы правильно их настроить, может потребоваться дополнительное время. Может быть, даже больше месяца или двух. Тем не менее, получить их правильно стоит. Я видел проблемы, возникающие через шесть месяцев или более после запуска программы — только для того, чтобы все в конечном итоге резко остановилось. В этот момент никто не счастлив.

Примечание о том, какой должна быть основная метрика…

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

Первичные метрики всегда должны быть метриками нисходящей воронки. Заказы. Отправка форм. MQL. Доход. LTV. SQL. Вы поняли идею. Некоторые люди говорят, что это всегда должно быть действие, наиболее близкое к изменениям, которые вы вносите, или показателям вовлеченности. Неправильный. Нет. Нет. Неправильно. БС. Тот, кто скажет вам это, должен через шесть месяцев или год обосновать программу перед директором по маркетингу или генеральным директором компании. Они будут в горячем кресле. НЕ ИСПОЛЬЗУЙТЕ программу, полную тестов, ориентированных на нажатия кнопок, переходы по ссылкам, просмотры страниц, средн. продолжительность сеанса, показатель выхода, показатель отказов, просмотры видео и так далее и тому подобное. Это не оправдает тысячи или сотни тысяч долларов, потраченных на эту работу. Каждый хочет знать свою рентабельность инвестиций и то, как работа повлияла на итоговый результат. Кнопки этого не сделают.

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

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

Шаг 2: Пользовательские исследования и идеи

На этом этапе вы должны (1) знать, что у вас достаточно данных для тестирования и (2) знать, что вы измеряете, и что вы собираете правильные данные, которым можно доверять. Ну и что дальше? Придумывает, что тестировать. Каковы ваши идеи для тестов? Как вы собираетесь их генерировать?

Угадайте, что делает большинство команд? Они исходят из интуиции и множества «мы думаем», «мы чувствуем» и «мы верим». Это слишком субъективно, и это ужасный способ запуска программы. Этот подход вообще не основан на данных. Это то, что практикующие врачи называют «тестированием спагетти», иначе говоря, швыряние вещей в стену в надежде, что они прилипнут. Разговоры, основанные на данных, не включают в себя такого рода язык, а необходимые данные поступают из исследований пользователей. Меня постоянно спрашивают, что означает слово «исследование».

Что ж, существует несколько методологий сбора данных, включая, помимо прочего, аналитику, опросы, опросы, тестирование пользователей, тестирование сообщений, тепловые карты, записи сеансов, сортировку карточек, тестирование дерева, картирование пути клиента, персоны и многое другое. Есть также несколько инструментов, которые помогут нам выполнить каждый из них. Я всегда говорю начинать с одного или двух и постепенно переходить к другим. Это определенно лучше, чем ничего. Технически я больше не считаю аналитику, потому что в наши дни у каждой компании есть аналитические данные. Если у вас его нет, скорее всего, у вас есть более крупная рыба. Однако, если он у вас есть, стремитесь к одному или двум сверх этого (и не говорите: «О, тогда у нас все хорошо»).

Существует методология, называемая эвристической оценкой. Это когда кто-то визуально оценивает опыт и делает выводы на основе своего опыта и знаний. Для этого есть время и место, но в большинстве случаев это не подтверждается «жесткими данными». Это довольно субъективно и будет в некоторой степени отличаться в зависимости от того, кто его завершает. Знайте, что ваша программа не должна основываться на подобных выводах.

Я не буду здесь подробно описывать, как проводить исследования, но вы можете посетить один из моих веб-семинаров VWO, где я расскажу больше о модели CXL ResearchXL.

Шаг 3: Расстановка приоритетов

Если у вас есть список тестовых идей, вы не можете реализовать их все сразу. Вам нужен стратегический, логичный способ создать план действий. Здесь в игру вступают рамки расстановки приоритетов. Многие существуют. Мне особенно нравится один из них: фреймворк PXL от CXL. Другие распространенные из них включают PIE, ICE или PILL. На мой взгляд, PXL наиболее объективен. Он настраиваемый и более надежный (в хорошем смысле).

Другие модели хороши и лучше, чем ничего. Если у вас есть что-то, и это работает на вас, отлично. Просто имейте один и убедитесь, что все его используют! Это избавит вас от лишнего хаоса.

Шаг 4: Дорожная карта

Дорожные карты наглядно показывают, что работает в любой момент времени. Объедините расстановку приоритетов и предварительные расчеты и бум. У вас есть дорожная карта. Лучше всего это делать на диаграммах Ганта. Добавьте все свои дорожки и тесты с предполагаемой продолжительностью, устройствами и другими полезными метаданными. Вы избежите нежелательного перекрытия и нежелательных эффектов взаимодействия. Это помогает каждому планировать гораздо более эффективно и результативно. Это убережет вас от дальнейшего хаоса.

Шаг 5 и далее: бизнес в обычном режиме

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

Связанные темы: Управление программой и руководство

Помимо отдельных тестов, есть и другие темы для рассмотрения в отношении всей «программы». К ним относятся управление программами и руководство. Вот как я думаю о них в очень упрощённом виде…

Управление программой: Как вы собираетесь организовать и отслеживать всю эту работу? Выясните, какие инструменты вы собираетесь использовать для задач, управления данными и общения. (Я узнал об этом от Бена Лабея, генерального директора Speero.)

Управление: Какие роли и обязанности есть у каждого? Полезный способ определить это — (1) выбрать модель управления и (2) заполнить диаграмму RASCI в соответствии с моделью управления. Общие модели управления для изучения и рассмотрения: индивидуальная, централизованная, децентрализованная, центр передового опыта, совет по тестированию и гибриды.

Если вы не соедините оба этих пункта со всем остальным, это будет дополнительный хаос, и вы будете платить за него на каждом шагу. Прибейте их вниз. Это требует дополнительного времени, но оно того стоит. Если вы какое-то время продираетесь сквозь вещи, последствия рано или поздно настигнут вас. Я обещаю. (Видимо, я дал здесь довольно много обещаний.)

Заключение

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

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

Если вы хотите узнать больше о том, как экспериментирование способствует инновациям и росту и стоит всей шумихи, посмотрите мой последний вебинар с VWO.