If you mean browser Push API and you want delivery tracking (knowing whether a push was actually delivered/shown/opened), the key limitation is:

The Web Push / Push API does not provide true end-to-end delivery receipts by itself.

What you can track depends on which step you care about:

1) Subscription status

You can know whether the browser has an active subscription.

• When user subscribes, store the endpoint, p256dh, auth on your server.
• If send fails with 410 Gone / 404, subscription is likely invalid.

2) Send attempt status

Your backend can track whether the push service accepted the message.

• Send push to the push service endpoint (FCM for Chrome, Mozilla autopush, etc.)
• If the HTTP response is successful, the push service accepted it.
• This is not the same as delivered to the device or shown to the user.

3) Delivery to browser/device

There is no universal, reliable browser-level callback saying “this push reached the browser.”

Possible approximations:

• Use push TTL and server response codes.
• If the browser is online and service worker receives the push, you can send a beacon/fetch back to your server from the push event to log “received by service worker.”
• This still only means the service worker got it, not that the notification was displayed.

4) Notification shown

If your service worker calls showNotification(), you can treat that as “displayed” locally, but it’s still not a cryptographic delivery receipt.

Example:

self.addEventListener('push', event => {
  const data = event.data?.json() || {};
  event.waitUntil((async () => {
    await self.registration.showNotification(data.title, {
      body: data.body,
      tag: data.tag
    });

    // Best-effort tracking back to server
    await fetch('/push-events', {
      method: 'POST',
      headers: {'Content-Type': 'application/json'},
      body: JSON.stringify({ type: 'shown', id: data.id })
    });
  })());
});

5) Notification click / open tracking

This is the most reliable user-action metric.

self.addEventListener('notificationclick', event => {
  const id = event.notification.data?.id;
  event.notification.close();

  event.waitUntil((async () => {
    await fetch('/push-events', {
      method: 'POST',
      headers: {'Content-Type': 'application/json'},
      body: JSON.stringify({ type: 'clicked', id })
    });
    clients.openWindow('/');
  })());
});

---

Practical “delivery tracking” pattern

Most systems implement a funnel:

1. Queued on server
2. Accepted by push service
3. Received by service worker
4. Shown as notification
5. Clicked/opened by user

You can track 2–5 with your own backend events, but only step 2 is guaranteed by the push service, and steps 3–5 require cooperation from the client/service worker.

---

Important caveats

• The browser may be offline or sleeping; delivery can be delayed.
• Some pushes may be collapsed/throttled.
• Some browsers enforce quiet UI or battery-saving behavior.
• If the user disables notifications, you may still get push events, but notification display can fail or be suppressed depending on browser rules.

---

If you want, I can provide:

• a complete Web Push implementation with delivery/open tracking
• backend examples in Node.js / PHP / Python
• a database schema for push status tracking
• a service worker example with receipts