Налаштування push-сповіщень за геозоною 1С-Бітрікс
Push-сповіщення за геозоною — окремий випадок геофенсингу з фокусом саме на каналі доставки. Завдання: коли користувач опиняється у заданому радіусі від точки, він отримує push на телефон. Розбираємо, як це реалізується з серверної сторони Бітрікса.
Стек доставки 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' або '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, за якою потрібно видаляти токен із бази.
Тригер за геозоною
Геозонна подія надходить із мобільного застосунку (логіку нативного геофенсингу див. у статті про 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 або власний ендпоінт).
| Етап | Час |
|---|---|
| Сховище токенів (HL-інфоблок + API) | 3–4 год |
| Інтеграція FCM HTTP v1 | 4–6 год |
| Обробник геозонних подій | 2–3 год |
| Логіка дедуплікації / cooldown | 2–3 год |
| Тестування на реальних пристроях | 3–5 год |







