In-App інструменти ASO: як використовувати події та покупки для зростання в App Store і Google Play

Коли ми працюємо над ASO, основна увага зазвичай іде на те, що користувач бачить до встановлення: іконка, скриншоти, назва, опис, оцінки. Але App Store додав ще один шар можливостей, і він працює інакше.

In-App Events та In-App покупки на перший погляд здаються частиною продуктової логіки: один інструмент для залучення, інший для монетизації. Насправді обидва впливають на видимість у пошуку, розширюють семантичне покриття і створюють додаткові точки входу у воронку. І все це без жодної зміни в основних метаданих додатка.

У цьому матеріалі розбираємо, як влаштована їхня механіка в App Store і Google Play, як оптимізувати кожен із них і як побудувати зв'язку подія → покупка → ретеншн, яка працює системно.

Порівняльна таблиця: що дає кожен інструмент

Розберемо обидва інструменти окремо, а потім подивимося, як вони працюють у зв'язці.

In-App Events

Що це і як працює в App Store

In-App Events — картки тимчасових подій, які Apple розміщує в пошуку, на сторінці додатка і в редакційних добірках. Інструмент з'явився у 2021 році, і його головна механіка полягає в тому, що користувач бачить картку події прямо в сторі: із заголовком, візуалами і кнопкою дії, без необхідності відкривати сторінку додатка.

Картка з'являється в кількох місцях одночасно. У результатах пошуку вона відображається поряд з іконкою і назвою нашого додатка. Ті, хто вже встановив його, бачать картку події замість звичних скриншотів. На сторінці додатка формується окремий блок з активними подіями. І якщо подію оформлено грамотно, редактори Apple можуть включити її до добірок Today, Games, Apps або до персональних рекомендацій.

З картки користувач може відкрити деталі, натиснути «Повідомити про старт», перейти за посиланням у потрібний розділ і поділитися карткою з іншими. Технічно у нас є до 10 чернеток подій, з яких одночасно можна опублікувати до 5.

Типи подій і коли їх використовувати

Apple вимагає обрати тип події при створенні. Це не просто мітка: тип впливає на те, як App Store просуває подію в добірках і персональних рекомендаціях. Тому до вибору варто ставитися як до частини стратегії, а не як до формального кроку.

Challenge — користувач повинен виконати завдання до кінця події: пробігти потрібну дистанцію у фітнес-додатку або пройти 10 рівнів у грі. Працює, коли є вимірювана мета.

Competition — користувачі змагаються: рейтинг, очки, нагороди. Підходить для ігор і гейміфікованих сервісів.

Live Event — реальна подія в конкретний час: стрим, спортивний матч, онлайн-концерт. Головна умова — новий досвід або контент, доступний саме в цей час.

Major Update — глобальний апдейт, нова функція, редизайн. Баг-фікси і косметичні оновлення сюди не підходять.

New Season — новий сезон, історія, персонажі. Актуально для ігор і додатків з циклічним оновленням контенту.

Premiere — перший показ унікального контенту: фільму, подкасту, треку. Акцент на новизну, не на наявну бібліотеку.

Special Event — все, що не вписується в інші типи: колаборації, тимчасові активності, комплексні кампанії. Умова одна — має бути щось нове: контент, функція, пропозиція.

Як Events впливають на пошук

Тут важливо не плутати: з усіх метаданих події пошуковій індексації підлягають лише назва (до 30 символів) і короткий опис (до 50 символів). Довгий опис (до 120 символів) бачать лише ті, хто вже відкрив картку.

80 символів — це окреме семантичне поле. Через Events ми можемо ранжуватися за запитами, яких немає в основних метаданих додатка, і займати позиції в пошуку, не змінюючи назву або ключові слова в налаштуваннях App Store Connect.

Приклад: фітнес-додаток запускає челлендж 30 днів бігу. У короткому описі — Пробіжи 5 км щодня, потрап у рейтинг. Додаток починає показуватися за запитами челлендж біг, щоденні пробіжки, біговий марафон без змін в основних метаданих.

Ще один момент, який часто упускають: користувачі, які вже встановили наш додаток, не бачать скриншоти в пошуку. Замість них відображається картка активної події. Це можливість повернути інтерес до продукту в аудиторії, яка давно не відкривала додаток, ненав'язливо і без пуш-повідомлень.

Як оптимізувати картку події

Якщо розглядати картку події як міні-лендінг, кожен її елемент має працювати на конкретне завдання.

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

З медіа важливо пам'ятати: текст на картці відображається білим кольором, тому світлий фон і яскраві елементи в нижньому лівому куті створять проблему — заголовок просто не читатиметься. Відео запускається автоматично і повторюється по колу, тому краще робити плавний loop без різких переходів. Постер-фрейм (обкладинка) відображається до відтворення — це перше, що бачить користувач.

З таймінгом орієнтуємося на тип події і аудиторію: короткострокові події (кілька годин — пара днів) підходять для акцій і анонсів, середньострокові (тиждень) — для повторного залучення, довгострокові (місяць і більше) — для сезонних кампаній. Apple дозволяє налаштовувати таргетинг за країнами, мовами і типом аудиторії. Одна подія — одна мета, без розпорошення.

Помилки при роботі з Events

Найчастіша і найприкріша помилка — білий фон медіа. Подія готова, модерацію пройшла, але картку ніхто не читає: текст білий, фон білий, підсумок передбачуваний.

Слабкий заголовок — це коли замість конкретики в назві стоїть щось на зразок Новий апдейт вже тут. Це сповіщення, а не заголовок. Назва має говорити, що саме відбулося і чому це цікаво користувачеві прямо зараз.

Несвоєчасний запуск без урахування часових поясів теж зустрічається регулярно. Подія про літній контент у жовтні або новорічний івент, який стартував за UTC і вже завершився на момент, коли потрібна аудиторія прокинулася — це втрачене охоплення.

Apple не схвалює щоденні повторювані активності, звичайні знижки без нового контенту і загальні промо без чіткої прив'язки до події.

І ще один момент: не варто ігнорувати довгий опис тільки тому, що він не індексується. Його читають ті, хто вже зацікавився. Тут потрібно закрити питання про те, чому варто брати участь саме зараз, а не повторювати заголовок іншими словами.

Google Play: аналог Events — LiveOps

Google Play запустив схожий інструмент у рамках LiveOps, але логіка роботи відрізняється.

В App Store Events показуються в пошуку всім користувачам і явно беруть участь у пошуковій індексації через метадані. У Google Play події менш інтегровані в пошукову видачу: ставка більше на головну сторінку і персональні рекомендації, а механізм індексації менш прозорий. App Store Connect дає детальний розбір за цілями подій — залучення, залученість, повернення. Google Play Console пропонує більш обмежений набір метрик.

Для додатків з крос-платформною аудиторією це означає, що стратегія Events буде різною для двох платформ: в App Store акцент на пошукову індексацію і метадані, у Google Play — на візуальну складову і охоплення через рекомендаційну систему.

In-App покупки як інструмент ASO

Як IAP індексуються в App Store і впливають на видимість

In-App покупки в App Store — це не лише джерело доходу, а й окремі точки входу з пошуку. Кожна покупка з оптимізованою назвою і іконкою може з'являтися в пошуковій видачі поряд з основним додатком як самостійний елемент.

Працює це так: якщо користувач шукає бізнес-англійська, а у нашого мовного додатка є IAP з такою назвою, картка покупки з'явиться в результатах пошуку. Користувач може перейти до покупки напряму, без відкриття сторінки додатка. Кожен правильно оптимізований IAP — додаткова точка, через яку нас знаходять у пошуку, без будь-яких змін в основних метаданих. Що відображається у видачі: іконка покупки, назва IAP, тип (підписка або разова покупка).

Що бачить користувач у пошуку

У результатах пошуку App Store картка IAP з'являється під основною карткою додатка. Для користувачів, які вже встановили додаток, це прямий шлях до конверсії. Для нових — спочатку встановлення, потім покупка. В обох випадках IAP створює додатковий контакт ще на етапі пошуку, до того як користувач потрапив на сторінку додатка.

Оптимізація назв IAP під пошукові запити

Підхід тут схожий з класичною роботою з метаданими, тільки об'єкт оптимізації інший.

Спочатку ми збираємо запити, пов'язані з функціями, які пропонує конкретна покупка. Для фітнес-додатка це можуть бути персональне тренування, план харчування, трекер калорій. Потім підбираємо назву, яка одночасно описує цінність для користувача і містить цільове слово. Персональний план тренувань — робочий варіант. Преміум-доступ — ні, бо за таким запитом нас ніхто не шукає.

Паралельно дивимося, як називають свої IAP-додатки в топі нашої категорії і які запити вони закривають. Через 2-4 тижні після оновлення назв оцінюємо зміни в позиціях за цільовими запитами.

Важливе обмеження: Apple може відхилити IAP з оманливою назвою. Фокус на точності і релевантності, не на клікбейті.

Приклад для мовного додатка: IAP Розмовна практика з носіями покриває запити про розмовну мову, Підготовка до IELTS закриває окремий запит, Бізнес-англійська для роботи залучає інший сегмент аудиторії. Три покупки — три сегменти — три додаткові точки входу з пошуку.

У Google Play: підписки і покупки в лістингу

У Google Play IAP не отримують окремі позиції в пошуку так само, як в App Store.

Але покупки і підписки відображаються на сторінці додатка в спеціальному блоці, який користувач бачить ще до встановлення.

Тут працює інша логіка. Чіткий опис підписки з конкретними перевагами — 7 днів безкоштовно, потім $4.99/міс — конвертує краще, ніж просто Преміум. Зрозуміла іконка IAP, яка відрізняється від основної іконки додатка, допомагає користувачеві швидко зчитати, про що мова. Порядок пропозицій на сторінці теж має значення: вигідніші варіанти краще розміщувати вище.

Непрямо на ранжування в Google Play впливають метрики: високий engagement платних користувачів і хороші показники retention сигналізують алгоритмам про якість додатка.

Зв'язок IAP з конверсією: як побудувати ієрархію пропозицій

Навіть якщо наші IAP чудово оптимізовані для пошуку, конверсія багато в чому залежить від того, як пропозиції вибудовані всередині додатка.

Робоча модель будується на трьох рівнях. Базовий варіант — найдоступніший, з низьким порогом входу. Його мета — перша транзакція. Оптимальний рівень пропонує найкраще співвідношення ціни і цінності, його часто позначають як популярний. Більшість користувачів, що конвертуються, обирає саме його. Преміум потрібен як якір, щоб оптимальний варіант виглядав розумним на його тлі.

Відсутність вибору створює ситуацію брати чи не брати замість що саме брати. Одна пропозиція замість трьох — типова помилка. Пробний період на 3-7 днів для підписок знижує бар'єр входу. Ключова метрика після — утримання після завершення тріалу.

Як Events і IAP працюють разом

Зв'язка: подія, покупка, ретеншн

Events і IAP рідко розглядають як систему — і дарма. У зв'язці вони закривають три завдання одночасно.

Подія залучає або повертає користувача: людина бачить картку в пошуку, дізнається про новий контент або акцію і відкриває додаток. IAP конвертує цей інтерес у транзакцію — особливо якщо подія супроводжується обмеженою пропозицією. Після покупки користувач з більшою ймовірністю повернеться, коли побачить наступну подію. Три етапи складаються в петлю: подія → покупка → повернення на наступну подію.

Сезонні кампанії: як поєднати Event з обмеженим IAP

Сезонні кампанії — найочевидніший формат для зв'язки, але важлива синхронізація.

Ми запускаємо Event типу Special Event або New Season із сезонною тематикою і одночасно додаємо IAP з обмеженою пропозицією. У короткому описі події згадуємо її: Обмежений доступ до зимової колекції. Користувач бачить подію в пошуку, переходить у додаток, бачить пропозицію з чітким дедлайном. Urgency працює, якщо вона реальна.

Що не працює — подія без зв'язку з IAP. Якщо назвати подію Зимний розпродаж, а всередині додатка користувач побачить стандартні ціни без змін, конверсії не буде. Невідповідність відчувається одразу.

Приклади з практики

В іграх механіка зазвичай виглядає так: RPG запускає New Season з новим сюжетом, і одночасно в сторі з'являється IAP Стартовий набір — сезон 3 зі знижкою 40%. Картка події індексується за запитами, пов'язаними з персонажами нового сезону. Результат — зростання встановлень серед нової аудиторії і конверсія в IAP у наявної.

У фітнес-додатках добре працює січневий Challenge 30 днів тренувань з одночасним запуском IAP Річний план з персональним тренером за спеціальною ціною тільки для учасників. Механіка ексклюзивності підіймає конверсію в підписку.

У стримінгу Premiere Event навколо нової прем'єри добре доповнюється IAP з доступом до ексклюзивного контенту або пробною підпискою на місяць. Користувач, якого залучила конкретна прем'єра, конвертується в підписника.

Моніторинг і аналітика

Як відстежувати ефективність Events через ASOMobile

Аналізувати Events конкурентів вручну — скролити стор і запам'ятовувати, що коли запускалося — це не стратегія. В інструменті Timeline в ASOMobile ми бачимо події конкурентів: коли запущені, який тип обрано, які метадані використано. Поле конкурентів вже сформоване, і ми отримуємо загальну картину без зайвої роботи.

Це допомагає в двох напрямках: бачити, як конкуренти вибудовують Event-стратегію по сезонах, і знаходити незакриті ніші в семантиці — запити, які конкуренти використовують в Events, але яких немає в нашому семантичному ядрі.

Розділ Featuring показує, чи потрапила наша подія в редакційні добірки Apple і на яких ринках. App Store просуває події, які оформлені правильно і відповідають критеріям платформи, тож це хороша метрика якості самої події.

Як аналізувати IAP конкурентів через In-App Monitor

In-App Monitor в ASOMobile показує IAP конкурентів. За його допомогою можна відстежувати зміни позицій покупок усередині додатка за пошуковими запитами, а також оцінювати запити за точними даними про потенційний трафік, складність і ефективність. Релевантність запиту перевіряється швидким доступом до результатів пошуку в App Store.

Це дає кілька практичних висновків. Ми бачимо, як конкуренти називають свої покупки і які ключові слова закривають — фактично це готова карта запитів, які працюють у нашій ніші. Ми бачимо ієрархію: скільки рівнів пропонують конкуренти і як називають пакети. Якщо всі використовують три рівні, а ми пропонуємо один, ми програємо на етапі вибору. І ми бачимо динаміку: коли конкуренти оновлювали назви IAP і чи збігається це з сезонними кампаніями.

In-App Keywords показує, за якими пошуковими запитами індексуються наші IAP. Це прямий спосіб знайти позиції, які можна покращити через оновлення назв покупок.

Чеклист перед запуском

Для In-App Events

• Тип події (бейдж) відповідає змісту
• Назва події (до 30 символів) містить релевантний пошуковий запит
• Короткий опис (до 50 символів) розширює пошукове покриття, не дублює заголовок
• Довгий опис розкриває деталі: терміни, умови, чому цікаво саме зараз
• Немає білого фону; яскраві елементи не перекривають текст у нижньому лівому куті
• Відео оформлене як loop, постер-фрейм обрано
• Тайминг враховує часові пояси цільової аудиторії
• Налаштовано таргетинг за сегментом: нові, активні або неактивні користувачі
• В App Store Connect задано мету події
• Перевірено попередній перегляд картки на різних пристроях
• Подія не порушує обмеження Apple

Для In-App покупок

• Назва IAP містить цільовий пошуковий запит, до 30 символів
• Назва зрозуміла без контексту: що саме отримує користувач
• Іконка IAP відрізняється від основної іконки і однозначно зчитується
• Є три рівні пропозицій, оптимальний візуально виділено
• Для підписок передбачено пробний період
• IAP перевірені через In-App Keywords: запити, що покриваються, відповідають цільовій аудиторії
• Конкуренти перевірені через In-App Monitor: немає упущених семантичних ніш
• Для Google Play: опис підписки заповнено, ієрархія вибудувана на сторінці додатка
• Назва IAP відповідає вимогам App Store і не вводить в оману

ASO — просто та вигідно. Оптимізуйте легко й досягайте успіху.