FAQ

关于 User_string 用户唯一标识的说明

1. 在初始化过程中，开发者必须提供一个唯一的字符串（user_str），用于生成用户的唯一标识码（UID）。该UID用于推送通知的身份识别，并且与用户的设备无关。
   

2. 若用户在多个浏览器或设备上使用相同的user_str进行订阅，系统会认定其为同一用户。新的订阅信息将替代旧的信息，确保用户在最后一次订阅的设备/浏览器上接收消息。以此避免同一用户在多个设备/浏览器上收到重复的消息。系统后台会为每个UID只保存最新的订阅信息。
   

3. 用户可以随时取消订阅，我们的SDK提供了相应的接口来实现这一功能。取消订阅操作将解除UID与订阅信息之间的绑定，但不会改变浏览器的通知权限设置。
   

4. 理论上，user_str应当与用户账户一一对应。在某些场景下，用户可能处于访客模式，此时开发者需要根据实际情况生成一个唯一的user_str。我们的SDK不会自动处理这一步骤，避免因user_str处理不当而导致统计数据不准确。
   

对于访客模式的用户，开发者可以使用以下示例函数来生成一个基于用户浏览器唯一性的user_str。但请注意，这种处理方式可能导致用户在更换浏览器、设备或清除缓存后，会生成一个新的user_str。
示例函数

          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();

        

哪些平台支持 WebPush？

按操作系统分类的浏览器支持

注 1： Microsoft Edge（2019年更新）、Opera、三星浏览器、Yandex 和 UC 浏览器等都是基于 Chromium 的浏览器，在 Engagelab 中会被标记为 Chrome。
注 2： Internet Explorer 不再接受功能更新。微软已将浏览器开发转向 Edge 平台。
注 3： 隐身模式、私人浏览模式和访客浏览器模式不支持网络推播。

按浏览器版本支持

Safari 浏览器的 Web 推送通知相关问题

Safari 浏览器上的 Web 推送通知支持 macOS（V11.1+）以及 iOS / iPadOS 16.4+。

Safari 推送支持哪些功能特征？

iOS 和 iPadOS 上的用户如何收到 Safari 网络推送通知？

1. 开发者如何设置才能让用户在iOS/iPadOS 16.4+中接收web通知？

在 iOS/iPadOS 16.4+ 中，可以使用 Web 推送通知。但是，网站必须具有适当的清单文件，并设置了正确的属性才能使通知正常工作。对应集成页面的html添加对应代码：“

引入清单文件：

          {
    "$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. 为了让用户订阅并接收移动 Safari Web 推送通知，他们必须将 Web 应用添加到主屏幕

发送移动 Safari Web 推送通知（适用于 iOS 和 iPadOS 16.4+）需要通知接收者执行以下操作：

• 在 16.4+ 的移动 Apple 设备上使用 Safari 浏览器访问您的网站。
• 点击移动设备上 Safari 浏览器的分享按钮。
• 点击“添加到主屏幕”选项。
• 保存设备上的应用程序。
• 从主屏幕打开应用程序。
• 订阅通知（在显示原生权限提示之前，他们必须点击订阅按钮）。 这些步骤是接收移动 Web 推送通知所必需的。 由于这个交互体验对于终端用户来说是比较复杂的，因此您需要帮助您的终端用户了解订阅通知的好处。

3. 在您的网站上添加横幅通知引导用户将应用“添加到主屏幕”

可以在您的网站上添加横幅，以告知您的终端用户移动 Web 推送通知的价值以及如何教他们如何订阅。
我们建议在您的网站上添加横幅，该横幅在移动 Apple 设备上显示，引导访问者点击分享按钮和“添加到主屏幕”选项。
还有一个热门的开源项目可以帮助您为用户提供这些指引：
底部横幅示例 Github 链接：https://github.com/rajatsehgal/add-to-home-screen

如果关闭浏览器，用户能收到通知吗？

• 走 engagelab 通道时，需要打开网站时才可以收到通知。
• 走系统通道时，可以在关闭浏览器时收到通知，其中不同平台上的行为不同，详情参见下表：

在 Windows 上，所有窗口都关闭，浏览器若仍在后台运行，即可以收到系统通知，若浏览器进程已经被关闭，则不会收到系统通知。
在 Mac OS X 上，即使所有窗口都被关闭，大部分浏览器进程仍会在后台运行，即可以收到系统通知，若浏览器进程被强制退出，则不会收到系统通知。Safari 无需运行即可接收通知，因为它们会直接发送到操作系统，用户需要先注册 Safari 通知，后续即使 Safari 完全关闭也能收到通知。

通知授权提示相关问题

在用户关闭网页推送提示后，何时再次显示提示？

如果用户在原生权限提示上点击"Block"（Chrome）、"Don't Allow"（Safari）或"Never Allow"（Firefox），则该网站将无法再次向他们发送提示，除非用户通过浏览器设置进行多步骤操作来订阅或重置权限。这就是为什么建议使用 EngageLab 提示（前往设置）的原因。

原生权限提示

Web 推送订阅需要本机浏览器权限提示，并且原生权限提示不可自定义。它使用用户浏览器设置中设置的语言。只有 HTTPS 网站可以显示本机浏览器原生提示。

Chrome ：您有 3 次机会让用户订阅，当用户在原生权限提示上点击第 3 次“X”后，用户将在一周内不再收到提示。有关这个 Chrome 功能的更多信息，请参阅此处。
Firefox ：从 Firefox 70 开始，当用户点击“关闭”按钮后，他们需要点击浏览器中的小通知图标才能再次收到提示。此外，对于 Firefox 72+，原生浏览器提示已被阻止显示，有关详细信息，请参阅此处。
Safari ：跟firefox一样，添加了一个更安静的 UI，用于提示通常拒绝权限的用户，并自动提示被拒绝推送的网站，Safari 12.1+

EngageLab软提示

因为原生弹窗只有一次机会，如果被用户拒绝了，网站将无法再次向用户获取授权，因此EngageLab推荐您使用「软提示」的方式来获得用户授权：
如果用户在 EngageLab 提示 （前往设置Guide to apply）上点击“允许”或“取消”，并且仍未通过原生提示弹窗订阅， EngageLab 提示 可以再次弹出。

• 用户在EngageLab 提示上点击"允许Allow"后，原生弹窗会被调出，但若用户此时在原生提示上点击"取消"，用户下次进入网站时EngageLab 提示仍然会弹窗询问用户是否允许授权该网站通知。
  
• 用户在EngageLab 提示上点击"允许Allow"后，原生弹窗会被调出，若用户此时在原生提示上点击“允许”，用户就授权了该网站进行web通知的权限；若用户此时在原生提示上点击“拒绝”，网站将无法再次向用户获得授权。
  
• 用户在EngageLab 提示上点击“取消”时，则可以判断为用户此时没有接收该网站通知的意愿，如果此时询问用户是否接收网站通知消息很可能被拒绝，所以我们此时不会调出原生弹窗，待下次用户访问的时候可再次通过EngageLab 提示询问用户接收通知的意愿。

通知收不到排查方式

1. 检查网页通知栏权限开启情况

2. 检查浏览器应用通知权限开启情况
Windows 通知设置：

• 关闭焦点辅助，详情参考 微软官方文档。
• 检查设置>通知和操作> 打开从应用程序和其他发件人获取通知。确保您的站点和浏览器也已启用。本文中的更多詳細信息参考 微软官方文档。

macOS 通知设置：

• 在“系统偏好设置”>“通知”>“Chrome”或所选浏览器中，确保“允许通知”已打开。
• 在“系统偏好设置”>“通知”>“焦点”>“请勿打扰和睡眠”中，确保此模式未打开或您在允许通知的时间内。
• macOS 在右上角菜单 > 向上滚动中也有临时的“请勿打扰”通知设置。

3. 浏览器厂商不稳定，切换 Engagelab 通道优先下发

          {
    "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"
    }
}

        

safari 浏览器无法弹出通知？

第一步：请检查 Safari 浏览器权限，注意允许开关是否开启，正常情况如图：

第二步：点击检查推送服务状态与浏览器通知权限，正常情况如图：

第三步：点击 Safari 浏览器 - 偏好设置

点击网站-点击通知，查看通知中心网站是否允许，正常情况如图：

特别注意： 1、点击停止推送，将会收不到极光推送消息，需要刷新页面 2、一个域名配置了多个 html 页面，请不要移除通知中心的网站权限，移除后 html 页面都将收不到通知（需用户找到主页面，重新获取网站通知权限）

如果同一个用户同时使用多个浏览器，给该用户下发一条消息，用户设备会如何展示？

如果选择是下发策略是系统通道优先，则这条消息只会通过该用户最近一次使用的浏览器厂商通道下发。如果选择仅通过极光通道下发，则会下发多条。

如果用户清除浏览器缓存和 Cookie了，还能接收到这个网站的WebPush吗？

用户在线的时候，极光通道仍然可以收到推送。
对于浏览器厂商通道来说，当用户清除浏览器的 Cookie 和缓存时，他们将取消订阅通知。这是因为订阅用户数据存储在浏览器的 IndexedDB 存储中。移除该数据会使浏览器“忘记”订阅者。但是清除这些数据并不会移除用户已经授权在该浏览器中接收通知的权限，这个时候需要进行初始化SDK的操作，让用户在返回网站时自动重新订阅。
但如果用户将浏览器的通知权限更改为“询问”或“阻止”，他们将不会被自动重新订阅。
如果用户从浏览器的通知设置中清除通知，他们也不会被自动重新订阅。

各浏览器清除通知的方式：

• Chrome：chrome://settings/content/notifications
  

• Firefox：about:preferences#privacy > 权限 > 通知
  

• Safari：首选项 > 网站 > 通知 > 删除

当用户重新订阅时，他们将获得一个新的Registration ID 记录。您可以使用window.MTpushInterface.getRegistrationID() 来获得rid。

同一时间给同一个用户发送多条消息，消息都会展示吗？

不同推送通道消息展示机制会有所差别：
EngageLab通道：无覆盖机制，同一时间给同一用户发送多条消息，多条消息会同时展示给用户。通知中心会保留多条消息，除最近一条消息，其他消息会折叠。
safari：无覆盖机制，同一时间给同一用户发送多条消息，多条消息会同时展示给用户。通知中心会保留多条消息，除最近一条消息，其他消息会折叠。
Chrome：有覆盖机制，同一时间给同一用户发送多条消息，每个通知将被更新的通知替换，仅会展示最后一条发出的消息。
edge：有覆盖机制，同一时间给同一用户发送多条消息，每个通知将被更新的通知替换，仅会展示最后一条发出的消息。
firefox：有覆盖机制，同一时间给同一用户发送多条消息，每个通知将被更新的通知替换，仅会展示最后一条发出的消息。

EngageLab WebPush支持更换域名吗？

浏览器已经以一种将订阅者绑定到特定源（域名/网站URL）的方式设置了Web Push。
出于安全原因和浏览器的同源策略，浏览器不允许将订阅者移动到其他源。这不是EngageLab的限制，任何声称可以将订阅者从一个网站移动到另一个网站的服务商，请务必确认他们正在订阅的是您的网站。
如果您更改了网站，最好的解决方案是为新网站设置一个新的WebPush应用，并让您的用户在此新应用下订阅网站，您无法将订阅者从一个源导入到另一个源。
您可以继续向旧网站（旧WebPush应用）的订阅者发送推送通知，但您的用户需要重新订阅新网站才能从新域名接收推送。迁移的推荐步骤如下：

• 为新站点域名设置一个新的WebPush应用。
  
• 使用旧站点域名继续从旧WebPush应用发送推送。在通知的“启动URL”中，使用新站点域名。
  
• 在2周到2个月之后（具体取决于您每天发送多少通知以及在新网站上获得多少订阅者），您可以停止使用旧的WebPush应用，仅使用新的WebPush应用。
  
• 如果您从旧的WebPush应用和新的WebPush应用发送相同的消息，那么在两者之下的订阅者将收到重复的消息。这就是为什么我们建议遵循这些时间框架。
  
• 您可以发送几条“我们已经搬迁，点击这里访问我们的新网站并重新订阅以保持更新”的消息。这将有助于提醒用户，如果他们不返回重新订阅，可能无法从您的网站收到推送。建议在搬迁开始时和从应用发送的最后一条消息时发送此类通知。
  
• 不幸的是，所有网站和用户群都有所不同。请做好短期内可能会失去订阅者的准备。
  在执行上述迁移步骤时，请务必注意用户体验，以免给用户带来不便。

EngageLab WebPush支持PWA推送吗？

1.什么是PWA?

PWA推送是指在渐进式Web应用程序（Progressive Web App，简称PWA）中使用Web Push技术向用户推送通知的过程。PWA是一种使用Web技术构建的应用程序，具有类似原生应用程序的功能和用户体验，同时可以通过浏览器进行访问，无需安装。
PWA推送是通过浏览器提供的Web Push技术实现的。Web Push技术使得Web应用程序可以像原生应用程序一样发送推送通知，即使应用程序不在活动状态或完全关闭。
与传统的应用程序不同，PWA不需要从应用商店下载和安装，可以通过URL在浏览器中直接访问。同时，PWA推送可以向用户提供及时的消息提醒，增强用户体验和参与度。
总之，PWA推送是一种使用Web Push技术向渐进式Web应用程序用户发送通知的方法，可以提高用户参与度和互动性，为Web应用程序提供更接近原生应用程序的用户体验。

2.EngageLab WebPush支持PWA推送吗？

EngageLab WebPush服务支持PWA推送，您需要使用EngageLab WebPush提供的Web SDK将Web Push功能集成到您的PWA应用程序中，并按照文档中提供的示例代码来注册Service Worker并初始化Web Push功能。一旦集成完成，您就可以使用EngageLab WebPush的API来向您的PWA应用程序用户发送推送通知了。

注：websdk支持PWA的两个必要条件：
1程序运行在在浏览器中，且浏览器支持w3c notifications；2.有一个具体的域名，且是https协议。

3.PWA的server work会不会跟EngageLab WebPush的server work冲突？

PWA（Progressive Web App）的 service worker 和 EngageLab WebPush 的 service worker 有可能会冲突，因为都运行在浏览器的背景下，且对于同一个源（origin）来说，通常只能有一个service worker处于激活状态。

Service workers 是一种脚本，由网站安装在浏览器中，可以支持离线体验、消息推送和背景同步等功能。因为 service worker 是在它们的作用域内控制页面的，所以在同一个作用域下不能有多个 service workers 同时控制页面。

如果你尝试在同一个应用/域下注册多个 service workers，后面注册的可能会取代前面的，或者当两个 service workers 的作用域有重叠时，可能会出现冲突。这种冲突可能会导致预期之外的行为，例如消息推送可能只能通过一个 channel 正常工作。

为了避免这种冲突，你可以：

1. 确保你只在应用中使用一个 service worker。如果 EngageLab 提供的 WebPush 功能和你的 PWA 功能可以通过同一个 service worker 来实现，那么最好将它们合并到一个 service worker 脚本中。

2. 如果需要使用两个独立的 service workers，你应当确保它们的作用域不重叠。这可以通过在注册 service worker 时指定不同的作用域路径来实现。

在实施之前，建议仔细阅读相关文档，并在开发和生产环境中进行充分的测试，以确保 service workers 能够和谐共存，不会互相干扰。

为什么不同浏览器，registration ID 会相同？

答：同一个应用配置的集成域名，同一个用户 userStr，就会生成同一个 rid，与是否同一个浏览器无关

• 检查是否是同一个用户的方法如下：查看 html 源码，找到初始化函数查看。