Настройка геозависимых push-уведомлений в 1С-Битрикс

Представьте: у вас интернет-магазин на 1С-Битрикс с мобильным приложением. Клиент подходит к вашему физическому магазину — вы хотите отправить ему персональное предложение с геозависимым push. Без геофенсинга это невозможно. Мы решаем эту задачу под ключ: от хранения токенов до интеграции с FCM и обработки ошибок. Бюджет такой интеграции — от $360–520, но экономия на маркетинговых рассылках окупает её за 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' или '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 дней в зависимости от сложности. Стоимость рассчитывается индивидуально после оценки проекта. Мы гарантируем стабильную работу и поддержку после внедрения. Закажите консультацию — оценим ваш проект бесплатно.