· Optimization · 6 мин чтения

Google Play Store Listing Experiments: A/B-тестирование скриншотов (2026)

Google Play Store Listing Experiments: A/B-тестирование скриншотов (2026)
TL;DR. Store Listing Experiments — встроенный бесплатный инструмент Play Console для A/B-тестирования ресурсов листинга, включая скриншоты. Можно запустить до 3 вариантов против текущего листинга, выбрать уровень достоверности (90/95/98/99%) и минимальный обнаруживаемый эффект — Google сам разделит живой трафик и определит победителя. Держи каждый тест минимум 7 дней, набери достаточно установок на вариант для значимости и меняй одну вещь за раз. Это аналог Apple Product Page Experiments со стороны Play.

В Google Play не нужно гадать, конвертирует ли новый первый скриншот лучше старого, — можно проверить это на реальном трафике Play Store. Store Listing Experiments встроены в Play Console, раздел Test and release → Store listing experiments (Google не раз переносил этот пункт меню; в старых руководствах он называется «Grow → Store listing experiments»). Это бесплатно, работает на твоём живом листинге, а разделение трафика и статистику Google берёт на себя.

Если ты публикуешься в обоих магазинах, это аналог настройки Apple. Сторону iOS мы разобрали в статье A/B-тестирование скриншотов App Store с Product Page Experiments — идея та же, механика другая. Этот пост — дополнение со стороны Play.

Как работают Store Listing Experiments

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

В результатах важны две метрики:

  • Привлечение (конверсия листинга). Доля посетителей, установивших приложение после просмотра конкретного варианта. Это ключевая цифра для тестов скриншотов.
  • Удержание новых установщиков (retention за 1 день). Остаются ли пользователи, привлечённые вариантом, ещё день спустя. Вариант, который даёт больше установок, но худшее удержание, возможно, что-то переобещал.

Google рассчитывает доверительный интервал для каждого варианта и, когда вариант проходит выбранный тобой порог достоверности, объявляет его победителем. Можно подключить email-уведомление, чтобы не следить за панелью постоянно. Применить победителя — одно нажатие, но обычно всё равно стоит провести победивший ресурс через обычный процесс релиза/ревью, чтобы остальной листинг оставался согласованным.

Графика по умолчанию против локализованных экспериментов

На этом месте многие спотыкаются, и от этого зависит, сколько тестов можно вести параллельно.

  • Эксперимент с графикой по умолчанию. Тестирует ресурсы листинга по умолчанию — того, что видят все, кому не показывается локализованная версия. Пользователи, которым показаны локализованные ресурсы, исключены из аудитории этого эксперимента. Можно вести только один такой эксперимент одновременно.
  • Локализованный эксперимент листинга. Тестирует ресурсы (и/или текст) для конкретного языка. Можно вести до 5 локализованных экспериментов одновременно — например, один для немецкого, один для японского, один для бразильского португальского и так далее, все сразу.

На практике: если установки сосредоточены в нескольких рынках, локализованные эксперименты позволяют тестировать эти рынки параллельно, а не выстраивать их в очередь за одним глобальным тестом. И не путай язык со страной: выбор «English (United States)» не ограничивает аудиторию США — он нацелен на всех, кому показывается этот локализованный листинг, где бы они ни находились.

Настройка A/B-теста скриншотов

  1. Открой Store listing experiments и создай эксперимент. Выбери листинг по умолчанию или конкретный локализованный листинг и дай ему название, которое ты поймёшь и через три недели («Главный скриншот — подпись с акцентом на выгоду v2»).
  2. Выбери ресурс. Отметь скриншоты. Тестируй один элемент за эксперимент — не меняй иконку и скриншоты в одном тесте, иначе не поймёшь, что именно повлияло на результат.
  3. Загрузи до 3 вариантов. Твой живой листинг — контроль. Каждый вариант — полный набор скриншотов правильного размера для Play; точные параметры — в справочнике размеров скриншотов Google Play.
  4. Задай аудиторию, достоверность и MDE. Распредели трафик между вариантами (обычно поровну — 50/50 для одного варианта против контроля или примерно по трети для трёх). Выбери уровень достоверности (90%, 95%, 98% или 99%) и минимальный обнаруживаемый эффект — наименьшее улучшение, которое стоит зафиксировать, настраивается примерно в диапазоне 0,5–6%. Play Console показывает условия завершения теста, так что ты видишь, на что подписываешься, ещё до старта.
  5. Запусти и не трогай. Не поддавайся желанию заглянуть и остановить тест раньше срока, как только вариант вырывается вперёд. Дай ему дойти до заданных условий.

Размер выборки, длительность и достижение значимости

Честный ответ на вопрос «сколько времени держать тест?» такой: пока не выполнятся заданные условия значимости — а не фиксированное число дней. Но есть реальные нижние и верхние границы.

  • Держи минимум 7 дней. Поведение при установке меняется в будни и выходные. Всё, что короче полной недели, встраивает в результат смещение по дням недели. Две недели (14 дней) — распространённый, более безопасный вариант по умолчанию, а приложениям с низким трафиком часто нужно 28 дней.
  • Достаточно установок на вариант, чтобы это имело значение. Значимость зависит от объёма установок, числа вариантов, уровня достоверности и MDE. Как грубый рабочий ориентир — стремись к порядку 1000+ установок на вариант, прежде чем доверять результату, — больше, если задан высокий уровень достоверности или маленький MDE.
  • Более жёсткие настройки требуют больше трафика. Уровень достоверности 99% или MDE 0,5% требует намного больше установщиков, чем 90% / 3%. Если у приложения низкий объём, требовательная конфигурация может никогда не дойти до значимости — смягчи MDE или прими 90%.

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

Ограничение по числу вариантов и что из него следует

Три варианта против контроля — жёсткий предел на эксперимент. Это особенность, а не ограничение, с которым нужно бороться: каждый дополнительный вариант дробит трафик тоньше и отодвигает значимость дальше. С тремя претендентами трафик листинга уже делится на четыре части (контроль + 3). Для большинства приложений один смелый, явно отличающийся претендент против контроля приводит к выводу быстрее, чем четыре расплывчатых вариации когда-либо приведут.

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

Каких ошибок избегать

  • Менять больше одной переменной. Новые скриншоты и новое краткое описание в одном тесте = результат, который невозможно интерпретировать. Изолируй переменную.
  • Останавливаться рано на «победителе». Ранние лидеры откатываются назад. Объявить победителя на 3-й день, потому что вариант обгоняет на 8%, — верный способ уверенно выкатить худший листинг.
  • Держать тест меньше 7 дней. Ты захватишь одну часть недельного цикла и упустишь остальное.
  • Слишком жёсткая статистика для приложения с низким трафиком. Требовать 99% / MDE 0,5% при скромном числе установок гарантирует неопределённый и затратный по времени тест.
  • Игнорировать retention за 1 день. Скриншот, который переобещает, может поднять установки и просадить удержание. Следи за обеими цифрами.
  • Забыть про разделение на дефолт/локализацию. Эксперимент с графикой по умолчанию не затрагивает пользователей на локализованных листингах — если твоя аудитория в основном локализована, тестируй там.
  • Тестировать только последний скриншот. Первые 2–3 панели делают основную работу по убеждению в Play Store. Тестируй в первую очередь их. (Подробнее о том, чем Play отличается от Apple: различия скриншотов в Play Store и App Store.)

Место Mokbi в этой картине

Mokbi не проводит A/B-тест — это делает Play Console, и это бесплатно. Большинству команд время тратится на другое: на создание самих вариантов, ведь убедительный претендент — это полный набор скриншотов правильного размера для Play, с реально изменённой подписью и раскладкой. В Mokbi ты собираешь один набор в браузере, затем дублируешь его и меняешь ведущую подпись, раскладку или фон, чтобы получить вариант B, — и переводишь подписи в один клик, если ведёшь локализованные эксперименты сразу на нескольких рынках. Дизайн бесплатен, с предпросмотром с водяным знаком; безлимитный экспорт без водяного знака и публикация доступны по подписке — Solo за €29.99/mo (1 приложение) или Studio за €49.99/mo (до 5 приложений), без разовой оплаты. Это ускоряет создание претендентов; кто из них победит, решает Play Console.

Что читать дальше

Открыть редактор →