How to compute number of views for the push notifications sent?

[myupchar]

We have a large number of subscribers at https://www.myupchar.com/en but we are not sure how many successfully see it? Is there a way to track it?

We are seeing 10million+ subscribers and only 4-5K visits. If we can get a view count, it will greatly help

[nerdysherpas]

Sounds like you're looking for something that can do impression tracking. That's not specifically something to do with the W3 push-api. That said, to do so you'd want to just make a GET/POST to an external url when you are showing your push that handles that for you.

If you use something like simple like ProxyHook you'd do:

self.addEventListener('push', function(event) {
    let trackingUrl = 'https://go.proxyhook.com/123'; //use the endpoint they provide instead of 123 as that's just an example
    
    //optionally grab the event data from the push to further narrow down (e.g. contents or campaign)
    let payload = {};
    
    //primary analytics
    fetch(trackingUrl, {
        method: 'post',
        body: JSON.stringify(payload)
    });

    //show the push
    self.registration.showNotification('Title', {});
})

[collimarco]

A fetch inside the push event is unreliable. The push can be triggered even when connection is not available or it is unreliable. Also, the request written like that can be terminated before finishing...

There is a reason if the Push API now supports a payload: that was added later because downloading a payload via fetch was not reliable.

As for the reasons why a notification is successfully sent but not displayed to the end user, there can be many reasons:
https://pushpad.xyz/blog/why-some-web-push-notifications-are-not-delivered-to-the-browser

[webmaxru]

Hello!
@collimarco, I believe @myupchar is talking about tracking, not requesting content for the notification. In that case, calling analytics API inside push event is valid idea.

I'd improve @nerdysherpas code a bit to leverage waitUntil method to have better chance that the browser will not unload service worker earlier than needed

Example similar to the one from my "Web Push Notifications Done Right" session:

self.addEventListener('push', (event) => {
      notification = event.data.json();
      const analyticsPromise = ... // calling Analytics API
      const showNotificationPromise = self.registration.showNotification(
        notificationData.title,
        notificationData
      );
      const promiseChain = Promise.allSettled([
        analyticsPromise,
        showNotificationPromise,
      ]);
      event.waitUntil(promiseChain);
    });

@myupchar you can also get extra insights about interactions with your notifications by calling analytics API inside notificationclick and notificationclose events also available in the service worker.

[collimarco]

@webmaxru

calling analytics API inside push event is valid idea.

Does it also work in practice? A few years ago we had very poor/unreliable results... The explanation was that the "push" event can be processed even during a "power-saving" status where opening new connections may not work. Basically the connection used to receive the notifications on mobile has a special status.

Consider that the entire idea of the Push API is to save bandwidth/energy by using a single connection to fetch events about all websites and apps. If you open random connections to random hosts each time that you receive a message... I don't know if that is planned and if it works reliably.

[webmaxru]

@collimarco, I don't have any statistics on failed fetch-in-push ratio so can't really reason about reliability. But this approach is regular for Web Push delivery services. For example, SW by Pusher. And this analytics call is marked as "best efforts" there as well - confirming your concern.

If we develop this idea towards its robustness, we can leverage something similar to what was implemented in workbox-google-analytics module (that is unfortunately not compatible with GA 4+): all failed requests stored in IndexedDB and then "synced" using Background Sync API (that is not available on iOS though)