Push принят сервисом, но пользователь его не увидел: какие статусы действительно нужны

В панели рассылки написано «успешно», а сотрудник показывает телефон без уведомления. Спор легко заходит в тупик: разработчик доказывает успешный запрос к провайдеру, пользователь — отсутствие сообщения на экране. Они говорят о разных этапах. Для разбора нужен договор о смысле каждого статуса.

Сначала найдите конкретную попытку на конкретном устройстве

Один пользователь может иметь несколько установок приложения. Одно сообщение — отправляться повторно или в разные каналы. Поэтому сопоставляйте ID сообщения, техническую цель доставки и ID попытки, если схема его предусматривает. Общий счётчик «отправлено пользователю» скрывает различие между старым телефоном и текущим устройством.

Не публикуйте действующие регистрационные токены в обычном тикете. Для диагностики используйте безопасный технический идентификатор, состояние токена, платформу и версию приложения. Ответ провайдера о недействительном адресате требует обработки по его документации, а не бесконечных повторов одного запроса.

Какие причины проверять после приёма провайдером

Устройство может быть вне сети, разрешение на уведомления — не выдано, а правила ОС — ограничивать фоновую обработку или отображение. Поведение зависит от платформы, типа сообщения и состояния приложения. При открытом приложении уведомление иногда обрабатывается иначе, чем в фоне. Эти различия должны входить в тестовую матрицу.

Не меняйте сразу весь формат сообщения. Возьмите один учебный сценарий и проверьте его при активном приложении, в фоне и после перезапуска. Зафиксируйте разрешение пользователя и доступность сети. Отдельно проверьте актуальную регистрацию устройства после переустановки или смены аккаунта.

Подтверждение приложения — ваша измерительная функция

Если продукту нужен собственный ACK, его надо спроектировать и реализовать. Нельзя получить такой статус простым переименованием ответа API. Событие должно иметь чёткий смысл: например, обработчик приложения принял сообщение. Оно само тоже может задержаться или потеряться, поэтому отсутствие ACK означает отсутствие наблюдения, а не однозначный провал доставки.

Открытие связывайте с исходным сообщением и проверенным пользователем. Повторный запуск экрана не должен многократно увеличивать число открытий. При этом не превращайте техническую диагностику в сбор лишних действий человека: состав аналитики и сроки хранения выбираются под реальные задачи и правила обработки данных.

Инструмент: одна карточка для каждого сообщения и цели

Введите учебные события в формате «сообщение;цель;этап». Допустимы queued, provider_accepted, app_ack, opened и error. Инструмент объединит наблюдения для каждой пары и покажет, каких подтверждений нет. Повтор одинакового события не увеличивает число целей.

Статусы могут конфликтовать: после ошибки повторная попытка иногда заканчивается успешно. Поэтому результат сохраняет все наблюдения, а не объявляет любую строку error окончательным отказом. В этой простой модели отдельные попытки не анализируются; для рабочего журнала их полезно выделить явно.

Что поставить в задачу команде

• Определить смысл слова «успешно» на каждом экране и в API.
• Связать серверные и клиентские события безопасными идентификаторами.
• Добавить обработку недействительных целей и предусмотренные повторы.
• Испытать несколько состояний приложения и разрешений на реальных тестовых устройствах.
• Показывать «подтверждение отсутствует» там, где измерение не позволяет уверенно утверждать недоставку.

Для критичных действий, например изменения статуса заказа, push не должен быть единственным местом истины. Актуальное состояние остаётся доступным в приложении, а уведомление помогает обратить на него внимание. Тогда техническая задержка баннера не уничтожает саму бизнес-операцию.