Вся правда і вигадки про push-розсилки

Звичайні користувачі сприймають «пуші» як маленькі набридливі нагадування, що вони забули подивитися, хто поставив їм лайки в Instagram. Про користь «пушів» для бізнесу думають лише ті, хто стикався з ними на професійному ґрунті. Якщо ви тут – час перейти з категорії скролерів у категорію серйозних обізнаних бізнесменів.

Ласкаво просимо у реальний світ, де push-повідомлення – це інструмент для бізнесу. Розберемося, як він влаштований насправді у 2026 році – з урахуванням того, що за останні пару років правила гри на Android і в браузерах помітно змінилися.

Push залишається одним з небагатьох каналів, який «дістає» користувача незалежно від того, чи відкритий у нього застосунок або пошта. Повідомлення з'являється поверх інших вікон, затримується на екрані на певний час – цього достатньо, щоб користувач його помітив, а якщо пропустить, завжди може знайти в Центрі сповіщень на Windows, macOS, Android чи iOS.

Ключова відмінність push від email чи SMS – добровільність. Нікого не примушують: користувач або сам дозволяє сповіщення, або ні. Але тут і криється головна зміна останніх років: отримати цей дозвіл стало складніше, ніж «просто натиснути кнопку», і про це далі.

Механіка доставки відрізняється залежно від того, де користувач отримує push – у браузері, у застосунку на Android чи в застосунку на iOS. Розберемо кожен варіант.

Web Push (браузер)

Працює в Chrome, Firefox, Edge та інших основних браузерах на десктопі й Android. З 2023 року Web Push доступний і на iPhone/iPad – але лише для веб-застосунків, доданих на екран «Домівка», а не для звичайного перегляду сайту в Safari. Це важливо враховувати: сказати «покажемо push усім користувачам з iOS» вже не можна без застереження про встановлення веб-застосунку.

Android

Сповіщення доставляються через Firebase Cloud Messaging (FCM): сервер надсилає payload у FCM, той доставляє його на пристрій через Google Play Services. Починаючи з Android 13, застосунок зобов'язаний явно запросити runtime-дозвіл POST_NOTIFICATIONS – без нього push не дійде взагалі, навіть якщо сервер надіслав повідомлення.

iOS

Застосунки на iOS перебувають у фоновому режимі недовго, тому доставка йде через окремий сервіс – Apple Push Notification service (APNs). Сервер надсилає подію в APNs, а той – на пристрій. Дозвіл на iOS запитувався завжди, у цьому сенсі для Apple нічого не змінилося – але з 2023 року вимога до явного opt-in підтягнулася й на Android.

Раніше єдина складність була на iOS – на Android push працювали «з коробки». З Android 13 це в минулому: без явного дозволу користувача застосунок узагалі нічого не зможе надіслати, а системний запит показується лише один раз.

1. Не показуйте системний запит одразу під час першого запуску – за статистикою, більшість користувачів на автоматі натискає «Не дозволяти», якщо їх нічого не підготувало.
2. Спочатку покажіть свій екран-пояснення (soft-ask): навіщо потрібні сповіщення і що конкретно користувач отримає – знижки, статус замовлення, новини.
3. Запитуйте системний дозвіл лише після кліку користувача на цьому екрані або після того, як він вчинив осмислену дію в застосунку.
4. На Android 14+ користувачі також можуть гнучко керувати важливістю і типами каналів сповіщень (наприклад, залишити транзакційні, але вимкнути промо) – варто заздалегідь продумати таксономію каналів, а не звалювати все в один потік.

Лайфхак: якщо користувач один раз відхилив системний запит, повторно викликати його programmatically не можна – єдиний шлях – направити в Налаштування. Тому додайте в застосунок окремий екран з кнопкою «Як увімкнути сповіщення» і зрозумілою інструкцією, а не покладайтеся лише на системний діалог.

Структура хорошого push концептуально не змінилася, але ліміти по символах варто тримати в голові окремо для кожного каналу – вони різні.

• заголовок – для web push оптимально до 30 символів, для мобільного push можна до 65, але чим коротше, тим менший ризик обрізки на різних екранах;
• основний текст – для web push 30-60 символів, для мобільного технічний ліміт вищий (iOS – близько 178 символів, Android – близько 663), але для сприйняття краще вкладатися у 120-150 символів;
• посилання на конкретну сторінку, а не просто на головну – чим точніша посадкова, тим вища конверсія;
• зображення – rich-сповіщення підтримують не всі браузери й не всі версії ОС, тому текст має бути зрозумілим і без картинки.

Лайфхак: тестуйте не лише текст, а й час відправлення, емодзі в заголовку та CTA – іноді заміна одного слова в заголовку помітно змінює CTR. Заведіть мінімум 2 варіанти на кожну велику розсилку і порівнюйте відкриваність.

Попри зрослу складність з дозволами, економіка каналу не змінилася – push залишається одним з найдешевших способів повернути користувача.

1. Добровільна підписка. Користувачі самі погоджуються на отримання сповіщень – а отже, лояльніше ставляться до пропозицій, ніж до холодної реклами.
2. Жива аудиторія. Частка випадкових підписників мінімальна – люди свідомо дозволили канал.
3. Реклама не повз ціль. Push прилітає прямо на екран, його складніше проігнорувати, ніж банер.
4. Швидкий зворотний зв'язок. Уже за кілька днів розсилок можна набрати достатньо статистики, щоб зрозуміти, які повідомлення працюють, а які ні.

Окрема тема – web push саме для інтернет-магазинів: там своя специфіка щодо довжини тексту і сценаріїв. Розбирали детально в статті «Web push-повідомлення для eCommerce: дратують чи продають».

Push-розсилки – не «поганий вид реклами», як іноді кажуть. Це добровільний, недорогий канал, який не примушує користувача до жодних дій – якщо, звісно, ним не зловживати. Головне, що змінилося за останні роки: отримати дозвіл стало складніше і на Android, а не лише на iOS, і це варто закладати в стратегію з самого початку розробки, а не патчити постфактум.

Якщо потрібно вбудувати push-сповіщення в мобільний застосунок з нуля – команда Brander робить розробку мобільних застосунків під ключ, включно з інтеграцією FCM і APNs.