View a markdown version of this page

RCS 最佳實務 - AWS 最終使用者傳訊簡訊
對話式和互動式設計建議策略豐富的卡片和浮動切換設計媒體最佳實務TTL 和備用策略監控和事件裝置和用戶端轉譯差異選擇退出處理

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

RCS 最佳實務

透過 RCS 豐富的訊息，您可以建立超越傳統 SMS 的對話互動體驗。本主題提供設計有效 RCS 訊息的指引，包括建議策略、豐富的卡片和浮動切換配置、媒體最佳化、訊息過期、備用規劃和監控。

如需個別功能的詳細資訊，請參閱 設定 RCS 建議、傳送 RCS 豐富的卡片、傳送 RCS 輪跳功能、設定每則訊息簡訊或 MMS 後援、 設定 RCS 訊息過期和 RCS 訊息事件。

對話式和互動式設計

RCS 訊息支援互動式元素，例如建議的回應、建議的動作、豐富的卡片和輪跳功能。若要有效地使用這些功能，請將每個訊息交換視為持續對話的一部分，而不是單向通知。

使用內容和選項開啟

包含明確的問候語、說明使用者可以做什麼，並提供建議的回應來引導下一個步驟。這可設定期望並減少摩擦。

保持訊息簡潔

目標是每則文字訊息少於 300 個字元。將複雜資訊分成多則訊息，或使用豐富的卡片進行結構化內容。

避免死結

每個訊息都應該導向下一個步驟。提供後續建議、主功能表選項或人類客服人員的路徑。

直接將使用者定址

使用第二個人。撰寫「您的預約已確認」而不是「預約已確認」。

建議策略

建議 （包括回覆和動作） 會在訊息下方顯示為互動式晶片。它們可減少輸入、增加參與度，並讓您透過結構化PostbackData值路由回應。如需建議類型的完整清單，請參閱 設定 RCS 建議。

寫入簡潔動作標籤

Text 欄位有 25 個字元的限制。使用動作導向語言，告訴使用者點選時會發生什麼情況。

建議標籤範例
避免 偏好
「選項 1」 「週一預訂」
"按一下這裡" 「檢視訂單狀態」
「更多資訊」 「請參閱定價詳細資訊」

提供 3 到 5 個選項

三個建議非常適合大多數互動。每則訊息最多可以包含 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 上提供足夠的顯示空間。

  • 保持標題和描述文字簡潔。有些用戶端會將文字裁剪超過三行。

  • 描述文字中的 URLs 無法做為所有用戶端上的連結。使用OpenUrl建議的動作，而不是在描述中嵌入連結。

  • 每張卡片包含一個明確的call-to-action建議。多個競爭動作會降低轉換率。

輪跳功能

  • 將建議或最相關的選項放在第一個卡片位置。使用者最常使用第一張可見的卡片。

  • 對導覽動作使用外部 （訊息層級） 建議，例如「返回功能表」或「說明」。預留該卡片特定動作的卡片層級建議。

  • 讓卡片內容比獨立卡片更簡潔，因為浮動切換卡的垂直空間較少。

  • 浮動切換卡媒體高度限制為 SHORT或 MEDIUM(TALL浮動切換不支援 )。

  • 確保所有卡的合併媒體保持在 100 MB 以下。在上傳之前最佳化映像。

媒體最佳實務

媒體檔案 （影像、影片、PDFs) 可增強訊息參與度，但新增承載大小和轉譯變異性。如需檔案格式和大小需求，請參閱 傳送豐富的 RCS 訊息。

  • 在上傳之前壓縮影像。將 JPEG 用於相片，將 PNG 用於具有透明度的圖形。

  • 將影片檔案保留在 5 MB 以下，以便在電信業者和裝置之間可靠交付。

  • ThumbnailUrl 為影片和大型檔案訊息提供 。縮圖會在完整媒體載入時顯示，並改善慢速連線的使用者體驗。

  • GIF 動畫在 Android 上播放，但在 iOS 上顯示為靜態第一個影格。請勿倚賴 GIF 動畫來傳達重要資訊。

  • 在 HTTPS URLs或 Amazon S3 中託管媒體 （使用 s3:// URIs)。所有媒體 URLs必須符合模式 ^(https://|s3://).+$。

TTL 和備用策略

存留時間 (TTL) 和備用組態可一起運作，以確保即使 RCS 交付失敗，您的訊息仍會送達使用者。如需實作詳細資訊，請參閱 設定 RCS 訊息過期和 設定每則訊息簡訊或 MMS 後援。

設定 TTL 值

一律設定時間敏感內容TimeToLive的值。將 TTL 與內容相關性視窗相符。

依內容類型的建議 TTL 值
內容類型 建議的 TTL
一次性密碼 (OTP) 或驗證碼 30 到 120 秒
快閃銷售通知 銷售結束之前的持續時間
預約提醒 預約時間
交付更新 1 到 4 小時
注意

API 最小值為 1 秒，但建議至少 10 秒的 TTL 以允許足夠的交付時間。上限為 172，800 秒 (48 小時）。

SMS 或 MMS 備用

FallbackConfiguration 為關鍵訊息 (OTPs、訂單確認、安全提醒） 設定 ，以便在 RCS 交付失敗或過期時，內容會送達使用者。

  • 將 Channel 欄位設定為 SMS或 ，MMS取決於您在後援中是否需要媒體。

  • 將 保留在 1，600 個字元MessageBody內 （後援限制，短於 3，072 個字元的 RCS 文字限制）。

  • 將 傳送至不支援 RCS 的電話號碼，並驗證簡訊或 MMS 訊息是否送達，以end-to-end測試備用交付。

監控和事件

使用事件目的地和交付事件來監控訊息效能，並最佳化您的訊息策略。如需事件類型和組態的詳細資訊，請參閱 RCS 訊息事件。

  • 在開始生產傳送之前設定事件目的地。這可確保您從一開始就擷取交付、讀取和過期事件。

  • 監控訊息過期率，以判斷您的 TTL 值是否適當。高過期率表示 TTL 太短或許多收件人沒有支援 RCS 的裝置。

  • 追蹤相對比較 (A/B 測試） 的讀取回條，而非絕對指標。並非所有用戶端都會報告讀取狀態。

  • 如果您在外部管理後援，請使用交付確認事件取消應用程式邏輯中的備援後援計時器。

裝置和用戶端轉譯差異

RCS 訊息在 Android 和 iOS 用戶端之間呈現的方式不同。在啟動行銷活動之前，針對兩個平台上的最低通用分母和測試進行設計。

Android 和 iOS 之間的轉譯差異
功能 Android iOS
GIF 影像 動畫 靜態 （僅限第一個影格）
以文字連結預覽 訊息中任何位置的 URL URL 必須是最後一個元素。接續其他文字的 URL 可能無法點選。
卡片媒體高度 遵守 SHORT、MEDIUM 和 TALL 以相同的方式轉譯所有垂直高度。可能會忽略高度屬性。
建議晶片順序 保留為已傳送 可能會重新排序晶片
建議的動作持續性 卡片外部的動作會在點選後消失。卡片按鈕會持續存在。 所有按鈕 （卡片和非卡片） 都會在點選後保留。
顯示名稱與路徑字元 (/、\、:) 已註冊的轉譯 iOS 轉譯層可能會分割字元
客服人員橫幅影像 在客服人員設定檔上可見 未顯示
隱私權政策連結 在客服人員設定檔上可見 未顯示
每種類型的多個聯絡人 所有聯絡人項目都可見 只有每種類型的第一個聯絡人可見 （依清單順序）
具有大型可存取性文字大小的媒體 穩定轉譯 啟用大型文字大小時可裁剪影像
電信業者驗證徽章 「由 【Carrier】 驗證」或「由 Google 驗證」 相同的徽章值。由 Apple 控制的轉譯。

根據這些差異設計建議：

  • 使用VERTICAL卡片方向進行一致的配置。

  • 在文字訊息結尾放置 URLs，以確保在 iOS 上呈現連結預覽。

  • 請勿依賴 GIF 動畫來傳達重要資訊。

  • 如果序列對使用者流程有意義，請在兩個平台上測試建議順序。

在 iOS 上顯示名稱轉譯

Apple 的 iOS Messages 應用程式可能會從顯示的代理程式名稱中分割類似作業系統路徑分隔符號 (/、\、:) 或 URL 逸出序列的字元。此行為是在作業系統層級控制，且無法由 AWS、Google、電信業者或簡訊合作夥伴覆寫。

若要避免顯示名稱不相符：

  • 在顯示名稱中僅使用英數字元、空格、連字號、句點和標準標點符號 （例如 &、'、!)。

  • 請勿在品牌名稱中使用正斜線、反斜線或冒號。

  • 如果您的品牌名稱包含這些字元，請考慮替代表示法 （例如，使用連字號或空格，而不是斜線）。

  • 在請求電信業者啟動之前，請務必在測試階段驗證 iOS 測試裝置上代理程式的外觀。這是測試代理程式的主要目的之一。

如果您已啟動具有受影響顯示名稱的客服人員，且需要變更，請聯絡 AWS Support。在啟動的客服人員上顯示名稱變更需要電信業者重新核准。

iOS 上的客服人員設定檔可見性

某些在 Android 上可見的客服人員設定檔元素不會在 iOS 上顯示：

  • 橫幅影像：不會在 iOS 上顯示。請勿依賴橫幅來傳達關鍵品牌資訊。

  • 隱私權政策連結：不會顯示在 iOS 代理程式設定檔檢視中。確保您的隱私權政策可透過其他方式 （例如您的網站或歡迎訊息中的建議動作） 存取。

  • 多個聯絡人：如果您設定多個電話號碼、電子郵件或網站，iOS 只會顯示每個聯絡類型的第一個項目。設定客服人員時，請先將主要聯絡人放在清單中。

跨平台測試

RCS 轉譯取決於收件人的作業系統版本、裝置模型和電信業者組態。請求電信業者啟動之前：

  • 將測試訊息傳送至 Android 和 iOS 裝置。

  • 在兩個平台上驗證顯示名稱、標誌、橫幅、描述、建議的動作、多張卡片和媒體。

  • 在 iOS 上使用不同的文字大小和可存取性設定進行測試。

  • 確認連結預覽在兩個平台上正確呈現。

Apple 的 RCS 實作仍在發展中。行為可能會隨著 iOS 更新而變更。在 iOS 發行後監控您的簡訊體驗，並相應地調整您的內容。

選擇退出處理

在所有訊息管道中，立即且一致地遵守使用者選擇退出偏好設定。

  • 在選擇退出請求之後，立即停止所有非必要訊息，以表彰 STOP 和 UNSUBSCRIBE 關鍵字。

  • 傳送簡短的選擇退出確認，其中包含您的品牌名稱，讓使用者知道他們取消訂閱的寄件者。

  • 維護您自己的選擇退出資料庫，並將其跨管道 (RCS、SMS、MS) 同步，以防止在使用者選擇退出另一個管道之後，在一個管道上傳送。

  • 請洽詢您的法務團隊，了解在選擇退出後仍可能傳送哪些訊息類型 （例如 OTPs或詐騙提醒）。

注意

AWS 最終使用者傳訊提供 SMS 和 MMS 的選擇退出清單管理。對於 RCS，請使用 AWS 最終使用者傳訊選擇退出清單和您自己的應用程式層級記錄來協調選擇退出處理。