「We're sorry, something went wrong(申し訳ありません、何らかのエラーが発生しました)」といったメッセージが表示されるエラーが発生し、原因の特定が困難な場合には、詳細なエラーメッセージを任意で有効にできます。これにより、解決に役立つ情報が表示されます。 SDKのinit()' methodのデバッグフラグに関する詳しい情報については、https://developers.facebook.com/docs/accountkit/webjs/referenceにあるドキュメントをご覧ください。
Account Kitインスタント認証では、Android利用者が、Facebookに登録されている電話番号と一致する電話番号を入力した場合には、SMSによる認証コードは不要になります。
これは、Android用Facebookアプリを使用しているときにのみ可能です。電話番号の一致が確認できないときには、通常のフローに従ってSMSで認証コードを受け取ります。
Account Kitに表示されるUIは、https://developers.facebook.com/docs/accountkit/languagesのリストに記載されている言語にローカライズされています。
サポートされている国とダイヤルコードの最新のリストについては、https://developers.facebook.com/docs/accountkit/countrycodesをご覧ください。
いいえ、サポートされているのは、https://sdk.accountkit.com/en_US/sdk.jsを使用するJS SDKのリンクのみです。このスクリプトはSDKローダーを取得します。このローダーは、accountkit.comかブラウザーのキャッシュのいずれかから最新のSDKを読み込みます。
SDKを独自のサーバー経由でホストする場合は、猶予期間が24時間になります。この猶予期間が終わると、SDKから警告が送信され、7日後に動作を停止します。
enableSendToFacebookパラメータ(iOSの場合)またはsetFacebookNotificationsEnabled (Androidの場合)をtrueに設定します。
SMSを配信できなかった場合、Facebookアカウントに関連付けられているメインの電話番号を使用してアプリにログインしている利用者には、Facebookのお知らせを通じて確認メッセージが送られます。
利用者がモバイルシェアダイアログやモバイルフィードダイアログを開いた後にキャンセルして閉じた場合は、onSuccess()コールバックメソッドを通じてアプリに通知が送られます。 onSuccess()コールバックは、ダイアログが何らかの形で正常に閉じられたという信号を送る機構だと考えることができます。ただし、実際に何かが投稿されたかどうかを確定するために、このコールバックを使用することはできません。 利用者がアプリに関して「publish_actions」権限範囲も付与していた場合は、キャンセル時にonCancel()コールバックメソッドが呼び出されます。
FacebookCallbackクラスについて詳しくは、リファレンスドキュメントをご覧ください。
ネイティブの「いいね！」ボタン(LikeView)は、ウェブベースの「いいね！」ボタンと同様に動作します。FacebookベースのURLの多くは、プライバシー上の理由で使用できません。例外は、FacebookページとFacebookのホームページです。
「いいね！」ボタンプレビューワーを使用して、事前にチェックできます。
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.
No.
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.
To access one of these fields, you will need to submit for Advanced Access for the Business Asset User Profile Access feature through App Review.
- アプリが別の未認定ビジネスに移動したので、以前承認されたすべてのアクセス許可がブロックされる。
- その後、アプリが認定されたビジネスに戻った場合、アクセス許可のブロックは解除されます。
- アプリは、他のビジネスにサービスを提供するものとしてマークされていますが、その後、認定されていない別のビジネスに移動させられました。
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.
アプリレビューが必要かどうかはアプリIDのレベルによって異なります。このようなアクセス許可または機能を使用しているアプリは、個別にレビュー用に送信する必要があります。
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日間の枠がリセットされるわけではないことに注意してください。
新しい機能やアクセス許可をテストするには、アプリのレビューと公開が完了してから、アプリダッシュボードで[テストアプリを作成]機能を使用して、本稼働アプリの複製を作成します。本稼働アプリのダッシュボードで、左上のナビゲーションペインのアプリ名の横にある下矢印をクリックし、[テストアプリを作成]をクリックします。開発中ステータスで作成されたアプリの複製では、すべてのアプリの役割に、すべての機能とアクセス許可へのアクセスが許可されます。
クライアントもアプリの「所有者」の場合は、クライアント自身も正当な開発者としてプロセスを完了します。クライアントがアプリの「所有者」としてサードパーティ開発者を使用している場合は、その開発者がレビュー対象になります。
leads_retrievalアクセス許可とpages_manage_adsアクセス許可をリクエストする必要があります。
アプリレビューの過程で、特定のAPIアクセス許可が必要なアプリが参照されます。ここでレビューに必要なアクセス許可を確認できます。SDKそのものの設定にアプリレビューは必要ありません。ただし、SDKによってアプリはFacebook APIを呼び出せるようになるため、このようなAPIがレビュー対象の場合は、そのアプリのアプリレビューを申請する必要があります。
すでにビジネスマネージャアカウントを1つ持っている場合は、その既存のビジネスマネージャにアプリをリンクすることをおすすめします。
1つのビジネスに複数のビジネスマネージャアカウントがある場合は、複数のビジネスマネージャアカウントがあることの理論的根拠を判断し、アプリを最適なビジネスマネージャと組み合わせることをおすすめします。ビジネスマネージャから設定された融資限度額がある場合は、アプリを融資限度額のあるビジネスマネージャと組み合わせることをおすすめします。
Facebookに使用してもらいたい追加設定、ホワイトリスト、またはテストユーザーのプロファイル情報がある場合、開発者は固有のテストユーザーを提供することができます。テストユーザーが提供されない場合、Facebookは独自のユーザーを使用します。フィールドをオプションとしてマークする必要があります。そうしなければテストユーザーを提供できません。
アプリレビューはアプリごとに実施されます。アプリダッシュボードを確認し、レビューが必要なアクセス許可の具体的なリストを取得することをおすすめします。
ビジネス認証はビジネスマネージャごとに必要です。すべてのアプリを同じビジネスマネージャに関連付ければ、ビジネス認証を一度で済ませることができます。
アプリは、最終的にそのアプリを所有し、そのアプリから生成されるデータにアクセス可能なビジネスのビジネスマネージャにリンクされている必要があります。このビジネスが、ビジネス認証プロセスを実施する必要があります。
ビジネス認証のステータス、契約、実行するべき手順は、アプリダッシュボードのアプリレビュータブにあるビジネス認証パネルでいつでも確認できます。プロセス中にアクションが必要になったら、お知らせが送信されます。
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.
レビュー過程で、ビジネスの登録名、住所、電話番号などのビジネス情報がたずねられます。加えて、公共料金の請求書、事業免許、設立証明書、定款などのビジネス書類の提出が求められます。
Same as other permissions, you will lose access.
2018年8月1日から、アプリに関連のあるビジネスマネージャの認証のみ必要とされるようになりました。
新規APIが利用可能になったら、これらのAPIをアプリレビューを通じてリクエストする必要があります。しかし、ビジネス認証はビジネスマネージャエンティティごとに1回しか受ける必要がないので、新規アクセス許可やAPIがアプリで必要になった場合でも、ビジネス認証を再度受ける必要はありません。
Facebookログインの追加許可と6つのAPI (ページ、Messenger、ビジネスマネージャ、Instagram、グループ、イベント)を呼び出す既存のアプリすべてを、ビジネス認証と契約への署名を含む新しいアプリレビューフローに申請する必要があります。この日付までにアプリレビューを申請する必要があるだけで、完了する必要はありません。2018年8月1日までに申請されなかった場合、2018年8月2日からこれらのAPIにアクセスできなくなります。
マーケティングAPIとリード獲得広告APIを呼び出す既存のアプリすべてを、2019年2月1日までに、ビジネス認証と契約への署名を含む新しいアプリレビューフローに申請する必要があります。
ビジネス認証は1回のみ受ける必要があります。ビジネスレベルで契約書に署名する必要があるのは1回のみです。その後のアプリの申請でアプリレビューは必要になりますが、認証は必要ありません。
アプリレビューの必要性は、アプリIDレベルに基づきます。アクセス許可または機能を使用している個々のアプリについて、レビューを申請する必要があります。
2018年5月1日に、Facebookログイン(追加許可)と6つのAPI (ページ、Messenger、ビジネスマネージャ、Instagram、グループ、およびイベント)に必要な新しいアプリレビュープロセスがFacebookにより発表されました。これらのAPIへのアクセスを維持するには、API/アクセス許可のアプリレビューを2018年8月1日までに申請する必要があります。
2018年7月2日に、Facebookはアプリレビューが必要な追加のAPIを発表しました。マーケティングAPIとリード獲得広告です。アクセスを維持するには、これらのAPIのアプリレビューを2019年2月1日までに申請する必要があります。期限について、詳しくはこちらをご覧ください。
グラフAPI v3.0では、ビジネスマネージャに変更は加えられていません。Business_Managementアクセス許可へのアクセス権が必要なアプリは、Facebookによるレビューを受ける必要があります。
FacebookのマーケティングAPIを使用しているアプリに影響を及ぼすような変更は、Facebookのアプリレビューポリシーにはありません。実際のAPIの変更について詳しくは、グラフAPIの更新履歴をご覧ください。
はい。アプリレビューを受けていないアプリは、ユーザーの名前、メールアドレス、およびプロフィール写真にしかアクセスできません。他のすべてのアクセス許可にFacebookによるレビューが必要です。
Instagram APIはグラフAPI v3.0の影響を受けません。ただし、Instagram APIを使用しているアプリはすべてFacebookによるレビューを受ける必要があります。
グラフAPI v3.0では、イベントにアクセスするアプリはuser_eventsアクセス許可を使用する必要があります。アクセス許可を使用するアプリは、Facebookによるレビューを受ける必要があります。
user_managed_groupsアクセス許可はグラフAPI v3.0で廃止されています。アプリでは、既存のpublish_groupsアクセス許可やread_groups_user_dataアクセス許可と一緒に新しいグループAPIを使用できます。新しいAPIとアクセス許可を使用するアプリは、Facebookのレビューを受ける必要があります。
publish_actionsアクセス許可はグラフAPI v3.0で廃止されています。アプリでは、まだ、ウェブ上のFacebookシェアダイアログやiOSとAndroid用のシェアシートなどの仲介エクスペリエンスを通して記事を投稿できます。アプリは、publish_groupsアクセス許可(使用するアプリはレビューを受ける必要がある)を介してグループに公開できます。
はい。v3.0では、すべてのMessengerプラットフォームAPIがPages_messagingアクセス許可に含まれ、レビューを受ける必要があります。
はい。公開ページのコンテンツにアクセスするアプリは、ページの公開コンテンツへのアクセス権をリクエストし、Facebookによるレビューを受ける必要があります。
レビュープロセス中に、Facebookのレビューチームは提出された手順に従って、アクセス許可がアプリでどのように使用されるかを再現します。手順を実行できない、アプリにログインできないなどの理由でこの手順を再現できない場合、申請も承認されません。
このような事態を避けるため、次のようにしてください。
- アクセス許可を使用するアプリの実用版を提供する
- [ノートを追加]セクションの手順がわかりやすいことを確認する
- リクエストしたログイン許可がサービスをパーソナライズし、Facebookの原則に準拠していることを確認する
具体的に言うと、publish_actionsアクセス許可の場合、アプリの公開機能が正しく構成されていることを確認してください。レビュープロセス中に、アプリのコンテンツをFacebookに公開できる必要があります。
アプリレビュープロセスには、サポート対象のそれぞれのプラットフォームにアプリをロードすること、Facebookでログインすること、レビュー中にリクエストしているすべてのFacebook統合を使用することが含まれます。多くの場合、このプロセスがいわゆる「一般的な問題」を招きます。つまり、アプリのロード、アプリへのログイン、アプリの一般的な機能に関連するエラーまたはバグなどです。これは、申請でリクエストされているアクセス許可をFacebookがテストできなかったことを意味します。
これらの問題が原因でFacebookの機能をレビューできないため、レビューの申請が行われたFacebookの機能がアプリでどのように使用されているかに関して詳しくコメントすることはできません。このため、Facebookでは「一般的な問題」として拒否し、プラットフォームごとにこの問題に関するフィードバックを提供します。
「一般的な問題」による拒否を受け取った場合、フィードバックをすべて注意深くお読みになることをおすすめします。フィードバックはプラットフォームごとに送信されます。それぞれのフィードバックではレビュー中に検出された問題について説明されています。
レビューの回答には、アプリが承認されなかった理由の明確な説明と次に実行が必要な手順が含まれています。Facebookではできるだけ早くプロセスに合格していただくことを願っているため、このフィードバックを注意深くお読みください。必要な変更を行ったら、再度レビューを申請できます。
承認されない方法でアプリがアクセス許可を使用している場合、それについてフィードバックで説明されます。その場合、レビューの再申請は行わないでください。
アプリセンターの承認を受けるには、アプリがFacebookの資格要件を満たす必要があります。アプリがFacebookアプリセンターの掲載条件を満たすためには、Facebookログインを使用するか、Facebookキャンバスアプリである必要があります。
アプリセンターの掲載条件を満たすアプリは次のとおりです。
- Facebookキャンバス上のアプリ
- iOS用FacebookログインまたはAndroid用Facebookログインを使用して、iOSまたはAndroid用に作成されたモバイルアプリ
- Facebookログインを使用するウェブアプリまたはモバイルアプリ
テキスト資産および宣伝用画像もFacebookのガイドラインを満たしている必要があります。
シェアダイアログまたはその他のソーシャルプラグインを使用してコンテンツをFacebookに公開している場合、レビューを申請する必要はありません。まだご不明な点がある場合は、Facebookの一般的なレビューに関する資料で詳細をご覧ください。
ソーシャルプラグインを使用することやページを「いいね！」することを利用者に促す行為は、プラットフォームポリシー4.5に違反します。これには、利用者がページを「いいね！」したかどうかに基づいて特典を与えたり、アプリまたはアプリのコンテンツを制限したりすることが含まれます。User_likesは、このような目的のためには承認されません。
Facebookの目標は、質の高いつながりを確保し、企業が自社にとって価値あるターゲット層にリーチできるよう支援することです。そのため、利用者がページを「いいね！」する理由は、人為的なインセンティブのためではなく、利用者が企業とつながりを持ち、企業の声を聞きたいからであると考えています。このポリシーが、利用者と広告主の双方に利益をもたらすと確信しています。
Facebookのレビューチームは、レビューを完了するために、アプリの追加のログイン情報を必要とする場合があります。
アプリがFacebookログインの前または後に2次ログインを必要とする場合、そのためのユーザーネームとパスワードを必ず提供してください。これには、テストサーバーまたはデモサーバーのログイン情報、アプリの2次ログイン、またはメール登録フローが含まれる場合があります。
ステージングサーバーまたは開発サーバーでホストされているアプリには、サーバーにログインするために追加ログインが必要な場合があります。この場合にも、そのために必要なログイン情報をすべて提供してください。
どのログイン情報が欠落しているのかがまだわからない場合は、申請対象のFacebookログインオプションと関係するすべてのFacebook統合を含めた動画を次回の申請で提供してください。
Facebookのレビューチームは、アプリの申請を承認するために、アプリにログインして、すべてのFacebook統合を確認する必要があります。
レビュー担当者がアプリをロードしたり、アプリを使用したりできない場合、次の点を確認してください。
- アプリURLが誰でもアクセスできるようになっており、localhostとして構成されていない
- 開発サイトまたはステージングサイトへのアクセスに必要なユーザーネームおよびパスワードを提供している
- サイトのセキュリティ証明書が最新であり、新規利用者が使用してもエラーが発生しない
- 新しく作成されたテストユーザーとしてアプリにログインし、アプリを使用できる
- レビューを申請したアイテムが、開発者のアプリで開発され、実動している
同じ理由で再度拒否された場合、[Review Instructions]または[ノートを追加]セクションを更新して、もう少しわかりやすい説明と追加情報をレビュー担当者にリクエストしてください。
スクリーンキャストは、アプリ内をガイドし、リクエストされたアクセス許可がどのように使用されるのかを示してくれる便利な方法です。ここでは、スクリーンキャスト作成のベストプラクティスとサードパーティのリソースをいくつかご紹介します。
提出する動画では、リクエストしているそれぞれのアクセス許可がアプリでどのように使われるのかを示す必要があります。publish_actionsをリクエストしている場合、動画では、アプリのコンテンツがどのように作成され、Facebookとシェアされているかを示す必要もあります。
インスタントゲーム用に作成されたFacebookアプリIDは、他のプラットフォームでは使用できません。詳しくは、Facebookのドキュメントをご覧ください。
Facebookのレビューチームは、あなたが提供した手順を使用して、アプリのFacebook統合をテストします。
レビュー担当者がアプリを間違って拒否したと思われる場合、レビューを再申請してください。その際に、更新されたレビュー手順を添付し、レビュー担当者にさらに多くの情報を提供してください。
レビュープロセスにおいて、レビュー担当者とコミュニケーションを取る最善の方法は、あなたが受け取ったフィードバックの内容に対応したノートを更新することです。
いいえ。アクセス許可が承認されたら、そのアクセス許可をすべてのプラットフォーム上のすべてのバージョンのアプリで使用できます。
新しいプラットフォーム上にアプリを展開して開発する場合も、レビューを申請する必要はありません。レビューの再申請が必要になるのは、新しいアクセス許可をリクエストする場合(アプリに新機能を追加する場合など)に限られます。アプリの詳細またはOpen Graph actionを変更して申請しても、これまで承認されたアクセス許可に影響はありません。
アプリがゲームであり、Facebookキャンバス上にページがある場合
以下のいずれかを使用して、新規プレイヤーをゲームに招待できます。
- リクエストダイアログ。リクエストダイアログを使用している場合、[filters=app_non_users]を設定して、アプリを使用していない利用者のみ表示するように、ダイアログをフィルタにかけることができます。アプリにキャンバスページがある場合、iOSおよびAndroidではリクエストダイアログも使用できることがあります。
- 招待可能な友達APIゲームのアプリで、自分のマルチ友達セレクタを作成する場合、Invitable Friends APIを使用できます。このAPIでは、アプリを使用していない利用者の友達のランク付けされたリストが返されます。利用者が招待する数人の友達を選択したら、Invitable Friends APIによって返されたトークンをリクエストダイアログのフィールドに渡します。そこから、利用者は招待をそれらの友達に送ることができます。
Facebookキャンバスにアプリのページがない場合
Message Dialog (iOSとAndroidの場合)または送信ダイアログ(ウェブの場合)を使用できます。これらの製品を使用すると、利用者は友達にアプリへのリンクが含まれているメッセージを直接送信できます。
このタイプのメッセージは、比較的少数の利用者と直接やり取りするための優れた手段です。Message Dialogと送信ダイアログのどちらにも自動入力が組み込まれており、利用者は招待を受け取る複数の友達を容易に選択できます。
Facebookのレビューチームは、アプリがそれぞれのアクセス許可をどのように使用するのかを、アプリの設定セクションにリストされている各プラットフォームで実際にテストします。レビュー担当者は、Facebookログイン統合が正しく機能していること、リクエストされたそれぞれのアクセス許可がFacebookの原則とユーティリティガイドラインを順守したうえで利用者へのサービスを向上させていることを確認します。
詳しくは、Facebookの原則とユーティリティガイドラインをご覧ください。
レビュー担当者は、user_likesのリクエストを承認する前に、利用者から受け取る「いいね！」の情報に基づいて、アプリが利用者に固有のサービスを提供していることを確認する必要があります。これを行うために、Facebookのレビューチームは、好きなものと趣味・関心がそれぞれ異なるさまざまなテストユーザーでアプリをテストします。
user_likesのリクエストを送信したら、以下を含む詳細な説明を作成する必要があります。
- user_likesをリクエストしている理由と、それがアプリで利用者へのサービスをどのように向上させるかに関するわかりやすい説明。
- user_likesの使用を検証するために、レビュー担当者に「いいね！」するよう依頼するサンプルページのリスト。アプリをテストする前に、レビュー担当者に「いいね！」するよう依頼するページへの直接リンクを指定してください。
user_likesをアルゴリズムの一部として使用している場合、このアルゴリズムの結果とそれが利用者に表示されるコンテンツに及ぼす影響をレビュー担当者が確認できるようにすることが重要です。
場合によっては、特定のテストユーザーのみに有効な一定の動作や機能を、レビュー担当者が再現できるようにする必要があります。その場合、[アプリレビュー]ページでこのユーザーを申請に追加します。[審査中のアイテム]セクションに、[テストユーザー(オプション)]セクションが表示されます。このセクションに、レビューで使用するユーザーの名前を入力できます。
ここで有効なテストユーザーは、アプリの[役割]セクションの[テストユーザー]として表示されるユーザーのみです。レビューの手順では、テストユーザーのFacebookログイン情報をシェアしないでください。
テストユーザーの作成方法については、こちらをご覧ください。
いいえ、モバイルアプリインストール広告を実行するためにレビューを申請する必要はありません。iTunes App StoreまたはGoogle Play Storeで販売されているアプリのみが必要です。Facebookのガイドを参考にして、モバイルアプリインストール広告を作成してください。
それぞれのアクセス許可または機能をアプリでテストする方法を正確に説明して、アプリの機能やアプリがFacebookのポリシーに従っていることをFacebookが確認できるようにする必要があります。アプリとFacebookの統合を十分にテストできない場合、そのアプリは承認されません。詳細な手順を提供すれば、レビューの再申請が必要になる可能性は低くなります。
リクエストするアクセス許可ごとに、再現する手順を、順を追って説明してください。手順はすべて英語で記述する必要があります。
説明が以下のようにならないようにしてください。
- 他の申請または資料の手順を参照している
- 手順を提供する代わりにアプリの機能を要約している
- あなたのAPIの仕組みの技術的な面を詳しく説明している
手順を追った良い説明の例を次に示します。
- 左側のメニューにある[設定]ボタンを押します。
- [Facebookでログイン]を選択します
- ステップ3を実行します
- ステップ4を実行します
記載する内容がまだご不明な場合は、Facebookのアプリレビューのサンプルセクションでさらに多くの例をご覧ください。
レビュープロセスに変更があったり、大量の申請が寄せられたりするために、申請されたアプリのレビューが完了するまで数週間かかることがあります。
レビュー担当者に役立つ情報をできる限り多く提供してください。わかりやすいスクリーンショット、順を追った詳しい手順、アプリとそのFacebook統合を録画したスクリーンキャストなどです。
ソーシャルプラグイン、シェアダイアログとシェアシート、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データの継続的な使用がFacebookのプラットフォーム規約および開発者ポリシーに従っていることを開発者が確認する必要がある毎年のプロセスです。
ビジネスで管理する個々のアプリを代表して確認する必要があります。
多くのアプリを管理している開発者は、複数のアプリに関するデータの使用状況の確認を一度に完了することもできます。アプリダッシュボードの[マイアプリ]ページに移動すると、このフローにアクセスできます。ここには、管理者になっているすべてのアプリが表示されており、サブセット(例えば、データの使用状況の確認が必要なもののみ)を絞り込んで、データの使用状況の確認を完了できます。
管理している個々のアプリについて確認を完了する必要があります(各アプリに複数のアクセス許可が存在する場合があります)。各アプリに設定された期限までにプロセスを完了しさえすれば、アプリを個別に確認できます。必要に応じて、優先順位に従って確認することもできます。
アクセスできるすべてのアクセス許可を確認する必要があります。ただし、特定のアクセス許可へのアクセスが不要な場合は、これらのアクセス許可を削除できます。これにより、削除したアクセス許可は、確認の必要がなくなります。
ライブモードと開発モードは、アプリの機能とデータの使用状況の確認に関連のある2つのアプリモードです。通常、開発モードは、テスト、API製品およびアクセス許可の調査、アプリレビューの完了に使用されます。開発モードのアプリは、ユーザーレベルのデータを呼び出せません。ライブモードは、本番シナリオで使用され、アプリレビューでアプリに承認されているデータおよびアクセス許可へのアクセスをゲート管理しません。データの使用状況の確認は、ライブモードのアプリにのみ必要です。
Facebookでは、アプリの管理者が同じ場合はアプリの期限をまとめて設定するようにしているため、一般的にアプリの期限は同じになります。ただし、例外もあり、一部のアプリ管理者はさまざまな期限でプロセスを完了する必要があります。例えば、他の人がデータの使用状況の確認を行った後にあなたがアプリを作成した場合、年間期限は異なります。
このプロセスは、アプリの管理者が完了する必要があります。アプリの管理者を確認するには、アプリダッシュボードにログインし、ページの左側にある[役割]をクリックします。アプリの管理者は、組織を代表して行動する権限を持っている必要があります。
アプリの管理者であれば誰でも、アプリを確認できます。アプリに複数の管理者がいる場合は、そのうちの1人が確認します。
完了期限は、プロセスの開始(最初の開発者アラートを受信した時点)から60日間です。
期限が過ぎると、期限の翌月の1か月間にわたってAPI呼び出しがスロットリングされ、プラットフォームアクセスの取り消しが開始されます。この期間中にアプリダッシュボードにアクセスしてデータの使用状況の確認を完了し、アプリを準拠状態に戻せば、プラットフォームアクセスを完全に復元できます。ただし、期限から1か月を過ぎると、プラットフォームアクセスは完全に取り消されます。
アプリダッシュボードに戻ってデータの使用状況の確認を完了することで、アクセスを復元できる場合があります。ただし、Facebookでは、アクティブでないアプリの「アクセス許可の回収」を定期的に行っているため、アクティブでない状態が一定期間経過すると、アクセス許可が完全に削除される可能性があります。削除された場合、アクセスを回復するにはアプリレビューを申請する必要があります。このシナリオを回避するためにも、期限前にデータの使用状況の確認を完了することをおすすめします。
データの使用状況の確認では、アクティブに使用しているかどうかに関係なく、アプリがアクセスできるすべてのアクセス許可が表示されます。この機会に統合を監査し、アプリの機能を詳しく把握し、不要なアクセス許可へのアクセスを削除することをおすすめします。
場合によっては、データの使用状況の確認のワークフローで、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.
Meta’s services are not available in all regions.
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.
アプリセンター用に承認されたスクリーンショットやバナー画像を削除することはできません。画像を新しいものと入れ替える場合は、スクリーンショットまたはバナーの[編集]をクリックして、代わりの画像を選択します。
利用者の写真をリクエストしなくてもエラーメッセージが表示されるかどうかと、最初からエラーメッセージが表示されていたかを確認します。 次に、以下のme/photos APIをリクエストし、元の画面に戻って、エラーメッセージがまだ表示されているかどうかを確認します。 me/photos呼び出しのテストを行う場合、意図したアプリを使用していることと、user_photosのアクセス許可を要求する正しいアクセストークンを取得し、問題なく動作しているかを確認してください。
このチェックの目的は、開発者がアクセス許可をFacebookにリクエストする前に、アプリ内の機能テストを徹底することです。試験段階のアプリをテストするのみでは、メインアプリが同様に安定して動作する保証にはなりません。外部の利用者向けにメインアプリを有効にする前に、メインアプリからのリクエストをテストし、想定したとおりに動作するか確認する必要があります。 提示された手順に従って手動でリクエストし、ダッシュボードにこの警告が表示されなくなったことを確認してください。
「Stream Post URL Security」の移行を設定すると、URLのドメインに戻らないURLを、Facebookアプリが公開しないようにします。アプリが他のサイトへのリンクを公開する場合は、このオプションを使用しないでください。
これは意図された動作です。詳細は次のドキュメントをご覧ください。https://developers.facebook.com/docs/apps/test-users#rules - テストユーザーは、公開されているFacebookページのファンになったり、ページのウォールに書き込むなどしてコンテンツを作成したりすることはできません。ただし、テストユーザーを作成したアプリに関連付けられているページのアプリタブの表示や操作は可能です。
これは意図的なものです。セキュリティ管理上、複数の任意のドメイン設定は許可していません。
これは意図された動作です。ログインダイアログでは画面幅は固定され、画面サイズに合わせて調整されることはありません。
これは意図された動作です。開発者はその責任において、利用者の機器に基づき適切な「redirect_uri」を設定する必要があります。そのため、利用者がモバイル機器を使用している場合は、「redirect_uri」にモバイルサイトのURLを設定する必要があります。
これは意図された動作です。セキュリティの潜在的な脆弱性の対策のためです。一部のブラウザでは、URLからリダイレクトされる新しいURLの最後に、このハッシュフラグメントを追加することがあります(新しいURL自体にハッシュフラグメントが含まれていない場合)。
たとえば、example1.comがexample2.comというリダイレクトを返す場合、example1.com#abcに移動するブラウザはexample2.com#abcに移動することになり、example1.comのハッシュフラグメントの内容がexample2.comのスクリプトにアクセス可能になります。
1つの認証フローを他のフローにリダイレクトすることができるため、1つのアプリの重要な認証データを、他のアプリがアクセスできるようにすることも可能です。新しいハッシュフラグメントをリダイレクトURLに追加してブラウザの動作を防止すると、この可能性を低減することができます。最終的なURLの健全性やクライアント側の動作に心配がある場合は、window.location.hashを使用、または、サーバー側で独自にリダイレクトして、問題を起こす文字列を除去することもできます。
Test apps created from Business apps will have Standard Access for all permissions and features.
No. The access level model only applies to permissions and features.
No. For a given permission, Business apps have either None, Standard, or Advanced Access.
Yes. A Business app will be auto-granted Standard Access and may request Advanced Access for a given permission.
Yes. For Business apps, the Advanced Access level includes access to all data within the Standard Access level.
URLをシェアする場合、関連付ける画像のサイズは200x200ピクセル以上である必要があります。これに満たない場合は、「指定されたog:imageが小さすぎます。少なくとも200x200ピクセルの画像を使用してください」のようなエラーが表示されます。
URL用の画像を選び取るために最初に参照されるのは「og:image」タグです。このタグがあることと、200x200ピクセル以上の画像であることを確認してください。「og:image」タグがない場合は、ウェブページで最初にヒットした画像が選択されます。
サイトの画像が200x200ピクセル以上であるにもかかわらずエラーが表示される場合は、サイトから間違った画像が取得されていることが原因と考えられますので、「og:image」タグの設定が正しいことを確認してください。
Facebookプラットフォームの他のプラグインや機能との統一を図るため、sharerプラグインの動作を変更しました。
sharerはカスタムパラメータを受け入れなくなりました。Facebookでは、URL OGメタタグから情報を取得し、その情報は投稿の表示と同じようにプレビューで表示されます。
いいえ、できません。シェアされたURLでは「title」と「description」は上書きできますが、「caption」は上書きできません。
他のアプリで作成されたアルバムに、アプリをアップロードすることはできません。
場合によっては、どのアプリとも関連付けられないアルバムもあります([ウォールの写真]アルバム)。アルバムのcan_uploadフィールドの確認をおすすめします。can_uploadフィールドがfalseを返す場合、利用者は自分のプロフィールの[アルバム]表示からこのアルバムに直接写真を送ることはできません。
コールトゥアクションは、動画の再生が終了した後、[リプレイ]アイコンの下に表示されます。
GIFをFacebookで再生するには、サイズを8MB未満にする必要があります。
API経由での未公開投稿へのコメント作成は現在サポートされていません。
インラインで作成した動画投稿は、すでに宣伝済みであるため、promotable_postsのエンドポイントには表示されません。インラインで作成した動画投稿は、広告作成の一環として作成された投稿であるため、別途に宣伝することはできません。
同様に、インラインで作成した投稿は、/promotable_postsのエンドポイントにも表示されません。
これは、トークンに関連付けられた利用者が、ページの[設定]にある[ページの役割]でアナリストとして登録されている場合に、ページアクセストークンを使用すると発生します。
リクエストがグラフAPIを使用したデータを要求している場合、プライバシーに関するさまざまなルールが適用されるため、ウェブサイトで表示されていてもデータが返されないことがあります。これには利用者のプライバシー設定や、アプリレベルのアクセス許可など、いくつかの要因が考えられます。つまり、APIの返すデータは、必ずしもウェブサイトで見られるものすべてを含むわけではないということです。
sharesフィールドが返されるのは、投稿のシェア回数が10回を超えた場合です。投稿のシェア回数が10回に満たない場合、このフィールドは省略されるか、数値を返そうとします。
このエンドポイントについて、詳しくはhttps://developers.facebook.com/docs/graph-api/reference/v2.4/postをご覧ください。
これは、旧システムで使われた古い値です。新システムへの移行時に、後方互換性を持たせたために発生します。
これは過去の投稿で発生します。最近の投稿では発生しません。
これは意図された動作です。投稿と、投稿内の写真には直接の関連はありません。投稿に最初にアップロードされた画像のみが返されます。
投稿がFacebookウェブサイトまたはモバイルアプリに帰属している場合、「application」フィールドは返されません。これはサイトと連携されるもので、サイトでは、このようなタイプの投稿の属性は示されません。
投稿の「privacy」フィールドには、この投稿のFacebookでの公開範囲に関する情報が含まれていますが、ページ投稿がターゲットにされているか、特定の利用者のみに見えるよう制限されている場合、選択しても、「privacy」フィールドの情報に表示されないターゲット設定があります。
投稿のターゲット状況や制限についてすべての項目を確認するには、「targeting」フィールド(制限付きの場合)と「feed_targeting」フィールド(ニュースフィードのターゲット設定の場合)をご覧ください。利用可能なフィールドについて詳しくは、投稿のドキュメントをご覧ください。
投稿に対して返されるcomment_count値は、非表示または削除されたコメントを含む場合があります。投稿で表示されているコメントの数は、comment_countを超えることはありません。
シェアされたURLの「caption」は上書きできません。シェアされたURLで上書きできるのは「title」と「description」のみです。
グラフAPI経由で公開可能なフィールドについて詳しくは、https://developers.facebook.com/docs/graph-api/reference/v2.3/page/feed#publishの/feedのドキュメントをご覧ください。
これは仕様です。Facebookアプリ(モバイル用またはウェブ用)で生成されたコンテンツが、Facebook自体へのアトリビューションなしで表示される形式に合わせて調整されているためです。
Facebook側で、ストリームデータと投稿データについて、API経由での取得方法と表示方法を更新しました。
API経由での投稿の取得に問題が発生し、ドキュメントの記載とは動作が異なると思われる場合は、以下の点を確認してください。
- 使用しているアクセストークンが、対象の投稿へのアクセスに対応したアクセス許可を付与されていること。
- 投稿の取得に使用しているすべてのAPI呼び出しが、以前の呼び出しで返された「id」を使用しており、ページや利用者などのIDを手動で変更していないこと。
Instagram経由でアップロードされた写真はOpen Graphアクションで公開され、グラフAPIで読み取るためには、Open Graphの適切なアクセス許可を必要とします。
Instagramの写真の場合、必要なアクセス許可は「user_actions:instapp」です。「instapp」はInstagram用のアプリのネームスペースです。
Open Graphアクションは/feed接続には表示されませんが、必要に応じて、Open Graphアクションとして写真がアップロードされる場所では、利用者のアルバム接続か、/photos接続経由でアクセスできます(適切なアクセス許可が必要です)。
Open Graph許可について詳しくは、こちらをご覧ください。
これは意図された動作です。削除されたオブジェクトや、プライバシーや権限のチェックのため非表示となっているオブジェクトについて、システムが上記のエラーメッセージを返します。
これは意図された動作です。この形式のページネーションは、コメントではサポートされません。
/{user-id}/accountsエンドポイントのsummaryパラメータのtotal_countは、想定よりも高い数値を返すことがあります。total_countには、利用者が管理者であった削除済みのページが含まれますが、
このエンドポイント自体から返されたデータには、削除されていないページのみが含まれているためです。
/user/likesエンドポイントは、時間ベースのページネーション(パラメータに「since」と「until」を使用)から、カーソルベースのページネーション(パラメータに「before」と「after」を使用)に変更されました。
この違いについて詳しくは、https://developers.facebook.com/docs/graph-api/using-graph-api/v2.3#pagingをご覧ください。
app-scoped-user-idの導入により、エンドポイントがデータを返す方法が変更されました。
v1.0は廃止されているため、ここではv2.xについて説明します。/v2.0/{id}はhttps://www.facebook.com/{id}か、https://www.facebook.com/app_scoped_user_id/{id}を返します。
これは意図的なものです。このエラーは、拡張しようとしているアクセストークンが、対応するアプリIDにアクセス不能であることを意味します。
もっとも可能性が高いのは、利用者の属性に基づく制限がアプリに適用されており、トークンの拡張対象の利用者が条件に合致していない場合です。また、場所を移動したり、より正確に場所を特定できるようになったりしたことによって合致しなくなったことも考えられます。
次に考えられるのは、場所が特定できなかった場合など、利用者の要件をFacebookで確認できないために、アプリの制限により利用者のアプリへのアクセスが許可されないという場合です。
2014年4月30日より後に作成されたアプリではバージョン2以降のAPIを使用するため、/me/friendsエンドポイントでは、アプリの友達のみが返されます。また、すべてのユーザーIDはアプリ専用のIDとなり、アプリ特有の永続的IDとして機能するようになりました。
v2.0で導入されたすべての新機能と変更点についての詳細な説明をご覧ください。
Userオブジェクトのemailフィールドのドキュメントでは、予想される動作について「有効なメールアドレスがない場合、このフィールドは返されません」と説明しています。
利用者にメールアドレスが返されるはずなのに返されない場合、考えられる状況は多数あります。プライバシーやセキュリティ上の理由から、利用者のメールアドレスが返されない原因を正確に特定することは困難です。
考えられる原因としては、次のようなものがあります。
- アカウントにメールアドレスが登録されていない
- アカウントのメールアドレスが確認されていない
- アカウントのメールアドレスが認証されていない
- あるセキュリティのチェックポイントでメールアドレスの再確認が必要になったが、再確認を終えていない
- 利用者のメールアドレスに到達できない
投稿がAPI経由で取得できないのは、投稿内の利用者のコンテンツがページで再シェアされており、利用者が自分のコンテンツを見るための承認をアプリに与えていないためです。
ページのタイムラインでシェアされた利用者の投稿は、利用者が投稿のコンテンツタイプの基本アクセス許可をオフにしていると、API経由では利用できません。
ファンからの写真投稿が見られない場合は、回避策として、ページのアクセストークンを使用して、ページのアルバムを取得できることがあります。この場合、写真は[タイムラインの写真]アルバムに入っています。
特定の、またはすべてのアプリで、Facebook利用者のプライバシー設定により、利用者の情報をまったく取得できないことがあります。これは、利用者が作成した投稿のうち、あなたのアプリが閲覧可能と想定されるコンテキストで行われた投稿(ページ管理など)にアクセスする場合にも発生します。
たとえば、利用者がアプリをブロックしたり、すべてのプラットフォームアプリに対してAPI経由で情報にアクセスできないようにしたりしていることなどが考えられます。
グラフAPIのv2.1のリリースで、この機能は削除されました。2014年8月7日より前に作成されたアプリでは、このフィールドはsigned_requestに存在しなくなりました。
この日付より前に作成されたアプリでは、「いいね！」のプロパティは対象の利用者がページに「いいね！」したかどうかにかかわらず、常にtrueを返します。
他の結果のページを取得するには、対応として返される「次のページ」と「前のページ」リンクを直接使用してください。提供されたリンクを使用することによって、将来的にページネーションリンクのフォーマットが変更されても、アプリが停止することを防ぐことができます。
APIの多くのアイテムと同様、インサイトデータはメインのFacebookサイトの機能と1:1ではマッピングされません。ページインサイト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についての詳細は、次のURLをご覧ください。https://developers.facebook.com/docs/graph-api/reference/cover-photo/#Creating
いいえ、API経由で幅を変更することはできません。
これは現行の仕様です。ページ管理者は、グラフAPI経由ではページ管理者自身として投稿することはできません。その機能は、http://www.facebook.com/とFacebookモバイルアプリでのみ利用可能です。
いいえ、できません。ページに「いいね！」した利用者全体のリストを取得する方法はありません。これは仕様です。
ページに代わってアクションを実行する場合、ページアクセストークンを使用していることを確認してください。このエラーメッセージは、ページアクセストークンではなくユーザーアクセストークンを使用していることを示しています。
アクセストークンの違いについて、詳しくは https://developers.facebook.com/docs/facebook-login/access-tokensをご覧ください。
取得はできません。投稿を固定することと、固定された投稿を読むことは、Facebookのネイティブ製品のみで可能です。
ある時点で外部URLのコメントミラーリングがオンになっていた場合、コメントがミラーリングされる投稿へのリアクションはURL自体に対して記録され、{URL-id}/reactions>を呼び出したときに返されます。
現時点では、/app_insights/app_eventエンドポイントの1,000件を超える内訳の値のデータは取得できません。データを特定のカテゴリに分類する場合は、Facebook Analytics UIを使用して、特定の国などのデータポイントに分割することをおすすめします。
データがサーバーに伝達されるよりも前に、エンドポイントの呼び出しが行われている可能性があります。
API呼び出しは、情報がすべてのサーバーに伝達されるまで1～2秒待ってから行う必要があります。
通常、「page_fans_country」指標はpage_fansの数の一部です。この指標は、利用者の国を正確に特定できた場合の、ページのファン数の国別の内訳を表しています。
また、この指標にはページのファン数を基準とした上位の国のみが含まれ、ファンが存在するすべての国が含まれるわけではありません。多くの国にファンがいるページの場合、人口の少ない国々はこの指標に含まれません。
APIでは、オフセットベースのページネーションの使用はサポートされていません。
その代わり、グラフAPIから各応答の最後に返される「paging」リンクを使用するか、「cursor」ベースのページネーションを使用してください。「cursor」を使用する方法がおすすめです。
グラフAPIで正確にページを取得する方法について詳しくは、https://developers.facebook.com/docs/graph-api/using-graph-api/v2.3#pagingをご覧ください。
アクセストークンには、短期のものと長期のものがあります。短期トークンは短時間のセッション用で、通常数時間で期限切れとなります。
短期トークンは長期トークンに切り替えることができ、その場合の有効期間は約60日となります。
詳しくは、アクセストークンのドキュメントをご覧ください。
これは意図された動作です。検索APIはFacebookのプライバシー性を考慮し、アクセストークン使用中の利用者に合わせた動作をします。またハッシュタグ検索はサポートしておらず、Facebook.comでの先行入力による検索と同じ動作をするようには設計されていません。
検索APIは、Facebook.comでの検索と同じ量、同じ結果を返すような動作はサポートしておらず、またそれを目的ともしていません。全般的に、API経由で返される投稿は、Facebook自体の投稿以上に、プライバシーによる制限とセキュリティのチェックが行われています。
Facebookのシステムでは、アプリが実行するAPI呼び出し頻度を制限しています。さまざまな制限事項によりアプリがうまく動作しないことについて詳しくは、https://developers.facebook.com/docs/marketing-api/api-rate-limitingをご覧ください。
フィードURLは異なるページで再利用できますが、ページが要求するドメインに一致するカノニカルURLを持つ記事のみが取り込まれます。
ページで取り込まれる記事のみを含むページごとに個別のRSSフィードを使用することをおすすめします。
ソーシャル埋め込みを使用することによって、動画などのサポートされるソーシャル埋め込みを追加できます。他のサードパーティの動画プレイヤーの場合は、インタラクティブな埋め込みとして記事に追加できます。
下書きモードの記事は、ページ管理者にインスタント記事としてのみ表示されます。記事が公開済みまたはライブモードの場合は、Facebook上の誰もがシェアでき、すべての利用者に対してインスタント記事として表示されます。
右から左に記す言語を表示するdir="rtl"属性が使用されている記事を、インスタント記事で右から左に表示する言語に対応していないアプリで表示させていると考えられます。
アプリの最新バージョンを使用していることをご確認ください。それぞれのアプリは次のバージョン以降で、右から左に表示する言語に対応しています。
- iOS用Facebook: 52.0
- Android用Facebook: 69.0
- iOS用ページマネージャ: 44.0
記事の<body>タグにdir="rtl"属性が設定されているかどうかを確認してください。右から左へ記す言語を使用しない場合は、記事にこの属性を設定しないでください。
インスタント記事の公開前に記事のURLをシェアすると、記事のモバイルウェブバージョンにリダイレクトされます。インスタント記事が公開されると、記事の公開前に投稿されていたリンクを含むすべてのリンクシェアでは、モバイルで閲覧したときに自動的にインスタント記事が表示されます。
Android用ページマネージャでは開発フィードはまだサポートされていません。Androidで記事を表示するための回避策として、記事を下書きとして本番フィードに追加できます。
インスタント記事の編集にはページのインターフェイスを使用します。インターフェイスを使用するには、ブラウザでFacebookページを開き、[投稿ツール] > [インスタント記事]に移動します。ここで記事を表示して編集できます。詳細については、https://developers.facebook.com/docs/instant-articles/publishingをご覧ください。
フィードのダウンロードタイムのタイムアウトは現在30秒です。
いいえ。シェアされたリンクには記事のカノニカルURLを使用する必要があります。たとえばパラメータを使用してURLを変更した場合は、別のURLとして見なされます。
RSSフィードの取り込みの際に表示されたエラーや警告は[設定]ページの[インスタント記事]タブで確認できます。また、[投稿ツール]ページの[インスタント記事]タブで記事をクリックすれば、個々の記事の警告やエラーを表示することもできます。
Facebookでは、完全なロードとRSSフィードの解析を10秒以内に行います。このエラーはその操作が失敗したことを示します。
10分以内に作成/変更された記事のみを含めるといったように、RSSフィード内のアイテムの数を減らすとエラーを解決できる場合があります。フィードは3分おきに取得されますので、必ずしも変更していない記事を含める必要はありません。
クローラーに静的IPアドレスのリストを使用することはできません。ただし、代わりにクローラーのユーザーエージェントfacebookexternalhit/1.1を使用できます。
複製される記事に異なるカノニカルURLが使用されていないかどうかご確認ください。Facebookでは記事のカノニカルURLが一意の識別子として使用されます。そのため、カノニカルURLが異なると別の記事として扱われます。
CMSが別のURLを使用して記事に更新を公開し、その結果、更新が新しい記事として取り込まれることがよくあります。
はい。各ページはドメイン名に対して一意にマッピングされ、これは1対1のマッピングになります。 特定のページに属するインスタント記事は、特定の度面または同じドメインのサブドメインに属するカノニカルURLを持つ必要があります。
ただし、RSSフィードURLのドメインはページにマッピングされているドメインに一致する必要はありません。この制限は、フィードの記事のカノニカルURLにのみ適用されます。
記事を言語ごとに異なるページに公開する場合、言語ごとに異なるRSSフィードを設定し、適切なRSSフィードを使用するように各ページを構成する必要があります。
いいえ。記事をRSSフィードから取り込むと、ページの投稿ツールから削除しない限り、インスタント記事として保存されます。次回の取得を短時間で処理できるように、RSSフィードから削除しても問題ありません。
現在のところ、API経由で記事を公開または削除する方法はなく、引き続き開発を行っています。
いいね！ボタンは、スタイル設定で構成するアクセントの色を使用します。アクセントの色がヘッダーの色と同じになっていないかご確認ください。
さらに、利用者が記事にすでに「いいね！」している場合はいいね！ボタンは表示されません。そのため、すでにページに「いいね！」しているページの管理者にはいいね！ボタンは表示されません。
1つの行に複数の<br>タグが使われていないか確認してください。記事のテキストを複数の段落に分割するには、改行ではなく段落(<p>)タグを使用することをおすすめします。
トラッキングピクセルを囲む「op-tracker」クラスが<figure>タグに追加されていることをご確認ください。このタグがない場合、画像埋め込みとして扱われます。
通常、この警告は、画像やインタラクティブな埋め込みなどテキスト以外のコンテンツを段落(<p>タグ)で囲んでいる場合に表示されます。段落には本文テキスト以外を含めることはできません。その他のコンテンツは<figure>タグやその他の適切なコンテナー要素で囲む必要があります。
いいえ。キャプション(<figcaption>)要素に使用できるのは<h1>タグ、<h2>タグ、<cite>タグのみです。段落(<p>)タグは使用できません。
現在のところ、<video>要素では「muted」属性は使用できません。
記事の広告は、標準のHTML5 <figure>要素を使用して定義します。この要素は、広告のマークアップを含む<iframe>要素を囲みます。<figure>要素にop-adクラスを指定すると、記事の広告を指定できます。広告の指定には2つの方法があります。iframeで「src」属性を使用して広告のURLを直接指定する方法と、エスケープしていないHTMLとスクリプトのセットをiframe内に埋め込む方法です。
広告の詳細については、https://developers.facebook.com/docs/instant-articles/reference/adをご覧ください。
標準の画像要素ではSVG画像を使用できません。代わりに、インタラクティブな埋め込み(「op-interactive」)を使用して<img>要素をiframeに追加し、「src」属性をSVG画像のURLを設定します。
Map要素に関するドキュメントは、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ピクセルです。
画像の間にスペースを追加するには、画像の間に空の段落(<p> </p>など)を追加します。
属性を追加するには、<figcaption>要素内に<cite>要素を使用します。
カバー画像では、いずれかの垂直位置属性を<cite>要素に明示的に指定することによって、属性を常に表示するように指定できます。指定しない場合は、画像を展開するまで画像の上には表示されません。
ソーシャルコンテンツを埋め込むには、「op-social」クラスを使用したfigureを追加し、埋め込むコンテンツを含むiframeを追加します。
詳細とコード散布については、こちらのドキュメントをご覧ください。
カバーを追加するには、動画ファイル(mp4ファイルなど)への直接リンクを使用する必要があります。Facebookに投稿されている動画のダイレクトリンクが提供されていない場合、カバーとして使用するには、動画を任意の場所にホストする必要があります。
テキストを太字にしたり、リンクを追加したりするなど、リストアイテム内には一部のHTMLタグを使用できます。色やフォントのスタイルをカスタマイズするには、Facebookページのインターフェイスでスタイルエディタを使用できます([設定] -> [インスタント記事])。
<video> HTML要素を使用して動画を埋め込む場合、Facebookでは複数の動画の連続再生はサポートされていないため、インスタント記事にプレイリストを追加することはできません。
動画プレイヤーは、埋め込まれるプレイヤーがiframeをサポートする場合にのみ、ソーシャル埋め込みとしてiframeに埋め込むことができます。
ブロッククオートは使用できません。段落タグの外側に配置する必要があります。
記事のタイトルが長く、2行で表示される場合は、ニュースフィードにはタイトルのみが表示されます。タイトルが1行に収まる場合は、ニュースフィードプレビューには記事のテキストの最初の部分も表示されます。
それぞれの記事のHTMLマークアップには、op-publishedクラスを使用して、記事が最初に公開された日時を示す<time>要素を含める必要があります。
op-modifiedクラスは必須ではありません。記事の内容を更新し、Facebookに保存されている記事のバージョンを更新する場合にのみ、<time>要素とop-modifiedクラスを含める必要があります。
<figure>が段落(<p>タグ)で囲まれていないかどうかご確認ください。画像は、figureタグで囲み、articleタグの下に直接ネストさせる必要があります。
幅やアイテムをインタラクティブな埋め込みとして指定する場合は、幅を指定する正数値をピクセル単位で使用してください。デフォルトでは、アイテムは最大幅で表示されます。
余白なしでインタラクティブな埋め込みを表示するには、「no-margin」クラスをコンテンツを含むiframeに追加します。
ページのRSSフィードがすでに承認されているのであれば、フィードのURLを変更したときに、再承認を申請する必要はありません。
各ページは一意のドメイン名にマッピングされます。RSSフィードのURL自体はこのドメイン名に一致する必要はありません。ただし、フィード内の個々の記事のカノニカルURLは同じドメインまたはそのドメインのサブドメインに属する必要があります。RSSフィードのURLのみを変更する場合は、それが原因で問題が発生することはありません。
記事のカノニカルURLが新しいドメインをポイントするように変更する場合は、パートナーマネージャからこのドメインの更新をリクエストする必要があります。手順は処理中に指示されます。
Facebookアプリに、本物のiPhoneストアID、iPadストアIDが設定されており、アプリセンター登録プラットフォームでiOS - iPadが有効になっていることを確認します。IDは、テスト用なら実際に使用しているIDである必要はなく、Apple App Storeで入手可能なあらゆるアプリを使用できます。
これは仕様です。フィードダイアログは添付ファイル付きのコンテンツを公開するため、追加で添付することはできません。
これは意図された変更点です。適切なプレイヤーに対するゲームリクエストの関連性を高める目的で、友達リストを短縮しました。なおプレイヤーは、検索フィールドを使用して、何人まででも友達を選択することができます。
また、この変更によりクリック数が増加し、全体的なCTRにも大きな増加が見られたこともお伝えしておきます。チャンネルの最適化を継続的に行い、利用者に合わせて適切なゲームを確実に届ける方法を探求しています。
og:titleやog:imageなどの変更は、現時点以降のリンクのシェアにのみ適用されます。
人やページがリンクをシェアして、投稿とのやり取りが50件を超えると(コメント、「いいね！」、シェア、など)、タイトルを変更できなくなります。これは、やり取りの後にサイトがリンクの詳細を変更してあなたが何か別のものとやり取りしたかのように見せるのを防ぐためです。他のプロパティはすべて、いつでも変更できます。
リンクをシェアして画像をアップデートした場合、投稿で画像を更新しない限り、元のシェアには引き続き古い画像が表示されます。
投稿でリンク画像を更新するには:- ニュースフィードの投稿に移動します。
- 投稿の右上にある楕円をクリックします。
- [シェアした添付ファイルを更新]を選択します。
タイトルは、そのオブジェクトに対して多数のアクションが実行されたときにフリーズされます。詳しくはこちらをご覧ください: 「Updating URLs (URLの更新)」。
画像がトリミングされる方法には、さまざまな要素が関係します。たとえば、顔が検出されると、できるだけそれが中心になるように試みられます。
大きな画像の場合は、トリミングなしで画像全体がフィードに表示されるようにするため、アスペクト比ができるだけ1.91:1に近くなるようにしてください。
ページ投稿では、リンクシェアに対して常に大きな横長の画像が使用されます。これはデスクトップのフィードでもモバイルのフィードでも同じです。フィードでトリミングなしで画像全体が表示されるようにするには、画像のアスペクト比をできるだけ1.91:1に近いものにしてください。
画像は非同期的にキャッシュされるため、コンテンツが初めてシェアされた時は画像が表示されない場合があります。これを回避するには、次のいずれかの手順を実行します。
- シェアデバッガーでスクレイピングして画像をプリキャッシュする
og:image:heightタグとog:image:widthタグを使って、画像を明示的に指定する
200x200ピクセル以上、600x315ピクセル以下の画像は、小さな正方形の画像で表示されます。
すべてのURLはリソース(ページ/画像)のカノニカルな場所を表すものであり、シェアや「いいね！」を正しいURLに帰して画像を適切に保存するためにも、URLは絶対である必要があります。
元の画像が利用できなくなっている、大きすぎる、または一時的な問題により取得できません。画像URLにクローラーがアクセスできる、サイズが8MBを超えていない、数秒の遅延内で提供されることを確認します。
ページのog:imageを更新したときは、既存のシェアにこの白色の領域が表示されるように、必ずサイトから古い画像を削除してください。
これは、データセンター間のレプリケーションの時間差が原因で発生します。このプロセスの完了までには数秒かかり、完了するまではAPIでオブジェクトIDにアクセスできません。
広告が完全に保存される前にその広告の詳細を読み込もうとすると、GraphMethodExceptionが返され、Unsupported get request. Object with ID 'XXXXXXXXXXXXXXXXXX' does not exist, cannot be loaded due to missing permissions, or does not support this operation.のようなメッセージが表示されます。
この問題は、少し待ってから広告の詳細を取得することにより回避できます。
特定のキャンペーンで、広告素材を使おうとするときに検証エラーが表示されることがあります。 これは、キャンペーンの目的が、その広告素材では使用できない場合に起こります。 たとえば、広告素材はキャンバスゲームを指しているのに、キャンペーンの目的が「MOBILE_APP_INSTALLS」になっている場合がこれに該当します。
検証エラーを解決するには、マーケティングAPI検証のベストプラクティスをご覧ください。
当該のアイテムを含んでいないアップロードセッションに、エラーがないかどうか確認してください。
製品アイテムは、アップロードセッションが成功して、deletion_enabledがtrueに設定されている場合のみフィードから削除されます。
このエラーが表示された場合、指定の広告アカウントのステータスを確認してください。多くは、広告アカウントが未決済のときにこのエラーが返されます。
この動作は仕様です。ページインサイトのバックエンドデータが保存されるのは2年分のみです。したがって、呼び出すと0値が返されます。0にならない項目は、投稿のインラインの「いいね！」、コメント、シェアのみです。これは投稿自体がデータを保持しているためです。
ターゲットスペックの構文を確認してください。特に、ターゲットスペックに有効なgeo_locationsパラメータと値があることを確認してください。
特定の目的で広告を作成すると、デフォルトのコンバージョンスペックが設定されます。コンバージョンスペックを変更すると、既存のスペックが上書きされます。
デフォルトのコンバージョンスペックがない目的の場合は、スペックを明示的に指定する必要があります。
これは、work_positionsで対象にする国のターゲット層が少なすぎるため、推定リーチに影響が生じないことが原因と考えられます。推定リーチに影響を与える、work_positionsの除外に追加される人数を改善するよう、継続してデータを収集しています。
これは、アプリでStream post URL securityの移行が有効になっている場合に発生します。
アプリでこの設定が有効になっていると、アプリ設定で参照されているキャンバスURLにリダイレクトされない限り、システムはいかなる種類のリンク投稿広告の作成も許可しません。アプリがキャンバスアプリで、キャンバスアプリのドメインにリダイレクトする記事のみを投稿する場合以外は、この設定を有効にする必要はありません。
利用者が、ビジネスマネージャ経由でアカウントと関連付けられている可能性があります。この場合、明示的なグラフAPIの関連付けとしては表示されません。
パートナーカテゴリが、適切なターゲットフィールドで指定されていることを確認してください。「/partnercategories」エンドポイントから取得されるパートナーカテゴリは、ターゲット設定タイプを指定するときに必要となるターゲットフィールドを指定する、「targeting_type」と呼ばれるフィールドを含んでいます。
たとえば、パートナーカテゴリで「behaviors」という「targeting_type」が返される場合、ターゲットスペックでの「behavior」フィールドでそのパートナーカテゴリを使用する必要があります。
ターゲット設定タイプとパートナーカテゴリについて詳しくは、https://developers.facebook.com/docs/marketing-api/partnercategories/v2.3#targeting_typesをご覧ください。
カスタムオーディエンスにinclusions/exclusionsが設定されていないために、このエラーが起きている可能性があります。この問題を解決する最善策は、新規カスタムオーディエンスを作成し、inclusions/exclusionsを確実に設定することです。
カスタムオーディエンスについて詳しくは、https://developers.facebook.com/docs/marketing-api/custom-audience-targeting/v2.3をご覧ください。
広告セットにはdaily_budgetとlifetime_budgetの両方が設定できます。お使いのアカウントの通貨で定義されるdaily_budgetの値は、最小値が100セントで、期間は24時間より長い必要があります。このフィールドのいずれかをクエリすると、両方が返されます。フィールドが未使用の場合は、0の値が返されます。
詳しくは、次のURLをご覧ください。https://developers.facebook.com/docs/reference/ads-api/adset
adcampaign_groupsエンドポイントでは、カーソルベースのページネーションを使用しているため、回数、制限、オフセットのフィールドを返すことはありません。一貫性のある結果を得るため、すべてのエンドポイントでカーソルベースのページネーションを使用することをおすすめします。
カーソルベースのページネーションの使用法について詳しくは、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_lead_gen_incomplete」を提供します。これによりビジネスは、リード以外の利用者を顧客にするためのフォールバックエクスペリエンスを用意することができます。詳しくは リード獲得広告後のHOP Webhook をご覧ください。
[概要を送信]がデフォルトで有効になるのは、広告中の[テンプレートを作成]ダイアログでアプリが選択されている場合のみです。概要は、リンクされたアプリの選択後に広告上で無効にできます。アプリが選択されていない場合でも、リード獲得広告はスレッド制御をハンドオーバープライマリレシーバーに渡す(設定されている場合)か、単にスレッド制御を解放します。リード送信後のすべてのフォローアップメッセージは、サブスクリプション登録されたアプリに送信されます。アプリはスレッドAPIにクエリしてメッセージ履歴を取得し、リード獲得中に共有された情報を取得することができます。
デフォルトでは、リード獲得広告の進行中は送信APIとWebhookがブロックされます。App Id: 413038776280800のMessengerリード獲得アプリがスレッド制御を取得します。この動作は、広告内にある[テンプレートを作成]ダイアログの[送信APIをブロック]トグルを使ってオフにすることができます。
リード送信が終了すると、アプリはユーザーメッセージのWebhookを取得し、メッセージに返信することができます。アプリの一部としてアプリが選択された場合、その選択されたアプリのみが返信を許可され、メッセージングチャネルのWebhookを取得します。メッセージ期間が始まり、アプリは送信APIを使って返信できます。
アプリのインストールはアプリのウェブサイトから行い、 Facebookログイン を使用して特定のページにpages_messagingアクセス許可を付与します。認証済みアプリは、[メッセージの詳細設定]内の[ページ設定]で確認できます。
表示されるのはページの認証済みアプリのみです。認証済みアプリは、[メッセージの詳細設定]内の[ページ設定]で確認できます。アプリのインストールはアプリのウェブサイトから行い、 Facebookログイン を使用して特定のページにpages_messagingアクセス許可を付与します。
はい、1つのFacebookアプリが複数のページをフォローすることはできます。pages_messaging権限などのアプリレビューを通過したアプリは、複数のページのWebhookを受け取るようにフォローすることができます。ペイロードに基づいて、各Webhookから取得するコンテキストは自由に決められます。
はい、複数のアプリをページにサブスクリプション登録できます。複数のアプリで同じスレッドを扱う場合に最適な方法は ハンドオーバープロトコル を使ってスレッドを所有するボットを常に管理することです。
Messengerプラットフォームの統合にプラットフォームテストユーザーを使用するための回避策を説明します。
- アプリの役割ページで、[テスターを追加]ボタンをクリックして新しいテストユーザーを作成します。
- [このアプリのテストユーザーを許可しますか？]オプションを切り替え、"manage_pages"と"page_messaging"のアクセス許可を付与します。
- [編集]ボタンを使用して、このユーザーのアクセストークンを取得します(v2.6を使用)。後で使用するため、このアクセストークンは保存しておいてください。
- [編集]ボタンを使用して、テストユーザーとしてログインします。
- ログイン後、テストユーザーとしてページを作成します。
- このテストユーザーのユーザーアクセストークンを使用して、このユーザーのページアクセストークンを取得します。この操作は次の呼び出しを使用して実行します。
https://graph.facebook.com/v2.6/me/accounts?access_token=[TEST_USER_ACCESS_TOKEN]
(ドキュメント) - このページアクセストークンを使用して、Facebookアプリケーションをページにリンクさせます。
https://graph.facebook.com/v2.6/me/subscribed_apps?method=POST&access_token=[TEST_USER_PAGE_ACCESS_TOKEN](ドキュメント) - これらの手順を実行すると、テストページにRTUのアップデートが送信され、テストページからテストユーザーにメッセージを送信できるようになります。
上述の操作に加えて、トークンの有効期限が短すぎてテストできない場合は、アクセストークンを長期トークンに置き換えることができます。こちらのドキュメントの手順に従ってください。
GET /oauth/access_token? grant_type=fb_exchange_token& client_id={app-id}& client_secret={app-secret}& fb_exchange_token={short-lived-token}
このような場合、次のようにいくつかの原因があります。
- FacebookログインのIDを使用している。 FacebookログインのユーザーIDを送受信APIで使用することはできません。Messengerプラットフォームの認証を通じて取得したIDのみが、Messengerプラットフォームで機能します。
- ページアクセストークンが間違ったIDを使用している。 MessengerプラットフォームのユーザーIDはページを対象としているため、ページに固有のものです。有効なユーザーIDでも、そのページアクセストークンが別のページに関連付けられている場合は、呼び出しが機能しません。必ず同じページに関連付けられたユーザーIDとページアクセストークンを使用してください。
- 最近認証されたものではない電話番号に送信している。 電話番号を使って送信APIを使用するときは、電話番号が最近認証されたものである場合にのみ、メッセージが送信されます。電話番号が認証済みであると表示される場合であっても、最近認証されたものでない場合は、送信が失敗することがあります。電話番号を再度認証し、24時間待ってから再度送信してください。
「Messengerに送信」プラグインを使用する際に、data-refパラメータをパススルーパラメータとして使うと、クリックのコンテキストに関する情報を通じて送信できます。
また、利用者はMessengerの検索機能を使用してあなたのページを見つけることもできます。このような場合、パススルーパラメータは使用できません。アカウントのリンク機能を使用すると、スレッドをサイトのユーザーアカウントに関連付けることができます。
Messengerの設定の下のアプリダッシュボードに、[最近のエラーを表示]というボタンがあります。このボタンを押して、Webhooksに対する応答が200であれば失敗していることになります。
最近のWebhookのエラーを表示するツールがあります。Webhooksで配信に失敗している場合、Facebookサーバーは該当するURLをサブスクリプション登録解除することになります。このツールを利用するには、アプリダッシュボード> [Messenger] > [設定]に移動し、Webhooksカードの中の[最近のエラーを表示]というボタンを使用します。
webhookからの応答のステータスコードが200になっていることを確認してください。これは、webhookが正しく受信されたことを示します。200が返されない場合は、正しく処理されるまで呼び出しが繰り返されます。また、webhookが長期間にわたって200を返さない場合は、開発者アラートが表示されます。
成功のステータスコードは時間通りに返されます。webhookの呼び出しは20秒後にタイムアウトします。成功のステータスコードがただちに返されて個別に処理されるように、このwebhookのようなコードは非同期に処理されるように設定してください。
webhookへの呼び出しには、X-Hub-Signatureという名前のヘッダー内にフィールドが含まれます。このフィールドを使用すると、呼び出しがFacebookから来たものであることを検証できます。
コールバックの受信には2つの手順が必要です。まず、webhookが正しく設定されていることを確認します(https://developers.facebook.com/docs/messenger-platform/webhook-reference#setup)。webhookが適切に設定されていることを示すインジケーターがあります。
次に、各ページをフォローします。フォロー対象のページはすべてリストに表示されます。
webhookへの呼び出しが長期間にわたって失敗する場合は、アプリのフォローが解除され、webhookやページの再フォローが必要になります。
OGタグを設定する以外に、オープングラフ記事をシェアするときにニュースフィードやタイムラインでの投稿の表示状態を変えることはできません。Facebookでは、コンテンツのエンゲージメントを最大化するよう、自動的に投稿を最適化します。
はい。アクションリンクの機能は廃止されました。アクションリンクのサポートはFacebookサイトから削除され、プラットフォームでも廃止となりました。将来的に再導入する可能性もありますが、現行のロードマップには入っていません。
ウェブページでOpenGraphメタタグを使用しており、og:imageエントリが含まれる場合、プレビューではその画像を取得して表示します。また、サイトのog:imageでog:image:widthとog:image:heightの両方を指定している場合、最初に作成されたシェアでもその画像が使用されます。
これらを指定していない場合は、クローラーが最初に画像を取得して分析するまで待つ必要があります。このしくみの例については、http://ogp.me/#structuredをご覧ください。
これは仕様です。REST APIは廃止されてから時間が経っており、機能を継続させる予定はありません。ページアクセストークンは、REST APIでは使用できないという制限があります。
「いいね！」ボタンの地域設定は、JS SDKの「locale」パラメータを使用することで設定できます。これは、ログインしていない利用者に対して有効です。利用者がログインしている場合は、個々の言語設定も考慮されます。特定の言語に設定されていれば、「いいね！」ボタンはその言語で表示されます。
この動作は、Facebookにログインせずにページを開くか、ブラウザのプライベートセッション機能を使用して確認できます。
Facebookでシェアするとき、テキストエリアに事前入力するとFacebookポリシー違反になります。アプリの利用者が、シェアするテキストを自分で入力するようにします。
シェアするときにテキストエリアに事前入力することは、プラットフォームポリシー2.3( https://developers.facebook.com/policy/#control )に違反します。Facebookでは、利用者が望む内容のみを正確にシェアできるようにして、本人が承認していないテキストを誤ってシェアすることがないように、このポリシーを施行しています。
これは意図された動作です。ウェブページのURLを変更または修正した場合に発生します。コメントプラグインを格納する各URLは個別のオープングラフオブジェクトとして扱われ、コメントはそのオブジェクトに関連付けられます。したがって、URLを変更すると新規オブジェクトが作成されるため、既存のコメントがページ上に表示されない可能性があります。
いいえ、できません。APIを経由してコメントプラグインにコメントを投稿することは許可されていません。
sharerでは、カスタムパラメータを渡すことはできません。その代わりに、ページのopen-graphメタタグから直接メタデータを取得します。
コンテンツのシェアのベストプラクティスについて詳しくは、 https://developers.facebook.com/docs/sharing/best-practicesのドキュメントをご覧ください。
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/)を変更することはできません。適切に動作させるには、すべてのメディアストレージをこのデフォルトの場所に配置する必要があります。
いいえ。現在のところ、CoreappとWebappの間でメディアボリュームを共有するには、AWS EFSを使用する必要があります。
いいえ、FacebookはKOPSをサポートしていません。ECSに基づくAWSソリューションはサポートしています。一般的なKubernetes minikubeのセットアップにも対応しています。
Coreappによって、Coreappコンテナ内の/usr/local/waent/dataディレクトリと/usr/local/waent/logディレクトリに10MB以上のストレージがあることがチェックされ、不足している場合はこの重大なエラーが発生します。
ログやデータディレクトリをチェックして、十分な空き容量を確保してください。
いいえ。現在のところ、同じWhatsApp Business APIクライアント設定で複数の電話番号を運用する手段はありません。将来的にこの問題を解決するため、適切なソリューションの開発が行われています。
messageStore.messagesテーブルとmessageStore.messages_receipt_logテーブルからメッセージと対応するメッセージ受信を破棄するには、データベースガベージコレクションのservices APIエンドポイントを使用します。
pass_throughアプリケーション設定を再確認してください。WhatsApp Business APIクライアントv2.29.1以上でpass_throughを有効にしている場合、読み取りステータスのコールバックを受け取れません。
読み取りステータスのコールバックを受け取りたい場合は、pass_throughアプリケーション設定を無効にしてください。pass_throughを無効にすると、データベースストレージが急激に増大することがあるので注意してください。データベースの管理の詳細については、データベース管理に関するドキュメントをご覧ください。
データベースガベージコレクションは、データベースを管理しやすくするために、messagesテーブルとmessages_reciept_logテーブルを定期的にクリーンアップします。
ガベージコレクターは、配信/処理が正常に動作するように、特定のメッセージを維持します。たとえば、特定の期間に受信したメッセージを維持して、ビジネス統合がメッセージを既読としてマーク付けできるようにします。
Coreappでは、ガベージコレクションがランダムな間隔(たとえば、数時間ごと)で実行されます。これは、データベースでの競合による高可用性スタックでのパフォーマンス低下の危険性を防止するためです。
ガベージコレクションはコールバックキューとは無関係に動作します。たとえば、Webhookサーバーが4日間使用できない場合は、Webhookサーバー接続の復旧時に配信されるようにコールバックが保存されます。
リンクがクリック可能としてレンダリングされるのは、受信者がすでにあなたのビジネスの電話番号を連絡先として保存している場合、またはあなたが公式ビジネスアカウントを持っている場合のみです。
v2.29.xまでは、バグのために、時間経過とともに送信メッセージキューのサイズが大きくなることがありました。v2.29.3にアップグレードすればこの問題は解決します。
予想されるユーザーの所在地と言語に基づいて、適切なQRコードを使用する責任はコードの作成者側にあります。
WhatsApp Business管理API内でQRコードの生成と管理を直接行えるようになり、ユーザーは自分のWhatsApp、iOS、Androidカメラでスキャンできます。
さらに、WhatsApp QRコードを使用すると
- 事前入力されたメッセージは完全にカスタマイズでき、いつでも変更または削除できます。
- ユーザーはインタースティシャルページを経由せず、常にアプリに直接アクセスできます。
- 期限が切れたコードのアプリ内エクスペリエンスで、ユーザーに明確なメッセージが送られます。
削除済みのQRコードまたは招待リンクにアクセスしようとすると、そのQRコードまたは招待リンクが期限切れになっていることを示すエラーメッセージが表示されます。
WhatsAppデスクトップクライアントがインストールされている場合は、ビジネスとのスレッドが開始されます。インストールされていない場合は、WhatsAppデスクトップクライアントをインストールするよう促すプロンプトが表示されます。
新しい招待リンクでは、リンクと関連付けた事前入力メッセージが使用でき、メッセージはいつでも編集または削除できます。また、URLの構文が短縮されてランダムなコードになるため、URLにメッセージを埋め込む必要がなくなり、電話番号を非表示にすることができます。
印刷物で最高品質を実現するためには、.svgファイルフォーマットをおすすめします。
WhatsApp Business管理APIまたはビジネスマネージャUIで、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公式ビジネスアカウントの取得をリクエストする方法については、公式ビジネスアカウントのリクエストドキュメントセクションの手順を参照してください。
いいえ。 現時点では、メッセージの制限は、事業者が発信するメッセージ(通知)にのみ適用されます。
WhatsApp Business APIから画像をアルバムとして送信する際は、少なくとも4つの画像を連続して送信する必要があります。画像の受信時点でユーザーのスレッドビューがアクティブになっていると、次回のアクセスまでアルバムビューは利用できません。
次のいずれかの条件に該当する場合、アルバムは作成されません。
- キャプション付きの画像
- 未読の小見出し - 一部の画像のみユーザーに表示されます
- 日付ヘッダー - 配信の合間の新しい日付
いいえ。現時点では、WhatsApp Business APIクライアントはDocker for Windowsでは動作しません。開発に必要な場合は、Linux仮想マシンを使用して、Linux上でDockerを実行する方法をおすすめします。本番ワークロードには、互換性とパフォーマンスの問題を回避するためにLinuxサーバーを使用することをおすすめします。
471エラーコードは、品質ベースのレート制限と関連があります。詳細については、品質ベースのレート制限に関するドキュメントをご覧ください。
すべてのビジネスは一番下の層から開始し、高品質のメッセージを多く送信すると、自動的により高い層にアップグレードします。
はい、メッセージテンプレートを送信するときに、受信側で表示に失敗した場合、エラーオブジェクトに「構造を利用できません」というメッセージが表示されなかったことを示す「失敗」のステータスコールバックを受け取ります。受信者によっては、メッセージが受信者に配信された後に、メッセージの表示に失敗したことを示す「配信済み」のステータスコールバックを受け取る場合もあります。
メッセージテンプレートの送信側検証エラーと、エラーが表示される原因を以下に示します。
- 「言語your-languageにメッセージテンプレートが存在しません」または「言語your-languageおよびロケールyour-localeにメッセージテンプレートが存在しません」 — 指定された言語パックが存在しません。ビジネスマネージャアカウントを確認してください。
- 「テンプレートyour-template-nameが言語your-languageに存在しません」または「テンプレートyour-template-nameが言語your-languageおよびロケールyour-localeに存在しません」 — 使用しようとしているテンプレートが存在しません(作成されていないか、まだ承認されていません)。削除されたテンプレートを使用してメッセージを送信しようとしたときも、このエラーが表示されます。
- 「localizable_paramsの数num1が、期待されるparamsの数num2と一致しません」 — 送信しようとしているメッセージテンプレートのパラメーターが、期待されるパラメーターの数と一致しません。API呼び出しが正しいことを確認してください。
- 「your-template-nameはリッチテンプレートであり、テンプレートメッセージAPIを使用する必要があります」 — メディアメッセージテンプレートを通常メッセージテンプレートとして送信しようとしています。メッセージタイプが
templateであることを確認してください。詳しくは、「メッセージテンプレートに関するドキュメント」をご覧ください。 - テンプレートがビジネスマネージャで承認(または削除)されてから、WhatsApp Business APIクライアントが更新されたテンプレートを受信するまでに最大で20分かかります。承認されたばかりのテンプレートを使用してメッセージを送信しようとしたときに、テンプレートが存在しないというエラーが表示された場合は、上記の時間が経過するのを待ってからメッセージの送信を再試行してください。
重複したメッセージがWhatsApp Webhookに送信されるのは、メッセージが少なくとも1回(1回だけではなく)必ず受信されることを保証するためです。これが端末でのメッセージの処理方法に影響する場合は、メッセージIDに基づいて重複するWebhookメッセージが削除されるようにすることをおすすめします。
リリースv2.18.26以降、アプリケーションの統計情報エンドポイントでは、内部指標をPrometheusテキスト形式でエクスポートすることが可能です。詳細については、インスタンスのモニタリングに関するドキュメントをご覧ください。
ビジネスプロフィールのデータが一部のみ設定されている場合は、空のprofileオブジェクトが返されます。この問題を解決するには、v2.21.4にアップグレードしてください。
ビジネスプロフィールの設定を完了する方法について詳しくは、ビジネスプロフィール設定ドキュメントを参照してください。
AWSデプロイメントの設定時に次のようなエラーが表示される場合は、8文字以下のスタック名に変更してみてください。
国名(2文字のコード) [AU]:州名(正式名称) [州]:市区町村名(市など) []:組織名(会社など) [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通知がユーザーエクスペリエンスおよび一般的な製品全体に及ぼす影響を測定および理解するための実験を実行します。メッセージ送信先のユーザーがこれらいずれかの実験の対象者である場合、それらのユーザーは、メッセージの受信をオプトインしていたとしても、通知を受け取らないことがあります。
現在の設定をバックアップして新しいマシンでそれを復元する場合、登録情報は実装のその他の部分とともに移行されるはずです。詳細については、「バックアップと復元の設定」ドキュメントをご覧ください。
はい。webappコンテナのログローテーションとcoreappコンテナのログローテーションの動作には、若干の違いがあります。
- Webapp: 最新のログファイル30件が保持されます。ログファイルのサイズが20MBを超える場合にのみ、ローテーションが行われます。
- Coreapp: 最新のログファイル30件が保持されます。ログファイルのサイズが15MBを超える場合にのみ、ローテーションが行われます。ローテーションが行われたファイルは圧縮されます。
WhatsApp Business API Clientのすべてのビルドには、リリース日から6か月の有効期限があります。このエラーが表示された場合は、できるだけ早く最新のリリースバージョンにアップグレードしてください。
メッセージを送信する前に、まず連絡先が存在するかどうかを確認する必要があります。この方法について詳しくは、連絡先に関するドキュメントを参照してください。
注:fallback言語ポリシーはv2.27.8以降廃止されており、現在ではdeterministic言語ポリシーがデフォルトポリシーです。
新しい言語で翻訳を作成する場合、使用するすべてのエレメントを新しい言語に翻訳する必要があります。そうしないと、受信者の携帯電話で自分の言語でのエレメントが見つからず、「structure unavailable」エラーが発生することがあります。このような「structure unavailable」エラーは、フォールバックポリシーを使用してテンプレートメッセージを送信する際に表示されます。
現時点で言語の翻訳を作成することができない場合、決定性ポリシーを使用してこれらのエラーを回避することができます。
ユーザーから送信されるメッセージペイロードは、テキストまたはメディアファイルのいずれかです。
テキストの場合、これまで危険は確認されていないと考えられています。
メディアファイルの場合:
- 一般的に、ビジネスは、潜在的な脅威を分析するための適切な保護ソフトウェア（ウイルス対策やマルウェア対策用のソフトウェア）を備えていることが期待されます。
- 転送されるファイルはエンドツーエンドで暗号化されているため、WhatsAppはそのようなファイルのコンテンツを識別または確認できません(テキストのみのコンテンツについても同じです)。
- ただし、WhatsAppビジネスAPIクライアントにメディアファイルが自動的にダウンロードされないようにする方法があります。ビジネスがユーザーからのファイルを受け取らないようにするには、
auto_downloadフィールドを空の配列に設定します。
いいえ。同じ電話番号を使用している複数のデバイスをWhatsAppビジネスAPIを使って検出する方法はありません。
スマートフォンがテンプレートメッセージを読み取れない場合、structure unavailable (構造利用不可)のエラーが発生します。
テンプレートはサーバーに保存されています。テンプレートメッセージが messages ノードを使って送信されると、メッセージ全体ではなく、名前空間、言語、要素名、ローカライズされたパラメーターのみがスマートフォンに送信されます。これらの値がスマートフォンに配信されると、スマートフォンはメッセージのレンダリングを試みます。
レンダリングの間に何らかのエラーが発生した場合、 structure unavailable エラーが、受信者とメッセージIDが指定されてコールバックURLに送信されます。このようなエラーは、ネームスペースが間違っている、ローカライズされたパラメーターが一致しない、要素名が間違っているなどの理由で発生します。
FacebookビジネスマネージャのWhatsAppマネージャに移動し、パラメーターの正しい数を確認してください。ネームスペースが正しく、要素名が存在していることを再度確認してください。
エラーのよくある原因の1つは、使用しているすべてのテンプレートの翻訳を作成していないことです。たとえば、よく送信する2つのテンプレートがあり、そのうちの1つの新しい言語の翻訳を追加する場合、もう一方のテンプレートのその言語の翻訳も必ず追加してください。複数の言語をサポートする予定の場合、サポートするすべての言語の翻訳を、すべてのテンプレートに対して用意する必要があります。
幸いなことに、 structure unavailable エラーの通常の原因は messages API呼び出しに誤りがあることであり、その場合は送信ペイロードを変更することで修正できます。
FacebookビジネスマネージャのWhatsAppアカウントで新しい電話番号を登録し、古い番号を削除することができます。
- WhatsAppアカウントで、[設定]に移動します。
- [WhatsAppマネージャ]をクリックします。
- [電話番号]タブを選択します。ここで、このアカウントのすべての電話番号を管理できます。
画像には、説明としてキャプションが追加されます。AndroidとiPhoneのどちらの画像も、キャプションテキストは実際の長さで表示されます。
ドキュメントの場合、キャプションはファイル名に置き換わります。これは、ユーザーのデバイスに説明テキストとして表示されることを意図しておらず、代わりにファイルの名前を示しています。iPhoneの場合は実際のテキストの長さで表示されますが、Androidはファイル名が短縮されて表示されます。これは、両方のデバイス上のWhatsAppにおける現在の実装の技術的な制限です。
登録の試行回数が多すぎて「SMS」で登録失敗し、「アクセスできません」というメッセージが表示される場合、「音声」で登録を試行してください。
現在は7日間です。キャッシュに7日間以上更新がない場合、パックのエレメントの有無に関わらずサーバーから最新の言語パックが取得されます。
デバイスはまずキャッシュから読み込み、要素が存在する場合はそのメッセージテンプレートを使用してメッセージを開封します。そのため、メッセージテンプレートを修正するよりも、別の要素名でテンプレートを新規で追加するほうがずっと安全です。こうすることで、その要素が見つからない場合に、言語パックが確実に再ダウンロードされます。メッセージテンプレートのストレージコストは無視できるほど小さいため、メッセージテンプレートを削除する絶対的な必要性はありません。
詳しくは、「メッセージテンプレートの送信 - 言語」をご覧ください。
ビジネスとユーザーにとって高いエクスペリエンスを維持するために、プレビューの公開を制限しています。Facebookでのビジネスを検討している場合、アベイラビリティを拡大中なので、検討材料としてビジネスに関する情報を送信してください。あるいは、すでにFacbookアカウントをお持ちの場合は、担当者にご連絡ください。
usersエンドポイント経由でユーザーアカウントからログアウトすると、そのアカウントに割り当てられたすべての認証トークンが無効になります。ユーザーを削除しても同じ効果が得られますが、それはかなり極端なやり方です。usersエンドポイント経由でユーザーアカウントにログインすると新しい認証トークンが返されますが、そのユーザーに対してすでに利用されている認証トークンは無効にならないことに注意してください。以前プロビジョニングされたトークンを所有しているすべての人は、トークンが期限切れになるか前述の方法のいずれかで無効化されるまで、トークンを引き続き使用できます。
このエラーが表示されていても、エラーで参照されている必須パラメーターがjson本体に設定されているのであれば、 json解析エラーである可能性があります。jsonフォーマットエラーが原因でjsonペイロード全体が解析不能である場合に、このエラーが発生することがあります。これらのパラメーターの値に、末尾の改行など、無効なjson文字がないかどうか確認してください。コピーしたパラメーターに余分な空白文字が含まれていて、その中にjsonを終了する文字があるということもよくあります。
多くの原因が考えられます。Coreappがダウンしているか、データベースが正しく設定されていない可能性があります。それ以外の場合は、Coreappログ(マルチコネクトを実行している場合はマスターCoreappログ)をご覧ください。データベース接続エラーが表示される場合、接続を使い果たしていることが考えられます。このエラーに関しては、MySQLのドキュメントまたはPostgreSQLのドキュメントを参照してください。
データベースで接続数を増やすことをおすすめします。データベース接続数が1000個あれば安全と考えられますが、接続数については詳細を十分に検討したうえで決定してください。エラーが続く場合は、サポートチケットをオープンしてください。
メッセージテンプレートが却下される原因には次のものがあります。
- 暴言やスパムのようなコンテンツなど、不適切である可能性があるコンテンツが含まれる
- 宣伝コンテンツが含まれる
- 選択したタグの種類に一致しない
- 形式が不正確
「connection refused」エラーは、恐らくCoreappが実行されていないことを意味しています。docker psを使用して、Coreappが動作しているかどうかを確認してください。動作していない場合、Dockerのログを確認してください。Coreappはデータベースに接続できない可能性があります。データベースが正しく設定されていることを確認してください。
これは、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.
はい、TCP接続が必要です。ビジネスが追加のポートを開くことができない場合は、終了したSSLを使用できます。
詳しくは、ネットワーク要件のドキュメントをご覧ください。
これは既知の問題です。CloudFormationスクリプトを使用してWhatsApp Business APIをアップグレードする場合、RDS DBスタックへの更新も必要になることがあります。新しいRDSスタックのホスト名が元のスタックのホスト名とは別のものになるため、Dockerコンテナがデータベースに接続できなくなります。解決策として、CloudFormationによって作成されたEC2インスタンスにSSHを使用して接続し、新しいホスト名を使用してwhatsapp.confファイルを更新してから、Dockerコンテナを再始動して新しい設定を適用します。
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コールバックがCoreappコンテナを介して送信されます。そのため、Webhookエンドポイントは、Coreappからのインバウンドリクエストを受け入れるように構成されている必要があります。
テスト用には、2つ目の電話番号を登録して、2つ目のCloudFormationスタックまたはDockerインスタンスを作成してください。同じ電話番号を使用するアクティブなWhatsApp Business APIクライアントが2つあると、暗号キーが競合することにより、サーバーから追い出される可能性があります。2つ目の環境を作成し、それを使用して本番ではないインスタンスをテストしてから、本番用クライアントに移行する、という方法をおすすめします。
MySQL 5.7.x、PostgreSQL 9.5.x、9.6.x、10.xが必要です。以前のバージョンを使用すると、Unable to initialize config storeエラーが発生します。
メッセージを送信するとメッセージIDが返されますが、それはメッセージリクエストがデータベースに格納されたことを意味します。WhatsAppビジネスAPIクライアントは、WhatsAppサーバーによって認識されるまで、そのメッセージの送信を試行し続けます。このプロセスに終了期限はありません。次に、WhatsAppサーバーは、メッセージをユーザーの携帯電話に配信しようとします。ユーザーの携帯電話がオンラインでない場合、メッセージは30日間保存された後、WhatsAppサーバーによって破棄されます。
データベース表には、アプリの設定、チャットスレッド、メッセージ、メディアなどに関連する情報が保存されます。これらはすべて、アプリを動かすために必要な情報です。
カスタマーがWhatsAppの電話番号を変更しても、ビジネスには通知されません。contactsノードを使用すると、その電話番号のステータスはinvalidとなります。
いいえ。インスタンスで使用できるアカウントは1つのみです。2つ目のテストアカウントが必要な場合、2つ目のインスタンスには必ず別の番号を使用してください。
容量が少なくなると、システムの動作が遅くなることがあります。メディアファイルやメッセージが多すぎることや、ログファイルが大きすぎることが原因と考えられます。ログファイルは自動的にローテーションされますが、サイズが大きくなった場合は削除しても問題ありません。
メッセージはデータベースに保存されています。メッセージは必要に応じて削除することができます。また、アプリケーション設定でpass_throughがfalseに設定されていると、メッセージは明示的に削除されるまですべてデータベースに保存されます。
ユーザーから送信されるメディアファイルは、メディアボリュームにダウンロードされます。どのメディアファイルを削除するかはビジネスに委ねられていますが、通常はどのメディアファイルを削除しても問題ありません。docker inspect your-container-idを使用してメディアファイルの場所を確認できます。
Docker MySQLガイドにしたがって、Dockerを使用してMySQLをローカルにセットアップします。
Docker PostgreSQLガイドにしたがって、Dockerを使用してPostgreSQLをローカルにセットアップします。
多くの場合、データベースは、コアコンテナやWebコンテナとは別の物理サーバーで実行する必要があります。データベースサーバーとコンピュートマシンの間の遅延は、数ミリ秒以内である必要があります。
メディアの削除のタイミングは各ビジネス次第です。
メディアをアップロードするとメディアIDを受け取りますが、これを使用してアップロードしたメディア要素を含むメッセージを送信することができます。メディアメッセージを送信すると、WhatsApp Business APIがメディアを暗号化してから WhatsAppサーバーにアップロードし、メディアはそこに14日間保持されます。その後、各ビジネスはメディアIDを指定してメディアを削除するか、後の使用のために保持するかを判断できます。メディアを30日間保持することを推奨していますが、それぞれのビジネスポリシーや使用事例に応じてリテンションポリシーを決めてください。
はい、WhatsAppに関連するテーブルに手を付けずにデータベースを他の方法で使用することができます。
許可リストは、ホスト名とIPアドレスのどちらでも作成できます。
詳しくは、ネットワーク要件のドキュメントのホスト名のセクションをご覧ください。
はい、できます。WhatsAppでは、メッセージ内の選択したテキストに、太字、斜体、取り消し線、または等幅のフォーマットを設定することができます。
はい。メッセージテンプレートは、すべてのWhatsAppメッセージ文字に加えて、絵文字、太字、斜体などを含む書式をサポートしています。絵文字については、対応するUnicode文字ではなく、絵文字キャラクター(コピー/貼り付け)を使用する必要があります。
フリーダイヤル番号は、国コードが含まれていれば使用できます。これは、国コードが含まれないフリーダイヤル番号では、同じ電話番号が2つの異なる国の電話番号に該当する場合があり、固有に識別できないためです。
また、フリーダイヤル番号には、他にも注意が必要な点があります。通常、国内でその国の国コードを付けてフリーダイヤル番号に電話を掛けてもつながりません。これは、国内の顧客がビジネス連絡先に記載された番号(国コード付き)に電話を掛けようとしてもつながらない可能性があることを意味します。その点が心配な場合は、顧客に番号を明示的に知らせる必要があります。
フリーダイヤル番号について詳しくは、こちらをご覧ください。
いいえ！どんな時でも、単一の電話番号で実行できるのは1つのインスタンスのWhatsApp Business APIクライアントだけです。2つ目のインスタンスを登録すると、すぐに1つ目のインスタンスは解除され、失敗します。WhatsAppでは、この問題を適切に解決するべく取り組んでいます。最新情報は随時通知されます。
WhatsAppは、ビジネスAPIユーザーが自分で制御するサーバー上のAPIエンドポイントを管理する場合、それらのユーザーとの通信はエンドツーエンドで暗号化されていると見なします。これは、エンドポイント間でコンテンツへのサードパーティアクセスがないためです。
一部の組織は、WhatsApp Business APIエンドポイントの管理をサードパーティのビジネスソリューションプロバイダーに委任していることがあります。その場合も、通信では同じSignalプロトコル暗号化が使用されます。しかし、WhatsApp Business APIユーザーがエンドポイントの管理をサードパーティに委任しているため、WhatsAppはこれらのメッセージがエンドツーエンド暗号化されているとは見なしません。これは、2021年中に、FacebookがホストするAPIのクラウドベースバージョンを利用している事業者にも適用される予定です。
さらに、WhatsApp Business APIクライアントへの呼び出しでHTTPSを使用している場合、その(バックエンドクライアントからWhatsApp Business APIクライアントへの)データはSSLで暗号化されます。
詳しくは、WhatsAppの暗号化の概要に関するテクニカルホワイトペーパーをご覧ください。
これは、古いバージョンのiOSクライアントの不具合が原因です。一般人口の増加に伴って、エラーが減少することが期待されます。
いいえ。メッセージが送信された順序で到着することは保証されていません。順序が重要な使用事例では、最初のメッセージの配信のコールバックをリッスンしてから、2つ目のメッセージを送信する方法を推奨します。
外部からトリガー可能な、コンテナ内の古いログをクリーンアップする次のスクリプトを使用できます。
docker exec CONTAINER_NAME /opt/whatsapp/bin/cleanup.sh
このスクリプトは、Webappコンテナにもコアアプリコンテナにも使用できます。このスクリプトを実行すると、コンテナ内に30ファイルのみが残るように、古いログファイルが削除されます。
注:WhatsApp Business APIを使用して、同じ受信者に同じメッセージを繰り返し送信しないでください。
配信率が100%でない場合は、いくつかの理由が考えられます。よくあるケースとしては、ネットワークにたまにしかアクセスしないユーザーや、一定期間アクティブでないユーザーがいることや、高品質のユーザーエクスペリエンスを作成すること が挙げられます。
WhatsAppで配信可能なメッセージには、配信率が非常に高いという傾向があります。しかし、メッセージが配信されなくなり得る理由はたくさんあります。コールバックをモニタリングすることで、メッセージの正確なステータスを把握することができます。しかし、これは、例えば、SMSでメッセージを送信する場合とは異なります。この場合、最終送信ステータスにアクセスできなかったため、メッセージを再送信すると、まったく異なる結果になる可能性があります。
ユーザーの携帯電話が故障している、バッテリ切れである、または携帯電話を紛失したユーザーが新しい携帯電話を入手して以前のSIMを停止したなどの理由で、メッセージが配信されないままになっていることがあります。ビジネスクライアントがネットワークに接続しようとするときにエラーが発生する可能性があります。コールバック(Webhooks)が配信されない可能性もあります。healthノードを使えば、これらの状況をモニタリングすることができます。サーバーの受信コールバックをオンにして、メッセージがWhatsAppサーバークラウドに配信されたことを確認できます。
ユーザーがネットワークに再接続した場合は、送信したメッセージがすべてユーザーに送信されます。同じコンテンツのメッセージを何通も受信することは、ユーザーにとって気持ちのよいことではありません。ユーザーからブロックされたり、クレームを受けたりする確立が高まります。配信登録が解除されかねません。
送信したメッセージに対してAPIからメッセージIDを受け取ったなら、そのメッセージを送信するためにすべきことはすべて完了しています。同じコンテンツを同じ受信者に再送信しないでください。
長期にわたって配信率が低下している場合は、 ダイレクトサポートからサポートチケットを提出してください。
WhatsApp BusinessオンプレミスAPIクライアントの場合、ビジネスとカスタマー間で送信されたメッセージを復号するためのキーを保管するデータベースが必要になります。WhatsAppのすべてのメッセージは、送信者と受信者のキーで暗号化されています。カスタマーのキーはカスタマーのモバイルデバイスに保存され、ビジネスのキーはそのビジネスのデータベースに保存されます。詳しくは、WhatsAppのセキュリティをご覧ください。
Metaがビジネスのデータベースをホストしてる場合、WhatsApp BusinessクラウドAPIを代替として使用できます。クラウドAPIを使用すれば、自社サーバーをホストする経費をかけずにWhatsApp Business APIを実装できます。詳しくはこちら。
いいえ。 WhatsApp Business API Clientは、WhatsAppサーバーのポート5222または443へのアウトバウンドTCP接続を開きます。TCPトラフィックは、この長期接続を介して行われます。通常、ファイアウォールはこれを「アウトバウンドトラフィックと確立済みトラフィック」の許可として分類します。もちろん、いったん接続が確立すればパケットは双方向に送られますが、接続開始はWhatsAppビジネスAPI Client側から行われるため、インバウンド接続を許可するルールは必要ありません。
MySQLとPostgreSQLがサポートされています。Dockerを自分で実行している場合、コンテナが接続するMySQLまたはPostgreSQLデータベースを用意する必要があります。AWSテンプレートを使用すると、デフォルトではMySQLデータベースが設定されます。
要件は、データ通信量や状況に応じて異なります。このソリューションは、インターネットに接続されていてDockerが実行されているものであれば、どのようなマシンでも実行できます。たとえば、ノートパソコンで簡単なテストを実行できます。
シングルインスタンスの本番用サーバー設定では、少なくとも250 GB SSD、16 GB RAM、4コアのCPUをおすすめします。HDDは、負荷がかかった場合に入出力速度がボトルネックになるのでおすすめしません。
マルチコネクトの本番用サーバー設定では、Coreapp/Master/Webappそれぞれのコンテナに対して少なくとも50 GB SSD、4 GB RAM、2コアのCPUをおすすめします。
多くの場合、データベースは、コアコンテナやWebコンテナとは別の物理サーバーで実行する必要があります。データベースサーバーとコンピュートマシンの間の遅延は、数ミリ秒以内である必要があります。
この設定では、毎秒20件のメッセージ送信がサポートされます。
もちろんです。WhatsAppの担当者に連絡し、リクエストしてください。
現在、そのような方法はありません。WhatsAppからのユーザーの着信に応答できる状況ではない場合、正規のサポートチャネルへの連絡先を案内する自動応答メッセージを送信するように設定することをおすすめします。
通常の消費者向けのシナリオでは、送信者がユーザーのアドレス帳に入っておらず、この相手に以前にメッセージを送信したことがない場合、これが正常な動作です。企業向けのシナリオでは、ユーザーと初めてやり取りする際に、事業者はメッセージテンプレートを使用して「信頼」を確立します。こうすれば、WhatsApp Business APIクライアントでリンクがレンダリングされ、クリックできるようになります。
通常の消費者向けのシナリオでは、送信者がユーザーのアドレス帳に入っておらず、この相手に以前にメッセージを送信したことがない場合、これが正常な動作です。エンタープライズ向けのシナリオでは、ユーザーとの間に最初に「信頼」を確立するように依頼する際に、ビジネスはメッセージテンプレートを使用します。これを行うことで、WhatsApp Business APIクライアントはアプリ内の自動ダウンロード設定のとおりに動作します。
現時点では、何人のユーザーが、またどのユーザーが、ビジネスをブロックしたかを知る方法はありません。最良の指標としては、ステータスコールバックをリッスンし、deliveredステータスを受け取らない場合、そのユーザーはビジネスをブロックしているか、ネットワーク接続がないかのいずれかであることがわかります。詳細については、Webhookに関するドキュメントをご覧ください。
ユーザーがビジネスをブロックしている場合でも、Contacts APIは引き続きその電話番号を有効なWhatsAppユーザーとして返します。しかし、メッセージを送信しても、配信されることはありません。それが有料メッセージの場合、料金は発生しません。
はい、ライブ配信を開始する準備が整ったら、新しい電話番号を設定したり、認証済み名称を変更したりできます。
最大ファイルアップロードサイズは64MBです。この制限はメッセージで送信される画像、ドキュメント、ビデオにも適用されます。
いいえ。WhatsAppビジネス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>
Webapp Dockerコンテナ
docker restart webapp<Current_WABA_Version>
どのバージョンを実行しているのか確認するには、次のコマンドを実行します。
docker ps
もちろんです。デフォルトでは、WhatsAppビジネスAPIクライアントは、ポート5222経由でchatdを使用して通信を試みます。最高のエクスペリエンスを実現するには、すべてのアウトバウンドトラフィックに対してポート5222をオープンしてください。トラフィックはデータセンターからのみ送信されるため、セキュリティの問題は生じません。
ポート5222をオープンできない場合、WhatsAppビジネスAPIクライアントはポート443の使用を試みます。ファイアウォールまたはプロキシが接続を終了する問題が解決しない場合は、ダイレクトサポートを通じてデバッグに関する質問を送信し、WhatsAppチームと連絡を取ってください。
- 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
- An admin of the campaigns
- A full admin of the page
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.
- アプリから利用者へのゲームリクエストは/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でリクエストが生成されることはありません。