本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
RCS 最佳实践
借助 RCS 丰富的消息传递,您可以创建超越传统 SMS 的对话式互动体验。本主题为设计有效的 RCS 消息提供了指导,包括建议策略、富卡和轮播布局、媒体优化、消息过期、后备计划和监控。
有关各个功能的详细信息,请参阅配置 RCS 建议发送 RCS 富豪卡、发送 RCS 旋转木马、配置 RCS 消息到期时间、配置每条消息的短信或彩信后备、和RCS 消息事件。
对话和交互式设计
RCS 消息支持互动元素,例如建议的回复、建议的操作、丰富的卡片和轮播。要有效使用这些功能,请将每次消息交换视为正在进行的对话的一部分,而不是单向通知。
- 使用上下文和选项打开
-
包括清晰的问候语,说明用户可以做什么,并提供建议的回复以指导下一步行动。这设定了期望并减少了摩擦。
- 保持消息简洁
-
每条短信应少于 300 个字符。将复杂的信息分解成多条消息,或者使用一张富卡片获取结构化内容。
- 避免死胡同
-
每条信息都应该引导下一步。提供后续建议、主菜单选项或通往人工代理的途径。
- 直接向用户讲话
-
使用第二人称。写上 “您的预约已确认”,而不是 “预约已确认”。
建议策略
建议(包括回复和操作)在您的消息下方显示为交互式筹码。它们可以减少打字,提高参与度,并允许您通过结构化PostbackData值传递回复。有关建议类型的完整列表,请参阅配置 RCS 建议。
写出简洁的动作标签
该Text字段的长度限制为 25 个字符。使用以操作为导向的语言,告诉用户点击后会发生什么。
| Avoid | 更喜欢 |
|---|---|
| “选项 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方向可在不同设备上实现最一致的渲染。 -
在 Android 和 iOS 上,使用
TALL媒体高度为图像提供足够的显示空间。 -
保持标题和描述文字简洁。有些客户裁剪超过三行的文本。
-
描述文本中的 URL 不能作为所有客户端上的链接。使用
OpenUrl建议的操作,而不是在描述中嵌入链接。 -
每张卡片都包含一条明确的号召性用语建议。多个相互竞争的操作会降低转化率。
旋转木马
-
将推荐或最相关的选项放在第一张牌的位置。用户使用第一张可见卡片进行最多的互动。
-
使用外部(消息级别)建议进行导航操作,例如 “返回菜单” 或 “帮助”。保留针对该卡牌的特定操作的卡牌级别建议。
-
保持卡片内容比独立卡片更简洁,因为旋转木马卡片的垂直空间较小。
-
旋转木马卡片媒体高度限制为
SHORT或MEDIUM(轮播中TALL不支持)。 -
确保所有卡上的合并介质保持在 100 MB 以下。在上传之前优化图片。
媒体最佳实践
媒体文件(图像、视频、PDF)增强了消息的参与度,但增加了有效负载大小和呈现可变性。有关文件格式和大小要求,请参阅发送丰富的 RCS 消息。
-
上传前压缩图片。对照片使用 JPEG,对具有透明度的图形使用 PNG。
-
将视频文件保持在 5 MB 以下,以便在运营商和设备上可靠传输。
-
ThumbnailUrl为视频和大文件消息提供。缩略图会在加载完整媒体时显示,并改善连接速度慢时的用户体验。 -
GIF 动画在 Android 上播放,但在 iOS 上显示为静态第一帧。不要依赖 GIF 动画来传达关键信息。
-
在 HTTPS 网址或亚马逊 S3 中托管媒体(使用
s3://URI)。所有媒体 URL 都必须匹配该模式^(https://|s3://).+$。
TTL 和后备策略
生存时间 (TTL) 和备用配置协同工作,确保即使在 RCS 交付失败的情况下,您的消息也能送达用户。有关实现的详细信息,请参见配置 RCS 消息到期时间和配置每条消息的短信或彩信后备。
设置 TTL 值
请务必为时间敏感的内容设置一个TimeToLive值。将 TTL 与内容相关性窗口进行匹配。
| 内容类型 | 推荐的 TTL |
|---|---|
| One-time 密码 (OTP) 或验证码 | 30 到 120 秒 |
| 限时抢购通知 | 促销结束前的持续时间 |
| 预约提醒 | 距离预约的时间 |
| 配送更新 | 1 到 4 个小时 |
注意
API 最小值为 1 秒,但建议使用至少 10 秒的 TTL,以留出足够的交付时间。最大值为 172,800 秒(48 小时)。
短信或彩信后备
FallbackConfiguration为关键消息(OTP、订单确认、安全警报)配置一个,以便在 RCS 交付失败或过期时向用户发送内容。
-
MMS根据您是否需要在后备中使用媒体,将该Channel字段设置为SMS或。 -
保持在 1,600 个字符以
MessageBody内(后备限制,它比 3,072 个字符的 RCS 文本限制短)。 -
通过发送到不支持 RCS 的电话号码并验证 SMS 或彩信是否到达,端到端测试后备传送。
监控和事件
使用事件目的地和传送事件来监控消息性能并优化您的消息传送策略。有关事件类型和配置的详细信息,请参阅RCS 消息事件。
-
在开始生产发送之前,请配置事件目的地。这可确保您从一开始就捕获传送、读取和过期事件。
-
监控消息过期率,以确定您的 TTL 值是否合适。过期率高表示 TTL 太短或许多收件人没有 RCS-capable 设备。
-
跟踪已读回执以进行相对比较(A/B 测试),而不是作为绝对指标。并非所有客户端都报告读取状态。
-
如果您在外部管理回退,则使用传送确认事件来取消应用程序逻辑中冗余的回退计时器。
设备和客户端渲染差异
安卓和 iOS 客户端上的 RCS 消息呈现方式不同。在启动活动之前,请设计最低的共同点,并在两个平台上进行测试。
| 功能 | Android | iOS |
|---|---|---|
| GIF 图片 | 动画 | 静态(仅限第一帧) |
| 以文本形式链接预览 | 消息中任意位置的 URL | URL 必须是最后一个元素。URL 后跟其他文本可能无法点击。 |
| 卡片介质高度 | 尊重短、中、高 | 以相同的方式呈现所有垂直高度。可能会忽略高度属性。 |
| 建议订购芯片 | 按发送时保存 | 可能会重新订购筹码 |
| 建议的动作持久性 | 点击后,卡片外的操作消失。卡片按钮仍然存在。 | 点击后,所有按钮(卡片和非卡片)都将保留。 |
显示带有路径字符 (/、\、:) 的名称 |
呈现为已注册 | iOS 渲染层可能会删除字符 |
| 代理横幅图片 | 在代理人资料上可见 | 未显示 |
| 隐私政策链接 | 在代理人资料上可见 | 未显示 |
| 每种类型有多个联系人 | 所有联系人条目均可见 | 只有每种类型的首次联系人可见(按列表顺序排列) |
| 具有较大无障碍文字大小的媒体 | 稳定的渲染 | 启用大文字大小后可能会裁剪图像 |
| 承运人验证徽章 | “由 [运营商] 验证” 或 “已通过 Google 验证” | 相同的徽章值。渲染由苹果控制。 |
基于以下差异的设计建议:
-
使用
VERTICAL卡片方向实现一致的布局。 -
将网址放在短信的末尾,确保在 iOS 上呈现链接预览。
-
不要依赖 GIF 动画来传达基本信息。
-
如果序列对用户流程有意义,则在两个平台上测试建议顺序。
在 iOS 上呈现显示名称
Apple 的 iOS Messages 应用程序可能会从显示的代理名称中删除类似于操作系统路径分隔符 (/\、、:) 或 URL 转义序列的字符。此行为由操作系统级别控制,AWS、Google、运营商或消息合作伙伴无法覆盖。
要避免显示名称不匹配,请执行以下操作:
-
在显示名称中仅使用字母数字字符、空格、连字符、句点和标准标点符号(例如
&'、、!)。 -
请勿在品牌名称中使用正斜杠、反斜杠或冒号。
-
如果您的品牌名称包含这些字符,请考虑使用其他表示形式(例如,使用连字符或空格代替斜杠)。
-
在请求运营商启动之前,请务必在测试阶段验证您的代理在 iOS 测试设备上的外观。这是测试代理的主要目的之一。
如果您已经启动了具有受影响的显示名称的代理,并且需要对其进行更改,请联系 AWS Support。更改已启动代理的显示名称需要承运人重新批准。
在 iOS 上可见代理档案
一些在 Android 上可见的代理个人资料元素不会在 iOS 上显示:
-
横幅图片:未在 iOS 上显示。不要依靠横幅来传达重要的品牌信息。
-
隐私政策链接:在 iOS 代理个人资料视图中不可见。确保您的隐私政策可通过其他方式访问(例如您的网站或欢迎消息中的建议操作)。
-
多个联系人:如果您配置多个电话号码、电子邮件或网站,iOS 仅显示每种联系人类型的第一个条目。配置代理时,将您的主要联系人放在列表的首位。
跨平台测试
RCS 的呈现取决于接收方的操作系统版本、设备型号和运营商配置。在请求承运人发射之前:
-
向安卓和 iOS 设备发送测试消息。
-
验证两个平台上的显示名称、徽标、横幅、描述、建议的操作、富卡片和媒体。
-
在 iOS 上使用不同的文字大小和辅助功能设置进行测试。
-
确认链接预览在两个平台上都能正确呈现。
苹果的RCS实施仍在不断演变。随着 iOS 的更新,行为可能会发生变化。在 iOS 发布后监控您的消息体验,并相应地调整您的内容。
Opt-out 处理
立即在所有消息渠道中始终如一地尊重用户的选择退出偏好。
-
在收到退出请求后,立即停止所有非必要消息,以遵守 STOP 和 UNSUBSCRIBRE 关键词。
-
发送包含您的品牌名称的简短退出确认信,以便用户知道他们取消了哪个发件人的订阅。
-
维护您自己的退出数据库,并在多个渠道(RCS、SMS、MMS)之间进行同步,以防止在用户选择退出另一个频道后在一个频道上发送消息。
-
请咨询您的法律团队,了解在选择退出后仍可能发送哪些消息类型(例如 OTP 或欺诈警报)。
注意
AWS 最终用户消息为短信和彩信提供选择退出列表管理。对于 RCS,请将您的选择退出处理与 AWS 最终用户消息选择退出列表和您自己的应用程序级记录进行协调。