high-MPS模式的引入

high-MPS Mode？

MPS是Messages per second，我個人非常確信這是在F8前不久才默默的出現在Messenger的文件中，當時其實一直很不解這是什麼意思，儘管到現在我也還是不清楚臉書引入這限制的決策思考是什麼，那什麼是high-MPS模式呢？

簡言之就是，如果你的聊天機器人在短時間內且持續性的發生大量地訊息發送與接收（目前在Changelog上寫的是40 MPS，也就是每秒發生40次），你的聊天機器人就會被臉書自動的切換成high-MPS模式，在此模式下，用來訂閱變成聊天機器人的粉絲專頁收件匣（Page Inbox）以及Conversation API會被臉書切換成disabled的狀態 ，聊天機器人的開發者必須自行透過Messenger API來處理，也就是說若你的Page被切換成high-MPS模式，你就得在Webhook端自行的將用戶與Bot間收發的訊息記錄起來，並自行撰寫Inbox或是某種紀錄系統來供使用者後續的查閱。

一般守法的聊天機器人其實很難達到這樣的每秒訊息收發數量，但有很多電商很喜歡濫用收集來的大量PSID去透過Messenger的Send API進行大量行銷訊息的推送，而要在短時間內完成大量PSID的推送需要將要推送的訊息與PSID先寫入Queue中，然後開啟多個workers去Queue中將要推送的訊息讀取出來對Messenger的Send API做parallel的請求，在Push Notification的campaign進行時，一次只發送一條訊息給某個PSID就算了，常見的Push Notification往往是多條訊息組成一次的推送，因此PSID的量一大，就很容易觸及到40 MPS的這一個high-MPS門檻，我記得Messenger API早期在文件中的MPS是60，因此新的架構下，訊息收發的門檻是朝緊縮的方向前進的。

另外，在high-MPS模式下，Broadcast API將解除每一次信息推送最多只能有10,000位接收者（10,000 PSID）的限制，反之，若你的Page並不處於high-MPS模式下，記得要好好控制你訊息推送時custom label所關聯的PSID數量。

最後還要注意的是，Broadcast API每分鐘最多只能呼叫十次，也就是說，極限來看，透過Broadcast API你每分鐘最多可以送出訊息給100,000組PSIDs，正常情境來說這似乎非常堪用😘

手動自high-MPS Mode切換回非high-MPS Mode的控制元件

不過臉書在F8之後，在粉絲團的Messenger Platform設定中新增了一個手動切換回非high-MPS模式的控制元件，若您的Page因為持續性的大量訊息收發而被臉書切換進入high-MPS模式時，可以在這邊手動的將其切換為來，但是根據該控制元件上的說明，一但Page被切換成為high-MPS模式，儘管能夠透過這一控制元件將其切換回來，但未來這個Page將會被套用上更嚴格的Rate limit

由於我這個測試用的Page沒有被切換成high-MPS mode，因此按下去Learn More時只會跳出如下的說明文字

所有Page自Graph API v3.3+開始必須透過申請通過Page-level subscription權限才能使用強大的Broadcast API（BTW，此API已經結束Beta狀態）

雖然Broadcast API非常的難用且限制很多，但是他擁有以下幾點好處

1. 可以在短時間內完成大量PSID的訊息推送（透過臉書的Infra來發送，比飛雷神還快）
2. 可以設定精準的排程去做訊息發送
3. 可以透過Custom Label去組織PSID來進行Targeting Broadcast，可多組custom label去交集受眾、排除接收訊息的受眾

要使用Broadcast API，粉絲團必須要進行”pages_messaging_subscriptions“權限的送審，送審的地方在 Page > Settings > Messenger Platform > Advanced Messaging Features 這個設定區塊裡，如果你送審通過的話，就會像我的這一個粉絲團，顯示為賞心悅目的綠色勾勾

反之，就會如下圖顯示

你要點擊”Request”這個按鈕去開啟送審頁面，如下圖，去進行”Page-level subscription permission”的送審流程

由於”page_messaging_subscriptions”這個權限已經完全的從App-level轉移到Page-level，所以目前還在用第三方SaaS進行訊息推送的聊天機器人大多是取巧的透過Message Tags的機制來越過Messenger 24+1訊息發送規則去進行大量的行銷訊息推送，建議儘速停止這樣的做法，並根據符合您自身商業邏輯的特性去撰寫Page-level subscription權限的送審表單，不過，儘管你成功的申請到Page-level subscription的權限也是不行用它來進行行銷訊息的推送，強烈建議你遵守24+1以及Subscription Messeger的遊戲規則，否則臉書將會在多次違規之後對你的粉絲團進行封鎖的懲罰（已經有多家電商透過第三方SaaS濫發行銷訊息的推送而遭停權了）。

Messing Insight API中的”page_messages_active_threads_unique”以及”page_messages_reported_conversations_by_report_type_unique”兩個成效指標已經在Graph API v3.3+中移除了

基本上，不知道有多少人在使用這組API提供的資料，大多數第三方SaaS也都沒怎麼看到呈現這邊給出去的指標（？），不過就注意一下有哪些成效指標已經被deprecated掉就好，免得發出API請求時發出Exception。

read_page_mailboxes權限將被deprecated並被pages_messaging所取代

“read_page_mailboxes“是台灣人最愛用的留言轉私訊（或是+1 / pm轉私訊）功能所必要的一個權限，在Graph API v3.3+開始將被deprecated，以後要做這種行銷操作，Facebook的App必須要送審通過pages_messaging這組權限，不過這應該是好事，畢竟申請pages_messaging權限不需要錄影上傳，只要給App Reviewer幾組能夠在Bot內產生作用的問與答範例就好（切記！Bot要真的能夠回答送審範例句中的問題呦），不然像是之前要送審”read_page_mailboxes“這一權限還得附上全程操作的錄影病加上一大堆的操作步驟說明，今後要實作這功能就不需要額外再跑一次App Review流程了。

Page Webhooks中的conversations欄位要被deprecated掉了

這其實影響不大，畢竟這邊收到的資料跟Messenger Platform的messages webhook事件所收到的資料基本上是一模一樣的，透過這次進行API的簡化也挺合理的。

小結

總的來說，在F8前後，Messenger各項相關的API並沒有太大與令人興奮的新功能被發佈出來，不過，可以看得出來的是，Facebook在各項既有API上所做的調整，包含high-MPS模式的引入以及訂閱權限從App level移轉到Page level在大方向上是會讓這個平台朝著更一個更健康的方向發展的，就讓我們持續的期待在接下來的幾季裡，在The future is private的大戰略下，Messenger平台將推出的各項新功能（手好癢）