 | 交接通訊協定 |
Messenger 平台的交接通訊協定可在兩個或以上的應用程式之間傳遞對話控制權，讓這些應用程式能夠參與對話。Facebook 專頁訂閱的應用程式會自動啟用交接通訊協定。
請注意：對話指派現已推出，將於不久後取代交接通訊協定。您應盡快更新應用程式，以使用對話指派。
運作方式
Facebook 專頁或 Instagram 專業帳戶可以使用多個通訊應用程式，來與顧客或對其內容感興趣的用戶交流通訊。以顧客支援為例，系統首先可能將顧客傳送至自動化體驗，但如果這類體驗無法解決顧客的問題，系統可以將顧客傳送至有即時支援服務人員提供協助的另一個應用程式。如要將對話和有關對話的中繼資料從一個應用程式轉移到另一個應用程式，或者在應用程式和 Facebook 專頁收件匣或 Instagram 收件匣之間轉移，您必須將對話控制權從一個應用程式傳遞到另一個應用程式。交接通訊協定正正支援此轉移程序。
預設情況下，當顧客傳送訊息以開始對話時，對話處於閒置狀態。Webhooks 會向應用程式傳送通知，說明應用程式已收到訊息且正在等待回覆。如要接收此通知，應用程式需要被訂閱特定交接 Webhooks。
所有應用程式都可以在對話處於閒置狀態時控制對話。控制對話的應用程式具有回覆訊息的專屬功能。不過，每次只有一個應用程式具有控制權，其他應用程式需等到控制中的應用程式釋出控制權後，才能傳送訊息。應用程式釋出控制權後，對話就會恢復閒置狀態，然後下一個應用程式便可開始控制。
控制對話的應用程式會收到來自通訊 Webhooks 的通知，而所有其他應用程式則會收到來自特定交接 Webhooks 的通知。
若對話在 24 小時內沒有收到任何動態，便會自動恢復閒置狀態。如有需要，控制中的應用程式可以將控制權時限延長至 24 小時以上。
如果沒有對話控制權的應用程式嘗試向用戶傳送訊息，系統便會傳回 400 錯誤代碼，其中錯誤子代碼為 2018300。
主要接收者
如果您希望在收到訊息時交由特定的應用程式處理，可以將此應用程式指派為主要接收者。主要接收者會接收對話中的所有新訊息、可以將控制權轉移到另一個應用程式或 Facebook 專頁收件匣或 Instagram 收件匣，並且能夠在需要時從另一個應用程式取回對話控制權。當非主要接收者應用程式完成對話並釋出控制權後，對話會設定為閒置。
如果用戶在對話處於閒置狀態時傳送新訊息至您的專頁或帳戶，主要接收者將持有對話的控制權，並且會收到關於新訊息的 Webhook 通知。
備註：您不一定要設定主要接收者。
收件匣
您不能將 Facebook 專頁收件匣或 Instagram 收件匣指派為主要接收者。但是，如果您將訊息移動到「主要」資料夾或在不受收件匣控制的對話中回覆訊息，則收件匣會取得對話控制權。如果您回覆收件匣中被標記為完成的訊息，則控制權仍屬於先前控制中的應用程式或主要接收者（若已設定），或者會遭釋出並處於閒置狀態。
對話進入點
在使用 Messenger 發訊廣告（CTM）對話進入點時，您可將有關對話指派給特定的應用程式。企業可使用 CTM 開始與顧客對話，以實現開發潛在顧客、提高品牌知名度等目的。
常駐選單
除非設定了主要接收者，否則所有應用程式都可設定專頁級別選單。如果已設定主要應用程式，則只有主要應用程式才能設定或刪除專頁級別選單。
擁有對話控制權的應用程式可以設定或刪除用戶級別選單（即使該應用程式並非主要接收者），且任何應用程式都可在對話閒置時設定用戶級別選單。
當顧客從選單中選擇項目時，建立選單的應用程式將控制對話。這是因為建立選單的應用程式獲配置為負責處理該資料。
回傳呼籲字句
當顧客點擊回傳呼籲字句（CTA）時，建立回傳呼籲字句的應用程式將獲得對話控制權，即使另一個應用程式正在控制對話亦不例外。這是因為建立回傳呼籲字句的應用程式獲配置為負責處理該資料。
顧客問卷調查
如果在另一個應用程式控制對話時傳送問卷調查，則在應用程式釋出控制權且對話處於閒置狀態前，問卷調查無法送達。
元件
如要為 Facebook 專頁已訂閱的訊息應用程式成功實施交接通訊協定，則需要以下元件。
存取憑證
如要呼叫交接通訊協定端點，將需要用到專頁存取憑證；此憑證應由可以在專頁上執行 MODERATE 任務的用戶要求獲取。
應用程式審查
符合以下描述的應用程式需要接受應用程式審查：
- 使用者為沒有應用程式角色的用戶
- 允許真人服務人員回覆顧客
真人服務人員功能
即使應用程式沒有對話控制權，只要該應用程式已透過應用程式審查獲准使用真人服務人員功能，便仍然能夠向用戶傳送訊息，而且有關訊息會附有真人服務人員標籤。沒有對話控制權的應用程式只能在此情況下傳送訊息。
權限
應用程式需要具備 pages_messaging 權限，才能要求顧客提供權限以存取訊息收發資料。
Webhooks
在交接通訊協定中，應用程式需訂閱兩組 Webhooks，即通訊 Webhooks 和備用 Webhooks。應用程式接收的通知類型視乎對話控制權而定。如果應用程式控制著對話，便會收到通訊 Webhooks 通知。如果應用程式並非控制著對話，便會收到備用 Webhooks 通知。
常見用途
顧客支援
企業使用一個應用程式提供自動化體驗以解答常見問題，但如果自動化體驗未能解決顧客的問題，則系統會將顧客轉移到另一個應用程式以獲得即時支援。自動化應用程式會被設為主要接收者，從而擁有所有對話的控制權。當即時支援服務人員需要加入對話時，即時支援應用程式可以要求獲得對話控制權。當網上服務人員應用程式完成對話後，對話控制權便會釋回給自動化應用程式。如果網上服務人員應用程式需要更多時間來處理顧客的問題，則該應用程式可以申請延期。以上兩個應用程式都應訂閱 Webhooks，從而確保對話正常推進。
營銷活動：商品潛在顧客
企業展開營銷活動並借助自動化體驗來找出符合條件的潛在顧客，或根據商品小測驗結果推薦商品。找出符合條件的潛在顧客後，企業使用 Facebook 專頁收件匣或 Instagram 收件匣跟進潛在顧客情況。自動化應用程式會被設為主要接收者，從而擁有所有對話的控制權。待自動化應用程式找出符合條件的潛在顧客後，對話控制權便會傳遞給 Facebook 專頁收件匣或 Instagram 收件匣。一旦在 Facebook 專頁收件匣或 Instagram 收件匣中完成對話後，系統便會將對話標記為完成。此操作會把對話控制權釋出給主要應用程式。以上兩個應用程式都應訂閱 Webhooks，從而確保對話正常推進。
營銷活動：Messenger 發訊廣告
企業展開營銷活動並將潛在顧客傳送至自動化應用程式，以提供特定的 Messenger 體驗。自動化應用程式會被設為主要接收者，從而擁有所有對話的控制權。當即時支援服務人員需要加入對話時，即時支援應用程式可以要求獲得對話控制權。當網上服務人員應用程式完成對話後，對話控制權便會釋回給自動化應用程式。如果網上服務人員應用程式需要更多時間來處理顧客的問題，則該應用程式可以申請延期。以上兩個應用程式都應訂閱 Webhooks，從而確保對話正常推進。
最佳操作實例
- 我們建議將自動化體驗設定為主要接收者應用程式，並將任何網上服務人員應用程式設定為非主要應用程式。同時，我們建議使用網上服務人員應用程式來監察備用事件，並僅在必要時採取行動。
- 一律使用「取得對話串控制權 API」來確認您是否擁有對話串的控制權，然後根據情況呼叫其他 API。如果沒有控制權，則不要插入或中斷對話。
- 請確保在有其他應用程式控制對話時，不要嘗試向對話串傳送訊息。如果您的應用程式為主要應用程式，請僅在必要時使用「接管對話串控制權 API」。如果是非緊急情況或您使用的是非主要應用程式，請要求對話串控制權。
- 確保在所有可能的情況下都重視來自任何其他應用程式的要求對話串控制權事件，並將對話串控制權傳遞給提出要求的應用程式。如果您出於任何原因而無法立即傳遞對話串控制權，請使用「傳遞中繼資料 API」向提出要求的應用程式提供額外背景資訊，並在您完成操作後優先向其傳遞對話串控制權。
- 如果您已完成對話相關操作，請將對話串控制權傳遞給先前提出要求且仍在序列中的應用程式，或者釋出對話串控制權以處於閒置狀態，以便任何其他應用程式接管對話串。如不按此操作，則會導致對話串自動從您的應用程式釋出，並在 24 小時後進入閒置模式。對這種情況進行編碼，其相關狀態也會有相應變更。
- 如果您透過呼叫「取得對話串控制權 API」而注意到對話串處於閒置狀態，請使用「要求對話串控制權」來控制對話串，以便您在不中斷的情況下向用戶傳送獨有訊息，並在完成後釋出控制權。