You can monitor web push notifications in different ways.
See the stats for a single notification
You can see detailed stats for each notification that you have sent from the Pushpad dashboard. Go to your project, then click Notifications and open a notification to see the details.
You can also fetch the stats with the REST API. When you send a notification, you get in response the new notification ID: you can use it later to fetch the notification stats. Otherwise you can also get all the notifications that you have recently sent.
For applications that integrate Pushpad through the API, it can be useful to log all the notifications sent:
- When you send a notification, you get in response the ID of the new notification
- Store the notification ID and other details in your application logs, so that you can search them later
Then, when you need to inspect a delivery of a message:
- Get the notification ID from your application logs
- Open the notification on Pushpad, so that you can see all the notification details and information about the delivery status. From the Pushpad dashboard go to your project, then click Notifications and enter the notification ID in the search field. You can also use the API if you prefer.
See aggregated stats for a project
You can see aggregated stats for your project from the Pushpad dashboard. Go to your project, then click Stats.
Create custom metrics and filter the project stats
If you send many notifications from the dashboard or even millions of notifications through the API, it becomes difficult to see the stats for each notification. In that case you must use the project stats, that aggregate the stats from multiple notifications. By default, there is one bucket where all the notification stats are collected. However you can easily create other buckets to aggregate the stats only from some notifications.
For example a newspaper may create the categories "sport" and "politics", then tag each notification with the appropriate category and finally compare the CTR of the different categories.
In order to aggregate the stats in custom categories you can follow these steps:
- Go to the project settings and enter the name of the new metric in the Custom metrics field. The name can only contain letters, digits and underscores and cannot be longer than 50 characters. You can create up to 50 metrics for a project.
- When you send a notification, enter the name of your metric in the Custom metrics field. Note that you can add up to 3 metrics for a single notification.
- Go to the project stats and select your metric. Basically you need to click No filter and select the name of your metric instead. In this way you will see only the stats for the notifications that were tagged with that metric name.
Pushpad collects detailed information about the delivery of each message. The following stats are available:
- Scheduled: it has a different meaning depending on context. For the project stats it represents the total number of notifications that you have sent (regardless of the delivery status). If you open the details of a single notification this metric represents the number of notifications that are in the Pushpad sending queue. Usually queues last at most a few seconds, however if you send millions of notifications in bulk, then a queue can last for some minutes. Sometimes you can also note that most notifications are reported as successfully sent immediately, while a small fraction of them takes more seconds to be processed: that means that Pushpad is performing automatic retries for some recipients.
- GCM Unauthorized: the number of deliveries that failed because the GCM API key is invalid. You can fix your GCM API key in the sender settings. This metric is only useful for legacy projects that use GCM.
- GCM Mismatch Sender ID: the number of deliveries that failed because the GCM API key belongs to a sender different from that of the subscriptions. You can fix your GCM API key in the sender settings so that it matches the GCM sender ID that you have used. This metric is only useful for legacy projects that use GCM.
- Expired: the number of subscriptions that have been deleted because they were expired. This usually happens when the users unsubscribe from notifications from the browser preferences.
- Invalid Push Service: the number of deliveries that failed because the browser push service is unknown or banned and thus Pushpad cannot communicate with it. This can also happen if you remove GCM or APNs from the sender settings.
- Invalid Subscription: the number of deliveries that failed because the browser push service (e.g. Mozilla autopush for Firefox, FCM for Chrome, WNS for Edge, Apple Push Notification service for Safari) reported that the subscription does not exist.
- Unsuccessful: the number of deliveries that failed for other reasons. You can contact support if you need more details.
- Successfully Sent: the number of notifications that were sent successfully by Pushpad to the browser push service (e.g. Mozilla autopush for Firefox, FCM for Chrome, WNS for Edge, Apple Push Notification service for Safari). This means that the browser push service confirms that the notification is successfully received and that it will try to deliver it to the end device as soon as the device becomes online.
- Delivered: the number of notifications that were received successfully by the device.
- Opened: the number of notifications that were clicked. This also includes any interaction with the action buttons.
- CTR: the Click-Through Rate is the ratio of users who click the notification to the number of total users who have received the notification. It is calculated as Opened / Delivered.
Notifications sent, but not delivered
For transparency, Pushpad reports both the number of notifications successfully sent and the number of notifications actually delivered to the user device. The number of deliveries is usually lower then the number of notifications sent. However that is not an issue related to Pushpad.
Basically notifications work like this:
- Pushpad sends a signal to the browser push service (Mozilla autopush for Firefox, FCM for Chrome, etc.) to notify that there are new notifications
- the browser push service (Mozilla autopush for Firefox, FCM for Chrome, etc.) sends that signal to the user browser
- the user browser connects to Pushpad to download the new notifications.
You can find more in the technical introduction to web push.
When a notification is marked as successfully sent but not delivered it means that the step 1 was successful, but the step 2 has not happened yet. That step isn't managed by Pushpad, but it is managed by the browser push service (Mozilla autopush for Firefox, FCM for Chrome, etc.) and by the user device. So in general we can't do anything about that.
A notification may not be delivered for various reasons, for example:
- the recipient device is turned off
- the recipient device has no internet connection
- the recipient device has airplane mode enabled
- the recipient device has power saving mode enabled
- the browser is closed (some browsers, mainly desktop browsers, need to be open in order to receive push notifications)
- the browser has not the right permissions to download data from the internet when the screen is locked (in that case the notification may be lost)
- the user unsubscribed from browser preferences, but the browser push service wasn't notified about that and thinks that the subscription is still valid
- the user doesn't use a given browser or device anymore (the browser push service will remove that subscription only after some months of inactivity)
- the browser push service (Mozilla autopush for Firefox, FCM for Chrome, etc.) crashes and loses some notifications
- the browser receives the signal, but the internet connection is lost when it tries to download the notifications from Pushpad
- a notification expires because of its TTL before it can reach the recipient device.
Note that the setting called Time To Live (TTL) can affect the delivery rate. You can set the TTL for notifications from the project settings or set it for specific notifications. Make sure to set the TTL to a large value, otherwise a notification will be dropped on purpose if it can't reach a device within that time.
Also note that the deliveries to Safari cannot be tracked (there's no way to do that): thus, even if the notifications are delivered successfully, they are still reported as not delivered in the stats.