Найкращі практики для скріншотів App Store, що витримують тестування
TL;DR:
- Більшість найкращих практик для скріншотів App Store насправді не є практиками. Це гіпотези, що спрацювали в чужому застосунку.
- Незмінними є лише дві речі: те, що вимагає Apple, і те, що магазин показує технічно.
- Усе інше ви тестуєте на власному трафіку.
- У Apple Ads ця різниця коштує грошей, адже ви платите за натискання.
- Слабкий набір асетів проявляється як дорожче натискання, а не лише як слабший скріншот.
Що насправді вважається найкращими практиками для скріншотів App Store
Найкращі практики для скріншотів App Store поділяються на дві групи, і найпоширеніша помилка — змішувати їх.
Обмеження — це те, що вимагає Apple і що магазин показує технічно. Це не думки. Налаштуйте їх правильно один раз і більше не перечитуйте.
- Скріншоти в результатах пошуку. Залежно від орієнтації, у результатах пошуку відображаються перші від одного до трьох зображень — і лише якщо немає доступного відеопрев’ю застосунку, згідно з рекомендаціями Apple щодо сторінки продукту. Решта з’являються, коли користувач відкриває сторінку продукту.
- Розміри та формати. Специфікації скріншотів Apple визначають межі завантаження. У нашій статті Розміри та виміри скріншотів App Store є робочий список.
- Іконка застосунку. Вона присутня всюди: у результатах пошуку, на сторінці та на головному екрані. Детальніше — у як створити дизайн іконки застосунку.
- Відеопрев’ю застосунку. Воно автоматично відтворюється без звуку, а на одній сторінці може бути до трьох таких відео. Якщо воно є, то займає в результатах пошуку місце, яке інакше отримали б ваші скріншоти. Правила наведені на сторінці Apple відеопрев’ю застосунків.
Ключовий момент: Правило щодо скріншотів поза рівнем обмежень є гіпотезою, а не найкращою практикою, доки ваш власний трафік не доведе інше.
Гіпотези — це все інше. Темний фон. Підписи на першому екрані. Обличчя на першому скріншоті. Порядок функцій.
Кожну з них підтвердила інша аудиторія з іншим пошуковим наміром. Для вашого застосунку це лише припущення з гарним скріншотом поруч.
Тож розподіліть кожне правило в одну з цих двох груп, перш ніж ставити завдання дизайнеру. А групу гіпотез завжди розглядайте як відправну точку, а не як вимогу. Ідеї, які варто спробувати, є в нашій статті про оптимізацію скріншотів App Store.
Чому ваші скріншоти визначають, скільки ви платите в Apple Ads
Ваші скріншоти визначають, скільки ви платите, оскільки Apple Ads стягує плату за натискання, а не за показ. Результат задають три окремі чинники, і корисно не змішувати їх.
- Ваша ставка — це стеля. Вона обмежує суму, яку ви можете заплатити. Вона не визначає, скільки ви заплатите.
- Релевантність визначає покази. Семантика ключового слова у співвідношенні з вашим лістингом у магазині визначає, чи взагалі ви маєте право на показ, ще до того, як постане питання креативу.
- Реакція на асети визначає цінність показу. Іконка застосунку та перші скріншоти впливають на коефіцієнт переходів за натисканням. Решта сторінки продукту впливає на конверсію з натискання в завантаження.
Ключовий момент: Ставка обмежує вартість натискання. Релевантність і реакція на асети визначають, чи вас покажуть і скільки ви фактично заплатите.
А тепер частина, що є спостереженням, а не задокументованим механізмом.
Я спостерігав, що застосунок із поганою конверсією отримує менше обсягу та дорожче натискання. Це саме ті дві речі, які люди намагаються виправити підвищенням ставки. Apple не публікує цю логіку, тож сприймайте її як закономірність, за якою варто стежити, а не як правило для планування.
Практичний висновок залишається незмінним у будь-якому разі. Слабкий набір асетів — це проблема ціни, а не лише дизайну.
Саме тут робота над асетами зазвичай зупиняється зарано. Редизайн випускають, і ніхто не повертається перевірити, що сталося з CPT або коефіцієнтом переходів за натисканням.
Кастомні сторінки продукту дають кожному пошуковому наміру власні асети
Кастомні сторінки продукту — це варіанти сторінки продукту, що показують різний набір асетів різному трафіку, і група оголошень Apple Ads може посилатися на конкретну з них.
Це важливо, бо одна стандартна сторінка для всіх — це інструмент усереднення.
Людина, яка шукає назву вашого бренду, і людина, яка шукає загальний термін категорії, — не одна й та сама людина. Сьогодні вони потрапляють на ідентичні асети.
Початкова гіпотеза: тому, хто шукає бренд, потрібне підтвердження надійності, а тому, хто шукає категорію, потрібна ваша відмінність уже на першому скріншоті. Це місце, з якого варто почати тест, а не факт про поведінку людей.
Ключовий момент: Сегментація асетів за пошуковим наміром — це те, що роблять можливим кастомні сторінки продукту. Що саме сказати кожному наміру — вирішує тест.
Кількість потрібних вам сторінок випливає з тем ваших ключових слів, а не з цільового числа. Природні кандидати:
- Бренд
- Конкурент
- Категорія та загальні запити
- Функція або сценарій використання
Тема з власним наміром і достатнім обсягом може мати власну сторінку. Тема без такого обсягу цілком може залишитися на стандартній сторінці.
Це аргумент на користь груп оголошень з одним ключовим словом, застосований до креативів. Сильний контроль там, де його підтримує обсяг, і чисті накладні витрати там, де ні. Не правило, якого слід дотримуватися всюди.
Механіка описана в кастомних сторінках продукту в App Store та в документації Apple про кастомні сторінки продукту.
Як A/B-тестувати асети App Store без припущень
Тест асетів App Store дає відповідь лише тоді, коли група оголошень за ним має реальну історію. Кілька інсталяцій на місяць вимірюють шум, а не креатив.
Саме тому серйозний інструмент не запускає тест без історії. Одразу зазначу: я працюю в Adapty, тож це не нейтральна думка.
- Історія. A/B-тестування CPP в Adapty Ads Manager вимагає, щоб вихідна група оголошень існувала щонайменше 28 днів і мала покази, натискання та інсталяції за цей період.
- Варіанти. Тест порівнює від 2 до 4 сторінок продукту. Ваша стандартна сторінка може бути контролем, якщо ви хочете дізнатися, чи кастомна сторінка перевершує ваш базовий рівень. Тест лише кастомних сторінок теж підходить.
Рівень трафіку також визначає, як швидко чергуються варіанти:
| Інтервал перемикання | Рівень трафіку | Типова тривалість тесту |
| Щогодини | Високий (5,000+ показів на день) | Дні |
| Щодня | Звичайний | Тижні |
| Щотижня | Низький (менше ніж 400 показів на день) | Місяці |
Низький трафік не блокує тест. Це лише означає, що відповідь з’явиться через місяці.
Ключовий момент: Тест асетів щось означає лише тоді, коли група оголошень за ним має достатньо історії, щоб відокремити сигнал від шуму.
Щоб запустити тест:
- Узгодьте метрику, що визначатиме результат, до запуску, поки ніхто ще не дивиться на результати. Таблиця варіантів показує TTR, CR від натискання до завантаження, CPT, CPA, витрати, дохід і ROAS.
- Виберіть одну групу оголошень з історією, щоб порівняти кілька сторінок між собою.
- Виберіть від 2 до 4 варіантів, зі стандартною сторінкою як контролем або без неї.
- Установіть точність — найменшу різницю в конверсії, яку тест може виявити. Доступні значення від 1% до 5%, за замовчуванням — 5%; 3–4% є збалансованим вибором.
- Установіть рівень упевненості — від 80% до 99%, за замовчуванням — 90%. Вищий рівень упевненості потребує більше даних і часу.
- Запустіть тест. Система клонує групу оголошень по одному разу для кожного варіанта, запускає по одному клону за раз і чергує їх за вашим розкладом. Наприкінці відновлюється оригінальна група.
- Суворо дотримуйтеся правила визначення переможця. Варіант стає загальним переможцем лише тоді, коли лідирує за визначальною метрикою з рівнем упевненості 95% або вище. Поки варіанти не мають зіставної кількості показів, нічого не виділяється.
Оптимізація сторінки продукту від Apple охоплює тестування на органічному трафіку. Процес вище — це версія для платних медіа.
Ще одна річ, яку ми будуємо: тестування самих рекламних креативів для Apple Ads, а не лише сторінок продукту. Ще не випущено.
