このページでは、効果的で魅力的な RCS ビジネス メッセージ エクスペリエンスを作成するためのベスト プラクティスについて説明します。技術的な実装と会話型デザインの両方について説明します。
技術に関するガイドライン
デバイスの機能を確認する
ユーザーとの会話を開始する前に、ユーザーのデバイスが RCS メッセージを受信できることを確認します。ユーザーの機能を特定するには、機能チェックを送信し、それに応じてエージェントのやり取りを調整します。デバイスがサポートしている方法でのみユーザーとやり取りします。ユーザーのデバイスで RCS が有効になっていない場合は、SMS などの別のチャネルで通信するフォールバック方法を設定します。
メッセージの最大サイズを尊重する
RBM メッセージとそれに含めることができるメディア ファイルの最大サイズには上限があります。詳細については、最大メッセージ サイズをご覧ください。
重複する着信メッセージを確認する
ユーザーからの受信メッセージを確認して返信する際は、messageId を確認し、メッセージをすでに受信して返信していないことを確認します。
分散システムでは、メッセージを送信する方法が 2 つあります。
- 最大 1 回: システムはメッセージを 1 回送信しますが、途中でネットワーク エラーや通信エラーが発生した場合、メッセージが受信されないことがあります。
- 1 回以上: システムがメッセージを複数回送信する可能性がありますが、ネットワーク エラーや通信エラーが発生した場合でもメッセージを受信できます。
Google Cloud Pub/Sub は at least once システムを使用します。これにより受信メッセージが重複する可能性がありますが、messageId 文字列をトラッキングすることで、メッセージを簡単に重複除去できます。すでにメッセージを受け取っている場合は、同じ messageId の追加メッセージは無視してかまいません。
すべての送信メッセージに一意の ID を使用する
エージェントがユーザーにメッセージを送信する場合、API 呼び出しに含める messageId はメッセージごとに一意である必要があります。
メッセージの受信について詳しくは、受信イベントを処理するをご覧ください。
指数バックオフで再試行を実装する
API を呼び出すときに、インフラストラクチャの問題、サービスの過負荷、QPS 上限などのエラーにより、呼び出しが失敗することがあります。API 呼び出しの失敗から正常に復元するには、指数バックオフを含む再試行を実装します。
指数バックオフで再試行を使用すると、インフラストラクチャで次の処理が自動的に行われます。
- 失敗した API 呼び出しを識別します。
- 最初の待機時間と最大再試行回数を設定します。
- 待機時間の間一時停止します。
- API 呼び出しを再試行します。
API 呼び出しのレスポンスを評価します。
- 成功した場合は、ワークフローの次のステップに進みます。
- 失敗した場合は、待機時間を増やしてステップ 3 に戻ります。
- 再試行の最大回数を超えた後に失敗した場合、失敗状態になります。
理想的な待機時間と再試行の最大回数は、ユースケースによって異なります。これらの数値は、インフラストラクチャとワークフローのレイテンシ要件に基づいて決定します。
リージョン エンドポイントで API のパフォーマンスを最適化する
レイテンシを改善するために API のパフォーマンスを最適化するには:
ユーザーのリージョンに最も近いエンドポイントを使用します。
次の表に、ユーザーの電話番号に応じて使用するリージョン RBM エンドポイントの推奨事項を示します。
電話番号のプレフィックス 推奨エンドポイント 地域 +1 us-rcsbusinessmessaging.googleapis.com 南北アメリカ +2 europe-rcsbusinessmessaging.googleapis.com ヨーロッパ +3 europe-rcsbusinessmessaging.googleapis.com ヨーロッパ +4 europe-rcsbusinessmessaging.googleapis.com ヨーロッパ +5 us-rcsbusinessmessaging.googleapis.com 南北アメリカ +6 asia-rcsbusinessmessaging.googleapis.com アジア +7 europe-rcsbusinessmessaging.googleapis.com ヨーロッパ +8 asia-rcsbusinessmessaging.googleapis.com アジア +9 asia-rcsbusinessmessaging.googleapis.com アジア デフォルト us-rcsbusinessmessaging.googleapis.com 南北アメリカ 選択したエンドポイントの近くにサーバーを配置することを検討してください。
Google のデータセンターについては、https://www.google.com/about/datacenters/locations/ をご覧ください。
エージェントのリージョンを特定する方法の詳細については、エージェントを作成するをご覧ください。
会話型 UI とユーザー エクスペリエンス
アプリの UI ではなく、会話型 UI
RBM エージェントは、会話型ユーザー インターフェースでユーザーに効率的かつ具体的なタスクを提供する場合に最適です。優れた設計のエージェントは、インタラクションを集中させ、理解しやすく、自然な会話のように構造化します。
エージェントはアプリやウェブページのビジュアル UI に依存することはできず、それを模倣しようとすべきではありません。代わりに、エージェントは、ユーザーのニーズに対応するよう丁寧に作成された会話に頼る必要があります。会話では、言葉による合図、提案、適切なエラー処理によってユーザーを導きます。
また、エージェントは、電話ツリーや、ユーザーが特定の操作を表す番号で応答するインターフェースを模倣してはなりません。ユーザーは、会話で他の人とやり取りするのと同じように、エージェントと自然にコミュニケーションできる必要があります。
会話を開始する
会話の開始時に、エージェントが何ができるかについてのユーザーの期待値が設定されます。会話は強い印象で始めましょう。エージェントの個性を示し、ユーザーが関心のある情報を最初に伝え、エージェントが何ができるかを共有します。エージェントとのやり取りや会話の継続について、ユーザーに明確な選択肢を提供します。
エージェントの個性を表現する: ユーザーに挨拶し、ブランドを紹介して、トーンを設定します。エージェントのペルソナ（バーチャル アシスタントやデジタル コンシェルジュなど）を作成する場合は、チャットボットであり、実在の人物ではないことを明確にしてください。エージェントの名前は、ペルソナに合わせて設定できます。アバターは、イメージを強化するのに最適な方法です。ロゴでも構いませんが、グラフィックの漫画風のキャラクターも効果的です。
エージェントが対応できることを伝える: 適切な挨拶メッセージは、会話で何ができるかを明確にします。エージェントの機能を大まかに説明します。また、ユーザーを特定のパスに誘導するための返信文の候補とアクションも含まれています。これらの提案を使用して、お客様が会話をスムーズに進め、エージェントがサポートできるタスクを理解できるようにします。
明確で一貫性のあるメッセージを作成する
ユーザーが理解しやすく、返信しやすいメッセージを送信します。ユーザーに返信を促すメッセージ テキストを作成します。一貫したスタイル、形式、ペースを維持して、ユーザーとの信頼関係を築きます。
メッセージ テキストを作成する際は、以下のベスト プラクティスも参考にしてください。
行き止まりを作らないでください。各メッセージは、意味のある次のステップにつながる必要があります。
- ユーザー ジャーニーに複数のステップを含むタスクがある場合は、談話標識を使用してユーザーをプロセスに沿って案内します。
たとえば、「Now…」、「And…」、「Got it!」などです。送信しています。
たとえば、「わかりました。ここからはアカウント マネージャーが対応いたします。」
たとえば、「完璧です。「お客様がお探しのものは、おそらくこちらです。」と伝え、ウェブサイトへのリンクを送信します。
お客様のメッセージを認識したことを示す単語やフレーズで返信します。
たとえば、「素晴らしい選択です！」、「OK」、「了解」、「承知いたしました」など。
名前（わかっている場合）または代名詞「you」を使用して、お客様に直接話しかけます。混乱を招く可能性があるため、ユーザーを「私」や「自分」と表現しないでください。
タイトルとラベルは、単語ごとに 1 文字目を大文字にするのではなく、文の最初の 1 文字を大文字にします。
たとえば、「Account statement」のように、大文字と小文字を区別します。
短縮形を使用します。これは、真剣なトーンや高揚したトーンのエージェントにも適しています。
たとえば、「it is」よりも「it's」の方が会話調です。
感嘆符は控えめに使う。
「A, B and C」ではなく、「A, B, and C」のように、文の区切りを明確にするための読点を使用します。
数字は数字で書き写します。
たとえば、「one、two、three」ではなく「1、2、3」とします。
絵文字を使用する場合は、その使用例にふさわしい遊び心のあるトーンであることを確認してください。
たとえば、レッカー車を予約したり、健康診断の結果を調べたりしているユーザーは、あまり気分が乗らないかもしれません。
メッセージの順序を維持する
複数のメッセージを順番に送信する場合は、ユーザーがそれらのメッセージを順番に受信することが重要です。メディアを含むメッセージは、テキストのみのメッセージよりも処理に時間がかかります。ユーザーがメッセージを正しい順序で受信できるようにするには、メッセージの 200 OK レスポンスを受信するまで待ってから、シーケンス内の次のメッセージを送信します。
返信文の候補や操作の候補を使用して、魅力的な会話を作成する
返信候補と操作候補は、ユーザーの会話をガイドし、強化するための強力なツールです。メッセージやリッチカードに続いて、会話のトピックを継続または変更するオプションを提供できます。
返信文の候補: 事前定義された選択肢を提供することで、ユーザーがエージェントにすばやく返信できるようにします。可能な限り、特に特定の回答が期待される場合は、返信文の候補を使用します。
候補のアクション: エージェントをデバイスの機能と統合し、サポートへの電話や場所の検索などのタスクを効率化できます。
より魅力的で効率的な会話を実現するには、次の重要な考慮事項に沿って対応してください。
- 関連性: 候補が現在の会話と一致していることを確認します。
- 簡潔さ: ユーザーに負担をかけないように、提案の数を制限します。
- 明確さ: 提案文には明確で簡潔な表現を使用します。
お客様をサポートする
エージェントは、ユーザーからの HELP メッセージに応答し、エージェントの機能についてユーザーに説明する必要があります。エージェントの能力に合わせて調整された返信候補のリストは、ユーザー エクスペリエンスを改善するのに役立ちます。
ロゴとヒーロー画像が適切に表示されるようにする
- ロゴの周囲に十分なスペースを確保し、切り抜きに対応して視覚的な完全性を維持します。
- ロゴやヒーロー画像を拡大縮小したり、歪ませたりしないでください。ブランドの認識に悪影響を及ぼす可能性があります。
- ロゴをテストする 最適な視認性と美しさを実現するため、ライトモードとダークモードの両方でロゴとメイン画像を確認します。
ロゴのデザインや問題のトラブルシューティングに役立つその他のリソースについては、ロゴのデザインに関するガイドラインをご覧ください。
ロゴ
- バランスと鮮明さを維持するため、円形の切り抜きを考慮してロゴをデザインします。
- ロゴを画像の中央に配置して、切り抜きに関する問題を回避します。
- 背景が透明なロゴの場合は、ダークモードに対応するため、明るい背景と暗い背景の両方に対して十分なコントラストがあることを確認してください。不明な場合は、白一色の背景を使用します。
ヒーロー画像
- アスペクト比 45:14 を使用して、不要な切り抜きを防ぎます。
ロゴの重なりを考慮してヒーロー画像をデザインし、重要な要素が隠れないようにします。
ユーザーがメッセージを望まない場合は尊重する
ユーザーの信頼を維持するには、ユーザーのコミュニケーション設定を尊重する必要があります。ユーザーがメッセージの受信を停止したいと表明した場合、エージェントはその選択を尊重する必要があります。これには、関連するすべての言語で「STOP」などのオプトアウトのさまざまな表現を理解し、適切に対応することが含まれます。
「STOP」などの命令コマンドへの応じ方については、事業を行っている国の法律および最良の慣行を参考にしてください。
たとえば、CTIA のベスト プラクティスを参照してください。
登録解除イベントと登録イベントを処理する
Google メッセージには、登録解除と登録の機能が組み込まれており、ユーザーは会話を管理できます。ユーザーが登録解除を選択すると、エージェントは UNSUBSCRIBE Webhook イベントを受け取ります。SUBSCRIBE イベントは、ユーザーがエージェントとのやり取りを再開する意向があることを示します。
ペイロードの詳細、ビジネスルール、例など、登録解除イベントと再登録イベントの処理について詳しくは、ユーザー生成イベントのドキュメントをご覧ください。
オプトアウトを処理する
RBM プラットフォームには、ユーザーのオプトアウト リストを直接管理する方法はありません。登録解除やその他のオプトアウト方法でメッセージの受信を停止したユーザーのデータベースを維持する責任は、お客様にあります。
会話を再開する
ユーザーがエージェントとの会話を削除した場合、ウェブサイトのオプトイン、SMS ショートコード、その他の同意メカニズムなどの別のチャネルを通じて連絡を再開する必要があります。この新しいインタラクションは、メッセージの受信に対する関心が再び高まったことを示します。