Збій доставки критичного сповіщення: клієнт не отримав код підтвердження, замовлення зависло, а SMS полетіли в спам. Такі інциденти обходяться бізнесу в середньому в 15% втрат виручки за даними аналітики. Щоб цього уникнути, ми впроваджуємо Viber Business Messages — канал з доставкою 90–95%, Rich Media та автоматичним fallback на SMS. Наш досвід: понад 5 років у мобільній розробці та 40+ інтеграцій з Viber. Viber Business Messages дозволяє надсилати персоналізовані транзакційні повідомлення з гарантією доставки, що критично важливо для фінансових, логістичних та сервісних додатків. Отримайте консультацію для оцінки вашого проекту.
Як працює Viber PA API?
Viber не дає прямого REST API розробникам без посередника. Відправка йде або через Rakuten Viber Partner (прямий доступ — тільки для великих бізнесів з контрактом), або через авторизованих агрегаторів: Infobip, SMSC, MessageBird, TurboSMS та інші. Агрегатор надає свій REST API, який всередині звертається до Viber. Повна специфікація доступна в документації Infobip.
Запит через Infobip виглядає так:
POST https://api.infobip.com/viber/1/message/bulk
Authorization: App {API_KEY}
Content-Type: application/json
{
"bulkId": "bulk-campaign-sample-1",
"messages": [
{
"from": "YourBrandName",
"destinations": [{ "to": "380991234567" }],
"viber": {
"text": "Ваше замовлення #98765 передане в доставку. Очікуйте сьогодні з 14:00 до 18:00.",
"imageUrl": "https://cdn.yourbrand.com/delivery-banner.jpg",
"buttonText": "Відстежити замовлення",
"buttonUrl": "https://yourbrand.com/track/98765"
}
}
]
}
Rich-повідомлення (з картинкою та кнопкою) — тільки для транзакційних. Промо-повідомлення з кнопками вимагають окремого узгодження з Viber.
Вибір агрегатора для Viber
Вибір агрегатора впливає на вартість, надійність та геодоступність. Порівняємо трьох популярних:
| Параметр |
Infobip |
SMSC |
MessageBird |
| Регіони |
Глобально |
Україна, СНД, РФ |
Європа, Азія |
| API |
REST, webhook |
REST, webhook |
REST, webhook |
| Ціна за повідомлення |
Середня |
Низька |
Висока |
| Підтримка rich-медіа |
Так |
Так |
Так |
| Fallback на SMS |
Так |
Так |
Так |
Ми рекомендуємо Infobip для великих проектів з міжнародною аудиторією, SMSC — для локального ринку, MessageBird — для складних сценаріїв з мультиканальністю.
Що таке fallback на SMS та як його налаштувати?
Ключова особливість Viber Business: якщо у користувача немає Viber або він недоступний — можна налаштувати автоматичний fallback на SMS. Це конфігурується на рівні агрегатора:
{
"messages": [{
"viber": { "text": "...", "validityPeriod": 15 },
"sms": { "text": "Коротка SMS-версія повідомлення" }
}]
}
validityPeriod — скільки хвилин чекати доставки у Viber перед перемиканням на SMS. Після відправки агрегатор надсилає webhook із фінальним статусом: DELIVERED_TO_VIBER, DELIVERED_TO_SMS, UNDELIVERABLE. Відповідно до документації Viber PA API, правильна обробка fallback скорочує втрати доставки до 5%.
Чому Viber Business вигідніший за звичайні SMS?
Viber Business — верифікований акаунт із брендингом, високою доставкою (90–95% проти 80% у звичайних повідомлень) та офіційною аналітикою. За статистикою, Viber Business доставляє повідомлення в 2 рази частіше, ніж звичайні SMS, і в 3 рази швидше — за секунди. Скорочення витрат на SMS-розсилку до 40% за рахунок Viber-каналу. Для середнього проекту з 100 000 повідомлень на місяць це дає економію бюджету до 40%. Зв'яжіться з нами — ми розрахуємо ефект для вашого проекту.
Мобільна частина: що реалізується в додатку
Додаток не працює напряму з Viber SDK — він викликає ваш бекенд, який надсилає повідомлення через агрегатора. На мобільній стороні:
- Форма для створення Viber-повідомлень з Rich Media (завантаження зображення, кнопка, текст).
- Попередній перегляд повідомлення перед відправкою.
- Запуск розсилки та відстеження статусу.
// Android — створення Viber-повідомлення
data class ViberMessage(
val recipientPhone: String,
val text: String,
val imageUrl: String? = null,
val buttonText: String? = null,
val buttonUrl: String? = null
)
suspend fun sendViberMessage(message: ViberMessage): MessageResult {
return apiClient.post("/notifications/viber", message)
}
Бекенд обробляє вебхуки та зберігає статуси. Мобільний додаток запитує агреговану статистику:
struct ViberCampaignStats: Decodable {
let total: Int
let deliveredViber: Int
let deliveredSms: Int
let failed: Int
let pending: Int
}
Як ми інтегруємо Viber: процес роботи
-
Аналітика: вибираємо агрегатора, проектуємо схему відправки та обробки вебхуків.
- Реєстрація PA: допомагаємо із заявкою та верифікацією (займає 2–5 робочих днів).
- Розробка API: створюємо REST-шар на бекенді для роботи з агрегатором.
- Мобільний UI: реалізуємо форми відправки rich-повідомлень та статистику.
- Тестування: перевіряємо всі сценарії — доставка, fallback, помилки.
- Деплой: налаштовуємо моніторинг, документацію та підтримку.
Що входить в роботу
- Аналіз поточної інфраструктури та вибір агрегатора (Infobip, SMSC, MessageBird або ін.)
- Реєстрація Public Account та верифікація бренду (до 5 робочих днів)
- Розробка REST API для відправки та обробки вебхуків
- Інтеграція мобільного додатку (форми відправки, статистика)
- Тестування всіх сценаріїв: доставка, fallback, помилки
- Документація по API та підтримка 1 місяць після запуску
Терміни та вартість
Базова інтеграція займає 4–7 робочих днів (без урахування верифікації PA). Вартість залежить від складності та обраного агрегатора — зв'яжіться з нами для оцінки вашого проекту за один день.
Сценарії використання Viber Business
| Сценарій |
Приклад |
Результат |
| Транзакційні сповіщення |
Статус замовлення, код підтвердження |
Доставка 95%, fallback SMS |
| Маркетингові розсилки |
Акції, новинки |
CTR 15%, конверсія 8% |
| Сервісні оповіщення |
Нагадування, зміни розкладу |
Зниження пропусків на 30% |
Замовте консультацію — розберемо ваш кейс і запропонуємо оптимальне рішення.
Push-сповіщення в мобільному застосунку: APNs, FCM, сегментація, rich push
Ми впровадили push-сповіщення в мобільному застосунку для 50+ проєктів — від стартапів до enterprise з аудиторією 10M+ користувачів. Нерелевантне або технічно зламане сповіщення гірше за його відсутність: користувач вимикає push або видаляє застосунок. Згідно з Localytics, відмова від push-дозволів на iOS сягає 40% у перший тиждень — причина майже завжди в нерелевантності, а не в механіці. Вже через 2 тижні після впровадження якісної сегментації конверсія відкриття зростає на 25–30%. Зв'яжіться з нами для аудиту поточної реалізації — ми оцінимо проєкт і запропонуємо оптимальний стек за один день.
Як працює інфраструктура: APNs та FCM
APNs — єдиний канал доставки на iOS. Все інше (OneSignal, Braze, Airship) — обгортки поверх нього. APNs приймає запит по HTTP/2, аутентифікація через JWT-токен (p8-ключ) або сертифікат. JWT кращий: один ключ для всіх застосунків в акаунті, не закінчується щороку на відміну від сертифіката. (Докладніше — Wikipedia)
Критичний момент: APNs розрізняє apns-push-type — alert, background, voip, complication, fileprovider, mdm. Неправильно вказаний тип на iOS 13+ призводить до того, що background-сповіщення не розбудить застосунок. Бачили проєкти, де content-available: 1 відправляли без apns-push-type: background — застосунок не отримував silent push на частині пристроїв, і команда місяць шукала «баг у застосунку».
FCM на Android працює через Google Play Services. Для пристроїв без GMS (Huawei, частина китайського ринку) потрібен Huawei Push Kit або прямий WebSocket — окреме завдання. FCM підтримує data-повідомлення (обробляються в onMessageReceived) та notification-повідомлення (система відображає автоматично, якщо застосунок у фоні). Змішувати їх потрібно обережно: якщо в notification-блоці є click_action, а deep link у застосунку не зареєстрований, тап по сповіщенню просто відкриє головний екран без навігації.
| Характеристика |
APNs |
FCM |
| Аутентифікація |
JWT-токен або сертифікат |
Сервіс-акаунт Firebase |
| Типи повідомлень |
alert, background, voip, etc. |
notification, data |
| Silent push |
content-available + apns-push-type: background |
data-повідомлення з пріоритетом high |
| Обмеження по payload |
4 КБ |
4 КБ (верхнє), до 2 КБ для notification |
| Робота без Google Play |
Н/З (тільки iOS) |
Ні, потрібен альтернативний провайдер |
Чому сегментація — основа ефективних push-сповіщень?
Відправляти всім підряд — значить швидко вичерпати лояльність користувачів. Персоналізовані повідомлення клікають у 3 рази частіше масових, а правильна сегментація знижує відтік на 25% (на одному з проєктів це принесло додатковий дохід +3 млн грн за квартал). Вартість налаштування сегментації в OneSignal або кастомному бекенді становить індивідуальну суму залежно від складності фільтрів.
Нормальна сегментація будується на кількох рівнях.
| Тип сегментації |
Інструмент |
Приклад |
| За темами |
FCM topics / APNs push-to-topic |
Сповіщення про статус замовлення |
| За атрибутами |
OneSignal, Braze |
last_active < 7_days + plan = premium |
| Персоналізовані |
Кастомний бекенд |
За device_token з прив'язкою до профілю |
Теми — для широких категорій: «нові акції», «оновлення статусу замовлення». Користувач підписується через FirebaseMessaging.getInstance().subscribeToTopic("orders"). Просто, але нема гнучкої фільтрації.
Сегменти за атрибутами — через OneSignal, Braze або кастомний бекенд. Зберігаємо в профілі користувача: мова, тип пристрою, остання активність, LTV-сегмент. Сповіщення йде тільки тим, у кого last_active < 7_days та plan = premium. OneSignal дозволяє будувати такі фільтри в інтерфейсі без коду.
Персоналізовані — за конкретним device_token. Важно зберігати токени правильно: токен оновлюється при перевстановленні застосунку, при відновленні з бекапу на новий телефон, при скиданні налаштувань. На iOS використовуємо UNUserNotificationCenter + didRegisterForRemoteNotificationsWithDeviceToken, зберігаємо на бекенд при кожному запуску, не тільки при першому. Інакше через 3 місяці 30% токенів у базі застарілі.
Що таке rich push і як він підвищує конверсію?
Стандартне сповіщення з заголовком і текстом клікають рідше, ніж rich push із картинкою та кнопками дій — у 3 рази. Але реалізація rich push — окрема робота на кожній платформі.
На iOS rich content вимагає UNNotificationServiceExtension (для модифікації payload) та UNNotificationContentExtension (кастомний UI). Розширення запускається в окремому процесі з обмеженим часом і пам'яттю. Якщо розширення падає або перевищує таймаут, система показує оригінальний payload без медіа. Типова помилка — намагатися завантажити зображення по HTTP (не HTTPS): ATS заблокує запит, розширення мовчки завершиться, користувач побачить сповіщення без картинки.
На Android з API 26+ сповіщення прив'язані до NotificationChannel. Якщо канал створений з IMPORTANCE_LOW, звук і вібрація недоступні. Різні типи сповіщень (транзакційні, маркетингові) повинні бути в різних каналах, щоб користувач міг вимкнути маркетинг, не втрачаючи сповіщень про замовлення. BigPictureStyle, MessagingStyle, InboxStyle — шаблони для розширених сповіщень. MessagingStyle з Person та аватарками — найкращий вибір для чатів.
| Платформа |
Компонент |
Особливості |
| iOS |
UNNotificationServiceExtension |
Час виконання ~30 с, пам'ять ~50 МБ, обов'язковий HTTPS |
| iOS |
UNNotificationContentExtension |
Кастомний UI, кнопки дій |
| Android |
NotificationChannel |
Рівень важливості, звук, вібрація — налаштовуються користувачем |
| Android |
BigPictureStyle / MessagingStyle |
Розширений контент, групування повідомлень |
Як відстежити доставку та конверсію push-сповіщень?
Відправити сповіщення — половина справи. Важно знати: доставлено воно, відкрито, чи привело до цільової дії.
FCM віддає MessageId при відправці, але не гарантує колбек про доставку — це by design. Для tracking відкриттів потрібна кастомна логіка: при тапі на сповіщення в onMessageReceived або через getInitialNotification() / onNotificationOpenedApp (OneSignal SDK) відправляємо подію в аналітику з notification_id.
OneSignal надає вбудовану аналітику доставки та CTR. Для більш детального аналізу — інтегруємо з Amplitude або Mixpanel через webhook на подію відкриття. Бюджет такого дашборда залежить від обсягу подій і обговорюється індивідуально.
Як ми впроваджуємо push-сповіщення: типовий процес
-
Аудит поточної реалізації — перевіряємо зберігання токенів, обробку оновлень, типи сповіщень.
-
Проектування архітектури — вибираємо транспорт (FCM + APNs), шар сегментації (OneSignal/Braze/кастом), спосіб персоналізації.
-
Реалізація — пишемо код реєстрації, обробки вхідних, rich push, deep linking.
-
Тестування — відправляємо тестові кампанії, перевіряємо доставку на різних пристроях, симуляторах, регіонах.
-
Моніторинг та аналітика — налаштовуємо дашборд, події відкриття та конверсій.
-
Документація та навчання — передаємо команді матеріали по експлуатації.
Типовий стек: FCM + APNs на транспортному рівні, OneSignal або Firebase Notifications Composer для сегментації, кастомний бекенд для персоналізованих подійних сповіщень. Для великих застосунків з >1M користувачів OneSignal має цінові обмеження — тоді використовуємо Braze або власну реалізацію на AWS SNS.
Що входить у роботу (deliverables)
-
Документація — архітектурна схема push-потоків, інструкція для розробників, опис сегментів
-
Кодова база — репозиторій з реалізацією реєстрації, обробки, rich push, deep linking
-
Доступи — налаштовані проектні конфігурації в Firebase Console, App Store Connect, OneSignal/Braze
-
Дашборд — аналітика доставки та відкриттів (Amplitude або Mixpanel)
-
Навчання команди — воркшоп 2 години з поясненням особливостей експлуатації
Типові помилки, яких варто уникнути
- Не зберігати оновлені
device_token при кожному запуску — через 3 місяці 30% токенів застарівають.
- Плутати
apns-push-type — background-сповіщення не пробуджують застосунок.
- Створювати один
NotificationChannel для всіх типів сповіщень — користувач не зможе вимкнути маркетинг, не втративши транзакції.
- Завантажувати медіа в rich push по HTTP — ATS блокує запит на iOS.
- Не перевіряти deep link у таргетингу — переходи йдуть на головний екран.
Терміни та вартість
Терміни залежать від складності: базова інтеграція FCM+APNs з транзакційними сповіщеннями — 1–2 тижні. Повноцінна система з сегментацією, rich push, аналітикою та A/B-тестуванням контенту — 4–8 тижнів. Вартість розраховується індивідуально після аудиту.
Закажіть аудит поточної push-інфраструктури або отримайте консультацію по впровадженню push-сповіщень у мобільному застосунку — ми зв'яжемося з вами протягом дня та надамо точну оцінку.