Как проводить A/B-тесты скриншотов в App Store для роста конверсии

Почему стоит A/B-тестировать именно скриншоты?

Скриншоты — самый влиятельный актив в карточке приложения. Собственные данные Apple по Product Page Optimization показывают, что первые три скриншота дают наибольший прирост конверсии — больше, чем иконка, подзаголовок и даже видеопревью приложения. Документация Google по Store Listing Experiments подтверждает то же самое: победы в графических тестах обычно значительно превышают победы в текстовых тестах.

Команды пропускают тесты скриншотов из-за высокого порога входа. Подготовка четырёх наборов претендентов (контроль + 3 варианта) × три размера iPhone × два размера iPad × локали, в которых вы релизитесь, означает десятки файлов на один тест. С API-рендером порог исчезает — одно дублирование шаблона, одно изменение параметра, один вызов API.

Что именно стоит тестировать?

Тестируйте по одной переменной за раунд. Самые влиятельные переменные в порядке убывания эффекта:

• Заголовок первого скриншота — виден в результатах поиска без прокрутки
• Главная функция — какую возможность вы выводите на первый план
• Стиль фона — однотонный, градиент или фотография
• Рамка устройства — с рамкой или без, угол наклона мокапа
• Положение подписи — сверху, снизу или поверх изображения
• Цвет CTA-элемента — основной цвет бренда против контрастного акцента

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

Как программно генерировать варианты?

Дублируйте контрольный шаблон в редакторе, измените один элемент, сохраните. Затем рендерьте каждый вариант одним и тем же вызовом API — отличается только templateId:

# Render the control + 3 challengers
for VARIANT in control red_cta photo_bg short_headline; do
  curl -X POST https://api.screenshots.live/v1/renders \
    -H "Authorization: Bearer $SCREENSHOTSLIVE_API_TOKEN" \
    -H "Content-Type: application/json" \
    -d "{
      \"templateId\": \"tpl_home_v3_${VARIANT}\",
      \"locales\": [\"en-US\"],
      \"devices\": [\"iphone-6.7\", \"iphone-6.1\"],
      \"outputDir\": \"./variants/${VARIANT}\"
    }"
done

В большинстве тестов имеет смысл рендерить только те локали, на которые тест действительно нацелен. Apple Product Page Optimization работает по локалям, поэтому для теста только в США достаточно ассетов en-US.

Как настроить тест в App Store Connect (PPO)?

Apple Product Page Optimization позволяет тестировать до трёх вариантов-претендентов против вашей страницы по умолчанию в одной локали. Apple распределяет трафик случайным образом, показывает показы и конверсию по каждому варианту, а также доверительные интервалы, когда тест достигает значимости.

1. В App Store Connect откройте приложение → Product Page Optimization → Create New Test.
2. Добавьте до трёх вариантов страницы продукта. У каждого варианта свой набор скриншотов, видеопревью и иконка.
3. Распределите трафик. Значение по умолчанию — 25% на вариант (контроль + три) — подходит большинству приложений.
4. Выберите локализацию. PPO работает по локалям — один и тот же тест нельзя одновременно применить к нескольким локалям.
5. Отправьте на проверку. Каждый вариант проходит App Review так же, как обычная сборка.
6. Запустите тест после одобрения всех вариантов.

Актуальные ограничения и сроки проверки смотрите на официальной странице Apple Product Page Optimization.

Как настроить Google Play Store Listing Experiments?

Процесс в Google похож, но более гибкий. В Play Console перейдите в Store Presence → Store Listing Experiments → Create Experiment. Выберите:

• Тип: Default Listing (глобальный) или Localized Listing (по локалям)
• Ассет: скриншоты телефона, 7-дюймового планшета, 10-дюймового планшета, feature graphic, иконка
• Варианты: до трёх претендентов против контроля
• Распределение аудитории: 25%/25%/25%/25% по умолчанию или произвольное

Play Console сама рассчитывает доверительные интервалы и помечает победителя, когда прирост статистически значим. Свежую документацию Google смотрите по ссылке Run experiments on your store listing.

Какой размер выборки нужен?

Используйте стандартный калькулятор z-теста для двух пропорций со следующими параметрами:

• Базовая конверсия: ваш текущий CTR страницы продукта (обычно 25–35% в App Store, 5–10% в Google Play)
• Минимально детектируемый прирост: относительный прирост 5% — разумная планка; ниже 3% редко стоит затраченного времени
• Уровень значимости: 95% (α = 0,05)
• Мощность: 80% (β = 0,20)

Для базовой конверсии 30% и относительного прироста 5% потребуется примерно 100–150 тыс. показов на вариант. Большинству приложений с менее чем 50 тыс. показов в неделю стоит проводить последовательные тесты (один вариант две недели, затем следующий, со сравнением со стабильным историческим базовым уровнем) вместо параллельных.

Сколько должен длиться тест?

Минимум одну полную неделю. Конверсия заметно колеблется по дням недели и по источникам трафика (Search Ads против органики). Семь дней охватывают один полный недельный цикл. Две недели лучше, когда трафика мало. Останавливайте тест досрочно только если: (а) разница подавляющая (>30% прирост) и (б) тест шёл минимум семь полных дней. Досрочная остановка по шуму — самый частый способ выкатить версию хуже исходной.

Как читать результаты, не обманывая себя?

Используйте доверительный интервал самой платформы. И Apple PPO, и Google Play Experiments показывают доверительные интервалы 90% / 95% для прироста варианта над контролем. Если интервал пересекает ноль — тест неубедителен; не внедряйте претендента только потому, что точечная оценка положительна.

Не пытайтесь выводить результаты из данных стороннего MMP. Какой вариант видит пользователь, решает сервер Apple или Google — ваш MMP не может определить, из какого варианта пришёл пользователь. Дашборд самого магазина — единственный источник истины.

Что делать с победителем?

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

Совмещайте это руководство с руководством по автоматизации CI/CD, чтобы варианты генерировались автоматически с каждым релизом, и с руководством по локализации, чтобы победитель переводился на 30+ языков без повторного тестирования каждой локали.