Connect with us

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

Apptimize

AppTractor

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

/

     
     

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

AppTractor
Комментарии Facebook
Продолжить чтение
Click to comment

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

 

Анна Гуляева
Комментарии Facebook
Продолжить чтение

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-тест, тем точнее данные вы получите.

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

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

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

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

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

 

Анна Гуляева
Комментарии Facebook
Продолжить чтение

Календарь

ноябрь

17ноя - 19Весь деньТИЛТЕХ МЕДХАК

24ноя - 26Весь деньWhat the hack?!

25нояВесь деньSmart Taler 2017

25нояВесь деньLadies Code: время технологий

30нояВесь деньSmart Cars & Roads 2017

декабрь

5дек18:30- 22:00Яндекс изнутри: глазами iOS-разработчика

8дек - 9Весь деньКубок СTF России

9дек - 10Весь деньGames Gathering 2017

9декВесь деньЛекционный день по игровой индустрии

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

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

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

Наш Facebook

Популярное

X

Спасибо!

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