View a markdown version of this page

RCS のベストプラクティス - AWS エンドユーザーメッセージング SMS
対話型およびインタラクティブな設計提案戦略リッチカードとカルーセルの設計メディアのベストプラクティスTTL とフォールバック戦略および イベントのモニタリングデバイスとクライアントのレンダリングの変動オプトアウト処理

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

RCS のベストプラクティス

RCS リッチメッセージングを使用すると、従来の SMS を超える会話型のインタラクティブなエクスペリエンスを作成できます。このトピックでは、提案戦略、リッチカードとカルーセルのレイアウト、メディアの最適化、メッセージの有効期限、フォールバック計画、モニタリングなど、効果的な RCS メッセージの設計に関するガイダンスを提供します。

個々の機能の詳細については、RCS の提案の設定、、RCS リッチカードの送信、RCS カルーセルの送信、RCS メッセージの有効期限の設定、メッセージごとの SMS または MMS フォールバックの設定および を参照してくださいRCS メッセージイベント。

対話型およびインタラクティブな設計

RCS メッセージは、推奨される返信、推奨されるアクション、リッチカード、カルーセルなどのインタラクティブな要素をサポートします。これらの機能を効果的に使用するには、各メッセージ交換を一方向の通知ではなく、進行中の会話の一部として扱います。

コンテキストとオプションで開く

明確な挨拶を含め、ユーザーができることを述べ、次のステップを導くために推奨される返信を提供します。これにより、期待値が設定され、摩擦が軽減されます。

メッセージを簡潔に保つ

テキストメッセージあたり 300 文字未満を目指します。複雑な情報を複数のメッセージに分割するか、構造化コンテンツにリッチカードを使用します。

デッドエンドを避ける

すべてのメッセージは次のステップにつながるはずです。フォローアップの提案、メインメニューオプション、またはヒューマンエージェントへのパスを提供します。

ユーザーに直接対処する

2 人目を使用します。「予約が確認されました」ではなく「予約が確認されました」と入力します。

提案戦略

提案 (返信とアクションの両方) は、メッセージの下にインタラクティブチップとして表示されます。入力を減らし、エンゲージメントを高め、構造化されたPostbackData値を通じてレスポンスをルーティングできます。提案タイプの詳細なリストについては、「」を参照してくださいRCS の提案の設定。

簡潔なアクションラベルを書き込む

Text フィールドには 25 文字の制限があります。タップ時に何が起こるかを正確にユーザーに伝えるアクション指向の言語を使用します。

提案ラベルの例
回避 優先
「オプション 1」 「月曜日の予約」
「ここをクリック」 「注文ステータスの表示」
「詳細情報」 「料金の詳細を表示」

オファー 3～5 のオプション

3 つの提案は、ほとんどのインタラクションに最適です。メッセージごとに最大 11 個の提案を含めることができますが (リッチカードごとに 4 個）、一度に 5 つ以上のオプションを含めると、ユーザーを圧倒する傾向があります。さらに選択肢が必要な場合は、カルーセルを使用するか、フローを複数のステップに分割します。

PostbackData でのルート

表示テキストを解析する代わりに、バックエンドルーティングロジックPostbackDataに を使用します。このアプローチはローカリゼーションをサポートし (ルーティングを変更Textせずにユーザー表示を変更できます）、アプリケーションの構造化コンテキストを提供します。

ポストバック値にアクション、エンティティ、コンテキストをエンコードします。例えば、次のようになります。

confirm_order_12345
cancel_appointment_20260615
nav_main_menu

バックエンドでのルーティングを簡素化するには、一貫したプレフィックス (book_、confirm_、cancel_、 などnav_) を使用します。

重要

古いポストバックを適切に処理します。ユーザーは、受信してから提案時間を選択できます。参照されたエンティティがまだ存在することを確認し、アクションが無効になった場合はユーザーに通知します。

リッチカードとカルーセルの設計

リッチカードとカルーセルは、構造化コンテンツ (イメージ、タイトル、説明、提案) をビジュアル形式で表示します。実装の詳細については、RCS リッチカードの送信「」および「」を参照してくださいRCS カルーセルの送信。

スタンドアロンのリッチカード

  • デバイス間で最も一貫したレンダリングを行うには、VERTICAL方向を使用します。

  • TALL メディアの高さを使用して、Android と iOS の両方で十分な表示領域をイメージに付与します。

  • タイトルと説明のテキストは簡潔にしておきます。一部のクライアントは 3 行を超えるテキストをトリミングします。

  • 説明テキストの URLsすべてのクライアントでリンクとして機能するわけではありません。説明にリンクを埋め込む代わりに、OpenUrl推奨されるアクションを使用します。

  • カードごとに 1 つの明確なcall-to-actionの提案を含めます。複数の競合アクションにより、変換レートが低下します。

カルーセル

  • 推奨されるオプションまたは最も関連性の高いオプションを最初のカードの位置に配置します。ユーザーは、最初に表示されるカードとほとんどやり取りします。

  • 「メニューに戻る」や「ヘルプ」などのナビゲーションアクションには、外部 (メッセージレベル) の提案を使用します。そのカードに固有のアクションについて、カードレベルの提案を予約します。

  • カルーセルカードは垂直方向のスペースが少ないため、カードの内容はスタンドアロンカードよりも簡潔に保ちます。

  • カルーセルカードメディアの高さは SHORTまたは に制限されています MEDIUM (TALLカルーセルではサポートされていません）。

  • すべてのカードの合計メディアが 100 MB 未満のままであることを確認します。アップロードする前にイメージを最適化します。

メディアのベストプラクティス

メディアファイル (画像、動画、PDFsメッセージエンゲージメントを強化しますが、ペイロードサイズとレンダリングの変動性を追加します。ファイル形式とサイズの要件については、「」を参照してくださいリッチ RCS メッセージを送信する。

  • アップロードする前にイメージを圧縮します。JPEG は写真に、PNG はグラフィックに透明に使用します。

  • キャリアとデバイス間で信頼性の高い配信を実現するために、動画ファイルを 5 MB 未満に保ちます。

  • ビデオメッセージとラージファイルメッセージThumbnailUrlには を指定します。完全なメディアロード中にサムネイルが表示され、低速接続でのユーザーエクスペリエンスが向上します。

  • GIF アニメーションは Android で再生されますが、iOS では静的な最初のフレームとして表示されます。重要な情報を伝えるために GIF アニメーションに依存しないでください。

  • HTTPS URLs または Amazon S3 (URI s3:// を使用) でメディアをホストします。 URIs すべてのメディア URLsパターン と一致する必要があります^(https://|s3://).+$。

TTL とフォールバック戦略

Time to Live (TTL) とフォールバック設定は連携して、RCS 配信が失敗した場合でもメッセージがユーザーに到達するようにします。実装の詳細については、RCS メッセージの有効期限の設定「」および「」を参照してくださいメッセージごとの SMS または MMS フォールバックの設定。

TTL 値の設定

時間的制約のあるコンテンツには、常にTimeToLive値を設定します。TTL をコンテンツ関連性ウィンドウに一致させます。

コンテンツタイプ別の推奨 TTL 値
コンテンツタイプ 推奨 TTL
ワンタイムパスワード (OTP) または検証コード 30～120 秒
フラッシュ販売通知 販売が終了するまでの期間
予約のリマインダー 予約までの時間
配信の更新 1～4 時間
注記

API の最小値は 1 秒ですが、十分な配信時間を確保するために 10 秒以上の TTL が推奨されます。最大は 172,800 秒 (48 時間) です。

SMS または MMS フォールバック

RCS 配信が失敗または期限切れになった場合にコンテンツがユーザーに到達するように、重要なメッセージ (OTPs、注文確認、セキュリティアラート) FallbackConfigurationの を設定します。

  • フォールバックでメディアが必要かどうかMMSに応じて、 Channelフィールドを SMSまたは に設定します。

  • を 1,600 文字MessageBody以内 (フォールバック制限。3,072 文字の RCS テキスト制限より短い) に保ちます。

  • RCS をサポートしていない電話番号に送信し、SMS または MMS メッセージが到着することを確認することで、フォールバック配信をend-to-endでテストします。

および イベントのモニタリング

イベント送信先と配信イベントを使用して、メッセージのパフォーマンスをモニタリングし、メッセージング戦略を最適化します。イベントタイプと設定の詳細については、「」を参照してくださいRCS メッセージイベント。

  • 本番送信を開始する前に、イベント送信先を設定します。これにより、配信、読み取り、有効期限のイベントを最初からキャプチャできます。

  • メッセージの有効期限をモニタリングして、TTL 値が適切かどうかを判断します。有効期限レートが高い場合は、TTL が短すぎるか、多くの受信者に RCS 対応デバイスがないことを示します。

  • 絶対メトリクスとしてではなく、相対比較 (A/B テスト) の読み取り受信を追跡します。すべてのクライアントが読み取りステータスを報告するわけではありません。

  • 外部でフォールバックを管理する場合は、配信確認イベントを使用して、アプリケーションロジックの冗長なフォールバックタイマーをキャンセルします。

デバイスとクライアントのレンダリングの変動

RCS メッセージのレンダリングは、Android クライアントと iOS クライアントで異なります。キャンペーンを開始する前に、最小の共通分母を設計し、両方のプラットフォームでテストします。

Android と iOS のレンダリングの違い
機能 Android iOS
GIF イメージ アニメーション 静的 (最初のフレームのみ)
テキストでプレビューをリンクする メッセージ内の任意の URL URL は最後の要素である必要があります。URL の後に追加のテキストが続くと、クリックできない場合があります。
カードメディアの高さ ショート、ミディアム、トールを尊重 すべての垂直方向の高さを同一にレンダリングします。height プロパティを無視する場合があります。
提案チップの順序 送信済みとして保存 チップの順序を変更する可能性がある
推奨されるアクションの永続性 カード外のアクションは、タップすると消えます。カードボタンは保持されます。 すべてのボタン (カードと非カード) は、タップ後も保持されます。
パス文字を含む表示名 (/、\、:) 登録済みとしてレンダリング 文字は iOS レンダリングレイヤーで削除できます
エージェントバナーイメージ エージェントプロファイルに表示される 表示されない
プライバシーポリシーリンク エージェントプロファイルに表示される 表示されない
タイプごとに複数の連絡先 すべての問い合わせエントリが表示されます 表示されるタイプごとの最初の問い合わせのみ (リスト順)
アクセシビリティテキストサイズが大きいメディア 安定したレンダリング 大きなテキストサイズが有効になっている場合にイメージをトリミングすることがある
キャリア検証バッジ 「Verified by [Carrier]」または「Verified by Google」 同じバッジ値。Apple によって制御されるレンダリング。

これらの違いに基づいて推奨事項を設計します。

  • 一貫したレイアウトにはVERTICALカードの向きを使用します。

  • テキストメッセージの最後に URLs を配置して、リンクプレビューが iOS でレンダリングされるようにします。

  • 重要な情報を伝えるために GIF アニメーションに依存しないでください。

  • シーケンスがユーザーフローにとって意味のある場合は、両方のプラットフォームで提案の順序をテストします。

iOS での表示名レンダリング

Apple の iOS Messages アプリは、表示されたエージェント名からオペレーティングシステムのパス区切り文字 (/、\、:) または URL エスケープシーケンスに似た文字を削除する場合があります。この動作は OS レベルで制御され、AWS、Google、キャリア、メッセージングパートナーによって上書きすることはできません。

表示名の不一致を回避するには:

  • 表示名には、英数字、スペース、ハイフン、ピリオド、および標準句読点 (&、'、 など!) のみを使用してください。

  • スラッシュ、バックスラッシュ、コロンをブランド名の一部として使用しないでください。

  • ブランド名にこれらの文字が含まれている場合は、代替表現を検討してください (スラッシュの代わりにハイフンやスペースを使用するなど）。

  • キャリアの起動をリクエストする前に、テストフェーズで iOS テストデバイス上のエージェントの外観を必ず確認してください。これは、エージェントのテストの主な目的の 1 つです。

影響を受ける表示名を持つエージェントをすでに起動していて、変更する必要がある場合は、AWS サポートにお問い合わせください。起動したエージェントの表示名の変更には、キャリアの再承認が必要です。

iOS でのエージェントプロファイルの可視性

Android に表示される一部のエージェントプロファイル要素は、iOS では表示されません。

  • バナーイメージ: iOS では表示されません。バナーに頼って重要なブランド情報を伝達しないでください。

  • プライバシーポリシーリンク: iOS エージェントプロファイルビューに表示されません。プライバシーポリシーが他の方法 (ウェブサイトやウェルカムメッセージの推奨アクションなど) でアクセス可能であることを確認します。

  • 複数の連絡先: 複数の電話番号、E メール、またはウェブサイトを設定すると、iOS は連絡先タイプごとに最初のエントリのみを表示します。エージェントを設定するときに、プライマリ連絡先をリストの最初に配置します。

プラットフォーム間のテスト

RCS レンダリングは、受信者のオペレーティングシステムのバージョン、デバイスモデル、キャリア設定によって異なります。キャリアの起動をリクエストする前に:

  • Android デバイスと iOS デバイスの両方にテストメッセージを送信します。

  • 両方のプラットフォームで、表示名、ロゴ、バナー、説明、推奨アクション、リッチカード、メディアを確認します。

  • iOS でさまざまなテキストサイズとアクセシビリティ設定を使用してテストします。

  • リンクプレビューが両方のプラットフォームで正しくレンダリングされることを確認します。

Apple の RCS 実装はまだ進化しています。iOS の更新に伴って動作が変わる場合があります。iOS リリース後にメッセージングエクスペリエンスをモニタリングし、それに応じてコンテンツを調整します。

オプトアウト処理

すべてのメッセージングチャネルで、ユーザーのオプトアウト設定を迅速かつ一貫して尊重します。

  • オプトアウトリクエストの直後にすべての重要でないメッセージを停止することで、STOP キーワードと UNSUBSCRIBE キーワードを尊重します。

  • サブスクライブを解除した送信者をユーザーが認識できるように、ブランド名を含む簡単なオプトアウト確認を送信します。

  • 独自のオプトアウトデータベースを維持し、チャネル (RCS、SMS、MMS) 間で同期して、ユーザーが別のチャネルをオプトアウトした後に 1 つのチャネルで送信しないようにします。

  • オプトアウト後も送信できるメッセージタイプ (OTPsや不正アラートなど) については、法務チームにお問い合わせください。

注記

AWS エンドユーザーメッセージングは、SMS と MMS のオプトアウトリスト管理を提供します。RCS の場合は、 AWS エンドユーザーメッセージングのオプトアウトリストと独自のアプリケーションレベルのレコードの両方を使用して、オプトアウト処理を調整します。