ビジネス メッセージ エージェント経由でユーザーとやり取りする場合は、次のベスト プラクティスに留意してください。
機密情報の提供や要求は行わない
チャット中に機密コンテンツを避けることで、貴社と顧客の情報を安全に保つことができます。機密情報には以下が含まれますが、これらに限定されません。
- クレジット カード番号
- 社会保障番号やパスポート番号など、政府発行の個人識別番号
- ログイン認証情報（パスワードなど）
ユーザーにすばやく返信する
ユーザー メッセージへの応答が遅い、または不合理な応答が返されると、顧客に不便が生じます。ユーザーのメッセージにタイムリーに応答するように、レスポンス インフラストラクチャを設計してください。
遅いレスポンスよりも悪いのは、レスポンスがまったくないということです。メッセージの読み込みに関係なく、ユーザーがメッセージに応答するようにしてください。たとえば、ライブスタッフが対応できない場合は、ユーザーに確認を求める自動メッセージを送信し、ユーザーが完全な応答を期待できると推定される時間を含めます。
Google はメッセージ間の応答時間（TTR）を測定します。ブランドのエージェントからの回答が遅い場合、Google はブランドのメッセージ ボタンを削除します。
自動化でリクエストを処理できない場合は、人間に引き渡す
自動化が正しく反応しないとユーザーは不満を抱きます。そのため、Google 管理のエントリ ポイントから起動するすべてのエージェント（Google 広告のエントリ ポイントを除く）には、自動化ができないときに会話を処理できる人間の代表者がいなければなりません。リリース前に、エージェント インタラクション タイプを設定して人間の担当者を含める必要があります。
自動化でユーザーのリクエストを 2 回続けて処理できない場合は、ライブ エージェント リクエストの提案を含むメッセージを送信することをおすすめします。
ユーザーがこの提案をタップすると、エージェントがライブ エージェントにリクエストされたイベントを受け取ります。エージェントは、人間の担当者に会話を引き継ぎ、ユーザーが必要なサポートを得られるようにする必要があります。
24 時間 365 日稼働している必要はありません。エージェントの可用性を設定して、人間が応答できる時間をユーザーに知らせます。
OAuth でユーザーを認証する
ユーザーの ID を検証し、パーソナライズされた情報をユーザーに提供するには、OAuth を介してバックエンド システムでユーザーを認証します。OAuth での認証により、エージェントはユーザーデータにすばやくアクセスでき、ユーザーやエージェントは機密情報（ユーザー名やパスワードなど）を会話に含めることを防止できます。OAuth で認証するをご覧ください。
ビジネス メッセージ内の CSAT の測定
ビジネス メッセージは、メッセージ エクスペリエンス内で直接アンケートを実施して顧客満足度（CSAT）を測定します。ユーザーが複数のアンケートを受信しないようにするには、ビジネス メッセージのアンケート機能を使用します。独自の CSAT 測定手法を実装しないでください。
トピックに沿っている
現在の会話に関係のない、または無関係なメッセージは送信しないでください。 次に例を示します。
- 元のリクエストとは無関係な商品やサービスに関するメッセージ
- ユーザーの返信がない繰り返しメッセージ
- 長すぎるメッセージ、または絵文字や URL の過度な使用
プレイス ID が利用可能な場合は活用する
位置情報ベースのエントリ ポイントの場合、メッセージのコンテキスト ペイロードに placeId が含まれることがあります。これを利用して、特定の場所の在庫など、ユーザーから質問を受ける可能性がある情報を提供できます。placeId は、Google プレイスのデータベースと Google Maps Platform で場所を一意に識別します。
位置情報ベースのエントリ ポイントのみでリリースする場合でも、placeId が存在しない場合の戦略を必ず実施してください。一般的ではありませんが、placeId がコンテキスト データの中で Webhook に渡されない場合があります。
指数バックオフを使用して再試行を実装する
API の呼び出し時に、インフラストラクチャの問題、サービスの過負荷、QPS の上限などのエラーが原因で、呼び出しが失敗する可能性があります。失敗した API 呼び出しから適切に回復するには、指数バックオフによる再試行を実装します。
指数バックオフと再試行を使用してインフラストラクチャを自動的にスケーリング
- 失敗した API 呼び出しを特定する
- 初期待機時間と再試行の最大数を設定する
- 待機期間を一時停止します
- API 呼び出しを再試行します
API 呼び出しのレスポンスを評価します。
- 成功の場合は、ワークフローの次のステップに進みます。
- 障害が発生した場合は、待機時間を増やしてステップ 3 に戻ります。
- 再試行の最大回数後に失敗すると、失敗状態になります
理想的な待機時間と理想的な再試行の最大回数は、ユースケースによって異なります。インフラストラクチャとワークフローのレイテンシ要件に基づいて、これらの数値を判断します。
重複した受信メールを確認する
ユーザーから届いたメッセージを確認して返信するときは、messageId をチェックして、まだメッセージを受け取っていないことを確認します。
分散システムでは、2 つの方法（少なくとも 1 回、少なくとも 1 回）でメッセージを送信できます。「最大 1 回」のシステムではメッセージが 1 回送信されますが、途中でネットワークまたは通信エラーが発生した場合は、メッセージを受信できない可能性があります。「少なくとも 1 回」システムでは、メッセージが複数回送信されますが、ネットワークや通信エラーが発生した場合でもメッセージを受信できます。
ビジネス メッセージでは「少なくとも 1 回」のシステムを使用します。これにより、受信メッセージの重複が発生する可能性がありますが、messageId 文字列を追跡してメッセージの重複を除去するのは簡単です。すでにメッセージを受信している場合は、同じ messageId で受け取った他のメッセージを無視しても問題ありません。