Налаштування геозалежних push-сповіщень у 1С-Бітрікс

Уявіть: у вас інтернет-магазин на 1С-Бітрікс з мобільним додатком. Клієнт підходить до вашого фізичного магазину — ви хочете надіслати йому персоналізовану пропозицію з геозалежним push. Без геофенсингу це неможливо. Ми вирішуємо це завдання під ключ: від зберігання токенів до інтеграції з FCM та обробки помилок. Бюджет такої інтеграції визначається індивідуально, але економія на маркетингових розсилках окупає її за 2–3 місяці. Зв'яжіться з нами — оцінимо ваш проект безкоштовно.

Як серверна частина обробляє геозону?

Геозонна подія надходить з мобільного додатку. На сервері ми приймаємо подію, ідентифікуємо користувача та шукаємо всі його активні токени в HL-інфоблоці DeviceTokens. Для кожного токена формуємо push через FCM HTTP v1 API. Цей API втричі надійніший за Legacy API та підтримує OAuth2.

Який стек доставки push ми використовуємо?

Для мобільних push-сповіщень працюють два канали:

• FCM (Firebase Cloud Messaging) — Android та iOS (через Firebase APNs proxy)
• APNs (Apple Push Notification service) — iOS напряму

Для веб-сайту без мобільного додатку існують Web Push (стандарт W3C), але вони вимагають відкритого браузера або підтримки Service Worker і не працюють в iOS Safari до iOS 16.4.

Бітрікс має вбудований модуль push.sender — але він призначений для Бітрікс24 та Push & Pull сервера. Для кастомних push у мобільному додатку використовуємо FCM напряму з PHP.

Реєстрація та зберігання токенів пристроїв

Перед відправленням push потрібно отримати device token користувача. Додаток при першому запуску запитує дозвіл та отримує токен від FCM/APNs, потім надсилає його на сервер.

Ендпоінт для реєстрації токена (/local/ajax/register-token.php):

$userId = $USER->GetID(); $deviceToken = $data['token']; $platform = $data['platform']; // 'android' or 'ios' // Сохраняем в HL-инфоблок DeviceTokens \Local\Push\DeviceTokenTable::add([ 'UF_USER_ID' => $userId, 'UF_TOKEN' => $deviceToken, 'UF_PLATFORM' => $platform, 'UF_UPDATED' => new \Bitrix\Main\Type\DateTime(), ]); 

Один користувач може мати кілька токенів (телефон + планшет). Токени застарівають — FCM повертає помилку NotRegistered, за якою потрібно видаляти токен з бази. Згідно з документацією FCM, HTTP v1 API рекомендований для нових проектів.

Чому важливо правильно зберігати токени?

Неправильне зберігання призводить до надсилання на неактивні пристрої, зростання кількості помилок та блокування від FCM. Ми ведемо історію оновлень, видаляємо токени після помилки та підтримуємо актуальність.

Тригер по геозоні

Геозонна подія надходить з мобільного додатку (логіку нативного геофенсингу див. у статті про geofencing-уведомления). Серверна частина отримує подію та шукає всі активні токени користувача:

$tokens = \Local\Push\DeviceTokenTable::getList([ 'filter' => ['=UF_USER_ID' => $userId, '=UF_ACTIVE' => true], 'select' => ['UF_TOKEN', 'UF_PLATFORM'], ])->fetchAll(); foreach ($tokens as $token) { \Local\Push\Sender::send( $token['UF_TOKEN'], $token['UF_PLATFORM'], $zone['UF_PUSH_TITLE'], $zone['UF_PUSH_BODY'], ['zone_id' => $zoneId, 'action' => 'open_promo'] ); } 

Відправлення через FCM HTTP v1 API

Google переходить з legacy FCM API на HTTP v1 (OAuth2). Приклад відправлення одного push:

namespace Local\Push; class Sender { public static function send( string $token, string $platform, string $title, string $body, array $data = [] ): bool { $accessToken = self::getOAuthToken(); // OAuth2 через Service Account JSON $message = [ 'message' => [ 'token' => $token, 'notification' => [ 'title' => $title, 'body' => $body, ], 'data' => array_map('strval', $data), ], ]; $http = new \Bitrix\Main\Web\HttpClient(); $http->setHeader('Authorization', 'Bearer ' . $accessToken); $http->setHeader('Content-Type', 'application/json'); $response = $http->post( 'https://fcm.googleapis.com/v1/projects/' . FCM_PROJECT_ID . '/messages:send', json_encode($message) ); $result = json_decode($response, true); return isset($result['name']); // name присутствует при успехе } } 

Для getOAuthToken() використовується Google Client Library або власна реалізація JWT-підпису з Service Account.

Кастомний звук та іконка

Для Android-сповіщень можна задати канал сповіщень (Notification Channel), звук та іконку через секцію android в payload FCM. Для iOS — через секцію apns. Ці параметри задаються при розробці мобільного додатку, серверна частина лише передає значення.

Моніторинг доставки

FCM HTTP v1 повертає результат негайно, але це лише підтвердження прийняття на обробку, не факт доставки. Для відстеження відкриттів сповіщень потрібна аналітика на стороні додатку (Firebase Analytics або власний ендпоінт).

Як налаштувати geofence push: покрокова інструкція

1. Створіть HL-інфоблок DeviceTokens з полями: UF_USER_ID (int), UF_TOKEN (string), UF_PLATFORM (string), UF_ACTIVE (bool), UF_UPDATED (datetime).
2. Реалізуйте ендпоінт для реєстрації токенів: приймає POST-запит з token та platform, зберігає запис.
3. Напишіть обробник входу в геозону: при події від додатку отримуєте userId, знаходите всі активні токени.
4. Для кожного токена викликайте Sender::send() з заголовком та тілом сповіщення.
5. Впровадьте cooldown: перед відправленням перевіряйте, коли було надіслано останнє сповіщення для цієї пари користувач+зона.

$lastSent = \Local\Push\SentHistoryTable::getRow([ 'filter' => ['=UF_USER_ID' => $userId, '=UF_ZONE_ID' => $zoneId], 'select' => ['UF_SENT_AT'], ]); if ($lastSent && (time() - $lastSent['UF_SENT_AT']->getTimestamp()) < 600) { return; // не отправляем чаще 10 минут } 

Що входить в роботу

• Налаштування HL-блоків для зберігання токенів та історії геозон
• Ендпоінт реєстрації токенів
• Інтеграція FCM HTTP v1 з OAuth2
• Обробник геозонних подій
• Дедуплікація та cooldown-логіка
• Тестування на реальних пристроях
• Документація по API та налаштуванні

Процес роботи

Терміни та вартість

Базова настройка займає від 2 до 5 днів залежно від складності. Вартість розраховується індивідуально після оцінки проекту. Ми гарантуємо стабільну роботу та підтримку після впровадження. Замовте консультацію — оцінимо ваш проект безкоштовно.