Як монетизувати застосунок у 2026 році: підписки, разові покупки, реклама чи платні завантаження

Щоб добре монетизувати застосунок, почніть з одного питання: яку цінність отримує людина і як часто? Хмарний сервіс, офлайн-інструмент і казуальна гра мають різні витрати та сценарії використання, тож однаковий пейвол їм не підходить. Спершу оберіть модель. Потім перевірте платіжні правила магазинів і комісії на 2026 рік, бо саме вони разом визначають, як ви можете брати оплату і скільки залишите собі.

Яку модель монетизації застосунку обрати?

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

Гібрид може спрацювати, але кожна додаткова модель — це ще одне правило, яке треба пояснити, і більше станів покупки для тестування. Почніть з найпростішої моделі, яку можете чітко пояснити. «Спробуйте безкоштовно, заплатіть один раз за експорт» зрозуміліше, ніж кредити, підписки й реклама водночас.

Коли підписка має сенс і чого вимагає Apple?

Підписка має сенс, коли застосунок постійно приносить цінність. Guideline 3.1.2(a) від Apple говорить, що автоматично поновлювані підписки «мають забезпечувати клієнтові постійну цінність», а період «має тривати щонайменше сім днів і бути доступним на всіх пристроях користувача».

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

До покупки Guideline 3.1.2(c) вимагає «чітко описати, що користувач отримає за цю ціну». Сторінка про підписки від Apple перелічує, що має бути на екрані оформлення: назва й тривалість підписки, що до неї входить, помітна повна ціна поновлення, спосіб увійти або відновити покупки, а також посилання на Умови використання і Політику конфіденційності. Протестуйте поновлення, скасування, завершення терміну і відновлення. Людина, яка скасувала підписку сьогодні, має зберегти доступ до кінця оплаченого періоду.

Коли краще підходить разова покупка або платне завантаження?

Разова покупка підходить для самодостатнього інструмента, витрати на який не зростають із використанням, як-от офлайн-редактор чи утиліта, що працює на пристрої. Вона погано підходить, коли ви обіцяєте дорогу обробку ШІ, сховище або ручну підтримку безстроково в обмін на один платіж.

На iOS ви все одно можете запропонувати пробний період без підписки. Guideline 3.1.1 дозволяє невитратну вбудовану покупку за Price Tier 0 з назвою "XX-day Trial". Перед початком пробного періоду ви маєте вказати, скільки він триває, що буде заблоковано і скільки коштує повний доступ. Якщо ви продаєте тарифіковані сервіси як витратні кредити поряд із разовим розблокуванням, пам'ятайте, що кредити, куплені через вбудовані покупки, «не можуть мати терміну дії». Не рекламуйте «безліміт», ховаючи жорстке обмеження на сторінці підтримки.

Чи є реклама хорошим способом монетизувати невеликий застосунок?

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

Вимірюйте, чи не заважають рекламні місця основному завданню. У швидкій утиліті повноекранна реклама перед результатом може коштувати більше через втрачених користувачів, ніж заробляє. Версія без реклами — це цифрова покупка: Політика платежів від Google прямо називає «версію застосунку без реклами» преміум-функціональністю, що проходить через Play billing. Рекламні SDK також збирають дані, тож оновіть свої розкриття інформації. Наш аудит SDK для міток приватності покроково описує цю перевірку.

Скільки Apple і Google забирають із доходу застосунку у 2026 році?

Станом на жовтень 2026 року Apple утримує 15% з учасників Small Business Program і з підписок після року платного обслуговування. У США, Великій Британії та ЄЕЗ Google Play стягує 10% сервісного збору плюс 5% платіжного збору з підписок, оплачених через Play billing.

Нова структура Google почала діяти 30 червня 2026 року в США, ЄЕЗ і Великій Британії, а 30 вересня 2026 року — в Австралії та Японії, згідно з її сторінкою про сервісні збори. У цих регіонах 5% платіжного збору стосуються лише покупок через Google Play billing. На інших ринках зберігаються старі ставки, доки зміни не дійдуть і до них.

Small Business Program від Apple охоплює розробників із доходом до $1 million за попередній календарний рік, а також розробників, нових в App Store. Безкоштовні пробні періоди не зараховуються до року платного обслуговування, потрібного для ставки 85% на підписки в Apple. Збори залежать від програми та типу транзакції, тож будуйте прогнози на основі реальних умов вашого акаунта, а не одного відсотка.

Коли можна використовувати власне платіжне посилання замість вбудованих покупок?

На вітрині Apple для США застосунки тепер можуть містити кнопки, зовнішні посилання чи інші заклики до дії, що ведуть до інших способів покупки. В інших місцях цифрові функції мають використовувати вбудовані покупки, якщо не діє регіональний дозвіл або один із перелічених винятків.

• Apple, поза США: Guideline 3.1.1(a) вимагає StoreKit External Purchase Link Entitlement, доступного лише на певних вітринах і певних платформах.
• Apple, фізичні товари: Guideline 3.1.3(e) говорить, що для фізичних товарів або послуг, якими користуються поза застосунком, слід використовувати способи оплати, відмінні від вбудованих покупок.
• Apple, індивідуальні живі послуги: згідно з 3.1.3(d), послуги в реальному часі між двома людьми, як-от репетиторство, можуть використовувати інші способи оплати. Послуги для невеликих груп і для широкої аудиторії мають використовувати вбудовані покупки.
• Google Play: цифрові товари використовують Play billing, якщо ви не зареєструвалися в програмі альтернативного білінгу чи зовнішніх пропозицій для відповідної країни. Фізичні товари та фізичні послуги не повинні використовувати Play billing.

Через які помилки монетизації відхиляли інші застосунки?

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

У гілці Apple Developer Forums 2019 року розробник гри-квесту просто неба продавав ігрові коди на своєму сайті й через партнерів. Потім користувачі вводили ці коди в застосунку. Оновлення відхилили за "Guideline 3.1.1 - Business - Payments - In-App Purchase", оскільки застосунок «дозволяє користувачам розблоковувати додатковий контент, купуючи код». Розробник послався на 3.1.3(b). У відповідях зазначили, що мультиплатформний доступ однаково вимагає, щоб ті самі товари були «доступні як вбудовані покупки в застосунку».

У гілці від січня 2025 року розробник використовував власні партнерські промокоди, щоб показувати дешевший із двох чинних продуктів вбудованої покупки. Apple відхилила застосунок, бо «застосунок використовує промокод для розблокування або ввімкнення платних функцій». Апеляцію відхилили з порадою: «Якщо ви хочете надавати підписки зі знижкою в застосунку, використовуйте код пропозиції, який підтримує Apple».

Обидва випадки дають однаковий урок. Для Apple неважливо, чи ваш код розблоковує контент напряму, чи лише змінює ціну. Якщо щось поза StoreKit вирішує, хто отримує платні функції, чекайте відхилення за 3.1.1.

Як зрозуміти, чи працює ваша монетизація?

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

Приклад: «Після того як користувачі завершать перший успішний експорт, показати платну опцію експорту з одним зрозумілим поясненням». Визначте метрику (конверсія в покупку та повернення коштів за 30 днів) і часове вікно до того, як щось змінювати. Крихітна вибірка не виправдовує впевнених висновків щодо ціноутворення. Перед випуском платної версії пройдіть цей чекліст:

1. Переконайтеся, що новий користувач дістається корисної частини застосунку, перш ніж побачить пейвол.
2. Покажіть ціну, період оплати і що входить у покупку, простою мовою.
3. Протестуйте успішні, очікувані, невдалі, повернені та відновлені покупки в релізній збірці.
4. Перевірте, що права доступу зберігаються після перевстановлення і переносяться між пристроями користувача.
5. Надайте App Review робочий шлях до кожної платної функції, з демо-акаунтом, якщо потрібен вхід.
6. Відстежуйте поновлення та відтік за когортами для підписок.

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