Запуск мобільного застосунку: чекліст для інді-розробників

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

У цьому посібнику план розібрано по черзі — від перевірки ідеї до утримання користувачів. Правила магазинів змінюються, тож уточнюйте деталі в офіційній документації.

Перед розробкою: перевірте ідею й запустіть список очікування

Найдешевше виправити ту помилку запуску, яку ви помітили ще до написання застосунку.

Перевірте попит за кілька днів

• Читайте відгуки про конкурентів. Відгуки з низькими оцінками на схожі застосунки перелічують, чого користувачі хочуть, але не отримують.
• Поговоріть із потенційними користувачами. Кілька коротких розмов покажуть, чи достатньо болюча проблема, щоб заради неї завантажувати застосунок. Питайте, як люди розв’язують її зараз, а не чи подобається їм ваша ідея.
• Пошукайте в магазинах. Введіть фрази, які ввели б ваші користувачі. Слабкі чи застарілі результати — це шанс для вас.

Зробіть простий лендинг зі списком очікування

Достатньо однієї сторінки з чітким заголовком, кількома скриншотами чи макетами й формою підписки на email. Усі, хто підпишеться, зможуть долучитися до бети й дізнатися про день запуску.

Збирати інтерес можуть і самі магазини: App Store підтримує попередні замовлення, а Google Play — попередню реєстрацію, тож люди отримають сповіщення, коли застосунок стане доступним. Перевірте актуальні умови для кожного магазину.

Визначте першу версію

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

Бета-тестування: TestFlight і треки тестування Google Play

Бета виявляє збої та незрозумілі екрани, яких ви самі вже не помічаєте, і перетворює підписників зі списку очікування на залучених користувачів.

TestFlight на iOS

TestFlight від Apple поширює бета-збірки через App Store Connect.

• Внутрішні тестувальники — це учасники вашої команди в App Store Connect; вони можуть встановлювати збірки без бета-перевірки.
• Зовнішніми тестувальниками може бути будь-хто, кого ви запросите електронною поштою або за публічним посиланням. Перша збірка для зовнішніх тестувальників проходить Beta App Review.
• Бета-збірки діють обмежений час, тож під час довгої бети регулярно завантажуйте нові.

Треки тестування в Google Play

• Внутрішнє тестування швидко доставляє збірки невеликій довіреній групі.
• Закрите тестування охоплює тестувальників, яких ви запрошуєте через список адрес чи групу, — звичний вибір для повноцінної бети.
• Відкрите тестування дає змогу будь-кому, хто знайде сторінку застосунку, приєднатися до публічної бети.

Нові особисті акаунти розробників у Google Play мають провести закрите тестування з мінімальною кількістю тестувальників протягом мінімального строку, перш ніж публікувати застосунок у продакшн. Перевірте актуальну вимогу в Play Console, перш ніж призначати дату запуску, бо це може додати кілька тижнів.

Проводьте бету з чіткою метою

1. Дайте тестувальникам два-три конкретні завдання, наприклад зареєструватися й створити перший запис.
2. Додайте звіти про збої та базову аналітику ще до старту бети.
3. Через кілька днів поставте одне відкрите запитання: що було незрозумілим чи дратувало?
4. Спершу виправте збої, потім — найбільші незрозумілі місця в онбордингу.
5. Регулярно випускайте нові бета-збірки, щоб тестувальники бачили, що їхні відгуки важливі.

Модерація в App Store і Google Play: чого очікувати

Обидва магазини перевіряють застосунки перед публікацією й оприлюднюють свої правила. Перед поданням хоча б раз прочитайте App Review Guidelines від Apple і Developer Program Policies від Google Play. Це вбереже від більшості відмов.

Тривалість перевірки залежить від застосунку, пори року й віку вашого акаунта розробника. Закладіть запас у кілька днів до будь-якої публічної дати запуску.

Типові причини відмов в App Store

• Збої та баги. Під час перевірки застосунок падає або якийсь сценарій не працює.
• Неповна інформація. Застосунок вимагає входу, але демо-акаунт не надано.
• Контент-заглушки. Lorem ipsum, тестові дані, биті посилання чи порожні екрани.
• Неточні метадані. Скриншоти чи описи, які не відповідають тому, що робить застосунок.
• Проблеми з конфіденційністю. Немає політики конфіденційності, відомості про конфіденційність не збігаються з тим, які дані збирає застосунок, або запити дозволів не пояснюють, навіщо потрібен доступ.
• Видалення акаунта. Якщо в застосунку можна створити акаунт, у ньому ж має бути змога розпочати його видалення.
• Платежі. Цифровий контент, що відкривається всередині застосунку, зазвичай має продаватися через вбудовані покупки (in-app purchase) — з деякими винятками й регіональними відмінностями.
• Мінімальна функціональність. Застосунок, який по суті є сайтом в обгортці або пропонує надто мало, щоб бути корисним, можуть відхилити.

Типові проблеми в Google Play

• Форма Data safety. Вона має точно описувати, які дані збирають і передають застосунок та його SDK.
• Чутливі дозволи. Доступ до фонової геолокації, SMS чи журналу викликів потребує задекларованого й обґрунтованого використання.
• Цільовий рівень API. Нові застосунки й оновлення мають орієнтуватися на нещодавній рівень Android API.
• Правила оформлення сторінки. Оманливі іконки, перенасичення ключовими словами чи твердження, які ви не можете підтвердити.
• Видалення акаунта й платежі. Застосунки з акаунтами мають давати змогу надіслати запит на видалення, а цифрові товари, які продаються в застосунку, підпадають під правила оплати Google Play.

Якщо застосунок відхилили, виправте саме те, що зазначено в повідомленні, і ввічливо дайте відповідь. Більшість відмов для невеликих застосунків вдається владнати з наступним поданням.

Поради з App Store Optimization для невеликого запуску

App Store Optimization, або ASO, — це робота над тим, щоб вашу сторінку було легко знайти в пошуку магазину і щоб вона переконувала тих, хто на неї потрапив.

Назва та підзаголовок або короткий опис

Назва застосунку — один із найсильніших пошукових сигналів, які ви контролюєте. Поєднайте бренд із короткою фразою про те, що робить застосунок, наприклад «Трекер звичок» чи «Планувальник бюджету». Підзаголовок в App Store і короткий опис у Google Play дають ще один короткий рядок. Ліміти символів жорсткі, тож кожне слово має бути ймовірним пошуковим запитом або реальною перевагою.

Ключові слова

• В App Store є приховане поле ключових слів. Розділяйте слова комами, не повторюйте слова з назви й не додавайте назв брендів конкурентів.
• У Google Play поля ключових слів немає. Магазин зчитує назву й описи, тож пишіть повний опис природно, довкола фраз, які шукають ваші користувачі.
• Локалізація сторінки іншими мовами допоможе з’являтися в більшій кількості пошукових запитів.

Скриншоти та прев’ю-відео

Багато людей ухвалюють рішення за першими скриншотами в результатах пошуку, навіть не відкриваючи сторінку. Сприймайте їх як коротку презентацію:

1. Починайте з головної переваги, а не з екрана входу.
2. Додайте до кожного скриншота короткий підпис про те, що отримує користувач.
3. Показуйте справжні екрани, а не макети функцій, яких немає.
4. Тримайтеся єдиного стилю, щоб набір сприймався як одна історія.

Коротке прев’ю-відео, яке показує головну дію в перші секунди, допомагає застосункам, цінність яких легше побачити, ніж описати.

Іконка, оцінки й відгуки

Іконка має бути простою, читатися в малому розмірі й відрізнятися від конкурентів. Оцінки впливають і на позиції в пошуку, і на конверсію. Використовуйте офіційні запити на відгук усередині застосунку на iOS та Android у момент успіху — наприклад, після виконання завдання, — і ніколи під час першого запуску. Обидві платформи обмежують, як часто показується такий запит. Ніколи не винагороджуйте людей за відгуки, а на критичні відповідайте виправленням або чіткою відповіддю.

План на тиждень запуску

Запуск — це короткий спланований ривок, а не один допис:

1. За два тижні. Надішліть фінальну збірку й оберіть ручний реліз в App Store або керовану публікацію в Google Play, щоб застосунок був схвалений, але ще не опублікований. Підготуйте скриншоти, коротке демо-відео, сторінку з прес-китом і чернетки всіх дописів про запуск.
2. За кілька днів. Надішліть списку очікування лист із датою. Попросіть кількох бета-тестувальників спробувати застосунок у перший день і поділитися чесними враженнями.
3. День запуску. Випустіть застосунок, перевірте, що він встановлюється в потрібних вам країнах, і надішліть списку очікування лист із прямими посиланнями на магазини. Опублікуйте анонси й відповідайте на кожен коментар.
4. Дні з другого по четвертий. Поділіться застосунком у решті спільнот зі свого списку — по одній-дві на день, адаптуючи текст під кожну аудиторію. Швидко виправляйте баги, що з’явилися після запуску.
5. Кінець тижня. Випустіть невелике оновлення з виправленнями за першими відгуками й подякуйте людям, які допомогли.

Для наступних оновлень поетапний реліз (phased release) в Apple і поступове розгортання (staged rollout) у Google Play дають змогу зробити паузу, якщо з’являться проблеми.

Де анонсувати запуск застосунку

Обирайте місця, де вже є ваші користувачі, замість публікувати всюди.

• Ваш список очікування й бета-тестувальники. Ваша найтепліша аудиторія. Попросіть їх оцінити застосунок, якщо він їм сподобався.
• Нішеві спільноти. Сабреддити, форуми, групи в Discord і Slack, присвячені проблемі, яку розв’язує ваш застосунок. Спершу прочитайте правила й розкажіть, чому ви його створили, а не кидайте голе посилання.
• Спільноти інді-розробників. Product Hunt, Indie Hackers і допис Show HN на Hacker News пасують застосункам з історією створення чи технічною родзинкою.
• Розсилки й автори у вашій ніші. Коротка особиста пропозиція з посиланням на демо працює краще за прес-реліз.
• Каталоги проєктів. Вони дають застосунку постійне місце, де його знайдуть і через довгий час після тижня запуску. Один із варіантів — One Dollar Planet: можна додати застосунок на планету як точку за $1, яка залишається назавжди, або з логотипом і власною сторінкою за $10, а відвідувачі можуть ставити йому зірки в рейтингу проєктів. Подробиці — на сторінці «Як усе влаштовано».

Вимірювання утримання після запуску

Завантаження показують, що запуск дійшов до людей. Утримання показує, що застосунок варто залишити на телефоні.

• Визначте активацію. Виберіть дію, яка свідчить про отриману користь, наприклад створення першого запису, і відстежуйте, скільки нових користувачів до неї доходять.
• Стежте за когортним утриманням. Дивіться, яка частка нових користувачів кожного тижня повертається на 1-й, 7-й і 30-й день. Крива, що вирівнюється, означає, що ядро аудиторії продовжує повертатися.
• Відстежуйте конверсію в магазині. App Store Connect і Google Play Console показують покази, перегляди сторінки та встановлення, тож ви зможете зрозуміти, що є вузьким місцем — сторінка чи сам застосунок.
• Стежте за стабільністю. Частота збоїв і зависань («застосунок не відповідає») впливає на оцінки, а в Google Play низька технічна якість може зменшити видимість.

Збирайте лише ті дані, які вам потрібні, і з кожним новим SDK оновлюйте відомості про конфіденційність в App Store та форму Data safety у Google Play.

Ітерації після запуску

Справжній продукт формується саме в перші тижні після запуску.

1. Спершу виправте збої та блокери. Ніщо інше не має значення, якщо застосунок не працює.
2. Покращте онбординг. Багато користувачів, які йдуть, роблять це вже в першій сесії, тож скоротіть шлях до активації.
3. Говоріть з активними користувачами. Питайте, що їх утримало і що мало не змусило піти.
4. Випускайте невеликі регулярні оновлення зі зрозумілим описом змін.
5. Перегляньте сторінку в магазині, використовуючи слова самих користувачів, і тестуйте варіанти за допомогою оптимізації сторінки продукту (product page optimization) в Apple або експериментів зі сторінкою (store listing experiments) у Google Play.
6. Вирішіть, що далі. Якщо утримання добре, інвестуйте в зростання. Якщо слабке — змініть продукт, перш ніж посилювати просування.

Більше посібників про запуск і маркетинг невеликих проєктів — у блозі.

Головні висновки

• Перевіряйте ідею реальними розмовами й списком очікування ще до завершення розробки.
• Проведіть структуровану бету в TestFlight і Google Play та заздалегідь перевірте вимоги Google Play до тестування для нових акаунтів.
• Прочитайте правила магазинів перед поданням. Збої, відсутні демо-акаунти, прогалини в конфіденційності та неточні метадані — причини багатьох відмов.
• Вважайте назву, перші скриншоти й ранні оцінки основою App Store Optimization.
• Плануйте тиждень запуску як серію дописів там, де вже є ваші користувачі.
• Оцінюйте успіх за утриманням, а не за завантаженнями, і насамперед покращуйте онбординг.

Часті запитання

Скільки коштує запуск мобільного застосунку?

Фіксовані витрати — це акаунти розробника: Apple бере щорічний членський внесок, а Google Play — одноразовий реєстраційний, тож перевірте актуальні ціни на їхніх офіційних сайтах. Крім цього, невеликий запуск тримається здебільшого на вашому часі й недорогих інструментах.

Скільки триває перевірка застосунку?

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

Чи варто запускатися на iOS та Android одночасно?

Не обов’язково. Запуск спершу на одній платформі дає змогу виправити проблеми на меншій групі, перш ніж подвоювати роботу. Почніть із платформи, якій надає перевагу ваша цільова аудиторія; навіть із кросплатформним фреймворком релізи можна рознести в часі.

Що таке App Store Optimization і чи працює вона для нових застосунків?

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

Як просувати мобільний застосунок без маркетингового бюджету?

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