Мы делали ремастер
целый год
Gamedev
AppQuantum

Как проводить A/B-тесты в мобильных приложениях: часть I

AppQuantum представляет статью по мотивам вебинаров “Как проводить A/B-тесты в мобильных приложениях”, созданных в коллаборации с агентством мобильного маркетинга Appbooster. Из них вы узнаете о том, для чего нужны A/B-тесты, как проводить их максимально эффективно и избегать ошибок. Кроме того, вы получите уникальные кейсы из практики авторов. Первый вебинар доступен по ссылке — вы можете посмотреть его в записи или почерпнуть информацию из этого материала.

A/B-тесты: что такое и зачем нужны

A/B-тесты, или сплит-тесты — это метод сравнения двух состояний одного элемента. Они помогают повысить конверсию и доходность проекта. Ключевая метрика при их оценке — доход, или revenue. Тестируемым элементом может стать что угодно: экран подписки, онбординг, рекламный креатив и тд.

История появления

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

Выглядело это так: вставлялся тег Google Optimize, в визуальном редакторе настраивались тестируемые элементы и эксперимент запускался. Пользователи рандомным образом делились на две части. Одна из них получала старый вариант элемента, вторая — измененный.

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

Работа с возражениями

  • Разработчик и без теста знает, как улучшить приложение.

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

  • Можно просто сравнить “до” и “после”.

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

  • A/B-тесты — это долго и дорого.

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

Тем не менее, оно того стоит. Пример из практики AppQuantum: одно приложение с подписками около полугода работало в убыток, который в пике составлял -$300 тысяч. После 50 тестов онбординга и пэйволла приложение выходит в плюс, окупает инвестиции, приносит стабильный доход в сотни тысяч долларов — все благодаря A/B-тестам.

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

Разработка правильной гипотезы

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

Предположим, мы хотим повысить прибыль и работаем для этого с метрикой удержания — retention rate. Выстраиваем гипотезы, много их тестируем, формулируем гипотезы снова, а метрика остается на том же уровне. В таком случае принято называть метрику неэластичной.

Сформулируйте ожидания внутри команды: на что должна повлиять гипотеза? Что она изменит? Изучите поведение пользователей, особенности продукта, определите желаемый прирост. Все это поможет сформулировать гипотезу, которая действительно будет влиять на метрики. Это сэкономит время, силы и деньги на тесты. В следующем разделе мы расскажем, как еще можно провести эффективные тесты с минимальными затратами.

Секрет дешевых A/B-тестов

  • Статистическая значимость

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

Например, мы тестируем пэйволлы: берем только когорту юзеров, дошедших до пэйволла — остальные для нас нерелевантны. У нас есть 2000 юзеров, которые делятся пополам, и 2 варианта тестируемого элемента. В группе А было 140 конверсий, в группе В — 160.

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

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

Попробуем интерпретировать результат нашего теста через один из самых распространенных калькуляторов Mindbox. Он опирается на классический частотный подход.

В примере на 1000 юзерах результаты сильно не различаются — сделать четкий вывод не получается. Прогоним те же вводные через калькулятор AB Testguide, использующий байесовский подход.

Мы видим, что он дает однозначный ответ: вариант B на 90% успешнее остальных. С байесовским подходом мы экономим время и сокращаем количество итераций теста — соответственно, потраченных денег. Важно понимать, что мы не прогоняем результат через 100 калькуляторов, пока не получим удовлетворяющий итог. Результат в обоих случаях одинаков, а вот интерпретация данных разная.

  • Радикальные тесты

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

Когда в продуктовой команде только выстраивается процесс работы с тестами, тестировать начинают ближайшие варианты к текущему. Если мы тестируем цены оффера, и изначальное значение $4, то чаще тестировать начинают $3 и $5. Так делать не стоит.

Мы убеждены, что проводить тесты надо радикально. Контрольная цена оффера $4 — ставьте максимально далекие от нее значения $1 и $10.

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

  • Они показательны. Радикальный тест дает сильно положительный или сильно отрицательный эффект, поэтому нам проще оценить результат изменений. Даже если тест был неудачным, мы понимаем, в какую сторону двигаться. Нерешительный тест внушает иллюзию найденного оптимума. Вариант $5 проиграл по сравнению с вариантом $4 — есть ощущение, что раз проиграл очень близкий к контрольному вариант, остальные бОльшие значения тестировать нецелесообразно, они точно не победят. Из нашего опыта, это не так.
  • Можно сэкономить. Итераций в радикальном тесте больше, но стоят они дешевле и достигают нужной значимости на меньшем числе конверсий. Нам требуется меньше данных для уверенного вывода.
  • Ниже погрешность. Чем ближе тестируемые варианты, тем выше вероятность случайности.
  • Шанс приятной неожиданности. Однажды мы в AppQuantum тестировали очень высокую цену на оффер — $25. Вся наша команда и партнеры-разработчики были уверены, что это слишком дорого, и никто по такой цене покупать не будет. Аналогичный по содержанию оффер у конкурентов стоил максимум $15. Но наш вариант в итоге победил. Приятные неожиданности случаются!
  • Ухудшающие тесты

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

Разберем на примере:

Из отзывов пользователей разработчик понял, что в приложении неправильный туториал. Он убежден, что сейчас исправит все ошибки, и метрики возрастут. Если улучшение должно поднять метрики — получается, ухудшение должно их “уронить”? Раз так, можно ухудшить туториал и посмотреть, насколько метрики реально поддаются изменениям. Уже после того, как разработчик убедился, что изменения имеют смысл, можно приступать к улучшению элемента, вкладывая в это силы, время и деньги.

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

На чем стоит проводить ухудшающие тесты:

  • Нарратив и качество локализации

Исключение: narrative-driven жанры и вертикали;

  • Пользовательский интерфейс

Исключение: офферы и пэйволлы;

  • User Experience дизайн

В этом случае ухудшающий тест влияет на активность и отзывы о приложении;

  • Туториал и онбординг

Изменения в них дают эффект, но зачастую не настолько значительные, как ожидается.

  • Много изменений за тест

Чаще всего неэффективно тестировать сразу несколько изменений за раз. Нет смысла тестировать 10 элементов, если результат 8 из них очевиден. Но из каждого правила есть исключения: иногда можно протестировать сразу много вариантов ради экономии на тесте.

Вносить много изменений за раз можно, когда:

  • Мы знаем, что изменения работают эффективно только в совокупности;
  • Мы уверены, что ни одно из них не сработает в минус;
  • За раз проще протестировать сразу несколько недорогих в производстве элементов.

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

Юнит-экономика в A/B-тестировании

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

Юнит-экономика AppQuantum

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

Гипотеза 1

Мы хотим поднять конверсию в клиентах. Добьемся прироста на 0,5% — это принесет 69 477 руб.

Гипотеза 2

Мы хотим увеличить повторные покупки. 20 клиентов делают 24 покупки, а нам нужно добиться, чтобы 20 клиентов сделали 31 покупку. Концентрация на конкретных метриках и четкая формулировка задачи помогают очертить круг возможных гипотез. Что мы будем делать? Возможно, проведем push-кампанию или будем давать игроку меньше жизней. Результат — профит уже 75 654 руб.

Гипотеза 3

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

Гипотеза 4

На каком-то этапе изучения юнит-экономики команду посещает идея сделать со своим продуктом что-то совершенно невообразимое. Например, создать суперфичу, которая повысит сразу несколько метрик и принесет 496 127 руб. На первый взгляд, проблема только в том, что ее разработка займет 3 месяца. Однако, есть и другие, которые рассмотрим дальше.

MVP больших фичей

MVP (minimum viable product) — это тестовая версия приложения с минимумом функций. MVP создают для теста гипотез и проверки жизнеспособности продукта.

Большая фича — не самое эффективное решение для поднятия метрик. Продукт может стать слишком сложным, размоется его основная ценность. На фичу будут потрачены время, силы и деньги. А впоследствии еще и окажется, что проблема приложения была вовсе не в том, что в нем нет этой фичи.

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

Алгоритм действий:

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

MVP больших фичей: кейс Doorman Story

Рассмотрим на примере приложения Doorman Story, которое издает AppQuantum. Это симулятор тайм-менеджера, где игрок развивает собственный отель. Работник в этом отеле должен обслужить посетителей за ограниченное время. У каждой игровой механики есть таймер и последовательность действий.

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

Совместно с партнерами из Red Machine (студия-разработчик Doorman Story) мы придумали максимально облегченный вариант суперфичи. Создали уникальную игровую механику платного автомата с жвачкой, которая не влияет на весь игровой баланс и встречается только в одном сете уровней. Одна механика, один арт — экономика приложения при этом не нарушается.

Этот пример ложится в метод MVP больших фичей: выделяем главный бонус и главный риск. Бонус — мы получаем возможность продавать то, что уже есть, не тратясь дополнительно. Риск — игрока может отпугнуть то, что в открытом доступе у него больше нет всех инструментов, некоторые надо покупать дополнительно. Из-за этого пользователь может даже уйти из продукта.

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

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

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

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

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

Оценка рисков теста

Запуская тест, мы должны оценивать возможные риски: понимать, что может “поломаться” в каждой группе. Допустим, при росте конверсии в пользователя снижается количество покупок в приложении. То есть, потенциальный юзер прошел онбординг, но уходит из приложения спустя небольшое время — из-за этого в приложении низкий уровень вовлеченности. И хоть пользователей по факту становится больше, зарабатываем мы с них меньше.

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

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

Очистка результатов теста

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

Варианты сегментации:

  • По демографии — чаще страна, иногда пол + возраст. От этого фактора меняются даже каналы привлечения трафика;
  • По плательщикам — если хватает данных, делаем несколько сегментов;
  • По новым и старым юзерам — но если возможно, стоит тестировать только новых юзеров;
  • По платформе и источнику.

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

Проблемы тестов в мобильных приложениях

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

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

Еще в A/B-тестировании существует проблема “подглядывания” («peeking problem») — смысл в том, что продуктовая команда делает выводы и заканчивает тест досрочно.

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

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

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

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

Байесовский бандит

Перейдем к самым удобным, современным и быстрым A/B-тестам: так называемому “байесовскому многорукому бандиту”. Он представляет собой тесты, обновляемые в режиме реального времени на основе эффективности вариации. Самой эффективной группе отдается бОльшая доля. Проще говоря, это автооптимизация.

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

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

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

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

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

Как это работает: есть кабинет, где вы создаете эксперименты. Вы интегрируете SDK Appbooster в свое приложение и закладываете варианты тестируемого элемента. Если это пэйволл, разработчик сразу программирует несколько образцов. Это можно сделать заранее в большом количестве.

Далее билд добавляется в стор, и приложение получает версию с тестами. Когда пользователь открывает приложение, SDK Appbooster запрашивает на сервере доступные для него эксперименты. Это может зависеть от версий сборки или GEO пользователя.

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

Appbooster копит статистику в личном кабинете, делает вывод, используя калькулятор статзначимости и переносит изменения в базовую версию продукта. С пейволлом B конверсия со всех каналов трафика растет — он ставится по дефолту; переходим к тестированию следующего элемента.

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

Как понять, что вы готовы к A/B-тестам

Вы готовы к A/B-тестированию, если у вас:

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

Вывод: А/B-тесты можно проводить быстро, дешево и легко, если знать, как это делать. И делать это нужно систематически. Суть не в том, чтобы запустить тест один раз и забыть об этом навсегда. Качественный эффект вы получите только через цепочки изменений.

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

0
30 комментариев
Популярные
По порядку
Написать комментарий...

Как обычно, аккуратно обходятся две вечные проблемы аб тестов, а именно:

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

- Неконтролируемый рост аб тестов пропорциональный количеству заинтересованных в них манагеров. Как следствие, захламление проекта и отсутствие поддержки. Я не раз уже видел аб тесты на вещи, которые уже как сто лет выпилены в рамках какого-нибудь рефакторинга.  ред.

7

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

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

3

Прям по живому режешь) 

2

Комментарий удален по просьбе пользователя

1

Для этого, кстати, есть a/a/b тесты.
И для того же можно использовать a/b/n-тесты (если тестовые группы отличаются друг от друга меньше, чем от контрольной ИЛИ отличие строго линейное – тогда дельта между группами даст понять, можно ли доверять результату топ-перформящей группы или это натяжка совы на глобус)

0

Комментарий удален по просьбе пользователя

0

Так статья-то написана по вебинару совместному с Апбустер, где они рассказывали про свои тулы)

3

Прогоним те же вводные через калькулятор AB Testguide, использующий байесовский подход. Мы видим, что он дает однозначный ответ: вариант B на 90% успешнее остальных.

Нет, видим мы совсем другое (что именно - сказано в вебинаре и нарисовано на скриншоте). Пересказ доверили SMM-девочке? ред.

2

Ну, если подумать - а кто еще этим должен заниматься, и для чего вообще кормят SMM в штате?)

0

Cпасибо, что подметили, тут действительно вкралась ошибка. В тексте, к сожалению, правила сайта уже не позволяют поправить :)

0

ну все, буду зарабатывать сейчас 300кк/наносек

2
Парадный каякер

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

Так понимаю статья ради рекламы?

1

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

3
Парадный каякер

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

0

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

1

Статья для освещения того, как именно осуществляются важные процессы в продуктовом анализе. Статья выражает мнение конкретных специалистов компаний. Было бы неверно не рассказать мнением каких компаний она является. Когда новость про игру от Ubisoft и их подходы к разработке - это реклама Ubisoft? ред.

0
Парадный каякер

Когда новость про игру от Ubisoft и их подходы к разработке - это реклама Ubisoft?

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

Почему тогда тут это предложение? Почему в статье нет списка похож платформ для а\б тестов? Почему сразу в лоб приводится эта платформа? 
Почему не сказать что это реклама конкретного тула?)

1
Парадный каякер

Норм статья, на удивление о_О

1

Благодарим, стараемся.

0

Отличная статья! Спасибо! Когда будет вторая часть?

1
Парадный каякер

«Важно понимать, что мы не прогоняем результат через 100 калькуляторов, пока не получим удовлетворяющий итог. Результат в обоих случаях одинаков, а вот интерпретация данных разная.»
Фраза не понятна. Можете пояснить, пожалуйста.

0

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

1
Парадный каякер

Спасибо. Если именно это имелось ввиду - то это совсем не очевидно.
Причем тут 100 калькуляторов? И если удовлетворяющий итог уже получен - зачем прогонять его через эти 100 калькуляторов, ведь он уже удовлетворяющий? :) При этом результат ни визуально ни семантически (выше говорится, что второй байесовский метод дает однозначный результат, в отличие от первого метода) не одинаков, хотя говорится, что "Результат в обоих случаях одинаков". 
Т.е. какой вывод то можно сделать из всего этого? Использовать всегда байесовский калькулятор? Тогда зачем первый метод вобще нужен? Непоняяяятно :)

0

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

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

2
Парадный каякер

Путаю, т.к. вывод это тоже результат :)
"Результата – это посчитанные значения. В обоих случаях они одинаковые." - в одном случае посчитаны 2 доверительных интервала, в другом - Chance of being best. Не очень одинаково. Вцелом мысль теперь понятна, спасибо, но предложение все-равно считаю криво сформированным ;)

1

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

0

Но ведь все равно нужно получить веса тестовых групп и сигнал на включение/выключение теста из какого-нибудь внешнего конфига.

Если мы, конечно, не делаем совсем захардкоженный (со всеми сопутствующими рисками) тест.

1

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

0

Тут есть здравое зерно и, признаюсь, мы пожрали говна при переходе с хардкода на ремоут конфиги и до сих пор на некоторых проектах отдаем предпочтение хардкоду.
Но переходить надо, рано или поздно все там будем :)

2

Комментарий удален

Это материал про A/B-тестирование. Количество вопросов по этой теме среди маркетологов в мобильном геймдеве иногда превышает гору Джомолунгма

0
Читать все 30 комментариев
null