A/B-тест карточки приложения: как не принять случайность за победу

Самый опасный момент наступает, когда график радует

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

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

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

Карточка показывает только начало пути

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

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

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

Гипотеза должна допускать неприятный ответ

Формулировка «сделаем современнее» ничего не проверяет. «Добавим эмоций» звучит чуть конкретнее, но все равно не связывает изменение с поведением. Рабочая гипотеза может выглядеть так:

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

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

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

Тестируйте слабое место, а не то, что проще перерисовать

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

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

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

Что можно проверить в App Store

В Apple инструмент называется Product Page Optimization. Он позволяет сравнить исходную страницу максимум с тремя вариантами и тестировать альтернативные иконки, скриншоты и видео. Команда задает долю трафика и локализации, а посетители распределяются случайно. В актуальной справке App Store Connect указано, что приложение должно находиться в статусе Ready for Distribution.

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

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

Как устроен эксперимент в Google Play

Store Listing Experiments работают с основной и специальными страницами приложения. При настройке доступны доля аудитории, минимальный обнаруживаемый эффект и уровень доверия. Google в русскоязычной инструкции рекомендует менять один ресурс за раз, чтобы результат можно было связать с конкретной причиной.

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

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

В RuStore тоже есть эксперименты со страницей

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

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

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

Победителя нельзя просто перевести

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

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

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

Хороший вариант заметно отличается по одной причине

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

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

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

Правило решения нужно написать до старта

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

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

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

Относительный прирост без исходной цифры вводит в заблуждение

Если конверсия выросла с 20% до 22%, абсолютная разница составляет два процентных пункта. Относительный прирост равен 10%. Обе цифры верны, но фраза «конверсия выросла на 10%» без исходного уровня звучит гораздо внушительнее.

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

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

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

При небольшом трафике меняется порядок работы

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

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

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

Как Appfyl связывает карточку с первым запуском

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

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

Посмотрите, как Appfyl превращает объем работ в запущенные продукты. Смотреть кейсы Appfyl.

Частые вопросы