Тестирование push-уведомлений
Last updated
Was this helpful?
Last updated
Was this helpful?
Push-уведомления — это сообщения, отправляемые на мобильное устройство клиента. Они обычно используются для доставки обновлений продуктов, напоминаний, персонализированных предложений, последних новостей и любой информации, которая является неотъемлемой частью функциональности приложения и требует особого внимания или быстрых действий.
Важно! Не путайте уведомления и push.
Уведомление – это всплывающая плашка, звук, значок – элемент интерфейса призванный обратить на себя внимание пользователя. Чтобы показать уведомление, приложению не нужно ничего, оно может показать информацию без подключения к интернету, напомнить вам о каком-либо событии и всё в этом духе. Триггером для показа уведомления может быть что угодно, внутренняя логика приложения, таймер, или же push-сообщение.
Push – пуш это сообщение! Сообщение в специальном формате , которое должно быть обработано на телефоне. Оно приходит через специального посредника – сервиса пуш-сообщений через интернет. Обычно им выступает сервис от производителя операционной системы (APNS - Apple, FCM - Google, HMS - Huawei) но также могут использоваться альтернативные поставщики пушей. Как правило пуши нацелены на то, чтобы показать вам уведомление, однако это совсем не обязательное условие, и пуши могут быть неотображаемые и нужны приложению для обновления какой-нибудь внутренней информации.
Иными словами пуш может быть уведомлением, а может не быть, а уведомление может быть пуш-уведомлением, а может локальным (или внутренним, реализуемый по внутренней логике приложения в обход пуш-сервера).
Пользователь устанавливает ваше приложение на устройство и запускает его;
1 – приложение регистрируется в службе push-уведомлений и получает у него токен — уникальный идентификатор устройства;
2 – приложение передает полученный токен на ваш сервер;
3 – сервер шлет уведомления в службу push-уведомлений при наступлении определенного события, вместе с полученным токеном;
4 – служба push-уведомлений по токену находит ваше устройство и отправляет push на него, , где служба сервиса принимает его и решает как поступить (показать, отложить или разбудить ваше приложение для обработки пуша).
Доставка push-сообщений даже, когда ваше приложение выключено, осуществляется за счёт того, что службы push-уведомлений постоянно подключены к своим серверам, не убиваются системой и имеют право "разбудить" ваше приложение.
В случае iOS уведомления работают через облачную платформу APNS (Apple Push Notification Service).
Если говорить о решении пуш-уведомлений от Android, то есть несколько вариантов. Самый простой способ действовать — использовать Firebase Cloud Messaging (FCM) для устройств Android с Google Apps. Если у ваших пользователей есть устройства Huawei (а именно, без Google Apps), то для работы пушей на таких устройствах необходимо будет также поддержать работу с HMS (Huawei Push Kit), используя Huawei Push Kit.
Конечно, вы также можете создать собственного провайдера push-уведомлений или использовать готовые проекты, поскольку платформа имеет открытый исходный код.
Стоит отметить тот факт, что решения для Android (как Firebase Cloud Messaging, так и Huawei Push Kit) можно использовать как прокси к пушам на iOS, позволяя работать с пушами из одной точки входа с единым API.
iOS основана на модели push Opt-In, которая не позволяет брендам отправлять мобильные push-уведомления пользователям своих приложений до тех пор, пока эти пользователи не согласятся их получать.
Начиная с 13 версии Android также добавил необходимость приложениям получать разрешения на показ уведомлений. До 13 версии Android по умолчанию разрешает пользователям получать push-уведомления с возможностью отказаться от них вручную. Что давало более широкую аудиторию пользователей с поддержкой push. Однако, когда у пользователей нет возможности легко отказаться от их получения, нерелевантные или слишком частые уведомления могут подтолкнуть клиентов отключить сообщения или удалить приложение.
Тут нужно отметить тот факт, что речь касается именно показа уведомлений, но так называемые тихие (silent) push-сообщения всё ещё будут приходить на устройство и "будить" ваше приложения для обработки сообщения, несмотря на запрет уведомлений.
Если у вас на проекте только вводят push-уведомления или вы обнаруживаете много проблем с их доставкой в первую очередь обратитесь к официальной документации провайдеров push-сообщений. Так как у них есть множество ограничений и условий (такие как время жизни пуша, приоритет и т.д.), неправильная настройка какого-либо параметра может сделать так, что почти все push не будут доходить или будут приходить с запозданием.
Не приходят push-уведомления: Чтобы разобраться в причине, для начала проверьте, чтобы в меню устройства была активирована соответствующая функция (разрешены уведомления для конкретного приложения). Затем убедитесь, что не включен режим «Не беспокоить». Если всё настроено правильно, но уведомления не приходят, попробуйте перезагрузить устройство и заново авторизоваться в приложении. Токен push-сервиса мог протухнуть и приложению необходимо получить его вновь. Или на вашем сервере не происходит регистрация или удаляется полученный токен. Совместно с backend вашего сервиса проверьте, корректность регистрации устройства, а также ответ API службы push-уведомлений (FCM, APNS или др.). Проверьте также, какой стиль уведомления используется (необходим «Баннер» либо «Предупреждение»). Если не помогло всё перечисленное, попробуйте перезайти в свою учетную запись магазина приложений, либо откройте саму программу, в том случае, если на другие приложения тоже не приходят push-уведомления (стоит также проверить наличие интернета на устройстве).
Переходы по push-уведомлению: При тестировании необходимо проверить такие сценарии (с учётом того, что пользователь может быть авторизован или неавторизован):
переход по push-уведомлению с заблокированного экрана;
переход по push-уведомлению из «шторки»;
пользователь находится в приложении;
переход по push-уведомлению при свёрнутом приложении;
пользователь разлогинился после получения push;
переход по push-уведомлению с включенным «Don't keep Activities» (характерно для Android-приложений).
Существуют push-уведомления, которые ведут на определенный экран с выбором определенных фильтров. В таком случае необходимо проверить, что переход осуществляется на правильный экран. Если это был поисковой запрос, то проверьте, что текст поискового запроса отображается в строке поиска и выдача товаров соответствует поиску. Также могут передаваться определенные фильтры, в таком случае необходимо проверить, что выбраны все «зашитые» фильтры.
Если push-уведомление ведет на WebView, то проверьте, что WebView открывается корректно на обеих платформах. И что в push зашит корректный URL.
Устаревший push-токен: У устройства изменился push-токен, когда восстановили приложение из резервной копии системы и не передался новый push-токен.
Ограничения со стороны службы push-уведомлений: Google и Apple не гарантируют доставку push, есть множество параметров, которые могут повлиять на скорость доставки пуша. Например, Google может уменьшить приоритет push-сообщений, если большая часть push-сообщений не отображается в виде уведомлений. Также на скорость доставки push может повлиять большая очередь на доставку со стороны служб.
Проверка максимального и минимального количества отображаемых символов: В iOS и Android имеется лимит отображаемых символов. Он разный. Максимальное значение количества символов для платформы iOS - ограничение в 4 строки (178 символов), а для Android — не более 13 строк (663 символа). Не забудьте также проверить push-уведомление, содержащее минимальное количество символов, для обоих платформ можно задать 1 символ.
Кастомный звук для push-уведомления: При тестировании push-уведомлений важно учитывать тот факт, что звук push-уведомления может быть задан кастомный. В таком случае необходимо проверять и звуковое сопровождение нотификации.
Изображения в push-уведомлениях: Push-уведомление может содержать изображение, при отправке пуша — клиент получает ссылку на изображение и перед показом загружает его, далее происходит процесс обогащения пуша картинкой - она устанавливается. Уведомление отображается после загрузки картинки. Если push-уведомление содержит картинку, необходимо проверить, что она отображается.
Локальные уведомления: Локальные уведомления планируются самим приложением и служат для своевременного и актуального информирования пользователей, пока приложение не работает на переднем плане. Чтобы уведомление отобразилось, его необходимо запланировать самому пользователю. В таких случаях проверяем кейсы, связанные с таймингом отправки сообщения.
Проблемы на серверной стороне: В другие приложения приходят push-уведомления, но не приходит на наше, хотя push-токен отправлен на сервер. Стоит проверить корректность отправки push на другие аккаунты сервиса и другие устройства. При отсутствии push-уведомлений сообщите команде серверной разработки.
Мультиаккаунт: Если в вашем приложние реализована возможность входа в несколько аккаунтов, крайне важно тщательно изучить какое должно быть поведение push при входе в несколько аккаунтов. Должны ли приходить push со всех или только с активного аккаунта. Если да нужно проверить коректность переключения аккаунтов при открытии push, а также, что пользователю понятно для какого аккаунта пришёл push. Если push не должны приходить для не активных аккаунтов, то следует проверить корректность перерегистрации аккаунта на сервере и/или push-токена (в зависимости от выбранной логики) при переключении аккаунтов.
Наличие систем наблюдения и статистики позволит вам быстрее реагировать на новые проблемы, а также анализировать эффективность доставки пушей, тем самым улучшая пользовательский опыт.
Есть два решения из которого можно взять статистику:
Статистика от push-провайдера – имеет как преимущества так и недостатки. Например, агрегированный формат и BigQuery для детального анализа от FCM или для iOS девайсов статистика от APNS. Однако, они не могут предоставить информацию об открытиях пушей, не все события будут записаны (например, если пользователь запретил сбор статистики), а также есть сложности в анализе конкретных проблем.
Второй вариант это собственная система аналитики (либо интеграция сторонних решений), когда ваше приложение само сообщает информацию на ваш бэк с информацией о том, что пуш был доставлен.
Такое решение позволяет получить подробную статистику о пушах, провести детальную трассировку от сервера до устройства, возможность реализовать больше бизнес-требований. Например, можно отслеживать не только пуши, но и в целом все виды уведомлений, которые у вас показываются, считая общую эффективность доставки сообщений, не зависимо от источника.
Источники:
Доп. материал: