Сбой доставки критического уведомления: клиент не получил код подтверждения, заказ завис, а 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 или кастомном бэкенде составляет от 100 000 до 250 000 рублей в зависимости от сложности фильтров.
Нормальная сегментация строится на нескольких уровнях.
| Тип сегментации |
Инструмент |
Пример |
| По топикам |
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 на событие открытия. Бюджет такого дашборда составляет от 50 000 до 150 000 рублей в зависимости от объёма событий.
Как мы внедряем push-уведомления: типовой процесс
-
Аудит текущей реализации — проверяем хранение токенов, обработку обновлений, типы уведомлений.
-
Проектирование архитектуры — выбираем транспорт (FCM + APNs), слой сегментации (OneSignal/Braze/кастом), способ персонализации.
-
Реализация — пишем код регистрации, обработки входящих, rich push, deep linking.
-
Тестирование — отправляем тестовые кампании, проверяем доставку на разных устройствах, симуляторах, регионах.
-
Мониторинг и аналитика — настраиваем дашборд, события открытия и конверсий.
-
Документация и обучение — передаём команде материалы по эксплуатации.
Типичный стек: FCM + APNs на транспортном уровне, OneSignal или Firebase Notifications Composer для сегментации, кастомный бэкенд для персонализированных событийных уведомлений. Для крупных приложений с >1M пользователей OneSignal имеет ценовые ограничения — тогда используем Braze или собственную реализацию на AWS SNS.
Типичные ошибки при настройке push-уведомлений
- Не хранить обновлённые
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-уведомлений в мобильном приложении — мы свяжемся с вами в течение дня и предоставим точную оценку.