Full screen

Reinstalls: як повертати користувачів, які вже видалили додаток

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

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

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

Чому користувачі видаляють додатки: причини та тригери відтоку

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

Серед базових причин усе, як і раніше, доволі передбачувано:

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

Але сьогодні цих факторів уже недостатньо, щоб пояснити весь відтік. Індустрія змінилася — і разом із нею з’явилися нові тригери видалення:

  • Privacy-фактор. Користувачі стали уважніше ставитися до того, які дані збирають додатки. Якщо ліхтарик просить доступ до контактів, а калькулятор — до геолокації, це викликає підозру. Додатки, які запитують надмірні дозволи або мають репутацію збирачів даних, видаляють частіше.
  • Підпискова модель. Багато хто пробує додаток у trial-період, а після його завершення просто видаляє, не розібравшись у цінності. Відсутність зрозумілого нагадування про те, що саме вони втратять, лише погіршує ситуацію.
  • AI-заміна функцій. Зростання AI-асистентів змінює ландшафт: прості утиліти — перекладачі, нотатки, сканери — дедалі частіше замінюються вбудованими AI-функціями або універсальними помічниками. Через це додатки з простим функціоналом опиняються під особливим тиском: користувачеві дедалі складніше пояснити, навіщо тримати окремий продукт.
  • Надмірні пуші. Агресивний ретеншн обертається проти продукту. Коли сповіщень занадто багато і вони нерелевантні, користувачі не просто вимикають їх — у половині випадків вони видаляють додаток.

Статистика uninstall і retention за категоріями

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

КатегоріяDay 30 RetentionОсобливості
News11.3%Сплески на подіях, але швидке падіння
Finance4.6%Висока довіра, щоденні потреби 
Shopping5%Залежить від циклів покупок і сезонності
Food & Drink3.7%Доставка утримує краще, рецепти — гірше
Health & Fitness3.7%Пік у січні, спад до березня
Travel3%Сезонне використання, довгі перерви
Gaming2.4%Високий D1, різкий спад, якщо немає прогресії
Utilities2.6%Використовуються «по справі», не щодня

Коли і чому користувачі повертаються: типологія повернення

Видалення додатка не означає остаточну втрату користувача. Люди повертаються, і в цьому поверненні є свої закономірності. Ми виділяємо три основні типи reinstalls, і кожен із них диктує свою логіку reactivation-кампаній.

Функціональне повернення

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

Приклади: туристичні сервіси, маркетплейси, агрегатори таксі, доставка їжі.

Як впливати: таким користувачам важливо нагадувати про себе в потрібний момент. Seasonal ASO, контекстна реклама за брендовими запитами та push-сповіщення з релевантними пропозиціями на кшталт «Незабаром літо — шукай вигідні квитки» працюють тут найкраще.

Емоційне повернення

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

Приклади: мобільні ігри, стримінгові сервіси, додатки для знайомств.

Як впливати: ключову роль тут відіграють емоційні тригери — нові сезони, івенти, оновлення контенту. Важливо підтримувати зв’язок через email або push — ненав’язливо — і показувати, що в додатку з’явилося щось свіже. ASO-елементи — іконка, скриншоти — теж мають транслювати настрій.

Тригерне повернення

Користувач не планував повертатися, але спрацював зовнішній стимул: побачив рекламу, отримав листа зі знижкою, прочитав новину про велике оновлення. Це найкерованіший тип повернення.

Приклади: будь-які додатки, у яких є маркетингові кампанії.

Як впливати: тут працюють усі канали — платні (ASA, UAC), власні (push, email), а також інфоприводи: нові функції, партнерства, оновлення. Важливо сегментувати аудиторію, що пішла, і підбирати для кожного сегмента релевантний офер.

Розуміння типу повернення дає змогу діяти не навмання, а обирати правильні інструменти:

Тип поверненняОсновний каналЩо показувати
ФункціональнеПошук, бренд-кампанії“Знову у справі” + актуальна пропозиція
ЕмоційнеІвенти, контент, соцмережі“Новий сезон”, “Ти скучив?”, оновлення
ТригернеPush, email, платна рекламаЗнижка, нова функція, лімітований івент

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

Як коректно відстежувати перевстановлення в епоху приватності

Перш ніж будувати стратегії повернення, потрібно домовитися про терміни й зрозуміти, з якими даними ми взагалі можемо працювати у 2026 році. Із приходом SKAN, обмежень на user-level дані та відмінностей у логіці платформ відстеження reinstalls перетворилося на окреме завдання — уже не лише маркетингове, а й технічне.

Часто плутають три поняття, хоча вони означають різне:

  • Reinstall — повторне встановлення додатка користувачем, який раніше його видалив. Саме по собі це не завжди переприсвоюється новому джерелу: залежно від налаштувань атрибуції та наявності retargeting-кампаній reinstall може залишитися за попереднім джерелом або вважатися organic.
  • Re-attribution — reinstall, який стався після взаємодії з рекламною кампанією й був переприсвоєний новому медіаджерелу в межах вікна переатрибуції. По суті, це платне повернення користувача.
  • Re-engagement — повернення користувача в уже встановлений додаток через диплінк, push або рекламу. Це не reinstall, а повторне залучення.

Вплив SKAdNetwork і обмежень платформ

Головна проблема 2026 року в тому, що SKAdNetwork спочатку створювався для вимірювання встановлень, а не реінсталів і ретаргетингу. Звідси кілька обмежень:

  • Re-engagement-кампанії не підтримуються в стандартній моделі SKAN.
  • Дані надходять із затримкою та в агрегованому вигляді. Замість user-level атрибуції ми отримуємо знеособлені сигнали через 24–48 годин, а іноді й пізніше.
  • Немає креативного рівня. Ми бачимо, що кампанія спрацювала, але не розуміємо, який саме креатив повернув користувача.
  • Потрібен мінімальний обсяг даних. Щоб SKAN повернув conversion value, кампанії потрібен достатній обсяг встановлень — для невеликих тестів це створює сліпу зону.

Чому цифри на різних платформах відрізняються?

Якщо порівняти звіти App Store Connect, Google Play Console і MMP та помітити розбіжності — це нормально. У цих платформ принципово різна логіка підрахунку.

ПлатформаЯк рахує reinstallЧи враховує re-attributionДоступ до user-level данихЗатримка
App Store ConnectРахує як нове встановлення, якщо користувач раніше видалив додатокНі, не прив’язує до джерелаНі, лише агреговані даніНі (у дашборді)
Google Play ConsoleРахує унікальні встановлення, тобто одного користувача двічі, якщо він видалив і перевстановив додаток НіНі, лише агрегованіНі

App Store і Google Play дають нам загальну картину «скільки разів додаток було встановлено», але не скажуть, хто з цих користувачів повернувся платно, а хто — самостійно. MMP допомагають побачити re-attribution, але вимагають правильного налаштування й працюють в умовах обмежених даних.

Сучасні стратегії збільшення reinstalls

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

ASO-інструменти повернення

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

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

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

Тестування custom product pages.
В App Store і Google Play можна створювати окремі версії сторінки для різних аудиторій. Це ідеальний інструмент для reactivation: ми можемо зробити сторінку, яка звертається безпосередньо до користувачів, що пішли, з повідомленням «Ми виправили те, що вам заважало» або «У нас з’явилося те, чого ви чекали». Такі сторінки можна таргетувати через платні кампанії на returning users.

Просування In-app events в App Store.
Події всередині додатка (турніри, нові сезони, челенджі) тепер відображаються в пошуку та на сторінці додатка. Це прямий канал комунікації з колишніми користувачами: вони бачать, що в додатку просто зараз відбувається щось цікаве, і в них з’являється причина повернутися.

Робота з розділом «Що нового» (changelog)

Розділ “Що нового” бачать усі користувачі під час оновлення, але він також впливає на reinstalls. Коли людина заходить на сторінку додатка після тривалої перерви, changelog — це перше, що вона читає, щоб зрозуміти, чи змінилося щось із моменту її відходу.
Формула ефективного повідомлення: проблема — рішення — вигода.

Не сухе «виправили помилки», а зрозуміле пояснення, що саме змінилося для користувача:  покращили стабільність роботи чату — повідомлення тепер завантажуються швидше. Або: Оптимізували запуск додатка — тепер він відкривається помітно швидше навіть на слабких пристроях.

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

Платні стратегії

Платний трафік — один із найбільш керованих способів повернути користувачів. Головне — правильно налаштувати кампанії та сегменти.

Apple Search Ads: кампанії на returning users

В ASA можна окремо таргетуватися на користувачів, які вже встановлювали додаток. Це окремий тип кампаній зі своєю логікою ставок. Такі кампанії часто дають вищий ROI, тому що користувачі, які повертаються, краще конвертуються в цільові дії й уже знайомі з продуктом.

Що важливо:

  • Окремі ставки. Користувачі, які повертаються, конвертуються інакше, ніж нові. Для них варто виставляти окремі ставки — нерідко вищі, якщо їхній LTV вищий.
  • Brand defense. Кампанії на повернення за брендовими запитами допомагають захищати аудиторію від конкурентів, які можуть перехоплювати ваш трафік.
  • Custom Product Pages для reactivation. Користувачам, які повертаються, можна показувати окремі версії сторінки з повідомленням на кшталт «З поверненням! У нас багато нового». Це підвищує релевантність і конверсію.

Google App Campaigns: UAC для re-engagement.

У Google є окремий тип кампаній — App campaigns for engagement (ACe). Вони дають змогу повертати користувачів, які вже встановили додаток, і спонукати їх до конкретних дій усередині нього.

Умови та налаштування:

  • Потрібно щонайменше 50 000 встановлень, щоб запустити такий тип кампаній.
  • Обов’язкова наявність deep linking — посилань, які ведуть не просто в додаток, а на потрібний екран.
  • Можна створювати аудиторії у Firebase (наприклад, «не заходили 30 днів», «покинули кошик») і таргетуватися на них.
  • Google автоматично підбирає креативи та майданчики (YouTube, пошук, Play, Display Network) під завдання повернення.

Різні маркетингові цілі для engagement-кампаній:

  • Re-engage lapsed users (не заходили 7+ днів)
  • Re-engage lapsed purchasers (купували раніше, але давно)
  • Re-engage non-purchasers (встановили додаток, але не купували)
  • Re-engage unnotified users (вимкнули пуші)

CRM-маркетинг

Push-сповіщення за тригером неактивності. Якщо користувач не заходить у додаток 7–14 днів, можна надіслати push із нагадуванням про цінність. Головне — не спамити, а пропонувати щось конкретне: нову функцію, персональну знижку або важливу подію.

Email-кампанії та win-back-сценарії. Для багатьох категорій email залишається одним із ключових каналів повернення. Ефективна win-back-кампанія вирішує три завдання: пробиває рекламну сліпоту, нагадує, навіщо користувач узагалі встановлював додаток, і показує, що він втрачає, залишаючись осторонь.

In-app messages для утримання. Поки користувач ще не видалив додаток, але вже знизив активність, йому можна показувати in-app-повідомлення з пропозиціями, знижками або питаннями про причини охолодження.

Робота з рейтингом і відгуками

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

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

Практика відповідей на негатив. На негативні відгуки важливо відповідати швидко й конструктивно:

  • подякувати за зворотний зв’язок;
  • визнати проблему, якщо вона реальна;
  • пояснити, що вже зроблено або буде зроблено;
  • за потреби запропонувати канал зв’язку.

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

Контентні тригери

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

Нові сезони. Ігри на кшталт Fortnite або Among Us будують повернення навколо сезонних оновлень. Новий сезон — новий контент, нові механіки, новий привід зайти. Це потужний емоційний тригер для тих, хто грав раніше.

Івенти. Святкові події (Геловін, Новий рік, День святого Валентина) — чудовий привід нагадати про себе. Тематичні квести, особливі предмети, обмежені в часі активності, створюють ажіотаж і повертають навіть давніх користувачів.

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

Інфоприводи в медіа. Для новинних додатків, спортивних трансляцій і сервісів із прогнозами reinstalls часто відбуваються «самі собою» у моменти великих подій (вибори, чемпіонати, природні катаклізми). Завдання — бути готовими до таких піків і не пропустити їх в аналітиці.

Ключовий принцип усіх контентних тригерів: вони мають бути помітними на вітрині (іконка, скриншоти, in-app events) і в комунікаціях (push, email), щоб користувач точно знав: у додатку відбувається щось нове й цікаве.

Метрики, на які варто дивитися

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

  • Reinstall rate — частка повторних встановлень у загальному трафіку.

Показує, скільки користувачів повернулися після видалення. Розраховується як співвідношення reinstalls до загальної кількості встановлень за період. Нормальне значення сильно залежить від категорії: для сезонних сервісів на кшталт travel або delivery воно зазвичай вище, для утиліт — нижче.

Де дивитися: App Store Connect  — метрика Redownloads, Google Play Console — розділ Statistics, фільтр Returning users. У Google Play важливо розрізняти Returning users (користувачі, які видаляли й перевстановили додаток) і просто активних користувачів, які повернулися в додаток.

  • Re-attribution rate — частка reinstalls, які сталися після рекламного контакту й були переприсвоєні новому джерелу.

Метрика допомагає оцінити ефективність платних reactivation-кампаній — наприклад, ASA на returning users або UAC для re-engagement.

Де дивитися: MMP у звітах із ретаргетингу. Важливо враховувати, що SKAdNetwork не підтримує re-engagement напряму, і дані можуть надходити із затримкою.

  • Cost per reactivation — вартість повернення одного користувача.

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

Де дивитися: розраховується вручну на основі даних MMP про re-attribution і бюджетів рекламних кампаній.

  • Time to reinstall — час, який минає між видаленням і повторним встановленням.

Розуміння цього інтервалу допомагає правильно налаштовувати win-back-кампанії: якщо більшість повертається через 30 днів, немає сенсу надсилати push через тиждень після видалення.

Де дивитися: MMP з налаштованими подіями uninstall і reinstall або когортний аналіз у Google Play Console.

  • LTV returned users vs new users — порівняння пожиттєвої цінності користувачів, які повернулися, і нової аудиторії.

Ключова метрика для розуміння економічної ефективності reactivation. Часто LTV користувачів, які повернулися, виявляється вищим — вони вже знайомі з продуктом і повертаються більш усвідомлено.
Де дивитися: MMP з прив’язкою до subscription-подій (для підпискових моделей), Google Play Console у Subscription reports, внутрішня аналітика (де можна налаштувати розрахунок LTV за когортами).

Порівняння з бенчмарками та вплив на юніт-економіку

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

У Google Play Console є можливість порівнювати свої метрики з групами пірів (peer groups) — це допомагає тверезіше оцінити ситуацію. Головне питання, на яке мають відповідати всі метрики reinstalls: як повернення користувачів впливає на загальну юніт-економіку? Якщо cost per reactivation нижчий за CPI, а LTV користувачів, які повернулися, вищий або дорівнює LTV нових, reactivation стає одним із найефективніших каналів зростання.

Практичний чекліст: як впровадити систему повернення користувачів

Щоб робота з reinstalls перестала бути хаотичною й перетворилася на передбачуваний канал зростання, ми використовуємо простий покроковий алгоритм:

Аналіз поточного uninstall rate і причин відтоку. Спочатку дивимося на масштаб: скільки користувачів іде і на якому етапі. D1, D7 і D30 retention допомагають зрозуміти, де втрати критичні. Потім збираємо причини: негативні відгуки, збої, невдалі оновлення, повторювані сценарії перед видаленням.

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

Оновлення ASO перед великим релізом або сезонною подією. Сторінка додатка має сигналізувати про зміни. Якщо виходить велике оновлення — змінюємо іконку, скриншоти, опис. Якщо наближається сезонний пік — адаптуємо вітрину під нього.

Налаштування платних кампаній на returning users. В ASA і Google UAC є окремі інструменти для повернення. Під них потрібен окремий бюджет, окремі ставки і свої креативи. Не забуваємо про диплінки: користувач має потрапляти одразу на потрібний екран.

Запуск CRM-ланцюжка win-back. Для тих, хто залишив email або не вимкнув пуші до видалення, налаштовуємо автоматичні сценарії повернення. Повідомлення мають відрізнятися за сегментами: після trial — одне, після тривалої відсутності — інше.

Моніторинг конкурентів. Дивимося, як конкуренти працюють із поверненням: які використовують креативи, які оновлення підсвічують, як оформлюють вітрину. Це допомагає помічати тренди й шукати вільні ніші.

A/B-тестування гіпотез. Усі гіпотези перевіряємо через тести. Одна гіпотеза — один експеримент. Лише так можна зрозуміти, що справді працює, а що просто виглядає переконливо на словах.

Висновок

Повернення користувачів, які видалили додаток, — це не просто спосіб підняти кількість встановлень у звітах. Це окремий канал зростання, який потребує такої ж системності, як acquisition або retention.

Головний висновок тут простий: reinstalls не працюють як разова акція. Недостатньо запустити пару кампаній і чекати результату. Потрібна зв’язка ASO, платних інструментів, CRM, контенту й аналітики — лише тоді повернення стає керованим.

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

Оптимізуйте легко разом з ASOMobile💙

FAQ

Reinstall — це повторне встановлення додатка користувачем, який уже встановлював його раніше, але видалив. В аналітиці важливо розрізняти reinstall як сам факт повторного встановлення і re-attribution — коли повернення відбулося після взаємодії з рекламною кампанією.

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

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

На практиці найкраще працює комбінація інструментів: оновлення ASO і вітрини додатка, кампанії на returning users в ASA або Google UAC, CRM-комунікації (push і email) і контентні тригери — нові функції, сезони, івенти або партнерства.

Користувачі видаляють додатки з кількох поширених причин: нестача пам’яті на пристрої, разове використання (наприклад, для поїздки або акції), технічні проблеми на кшталт збоїв і вильотів або просто втрата інтересу. Останніми роками з’явилися й нові тригери: занепокоєння щодо приватності, втома від підписок, заміна простих функцій AI-асистентами та надмірні push-сповіщення. Розуміння цих причин — перший крок до побудови ефективної стратегії повернення користувачів.

Останнє у блозі
ASO Новини. Лютий 2026 ASO Новини. Лютий 2026

Заповніть форму, щоб отримати книгу