Audience: Client developers integrating Zixflow SDK (Web)
Purpose: Track push notification lifecycle events — delivery, open, and action clicks — so Zixflow can measure campaign performance accurately. See also: Web Push Notifications and the reference implementation
sw.js.
Why Push Tracking Matters
When Zixflow sends a push notification to a user’s device, it records that the notification was sent. But it cannot know on its own:- Did the notification actually arrive on the device?
- Did the user open it (tap the banner)?
- Did the user tap an action button (“Shop Now”, “Remind Me”)?
The Delivery Lifecycle at a Glance
Note: trackMetric is not available in a service worker context — call the Zixflow HTTP API directly from your service worker.
The Push Payload
Zixflow injects two special fields into every push notification’s data payload. Your app uses these to associate the tracking event with the correct campaign delivery.
Example raw data payload received by the app:
Important:action_buttonsis a JSON string (not a nested object). Parse it withJSON.parsebefore use.
The Three Tracking Events
1. Delivery Confirmed
Event name (sent to Zixflow):Push Notification DeliveredWhen to fire: The moment the push data payload arrives on the device — inside your service worker
push event handler.What happens: Zixflow updates the campaign delivery record to
delivered. No profile event is stored.
2. Notification Opened
Event name (sent to Zixflow):Push Notification OpenedWhen to fire: When the user taps the notification banner. Fire for both body taps and action button taps.
What happens: Zixflow updates the campaign delivery record to
opened. No profile event is stored.
3. Action Button Clicked
Event name (sent to Zixflow):Push Notification Action ClickedWhen to fire: When the user taps a named action button. Always fire Opened first, then fire this event.
What happens: Zixflow records a
clicked delivery report and captures which button was tapped for campaign analytics.
Properties:
Platform-Specific Integration
Token Registration
Track Delivery (Service Worker — push event)
Track Open (Service Worker — notificationclick event)
Action Buttons Format
Theaction_buttons field in the push payload is a JSON-encoded string containing an array of button objects. You must parse it before use.
Payload value (raw string):
- Maximum 2 buttons per notification (Chrome/desktop browsers support up to 2 actions)
deeplinkmay be an empty string — handle gracefully, don’t navigate to a blank URL- Button index is 0-based
Parsing action_buttons
Building the Buttons on the Notification
actions array and show a plain notification.
Handling the Tap (End-to-End)
Deep Link Handling
The service worker can’t render an in-app screen directly — it either focuses/navigates an existing tab or opens a new one. Route to your SPA’s own client-side router by opening the URL as-is:- If an action button was tapped → use
action_buttons[index].deeplink - If body was tapped → use
deeplink_url - If neither is set → open app to default screen
Write Key via SDK_CONFIG
Prefer receiving the write key from the WebPush plugin (not a hardcoded constant):Setting User ID
Afteranalytics.identify():
Decision Flowchart
Fallback Behaviour (No Zixflow-Delivery-ID)
If the push notification was sent by a non-Zixflow source,Zixflow-Delivery-ID and Zixflow-Delivery-Token will be absent from the payload.
In this case, skip tracking with reserved event names. Push notification event names are reserved for Zixflow’s delivery pipeline — they are not stored as user profile events.