Business Messages エージェントを通じてユーザーとやり取りする際は、次のベスト プラクティスに留意してください。
機密情報を提供またはリクエストしないでください
チャット中に機密情報を取り上げないようにすることで、エージェントとお客様の情報を安全に保つことができます。機密情報には以下のものが含まれますが、これらに限定されません。
- クレジット カード番号
- 社会保障番号やパスポート番号など、政府発行の個人識別番号
- ログイン認証情報（パスワードなど）
ユーザーに迅速に対応する
ユーザーのメッセージへの返信が遅い、または不当に長い場合、顧客の利便性が損なわれます。ユーザー メッセージに確実にタイムリーに返信できるように、レスポンス インフラストラクチャを設計してください。
応答が遅いことよりも、まったく応答しないことがさらに悪い状況です。メッセージの負荷に関係なく、ユーザーが常にメッセージに返信を受け取るようにしてください。たとえば、リアルタイムのスタッフが対応できない場合は、ユーザーの存在を認識する自動メッセージを送信し、ユーザーが完全な回答を期待できるタイミングの見積もりを記載します。
Google は、メッセージ間の応答時間（TTR）を測定します。ブランドのエージェントが消費者に迅速に対応していない場合、Google はブランドのメッセージ ボタンを削除します。
自動化でリクエストを処理できない場合は、人間に引き継ぐ
自動化が適切に応答しないと、ユーザーは不満を抱きます。そのため、Google が管理するエントリ ポイントから開始するすべてのエージェント（Google 広告のエントリ ポイントを除く）には、自動化が対応できない場合に会話を処理できる人間の担当者が必要です。リリース前に、エージェントとのやり取りの種類を設定して、人間の担当者を含める必要があります。
自動化でユーザーのリクエストを 2 回連続で処理できない場合は、リアルタイム エージェント リクエストの候補を含むメッセージを送信することをおすすめします。
ユーザーがこの候補をタップすると、エージェントはリアルタイム エージェント リクエスト イベントを受け取ります。エージェントは、ユーザーが必要なサポートを受けられるように、会話を人間の担当者に引き継ぐ必要があります。
人間が 24 時間 365 日対応する必要はありません。エージェントの対応可能時間を設定して、ユーザーが人間による対応をいつ期待できるかを知らせます。
OAuth でユーザーを認証する
ユーザーの ID を確認してパーソナライズされた情報を提供するには、OAuth を介してバックエンド システムでユーザーを認証します。OAuth による認証を使用すると、エージェントはユーザーデータに迅速にアクセスできます。また、ユーザーやエージェントが会話に機密情報（ユーザー名やパスワードなど）を含めることを防ぐことができます。OAuth で認証するをご覧ください。
ビジネス メッセージ内で CSAT を測定する
ビジネス メッセージでは、メッセージ エクスペリエンス内で直接アンケートを使用して顧客満足度スコア（CSAT）を測定します。ユーザーが複数のアンケートを受信しないようにするには、Business Messaging のアンケート機能を使用します。独自の CSAT 測定手法を実装しないでください。
トピックを変更しない
不要なメッセージや、現在の会話に無関係なメッセージを送信しないでください。次に例を示します。
- 顧客からの当初のリクエストとは無関係な商品やサービスに関するメッセージ
- ユーザーからの応答がないのに繰り返しメッセージを送信する
- 長すぎるメッセージや、絵文字や URL が多すぎるメッセージ
利用可能な場合は Place 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 で受信した追加のメッセージは無視してかまいません。