FAQ
哪些平台支援WebPush?
按操作係統分類的瀏覽器支援
瀏覽器 | Windows PC | macOS | Android | iOS (iPhone, iPad) |
---|---|---|---|---|
Chrome | Yes | Yes | Yes | No |
Firefox | Yes | Yes | Yes | No |
Safari | No | Yes | No | Yes |
Microsoft Edge | Yes | Yes | No | No |
Opera | Yes | Yes | Yes | No |
註 1: Microsoft Edge(2019年更新)、Opera、三星瀏覽器、Yandex 和 UC 瀏覽器等都是基於 Chromium 的瀏覽器,在 Engagelab 中會被標記為 Chrome。
註 2: Internet Explorer 不再接受功能更新。微軟已將瀏覽器開發轉嚮 Edge 平台。
註 3: 隱身模式、私人瀏覽模式和訪客瀏覽器模式不支援網路推播。
按瀏覽器版本支援
瀏覽器 | Windows | macOS | Android |
---|---|---|---|
Chrome | Chrome 42+ | Chrome 42+ | Chrome 105+ |
Firefox | Firefox v44+ | Firefox v44+ | Firefox v104+ |
Apple Safari | / | Safari V11.1+ | / |
Opera | Opera v29+ | Opera v29+ | Opera mobile v64+ |
Microsoft Edge | Edge v17+ | Edge v17+ | / |
Safari 瀏覽器的 Web 推送通知相關問題
Safari 瀏覽器上的 Web 推送通知支援 macOS(V11.1+)以及 iOS / iPadOS 16.4+。
Safari 推送支援哪些功能特徵?
功能 | macOS (15-) | macOS (16+) | iOS/iPadOS 16.4+ |
---|---|---|---|
圖片 | 否 | 否 | 否 |
操作按鈕 | 否 | 否 | 否 |
啟動 URL | 是 | 是 | 是 |
自定義網站圖示 | 是 | 否 | 是 |
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 | macOS |
---|---|---|
Chrome | 是,需瀏覽器進程在後台 | 是,需瀏覽器進程在後台 |
Firefox | 是,需瀏覽器進程在後台 | 是,需瀏覽器進程在後台 |
Safari | / | 是 |
Opera | 是,需瀏覽器進程在後台 | 是,需瀏覽器進程在後台 |
Microsoft Edge | 是,需瀏覽器進程在後台 | 是,需瀏覽器進程在後台 |
在 Windows 上,所有視窗都關閉,瀏覽器若仍在後台運行,即可以收到係統通知,若瀏覽器進程已經被關閉,則不會收到係統通知。
在 Mac OS X 上,即使所有視窗都被關閉,大部分瀏覽器進程仍會在後台運行,即可以收到係統通知,若瀏覽器進程被強製退出,則不會收到係統通知。Safari 無需運行即可接收通知,因為它們會直接傳送到操作係統,用戶需要先註冊 Safari 通知,後續即使 Safari 完全關閉也能收到通知。
通知的有效期為 3 天,3 天後即永久丟失。 例如,假設用戶應該收到 Firefox 推播通知,但 Firefox 已關閉,如果用戶在 3 天內打開 Firefox,則用戶將僅收到最後一條未過期的推播通知;如果用戶在 3 天後打開 Firefox,將不會收到 3 天前傳送的推播通知。
通知授權提示相關問題
在用戶關閉網頁推送提示後,何時再次顯示提示?
如果用戶在原生權限提示上點擊"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、點選停止推播,將會收不到 Engagelab 推播訊息,需要刷新頁面
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的service worker會不會跟EngageLab WebPush的service worker衝突?
PWA(Progressive Web App)的service worker與EngageLab WebPush的service worker有可能會衝突,因為都運行在瀏覽器的背景下,且對於同一個源(origin)來說,通常只能有一個service worker處於激活狀態。
Service workers是一種腳本,由網站安裝在瀏覽器中,可以支持離線體驗、消息推送和背景同步等功能。因為service worker是在它們的作用範圍內控制頁面的,所以在同一個作用範圍下不能有多個service workers同時控制頁面。
如果你嘗試在同一個應用/域下註冊多個service workers,後面註冊的可能會取代前面的,或者當兩個service workers的作用範圍有重疊時,可能會出現衝突。這種衝突可能會導致預期之外的行為,例如消息推送可能只能通過一個channel正常工作。
為了避免這種衝突,你可以:
- 確保你只在應用中使用一個service worker。如果EngageLab提供的WebPush功能和你的PWA功能可以通過同一個service worker來實現,那麼最好將它們合併到一個service worker腳本中。
- 如果需要使用兩個獨立的service workers,你應當確保它們的作用範圍不重疊。這可以通過在註冊service worker時指定不同的作用範圍路徑來實現。
在實施之前,建議仔細閱讀相關文檔,並在開發和生產環境中進行充分的測試,以確保service workers能夠和諧共存,不會互相干擾。
為什麼不同瀏覽器,regid 會相同?
答:同一個應用程式配置的集成域名,同一個用戶 userStr,就會生成同一個 rid,與是否同一個瀏覽器無關
檢查是否是同一個用戶的方法如下:查看 html 源碼,找到初始化函數查看。
關於 User_string 用戶唯一標識說明
在初始化過程中,開發者必須提供一個唯一的字串(user_str),用於生成使用者的唯一標識碼(UID)。該UID用於推送通知的身份識別,並且與用戶的設備無關。
若使用者在多個瀏覽器或設備上使用相同的user_str進行訂閱,系統將認定其為同一使用者。新的訂閱資訊將替代舊的資訊,確保使用者在最後一次訂閱的設備上接收消息,以此避免同一使用者在多個設備上收到重複的消息。系統後台將為每個UID只保存最新的訂閱資訊。
使用者可以隨時取消訂閱,我們的SDK提供了相應的接口來實現這一功能。取消訂閱操作將解除UID與訂閱資訊之間的綁定,但不會改變瀏覽器的通知權限設定。
理論上,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();