Messengerプラットフォーム

ハンドオーバープロトコル

Messengerプラットフォームハンドオーバープロトコルを使用すると、2つ以上のアプリがスレッドの制御を互いに受け渡しながら、1つのスレッドに参加できます。Facebookページがサブスクリプション登録しているアプリでは、ハンドオーバープロトコルが自動的に有効になります。

注:スレッドルーティングが利用可能になっており、間もなくハンドオーバープロトコルを置き換える予定です。スレッドルーティングを使用するため、できるだけ早くアプリをアップデートしてください。

処理の概要

FacebookページまたはInstagramプロアカウントは、複数のメッセージアプリを使用して顧客やコンテンツに興味・関心がある人とやり取りすることができます。例えば、カスタマーサポートでは、顧客を自動化エクスペリエンスに送ることができますが、自動化エクスペリエンスが顧客の問題を解決できない場合、顧客をライブサポートエージェントによって別のアプリに送ることができます。スレッドやスレッドのメタデータをあるアプリから別のアプリに転送したり、Facebookページの受信箱やInstagramの受信箱の間で転送したりするために、スレッドの管理をアプリ間で移行する必要があります。ハンドオーバープロトコルにより、この転送が可能になります。

デフォルトでは、顧客がメッセージを送信してスレッドを開始すると、スレッドは待機中になります。アプリは、メッセージが受信され、返信を待っているという通知をWebhooks経由で受け取ります。この通知を受信するには、アプリでハンドオーバーの特定のWebhooksをサブスクリプション登録する必要があります。

スレッドが待機中であれば、どのアプリでもスレッドを管理することができます。スレッドを管理しているアプリだけが、メッセージに応答することができます。一度に管理できるアプリは1つのみで、管理アプリが管理をリリースするまで、他のアプリはメッセージを送信できません。アプリが管理をリリースすると、スレッドは待機中に戻り、次のアプリが管理権を得ることができます。

スレッドを管理しているアプリは、メッセージングWebhooksから通知を受け取ります。他のすべてのアプリはハンドオーバーの特定のWebhooksから通知を受け取ります。

24時間アクティビティがない場合、スレッドは自動的に待機中に戻ります。管理アプリは、必要に応じて24時間を超えて管理することができます。

スレッドを管理していないアプリが、特定の人にメッセージを送信しようとすると、エラーサブコード2018300付きの400エラーが返されます。

プライマリレシーバー

受信時に特定のアプリでメッセージを処理する場合は、そのアプリをプライマリレシーバーとして割り当てることができます。メインレシーバーは、スレッドのすべての新しいメッセージを受け取り、別のアプリまたはFacebookページの受信箱やInstagramの受信箱に管理を移行し、必要に応じて別のアプリのスレッドを管理することができます。プライマリレシーバーでないアプリがスレッドを終了して、管理をリリースすると、スレッドは待機中に設定されます。

スレッドが待機中で、ある人があなたのページやアカウントに新しいメッセージを送信した場合、プライマリレシーバーがスレッドを管理し、新しいメッセージに関するWebhooks通知を受け取ります。

注: プライマリレシーバーの設定は不要です。

受信箱

Facebookページの受信箱やInstagramの受信箱をプライマリレシーバーとして割り当てることはできません。ただし、メッセージをメインフォルダに移動したり、受信箱で管理されていないスレッドのメッセージに返信したりした場合、受信箱がスレッドを管理します。受信箱の完了と記載されたメッセージに返信した場合、管理は前の管理アプリやプライマリレシーバーにとどまる(設定されている場合)か、リリースされて待機中になります。

スレッドのエントリーポイント

Messenger誘導広告(CTM)のスレッドエントリーポイントを使用すると、特定のアプリにスレッドを割り当てることができます。ビジネスはCTMを使って顧客とのスレッドを開始しリードを獲得したり、ブランドの認知度をアップしたりすることができます。

固定メニュー

プライマリレシーバーが設定されていない限り、どのアプリでもページレベルのメニューを設定できます。プライマリのアプリが設定されている場合、ページレベルのメニューを設定または削除できるのはプライマリのアプリのみです。

スレッドを管理するアプリは、アプリがプライマリレシーバーでなくてもユーザーレベルのメニューを設定または削除することができます。スレッドが待機中の場合はどのアプリでもユーザーレベルのメインメニューを設定できます。

顧客がメニューからアイテムを選択すると、メニューを作成したアプリがスレッドを管理します。メニューを作成したアプリがそのデータを処理するように設定されているためです。

ポストバックコールトゥアクション

顧客がポストバックコールトゥアクション(CTA)をクリックすると、ポストバックCTAを作成したアプリは他のアプリが管理していてもそのスレッドを管理します。ポストバックCTAを作成したアプリがそのデータを処理するように設定されているためです。

顧客アンケート

他のアプリがスレッドを管理しているときにアンケートが送信された場合、そのアンケートはアプリが管理をリリースしスレッドが待機中になるまでは配信されません。

コンポーネント

サブスクリプション登録しているメッセージアプリのハンドオーバープロトコルをFacebookページが正常に実装するには、以下の要素が必要です。

アクセストークン

ハンドオーバープロトコルエンドポイント向けの通話には、ページでMODERATEタスクを実行できる人がリクエストしたページアクセストークンが必要です。

アプリレビュー

次のアプリにはアプリレビューが必要です。

  • アプリで役割のない人にも使用される
  • ヒューマンエージェントが顧客に応答できるようにする

ヒューマンエージェント機能

承認された場合、アプリはスレッドを管理していなくてもアプリレビュー中にヒューマンエージェント機能を使ってメッセージを送信できるようになります。そのメッセージには、ヒューマンエージェントのタグが付けられます。これは、スレッドを管理していないアプリからメッセージを送信できる唯一のシナリオです。

アクセス許可

アプリが顧客にメッセージングデータへのアクセスを許可するよう求めるには、pages_messagingのアクセス許可が必要です。

Webhooks

ハンドオーバープロトコルには、アプリがサブスクリプション登録するWebhooksとして、メッセージングWebhooksとスタンバイWebhooksの2セットがあります。アプリが受け取る通知はスレッド管理に依存します。アプリでスレッドを管理している場合、アプリはメッセージングWebhooksの通知を受け取ります。アプリでスレッドを管理していない場合、アプリはスタンバイWebhooksの通知を受け取ります。

一般的な用途

カスタマーサポート

ビジネスは、よくある質問に対して自動化されたアプリを使用しますが、自動化されたアプリで顧客の問題を解決できない場合は、顧客を別のアプリに移行します。自動アプリはプライマリレシーバーに設定されているため、すべてのスレッドは自動アプリが所有します。ライブサポートエージェントがスレッドに参加する必要がある場合、ライブサポートアプリでスレッド管理をリクエストすることができます。ライブエージェントアプリがスレッドを完了すると、スレッド管理は自動アプリに戻されます。ライブエージェントアプリが顧客の問題に対処するためにさらに時間を必要とする場合、アプリで延長をリクエストすることができます。どちらのアプリも、スレッドが正しく動作するようにWebhooksをサブスクリプション登録する必要があります。

マーケティングキャンペーン - 製品リード

ビジネスはマーケティングキャンペーンを実施し、自動化エクスペリエンスを利用して、製品クイズに基づいてリードを選別したりおすすめ商品を提供したりします。リードの選別後、ビジネスはFacebookページの受信箱やInstagramの受信箱を使って見込み顧客をフォローアップします。自動アプリはプライマリレシーバーに設定されているため、すべてのスレッドは自動アプリが所有します。自動アプリがリード選別フェーズを完了すると、スレッド管理はFacebookページの受信箱やInstagramの受信箱に渡されます。Facebookページの受信箱やInstagramの受信箱のスレッドが完了したら、スレッドを完了にしてください。そうすると、プライマリのアプリに対してスレッド管理がリリースされます。どちらのアプリも、スレッドが正しく動作するようにWebhooksをサブスクリプション登録する必要があります。

マーケティングキャンペーン - Messenger誘導広告

ビジネスはマーケティングキャンペーンを実施し、特定のMessengerエクスペリエンスのために自動アプリに見込み顧客を誘導します。自動アプリはプライマリレシーバーに設定されているため、すべてのスレッドは自動アプリが所有します。ライブサポートエージェントがスレッドに参加する必要がある場合、ライブサポートアプリでスレッド管理をリクエストすることができます。ライブエージェントアプリがスレッドを完了すると、スレッド管理は自動アプリに戻されます。ライブエージェントアプリが顧客の問題に対処するためにさらに時間を必要とする場合、アプリで延長をリクエストすることができます。どちらのアプリも、スレッドが正しく動作するようにWebhooksをサブスクリプション登録する必要があります。

ベストプラクティス

  1. プライマリレシーバーアプリとして自動化エクスペリエンスを設定し、ライブエージェントアプリを非プライマリアプリとすることをおすすめします。ライブエージェントアプリがスタンバイイベントをリッスンするようにし、必要でない限りアクションを起こさないようにすることをおすすめします。
  2. 必ずGet Thread Control APIを使用して、スレッドを管理しているかどうかを確認してから、シナリオに基づいて他のAPIを呼び出すようにします。管理していない場合は邪魔したり中断させたりしないでください。
  3. 他のアプリがスレッドを管理しているときは、スレッドにメッセージを送信しないようにしてください。プライマリのアプリでは、必要な場合にのみスレッド管理APIを使用してください。緊急でない場合やプライマリのアプリでない場合は、スレッド管理をリクエストしてください。
  4. 可能なら、他のアプリからのリクエストスレッド管理イベントを承認し、リクエストアプリにスレッド管理を渡すようにしてください。何らかの理由でスレッド管理をすぐに渡せない場合は、Pass Metadata APIを使用してリクエストアプリに追加のコンテキストを送信し、完了後にスレッド管理を渡せるようにキューに入れたままにします。
  5. スレッドが完了したら、まだキューに入っている以前にリクエストしていたアプリにスレッド管理を渡すか、スレッド管理をリリースして待機中にし、他のアプリがスレッドを取得できるようにしてください。そうしない場合、スレッドは自動的にアプリからリリースされ、24時間後に待機中モードになります。このシナリオをコーディングすると、状況に応じてステータスが変わります。
  6. Get Thread Control APIを呼び出してスレッドが待機中になっていることに気づいた場合は、スレッド管理のリクエストを使用してスレッドを管理してください。中断することなくユーザーにメッセージを送信し、完了後にスレッドをリリースできます。

詳しくはこちら

ハンドオーバープロトコルの構成要素について詳しくはこちら。

次のステップ

ハンドオーバープロトコルの仕組みがわかりました。このプロトコルを実装するには以下が必要です。