はじめに
2018年5月11日、Messenger APIがアップデートされました。
簡単ではありますがまとめていきたいと思います。
Messenger APIの変更履歴はMessenger APIのChangeLogから確認が可能です。
Customer Chat Plugin関係のアップデート
Customer Chat Plugin概要
Messenger APIがupdateされる度に地味にupdateされつづけている Customer Chat Plugin。
簡単にいうと、webにmessengerのスレッドを埋め込むことができるAPIです。
こんな感じ。
変更内容1
Customer Chat Plugin SDKの機能拡張が行われました。
特定のイベントに対してChat Customer Pluginの表示/非表示ができる模様です。(動作未確認)
FB.CustomerChat.hide();
これがあれば、Web UI上で特定のボタンがクリックされたタイミングでスレッドを表示することが可能..?
変更内容2
sender actions, user data quick replies, and enables users to send attachments.
へのサポートが増えたとのこと。
ひとつひとつ見ていくと、
sender actionsは、Messengerで相手が入力中のときに表示されるにょろにょろを指します。
user data quick repliesはスレッドへ流入したユーザーから電話番号/メールアドレスを取得するためのquick_replyのことを指している模様です。
attachmentsは、画像/動画/音声ファイル/ファイルのことを指します。
Broadcast APIの拡張
Broadcast API概要
Broadcast APIとは、スレッドを開始した複数人のユーザーに対してメッセージを送信するAPIです。
ざっくりした流れは、
1. 送信するメッセージをmessenger api上に登録
2. ユーザーに対してlabelを付与
3. 1. 2. で設定したメッセージのIDとlabelのidを指定し、送信する。
というものになります。大量のユーザーを抱えているFacebookページではユーザーに対して一斉にメッセージを送信する際のサーバーへの負荷等を考慮しなくてよいのがメリットです。
一方で１人1人に対して個別でメッセージを送信するのはユーザーのPSIDを指定する方がAPIを叩く回数が増えてしまう分あまり向いていないかも知れません。
変更内容
ユーザーに対してlabelを付与する際の機能拡張が行われました。
Label Predicates という機能らしいですが、英語からだと正直良くわかりません。
が、実際のAPIを見ればどんなものか分かります。
curl -X POST -H "Content-Type: application/json" -d '{
"message_creative_id": <MESSAGE_CREATIVE_ID>,
"targeting": {
"labels": {
"operator": "<OR|NOT|AND>",
"values": [
{
"operator": "<OR|NOT|AND>",
"values": [
<CUSTOM_LABEL_ID>,
<CUSTOM_LABEL_ID>,
...
]
},
{
"operator": "<OR|NOT|AND>",
"values": [
<CUSTOM_LABEL_ID>,
<CUSTOM_LABEL_ID>,
...
]
},
...
]
}
}
}' "https://graph.facebook.com/v2.11/me/broadcast_messages?access_token=xxx"
要は、ユーザーに対して付与してきたlabelに対してOR/NOT/ANDを指定することができるというものです。
つまり、、
40歳以下、というラベルと東京在住というラベルをANDで指定し、30歳以下、というラベルをNOTで指定すると30歳~40歳の東京在住ラベルのできあがりです。
Send to Messenger pluginの拡張
Send to Messenger plugin概要
Send to Messenger pluginは、web上からfacebookページのMessengerを起動するためのAPIです。
変更内容
これまで、Send to Messenger というテキストしか選択できなかったものが、
GET_THIS_IN_MESSENGER
RECEIVE_THIS_IN_MESSENGER
SEND_THIS_TO_ME
GET_CUSTOMER_ASSISTANCE
GET_CUSTOMER_SERVICE
GET_SUPPORT
LET_US_CHAT
SEND_ME_MESSAGES
ALERT_ME_IN_MESSENGER
SEND_ME_UPDATES
MESSAGE_ME
LET_ME_KNOW
KEEP_ME_UPDATED
TELL_ME_MORE
SUBSCRIBE_IN_MESSENGER
SUBSCRIBE_TO_UPDATES
GET_MESSAGES
SUBSCRIBE
GET_STARTED_IN_MESSENGER
LEARN_MORE_IN_MESSENGER
GET_STARTED
SEND_TO_MESSENGER
こんな感じのテキストに変更が可能になる模様です。まぁ確かに便利そう。
Handover protocolの拡張
Handover protocolの概要
記事執筆現在、change logに何点かリンクの張り間違いがありますが、
Handover protocolとは、ユーザーが送信したメッセージを複数のappからをフォローし、それぞれprimary, Secondary としてwebhookを受け取ることができる機能です。
ドキュメント上でのユースケースを参考にすると、botが自動応答する際のappをprimaryとして設定し、live agentsのような有人対応が必要なタイミングで Secondaryへスレッドの制御する権限を切り替える、というものになります。
Secondaryへスレッド制御が渡されると、制御しているappが変更された旨を通知するようなwebhookが飛んだり、これまでスレッドを制御していたappへのwebhookの形式が変わったり、細かなイベント単位でwebhookを受け取れるようになるみたいです。
このユースケースだとユーザーが特定の発話を通過したタイミングでDB上なりで自動応答するかどうかのフラグを立ててしまえば完結する気もしますが..。
変更内容
Change Logのリンクが404を吐いていましたが、おそらくこのget thread ownerのAPIを指しています。
このAPIでは、特定のユーザーに対してどのappがowner(=スレッドを制御)しているappのidを取得することができます。今まで無かったのがやや驚きです。
Page Insight API
Page Insight APIの概要
Page Insight APIは、この画面で可視化されているデータを取得することができるAPIです。
開始地点と終了地点の日時、取得したいデータ(metric)を指定すると、その間のデータを取得することができます。
変更内容
page_messages_total_messaging_connectionsというパラメータが取得できるようになったそうです。
さいごに
あくまで私の個人の意見ですが、Customer Chat Plugin, Handover Protocolは他のAPIと比較すると頻繁にアップデートが繰り返されているので、MessengerのWeb拡張や有人対応でのユーザー対応のスキームを前面に押し出したいのかもしれません。
本国の記事を見ていていも、非エンジニア向けにCustomer Chat Pluginの導入方法を紹介しているものが何個か見受けられたので、よりマスな層を取りにいってるのだと思います。
それはある意味Messenger Botのユースケースが確立し、キャズムを超えてきていることの証明なのかもしれませんね。
Messenger APIはちょくちょくアップデートされているので、定期的に更新していきたいと思います。
是非皆さんもMessenger API触ってみてください！できることはとっっっっっっっても多いので面白いですよー！
マサカリお待ちしております！