FCM не предоставляет уведомление всем подписчикам темы (уведомление о данных)

Я использую FCM для отправки уведомлений пользователям моих приложений. Я также использую Firebase Analytics, чтобы получить некоторые отзывы о поведении приложения.

У меня есть приложение, которое подписывается на конкретную тему, когда начинает свою деятельность по умолчанию. Таким образом, в основном каждый пользователь, который запускал хотя бы один раз приложение, является подписчиком темы. Из аналитики firebase я вижу 21374 first_open в журналах событий за последние 30 дней. Я также могу увидеть эту сумму на панели "активных пользователей".

В основном, для этой темы должно быть доступно не менее 21k подписчиков.

Вчера я опубликовал уведомление по этой теме. Это уведомление о данных, поэтому нет проблем с фоном/передним/не начатым состоянием приложения.

В методе onMessageReceived я регистрирую событие на основе аналитики firebase. И, видимо, только 2,9 тыс. Пользователей получили уведомление.

Что может объяснить это различие между подсчетами подписчиков и уведомлением, эффективно продвигаемым пользователям?

Некоторые элементы, которые могут быть связаны:

  • Приложение было обновлено в магазине 3 дня назад. Таким образом, пользователи могут не запускать новую версию приложения. Но обновление не должно удалять тему, уже подписанную предыдущей версией. Я также проверил некоторые тесты, чтобы проверить это, и обновление не удаляет тему, подписанную предыдущей версией (если приложение не будет удалено первым). Поэтому это не должно быть причиной этой проблемы.

  • Приложение было обновлено новой версией пакета GooglePlayServices/Firebase (от 9.2 до 10.0.1) Удаляет ли он все темы, подписанные более старой версией пакета GooglePlayServices/Firebase?

Есть ли другая причина, которая может привести к такой разнице между подсчетами подписчиков и количеством отправленных уведомлений?


@Bob Snyder

Вот как я проверяю версию Google Play Services:

protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    GoogleApiAvailability googleApiAvailability =  GoogleApiAvailability.getInstance();
    int success = googleApiAvailability.isGooglePlayServicesAvailable(this);
    if(success != ConnectionResult.SUCCESS) {
        googleApiAvailability.makeGooglePlayServicesAvailable(this);
    }

    FirebaseMessaging.getInstance().subscribeToTopic("mytopic");

Используемая версия Служб Google Play относится к среде Mobile + wear, у многих пользователей есть некоторые проблемы с обновлением версии GooglePlayService, поэтому я обычно поддерживаю более низкую версию, чем последняя версия, и обновляю ее только в том случае, если необходимо.


@Jorgesys

My FirebaseMessagingService на самом деле довольно прост:

public class MyFirebaseMessagingService extends FirebaseMessagingService {
@Override
public void onMessageReceived(RemoteMessage remoteMessage) {
    Logger.d("From: " + remoteMessage.getFrom());

    MyFirebaseAnalytics mAnalytics = new MyFirebaseAnalytics(this);
    mAnalytics.logEvent("notif", "reception");

    Map<String, String> data = remoteMessage.getData();
    // Check if message contains a data payload.
    if (data.size() > 0) {
        Logger.d("Message data payload: " + data);
}

Метод logEvent - это тот, который регистрирует событие в Firebase.

Ответ 1

Ну, здесь может быть несколько факторов:

1) Люди, возможно, удалили ваше приложение

2) Люди могли использовать "Force Stop" в вашем приложении

3) Аналитические данные обычно занимают некоторое время для регистрации, оно может быть неполным

4) Люди не подключены к сети, кэш-сообщения которых кэшируются до истечения срока действия сообщения темы (по умолчанию 4 недели)

5) Пользователь мог очистить данные приложения, что приводит к тому, что идентификатор экземпляра становится недействительным, а сообщения темы также отменяются. Если у вас нет логики повторной подписки на вашем конце, они останутся без подписки.

6) В новых версиях Android, если ваше приложение не открывается в течение некоторого времени (Google не раскрыл сумму), и в те дни, если ваше приложение не имеет каких-либо видимых компонентов, например, переднего плана, уведомления и т.д... Приложение получает кеширование и уведомления не доставляются, как обычно. Это режим ожидания приложения

7) Истекает время истечения срока действия сообщения данных, и к этому времени пользователь не подключился к серверу FCM и не получил сообщения.

8) В некоторых ситуациях FCM может не доставлять сообщение. Это происходит, когда слишком много сообщений ( > 100) ожидает вашего приложения на определенном устройстве в момент его подключения или если устройство не подключено к FCM более чем за один месяц. В этих случаях вы можете получить обратный вызов FirebaseMessagingService.onDeletedMessages()

Могут быть и другие факторы, такие как экран темы, показывающий 21k, но он не обновляется с фактическим счетом и т.д.

Ответ 2

Похоже, что аналитика firebase по "полученному уведомлению" в случае, если уведомление о данных является очень неточным.

Я провел следующий тест: отправил ~ 100 000 пользователей уведомление о данных, которое немедленно отображает уведомление, а другим ~ 100 000 пользователям это же уведомление на этот раз с помощью консоли Firebase. (Перед созданием тем для теста случайным образом перетасовали токены)

Согласно консоли Firebase, скорость получения уведомлений о данных составляет 40%, а уведомлений, отправленных из консоли, - 84%. Таким образом, можно ожидать, что число открытий толчка будет пропорционально количеству "полученных", но удивительно, что число открытий толчка в обеих группах было практически одинаковым.

В другом тесте, который мы провели, мы сравнили аналитику из нашей внутренней системы с firebase, и "полученное" в нашей системе было в два раза больше, чем сообщалось в firebase. Обратите внимание, что эти тесты были проведены совсем недавно (2 дня), и могут быть некоторые задержки с событиями, появляющимися в базе данных. Я обновлю комментарий, если числа будут выровнены в ближайшие дни.

Изменить Как и обещал обновить, приборная панель не обновилась. У меня есть сильное ощущение, что "полученное" событие для уведомления о данных ненадежно.