Как определяется доставка пуш-уведомления?
Что проверяют
Понимаете ли вы, что у пуша несколько точек, которые называют «доставкой», и что успешный ответ сервиса отправки ещё не значит, что пользователь что-то увидел. Следом обычно просят составить набор проверок: какие состояния устройства и приложения вы переберёте.
Как отвечать
Разложите путь по звеньям и назовите, что видно на каждом:
- бэкенд и провайдер: сервер отправляет запрос в FCM (HTTP v1 API) или APNs (HTTP/2). Успешный ответ значит только, что провайдер принял сообщение. Ошибки говорят о токене:
UNREGISTEREDу FCM,410у APNs, такие токены удаляют; - провайдер и устройство: пока устройство оффлайн, FCM хранит сообщение до истечения TTL (по умолчанию до четырёх недель), а APNs держит только последнее уведомление для приложения. Статистику этапа дают отчёты доставки в консоли Firebase и экспорт данных доставки в BigQuery для Android;
- показ: система не покажет уведомление, если отключено разрешение (с Android 13 это runtime-разрешение
POST_NOTIFICATIONS), выключен канал уведомлений или включён режим фокусирования на iOS; - открытие: тап фиксирует аналитика приложения.
Фактическую доставку подтверждает только клиент. На Android приложение шлёт квитанцию из onMessageReceived, на iOS это делает Notification Service Extension при mutable-content: 1. Сверка «отправлено, принято провайдером, получено клиентом» по одному идентификатору сообщения и есть метрика доставки.
Состояния для тестов: приложение на переднем плане, в фоне, выгружено, принудительно остановлено на Android (сообщения не придут до ручного запуска), Doze, устройство без сети, переустановка со сменой токена.
Где спотыкаются
Считают ответ 200 от провайдера доставкой и закрывают тест по логам сервера.
Проверяют только приложение на переднем плане. На Android notification-сообщение в фоне показывает система без вызова onMessageReceived, квитанция не уходит, а data-сообщение ведёт себя иначе.
Не проверяют отозванные разрешения и устаревшие токены. По логам пуш «доставлен», а на экране его нет.