部分中斷share-external
開發人員常見問題
Account Kit

如果發生類似「抱歉,有些地方出錯了」的錯誤,並且難以確定原因,您可以選擇啟用更詳細的錯誤訊息,或許可以顯示更實用的資訊。 如需深入瞭解該 SDK init() 方法的偵錯旗標,請參閱 https://developers.facebook.com/docs/accountkit/webjs/reference

當 Android 用戶輸入的電話號碼符合其在 Facebook 列出的電話號碼時,Account Kit 即時驗證會略過以簡訊取得驗證碼的步驟。

只有在用戶使用 Android 版 Facebook 應用程式時,這才可行。如果我們無法確認電話號碼是否相符,會將用戶導入一般流程,並透過簡訊收到驗證碼。

對於以下名單中的語言,Account Kit 會顯示本地化 UI:https://developers.facebook.com/docs/accountkit/languages

不可以,我們僅支援透過 https://sdk.accountkit.com/en_US/sdk.js 連結該 JS SDK。此指令碼會擷取 SDK 載入程式,後者會從 accountkit.com 或瀏覽器快取中載入最新的 SDK。

若想透過您自己的伺服器代管 SDK,寬限存留期為 24 小時。在此寬限期後,SDK 會開始發出警告,然後在 7 天後停止運作。

請將 enableSendToFacebook 參數(iOS)或 setFacebookNotificationsEnabled(Android)設定為 true。

如果無法傳送簡訊,並且用戶使用的電話號碼是與其 Facebook 帳號連結的主要電話號碼,則登入您應用程式的用戶會透過 Facebook 通知收到確認訊息。

您將需要新增 INTERNET 權限,才能呼叫 API 方法。此外,您還可以選擇新增其他權限,讓登入程序更為順暢:

  • 如需存取簡訊,請新增 RECEIVE_SMSREAD_PHONE_STATE 權限。
  • 如需使用電子郵件功能,請新增 GET_ACCOUNTS 權限。

如需深入瞭解如何將 Account Kit 整合至 Android 應用程式,請參閱此處

Android SDK

用戶開啟行動分享對話方塊或行動版動態對話方塊後,卻以取消的方式關閉對話方塊時,您的應用程式就會透過 onSuccess() 回呼方法收到此通知。 您可以將 onSuccess() 回呼視為一種機制,表示對話方塊已透過某種方式成功關閉,但是您無法將其用來確認是否實際發佈了某些內容。 如果用戶也將「publish_actions」權限範圍授予您的應用程式,就會在取消時叫用 onCancel() 回呼方法。

若要查看 FacebookCallback 類別的完整詳情,請參閱參考文件

原生的「讚」按鈕(LikeView)運作方式與網頁型「讚」按鈕完全一樣。因為隱私問題,多數基於 Facebook 的網址都無法使用。但 Facebook 粉絲專頁和 Facebook 的首頁除外。

您可以使用「讚」按鈕預覽程式進行初步檢查。

這個情況有其目的。我們收到了很多垃圾訊息檢舉以及看到濫用此功能的情況,為了改善整體用戶體驗,我們決定強制執行這項變更。

這裡說明了更適合 Android 的分享方式。

應用程式審查

We’ve moved all Messenger permissions to the Permissions and Features page.

We've consolidated this into one Permissions and Features page for Business apps, where you can see what access levels you have for each permission and feature.

Yes, developers may opt out of the Business app type and return to the previous App Review process for their app by selecting “Change App Type” on the App Dashboard. However, developers may not opt back into the Business app type and will need to create a new app to do so.

Additionally, apps previously in Development Mode that opt out to the legacy experience that have been approved for Advanced Access via App Review in the new model will lose access to data beyond what their business or anyone with a role on their app owns until they turn their app to Live Mode.

We have replaced Development and Live Mode with Standard and Advanced Access. Standard Access is always active and allows you to access data that a developer’s business or anyone with a role on their app owns. You may submit for App Review for permissions and features to access data owned by other businesses or people. Refer to our Access Levels document to learn more.

Business apps designed to help businesses and organizations manage Pages, Groups, Events, Ads, and ad-related assets.

您的應用程式獲得權限後又喪失,原因如下:
  • 應用程式已移至其他尚未認證的商家。我們已封鎖先前所有批准的權限。
    • 如果之後應用程式又移回已驗證的商家,我們會取消封鎖權限。
  • 應用程式已標示為為其他商家提供服務,但之後已移至尚未驗證的其他商家。

Yes, ALL apps that leverage permissions that require review (Pages API, Groups API, Events API, Business Manager API, Instagram Graph API, Messenger Platform, extended Facebook Login permissions, Marketing API and Lead Ads API) must submit for app review in adherence with the communicated deadlines.

Active apps that leverage permissions with an August 1st deadline (Pages API, Groups API, Events API, Business Manager API, Instagram Graph API, Messenger Platform, extended Facebook Login permissions) and have not yet proactively submitted for review will be auto-enrolled in the review process. You can accelerate the App Review process by submitting your app for review prior to auto-enrollment. This will give you more control over when your app is reviewed and what information is used for the review.

如需詳細資訊,請參閱這個頁面。您可以在程序中提供所需權限的詳細資料,並且說明權限的用途。Facebook 將審查使用案例,並且判斷我們的政策是否接受您所提出的用途。權限審查結束後,視 API/權限而定,我們可能會另外提出要求,例如商家驗證及簽約。

是否需要接受應用程式審查,取決於應用程式編號層級。使用這些權限或功能的個別應用程式,皆須提交進行審查。

Yes, if your apps have made calls to the Graph API in the last 28 days as of July 31, 2018 and require access to the reviewable permissions with an August 1st deadline, your app will be auto-enrolled in the app review process. We will notify you when we have a process available to send us the additional information needed to complete the review process.

As we announced earlier this year, all apps accessing the Pages API, Groups API, Events API, Business Manager API, Instagram Graph API, Messenger Platform, and Facebook Login were expected to submit for app review by August 1.

To help protect the integrity of our platform, we have removed API access for apps that require these permissions, have not gone through app review, and have not been active within the last 28 days as of July 31, 2018. If you still need access to our APIs, we encourage you to submit for review through your app's App Dashboard.

All active apps that require these permissions will be auto-enrolled in app review in the coming weeks. Developers will be notified if we require additional information to complete the app review submission. If responses are not received in the allocated timeframe, reviewable API access will be disabled.

如果您目前提交審查的申請案件,要求額外的資訊,則從收到這個要求開始,您將會有 30 天的時間來處理和重新提交審查內容。在這 30 天的期間,應用程式審查團隊可能會要求您提供更多的資訊。請注意,在這 30 天的期間,每次重新提交不會重設這 30 天的時間計算。

若要測試新功能或權限,在審查和發佈應用程式後,請使用應用程式主控板中的建立測試版應用程式功能建立正式版應用程式的複製。在正式版應用程式的主控板內,點擊左上方瀏覽窗格中應用程式名稱旁的向下箭頭,然後點擊建立測試版應用程式。應用程式複製(狀態為開發中)允許所有應用程式角色存取所有功能和權限。

如果用戶端也是應用程式的「擁有者」,他們自己會以直接開發人員的身分進行該程序。如果用戶端是以第三方開發人員作為應用程式的「擁有者」,則由該開發人員進行審查。

您將需要申請 leads_retrievalpages_manage_ads 權限。

您可以提供整合的螢幕錄影檔案。假如您的應用程式不包含終端用戶體驗,則可提供至少 2 張螢幕截圖,以呈現頁面、CRM 或企業管理平台的設定畫面。此外,若您有透過上述產品管理粉絲專頁,也可提供該粉絲專頁的編號。您可以點選這裡詳讀更多資訊。

應用程式審查程序適用於需要特定 API 權限的應用程式。您可以到這裡詳閱必須接受審查的權限。若只設定 SDK,並不需要接受應用程式審查。不過,SDK 確實能讓應用程式呼叫 Facebook API,倘若是必須接受審查的 API,則應用程式也需提交進行應用程式審查。

如果您已擁有一個企業管理平台帳號,建議您將應用程式連結到現有的企業管理平台。

如果有多個屬於該企業的企業管理平台帳號,建議您判斷擁有多個企業管理平台帳號是否合理,並將應用程式與最合適的企業管理平台連結。如果企業透過企業管理平台設定信用額度,建議您將應用程式與具有該信用額度的企業管理平台連結。

若有其他設定資料、許可名單、測試用戶檔案資料希望供我們使用,我們會允許開發人員提供特定的測試用戶。若開發人員未提供,我們會使用自己的測試用戶。此欄位應為選用項目,不能因為此欄未完成而封鎖對方。

每個應用程式都必須接受應用程式審查。建議您進入應用程式主控板中查看須審查權限的具體清單。

每個企業管理平台都要完成一次商家驗證。如果選擇將您的應用程式全數歸在同一個企業管理平台之下,則只需要進行一次商家驗證。

應用程式應連結至最終擁有該應用程式的企業管理平台,且該企業管理平台須能存取該應用程式所產生的資料。應接受商家驗證程序的就是這家企業。

您隨時可以在應用程式主控板的應用程式審查索引標籤中查看企業驗證面板,來瞭解企業驗證與合約的狀態,以及所要執行的步驟。我們將會在過程中發送通知給您,告知您需要採取的動作。

You need to initiate app review before August 1, 2018 for these APIs: Pages API, Groups API, Events API, Instagram Platform API, Messenger Platform, Business Manager API, and Facebook Login.

You need to initiate App Review before February 1, 2019 for these APIs and features: the Marketing API and the Lead Ads Retrieval feature.

目前我們的作業量增加,整個程序約需數週。

  • 權限審查可能需要數週。請到這裡參閱最新的時間表更新資訊。
  • 商家驗證約需幾天的作業時間,但實際情況因文件品質而異。
  • 待您指定的主管簽署合約後,即可完成簽約。

在審查程序中,我們可能會向您詢問諸如企業法定名稱、地址和電話號碼等企業資訊。此外,我們可能會請您提供水電費帳單、執照、設立登記證或公司章程之類的企業文件。

2018 年 8 月 1 日起,只需驗證應用程式所連線的企業管理平台即可。

有新的 API 時,您需要透過應用程式審查提出申請。不過每個企業管理平台實體只需要進行一次商家驗證,因此如果應用程式需要新的權限或 API 時,不需再進行一次商家驗證。

所有呼叫「Facebook 登入」延伸權限的現有應用程式和 6 個 API(粉絲專頁、Messenger、企業管理平台、Instagram、社團和事件)都需要提交到新的應用程式審查程序,程序包括企業管理平台驗證和合約簽署。不需在此日期之前完成應用程式審查,只要提交即可。如果未在 2018 年 8 月 1 日之前提交,2018 年 8 月 2 日將失去對這些 API 的存取權限。

所有呼叫行銷 API 和名單型廣告擷取 API 的現有應用程式都必須提交到新的應用程式審查程序,程序包括 2019 年 2 月 1 日之前必須完成的企業管理平台驗證和合約簽署。

請前往此頁面瞭解詳情。審查時,請詳述應用程式需要哪些權限,並說明權限使用方式。Facebook 會審查權限使用案例,判定使用方式是否合乎我們的政策。審查權限後,我們可能會根據 API╱權限的不同提出其他要求,像是企業管理平台驗證和合約簽署。

每家企業僅需驗證一次,合約也僅需由指定人員代表企業簽署一次。後續提交的應用程式須完成應用程式審查,但不必驗證。

應用程式是否需要審查,應視應用程式的編號層級決定。使用特定權限或功能的每個應用程式都必須接受審查。

我們在 2018 年 5 月 1 日宣佈了新的應用程式審查程序,凡使用 Facebook 登入權限和以下 6 種 API 的應用程式皆須接受審查:粉絲專頁、Messenger、企業管理平台、Instagram、社團、活動。使用上述 API╱權限者須在 2018 年 8 月 1 日前提交應用程式審查,才能保有 API 存取權限。

2018 年 7 月 2 日,我們宣佈了更多需接受應用程式審查的 API,即行銷 API 和名單型廣告擷取。使用上述 API 者須在 2019 年 2 月 1 日前提交應用程式審查,才能保有存取權限。有關提交的最後期限,請參閱這裡

審查程序期間,我們的審查團隊會依照您的指示,重現權限在您應用程式內的使用方式。如果我們無法重現此體驗,例如,因為我們無法遵循您的指示或者無法登入您的應用程式,那麼我們也無法批准您的提交資料。

若要避免此問題,請:

  • 提供使用該權限且為可運作版本的應用程式
  • 確定您在「新增備註」區塊提供明確的指示
  • 確定所要求的登入權限可將用戶體驗個人化,而且符合我們的原則

特別是對於 publish_actions 權限,請確認您的應用程式發佈功能設定正確。在審查程序期間,我們需要能夠將您的應用程式內容發佈回 Facebook。

應用程式審查程序涉及在每個支援的平台上載入您的應用程式、使用 Facebook 登入,以及在審查中使用您要求的每個 Facebook 整合。這經常會導致我們所說的「一般問題」。一般問題指的是與載入您的應用程式、登入您的應用程式,或者您應用程式的一般功能相關的錯誤或故障。這表示我們無法測試您在提交資料中要求的權限。

由於這些問題會導致我們無法審查您的 Facebook 功能,我們無法詳細針對應用程式如何使用您提交審查的 Facebook 功能作出評論。因此,我們以「一般問題」拒絕,並就每個平台對此提供意見回饋。

如果您因為「一般問題」而遭到拒絕,請仔細閱讀所有意見回饋。每個平台都會收到個別意見回饋,說明審查中遇到的問題。

您收到的審查回應將包含您的應用程式未獲得批准的明確說明,以及接下來應採取的步驟。我們希望您盡快通過此程序,因此請仔細閱讀此意見回饋。您完成必要變更後,即可以重新提交審查。

如果您的應用程式以不會獲得批准的方式使用權限,您收到的意見回饋中會包含相關說明,且不應重新提交審查。

若要通過應用程式中心的批准,您的應用程式必須符合我們的資格要求。符合 Facebook 應用程式中心資格的應用程式,必須使用「Facebook 登入」或具有 Facebook 全螢幕互動廣告應用程式。

符合資格可列於應用程式中心的應用程式如下:

您的文字資產和宣傳圖像也必須符合我們的準則

如果您使用「分享」對話方塊或任何其他社交外掛程式將內容發佈回到 Facebook,則不需要提交審查。如果您仍然不確定,您可以在我們的一般審查文件找到更多資訊。

獎勵用戶使用社交外掛程式或者在粉絲專頁按讚違反開放平台政策第 4.5 節的規定。其中包括根據用戶是否在粉絲專頁按讚來提供獎勵,或對應用程式或應用程式內容設限。用於這種目的 user_likes 不會獲批准。

為了確保優質關係以及協助企業觸及重要用戶,我們希望用戶是因為想進一步聯繫或者取得企業資訊才對粉絲專頁按讚,而不是為了人為的獎勵。我們相信這項政策能夠讓用戶以及廣告商都獲益。

我們的審查團隊可能需要其他登入憑證才能夠登入您的應用程式,以完成審查。

如果您的應用程式在「Facebook 登入」之前或之後需要輔助登入,請確定您已提供該登入所需的用戶名稱和密碼。這可能包含測試或示範伺服器所需的登入憑證,以及您的應用程式或電子郵件註冊流程所需的輔助登入。

位於預備或開發伺服器上的應用程式可能需要進一步登入,才能夠存取您的伺服器。請同時針對此項作業提供所有必要的登入憑證。

如果您仍然不確定遺漏哪些憑證,您可以在下次提交時提供影片,在影片中包含您想提交審查的「Facebook 登入」選項和所有相關的 Facebook 整合。

我們的審查團隊需要登入您的應用程式並檢查所有 Facebook 整合,才能夠批准您的應用程式提交資料。

如果審查人員無法載入或使用您的應用程式,請檢查以下事項:

  • 應用程式網址可公開存取而且未設定為 localhost
  • 您已經提供存取您的開發或預備網站所需的用戶名稱和密碼
  • 您的網站具有最新的安全憑證,而且對新用戶不會造成錯誤
  • 您能夠以新建的測試用戶身分登入和使用您的應用程式
  • 您提交審查的項目已開發完成而且已在您的應用程式中運作

如果您因相同原因再度遭到拒絕,請更新審查指示新增備註區塊,要求審查人員提供更明確的說明以及其他資訊。

螢幕錄影是導覽應用程式功能,以及說明您會如何運用所要求權限的絕佳方式。請參閱此連結,瞭解錄製螢幕錄影的最佳作法和第三方資源。

提供的影片應該顯示您的應用程式如何使用所要求的每個權限。如果您有要求 publish_actions,影片還應該顯示如何從您的應用程式建立內容然後分享至 Facebook。

為即時遊戲建立的 Facebook 應用程式編號無法用於其他平台。您可以在我們的文件中取得更多資訊。

我們的審查團隊將使用您提供的指示來測試您應用程式的 Facebook 整合。

如果您認為應用程式審查沒有通過的決議有誤,您應該更新審查指示,提供更多資訊給審查員,然後重新申請審查。

最佳的作法是,更新備註以處理收到的審查意見回饋,然後透過審查程序與審查員進行溝通。

我們的審查團隊在審查提交資料時會使用多位測試用戶,不會只使用您提供的測試用戶。如果您的提交資料不需要使用特定測試用戶進行審查,請在審查指示中告訴我們。

如果您提供測試用戶,請確定您已正確建立測試用戶並在提交資料中附上該用戶。

否。權限一旦獲得批准,您即可在任何平台的任何應用程式版本上使用該權限。

如果您是在新平台上拓展和開發應用程式,將不需要提交審查。您只有在要求新權限時才需要重新提交審查,例如在應用程式加入新功能時。變更和提交「應用程式詳細資料」或「開放社交關係圖」動作不會影響您已獲得批准的權限。

如果您的應用程式屬於遊戲類別,而且會在 Facebook 全螢幕互動廣告中顯示

您可以使用下列功能邀請新玩家加入您的遊戲:

  • 「邀請」對話方塊。使用「邀請」對話方塊時,您可以設定「filters=app_non_users」來篩選對話方塊,使其僅顯示未使用您應用程式的用戶。如果您的應用程式具備全螢幕互動廣告功能,您還可以在 iOS 和 Android 上使用「邀請」對話方塊。
  • 可邀請的朋友 API。如果您的應用程式是一款遊戲,且您想要自行建立朋友複選器,可以使用可邀請的朋友 API;這樣將會傳回用戶朋友中未使用應用程式的排名清單。用戶選擇要邀請的朋友後,您可以將可邀請的朋友 API 傳回的權杖傳送至邀請對話方塊的欄位,供用戶從中傳送邀請給朋友。

如果您的應用程式不會在 Facebook 全螢幕互動廣告中顯示

您可以使用 iOS 訊息對話方塊Android 訊息對話方塊或網頁上的發送對話方塊。這些產品可讓用戶將內含您應用程式連結的訊息直接發送給朋友。

這種類型的訊息是與少數用戶直接溝通的絕佳管道。「訊息對話方塊」和「發送對話方塊」都包含輸入提示,讓用戶可以輕易地選擇多位要接收邀請的朋友。

目前,如果應用程式僅由在應用程式中具有角色的用戶所使用,以及僅發佈到自己動態時報或粉絲專頁的用戶所使用,則不需要應用程式審查。不過,從 2018 年 8 月 1 日開始,應用程式無法再發佈到用戶動態時報,任何允許用戶發佈到社團或粉絲專頁的應用程式都必須進行應用程式審查。

我們的審查團隊將實際測試在您的應用程式的設定區塊所列出的每個平台上,您的應用程式如何使用各個權限。審查人員會確保您的「Facebook 登入」能夠正確整合,以及所要求的每個權限除了提供更佳的用戶體驗,同時也符合我們的政策及使用準則。

如需詳細資訊,請參閱我們的政策使用準則

在核准您的 user_likes 要求之前,審查人員需要根據應用程式收到用戶的按讚資訊,確認您的應用程式為用戶提供獨特的體驗。在進行測試時,我們的審查團隊將使用各種測試用戶,個別搭配一組不同的愛好和興趣來測試您的應用程式。

在提交 user_likes 要求時,您應該撰寫詳細的指示,包括以下項目:

  • 明確說明您要求 user_likes 的原因,以及該要求如何在您的應用程式中提升用戶的體驗。
  • 列出粉絲專頁範例清單,提供審查人員按讚以驗證您如何使用 user_likes。在審查人員測試您的應用程式之前,請先提供他們應按讚的粉絲專頁直接連結。

如果您使用 user_likes 作為演算法的一部分,審查人員必須可以看到此演算法的結果,以及該演算法如何影響向用戶呈現的內容,這點十分重要。

在某些情況下,您可能需要審查人員重現只針對特定測試用戶提供的行為或體驗。如果是這種情況,您可以在「應用程式審查」頁面上將該用戶新增至您的提交資料中。在「審查中的項目」區塊中,您會看到「測試用戶(選填)」區塊,供您輸入要在審查中使用的用戶名稱。

在此處,您只能夠選擇應用程式的「角色」區塊中列出的測試用戶。請勿在審查指示中分享用戶的 Facebook 登入憑證。

深入瞭解如何建立測試用戶。

不用,無須提交審查也能夠刊登行動應用程式安裝廣告。您只要將應用程式在 iTunes App Store 或 Google Play 商店上架即可。您可以按照我們的指南來建立行動應用程式安裝廣告

您需要明確說明如何測試您應用程式的每個權限或功能,以便我們確定其運作正常以及遵守我們的政策。如果我們無法完整測試您的應用程式如何整合 Facebook,我們將無法批准您的應用程式。您提供的指示越詳細,被審查人員要求重新提交審查的機率就越小。

請為您要求的每一個權限逐步列出重現指示。所有指示皆須以英文撰寫。

您的指示不應該

  • 引用其他提交資料的指示或文件
  • 提供您應用程式功能的摘要而沒有提供指示
  • 提供 API 運作方式的技術詳細資料

以下為很好的逐步指示範例:

  1. 按下左側功能表上的「設定」按鈕。
  2. 選擇使用 Facebook 登入
  3. 完成第三個步驟
  4. 完成第四個步驟

如果您仍然不確定要包括哪些資訊,請參閱我們應用程式審查範例區塊中提供的更多範例。

由於審查程序變更,以及大量的預期提交資料,因此提交的應用程式可能需要好幾個星期才能完成審查。

為了加速審查人員的作業流程,請盡可能提供充分資訊,包括清晰的螢幕截圖、詳細的逐步指示,以及您的應用程式與 Facebook 整合的螢幕錄影錄製內容。

如果應用程式有使用中介分享產品(例如社交外掛程式、「分享」對話方塊、分享表單或「Facebook 登入」功能子集),就不必經過 Facebook 審查。如需深入瞭解哪些內容需要接受審查,請參閱應用程式審查文件。

我們會審查您的應用程式,以確保所有應用程式皆能提供高品質的 Facebook 體驗。一般來說,用戶必須清楚知道自己正在登入 Facebook 及張貼貼文。用戶應該要能控制想分享給您應用程式或分享到 Facebook 的資訊。

注意:應用程式「角色」頁籤中列出的用戶將具有更多存取權限,而且不需經過審查(例如 user_posts)。然而,若應用程式開放大眾使用,就必須經過應用程式審查才能存取資訊,即便是具備應用程式角色的用戶也不例外。

所有應用程式功能在開發模式下都應開放使用,但您只能存取自己的資料、測試用戶的資料,或是粉絲專頁的資料。若想公開發佈應用程式,便必須經過應用程式審查,即使您是應用程式唯一的用戶也一樣。

企業管理平台

如果透過 /BUSINESS_ID/pages 要求企業的粉絲專頁清單,並非粉絲專頁的所有欄位皆可要求,而且 API 可能會回應以下錯誤:(#100) Unknown fields: <FIELD_NAME>

這是因為這個端點不像其他類似端點,並不會傳回粉絲專頁物件,而且還會包含如待核准要求等尚未獲得批准的項目。因此,無法利用欄位擴展傳回粉絲專頁的欄位。

您可以使用 <BUSINESS_ID>/owned_pages<BUSINESS_ID>/client_pages,這兩個端點應該會傳回粉絲專頁物件,並且也支援欄位擴展。

若要向已驗證的粉絲專頁傳送要求,Facebook 業務經理必須將企業設定為允許向與該粉絲專頁連結的組織發出這類要求。沒有 Facebook 業務經理的企業將無法發出這類要求。

資料使用情形檢查

進行資料使用情形檢查時,應用程式管理員必須:
1.查看應用程式獲批准的權限和功能
2.確認應用程式遵守允許的使用方式
3.確認遵守 Facebook《開放平台使用條款》《開發商政策》以及其他所有適用的條款和政策

「資料使用情形檢查」和「應用程式審查」是各自獨立但又互相關聯的兩種平台誠信措施。「應用程式審查」是著重於日後用途的審查程序,對存取某些 Facebook 開放平台的權限有所限制,開發商必須提交申請充分說明存取平台的理由,再由開發人員作業團隊以人工方式進行審查。獲得平台存取權限後,「資料使用情形檢查」則是一年一度的認證程序,要求開發商確認繼續使用 Facebook 資料的方式遵守我們的《開放平台使用條款》《開發商政策》

管理許多應用程式的開發商可選擇一次完成多個應用程式的資料使用情形檢查。您可前往應用程式主控板的「我的應用程式」頁面來使用此流程。您可以在此查看您擔任管理員的所有應用程式、篩選出部分應用程式(例如僅查看須進行資料使用情形檢查的應用程式),並且完成資料使用情形檢查。

您必須對您管理的每個應用程式完成檢查(一個應用程式可能擁有多項權限)。您可依自身需求先後認證個別應用程式,只要在各應用程式的截止日期前完成這項程序即可。

系統會提示您認證您可存取的所有權限。不過如果您發現不再需要存取某些權限,您可以將這些權限移除,便不需要再為其進行認證。

「上線模式」和「開發模式」是對應用程式功能和資料使用情形檢查有所影響的兩種模式。「開發模式」一般用於測試、探索 API 產品/權限,以及完成應用程式審查;處於開發模式的應用程式不能呼叫用戶層級資料。「上線模式」用於生產情境,而且不會限制應用程式存取在應用程式審查中獲准存取的資料/權限。只有「上線模式」的應用程式才需要進行「資料使用情形檢查」。

如果您因為某些原因無法存取應用程式且需要重新取得管理員身分,請點擊這裡

一般來說,我們會為擁有相同應用程式管理員的應用程式訂定相同的截止日期,因此您的應用程式應該都有相同的期限。不過也可能有例外情況,使得部分應用程式管理員需要在不同的截止期限前完成此程序。舉例來說,如果您在其他應用程式已通過資料使用情形檢查後建立應用程式,則該應用程式就會有不同的年度截止日期。

您可前往應用程式主控板的「我的應用程式」頁面,查看需要進行「資料使用情形檢查」的所有應用程式。您可以在此查看所有您管理的應用程式,並篩選出需要進行「資料使用情形檢查」的應用程式。

這項程序應由應用程式管理員完成。若要查看應用程式的管理員,請登入應用程式主控板,然後點擊頁面左側的「角色」。應用程式管理員應獲得授權可代表組織行事。

所有應用程式管理員都可進行應用程式認證。如果應用程式有多位管理員,只須其中一位進行認證。

從程序開始(您收到第一封開發人員通知)到截止日期為止,您有 60 天的時間可以完成認證程序。

在截止日期過後的一個月內,我們會限制 API 呼叫速度,開始撤銷平台存取權限。在這段期間,您可前往應用程式主控板完成「資料使用情形檢查」,使應用程式重新符合規範,即可完全恢復平台的存取權限。但是過了這一個月之後,平台存取權限就會完全撤銷。

您仍然可回到應用程式主控板完成「資料使用情形檢查」,以恢復存取權限。不過我們會針對不活躍的應用程式定期進行未使用的「權限整理」,也就是說,權限在一段時間未使用後有可能會遭到永久移除,您必須提交「應用程式審查」才能重新取得權限。建議您在截止期限之前完成「資料使用情形檢查」以避免上述情形。

資料使用情形檢查會顯示您應用程式可存取的所有權限,不論您目前是否正在使用。建議您利用這次機會審視您的整合方式、深入瞭解應用程式功能,以及移除任何您不需要的權限存取權。

在某些情況下,我們會直接在資料使用情形檢查流程中顯示 API 用途資訊。其他時候,您可以在應用程式主控板的「權限和功能」區塊查看每項權限的用途層級。登入後請點擊頁面左側的「應用程式審查」,然後在下拉式功能表選擇「權限和功能」。您會看到「API 呼叫」欄位,如果我們的紀錄顯示您目前正在使用某權限,此欄位便會出現綠色打勾符號。請注意,此欄位僅供參考,您應詢問您的開發團隊以瞭解整合是否需要該權限。

因為這些自動授予的「基本」權限用途廣泛且提供用戶資料的存取權,因此我們要求開發商須認證這些權限。不過即使您未使用這些資料,您仍然可安心完成這項程序,因為認證程序代表該權限的任何使用方式皆遵守相關規定,其中也包括「不使用」的使用方式。

首先,請前往應用程式主控板移除這項權限(在左側「應用程式審查」下的下拉式功能表中點擊「我的權限和功能」)。接著,您便可以認證仍在使用的其他權限和功能。

不過您無法移除某些自動授予的權限,而且系統可能會要求您進行認證。即使您未使用這些資料,您仍然可安心完成這項程序,因為認證程序代表該權限的任何使用方式皆遵守相關規定,其中也包括「不使用」的使用方式。

不需要。在應用程式主控板移除權限後,只要重新整理「資料使用情形檢查」頁面,您移除的權限應該就會消失。

您必須對您應用程式可存取的所有權限完成資料使用情形檢查。

我們將分階段實施資料使用情形檢查,因此雖然此程序預計應在接下來的幾個月內完成,但確切的截止日期將各有不同。請確認您應用程式主控板的是最新聯絡資料,並請參閱開發人員通知以瞭解確切截止日期。

開發人員帳號和服務

In order to comply with certain legal obligations, Meta’s developer services may not be available in all locations, including countries and regions currently subject to U.S. sanctions prohibitions.

Registration reviews may take longer and you may be unable to access our service during that time. Please try again in a few days. For more information, please refer to Meta’s Terms of Service.

We are currently reviewing your registration details. This takes 24 to 48 hours. Once completed and approved, you may be able to login and complete your registration.

開發人員工具

如果螢幕截圖或橫幅圖像已獲准在應用程式中心刊登,您就無法加以刪除。若要使用新的圖像加以替換,請點擊螢幕截圖或橫幅上的「編輯」,然後選擇替換的圖像。

請在不要求用戶相片的情況下看看是否會顯示此錯誤訊息,並確認一開始即顯示錯誤訊息。 接著,請發出以下的 API 要求 me/photos,然後返回查看是否仍然會顯示該錯誤訊息,或是否不再顯示。 發出測試 me/photos 呼叫時,請務必使用預期的應用程式,並取得正確的存取權杖(必須有 user_photos 權限),即可順利進行測試!

這個檢查的目標是確保開發人員在要求相同權限之前,已在應用程式中完整測試此功能。在測試應用程式中進行測試,無法保證在主要應用程式會有相同的穩定行為。您必須從主要應用程式發出測試要求,確認是否如期運作,再啟用供外部受眾使用。 請遵循以下提供的步驟,手動發出要求,然後檢查主控板是否已不再出現此警告。

如果您的 Facebook 應用程式發佈的網址未指回應用程式擁有的網域,「串流貼文網址安全性」轉移就會禁止您的 Facebook 應用程式發佈這些網址。如果您的應用程式會發佈前往其他網站的連結,請勿使用此選項。

此主控板功能已移除。您必須使用「/{app-id}/accounts/test-users/」端點才能將測試用戶與應用程式建立關聯。您可以在這裡詳讀更多資訊。

這是預期的行為,並且在這裡提供說明 - https://developers.facebook.com/docs/apps/test-users#rules:測試用戶無法成為公開 Facebook 粉絲專頁的粉絲,也無法在其中建立內容,例如在粉絲專頁的塗鴉牆上留言。然而,測試用戶可以在應用程式建立的相關聯粉絲專頁上,檢視以及與任何應用程式頁籤互動。

這個情況有其目的。為了安全起見,我們不允許使用多個任意網域。

Facebook 登入

這是預期的行為。「登入」對話方塊會使用固定寬度,不會縮放以符合較大的螢幕。

這是預期的行為。開發人員必須負責依據用戶的裝置設定適當的「redirect_uri」。因此,如果用戶使用的是行動裝置,「redirect_uri」就必須是行動網站網址。

這是預期的行為,因為這樣能夠防止可能的安全性漏洞。有些瀏覽器會在重新導向的新網址末端附加網址的雜湊片段(如果新網址本身沒有雜湊片段)。

例如,如果 example1.com 傳回往 example2.com 的重新導向,那麼前往 example1.com#abc 的瀏覽器就會前往 example2.com#abc,而 example2.com 的程式碼就可以存取 example1.com 的雜湊片段內容。

因為有可能將驗證流程重新導向至另一個驗證流程,所以應用程式之間有可能存取敏感驗證資料。對重新導向網址附加新的雜湊片段,便可防止此瀏覽器行為,以減輕這個漏洞的危險性。如果所產生網址的美觀與否或用戶端行為非常重要,就可以使用 window.location.hash(或甚至是您自己的伺服器端重新導向)來移除不當的字元。

圖形 API

Test apps created from Business apps will have Standard Access for all permissions and features.

No. For a given permission, Business apps have either None, Standard, or Advanced Access.

Yes. For Business apps, the Advanced Access level includes access to all data within the Standard Access level.

若要分享網址,關聯的圖像必須至少為 200x200 像素。如果並非如此,您就會收到類似以下的錯誤:「提供的 og:image 尺寸不足。請使用至少為 200x200 像素的圖像。」

為網址挑選圖像時,我們會先查看您的「og:image」標籤,看看標籤是否存在,以及是否符合 200x200 像素的要求。如果沒有「og:image」標籤,我們就會選擇在網頁上找到的第一個圖像。

如果您收到錯誤,但是認為您的網站圖像大於 200x200 像素,就應該確認您是否已正確設定「og:image」標籤,因為最可能的原因是我們從您的網站擷取了錯誤的圖像。

我們已變更分享外掛程式的行為,以便與開放平台中其他外掛程式和功能的行為一致。

分享外掛程式不會再接受自訂參數,Facebook 也會從網址 OG 中繼標籤載入預覽中顯示的資訊,如同以貼文方式顯示在 Facebook 上一樣。

否,分享網址上的「caption」無法覆寫,只能覆寫「title」和「description」。

應用程式無法上傳內容到其他應用程式建立的相簿。

在某些情況下,有些相簿不會與任何應用程式建立關聯(塗鴉牆相簿)。建議您檢查 can_upload 欄位。如果 can_upload 欄位傳回 false,就表示用戶無法透過個人檔案的相簿檢視,直接將相片直接放入此相簿中。

影片播放完後,行動呼籲將顯示在「重播」圖示下方。

GIF 的大小必須小於 8MB,才能夠在 Facebook 播放。

目前並不支援透過 API 對未發佈的貼文建立留言。

內嵌建立的影片貼文不會顯示在 promotable_posts 端點中,因為這類貼文已經獲得推廣。內嵌建立的影片貼文是在廣告建立流程的一部分中建立的貼文,因此無法單獨加強推廣。

因此,內嵌建立的貼文也不會顯示在 /promotable_posts 端點中。

如果您使用粉絲專頁存取權杖,而且與該權杖關聯的用戶在粉絲專頁「設定」下的「粉絲專頁角色」中列為分析師,就可能會發生這種情況。

使用圖形 API 要求資料時,適用各種隱私規則,因此會造成特定資料無法傳回,即使您可以在網站上查看這些資料。這取決於多種因素,例如用戶的隱私設定、應用程式等級權限等。這代表 API 傳回的資料不一定會包括網站上顯示的所有資料。

如果貼文是使用廣告 API 的「object_story_spec」建立,這些貼文就歸類為內嵌貼文。若要查看此類貼文,您必須使用 /{page-id}/promotable_posts 關係連線,並且使用「is_inline」修飾詞(第 2.3 版和先前版本)或「include_inline」修飾詞(第 2.4 版和更新版本)。您可以在這裡閱讀更多內容。

如果貼文分享超過 10 次,就會傳回 shares 欄位。如果貼文分享不到 10 次,我們可能就會略過此欄位或嘗試傳回數字。

您可以到這裡瞭解更多有關此端點的資訊:https://developers.facebook.com/docs/graph-api/reference/v2.4/post

這是舊版基礎架構所使用的舊值,我們在改為新版本時因回溯相容性而加以保留。

舊貼文會發生這種情形,但是新的貼文就不會了。

此運作方式與預期相同。貼文和貼文中的相片之間並無關聯。我們只會傳回貼文中上傳的第一張圖像。

如果貼文來源為 Facebook 網站或行動應用程式,就不會傳回「application」欄位。這和網站保持一致,網站上也不會顯示這類貼文的來源。

貼文的「privacy」欄位會包含有關該貼文在 Facebook 上的能見度資訊。但是,粉絲專頁貼文已設定目標或受到限制,只會顯示給特定受眾時,「privacy」欄位中的資訊就不會顯示所有選擇的目標設定選項。

若要查看如何限制或設定貼文目標的完整詳情,請查看「targeting」欄位(針對限制)和「feed_targeting」欄位(針對動態消息目標設定)。請參閱貼文文件以進一步瞭解有關可使用欄位的資訊。

針對貼文傳回的 comment_count 值可能包括已隱藏或刪除的留言。貼文上顯示的留言數目絕對不會超過 comment_count。

分享網址的「caption」是無法覆寫的。您只能覆寫該網址的「title」和「description」。

如需瞭解詳細資訊以及您可以透過圖形 API 發佈哪些欄位,請到以下網址查看 /feed 文件:https://developers.facebook.com/docs/graph-api/reference/v2.3/page/feed#publish

系統的設計就是如此。這與 Facebook 應用程式(行動版或網頁版)所產生內容的顯示方式一致,不會歸因至 Facebook 本身。

關於透過 API 擷取與顯示串流和貼文資料的方式,我們已做出更新。

如果您在從 API 擷取貼文時遇到問題,而且認為其運作方式和文件說明不符,請確認以下事項:

  • 您使用的存取權杖是否有適當的權限可存取您感興趣的貼文。
  • 請確定用來擷取貼文的所有 API 呼叫是否皆使用先前呼叫中傳回的「id」,而且您並未依據粉絲專頁、用戶或其他編號來手動製作編號。

透過 Instagram 上傳的相片是以開放社交關係圖動作的方式發佈,所以需要適當的開放社交關係圖權限才能從圖形 API 讀取。

如果是 Instagram 相片,所需的權限是「user_actions:instapp」,其中的「instapp」是 Instagram 的應用程式命名空間。

開放社交關係圖動作不會顯示在 /feed 關係鏈中。但是,如果相片是以開放社交關係圖動作上傳,就可以透過適用的用戶相簿關係鏈或 /photos 關係鏈,使用適當的權限加以存取。

您可以到這裡找到更多有關開放社交關係圖權限的資訊。

這個情況有其目的。對於已刪除或因隱私/權限檢查而未顯示的物件,我們的系統就會傳回以上的錯誤訊息。

這是預期的行為,而且留言不支援這種分頁形式。

/{user-id}/accounts 端點摘要參數的 total_count 欄位可能會傳回高於預期的數字。這是因為 total_count 還包含用戶是管理員的所有已刪除粉絲專頁。

然而,該端點本身傳回的資料只會包含未刪除的粉絲專頁。

/user/likes 端點已從時間型分頁(使用「since」和「until」做為參數)變更為游標型分頁(使用「before」和「after」參數)。

您可以到這裡閱讀更多有關這些差異的資訊:https://developers.facebook.com/docs/graph-api/using-graph-api/v2.3#paging

在推出應用程式範圍的用戶編號時,我們就變更了端點傳回資料的方式。

因為第 1.0 版已停用,我們這裡將專注討論第 2.x 版。/v2.0/{id} 可能會傳回 https://www.facebook.com/{id},或是會傳回 https://www.facebook.com/app_scoped_user_id/{id}

這個情況有其目的。此錯誤代表您嘗試延展效期的存取權杖,並無法存取嘗試延展該權杖效期的應用程式編號。

之所以會出現此錯誤,最可能的原因是您的應用程式套用了人口統計資料限制,而且我們偵測到您嘗試延展效期的權杖所屬用戶不符合這些限制(或不再符合限制,因為他們的所在地點已變更,或是我們現在會偵測更精確的地點)。

其次的可能原因是我們無法確認用戶是否符合要求(例如我們無法得知他們的所在地點),而且您的應用程式限制不允許這些用戶存取應用程式。

自 2013 年 7 月起,即無法在用戶搜尋輸入中使用電子郵件搜尋端點。

此外,我們也在推出第 2.0 版時對圖形 API 做出許多變更。第 2.0 版不提供搜尋公開貼文和關鍵字搜尋的功能。

請參閱變更紀錄以瞭解更多詳情。

所有在 2014 年 4 月 30 日之後建立的應用程式都會使用 API 第 2 版及更新版本,因此會像您敘述的一樣,使用 /me/friends 端點只會傳回您在應用程式上的朋友。此外,所有用戶編號現在都屬於應用程式範圍編號,對您的特定應用程式都是唯一且永久的編號。

您可以深入瞭解有關 v2.0 中推出的所有新功能和變更。

User 物件的 email 欄位相關文件清楚說明了這裡的預期行為:「如果未提供有效的電子郵件地址,就不會傳回此欄位」。

在一些情形下,您可能會認為用戶應該傳回電子郵件地址,但是並沒有。為了隱私和安全起見,我們無法詳細說明不會傳回任何特定用戶電子郵件地址的確切原因。

部分可能的原因為:

  • 帳號中沒有電子郵件地址
  • 帳號中沒有已確認的電子郵件地址
  • 帳號中沒有已驗證的電子郵件地址
  • 用戶輸入的安全檢查項目要求用戶再次確認電子郵件地址,但是尚未確認
  • 無法聯繫用戶的電子郵件地址
您還需要「email」延伸權限,即使對於帳號中有有效、已確認且可聯繫電子郵件地址的用戶亦然。

這些貼文無法透過 API 擷取,因為在此類貼文中,用戶的內容是在粉絲專頁上轉貼,而且該用戶並未授權應用程式查看其內容。

如果用戶針對貼文的內容類型關閉了基本權限,就無法透過 API 取得用戶在粉絲專頁動態時報上分享的貼文。

若要查看遺失的粉絲相片貼文,您可以使用粉絲專頁存取權杖來擷取粉絲專頁的相簿──相片應該會在動態時報相簿中。

即使貼文設為公開而且提及所要求的粉絲專頁,如果您的應用程式沒有這些貼文擁有者的 read_stream 權限,就還是無法查看這些貼文。這代表 {page_id}/tagged 端點不會傳回所有貼文。

您可以到粉絲專頁動態文件中閱讀更多有關此內容的資訊。

在有些情況下,特定應用程式(或任何應用程式)會因為 Facebook 用戶的隱私設定而無法取得與該用戶相關的任何資料,這種情況包括在您應用程式應該能夠查看貼文的範圍內,存取該用戶所發佈的貼文時(例如粉絲專頁管理)

例如,當用戶已封鎖應用程式,或是已停用所有平台應用程式,使其無法透過 API 存取其資訊。

推出圖形 API 第 2.1 版後,我們就移除了這項功能。如果是在 2014 年 8 月 7 日前建立的應用程式,signed_request 中就不會再有此欄位。

針對在此日期之前建立的應用程式,liked 屬性將一律傳回 true,無論該用戶是否已對粉絲專頁按讚。

若要取得其他結果頁面,請直接使用回應中傳回的 paging.next 和 paging.previous 連結。使用所提供的連結,可確保如果將來分頁連結的格式有所變更,您的應用程式將不會受到影響。

就像 API 上的多數項目一樣,這些並非完全 1:1 對應於主要 Facebook 網站上的功能。粉絲專頁洞察報告 UI 與透過 API 所稱的自主觸及人數有很大的不同,計算方式也不同。

例如,粉絲專頁洞察報告 UI 中的「organic」值對應的是透過圖形 API 所取得 page_impressions_by_paid_non_paid_unique 指標中的「unpaid」值。

我們希望能夠讓這兩者一致,但是可能需要一些時間。

此錯誤表示因為隱私問題,與存取權杖關聯的用戶無法查看此粉絲專頁。例如,粉絲專頁可能未發佈,用戶也不是粉絲專頁的有效管理員。

當嘗試對非常活躍的粉絲專頁擷取洞察報告時,通常會發生此錯誤。如果您使用「since」和「until」欄位,將要求洞察報告的時間間隔縮短,就可以解決此問題。

這是測試應用程式和處於開發模式下應用程式的預期行為。一旦發佈應用程式,此功能就會正常運作。

您可以到這裡查看此設計限制的相關錯誤

只有管理員、編輯或版主才能夠讀取和傳送粉絲專頁訊息。擔任其他角色的用戶(例如廣告主和分析師)無法讀取粉絲專頁對話。

請瀏覽此使用說明頁面以深入瞭解各種粉絲專頁角色: https://www.facebook.com/help/289207354498410

「page_fans」和「page_fans_country」的總數並非一直都相等。有許多因素會影響「page_fans_country」值。例如,某些粉絲可能未在帳號中設定國家/地區,或是某些粉絲可能設有隱私設定,而隱藏國家/地區。

若要深入瞭解 Facebook 隱私設定,請瀏覽以下的使用說明頁面:https://www.facebook.com/help/445588775451827

有些公開的粉絲專頁貼文是從用戶內容轉貼的。如果建立貼文的用戶尚未將所需權限授予應用程式,應用程式就無法透過圖形 API 存取用戶的貼文,因此也無法回應這些貼文。

以內嵌方式建立成廣告創意一部分的貼文,無法單獨加強推廣。因此,這些貼文也不會顯示在粉絲專頁的 /promotable_posts 端點呼叫中。

如果您使用仍然在開發模式的應用程式來排程貼文,就會發生這種情形。請使用已正式推出的應用程式,就不會發生這個問題了。

很抱歉,我們目前不支援透過 API 建立、更新或刪除封面相片。

若要瞭解有關封面相片 API 的詳情,請瀏覽 https://developers.facebook.com/docs/graph-api/reference/cover-photo/#Creating

這是目前的行為。粉絲專頁管理員無法透過圖形 API 以自己的身分發佈貼文到粉絲專頁。此功能只能在 http://www.facebook.com/ 和我們的行動應用程式中使用。

不可以,沒有任何方式能夠取得對粉絲專頁按讚的完整用戶名單。系統的設計就是如此。

代表粉絲專頁執行動作時,請務必使用粉絲專頁存取權杖。這則錯誤訊息代表您使用的是用戶存取權杖,而不是粉絲專頁存取權杖。

您可以到以下網址瞭解各種類型的存取權杖: https://developers.facebook.com/docs/facebook-login/access-tokens

沒有辦法,您只能透過原生 Facebook 產品將貼文置頂與閱讀置頂貼文。

如果已經在某個時間點針對外部網址開啟留言同步功能,對於同步留言的貼文,其心情會針對網址本身記錄,並且將會在呼叫 {URL-id}/reactions> 時傳回。

目前不支援針對 /app_insights/app_event 端點提取超過 1000 個資料解析值的資料。如果您想要將資料按特定類別細分,建議利用 Facebook 分析工具 UI 切入至特定資料點,例如特定國家/地區。

您可能在資料傳播到我們的伺服器前,就已經呼叫該端點。

您應該等候 1-2 秒,讓資訊傳播到我們所有的伺服器,再發出 API 呼叫。

「page_fans_country」指標通常是「page_fans」計數的子集。這個指標涵蓋粉絲專頁按國家/地區細分的粉絲人數,但前提是我們要能準確判別用戶的國家/地區。

這個指標也僅包含粉絲專頁粉絲的熱門國家/地區(按粉絲人數),並未包含粉絲所在的所有國家/地區;對於粉絲散布在許多國家/地區的粉絲專頁,這個指標不會包含粉絲人數較少的國家/地區。

此 API 不支援使用位移型分頁。

您應該改為使用在每個圖形 API 回應結尾傳回的「分頁處理」連結,或是使用「游標」型分頁(建議使用)。

您可以到以下網址瞭解更多有關如何透過圖形 API 正確處理分頁的資訊:https://developers.facebook.com/docs/graph-api/using-graph-api/v2.3#paging

存取權杖分為短期和長期存取權杖。短期權杖適用於較短的連線階段,而且通常幾小時後就會失效。

您可以將短期權杖換為長期權杖,這樣就有大約 60 天的使用期。

您可在存取權杖文件中閱讀相關資訊。

這是預期的行為。搜尋 API 會遵守 Facebook 的隱私規定,而且是專為您使用的存取權杖所屬用戶量身打造,不但不支援主題標籤搜尋,其設計也和 Facebook.com 搜尋輸入提示中執行的搜尋不同。

我們決定不支援或規劃讓搜尋 API 傳回與 Facebook.com 搜尋相同的結果數量或特定結果。而且,一般來說,相較於 Facebook 本身的相同貼文,透過 API 傳回的貼文必須遵守更嚴謹的隱私規定和安全驗證。

我們的系統會對應用程式發出的 API 呼叫強制執行速率限制。若要深入瞭解各種限制,並避免您的應用程式受到限速,請瀏覽 https://developers.facebook.com/docs/marketing-api/api-rate-limiting

即時文章

您可以使用 <figure> 元素來包裝參照 GIF 圖像網址的 <img> 元素,在文章中加入動畫 GIF 圖像。如同其他圖像,您可以對 GIF 圖像加入說明和出處。

如需更多詳情和範例,請參閱這裡的文件。

您可以在不同的粉絲專頁重複使用摘要網址,但請注意,系統只會擷取其標準 URL 和粉絲專頁領取的網域相符的文章。

我們建議的方式是各個粉絲專頁使用個別的 RSS 摘要,而且摘要中只包含該粉絲專頁應該擷取的文章。

您可以透過使用內嵌社交功能,加入受支援的內嵌社交功能,包括影片。對於其他第三方影片播放器,您可以透過互動內嵌功能的方式,將其加入文章中。

您可以使用含 op-interactive 類別的 <figure>,將互動式圖形和內容內嵌在文章中。這個 figure 應該包含 <iframe>,用於包含要內嵌的內容。

您可以在這裡找到詳細資訊和範例。

您可以使用 <figcaption> 元素來指定說明。在說明內,您可以使用 <cite> 元素來加入出處。

您可以在這裡的文件中找到詳細資訊和範例。

當文章處於草稿模式時,只有對粉絲專頁管理員才會顯示為即時文章。當文章一旦發佈並上線後,便可供任何的 Facebook 用戶分享,而且對所有人都會顯示為即時文章。

請檢查是否將 pages_manage_instant_articles 權限授予應用程式。若要呼叫 API 方法來讀取和更新粉絲專頁的即時文章,這項權限是必要的。

您可以在這裡找到使用該 API 的更多資訊。

如果您在文章中使用 dir="rtl" 屬性來顯示由右至左書寫的語言,有可能用於瀏覽文章的應用程式並未支援即時文章中由右至左書寫的語言。

請檢查您是否使用應用程式的最新版本。各應用程式支援由右至左書寫語言的最低版本為:

  • iOS 版 Facebook:52.0
  • Android 版 Facebook:69.0
  • iOS 版專頁小助手:44.0
請注意,我們目前在 Android 版專頁小助手中不支援由右至左書寫的語言。

請檢查文章的 <body> 標籤是否設定 dir="rtl" 屬性。如果您的文章並未使用由右至左書寫的語言,則不應在文章中設定這個屬性。

請檢查是否在文章的 body 標籤中設定 dir 屬性。對於由右至左書寫的語言,您應該將 dir 屬性設為「rtl」。

文章的動態消息預覽會使用文章網頁版的 og:image 中繼標籤所指定的圖像。您也可以透過對文章中的任一影片加入「fb-feed-cover」類別,選擇以影片取代圖像。您可以在這裡找到關於動態消息預覽的更多資訊。

如果在即時文章發佈之前就分享文章的網址,用戶會被重新導向至文章的行動網頁版。即時文章一旦發佈之後,所有的連結分享,包括在文章發佈之前張貼的分享,在行動裝置上檢視時,都會自動顯示即時文章。

目前「views」指標僅涵蓋 iOS 用戶。Android 瀏覽次數會在「android_views」指標中分開計算。

您可以在這裡取得更多資訊。

我們尚未在 Android 版專頁小助手中提供開發摘要的支援。目前若要在 Android 上查看文章,因應措施為可以嘗試將文章以草稿的方式加入生產摘要。

若要編輯即時文章,您可以使用粉絲專頁介面。若要以這種方式進行,您可以在瀏覽器中前往您的粉絲專頁,然後前往「發佈工具 > 即時文章」。您會在該處看到您的文章,並且就地進行編輯。您可以在此詳讀更多資訊:https://developers.facebook.com/docs/instant-articles/publishing

摘要下載的逾時時間目前為 30 秒。

不可以,分享連結必須是文章的標準 URL。如果變更這個網址(例如加入參數),就會被視為不同的網址。

系統擷取 RSS 摘要時發生的任何錯誤或警告都會顯示在「設定」頁面的「即時文章」頁籤中。您也可以在「發佈工具」頁面的「即時文章」頁籤中點擊文章,以檢視個別文章的警告和錯誤。

請檢查 RSS 摘要是否遵循這裡記載的格式。

文章的標準 URL 也應該使用為粉絲專頁設定的網域,或該網域的子網域。如果您發現系統會擷取新文章,但並未顯示現有文章的更新,請檢查是否遞增「op-modified」時間戳記。

您可以在這裡找到更多資訊。

文章並未根據 RSS 摘要更新的常見原因之一,是因為摘要中文章的 op-modified 時間戳記和我們上次擷取的版本相同。只有在該時間戳記比上個版本更晚時,我們才會更新文章。

此外,您也應該確認文章的更新版本是否使用相同的標準 URL。

您可以參閱這裡的文件,瞭解有關我們如何從 RSS 摘要擷取文章的詳細資訊。

我們會嘗試在 10 秒內完整載入並剖析您的 RSS 摘要。這個錯誤表示嘗試並不成功。

解決這個問題的方法之一,是在您的 RSS 摘要中包含較少的項目,例如:僅包含過去 10 分鐘內新增/變更的文章。因為系統每 3 分鐘就會擷取摘要一次,所以包含未變更的文章是不必要的。

很抱歉,我們沒有網路爬蟲所用的靜態 IP 位址清單。不過,您可以改用我們網路爬蟲的用戶代理程式:facebookexternalhit/1.1

如果對現有即時文章的更新已超過 24 小時(依據 op-modified 時間計算),則提取會將其忽略。這表示該修改時間應該是在現有文章中設定的修改時間的 24 小時內,而不是目前時間。在這類更新被忽略的情況下,您可以透過網頁型即時文章編輯器工具,手動變更文章。

您可以在這裡找到更多資訊。

請檢查重複的文章是否使用不同的標準 URL。我們使用文章的標準 URL 做為文章的唯一識別碼,所以使用不同標準 URL 的文章會被視為個別文章處理。

一個常見的問題是,您的內容管理系統可能會使用不同的 URL 來發佈文章更新,導致系統將更新擷取為新文章。

是,每個粉絲專頁都會唯一對應到一個網域名稱,而且是 1:1 對應。 我們要求屬於特定粉絲專頁的即時文章,其標準 URL 必須屬於該指定網域或相同網域的子網域。

不過,RSS 摘要網址本身的網域不需要和對應至粉絲專頁的網域相符。這項限制僅適用於摘要中文章的標準 URL。

如果您想要根據粉絲專頁的語言將文章發佈到不同的粉絲專頁,您應該為每種語言設定不同的 RSS 摘要,然後將各個粉絲專頁設定為使用合適的 RSS 摘要。

不會,一旦從 RSS 摘要中擷取文章後,該篇文章就會以即時文章的方式持續保存,直到從粉絲專頁的發佈工具中刪除為止。然後,您就可以從 RSS 摘要中安全移除該篇文章,以加快下一次的擷取程序。

目前無法透過 API 來發佈或刪除文章,但我們正在研究這項功能。

「讚」按鈕會使用您樣式設定中所設定的輔色色彩。請檢查您是否設定在頁首襯托下明顯可見的色彩。

此外,只有在瀏覽文章的用戶尚未對該粉絲專頁按讚時,才會顯示「讚」按鈕。因此,對於先前已經對該粉絲專頁按過讚的粉絲專頁管理員,系統並不會顯示「讚」按鈕。

請檢查並未在同一列中使用多個 <br> 標籤。若要將文章正文分割成多個段落,建議您使用段落(<p>)標籤,而不是換行符號。

請確保在包裝追蹤像素的 <figure> 標籤中加入「op-tracker」類別。若無這個標籤,追蹤像素會被視為內嵌圖像處理。

請檢查是否使用支援的影片檔案格式。您可以在這裡找到所有支援影片格式的清單。

您也應該確保將內嵌影片正確包裝在 <figure> 標籤中,而不是將影片包裝在段落(<p> 標籤)中。

如果您在段落(<p> 標籤)內包裝非文字內容,如圖像或互動內嵌功能,通常就會顯示這項警告。段落只應該包含正文,其他任何內容都應該加入 <figure> 標籤內或其他合適的容器元素中。

不可以,說明(<figcaption>)元素僅支援 <h1>、<h2> 和 <cite> 標籤。不支援段落(<p>)標籤。

目前 <video> 元素不支援「muted」屬性。

文章中的廣告是使用標準的 HTML5 <figure> 元素來定義,該元素用於包裝內含廣告標記的 <iframe> 元素。您可以將 op-ad 類別套用至 <figure> 元素,以在文章中指定廣告。指定廣告有兩種方式:透過在 iframe 中使用「src」屬性,直接指定廣告的網址;或透過在 iframe 中內嵌未逸出的 HTML 和指令碼。

您可以在這裡找到有關廣告的更多資訊:https://developers.facebook.com/docs/instant-articles/reference/ad

標準圖像元素不支援使用 SVG 圖像。您可以改用互動內嵌功能(「op-interactive」),在 iframe 內加入 <img> 元素,並將「src」屬性設為 SVG 圖像的網址。

您可以使用這裡記載的地圖元素:https://developers.facebook.com/docs/instant-articles/reference/map。這是在即時文章中加入地圖的建議方式。

如果您以互動內嵌功能的方式在文章中加入 Google 地圖內嵌,由於內嵌功能運作方式上的已知問題,可能會造成地圖無法顯示。若要避免發生這個問題,您需要將載入地圖內容(「https://www.google.com/maps/embed?...」)的 iframe 包含在另一個 iframe 內。

您可以使用含 op-interactive 的 figure 來內嵌互動式模組。您可以在這裡取得詳細資訊和程式碼範例:https://developers.facebook.com/docs/instant-articles/reference/interactive

若要定義高度,請將「height」屬性加入包裝所內嵌內容的 <iframe> 元素中。該屬性值應該是整數值,指出以像素表示的高度。高度最大可設為 960 像素。

您可以透過在頁首內新增 <figure> 標籤來加入封面。透過在 figure 中加入 <img> 或 <video> 標籤,您就可以使用圖像或影片做為封面。

您可以在這裡找到有關封面的更多資訊。

若要在圖像之間加入間距,您可以在圖像之間加入空白段落,例如:<p>&nbsp;</p>。

若要加入出處,請在 <figcaption> 元素內使用 <cite> 元素。

對於封面圖像,您可以在 <cite> 元素明確指定任一「垂直對齊方式」屬性,即可指定一律顯示出處。否則,除非展開圖像,不然不會顯示出處。

您可以透過加入含「op-social」類別的 figure,並且加入包含所要內嵌內容的 iframe,即可內嵌社交內容。

如需更多詳情和程式碼範例,請參閱這份文件

您需要使用影片檔案(如 mp4 檔案)的直接連結來加入封面。由於託管在 Facebook 上的影片不提供直接連結,因此您需要將影片託管在其他地方,才能做為封面使用。

您可以在清單項目內使用部分 HTML 標籤,例如將文字變為粗體或加入連結。若要自訂色彩或字型樣式,您可以使用 Facebook 粉絲專頁介面上的樣式編輯器(「設定 -> 即時文章」)。

如果您使用 <video> HTML 元素來內嵌影片,因為我們不支援依序播放多部影片,所以無法在即時文章中加入影片播放清單。

如果您將影片播放器內嵌為 iframe 中的社交內嵌功能,只要內嵌的播放器提供支援,應該就可以在即時文章中加入影片播放清單。

段落式引文不受支援,必須置於段落標籤之外。

如果文章標題長到必須用兩行顯示,動態消息只會顯示標題。如果標題可用單行顯示,則動態消息預覽還會顯示文章正文的開頭。

請檢查並未在影片中加入「data-fb-disable-autoplay」屬性。

如果只有特定用戶無法自動播放影片,請檢查並未在 Facebook 應用程式的設定中停用影片自動播放功能。您可以在這裡找到檢查這個設定的指示。

您可以透過對文章中的任一影片加入「fb-feed-cover」類別,即可在文章的動態消息預覽中顯示影片。您可以在這裡找到關於動態消息預覽的更多資訊。

每篇文章都需要在 HTML 標記中使用 op-published 類別來包含 <time> 元素,以指定文章原始發佈的日期/時間。

op-modified 類別則非必要。只有在您更新文章內容,並且要我們更新原先儲存的文章版本時,才需要使用這個類別來包含 <time> 元素。

請檢查是否將文字包裝在段落(<p> 標籤)中。您可以在這裡找到有關建立文章標記的更多資訊。

請檢查並未將 <figure> 包裝在段落(<p> 標籤)中。圖像應該包含在直接於 article 標籤下巢狀化的 figure 標籤中。

很抱歉,無法對輕影片中的個別圖像加入說明。您只可針對整部輕影片加入單一說明。

您可以參閱輕影片相關文件,以取得詳細資訊。

您可以透過在包含圖像的 <figure> 標籤上指定「data-feedback」屬性,對圖像加入按讚或留言功能。例如,加入 data-feedback="fb:likes,fb:comments" 屬性會在圖像上顯示按讚和留言功能。

如需詳細資訊,您可以參閱意見回饋屬性相關文件

指定互動內嵌功能等項目的寬度時,請使用整數值來指定以像素表示的寬度。根據預設,項目會以全寬度顯示。

若要在顯示互動內嵌功能時不含任何邊界,您可以在包含該內容的 iframe 中加入「no-margin」類別。

如果我們已經批准您粉絲專頁的 RSS 摘要,即使變更摘要網址,也無需再次提交送審。

我們會將每個粉絲專頁對應到唯一的網域名稱。RSS 摘要本身的網址不需要和這個網域名稱相符。不過,摘要內個別文章的標準 URL 必須屬於相同網域或其子網域。如果您只是變更 RSS 摘要的網址,並不會造成任何問題。

如果您同時更新文章的標準 URL 來指向新網域,則需要透過合作夥伴經理要求這個網域更新,他們應該能夠引導您完成程序。

iOS SDK

請確認您的 Facebook 應用程式已設定真正的 iPhone Store 編號、iPad Store 編號(如果是測試用途,並不需要使用您真正的編號。您可以使用 Apple App Store 提供的任一應用程式編號),而且應用程式中心列出的平台中也啟用了 iPad 版的 iOS。

系統的設計就是如此。「動態」對話方塊會發佈含有附件的內容,因此無法自訂其他附件。

Javascript SDK

若要將圖像最佳化以產生絕佳的預覽畫面,請參閱此處文件所提供的一些最佳作法。

只有在用戶使用 Facebook 登入您的應用程式並已經授予 publish_actions 權限時,才會提供回應資料。請另參閱此處的說明。

這是刻意的變更。我們已縮短朋友名單,為的是讓遊戲邀請和適當的玩家更具關聯性。請注意,玩家還是可以使用「搜尋」欄位選擇任意數目的朋友。

好消息是,透過這個變更,我們看到點擊率有所增加,整體 CTR 也有相當大的提升。我們期望讓這個管道更臻完美,也希望能夠找到全新的方式來確保向理想用戶顯示適當遊戲。

分享連結

網路爬蟲會尋找 AAAA 紀錄,並在找不到該紀錄時回傳程式碼 0 作為回應。 確保您在變更網址或伺服器時,已正確更新 AAAA 紀錄。

請參閱更新網址以瞭解更多資訊。

變更 og:title、og:image 等內容,只會套用到之後分享的連結。

用戶或粉絲專頁分享連結後,若該則貼文有超過 50 次互動(留言、讚、分享等),就無法變更其標題。此舉旨在避免網站在您與其互動後,變更了連結的詳細資訊,讓您認為自己是與其他網站互動。其他所有屬性則可隨時修改。

如果已分享連結並更新圖像,除非您在原分享貼文重新整理圖像,否則貼文會繼續顯示舊圖像。

若要重新整理貼文的連結圖像:
  1. 前往動態消息的該則貼文。
  2. 點擊貼文右上角的刪節號。
  3. 選擇重新整理分享的附件

我們會在您對標題採取了一些動作後將標題凍結(如此處所述:更新網址

許多因素會影響圖像裁切方式。例如,我們會盡量讓能偵測到的臉孔出現在圖像中央。

若是大型圖像,圖像長寬比越接近 1.91:1 越好,這樣不需裁切也能在動態消息中顯示完整圖像。

專頁貼文的連結分享一向以大型的橫向圖像呈現,桌面版和行動版動態也是如此。請嘗試將圖像長寬比盡可能保持為 1.91:1,以便在動態顯示未經裁切的完整圖像。

這可能是因為我們的內容過濾系統將連結標示為異常。如果您認為系統判斷錯誤,請在使用說明網站回報問題,並務必附上相關網址。

圖像以非同步方式快取,因此用戶第一次分享您的內容時可能不會轉譯圖像。您可以執行下列其中一項來避免這種情況:

  • 使用 [分享偵錯工具](/tools/debug/)來觸發抓取,以預先快取圖像
  • 使用 [og:image:heightog:image:width 標籤](/docs/sharing/opengraph/object-properties#image)來明確指定圖像

所有的按讚和分享次數都是連結到特定網址(即所謂的標準 URL)。變更網站結構來使用新網址,便可將按讚和分享次數轉移至新網址。

請參閱更新網址以瞭解更多資訊。

所有的按讚和分享次數都是連結到特定網址(即所謂的標準 URL)。變更網站結構來使用新網址,便可將按讚和分享次數轉移至新網址。

請參閱更新網址以瞭解更多資訊。

小於 600 x 315 像素、大於 200 x 200 像素的圖像,都會以小正方形圖像顯示。

因為圖像網址會用來快取不同圖層的資源,我們將所有圖像網址均視為不可變動,因此如果您要取代圖像,必須使用新的網址。隨著快取保留時間到期,我們會擷取新的圖像,此問題便自然迎刃而解。

如果您已使用不同網址卻仍看見舊的圖像,您可前往分享偵錯工具並重新抓取網址:

網址代表的是資源(粉絲專頁/圖像)的標準位置,因此所有網址皆必須為絕對網址,以便我們將按讚和分享次數妥善轉移至正確的網址及快取圖像。

這表示原始圖像已無法使用、檔案過大,或因暫時性的問題而無法擷取。確保我們的網路爬蟲可抓取圖像網址,檔案不超過 8 MB 且延遲顯示的時間在幾秒之內。

在變更網頁的 og:image 時,請務必確認您未移除網站的舊有圖像。若是移除了舊圖像,現有的分享圖像就會顯示為白色方塊。

行銷 API

原因在於資料中心之間的複寫延遲。這個程序需要數秒鐘才能完成,在此之前,無法透過 API 存取該物件編號。

如果您在完全儲存前就嘗試讀取廣告詳細資料,可能會發生 GraphMethodException,訊息如下:Unsupported get request. Object with ID 'XXXXXXXXXXXXXXXXXX' does not exist, cannot be loaded due to missing permissions, or does not support this operation.

請稍候片刻再嘗試 GET 廣告詳細資料,就可避免這個問題發生。

有時候,嘗試在特定行銷活動中使用特定廣告創意時,您可能會遇到驗證錯誤。 行銷活動的目標與您所使用的廣告創意不相容時,就可能會發生這種情形。 例如,如果您的廣告創意指向畫布遊戲,行銷活動目標卻是「MOBILE_APP_INSTALLS」時,就可能會發生這種情形。

若要解決您可能看到的驗證錯誤,您可以遵循行銷 API 驗證最佳作法

請檢查未含有相關項目的上傳連線階段沒有出現任何失敗。

只有在 deletion_enabled 設為 true 時,才會將成功上傳連線階段的動態中已不存在的項目刪除。

如果您遇到這個錯誤,請檢查要指定的廣告帳號狀態。廣告帳號的狀態為未結清時,經常會傳回此錯誤。

這是預期的行為,因為粉絲專頁洞察報告的後端資料只會儲存 2 年。因此,呼叫預期會傳回零值。唯一不會是零的項目是貼文上的內嵌按讚數/留言數/分享次數,因為這些資料會由貼文本身保留。

請檢查目標設定規格的語法,尤其是要確認目標設定規格具備有效的 geo_locations 參數和值。

使用特定目標建立廣告時,會設定預設轉換規格。如果您對轉換規格做出變更,就會覆寫現有的規格。

請注意,特定目標不會有預設轉換規格,而必須明確指定。

這可能是因為您設定為目標的國家/地區的 work_positions 廣告受眾規模太小,無法影響觸及人數預估。我們將持續收集資料,希望能夠改善新增到 work_positions 排除的人數,進而影響觸及人數預估。

會發生這種情況,是因為您的應用程式啟用了串流貼文網址安全移轉。

如果您的應用程式已開啟此設定,系統就不會允許建立任何種類的連結貼文廣告,除非這類廣告重新導向至您應用程式設定中參照的畫布網址。除非您的應用程式是畫布應用程式,而且只發佈重新導向回畫布應用程式網域的動態,否則不應該要求啟用此功能。

該用戶很可能是透過企業管理平台與帳號建立關聯,因此不會顯示為明確的圖形 API 關聯。

請確認您已在適當的目標設定欄位中指定合作夥伴類別。從「/partnercategories」端點擷取的合作夥伴類別會包含名為「targeting_type」的欄位,用於指定您在指定目標設定類型時,需要使用的目標設定欄位。

例如,如果您的合作夥伴類別傳回的「targeting_type」為「behaviors」,則您必須在目標設定規格的「behavior」欄位中使用該合作夥伴類別。

您可以在以下網址找到更多有關目標設定類型和合作夥伴類別的資訊:https://developers.facebook.com/docs/marketing-api/partnercategories/v2.3#targeting_types

造成此錯誤的原因可能是自訂廣告受眾未設定任何包含/排除條件。解決此問題的最佳方式是建立新的廣告受眾,然後確定已設定一些包含/排除條件。

更多有關自訂廣告受眾的資訊請見此處:https://developers.facebook.com/docs/marketing-api/custom-audience-targeting/v2.3

廣告組合可以同時具有 daily_budget 和 lifetime_budget。以您帳號的幣別定義的 daily_budget 值必須至少為 100 美分,而且期間必須超過 24 小時。如果您查詢兩者任一欄位,就會同時傳回這兩個值。欄位未使用時,傳回的值就會是 0。

若要瞭解詳情,請瀏覽:https://developers.facebook.com/docs/reference/ads-api/adset

adcampaign_groups 端點會使用游標型分頁,因此不會傳回 count、limit 和 offset 欄位。建議對所有端點都使用游標型分頁,才能獲得一致的結果。

如需更多有關如何使用游標分頁的資訊,請查閱以下網址:https://developers.facebook.com/docs/graph-api/using-graph-api/v2.0#paging

可能是其中有些貼文是以內嵌建立。若要擷取這些內嵌貼文,請查看以下文件區塊底部 /promotable_posts「is_inline」欄位上的備註:https://developers.facebook.com/docs/reference/ads-api/adcreative/v2.2#object_story_spec

Messenger 開放平台

只要用戶回覆第一個問題,系統就會開放訊息期間。如果用戶提供的回答未符合資格或如果用戶未回覆,則系統將結束廣告體驗,廣告會將對話串控制權傳遞給目標應用程式並提供「messenger_lead_gen_incomplete」中繼資料,以便商家提供遞補體驗來將非潛在顧客轉換為顧客。請參閱 名單型廣告後的 HOP Webhook 以瞭解詳細資訊

只有在廣告內的「建立範本」對話方塊中選擇應用程式時,預設才會啟用「傳送摘要」。請注意,選擇已連結的應用程式後,您可以在廣告上停用摘要。即使未選擇應用程式,名單型廣告也會將對話串控制權傳遞給已設定的交接系統的主要接收者,或單純釋出對話串控制權。潛在顧客經提交後,任何後續聯絡訊息都會傳遞至已訂閱的應用程式。應用程式可以查詢轉換 API 以擷取訊息紀錄,並取得在開發潛在顧客期間分享的資訊。

名單型廣告處於刊登狀態時,預設會封鎖 Send API 和 Webhooks。Messenger 名單型廣告應用程式的應用程式編號:413038776280800 會擁有對話串控制權。您可以使用廣告內「建立範本」對話方塊上的「封鎖 Send API」切換開關來停用此行為

潛在顧客提交流程結束後,應用程式會取得用戶訊息的 Webhooks,並能夠回覆他們。如果在應用程式中選擇其中一個應用程式,則只有已選擇的應用程式可以回覆及取得訊息管道的 Webhooks。訊息期間將為開放狀態,且應用程式可以使用 Send API 進行回覆

應用程式可透過應用程式網站使用 Facebook 登入 進行安裝,並會授予特定粉絲專頁 pages_messaging 權限。經授權的應用程式會顯示於進階訊息內的粉絲專頁設定中。

系統只會顯示粉絲專頁授權的應用程式。您可以在進階訊息內的粉絲專頁設定中看到經授權的應用程式。應用程式可透過應用程式網站使用 Facebook 登入 進行安裝,並會授予特定粉絲專頁 pages_messaging 權限。

您應在以下時間點告知用戶自動化聊天室功能(即「Bot(機器人程式)」)是與自動化服務互動:

  • 在展開任何對話或訊息對話串時
  • 經過很長時間後
  • 當聊天室功能從真人互動轉變為自動化體驗時

如需深入瞭解此政策,請點擊這裡

若適用法律另有規定,請務必告知用戶自動化聊天室功能(即「Bot(機器人程式)」)是與自動化服務互動。即使適用法律沒有相關規定,也建議您揭露此資訊,避免用戶感到驚訝。如需參閱此政策的詳細資訊,請點擊這裡

是的,單一 Facebook 應用程式可以訂閱至多個粉絲專頁。一旦進行應用程式審查(例如 pages_messaging 權限),該應用程式就能夠訂閱以接收多個頁面上的 Webhook。您可以根據承載自行決定取得每個 Webhook 的環境。

可以,您可以讓多個應用程式訂閱粉絲專頁。當有多個應用程式處理相同對話時,建議使用 交接通訊協定 來處理在任何指定時間擁有對話串的 Bot(機器人程式)。

如果該用戶已經刪除對話串,就會發生這種情況。這會造成 Bot 無法再向該用戶傳送訊息。當該用戶向 Bot 傳送訊息而重新展開對話後,Bot 就能夠與該用戶進行通訊。

針對 Messenger 平台整合,使用平台測試用戶的因應措施如下:

  1. 在應用程式的角色頁面,點擊「新增」按鈕,建立新的測試用戶。
  2. 切換為此應用程式授權測試用戶?選項,然後授予「manage_pages」「page_messaging」權限。
  3. 使用「編輯」按鈕,取得這位用戶的存取權杖(使用第 2.6 版)。請儲存此存取權杖以供稍後使用。
  4. 使用編輯按鈕,以該測試用戶的身分登入。
  5. 登入後,以測試用戶的身分建立粉絲專頁。
  6. 使用該測試用戶的用戶存取權杖,取得這位用戶的粉絲專頁存取權杖。您可使用以下呼叫來完成這項操作:
    https://graph.facebook.com/v2.6/me/accounts?access_token=[TEST_USER_ACCESS_TOKEN]
    說明文件
  7. 使用這個粉絲專頁存取權杖,將 Facebook 應用程式連結到粉絲專頁:
    https://graph.facebook.com/v2.6/me/subscribed_apps?method=POST&access_token=[TEST_USER_PAGE_ACCESS_TOKEN]
            
    說明文件
  8. 按照上述步驟操作後,您就會收到測試粉絲專頁的即時更新,並且能夠從測試粉絲專頁傳送訊息給測試用戶。 除了上述步驟之外,如果存取權杖太快到期而無法測試,您可將存取權杖替換為長期權杖。請按照此處的說明文件進行:
    GET /oauth/access_token?  
        grant_type=fb_exchange_token&           
        client_id={app-id}&
        client_secret={app-secret}&
        fb_exchange_token={short-lived-token} 
            

發生這類錯誤可能有以下幾個原因:

  • 您使用來自「Facebook 登入」的編號: 來自「Facebook 登入」的用戶編號不應用於傳送/接收 API。只有透過 Messenger 平台驗證取得的用戶編號才可用於 Messenger 平台
  • 您使用的編號有不正確的粉絲專頁存取權杖: 用於 Messenger 平台的用戶編號侷限於粉絲專頁的範圍,因此是粉絲專頁特定的用戶編號。如果您使用有效的用戶編號,但使用的粉絲專頁存取權杖與不同的粉絲專頁相關聯,則呼叫會失敗。請務必使用與相同粉絲專頁相關聯的用戶編號和粉絲專頁存取權杖。
  • 您傳送到最近並未驗證的電話號碼: 使用傳送 API 搭配電話號碼時,只有在電話號碼最近經過驗證時,我們才會傳送訊息。即使顯示電話號碼已經過驗證,但如果最近並未驗證,傳送仍可能失敗。請重新驗證電話號碼,然後等候 24 小時後再試。

使用「傳送到 Messenger」外掛程式時,您可使用 data-ref 參數作為傳遞參數,以傳遞任何有關點擊內容的資訊。

用戶也可能透過在 Messenger 中搜尋來探索您的粉絲專頁。在這種情況下,您就沒有傳遞參數。您可使用帳號連結功能,將對話串與您網站上的用戶帳號建立關聯。

您可以前往「Messenger 設定」底下的應用程式主控板,然後使用名為「顯示最新錯誤」的按鈕查看 Webhooks 是否收到回覆 200 或失敗。

我們提供一個可顯示最新 Webhook 錯誤的工具。在 Webhooks 無法傳遞的情況下,Facebook 伺服器會取消訂閱您的網址。若要尋找該工具,請依序點擊「應用程式主控板」>「Messenger」>「設定」,在 Webhooks 卡中找到名為「顯示最新錯誤」的按鈕

請確定 Webhook 以狀態代碼 200 回應。這樣會告知我們已成功收到 Webhook。如果您未傳回狀態代碼 200,我們會重新嘗試呼叫,直到成功完成為止。此外,如果 Webhook 很長一段時間都未傳回狀態代碼 200,我們就會傳送開發人員重要通知。

另請注意,成功狀態代碼必須即時傳回。Webhook 呼叫會在 20 秒後逾時。請務必在設計程式碼架構時,以非同步的方式處理 Webhook,以便可立即傳回成功狀態代碼,然後分別處理 Wehbook。

對 Webhook 發出的呼叫會在標頭中包含名為 X-Hub-Signature 的欄位,您可使用這個欄位來驗證呼叫是否來自 Facebook。

需要兩個步驟才能接收回呼。首先,確定 Webhook 是否正確設定(https://developers.facebook.com/docs/messenger-platform/webhook-reference#setup)。當 Webhook 正確設定時,畫面會顯示指示器。

接著,您必須訂閱每個粉絲專頁。畫面會列出所有訂閱的粉絲專頁。

如果對 Webhook 的呼叫長時間都失敗,系統會將您的應用程式取消訂閱,您就必須重新新增 Webhook 並重新訂閱粉絲專頁。

開放社交關係圖

內容很可能需要重新抓取,而且會適時自動執行,或可透過偵錯工具手動觸發。

除了提供粉絲專頁的 OG 標籤以外,分享的開放社交關係圖動態時,您無法控制貼文在動態消息或動態時報上的顯示方式。Facebook 會自動將貼文最佳化,以確保您的內容能夠獲得最多的互動。

是的,動作連結功能已經停用。我們已經從 Facebook 網站移除動作連結的支援,因此開放平台也會停用此功能。我們將來可能會再次推出此功能,但是目前並無此規劃。

如果您的網頁使用開放社交關係圖中繼標籤,而且含有 og:image 項目,我們就會擷取該圖像,並且顯示在預覽中。此外,如果您的網站同時提供 og:image、og:image:width 和 og:image:height,則即使是第一次建立的分享,還是使用該圖像。

如果未提供這些資訊,就表示您必須等候網路爬蟲先擷取與分析圖像。請參閱 http://ogp.me/#structured 以查看處理範例。

Rest API

系統的設計就是如此。REST API 很久以前就停用了,無法繼續運作,因此會有所限制,也就是粉絲專頁存取權杖無法搭配 REST API。

社群外掛程式

您可以使用 JS SDK 中的「locale」參數設定「讚」按鈕的地區。這種方式適用於未登入的用戶。如果用戶已登入,系統也會將用戶的語言偏好列入考量。如果用戶的語言偏好設定為特定語言,「讚」按鈕就會顯示為該語言。

若要測試這種行為,請在未登入 Facebook 的情況下瀏覽您的頁面(或使用瀏覽器的私密連線階段)。

分享內容到 Facebook 時,預先填入文字區域將違反 Facebook 政策。您的應用程式用戶必須自行填入想要分享的文字。

分享時預先填寫文字區域將違反開放平台政策第 2.3 節(https://developers.facebook.com/policy/#control)。我們會強制執行此政策,確保用戶在 Facebook 上分享的內容完全是自己想要分享的,而不會不小心分享並不認同的文字。

如果您變更或修改網頁的網址,就會發生這種行為。每個置放留言外掛程式的網址都會視為單獨的開放社交關係圖物件,而且留言會與該物件建立關聯。因此,如果您修改網址,就會建立新的物件,因此現有的留言可能不會顯示在網頁上。

不可以,您不能透過 API 對留言外掛程式發佈留言。

分享外掛程式不會允許您傳入自訂參數,而且會改為直接從粉絲專頁的開放社交關係圖中繼標籤載入中繼資料。

若要深入瞭解內容分享的最佳作法,請參閱此文件: https://developers.facebook.com/docs/sharing/best-practices

WhatsApp Business API

Yes, Whatsapp Flows can be sent with On-Premises API. You can learn more about Whatsapp Flows here, or learn how to get started with Whatsapp Flows and On-Premises API here.

No this is not possible. Numbers that are registered under WABAs (WhatsApp Business Accounts) can only message regular WhatsApp accounts.

We will provide a seven day grace period post sending the warning. This will allow time for businesses to adjust their behavior. If businesses continue to exceed our internally set threshold of calls to the Contacts API vs. number of messages sent, we will permanently disable the phone number.

Interactive messages can be reopened by the user in order to resend an option. This is in case of mistyping the desired option or wanting to choose a new option.

Through user testing we’ve identified 10 as the optimal number of rows to provide a good user experience. If you have a list of more than 10 options, and cannot condense into one list message, we recommend creating an additional step in the flow and using two list messages. During testing businesses had higher response rates and conversions with this approach than using text-based lists.

Through user testing we’ve identified 3 as the optimal number of buttons to provide a good user experience. If you have a list of more than 3 options, and cannot condense it into one button message, we recommend using list messages. During testing, businesses had higher response rates and conversions with list messages than using text-based lists.

There may be a very small number of users for whom their app version does not support this feature, the business will receive a webhook notification throwing an error that describes why the message was unable to be received. It is up to the business to determine how to handle this error elegantly. Best practice would convert the interactive message to a text-based list to allow the user to complete the workflow.

If there is a delay in a subset of numbers, then it is likely not an issue affecting the customers integration but rather an issue on the recipients end, these delays in delivery can happen for a number of reasons. See Send Message Performance, Delays for more information.

不行,目前我們不支援變更預設的媒體儲存空間路徑(/usr/local/wamedia/)。所有媒體儲存空間都必須位於此預設位置才能正常運作。

沒有,目前我們必須使用 AWS EFS 在核心應用程式和網路應用程式之間分享媒體磁碟區。

核心應用程式將檢查核心應用程式容器內的 /usr/local/waent/data/usr/local/waent/log 目錄,確保至少有 10 MB 的儲存空間,否則將會顯示此嚴重錯誤。

請檢查您的記錄和資料目錄,確保您有足夠的空間。

不行,目前無法在同一 WhatsApp Business API 用戶端設定中執行多個電話號碼。我們正在研究適當的解決方案,於將來提供這項功能。

請使用資料庫記憶體回收 services API 端點清除 messageStore.messagesmessageStore.messages_receipt_log 資料表中的訊息和對應的訊息回條。

請再次檢查 pass_through 應用程式設定。如果您已啟用 pass_through 並使用 WhatsApp Business API 用戶端 v2.29.1 或以上版本,將不會收到任何讀取狀態回呼。

如果您想接收讀取狀態回呼,請停用 pass_through 應用程式設定。請注意,若停用 pass_through,您的資料庫儲存可能會快速增加。如需管理資料庫的詳細資訊,請參閱資料庫管理文件

資料庫記憶體回收會定期清除 messagesmessages_reciept_log 資料表,以協助管理資料庫。

記憶體回收器會保留特定訊息,以便成功進行傳送/處理。例如,保留傳入的訊息一段時間,以允許企業整合工具將訊息標記為已讀。

核心應用程式將以隨機的間隔(即每隔幾小時)執行記憶體回收。如此可避免因資料庫爭用而導致高可用性堆疊的潛在效能下降。

記憶體回收獨立於回呼佇列。例如,如果 Webhook 伺服器有 4 天無法使用,則將儲存回呼以在 Webhook 伺服器連接恢復時進行傳送。

只有當收件人已將您的企業電話號碼保存為聯絡人或您擁有官方商業帳號時,連結才會呈現為可點擊。

v2.29.x 之前,傳出的訊息佇列大小會隨時間增加是因故障之故。升級至 v2.29.3 即可解決此問題。

無法使用 QR 條碼和短連結的分析工具,因為我們限制記錄的資料量以保護用戶隱私。

您將負責根據用戶的預期地點和語言來使用適當的 QR 條碼。

QR 條碼現在可以直接於 WhatsApp Business Management API 內產生和管理,用戶可以使用 WhatsApp、iOS 或 Android 相機對其進行掃描。

此外,透過 WhatsApp QR 條碼

  • 可以完整自訂預先填入的訊息,並且可以隨時變更或刪除內容,
  • 用戶將一律直接進入應用程式,沒有任何插頁廣告頁面,
  • 針對已失效的條碼,應用程式內部體驗會向用戶傳送清楚的訊息。

如果用戶嘗試存取已刪除的 QR 條碼或短連結,將會看到錯誤訊息,指出 QR 條碼/短連結已失效。

如果用戶安裝了 WhatsApp 桌面用戶端,將會啟用與您企業的對話。若沒有安裝,系統將提示用戶安裝 WhatsApp 桌面用戶端。

新的短連結可讓您隨時編輯或刪除與連結相關聯的預先填入訊息。短連結還能將網址的語法簡化為隨機代碼,如此就不需要在網址中內嵌訊息,並可遮罩電話號碼。

建議使用 .svg 檔案格式,以在列印材質上獲得最佳品質。

單一 WABA 電話號碼不能與超過 2,000 個 QR 條碼和短連結建立關聯。

您可以在 WhatsApp Business Management API企業管理平台用戶介面中檢視、建立、編輯和刪除 QR 條碼以及短連結。

We are announcing the deprecation of Groups through the WhatsApp Business API. Starting July 8, 2020, only API phone numbers in a group created prior to July 8th can continue to use/manage Groups through the WhatsApp Business API. All other API phone numbers won’t be able to create/manage Groups through the Whatsapp Business API. On October 8, 2020, we will deprecate this feature for all API phone numbers (i.e., API phone numbers will be removed from their groups and no longer be able to send messages to their group).

v2.25.x 可提升較先前版本更高的出站和入站效能。此最佳化仰賴於建立其他資料庫連線。對某些部署而言,這可能導致資料庫連線數量增加並達到設定的限制。為了維持提高的效能,您可以增加資料庫伺服器可接受的最大連線數量。如果這麼做不可行,您可以變更 axolotl_context_striping_disabled 參數來停用此行為。如需變更參數的詳細操作資訊,請參閱應用程式設定文件

不適用。訊息傳遞限制目前僅適用於企業初始的訊息(通知)。

從 WhatsApp Business API 將圖像以相簿方式傳送時,必須連續傳送至少 4 個圖像。如果用戶的對話檢視在接收圖像時為使用中,必須等到下次瀏覽才能使用相簿檢視。

符合下列任一條件時,系統將不會建立相簿:

  1. 對圖像加入文字
  2. 未讀取的分隔線 - 用戶可看到部分圖像,但看不到其他圖像
  3. 日期頁首 - 傳遞之間的新日期

不行。WhatsApp Business API 用戶端目前無法在 Docker for Windows 上執行。針對開發需求,建議使用 Linux 虛擬機器來執行 Docker。若是生產工作負載,建議使用 Linux 伺服器以避免相容性和效能問題。

若 WhatsApp Business API 用戶端執行的版本為第 2.21.6 版,當用戶端與伺服器中斷連線時,中斷時間可能會維持幾分鐘(最多 4 分鐘),然後再重新連線。升級到第 2.23.4 版可減少用戶端在嘗試連結至伺服器時的停機時間。

471 錯誤代碼與依品質決定的速率限制有關。如需詳細資訊,請參閱「依品質決定的速率限制」文件

所有企業都始於最低層級,在發出更多優質的訊息後會自動升級到更高層級。

是的,如果所傳送的訊息範本未顯示於接收端,您將收到「失敗」狀態回呼,其錯誤物件含有「結構無法使用」通知,表明該則訊息無法顯示。根據收件者的不同,您可能還會收到「已傳遞」狀態回呼,該回呼僅指示訊息已傳遞給收件者,但之後收件者無法顯示訊息。

以下是訊息範本傳送端驗證錯誤及其可能成因:

  • 「語言(your-language)中不存在任何訊息範本」或「語言(your-language)和區域(your-locale)中不存在任何訊息範本」- 指定的語言套件不存在。請檢查您的企業管理平台帳號。
  • 「語言(your-language)中不存在範本(your-template-name)」或「語言(your-language)和區域(your-locale)中不存在範本(your-template-name)」- 您嘗試使用的範本不存在(尚未建立或尚未核准)。如果您嘗試傳送含有已刪除範本的訊息,也會收到此錯誤。
  • 「localizable_params num1 的數量與預期的 params num2 數量不符」,您嘗試傳送的訊息範本,其參數數量與預期的參數數量不符。請檢查 API 叫用是否正確。
  • your-template-name 是一個 Rich 型範本,需要使用範本訊息 API」,您嘗試將媒體訊息範本以一般訊息範本的方式傳送。請確認訊息類型為 template。如需詳細資訊,請參閱媒體訊息範本文件
  • 在企業管理平台中核准(或刪除)範本後,WhatsApp Business API 用戶端最多可能需要 20 分鐘才能收到更新的範本。如果您嘗試傳送含有剛經核准範本的訊息,並且收到該範本不存在的錯誤,可以在等待前述指定時間後重試傳送該訊息。

系統會將重複訊息傳送到 WhatsApp Webhook,因為系統的唯一保證是至少會收到一次(而不是只收到一次)。如果這會影響您處理訊息的方式,建議您根據訊息編號來刪除重複的 Webhook 訊息。

如果該電話號碼尚未用於 WhatsApp Business API,就可以使用。請按照此處說明的移轉步驟,重複使用該電話號碼。

自第 2.18.26 版起,應用程式 Stats 端點允許匯出 Prometheus 文字格式的內部衡量指標。如需詳細資訊,請參閱執行個體監控文件

如果商業檔案僅部分填入,將傳回空白 profile 物件。請升級至 v2.21.4 以解決此問題。

如需深入瞭解完整填寫商業檔案的相關資訊,請參閱商業檔案設定文件。

如果設定 AWS 部署時收到類似下列錯誤,請嘗試更改為 8 個或更少字元的堆疊名稱。

國家/地區名稱(兩個字母代碼)[AU]:省/市名稱(完整名稱)[Some-State]:位置名稱(例如城市)[]:組織名稱(例如公司)[Internet Widgits Pty Ltd]:組織單位名稱(例如部門)[]:一般名稱(例如伺服器 FQDN 或您的名稱)[]:字串太長,必須為少於 64 個位元組長的一般名稱(例如伺服器 FQDN 或您的名稱)[]:電子郵件地址 []:錯誤,設定檔中未指定物件的問題導致憑證要求建立internal-wa-inc-name-LB-123456789.ap-southeast-1.elb.amazonaws.com 的裝置密鑰

訊息範本中允許的參數數量沒有限制。

每個 WhatsApp 企業帳號的訊息範本數上限為 250 個。

若因故(例如用戶端離線)未能傳遞 Webhook 事件,或是 Webhook 要求傳回 200 之外的 HTTP 狀態碼,我們將重試傳遞 Webhook。我們會繼續重試傳遞,並將延遲增加至特定逾時(通常為 24 小時,但可能有所不同),或直到傳遞成功為止。

在某些情況中,您可能需要更多時間來處理顧客查詢,並且只能在 24 小時後回覆。我們建議建立訊息範本來執行下列步驟:

  • 傳遞結果給用戶,或
  • 提示用戶進行回覆以啟動顧客服務視窗。

在上述兩種情況中,請務必盡可能為訊息範本提供更多內容。例如:

  • 「您好 {{1}},關於您之前回報的問題,我們很遺憾地通知您 {{2}}。造成您的不便我們深表歉意。」
  • 我們已就您的票證進行更新。如果您希望繼續支援,敬請回覆。」

WhatsApp 進行實驗以衡量和瞭解 WhatsApp Business API 通知對用戶體驗和整體產品的一般影響。如果您傳訊的用戶是這些實驗的其中之一,即使他們已選擇接收通知,也不會收到您的通知。

如果您備份目前的設定並將其還原到新裝置,註冊資訊會隨其餘實作部分一併轉移。如需詳細資訊,請參閱備份和還原設定文件

有,網路應用程式容器和核心應用程式容器的記錄檔輪替方式稍有不同:

  • 網路應用程式:保留最後 30 個記錄檔。記錄檔只會在大小超過 20MB 時輪替。
  • 核心應用程式:保留最後 30 個記錄檔。記錄檔只會在大小超過 15MB 時輪替。系統會壓縮輪替的檔案。

聯絡支援團隊,提供所有相關資訊。我們將進行調查並關閉任何假帳號。

所有 WhatsApp Business API 用戶端組建自發行日起有效期為 6 個月。如果您看到此錯誤,請儘快升級到最新版本。

在傳送訊息之前,您必須先檢查聯絡人是否存在。如需操作方法的詳細資訊,請參閱聯絡人文件

此錯誤是由於核心應用程式尚未初始化,表示註冊可能未徹底成功完成,請先嘗試註冊,然後再呼叫其他端點。安裝 WhatsApp Business API 後的第一步驟是登入,第二步驟是註冊。在向任何其他端點發出要求之前,都必須執行這兩項步驟。

注意:v2.27.8 開始,fallback 語言政策已過時停用,deterministic 語言政策是目前的預設政策。

如果您使用新語言建立翻譯,必須將使用的所有元素翻譯成該語言。否則,您可能會收到「結構無法使用」錯誤,因為收件者的手機找不到預期的語言元素。若使用遞補政策傳送範本訊息,將看到這些結構無法使用的錯誤。

如果目前建立語言翻譯不是您的選項,可以使用決定性政策來避免這些錯誤。

來自用戶的訊息酬載可以是文字或媒體檔案。

若是文字,將視為沒有任何已知危險。

若是媒體檔案:

  • 通常,企業應具備一些防護軟體(即防毒、反惡意軟體等)來分析任何潛在威脅。
  • WhatsApp 無法識別或檢查端對端加密傳輸的檔案內容(此亦適用於純文字內容)。
  • 有一個選項可以防止在 WhatsApp Business API 用戶端中自動下載媒體檔案。如果企業不想接收用戶的任何檔案,可以將 auto_download 欄位設為空陣列。

不行,無法使用 WhatsApp Business API 偵測相同手機號碼的裝置。

當電話無法讀取範本訊息時,會發生結構無法使用的錯誤。

範本儲存在伺服器上。使用 訊息 節點傳送範本訊息時,系統只會將命名空間、語言、元素名稱和本地化參數傳送到電話,而不是傳送整個訊息。當這些值傳遞到電話時,系統會嘗試轉譯訊息。

如果轉譯過程中發生任何錯誤,系統會傳送 「結構無法使用」 錯誤到包含收件人和訊息編號的回呼網址。這些錯誤可能是肇因於命名空間錯誤、本地化參數不符、元素名稱錯誤等等。

請前往 Facebook 企業管理平台,在 WhatsApp 管理工具中查看正確的參數數量。請仔細檢查命名空間是否正確以及元素名稱是否存在。

沒有為所有使用中的範本建立翻譯是一項常見的錯誤來源。例如,如果您通常會傳送 2 個範本,並為其中一個範本新增語言翻譯,請務必同時為另一個範本新增該語言翻譯。如果您計劃支援多種語言,您應該為所有範本提供所有支援語言的翻譯。

好消息是, 「結構無法使用」 錯誤絕大部分是肇因於 訊息 API 呼叫中的錯誤,這可以藉由變更傳送承載來修復。

您可以在 Facebook 企業管理平台的 WhatsApp 帳號中註冊和刪除新舊電話號碼。

  1. 在您的 WhatsApp 帳號中,前往設定
  2. 點擊 WhatsApp 管理工具
  3. 選擇電話號碼頁籤。您可以在此管理該帳號的所有電話號碼。

圖像可加入說明文字。Android 和 iPhone 圖像的說明文字皆以完整長度顯示。

若是文件,這類文字會取代檔案名稱。這並不會在用戶裝置顯示為說明文字,而是顯示為檔案名稱。iPhone 會顯示完整文字,Androids 則會截斷檔案名稱;這是目前 WhatsApp 在兩種裝置上的技術限制。

如果因使用「簡訊」嘗試次數過多而註冊失敗,且收到「存取遭拒」的訊息,請嘗試使用「語音」註冊。

目前是 7 天。如果超過 7 天未更新快取,無論套件是否已有該元素,系統都將從伺服器中提取最新的語言套件。

裝置會先從快取載入內容,此時若存在元素,將使用該訊息範本來解壓縮訊息。因此,最安全的方式不是修改訊息範本,而是加入具有不同元素名稱的新範本。如此一來,可確保在找不到該元素時重新下載語言套件。訊息範本的儲存成本可忽略,因此無需刪除訊息範本。

如需詳細資訊,請參閱傳送訊息範本 - 語言

為了確保企業和用戶獲得高品質的體驗,我們提供有限的公開預覽。我們持續擴大合作機會,如有意願請提交有關貴企業的詳細資訊以供參考,或是與您現有的 Facebook 代表聯繫。

透過 users 端點將用戶登出,可以將指派給該帳號的所有驗證權杖設定為無效。刪除用戶也具有相同效果,但這個動作的影響程度要大得多。請記住,透過 users 端點登入用戶,系統會傳回新的驗證權杖,但不會將該用戶已流通的驗證權杖設定為無效。擁有之前已佈建權杖的任何用戶將可繼續使用,直到該權杖過期或透過前述任一方法將其設為無效。

如果您看到此錯誤,但所缺少的必要參數是在 JSON 主體中設定,則可能是 JSON 剖析錯誤。若因 JSON 格式錯誤而無法剖析整個 JSON 酬載,就可能發生此錯誤。請檢查這些參數值是否含有無效的 JSON 字元,例如字尾的歸位字元。複製參數時,有時可能會附帶額外的空白,其可能含有會破壞 JSON 的字元。

原因有很多。您的核心應用程式可能已關閉,或資料庫設定不正確。如果不是這些原因,請查看您的核心應用程式記錄檔(或是如果您正在執行多點連線,則查看主節點核心應用程式記錄檔)。如果您看到資料庫連接錯誤,可能是資料庫的連線數不足。如需此錯誤的相關資訊,請參閱 MySQL 文件PostgreSQL 文件

建議您提高資料庫中的資料庫連線數。1000 個資料庫連線應已足夠,但請依據充分資訊自行決定適當的連線數。如果錯誤仍然存在,請開立支援票證。

訊息範本可能遭拒的原因包括:

  • 含有潛在的不當內容,例如辱駡性語言或類似垃圾訊息的內容
  • 含有促銷內容
  • 不符合選擇的標籤類型
  • 格式不正確

「拒絕連線」錯誤可能表示核心應用程式未執行,請使用 docker ps 查看核心應用程式是否執行中。如果沒有執行,請查看 Docker 記錄檔。核心應用程式可能無法連接到資料庫,請確認您已正確設定資料庫。

如果 Docker 橋接損毀,就會發生此錯誤。最好的補救措施是停止 Docker 服務並重新啟動。您也可以在容器上嘗試 docker restart

WhatsApp 會對所提供的號碼進行強式驗證,確認該號碼是否屬於特定手機。用戶擁有 WhatsApp 帳號即證明他們已確認該號碼,且後續沒有人使用該號碼在 WhatsApp 上註冊,但是無法保證 SIM 卡的所在地點。

另一方面,如果用戶的手機遺失或被竊,可以停用其 WhatsApp 帳號。若要瞭解用戶如何停用其帳號的詳細資訊,請參閱手機遺失或被竊常見問題

如果顧客手機號碼停用後仍使用 WhatsApp,則可以繼續存取 WhatsApp,直到手機號碼經重新指派或重新註冊為止。

WhatsApp strongly verifies whether number provided actually belongs phone. The fact that a user has a WhatsApp account is proof that they confirmed the number and no one else has used that number to register on WhatsApp subsequently. However, It is not a guarantee of the physical location of the sim.

On the other hand, if users phone is lost or stolen, they can deactivate their WhatsApp account. You may read to know more about how users can deactivate their account here.

若發生這項錯誤,表示資料庫未正確設定。

  • 請確認您使用的是 MySQL 5.7 或以上版本,或是 PostgreSQL 9.5.x、9.6.x、10.x。
  • 您的資料庫密碼不可包含以下任何字元:?{}&~!()^。
  • 如果您使用的是 AWS,請確認堆疊採用短名稱。如需詳細資訊,請參閱安裝文件。

是的,TCP 連線是必要條件。如果您的企業無法開啟其他連接埠,可以使用已終止的 SSL。

如需詳細資訊,請參閱網路需求文件

這是已知的問題。有時候,使用 CloudFormation 指令碼升級 WhatsApp Business API 用戶端也需要更新 RDS 資料庫堆疊。新的 RDS 堆疊與原始堆疊的主機名稱會不同,且 Docker 容器將無法連接到資料庫。解決方案是將 SSH 放入由 CloudFormation 建立的 EC2 實例,並使用新的主機名稱更新 whatsapp.conf 檔,然後重新啟動 Docker 容器,以便其擷取新的設定。

是的,傳送訊息之前,要向 contacts 節點傳送 API 呼叫。檢查 contacts 所得出的資訊會以快取方式儲存於容器,否則可能會導致 Unkown Contact 錯誤。如需詳細資訊,請參閱檢查聯絡人文件。

Use the mcdockerreset script and tear down the webapps then use the mcdockersetup script to bring up a new webapp.


Reason: When the webapp first connects to the DB, it creates the database.yml file. it will never try to create it again. The coreapps will just not start up on a bad DB config; however, the webapp will, so you see the master and slave nodes in your DB because they were setup correctly once you got around all the DB and script issues but the webapps were started by the script in a bad state to begin with.

如果 Webhook 無法傳送回呼,系統會將回呼放入重試佇列。您不會收到初始回呼失敗後傳送的任何回呼。只有當初始失敗的回呼成功之後,其餘回呼才會跟進。

WhatsApp Business API 用戶端會透過核心應用程式容器向您傳送 Webhook 回呼。因此,您必須將 Webhook 端點設定為可接受來自核心應用程式的入站要求。

您應該註冊第二個手機號碼,並啟動第二個 CloudFormation 堆疊或 Docker 實例進行測試。如果您有兩個 WhatsApp Business API 用戶端使用同一手機號碼,伺服器會因為加密金鑰發生衝突而將您登出。建議您在正式作業用戶端執行任何移轉之前,先使用第二個環境來測試非正式作業實例。

必須使用 MySQL 5.7.x 以及 PostgreSQL 9.5.x、9.6.x、10.x。使用先前的版本會出現 Unable to initialize config store 錯誤。

當您傳送訊息時,一旦傳回訊息編號,即表示訊息要求已儲存在資料庫中。WhatsApp Business API 用戶端將繼續嘗試傳送該訊息,直到 WhatsApp 伺服器確認為止。這項流程沒有結束時間表。接著,WhatsApp 伺服器會嘗試將該訊息傳遞到用戶的手機。如果用戶的手機未在線上,WhatsApp 伺服器會將訊息儲存 30 天後捨棄。

資料庫資料表會儲存應用程式設定、聊天對話串、訊息、影音素材等相關資訊,這些都是應用程式運作所需的要素。

顧客變更 WhatsApp 手機號碼時,您的企業不會收到通知。當您使用 contacts 節點時,該手機號碼的狀態將為 invalid

不可以,每個實例只能執行單一帳號。如果您需要第二個測試帳號,第二個實例務必使用不同的手機號碼。

健康狀態檢查是一項免費服務,您可以依需求進行查詢。

如需詳細瞭解可查詢的應用程式和資料庫統計資料,請參閱統計資料文件。應用程式統計資料儲存在記憶體中,很容易查詢。資料庫統計資料需要更多資源,應只在需要時才查詢。

使用 messages 節點時,必須針對 WhatsApp Business API 用戶端將 Content-Type 標頭設定為 application/json,以正確剖析訊息正文。您還需要設定一個 Authorization 標頭,且必須包含未過期的存取權杖。有關如何取得權杖以及權杖過期時的資訊,請參閱登入與驗證文件。

儲存空間已滿時,系統執行速度可能會開始變慢。這可能是由許多媒體檔案、訊息和大型記錄檔案所造成。系統會自動輪換記錄檔,但如果佔用空間漸增,刪除才是安全之道。

系統將訊息儲存在資料庫中,您可視需求加以刪除。此外,若在應用程式設定中將 pass_through 設為 false,系統在明確刪除訊息之前,會將其儲存在資料庫中。

系統會將用戶傳送給您的媒體檔案下載至媒體磁碟區。企業可自行決定要刪除哪些媒體檔案,而刪除任何媒體檔案通常都是安全的。您可以使用 docker inspect your-container-id 檢查媒體磁碟區資料夾的位置。

請按照 Docker MySQL 指南操作,使用 Docker 在本機設定 MySQL。

請按照 Docker PostgreSQL 指南操作,使用 Docker 在本機設定 PostgreSQL。

在大多數情況下,您應該從核心和網路容器的個別實體伺服器上執行資料庫。資料庫伺服器離運算電腦應只有幾毫秒的延遲。

何時刪除由您決定。

上傳影音素材後,您將收到影音素材編號,可以用來傳送訊息說明已上傳影音素材的元素。傳送影音素材訊息時,WhatsApp Business API 將對影音素材進行加密並將其上傳到 WhatsApp 伺服器,並在伺服器中保留 14 天。之後,您可以決定透過提供影音素材編號來刪除影音素材,或保留供以後使用。雖然我們建議將影音素材保留 30 天,但仍由您根據企業政策或使用案例來決定留存率政策。

是的,在不涉及 WhatsApp 相關資料表的前提下,您可以透過其他方式使用資料庫。

請先檢查回呼是否有嚴重錯誤來診斷問題。

如果您看到「衝突:偵測到多個共用同一電話號碼的實例」,則需要檢查容器。最可能的原因是您擁有多個 Docker 容器,這些容器嘗試使用同一 WhatsApp 帳號連接到 WhatsApp 伺服器。請確認您只擁有一個使用和執行中的容器。如果您有舊容器,請先將其關閉,如此即可解除錯誤。

如果您想測試更複雜的高可用性解決方案,請參閱高可用性文件。

您可以使用主機名稱或 IP 位址來建立允許清單。

如需詳細資訊,請參閱網路需求文件「主機名稱」部分

可以!WhatsApp 允許您將訊息內選取的文字設定為粗體、斜體、刪除線或等寬格式。

是的,訊息範本支援所有 WhatsApp 訊息字元和格式,包括表情符號、粗體、斜體等。若是表情符號,您必須使用表情符號字元(複製/貼上),而不是其對等的 unicode。

只要免付費電話包含您的國碼/區碼就可以使用。原因是,系統無法不重複地識別出未含國碼/區碼的免付費電話 - 因為同一電話號碼可適用於兩個不同國家/地區。

另請注意,免付費電話的複雜度較高。通常,如果您於所在國家/地區內撥打含有國碼/區碼的免付費電號,將無法成功撥打。這表示您所在國家/地區的顧客可能會嘗試撥打顯示為企業聯絡人的電話號碼(包含國碼/區碼),而他們將無法聯繫到您。如果您重視此問題,請務必明確告知顧客。

您可以在此深入瞭解免付費電話。

不可以!在任何指定時間,您只能使用單一電話號碼執行一個 WhatsApp Business API 用戶端實例。只要您註冊第二個實例,第一個實例將啟動並失敗。我們正在研究適當的解決方案來提供這項功能。若有任何最新消息,我們將隨時通知您。

由於端點之間沒有第三方存取內容,因此 WhatsApp 將與 Business API 用戶(該用戶管理其控制之伺服器上的 API 端點)的通訊視為端對端加密。

某些組織可能選擇將 WhatsApp Business API 端點委託給第三方企業解決方案供應商管理。在此情況中,通訊仍會使用相同的訊號協定加密。但是,由於 WhatsApp Business API 用戶選擇第三方來管理端點,因此 WhatsApp 不會將這些訊息視為端對端加密。未來在 2021 年中,此情況也適用於選擇使用 Facebook 代管之雲端型 API 版本的企業。

此外,若使用 HTTPS 呼叫 WhatsApp Business API 用戶端,該資料將採用 SSL 加密(從後端用戶端到 WhatsApp Business API 用戶端)。

請參閱我們的 WhatsApp Encryption Overview technical whitepaper(WhatsApp 加密概觀技術白皮書)以瞭解詳情。

這是由舊版 iOS 用戶端中的故障所引起。隨著一般用戶數量的升級,這些錯誤應該就會逐漸減少。

否,訊息抵達的順序不保證與傳送的順序相同。如果順序對您的使用案例至關重要,建議先接聽第一則訊息已傳遞的回呼,然後再觸發第二則訊息。

您可以在外部觸發下列指令碼來清除容器的舊記錄檔:

docker exec CONTAINER_NAME /opt/whatsapp/bin/cleanup.sh

此指令碼同時適用於網路應用程式和核心應用程式容器。執行此指令碼後,系統將移除舊記錄檔,僅保留 30 個容器的記錄檔。

注意:請勿使用 WhatsApp Business API 向相同收件人重複傳送相同訊息。

造成投遞率不是 100% 的原因很多。一些常見案例包括用戶偶爾上網、停用一段時間,或者建立 優質用戶體驗

能夠透過 WhatsApp 傳遞的訊息具有非常高的投遞率。但是,無法傳遞訊息的原因很多。透過監控回呼,您可以存取訊息的確切狀態。這與使用簡訊傳送訊息有所不同,舉例來說,您無法存取最終傳遞狀態,重新傳送訊息可能在實際上產生不同的結果。

用戶手機暫停服務、沒電,或是遺失且準備購買新機並停用 SIM 卡,都可能造成訊息無法傳遞。企業用戶端的網路連線能力可能發生錯誤,也有可能系統未傳遞回呼(Webhooks)。您可以使用 health 節點監控這些情況。您可以開啟伺服器回條回呼,以瞭解該訊息已進入 WhatsApp 伺服器雲端。

如果用戶重新連線到網路,系統會將您已傳送的所有訊息傳遞給他們。對用戶來說,接收多則相同內容的訊息是一項糟糕的體驗。他們較可能封鎖您或提出抱怨,而您遭到禁用的機率會提高。

如果您傳送訊息並從 API 收到訊息編號,表示已執行可傳送該訊息的作業。請勿將相同內容重新傳送給相同收件人。

如果您在很長一段時間內發現投遞率較低,請透過以下方式提交支援案件: 直接支援

WhatsApp Business 內部部署 API 用戶端需要儲存密鑰的資料庫,以解密商家與顧客之間傳送的訊息。使用傳送者和接收者密鑰加密 WhatsApp 上的所有訊息。將顧客密鑰儲存在其行動裝置上,並將商家密鑰儲存在商家的資料庫中。深入瞭解 WhatsApp 的安全性

WhatsApp Business 雲端 API 是 Meta 託管商家資料庫的替代項目。雲端 API 允許您實作 WhatsApp Business API,無須自有伺服器的託管成本。瞭解詳情。

不需要。WhatsApp Business API 用戶端會在 WhatsApp 伺服器上開啟連接至埠 5222 或 443 的出站 TCP 連線。TCP 流量會透過此長期連線傳輸。通常,防火牆會將此歸類為允許「出站流量和已建立的流量」。當然,封包在連線建立後將來回傳輸,但連線是由 WhatsApp Business API 用戶端啟動,因此不需要允許入站連線的規則。

系統支援 MySQL 和 PostgreSQL。如果您自己執行 Docker,必須提供允許容器連線的 MySQL/PostgreSQL 資料庫。若使用 AWS 範本,系統會依預設值來設定 MySQL 資料庫。

相關要求視您的負載和情況而定。解決方案將在任何執行 Docker 的網路連線裝置上執行。例如,您可以在筆記型電腦上進行簡單的測試。

如果要設定為單一實例生產伺服器,建議至少配備 250 GB SSD、16 GB RAM 和 4 核心 CPU。不建議使用 HDD,因為 I/O 速度會成為負載的瓶頸。

如果要設定為多點連線生產伺服器,建議每個核心應用程式/Master 節點/網路應用程式容器至少配備 50 GB SSD、4 GB RAM 和 2 核心 CPU。

在大多數情況下,您應該從核心和網路容器的個別實體伺服器上執行資料庫。資料庫伺服器離運算電腦應只有幾毫秒的延遲。

此設定支援每秒傳送約 20 則訊息。

當然可以!請聯繫您的 WhatsApp 代表並提出這項要求。

目前無法這麼做。如果您無法透過 WhatsApp 處理用戶的入站回應,建議您傳送自動回覆訊息,將其重新導向至適當的支援管道。

在一般消費者案例中,若寄件者不在您的通訊錄中,且您不曾向此寄件者傳送訊息,就會發生這個狀況。在企業案例中,企業應該在首次與用戶互動時使用訊息範本來建立「信任」;如此一來 WhatsApp Business API 用戶端才能轉譯連結並使其成為可點擊的項目。

I在一般消費者案例中,若寄件者不在您的通訊錄中,且您不曾向此寄件者傳送訊息,就會發生這個狀況。在企業案例中,企業應該在首次與用戶互動時使用訊息範本來建立「信任」;如此一來 WhatsApp Business API 用戶端才會遵循「應用程式內自動下載」的設定。

很遺憾,您必須選擇其他能夠接收簡訊或語音的電話號碼,以便我們傳送註冊代碼。過去我們允許手動註冊代碼,現已不再支援此功能。之前使用手動註冊代碼的電話號碼,我們將根據需求繼續支援。對於任何新的電話號碼,我們只會透過簡訊或語音通話來傳遞註冊代碼。

如果您想使用 1800 或免付費電話,請閱讀本指南

目前無法查看有多少用戶或哪些用戶封鎖了您的企業。最佳指標是接聽狀態回呼,如果您未收到 delivered 狀態,表示用戶已封鎖您的企業或沒有網路連線。如需詳細資訊,請參閱 Webhook 文件。

如果用戶已封鎖您的企業,聯絡人 API 將繼續以有效的 WhatsApp 用戶身分傳回該手機號碼。但是,系統將永遠不會傳遞您所傳送的訊息。若為付費訊息,您將不需支付費用。

是的,當您準備好上線,即可設定新的手機號碼或變更驗證名稱。

上傳檔案大小的上限為 64 MB,此限制也適用於隨訊息傳送的任何圖像、文件或影片。

不行,WhatsApp Business API 解決方案需要未使用的手機號碼。

若要尋找媒體磁碟區的掛接點,可以執行 docker 命令。

要求

docker volume inspect whatsappMedia

回應

[
    {
        "Driver": "local",
        "Labels": {},
        "Mountpoint": "/var/lib/docker/volumes/whatsappMedia/_data",
        "Name": "whatsappMedia",
        "Options": {},
        "Scope": "local"
    }
]

然後,若要查看所有傳入的媒體檔案,可以使用接收的 Mountpoint 檔案路徑執行 ls 命令:

ls /var/lib/docker/volumes/whatsappMedia/_data/

若是 AWS 設定,系統會將媒體磁碟區掛接到主機上的 /mnt/wa/media 路徑。

針對傳出或傳入媒體檔案,系統並沒有相關的清除機制。您可以透過在檔案系統上找出媒體檔案予以手動刪除。

您可以執行下列程式碼重新啟動 Docker 容器:

核心應用程式 Docker 容器

docker restart wacore<Current_WABA_Version>

網路應用程式 Docker 容器

docker restart webapp<Current_WABA_Version>

您可以使用下列程式碼檢查目前執行的版本:

docker ps

是的!預設情況下,WhatsApp Business API 用戶端會嘗試使用 chatd 經由埠 5222 進行通訊。若要獲得最佳體驗,請為所有輸出流量開啟埠 5222。此舉並不會帶來安全問題,因為流量僅從資料中心輸出。

若無法開啟埠 5222,WhatsApp Business API 用戶端會嘗試使用埠 443。如果您的防火牆或 Proxy 仍持續終止連線,請徑向直接支援(服務)提交問題,以聯繫 WhatsApp 團隊進行偵錯。

正常運作
請改用分享偵錯工具:https://developers.facebook.com/tools/debug/sharing/。不再維護 OG 偵錯工具。
The behavior is by design. All newly created accounts go through a classification process which may last up to 45 minutes. During that time, these accounts won't be able to login to any app.
輪播廣告圖像不會在輪播廣告媒體節點傳回「media_url」,因為輪播廣告為圖像的集合。而用戶應查詢 children{media_url},以便查看子節點的「media_url」。
從 2.9 版及以上版本開始,如有貼文的廣告帳號需要更新付款方式,因而不符發佈資格,我們會篩選掉這些貼文。請再次確認您的廣告帳號具備有效的付款方式。
API 將不再支援此欄位。若要查看此欄位提供的任何資訊,請改用以下工具:https://developers.facebook.com/tools/app-ads-helper/
不將 Thread_key 納入 Webhook 事件是刻意設計的作法
「estimate_DAU」為 0 時,我們會自動針對所有項目傳回預設的 0 元建議出價 因為我們不會針對使用自訂廣告受眾的行銷活動,顯示廣告受眾規模。
網站自訂廣告受眾若有多個區塊,會使我們無法根據多個區塊辨識其各自的留存率,因此會傳回為 0 的像素編號及保留天數。 若要為此擷取規則,您必須指定 rule_v2 而非 rule:GET audience_id?fields=rule_v2
At this time, "Force Web OAuth Reauthentication" feature is unsupported for Device Login. To enable device login feature, please turn off "Force Web OAuth Reauthentication" under Facebook Login settings.
Notifications on canvas games are not guaranteed. We have systems in place which will determine if a notification is of low or high signal automatically and filter users' jewel notifications accordingly. This means that not all notifications will appear within the users jewel notification.
We have privacy policies in place to prevent content generated from an Application that is not visible, to be distributed to the public. Also in effect is the app is in dev mode.
You should be able to add pages to your app that meet a few conditions:
  • The Page must be categorized as "App Page"
  • You should have access to the page via a role
  • The App Page should not already be linked to an existing app
  • The Page must have the same name (or a subset of the name) of the app
/page/* — User information will not be included in GET responses for any objects owned by (on) a Page unless the request is made with a Page access token. This affects all nodes and edges that return data for objects owned by a Page.
The business management permission is a granular permission, which means that it can be granted to some businesses and not granted to others. The access token debugging tool will show the access token has the permission even if it was granted for only some apps.
We maintain a specific cache on Android which can take some time to refresh. However, in iOS, you should see the updates almost instantly when you refresh the article.
The app must be subscribed to 'messaging_account_linking' Webhook event for Account Linking to work. You can subscribe to the event by going to the Messenger tab of your Application Settings.
In order to access the Leadgen information received from a Webhook you needed to be:
  • An admin of the campaigns
  • A full admin of the page
This message is usually shown if the user has an old Facebook for Android app installed on their device. If the user removes the old app and install the latest one, this message should disappear. If not, then please report a bug.
1. The message shown on screen does not mean the user has read it. In order to trigger a read receipt, there need to be some movements on the user side. (The user closing the input box is definitely a movement) An indicator of a message being read is the message text turns from the bold state into a normal state in the preview;
2. There won't necessarily be a read receipt for each message. The read receipt means that ALL messages before this watermark timestamp have been read by the user.
Unique fields are not supported with hourly breakdowns. Unique fields are those prepended with `unique_*` or `reach`.
應用程式向用戶傳送的遊戲邀請以及用戶向用戶傳送的遊戲邀請,兩者有所不同:
  • 應用程式對用戶的遊戲邀請會透過 /apprequests API 端點傳送。這些會在遊戲動態中產生邀請,但不會在網站中產生通知。https://developers.facebook.com/docs/graph-api/reference/app-request#Creating
  • 而用戶對用戶的遊戲邀請則會透過邀請對話方塊傳送。這些會在遊戲動態中產生邀請,也會在網站中產生通知。https://developers.facebook.com/docs/games/services/gamerequests
  • 此外,應用程式對用戶的通知則會透過 /notifications API 端點傳送。這些會產生通知,但不會在遊戲動態中產生邀請。https://developers.facebook.com/docs/games/services/appnotifications
貼文的目標設定只能以區域和國家/地區為條件。例如,假設貼文的目標設定為「US 或 CA」,則如果用戶位於美國(US)或來自加州(CA),都會符合這條規則的限制。如果您想要將目標設定限制在國家/地區內的某個區域,則應該僅指定區域而已。
全球粉絲專頁結構會降低粉絲專頁按讚次數。 設定全球粉絲專頁結構後,根據各粉絲專頁的目標設定,粉絲會移轉到結構內不同的粉絲專頁。 因此, page_fans 的變更數量不會符合 page_fan_adds 和 page_fan_removes 之間的差異數量。
有時無法透過 API 擷取新建的自訂廣告受眾。這是因為資料中心之間的保留延遲和複寫延遲。
利用 ?ids= 端點無法取得內部 FB 網址的貼文編號。如文件所述(https://developers.facebook.com/docs/graph-api/reference/v2.8/url),這個端點針對的是外部網址。