Resources / Service guidance

把 RCS 创意，变成可运营的消息旅程

这些框架支持企业 RCS 聚合接入与消息运营，从富媒体编排、SMS fallback 到 API/Webhook 集成，连接品牌、产品、法务和工程团队。

浏览资源 ↓查看开发者指南 →
Resource library

按消息交付流程组织的实用指南

从内容、旅程、治理、工程、衡量到术语，在一个资源库中快速定位所需指南。

▦Content guide

RCS 卡片内容框架

用标题、说明、媒体与建议操作建立可扫读的信息层级。

阅读框架 → ↘Journey guide

SMS fallback 设计

决定精简文本中必须保留的结论、链接、条件和退订信息。

阅读指南 → ✓Governance

同意与频率检查

在发送前确认同意来源、消息目的、频率、隐私和退订路径。

查看清单 → { }Engineering

集成与 Webhook 清单

覆盖幂等、签名、重试、乱序、可观察性和数据边界。

查看清单 → ◎Measurement

基础分析边界

连接消息状态、用户操作、业务归因与持续优化。

理解边界 → AaGlossary

RCS 消息术语

统一 rich card、suggested action、fallback 与 webhook 的团队语言。

查看术语 →
01 / Card content

先给结论，再给上下文与操作

手机消息不是缩小版落地页。让用户在几秒内理解发生了什么、是否紧急，以及可以做什么。

  • 标题用一句话说明对象与状态
  • 说明补充时间、地点、金额或条件，但不重复标题
  • 媒体解释内容，不承担关键信息的唯一表达
  • 操作文字使用动词，避免“点击这里”
TITLE包裹将在今天送达

先给用户最需要的结论。

DETAIL预计 14:20–16:20

补充决定下一步所需的上下文。

PRIMARY查看物流

明确最可能的用户意图。

SECONDARY调整时间

提供必要但不喧宾夺主的选项。

A

提取关键结论

明确如果只能保留一句话，用户必须知道什么。

B

保留可信入口

使用经过确认的短链接或品牌域名策略，不临时拼接未知地址。

C

加入必要条件

保留时限、费用、风险提示或退订要求。

D

独立测试文本

验证长度、字符集、分段、链接和目标市场规则。

02 / SMS fallback

备用文本不是富媒体卡片的自动截断

分别编写和审批 RCS 与 SMS 内容，确保即使没有媒体和按钮，用户仍能理解信息并安全继续。

SMS fallback 通过独立内容设计承接关键结论、可信入口、发送者设置、同意与当地规则。
04 / Integration checklist

让事件处理经得起重复、乱序和暂时失败

生产集成以鉴权、幂等、签名、重试、告警与数据保留为可靠运行基础。

查看 API 与 Webhook 工作流 →

使用稳定的业务引用或幂等键，并在服务端保留足够的去重状态。在接入配置中明确去重窗口与处理语义。

验证签名和时间戳、限制来源、快速确认并异步处理；避免在日志中记录密钥或完整敏感载荷。

使用事件 ID、发生时间和状态转换规则，根据业务时间线处理到达顺序。

05 / Measurement

把“发生了什么”和“为什么发生”分开

消息状态与建议操作呈现旅程活动，业务归因则结合自有系统中的实验与结果数据。基础分析帮助团队发现断点并持续优化。

1
消息状态

请求、路由与状态事件的操作观察。

2
用户操作

建议回复或按钮事件的旅程上下文。

3
业务结果

需在自有系统中结合实验与归因方法判断。

06 / Glossary

团队常用术语

在支持条件下，让企业消息使用富媒体卡片、建议操作和对话体验。按市场、运营商、设备、发送者与收件人条件组织消息路径。

将媒体、标题、说明与操作组合成单张卡片，或以可浏览的多卡片集合呈现相关选项。

帮助用户打开链接、导航、加入日历或发送预设回复的明确操作入口。

当 RCS 路径不可用或不适用时，按配置发送精简 SMS，延续关键内容与操作入口。

Move from guide to journey

把检查清单带进下一次消息评审。

从一个真实通知开始，邀请品牌、产品、法务和工程一起审查内容、路径、同意与验收方式。

生成需求摘要 ↗查看服务能力 →