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