Connect with us

A/B тестирование

Почему результаты большинства A/B тестов – полная чепуха

Джастин Мегахэн из Mixpanel утверждает, что проведение А/Б тестов в большинстве случаев то же самое, что просто бросать монетку и смотреть что выпадет.

Ксения

Опубликовано

/

     
     

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

Justin

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

Компания AppSumo выяснила, что только 1 из 8 тестов приносит результат. В Kaiser Fung подсчитали, что от 80 до 90 A/B тестов, который они провели, принесли статистически незначимые результаты.

Тем не менее, много новых тестировщиков берутся за A/B тестирование, думая, что они быстро и легко получат результаты. Проведя несколько простых тестов, они ожидают, что найдя правильный цвет для кнопки или чуть-чуть изменив вон то поле, конверсии – бах – и подскочат на 38% магическим образом.

Они начинают проводить тестирование на своих приложениях или сайтах, и тут внезапно вмешивается суровая реальность. Тесты не приводят к определённым результатам. Они приносят «статистически незначимые» результаты, и никаких ценных выводов о продукте или пользователях. Что происходит? Где же подъем на 38% и последующие овации?

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

Вам кажется, что вы сможете что-то извлечь из любого A/B теста, который проведете. Никто (почти) не пишет посты в блогах о том, как они протестировали 3 варианта и не увидели значительной разницы в конверсии. Это означает то, что результаты настолько незначимы статистически, что не приводят ни к каким выводам из эксперимента. По сущности, это всё равно, что проводить эксперимент вообще не сделав никакой разницы между А и Б.

Представьте, вы подкидываете две монеты, по 20 раз каждую. На монете А орел выпадает 12 раз. На монете B – 9 раз. Вы же не станете утверждать, что вы вычислили монету, на которой на 33% вероятнее выпадет орел, правда? Вы знаете, что это просто дело случая. А не статистически значимо.

Затем, если вы бросите каждую монетку еще 180 раз, и на монете А орел выпадет 120 раз, а на B – 90 раз, может показаться, что получится что-то осмысленное. Но, опять же, мы знаем, что это не так. После 200 бросков может быть разница в этих числах, но это случайность. А разница – просто помехи.

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

ab-infographic

Если кого и нужно винить, то этот глупый вариант кнопки.

Эксперименты с цветом кнопки — это азы A/B тестирования. И до сих пор кто-нибудь, объясняя принцип таких тестов, использует этот пример, где в одном варианте страницы кнопка покупки была зеленая, а в другом красная. Проведете тест – узнаете, какой цвет кнопки обладает большим процентом конверсии.

Правда в том, что некоторые компании провели такой эксперимент и реально получили осмысленные результаты для улучшения своего продукта. Если вы хотите, чтобы пользователь с чем-то взаимодействовал, то это определенно стоит выделить на фоне других объектов. И всё-таки, хотя изменение цвета кнопки – это отличный способ описания A/B тестирования, ваш продукт это вряд ли улучшит.

Я провел свой собственный бессмысленный тест около 1,5  месяца назад.

Я слышал, что если начать письмо с названия компании, то это может улучшить уровень просмотра. У нас была публикация на тему превращения QuizUp в социальную платформу. Мы разослали одной половине наших пользователей материал под названием «Why 15 million users weren’t good enough for this mobile trivia app», а другой «Mixpanel – Why 15 million users weren’t good enough for this mobile trivia app». Очень простой тест, правда? Если название компании влияет, то мы могли бы использовать это для улучшения количества просмотров рассылки.

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

Когда же результаты появились, они не могли быть еще менее статистически незначимыми. Письмо с заголовком без «Mixpanel» набрало 22.75% просмотров. Письмо с указанием названия компании – 22.73%. Разница – 0.02%.

В сотнях тысяч моих отправленных писем разница составляла 20 открытий. Во всех отношениях и с любой точки зрения, я просто бросал монетки.

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

Так что я должен был сделать, чтобы получить значимые результаты?

Что ж, во-первых, мне нужно было написать совершенно другую тему письма. Например, менее интригующую, но более понятную «Why QuizUp turned the fastest-growing game in history into a social platform». Этот контраст с наибольшей вероятностью бы принес статистически значимые результаты.

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

images

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

Или же уделить много времени тестированию мелочей, например, разных картинок, немного отличающихся вариантов дизайна и другого для незначительных улучшений. Это одна команда A/B тестеров, обещающих вам «оптимизировать свой путь к успеху». Другая команда включает тех, кто тестирует глобально разные вещи, например, два разных вида введения для пользователя.

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

Я не один так думаю. Недавно, я разговаривал с Хари Анант, сооснователем Jobr насчет не очень значимых A/B тестов, которые они провели для улучшения приобретения пользователей.

Мы хотели улучшить наше введение, чтобы привлечь больше пользователей в приложение.

Jobr – приложение, которое позволяет соискателям работы свайпить так же, как в Tinder.

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

Jobr существенно поменяли свой процесс онбоардинга основываясь на том, на каком этапе пользователи «слились».

A/B тесты Cozi были более близки к варианту «оптимизируйте свой путь к успеху». Команда тестировала незначительные эстетические изменения, например, переход на более светлый фон, уменьшение количества шагов введения и другие мелочи. Ни одно изменение не привело к значительному улучшению конверсий. Но в совокупности они помогли улучшить завершение пользователем введения с 55% до 76%.

Проводите тесты, которые дадут значимые результаты

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

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

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
5 комментариев

5 Comments

  1. Sayat Mukhamadiev

    09.03.2016 at 15:24

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

    • AppTractor

      09.03.2016 at 23:44

      То есть вы поменяли цвет кнопки на сайте и у вас сайт другой? Оооок.

      • Sayat Mukhamadiev

        09.03.2016 at 23:46

        но уж точно не одинаковые!

        • AppTractor

          10.03.2016 at 09:05

          По-моему вы утрируете :)

          • Serj Nilov

            02.08.2016 at 09:01

            Вы не верите, что цвет кнопки имеет значение? Десятилетия исследований цветовой психологии для вас пустой пшик?

You must be logged in to post a comment Login

Leave a Reply

A/B тестирование

Подводные камни A/B-тестирования в социальных сетях

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

Анна Гуляева

Опубликовано

/

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

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

В типичном A/B тесте вариант случайно выбирается для каждого отдельно взятого пользователя. Например, если мы меняем дизайн нашей страницы входа в систему, половина пользователей увидит новую страницу (тестовая группа), а половина – старую (контрольная группа). Такое распределение – это простой и мощный способ протестировать изменение пользовательского поведения при помощи новой функции.

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

Почему распределение пользователей может стать неудачным

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

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

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

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

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

  • они могут не заинтересоваться неготовой функцией (“Я проигнорирую её на стадии тестирования”)
  • наоборот, они могут полюбить функцию (“Хочу общаться только по видео”), что усложнит контакт между контрольной и тестовой группами – тестовая группа ограничит себя маленькой частью сайта, а у контрольной группы будет масса неотвеченных сообщений.

Любой расклад приведет к предвзятым и неточным результатам эксперимента.

Эффекты высшего порядка

Другое ограничение подобного распределения – это то, что вы не можете измерить “эффекты высшего порядка” (также известные как сетевые эффекты или внешние эффекты). Они происходят, когда новая функция выходит за пределы тестовой группы и влияет на поведение в контрольной группе.

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

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

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

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

Использование случайного распределения по сообществам

Альтернативой может стать использование случайного распределения по сообществам. В этом случае “сообщество” – это любая группа пользователей, взаимодействия которых направлены на других пользователей внутри группы. Data-команды в  LinkedIn и Instagram уже обсуждали свои кейсы A/B-тестирования, основанного на сообществах, но самое сложное здесь – понять, как определить сообщества для вашего конкретного продукта.

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

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

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

Определение географических сообществ

Определить географические регионы для эксперимента просто, да? Вы просто привязываете каждый город к каждому экспериментальному состоянию. Но оказалось, что сложно сказать, где город заканчивается.

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

Однако я смог определить оптимальные регионы, создав границы, которые заключают в себе максимальное количество связей внутри региона, используя алгоритм Normalized Cut.

Вот общее содержание метода:

  1. Создайте граф, чтобы описать, сколько сообщений было отправлено между парами местоположений в качестве квадратной матрицы смежности A (num_Locations-by-num_Locations). Значение A [i, j] определяется количеством сообщений, отправленных между пользователями в местоположении i пользователям в местоположении j. Я не делал различий между отправителем или получателем сообщения, поэтому A симметрична.
  2. Вычислим векторный лапласиан графа L из матрицы смежности A и матрицы степени D как L = D – A. Матрица степени – это всего лишь диагональная матрица со степенью каждого узла на диагонали и нулями.
  3. Вычислите спектральное разложение матрицы L и вычислите её собственные значения. Каждое полностью изолированное множество узлов будет представлено собственным вектором с соответствующим собственным значением 0. Дальнейшая сегментация этих областей выполняется путем поиска паттернов в собственных векторах с k наименьшими ненулевыми собственными значениями. Значение k может варьироваться в зависимости от того, сколько регионов вы хотите сделать.

Я варьировал k в широком диапазоне от 5 до 250 и тестировал, насколько хорошо каждый набор регионов разделял сообщества пользователей, измеряя соотношение сообщений внутри региона с количеством сообщений между регионами. Оказалось, что для городов Канады и США оптимальным оказалось разделение на 36 регионов. После определения регионов мы оценили их разделенность на свежих данных, которые не участвовали в анализе сегментации и обнаружили, что примерно 95% взаимодействий (сообщения, лайки, просмотры профиля) произошли между пользователями внутри региона.

Заключение

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

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

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

 

Комментарии
Продолжить чтение

A/B тестирование

Как увеличить загрузки приложения на 14% с помощью нового дизайна иконки

Это очередной кейс о том, как увеличить загрузки приложения с помощью нового дизайна иконки и A/B-тестов в Google Play. В течение всего эксперимента мы провели 16 A/B-тестов, поменяли 6 концепций дизайна, столкнулись с погрешностью, чуть не упустили важный нюанс, но в очередной раз доказали, что один лишь новый дизайн иконки приложения способен увеличить его органические загрузки.

IconDesignLab

Опубликовано

/

Автор:

Это очередной кейс о том, как увеличить загрузки приложения с помощью нового дизайна иконки и A/B-тестов в Google Play. В течение всего эксперимента мы провели 16 A/B-тестов, поменяли 6 концепций дизайна, столкнулись с погрешностью, чуть не упустили важный нюанс, но в очередной раз доказали, что один лишь новый дизайн иконки приложения способен увеличить его органические загрузки.

Собираем данные о приложении и его текущей иконке

Суть приложения:

“Just Facts: Did You Know?” — это приложение, которое с помощью анимированных слайдов рассказывает об удивительных фактах из разных областей науки и окружающего мира.

Целевая аудитория – 70% пользователей приложения были мужчины, в основном молодого возраста.

Трафик был только органическим в основном из Индии, США, Филиппин, Пакистана и Южной Африки. В рейтингах Entertainment приложение постоянно прыгало то вверх, то вниз.

Ключевые слова:
Основная масса пользователей находила приложение по ключевым словам “did you know” или “facts”.

Основная масса пользователей находила приложение по ключевым словам “did you know” или “facts”.

Конкуренты:

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

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

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

Прежняя иконка приложения и эксперименты с ней:

Вот так выглядела иконка приложения до обращения к нам.

Сразу 2 ключевых запроса на самой иконке

Сразу 2 ключевых запроса на самой иконке

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

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

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

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

Цели и пожелания заказчика:
  • увеличить количество загрузок приложения;
  • протестировать кардинально другие концепции;
  • дизайн иконки сделать цветным, объемным, позитивным;
  • сделать универсальную иконку, которую, немного изменив, можно будет использовать для другого приложения из той же тематики.

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

Как мы разрабатывали новые концепции дизайна иконки

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

И вот к каким идеям мы пришли:

Первые идеи и концепции

Первые идеи и концепции

Простые дизайны, привлекающие внимание:
  • Эскизы №1 и 2 — более крупное написание названия. Ставка на основные ключевые запросы.
  • Эскиз №3 — иконка в стилистике американского научно-познавательного канала ТЕD. Таким образом мы хотели охватить аудиторию США.
  • Эскиз 4 — парень на унитазе смотрит на экран мобильного. Немного шокирует и привлекает внимание.
Дизайны на тему развлечений:
  • Эскизы №5,6,7 — карточки с темами фактов или с картинками из разных областей знаний, подобно тем, что используются в американских викторинах или телешоу.
  • Эскиз №8 — буква «F» от слова «facts», внутри которой бесконечная вселенная.
Дизайны — психологические трюки:
  • Эскиз №9 — кнопка с надписью на английском «Не нажимать», на которую инстинктивно будет хотеться нажать.
  • Эскиз №10 — популярная картинка с девушкой, которая выглядит, как торшер.
  • Эскиз №11 — оптическая иллюзия, привлекающая внимание. Фактически должна выглядеть, как анимированная иконка.
  • Эскиз №12 — очень мелкое название приложения. Прием, который должен обратить на себя внимание, т.к. человек не сможет прочитать сразу, что написано на иконке, и ему придется присмотреться получше.
Дизайны, выражающие эмоцию:
  • Эскиз №13 — стилизованный персонаж, передающий эмоцию сильного удивления.
  • Эскиз №14 — удивленный пришелец.
  • Эскиз №15- человек с упавшей до пола челюстью, от английской идиомы “someone’s jaw drops”, что означает очень сильное удивление.
  • Эскиз №16 — удивленный Эйнштейн или другая известная в США личность.
  • Эскиз №17 — более классический персонаж, смотрящий в сторону названия приложения в магазине с удивлением на лице. Таким образом мы заставим пользователя обратить внимание именно на название приложения.

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

Вот, что мы создали в итоге перед проведением A/B-тестов:

Новые концепции, отобранные для А/Б тестирования

Новые концепции, отобранные для А/Б тестирования

А дальше оказалось, что не все так просто, а результаты тестов вышли совершенно неожиданными.

Как мы столкнулись с трудностями A/B-тестирования иконок

Первые A/B-тесты иконок

Для первого и второго теста мы отобрали иконки, на которые мы делали самые большие ставки:

Иконки, подготовленные для первого А/Б теста

Иконки, подготовленные для первого А/Б теста

Но результаты нас немного обескуражили. Все иконки сработали хуже текущей. В настройках A/B-тестирования заказчик оставил текущей иконке 25% трафика, а 75% выделил под эксперименты.

Загрузки просели

Загрузки просели

Мы запустили еще один A/B-тест. В этот раз текущей иконке мы выделили 70%, а трем тестируемым — по 10%.

Иконки, отобранные для 2ого А/Б теста

Иконки, отобранные для 2ого А/Б теста

Но результат снова был неожиданным.

Когда мы впервые увидели старую иконку приложения, в голове крутилось: “Да, мы легко нарисуем лучше!”. А тут второй тест показывает, что качественная визуальная графика работает в 2 раза хуже, чем прежняя иконка ;(

Когда мы впервые увидели старую иконку приложения, в голове крутилось: “Да, мы легко нарисуем лучше!”. А тут второй тест показывает, что качественная визуальная графика работает в 2 раза хуже, чем прежняя иконка

Больше всего настораживала схожесть результатов новых вариантов. Все они показывали уменьшение загрузок в диапазоне 60-50%. Как могут совершенно разные иконки показать одинаково плохой результат в сравнении с действующей на тот момент иконкой? Нас все время преследовала мысль, что мы что-то упустили.

Проблема погрешности при тестировании

Еще одной проблемой, с которой мы столкнулись, стала погрешность. После первого A/B-теста, когда просели загрузки, заказчик больше не хотел рисковать и выделял на эксперименты лишь 30% трафика, т.е. каждой из иконок — 10%. Логика ясна: зачем выделять больше трафика, если Гугл масштабирует результат.

Справка: Так называемые scaled installs (масштабируемые установки), на которые мы ориентируемся, — это количество установок во время эксперимента, разделенных на долю аудитории. Например, если вы провели эксперимент с двумя вариантами, которые использовали 90% / 10% доли аудитории, а установки для каждого варианта были A = 900 и B = 200, масштабированные установки отображались бы как A = 1000 (900 / .9 ) И B = 2000 (200 / 0,1).

Т.е. вроде бы как распределяешь трафика меньше, а результат должен быть тот же. Но мы засомневались.

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

Мы провели несколько AAB-тестов, распределяя трафик таким образом: 50% текущей иконке, 25% текущей иконке, загруженной в качестве нового варианта, и еще 25% — альтернативному новому дизайну. Выяснилось, что при 7-дневном тестировании и распределении трафика по 25% на альтернативные иконки, погрешность составляла от -0,2 до+10,1% при загрузках в 1.5-3К.

Гугл говорит, что эксперимент завершен и можно делать выводы: текущая иконка победила текущую иконку и увеличила загрузки на 4,95% (в среднем) :)

Гугл говорит, что эксперимент завершен и можно делать выводы: текущая иконка победила текущую иконку и увеличила загрузки на 4,95% (в среднем) 🙂

Вот чем полезен AAB-тест. Мы выявили удручающую погрешность.

На заметку

Погрешность уменьшится, если:

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

Однако, даже с учетом средней погрешности в 4.95%, альтернативные иконки пока работали хуже. Мы знали, что погрешность будет меньше, если проводить тест дольше. Тогда количество загрузок перевалит за 3К, и результаты будут точнее. Но ждать дольше мы пока не видели смысла, т.к. было абсолютно ясно, что выбранные концепции не работают.

Эврика!

Как мы нашли то, что упустили

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

  1. Иконка с текстом гораздо лучше передавала суть приложения. Это было тяжело признать, т.к. наличие слов в дизайне иконки во всем мире считается неприемлемым, кроме исключений. Что же, возможно, мы как раз и попали на это исключение.
  2. Текст на старой иконке содержал ключевые слова, по которым пользователи обычно и находили приложение. Так зачем же их убирать, если это как раз то, что они ищут?
  3. Кроме того наш дизайнер обратил внимание на то, что поиск по названию в Google показывает на превью старую иконку приложения, а уже в магазине — новую. А значит, пользователь от этого может растеряться и закрыть вкладку.

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

Как мы разработали успешную концепцию дизайна иконки

Мы посмотрели на протестированные нами иконки. Иконка с черно-белым удивленным Линкольном хоть и не сработала, но ее результат был лучшим среди альтернативных вариантов. Кроме того, этот образ больше всего подходил для привлечения американской аудитории и отлично вписывался в старый дизайн. Хотя могло оказаться и так, что для аудитории остальных стран он не был узнаваем, что тоже могло отразится на загрузках. Посмотрим.

Задача была связать старый дизайн иконки с образом удивленного Линкольна

Задача была связать старый дизайн иконки с образом удивленного Линкольна

А вот, что из этого получилось:

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

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

Тесты стали давать положительные результаты. Так появилась новая концепция — создать новую иконку, опираясь на старый дизайн. Дизайнер создал несколько новых вариантов, чтобы проверить эту идею.

Различные варианты интеграции старого и нового дизайна

Различные варианты интеграции старого и нового дизайна

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

И наконец, мы решили остановиться, когда средняя конверсия стала +14,15%

И наконец, мы решили остановиться, когда средняя конверсия стала +14,15%

Вот она - иконка-победитель

Вот она — иконка-победитель

Именно с ней количество загрузок на протяжении A/B-теста удалось увеличить на 6.2% — 22.1%. И даже с учетом погрешности в 4.95% этот результат нас вполне устроил, т.к. свою работу мы считаем выполненной, если в среднем конверсия выросла на 10%. Результат достигнут. Но, по большому счету, экспериментировать можно еще продолжать. Вероятно, это как путь к совершенству — бесконечный процесс.

Вот так выглядит иконка приложения в Google Play на сегодняшний день.

Факты: знаешь ли ты?
Факты: знаешь ли ты?
Разработчик: Fruktorum LLC
Цена: Бесплатно

Выводы о тестировании иконок приложений

С каждым новым A/B-тестированием мы получаем новый опыт и полезную информацию, которой делимся с вами. Мы уже писали вам о кейсе, когда надпись “Free” непредсказуемым образом повлияла на количество загрузок приложения. В этот раз мы зафиксировали факт, который идет в разрез с общепринятым мнением маркетологов о том, что текст на иконке приложения — это табу. Вот вам наглядный пример того, как текст на иконке в новом дизайне сработал только в плюс и увеличил загрузки на 14-15%. Так что не стоит слепо следовать правилам и стандартам в дизайне иконок. Кто знает, может именно ваш случай будет исключением. Лучше следуйте правилам, которые подтверждены практическим опытом:

  1. Чем яснее иконка приложения передает его суть, тем лучше она работает.
  2. При выборе дизайна иконки полагайтесь лучше на A/B-тесты, чем на собственное мнение, тренды или общепринятые правила.
  3. Кардинально новый дизайн, даже с более качественной графикой, не гарантирует вам резкий скачек конверсии вверх. Небольшие улучшения мелкими шагами — вот более близкий путь к цели.
  4. Не полагайтесь слепо на результаты A/B-тестирования. Учитывайте погрешность с помощью AAB-тестов и уменьшайте ее путем изменения факторов, которые на нее влияют.
  5. Помните рекомендации Гугл, что чем дольше будет проводится A/B-тест, тем точнее данные вы получите.

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

Комментарии
Продолжить чтение

A/B тестирование

Более 100 миллиардов версий сайта: как Booking.com проводит A/B-тесты

Доверяйте своим людям. Доверяйте своим инструментам. Доверяйте науке.

Анна Гуляева

Опубликовано

/

О принципах работы Booking.com и подходе компании к A/B-тестированию рассказала Дженни Женг из Taplytics в блоге компании.

Каждый год Google проводит конференцию по конверсии продаж в своей штаб-квартире региона EMEA в Дублине. Темой 2017 года стала “конверсия мобильных пользователей”, и среди всех презентаций особенно выделялись две: Стюарта Фрисби из Booking.com и Вани Млако из Transavia. Обе компании работают в сфере туризма и путешествий и подчеркивают важность тестирования в своих организациях.

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

Во-первых, давайте посмотрим, как Booking.com выстраивает свою компанию вокруг A/B-тестирования. Их сайт является агрегатором, который связывает пользователей с отелями и гостиницами – в день на сайте резервируется более миллиона комнат. В основе пользовательского опыта Booking.com лежит персонализация, которая ведет к удержанию пользователя, и чтобы этого достичь, компания активно использует тестирование.

Важность тестирования

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

Идите в направлении, которое добавит ценности в жизни ваших клиентов.

Booking.com проводит тестирования восемь лет. Изначально на рынке не было большого выбора инструментов, поэтому в компании создали их самостоятельно. После выделения средств и ресурсов для разработки своих процессов тестирования, они создали сильное in-house решение.

Согласно исследованию Evercore Group L.L.C., их “тестирование повысило конверсию до уровня в 2-3 раза выше, чем в среднем по индустрии”. Они постоянно проводят эксперименты как для улучшения производительности, так и для новых продуктов.

Процесс

Процесс тестирования Booking.com зависит от того, есть ли у них ресурсы для проведения тестов внутри компании. В Booking.com поощряется выдвижение сотрудниками гипотез, основанных на существующих данных, которые нужно подтвердить или опровергнуть. При этом нужно отличать гипотезу от обычной идеи, потому что сотрудники должны быть “более привязаны к реальности бизнеса”. Как сказал Стюарт,

Люди с идеями – это художники, люди с гипотезами – дизайнеры.

После выдвижения гипотезы тест разбивается на небольшие эксперименты. Это сокращает риск и дает более надежные результаты из-за меньшего количества влияющих факторов. На фазе тестирования в любой момент времени проходит 1000 экспериментов. Только представьте это количество: существовало больше версий сайта Booking.com, чем когда-либо на свете жило людей.

A/B-тестирование основывается на идее того, что вам нужно доверять своим инструментам… Вам нужно либо довериться тому, что у вас есть, либо поменять инструменты, либо создать свои собственные.

Многие компании часто интересуются: лучше создать собственную платформу для тестирования или довериться внешним ресурсам, например, Taplytics. Booking.com уникален благодаря своей бизнес-модели: им не нужно беспокоиться об управлении цепочками поставок или о поддержании собственного оборудования, поэтому они решили сделать необходимые инвестиции во внутреннее тестирование. Они были настроены взять на себя этот значительный проект, развить его внутри компании и пожертвовать на него необходимое время и усилия. Booking.com принял это решение 8 лет назад, и оно определенно окупилось.

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

Культура экспериментов

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

Booking.com верит в “принципы, а не правила” и предлагает сотрудникам полную свободу в вопросах того, что и как тестировать. Они отбрасывают мнение самого высокооплачиваемого сотрудника для более демократичного принятия решений. В компании работает 75 фронтенд-команд, в каждой из которых работает дизайнер, что позволяет им работать над конкретными проблемами. Сотрудники также меняют команду каждые 10-12 месяцев, чтобы видеть компанию более целостно и развивать гибкое мышление.

Компания, которая понимает силу A/B-тестирования, хорошо подготовлена к будущему. Это применимо для всех индустрий: от спорта до онлайн-магазинов. Подход Booking.com к оптимизации может стать примером для многих компаний, использующих мобильные взаимодействия для определения пользовательского опыта.

Как сказал Стюарт Фрисби:

Выбросьте свой план. Доверяйте своим людям. Доверяйте своим инструментам. Доверяйте науке.

 

Комментарии
Продолжить чтение

A/B тестирование

Опыт Star Walk 2: как увеличить органические установки на 40% при помощи новой иконки

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

AppTractor

Опубликовано

/

Автор:

Ольга Штауб из Vito Technology поделилась с нами вариантами иконок, которая компания протестировала в поисках идеала.

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

О нас

Компания Vito Technology появилась на мобильном рынке в далеком 2001 году, когда Symbian и Windows Mobile (заметьте, не Windows Phone) были на пике. Представленные Apple новые технологии, в частности цифровой компас и гироскоп, встроенные в мобильный телефон, вдохновили нас на создание карты ночного неба с использованием технологии дополненной реальности. Приложение Star Walk, наш бестселлер, выпущенный в самом начале истории App Store, может считаться классикой данного жанра. Датой первого релиза было 6 ноября 2008 года.

Однако сегодня мы поговорим о сиквеле вышеупомянутого приложения – Star Walk 2, выпущенном в 2014 году. Мы были уверены, что иконка нашего оригинального Star Walk, зарегистрированная торговая марка с изображением зеркально отраженного созвездия Большой Медведицы, узнаваема, поэтому взяли её за основу, инвертировали исходные цвета. Таким образом мы хотели показать преемственность приложений. Иконка новой программы получилась строгой и аккуратной, хорошо вписалась в дизайн вышедшей к моменту релиза приложения iOS 7.

Мы были довольны получившимся результатом до недавнего времени. Сейчас все труднее удержать на плаву то или иное приложение, ведь каждый день на рынок выходят тысячи новых продуктов. Когда конверсия платной версии опустилась до 3%, а бесплатной до 30%, мы задумались о том, не пора ли обновить иконку, описание, баннеры и даже название. Результаты проведённого A/B тестирования иконок оказались очень впечатляющими, и мы решили поделиться ими с другими разработчиками.

Методология

Для А/В тестирования мы воспользовались инструментами предоставляемыми Google Play. Есть отдельные настройки для тестирования иконок, баннеров, скриншотов, промо ролика, а также длинных и коротких описаний. Для получения полноценных результатов эксперимента в Google Play необходимо набрать достаточное количество установок. Более подробно об условиях тестирования здесь. Другая платформа для А/В тестирования – SplitMetrics, которая также дает возможность сделать хорошую статистическую выборку, о чем они пишут в блоге.

Вопросы

Может ли белый фон иконки отталкивать потенциальных покупателей? Что будет, если изменить фирменное изображение созвездия Большой Медведицы на классическое? Что ещё мы можем изменить в иконке, чтобы увеличить количество установок?

Тест 1

Для первого этапа эксперимента мы сделали два новых варианта иконки – с темно-синим фоном, который так популярен среди наших конкурентов. На одном из дополнительных вариантов мы расположили созвездие классически. Меньше всего голосов набрал действующий вариант иконки. Оба дополнительных варианта показали хорошие результаты, что давало надежду на увеличение установок на 15-40%, но, поскольку они набрали примерно одинаковое количество голосов, мы решили оставить наше фирменное расположение созвездия.

Тест 2

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

Тест 3

Так как участники теста номер 2 показали хорошие результаты, мы решили объединить оба варианта в один. Ожидалось, что иконка с мерцающей звездой и линией горизонта понравится пользователям еще больше, но мы ошиблись. Иконка с горизонтом и без мерцающей звезды победила, показав еще более впечатляющий результат – 40-65% роста.

Тест 4 и 5

Следующие два эксперимента были посвящены цвету. Мы добавили несколько иконок с различными оттенками фиолетового и зеленого. Победу вновь одержал вариант с синим фоном!

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

Подведем итоги

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

Выводы

  1. Используйте системы для A/B тестирования.
  2. Позвольте людям проголосовать за понравившийся им вариант.
  3. Посмотрите на работы ваших конкурентов, возможно вы сможете почерпнуть вдохновение для создания новых иконок.
  4. Не бойтесь вносить изменения в иконки ваших приложений, это может дать положительный результат.
  5. Экспериментируйте с цветами и дополнительными элементами.
  6. Не прекращайте поиски, и вы найдете лучший вариант.
Комментарии
Продолжить чтение

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков веб и мобильных приложений!

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Популярное

X

Спасибо!

Теперь редакторы в курсе.