Web push notifications allow you to maintain communication with customers through a web browser. The unobtrusive character of web push notifications will keep your message away from spam folders or ad blocking software. The notifications will always be displayed to users who have agreed to receive them. The following combinations of operating systems and browsers are supported for web push notifications: - Windows: Chrome, Edge, Firefox, Opera - macOS: Firefox, Chrome, Edge, Opera - Android: Chrome, Samsung Internet, Firefox, Brave
Incognito Mode, Private Browsing Mode, and Guest Browser Mode do not support Web Push.
## Benefits --- - Good way of increasing the number of your subscribers - users more eagerly agree to receive web push notifications rather than share their email address. - Great deliverability in real time - Good engaging results as directing traffic to a particular URL is only one click away - Good way to increase the traffic (for example, with a catchy notification title) - Good way to increase conversion as users can subscribe to web push notification to be informed about the product availability or discounts - The possibility of personalizing content of notifications by using Jinjava variables (such as the first name of the user, the number of collected loyalty points, and so on). ## Examples of use --- See examples in [web push notification use cases](/use-cases/?ordering=DESC&sortBy=publishDate&filters=tags%3D%3D"web+push") ## Anatomy of web pushes --- A web push notification consists of the following elements:
An example of a simple web push notification
An example of a simple web push notification
| No. | Web push element | Function | Recommendations & possibilities | |-----|------------------|--------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 1. | **Title** | This is the top text of your notification | - We suggest a 50-character limit to avoid being cut off, but the length depends on the browser
- You can personalize the title using [inserts](/developers/inserts/webpush) and emojis | | 2. | **Message** | This is the main content of your notification | - We suggest a 100-character limit to avoid being cut off, but the length of the text vary across different browsers
- You can personalize the message using [inserts](/developers/inserts/webpush) and emojis | | 3. | **Icon** | An icon helps in brand recognition | - We recommended using a size of 192x192
- To use an icon in the notification, upload the icon first in **Synerise > Data Modeling Hub > File**. | | 4. | **Large image** | On macOS, it serves as an expanded icon, while on Windows and Android, it acts as a custom image | - Make sure to follow the [image requirements](/docs/campaign/Webpush/creating-webpush-templates#image-requirements) for optimal display
- To use a large image in the notification, upload the image first in **Synerise > Data Modeling Hub > File** | | 5. | **Action buttons** | They redirect users to a URL you indicate | - You can add up to 2 action buttons
- You can personalize the text on the button by using [inserts](/developers/inserts/webpush) and emojis
-You can add [inserts](/developers/inserts/webpush) to the URL
| | 6. | **Close button** | This button closes notification. The browser adds a close button to the notification. | n/a | | 7. | **Domain** | The domain is automatically included in the notification. | n/a | | 8. | **Browser badge** | The browser defines the browser badge. | n/a | ## Requirements --- - [Integrate with Synerise JS SDK](/docs/settings/tool/tracking_codes) - Create an account in Firebase - [Integrate Firebase with Synerise](/docs/settings/tool/firebase) - [Enable web push notifications in Synerise](/docs/campaign/Webpush/configuring-web-push#install-service-worker) - [Prepare an agreement form](/docs/campaign/Webpush/one-step-agreement-form) ## How it works --- Synerise uses Firebase Cloud Messaging (FCM) as a platform for real-time messaging and data exchange between servers and client applications. The process starts when Synerise sends messages to FCM, which manages the delivery of notifications to customers' browsers. To facilitate this process, the Firebase SDK is integrated through the JS SDK to generate a unique customer token. This token is then shared between Synerise and FCM. FCM dispatches messages to customers with assigned FCM tokens. To display these messages in a browser, a service worker acts as a kind of proxy between the browser and the network, allowing for the interception and management of network requests, caching of files for offline use, and receiving web push messages from a server. Then, if a customer has provided consent for receiving web push notifications through a browser pop-up, the notification will be presented to the customer.
Overview of the process of sending a web push
Overview of the process of sending a web push
### FCM token An FCM token is a unique identifier which lets mobile and web applications receive messages from Firebase Cloud Messaging. It is generated by Firebase SDK and saved in the browser's storage. The token is also sent to FCM and to Synerise together with UUID of a customer who agreed to receive web push notifications through a browser's [agreement form](#marketing-agreement). Tokens can be generated only when all the following conditions are met: - Synerise and Firebase are integrated - Web push notifications are enabled in the Synerise platform - The service worker has been implemented into a website - A customer agreed to receive web push notifications ### FCM token as attribute in Synerise The status of a profile's FCM token is stored in the `snrs_has_web_push_devices` attribute. When the token is assigned, the value is `true`. This attribute is available: - on the customer's card in **Synerise > Behavioral Data Hub > Profiles**, this way you can see the status of this attribute for each customer - for use in Decision Hub ### Token TTL Tokens generated by FCM for web push notifications remain valid until the customer revokes notification permissions or clears the browser/application data. In case when the token is inactive for 270 days, it is expired (change introduced by Google Firebase since May 15, 2024). Every time a new token is generated for a customer, the [`webpush.tokenUpdate` event](/docs/assets/events/event-reference/webpush#webpushtokenupdate) is generated and added to the activity list on their card in **Profiles**. #### Discrepancies between the number of customers with FCM token and the actual number of recipients of the notification Differences may occur between the number of customers who have an FCM token in Synerise and the actual number of recipients who receive notifications. This is because Synerise isn't notified immediately when a customer withdraws an agreement in the browser settings or clears browser data and at the moment of sending, all the conditions in Synerise are still met. After a failed delivery, [`webpush.notRegistered`](/docs/assets/events/event-reference/webpush#webpushnotregistered) and [`webpush.tokenDelete`](/docs/assets/events/event-reference/webpush#webpushtokendelete) events are generated. As a result, the `snrs_has_web_push_devices` attribute is set to false, but the marketing agreement status remains unchanged. The table below provides information what happens while [customer profiles are merged](/developers/api/clients/profiles/merging-profiles). The table contains only allowed merging combinations and each mention of `agreement` refers to the [web push marketing agreement](#marketing-agreement). ### FCM token migration Token migration is a process in which the assignment of a FCM token is transferred from one user to another, along with associated changes in web push marketing consent. This migration occurs when a customer context changes in the browser, such as when a user logs out and a new user logs in, causing the FCM token to be reassigned to the new user or when [customer profiles are merged](/developers/api/clients/profiles/merging-profiles). 1. **An anonymous customer is recognized** Token and marketing agreement will not change because the UUID of the customer is still the same. This customer can receive web push notifications. 2. **A customer context changes in the browser** - In the following scenario, both customers will not receive web push notification: 1. A customer is logged in as `john.doe@example.com` (further referred to as John Doe) in the browser. This customer has been assigned a Firebase Cloud Messaging (FCM) token and his marketing consent is enabled. 2. John Doe logs out. 3. `anna.smith@example.com` (further referred to as Anna Smith) logs in (the customer context in the browser changes). A new user, Anna Smith, has been added, and the FCM token that was previously assigned to John Doe is now passed to Anna Smith. 3. Anna Smith now has the FCM token, but her web push marketing consent is disabled. To receive web push notification, Anna must enable her agreement through an [agreement form](/docs/campaign/Webpush/two-step-agreement-form). 4. When attempting to send a web push notification to John Doe, the value of the `snrs_has_web_push_devices` attribute is changed from true to false, the marketing consent remains unchanged. 3. **Customers are merged** The table below provides information what happens while [customer profiles are merged](/developers/api/clients/profiles/merging-profiles). The table contains only allowed merging combinations and each mention of `agreement` refers to the [web push marketing agreement](#marketing-agreement). | Column: Source profile Row: Target profile | From: Anonymous, agreement disabled | From: Anonymous, agreement enabled | |---------------------------------------------|-------------------------------------------------------------------------|-------------------------------------------------------------------------| | To: Recognized, agreement enabled | Result: After merging the profiles, agreement is **enabled**. The token remains the same. | Result: After merging the profiles, agreement is **enabled**. The token from the recognized profile is kept. | | To: Recognized, agreement disabled | Result: After merging the profiles, agreement is **disabled**. There is no token. | Result: After merging the profiles, agreement is **disabled**. The token from the anonymous customer is rejected. | ### Marketing agreement Marketing consent is the permission in the browser to receive notifications. The customer can provide such consent through the native window displayed at the top of the page. The agreement is stored in the `receive_webpush_messages` attribute (this is the backend name of the attribute) which can be found in the profile card, in the Subscription section:
The Subscriptions section on a profile card
The Subscriptions section on a profile card
You can prepare such an agreement in Synerise, more information about that is in [Prepare an agreement form](/docs/campaign/Webpush/one-step-agreement-form) article. ### Marketing agreement across multiple browsers Customers will receive web push notifications on any browser where they have consented to receiving them. If customers have provided consent on multiple browsers, they may receive the same web push notification on each of those browsers. ### Events related to web push notifications As a result of implementing JS SDK, various types of events are automatically generated. These events can be triggered by both the customer's actions (such as clicking on the notification or dismissing the web push consent) and by the infrastructure (such as failed notification delivery due to invalid Firebase tokens or exceeding message limits). By analyzing these events, you can measure the effectiveness of your messages and their deliverability. See [default events associated with web push notifications](/docs/assets/events/event-reference/webpush). ## Creating web push --- 1. Define the recipients of the web push notification. 2. Prepare the content of the web push notification (web push templates). 3. Schedule the web push notification. 4. Define the UTM parameters. ## Sending methods --- Web push notifications are sent in two ways: 1. Automatically by using [Automation Hub](/docs/automation). In response to customer activity, update of profile data, or other events (check the list of [triggers](/docs/automation/triggers) that start a workflow), a web push notification can be sent to customers. 2. Manually by clicking the **Send** button while creating web push notification. ## Web push status --- The status of web push communication is available on the list of web push notifications. In the [Communication statuses](/docs/campaign/statuses) article, you can check the statuses which can be assigned to web push communication.