FAQ

Which platforms support WebPush?

Browser support by operating system

Note 1: Microsoft Edge (updated in 2019), Opera, Samsung Internet, Yandex, and UC Browser are all browsers based on Chromium and are identified as Chrome within Engagelab.
Note 2: Internet Explorer no longer receives feature updates. Microsoft has shifted browser development to the Edge platform.
Note 3: Incognito mode, private browsing mode, and guest browser mode do not support web push notifications.

Supported by browser version

Safari Browser Web Push Notifications Related Questions

Web push notifications on Safari browser support macOS (V11.1+) as well as iOS/iPadOS 16.4+.

What features are supported by Safari push notifications?

How do users on iOS and iPadOS receive Safari web push notifications?

1. How can developers set up to allow users to receive web notifications in iOS/iPadOS 16.4+?

In iOS/iPadOS 16.4+, Web Push Notifications are available. However, a website must have the proper manifest file and be set with the correct attributes for notifications to work properly. Add the corresponding code to the html of the integration page:

Include the manifest file:

              
              {
    "$schema": "https://json.schemastore.org/web-manifest-combined.json",
    "display": "standalone",
    "start_url": "/webpush/index.html",
    "name": "Engagelab WebPush Example",
    "short_name": "Engagelab",
    "icons": [
        {
            "src": "/icon-large-cb438cac.png",
            "type": "image/png",
            "sizes": "1024x1024"
        }
    ]
}

            

2. In order for users to subscribe and receive mobile Safari Web push notifications, they must add the Web app to the home screen

To send mobile Safari Web push notifications (applicable to iOS and iPadOS 16.4+), the notification recipients need to perform the following actions:

• Visit your website using the Safari browser on a mobile Apple device with 16.4+.
• Tap the share button on the Safari browser of the mobile device.
• Tap the “Add to Home Screen” option.
• Save the application on the device.
• Open the application from the home screen.
• Subscribe to notifications (they must tap the subscribe button before the native permission prompt appears). These steps are necessary to receive mobile Web push notifications. As this interaction experience is relatively complex for end-users, you need to help your end-users understand the benefits of subscribing to notifications.

3. Add a banner notification on your website to guide users to "Add to Home Screen"

A banner can be added to your website to inform your end-users of the value of mobile Web push notifications and how to teach them to subscribe.
We recommend adding a banner to your website that displays on mobile Apple devices, guiding visitors to tap the share button and the "Add to Home Screen" option.
There is also a popular open-source project that can help you provide these guidelines to users:
Bottom banner example Github link: https://github.com/rajatsehgal/add-to-home-screen

If the browser is closed, can the user receive the notification?

• When you go through the engagelab channel, you must open the website to receive notifications.
• When you go through the system channel, you can receive notifications when you close the browser. Different platforms behave differently. For more information, see the following table:

On the Windows, all Windows are closed. If the browser is still running in the background, it can receive system notifications. If the browser process has been closed, it will not receive system notifications.

On the Mac OS X, even if all windows are closed, most browser processes will still run in the background, that is, they can receive system notifications. If the browser process is forced to exit, they will not receive system notifications. Safari can receive notifications without running, because they are sent directly to the operating system. Users need to register Safari notifications first, and then receive notifications even if Safari is completely disabled.

The notification is valid for 3 days and will be permanently lost after 3 days. For example, assume that the user should receive Firefox push notification but the Firefox is disabled. If the user opens the Firefox within 3 days, the user will receive only the last push notification that has not expired. If the user opens the Firefox after 3 days, the user will not receive the push notification sent three days ago.

Notification Authorization Prompt Related Questions

When will the prompt be displayed again after a user dismisses the web push prompt?

If a user clicks "Block" (Chrome), "Don't Allow" (Safari), or "Never Allow" (Firefox) on the native permission prompt, the website will not be able to send them prompts again unless the user goes through a multi-step process in the browser settings to subscribe or reset permissions. This is why it is recommended to use EngageLab prompts (go to settings).

Native Permission Prompt

A web push subscription requires a native browser permission prompt, and the native prompt is not customizable. It uses the language set in the user's browser settings. Only HTTPS websites can display native browser prompts.

Chrome: You have 3 chances to get the user to subscribe. After the user clicks "X" on the native prompt for the 3rd time, they will not receive prompts for a week. For more information on this Chrome feature, see here.
Firefox: Starting with Firefox 70, after a user clicks the "close" button, they need to click the small notification icon in the browser to receive prompts again. Moreover, for Firefox 72+, the native browser prompt has been blocked from displaying, for details, see here.
Safari: Similar to Firefox, a quieter UI has been added for users who typically refuse permissions, and automatic prompts for sites that have been denied push are also provided, Safari 12.1+

EngageLab Soft Prompt

Because the native pop-up only has one chance, if it is rejected by the user, the website will no longer be able to obtain authorization from the user, therefore EngageLab recommends that you use the 'soft prompt' method to obtain user authorization:
If a user clicks "Allow" or "Cancel" on the EngageLab prompt (go to settings Guide to apply) and is still not subscribed via the native prompt, the EngageLab prompt can pop up again.

• When a user clicks "Allow" on the EngageLab prompt, the native pop-up will be called out, but if the user clicks "Cancel" on the native prompt at this time, the EngageLab prompt will still pop up asking the user if they allow authorization of the website notification the next time they enter the website.
  
• When a user clicks "Allow" on the EngageLab prompt, the native pop-up will be called out, and if the user clicks "Allow" on the native prompt at this time, the user has authorized the website for web notification permissions; if the user clicks "Deny" on the native prompt at this time, the website will not be able to obtain authorization from the user again.
  
• When a user clicks "Cancel" on the EngageLab prompt, it can be judged that the user does not have the will to receive notifications from the website at this time, and if they are asked whether they accept website notification messages, it is likely to be refused, so we will not call out the native pop-up at this time, and the next time the user visits, the EngageLab prompt can ask the user's willingness to receive notifications again.

Troubleshooting methods for failure to receive notifications

1. Check the permission on the notification bar of the webpage.

2. Check whether the browser application notification permission is enabled. Windows notification settings:

• turn off focus assistance. For more information, see microsoft official documentation .
  
• Check Settings> Notifications and actions> turn on obtaining notifications from applications and other senders. Make sure that your site and browser are also enabled. For more information, see microsoft official documentation .
  

macOS notification settings:

• in System Preferences> Notifications> Chrome or the selected browser, make sure that allow notifications is turned on.
• In System Preferences> Notifications> Focus> Do Not Disturb and sleep, make sure this mode is not turned on or you are within the allowed notification time.
• macOS also has a temporary "do not disturb" notification setting in the upper-right corner menu> scroll up.

3. The browser manufacturer is unstable, so switching the Engagelab channel is preferred.

              
              {
    "from":"web_push",
    "to":{
        "registration_id":[
            "xxx"
        ]
    },
    "body":{
        "platform":"web",
        "notification":{
            "web":{
                "title":"web_push",
                "alert":"Hi,MTPush !",
                "url":"http://www.google.com",
                "extras":{
                    "web-key1":"web-value1"
                }
            }
        },
        "options":{
            "time_to_live":30,
            "third_party_channel":{
                "w3push":{
                    "distribution":"mtpush"
                }
            }
        },
        "request_id":"12345678",
        "custom_args":"business info"
    }
}

            

Can't the safari browser pop up a notification?

Step 1: Check the Safari browser permissions, note whether the allow switch is enabled , the normal situation is shown in the figure:

step 2: click Check push service status and browser Notification permission, the normal situation is shown in the figure:

Step 3: Click Safari browser - preferences click website - click notification to check whether the Notification Center website is allowed, the normal situation is shown in the figure.

note:

1. Click stop push, the Aurora push message will not be received, and the page needs to be refreshed.
   
2. A domain name is configured with multiple html pages. Do not remove the website permissions of the notification center. After the deletion, the html pages will not receive notifications. (You need to find the main page and obtain the website Notification permission again)
   

If the same user uses multiple browsers, how will a message be displayed on the user's device if sent to them?

If the chosen distribution strategy prioritizes system channels, then the message will only be sent through the browser manufacturer's channel that the user most recently used. If the option is to send exclusively through the Jiguang channel, then multiple messages will be sent.

If a user clears browser cache and cookies, can they still receive WebPush from this website?

When the user is online, the Jiguang channel can still receive push notifications.
For browser manufacturer channels, when users clear their browser's cookies and cache, they will unsubscribe from notifications. This is because the subscription user data is stored in the browser's IndexedDB storage. Removing this data will make the browser "forget" the subscriber. However, clearing this data does not remove the permissions that users have already granted to receive notifications in that browser. At this time, an initialization of the SDK is needed so that users are automatically resubscribed when they return to the website.
But if users change the browser's notification permissions to "Ask" or "Block," they will not be automatically resubscribed.
If users clear notifications from the browser's notification settings, they will also not be automatically resubscribed.

How to clear notifications in various browsers:

• Chrome: chrome://settings/content/notifications
  
• Firefox: about:preferences#privacy > Permissions > Notifications
• Safari: Preferences > Websites > Notifications > Remove !

When users resubscribe, they will receive a new Registration ID record. You can use window.MTpushInterface.getRegistrationID() to get the rid.

If multiple messages are sent to the same user at the same time, will all the messages be displayed?

The display mechanisms of messages can vary across different push channels:

• EngageLab channel: There is no overwrite mechanism, so if multiple messages are sent to the same user at the same time, all the messages will be displayed to the user simultaneously. The notification center will retain multiple messages; except for the most recent message, the others will be collapsed.
• Safari: There is no overwrite mechanism, so if multiple messages are sent to the same user at the same time, all the messages will be displayed to the user simultaneously. The notification center will retain multiple messages; except for the most recent message, the others will be collapsed.
• Chrome: There is an overwrite mechanism, so if multiple messages are sent to the same user at the same time, each notification will be replaced by the updated one, and only the last message sent will be displayed.
• Edge: There is an overwrite mechanism, so if multiple messages are sent to the same user at the same time, each notification will be replaced by the updated one, and only the last message sent will be displayed.
• Firefox: There is an overwrite mechanism, so if multiple messages are sent to the same user at the same time, each notification will be replaced by the updated one, and only the last message sent will be displayed.

Does EngageLab WebPush support changing domain names?

Browsers have set up Web Push in a way that binds subscribers to a specific source (domain name/website URL).
For security reasons and due to the browser's same-origin policy, browsers do not allow subscribers to be moved to another source. This is not a limitation of EngageLab; any service provider that claims to be able to move subscribers from one website to another, please make sure that they are subscribing to your website.
If you change your website, the best solution is to set up a new WebPush application for the new website and get your users to subscribe to the website under this new application. You cannot import subscribers from one source to another.
You can continue to send push notifications to subscribers of the old website (old WebPush application), but your users need to resubscribe to the new website to receive pushes from the new domain. The recommended steps for migration are as follows:

• Set up a new WebPush application for the new site domain.
  
• Continue to send pushes from the old WebPush application using the old site domain. In the notifications' "launch URL," use the new site domain.
  
• After 2 weeks to 2 months (depending on how many notifications you send per day and how many subscribers you get on the new website), you can stop using the old WebPush application and use only the new WebPush application.
  
• If you send the same message from both the old and new WebPush applications, subscribers under both will receive duplicate messages. This is why we recommend following these timeframes.
  
• You can send a few messages saying "We've moved, click here to visit our new website and resubscribe to stay updated." This will help to remind users that if they do not return to resubscribe, they may not receive pushes from your site. It is recommended to send such notifications at the beginning of the move and with the last message sent from the application.
  
• Unfortunately, all websites and audiences are different. Be prepared that you may lose some subscribers in the short term.
  When executing the above migration steps, make sure to pay attention to the user experience to avoid inconveniencing users.

Does EngageLab WebPush Support PWA Push Notifications?

1. What is PWA?

PWA push refers to the process of using Web Push technology in Progressive Web Apps (PWA) to send notifications to users. PWA is an application built using web technologies that offers similar functions and user experience to native applications, while also being accessible through a browser without the need for installation.
PWA push is implemented through the Web Push technology provided by browsers. Web Push technology allows web applications to send push notifications like native apps, even when the app is not active or completely closed.
Unlike traditional applications, PWAs do not need to be downloaded and installed from app stores; they can be directly accessed in a browser via a URL. Additionally, PWA push notifications provide timely message alerts to users, enhancing user experience and engagement.
In summary, PWA push is a method that uses Web Push technology to send notifications to users of progressive web applications, increasing user engagement and interaction and offering a user experience closer to that of native apps.

2. Does EngageLab WebPush Support PWA Push Notifications?

EngageLab WebPush service supports PWA push notifications. You need to integrate the Web Push functionality into your PWA using the Web SDK provided by EngageLab WebPush, following the sample code in the documentation to register the Service Worker and initialize the Web Push feature. Once integration is complete, you can use the EngageLab WebPush API to send push notifications to your PWA users.

Note: There are two necessary conditions for the WebSDK to support PWA:
1. The program runs in a browser that supports W3C notifications; 2. There is a specific domain name, and it uses the HTTPS protocol.

3. Will the PWA's service worker conflict with EngageLab WebPush's service worker?

The service worker of a Progressive Web App (PWA) and EngageLab WebPush's service worker could potentially conflict, as both operate in the background of the browser, and for the same origin, typically only one service worker can be active at a time.

Service workers are scripts installed by websites in the browser that can support offline experiences, message pushing, and background synchronization, among other features. Since a service worker controls pages within its scope, multiple service workers cannot control pages in the same scope simultaneously.

If you attempt to register multiple service workers within the same application/domain, the later registered service worker might replace the earlier one, or there could be conflicts when the scopes of two service workers overlap. Such conflicts might lead to unexpected behaviors, such as push messages only working correctly through one channel.

To avoid such conflicts, you can:

1. Ensure that you use only one service worker in your application. If the WebPush functionality provided by EngageLab and your PWA features can be implemented through the same service worker, it is best to merge them into one service worker script.

2. If you need to use two separate service workers, ensure that their scopes do not overlap. This can be achieved by specifying different scope paths when registering the service workers.

Before implementation, it is recommended to carefully read the relevant documentation and conduct thorough testing in both development and production environments to ensure that the service workers can coexist harmoniously without interfering with each other.

why do different browsers have the same regid?

A: If an integrated domain name configured for the same application is userStr by the same user, the same rid will be generated, regardless of whether the same browser is used.

About User Unique Identifier Explanation

1. During initialization, a unique string must be filled in to generate a unique UID. This UID is the identity recognition code for push notifications and is not related to the device.
   
   
2. When a user uses the same user_str, they will be recognized as the same user. Subscribing on different browsers or devices will replace the subscription information with the latest one for message sending. For example, User A subscribes with the same user_str on browsers a1, a2, and a3 in succession. In theory, only the last subscribed a3 can receive messages, preventing the same user from receiving multiple messages and excessive message sending. The backend always saves only the latest subscription information for the same UID.
   
   
3. Message subscriptions can be canceled, and the SDK provides a cancel subscription interface. This cancel subscription interface only cancels the binding relationship between UID and subscription information and does not modify the browser's notification permissions.
   
   
4. In theory, user_str should correspond one-to-one with actual users. In some specific situations, users may be in visitor mode. Developers need to explicitly generate a unique user_str based on their actual situation. The SDK does not automatically perform default processing to avoid errors in the process when developers have not properly handled the relationship between user_str and actual users, resulting in statistical data not matching the expected situation.

   When users are in visitor mode, developers can refer to the following function to generate a unique user_str. This function uses the user's browser as the unique identity recognition code. Note that this processing method will cause the same user to generate a new user_str when changing browsers, devices, or clearing cache.
   Sample function:

   function randomUid() { const keyStr = 'mtWebPushRandomUid'; let uid = window.localStorage.getItem(keyStr); if (!uid) { uid = new Date().getTime().toString(36) + Math.floor(Math.random() * 10000000).toString(36); window.localStorage.setItem(keyStr, uid); } return uid; } var user_str = randomUid();

                 
                 function randomUid() {
    const keyStr = 'mtWebPushRandomUid';
    let uid = window.localStorage.getItem(keyStr);
    if (!uid) {
        uid = new Date().getTime().toString(36) + Math.floor(Math.random() * 10000000).toString(36);
        window.localStorage.setItem(keyStr, uid);
    }
    return uid;
   }
   var user_str = randomUid();
   
               

   このコードブロックはフローティングウィンドウ内に表示されます