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