本页介绍了 RBM 创建的数据文件，以协助运营商进行结算和审核。
| 文件 | 说明 | 有权访问的人 |
|---|---|---|
| 结算事件报告 | 关于已启动的客服人员与用户之间的可结算事件的汇总报告。 | 签署了 RBM MDA 的所有运营商。 |
| 活动日志 | RBM 活动的原始数据日志，包括可结算事件。 | 签署了 RBM MDA 且根据自己的《服务条款》(ToS) 运营 Google RCS 服务的运营商。 |
文件生成
每个数据文件代表一天的 RBM 使用情况（以世界协调时间 [UTC] 为单位）。文件每天在世界协调时间 (UTC) 10:00 到 12:00 之间生成。
对于非对话式客服人员，这些文件包含文件生成时间前 24 小时内的数据。例如，如果结算事件报告在 5 月 5 日世界协调时间 (UTC) 11:00 生成，则其中将包含 5 月 4 日世界协调时间 (UTC) 11:00 至 5 月 5 日世界协调时间 (UTC) 11:00 的数据。
对于对话式客服人员，这些文件包含文件生成时间前 1-2 天的 24 小时内的数据。例如，如果结算事件报告在 5 月 5 日 11:00 UTC 生成，则其中可能包含 5 月 3 日 11:00 UTC 至 5 月 4 日 11:00 UTC 的数据。
出现延迟的原因是，对话式 AI 助理的 RBM 活动与对话相关联，而对话最长可能需要 48 小时才能完成。此延迟时间可让 RBM 在计算结算事件之前捕获对话中的所有消息。如需详细了解对话式客服人员，请参阅客服人员结算类别。
要点：
无活动：如果指定日期没有平台活动，系统将不会生成任何文件。
命名：文件名中的日期是文件生成日期，而不是其中数据的日期。
保留：文件最多会保留 30 天，然后才会被删除。
您可以使用这些文件将最新的平台使用指标更新到数据仓库。
文件存储和访问
数据文件在静态存储时和传输过程中都会加密。
如需通过安全文件传输协议 (SFTP) 检索数据文件，请提供您的 SFTP 公钥。如需生成密钥，请参阅为 SFTP Dropbox 生成安全外壳 (SSH) 密钥对。
SFTP 服务器为 partnerupload.google.com，连接使用高端口号 (19321) 以加强安全性。
您可以使用以下命令访问数据文件：
sftp -i <path_to_private_key> -P 19321 <username>@partnerupload.google.com
Google 提供的账号用户名采用以下格式：
rbmreports-billableevents-<carrier name>rbmreports-activity-<carrier name>
Google 会指定 <carrier name>，并为每种报告类型提供单独的账号。
您需要使用不同的账号才能访问不同的报告类型。
文件可用性
如果尚未生成任何数据文件，您会看到类似 remote readdir("/"): No such file or directory 的 SFTP 错误，这是正常现象。
如果没有要报告的 RBM 流量，系统将不会生成文件。这意味着，有些天可能不会生成任何文件。如果您需要空文件来简化流程，请联系 rbm-support@google.com。
结算事件报告
结算事件报告是结算事件的记录，系统会根据代理的结算类别和其发送的消息类型来计算这些记录。结算事件报告面向已实施 RBM MDA 的所有运营商提供。
结算事件报告包含机密信息，但不包含用户个人身份信息 (PII)，例如 MSISDN、经过哈希处理的 MSISDN 或任何用户唯一标识符。
代理结算类别
创建代理时，所有者可以根据代理与用户的互动方式设置其结算类别。结算类别不会限制客服人员可以发送的消息数量或类型。但它确实会决定系统如何向客服人员收取消息费用。下表介绍了两大结算类别。
| 结算类别 | 代理类型 | 用例示例 | 结算方式 |
|---|---|---|---|
非对话式 （包括“基本消息”和“单条消息”类别。注意：这两类内容不再有任何区别。属于这两类中的任一类别的客服人员都将按非对话式客服人员的费率计费。） |
主要发送单向消息的客服人员。 |
|
按向用户传送的消息数量收费。 |
| 对话式 | 旨在与用户进行来回交流的代理。 |
|
按对话计费：如果一方（客服人员或用户）在 24 小时内回复另一方发来的消息，则会开启对话。在对话时间范围（首次回复后的 24 小时内）内，客服人员和用户可以互换任意数量的消息，并且客服人员将按固定费率支付对话费用。 按消息计费：如果代理发送的消息在 24 小时内未收到用户回复，系统会按消息向代理收费，与非对话型客服人员类似。 |
对话式代理与非对话式代理
结算类别主要分为两类：对话型和非对话型。“非对话型”类别包括“基本消息”和“单个消息”类别，这两个类别的功能相同。属于这两类中的任一类别的客服人员都会按非对话式客服人员的费率计费。
结算类别的主要区别在于对话型客服人员和非对话型客服人员：
非对话式客服人员向用户传送每条消息时，系统都会收取相应费用。
- 此类别最适合预计不会频繁回复的客服人员。
系统会按对话（包括 24 小时内互发的所有消息）向对话代理收取固定费用。
- 此类别最适合与用户进行多轮对话的客服人员。
结算事件
结算事件报告中会记录五种不同类型的结算事件。这些事件包括 A2P 和 P2A 消息。
- A2P（应用到个人）：由企业发送。
- P2A（个人与应用）：由用户发送。
下表介绍了适用于非对话式和对话式客服人员的每项结算事件。
| 事件 | 说明 | 非对话式客服 | 对话代理 |
|---|---|---|---|
basic_message
|
仅包含文本且不超过 160 个字符的 A2P 消息。如果文本包含包含 openGraph 代码的网站的网址，则消息可能会显示图片预览，而合作伙伴无需为此支付额外费用。 | 无论用户是否回复，始终都将其视为单独的结算事件。 | 除非用户在 24 小时内回复，否则会被视为单独的结算事件。在这种情况下，消息会成为 a2p_conversation 的一部分。 |
single_message
|
包含多媒体内容和/或超过 160 个字符的文字的 A2P 消息。 | 无论用户是否回复，始终都将其视为单独的结算事件。 | 除非用户在 24 小时内回复，否则会被视为单独的结算事件。在这种情况下，消息会成为 a2p_conversation 的一部分。 |
a2p_conversation（由商家发起）
|
当用户在收到 A2P 消息后的 24 小时内回复该消息，且不在现有对话中时发起。 | N/A。非对话式客服代理绝不会生成此类事件。 | 如果 P2A 消息在多条 A2P 消息发送后的 24 小时内传送，则系统只会使用紧随 P2A 消息之前的 A2P 消息来发起对话。这条 A2P 消息以及接下来 24 小时内传送的所有消息都属于 a2p_conversation。
|
p2a_conversation（用户发起）
|
当代理在收到 P2A 消息后的 24 小时内回复该消息（而非在现有对话中回复）时发起。 | N/A。非对话式客服人员从不生成此类事件。 | 如果 A2P 消息在多条 P2A 消息发送后的 24 小时内传送，则系统只会使用紧随 A2P 消息之前的 P2A 消息来发起对话。这条 P2A 消息以及接下来 24 小时内传送的所有消息都属于 p2a_conversation。
|
p2a_message
|
任何类型的 P2A 消息。 | 无论客服人员是否回复，均始终被视为单独的结算事件。 | 除非客服人员在 24 小时内回复，否则将其视为单个结算事件。 |
结算事件与结算类别
请勿将 basic_message 和 single_message 结算事件与“基本消息”和“单条消息”结算类别混淆。
任何代理（无论其结算类别如何）都可以生成
basic_message和single_message结算事件。“基本消息”和“单条消息”结算类别用于对非对话式客服人员进行分类。这些结算类别中的客服人员不会生成对话式结算事件 (
a2p_conversations或p2a_conversations)，而是会生成单独的basic_message、single_message和p2a_message结算事件。
结算报告生成
只有获得非测试人员流量的代理会生成结算事件。测试电话号码的活动不会显示在结算事件报告中。
这些报告假定事件的计费时间为消息传送时间，而非消息发送时间。未递送的消息或在递送前取消的消息不会触发结算事件。
结算报告格式
结算事件报告使用文件名格式 rbm_billable_events_YYYY-MM-DD.csv。文件名中的日期是文件生成日期。
报告中的每一行都是一条记录，表示单个结算事件。 记录中的字段以制表符分隔。例如，与同一客服人员进行的两次 A2P 对话会在结算事件报告中生成两个结算事件和两个记录。
报告中的每条记录都包含每项结算事件的以下信息：
| 字段 | 格式 | 说明 | 示例 |
|---|---|---|---|
billing_event_id
|
字符串 | UUID 标识符。系统在创建每个新事件时为其生成的随机数字。 | 242f1d9f-7c3f-4e5b-ab3f-818f188fa3ff
|
type
|
字符串 | 事件类型：
|
single_message
|
agent_id
|
字符串 | 参与事件的代理的唯一标识符。 | rbm-welcome-bot@rbm.goog
|
agent_owner
|
字符串 | 创建代理的合作伙伴账号的当前所有者的电子邮件地址。 | name@aggregator.com
|
billing_party
|
字符串 | 为活动结算账单的一方。
|
carrier
|
max_duration_single_message
|
数值 | 在对话发起时间范围结束并将消息归类为 single_message 事件之前，用户响应客服人员消息的最大时限（以小时为单位）。
|
24
|
max_duration_a2p_conversation
|
数值 | A2P 对话时长上限（以小时为单位）。从用户对客服人员初始消息的首次回复起算。 | 24
|
max_duration_p2a_conversation
|
数值 | 人机对话时长上限（以小时为单位）。从对话中的第一条用户消息开始计算。 | 24
|
start_time
|
YYYY-mm-ddTHH:00:00Z | 事件的开始日期/时间（采用 ISO 8601 格式，舍入到最近的小时）。
|
2019-07-25T08:00:00Z
|
duration
|
数值 | 活动时长（四舍五入到最接近的分钟数）。
当事件类型为 |
45
|
mt_messages
|
数值 | 事件中移动端终止 (A2P) 消息的数量。 | 11
|
mo_messages
|
数值 | 事件中移动端发起 (P2A) 消息的数量。 | 9
|
size_kilobytes
|
数值 | 事件中邮件附加的所有文件的大小，四舍五入到最接近的千字节（1kB = 1024 字节）。 | 912
|
agent_name
|
字符串 |
参与事件的客服人员的姓名。 |
XYZ Mobile USA
|
owner_name
|
字符串 | 创建客服人员的合作伙伴账号的当前所有者的姓名。 | XYZ Mobile
|
结算事件报告示例
您可以下载结算报告示例文件。
典型文件大小
来自有效 RBM 合作伙伴的每日报告可能包含约 53,000 条记录，大小约为 8MB。
活动日志
活动日志提供有关 RBM 平台上活动的原始数据。您可以使用这些日志来审核结算事件和创建自定义事件。
由于活动日志包含个人身份信息 (PII)，例如详细的交易信息和订阅者 MSISDN，因此只有在运营商根据自己的服务条款运营 RCS 时，才能使用这些日志。如果您的网络上有 RBM 流量，并且您根据 Google 的服务条款启用了 Google RCS 的 RCS 活动，则无法访问活动日志。
活动日志格式
活动日志使用文件名格式 rbm_activity_YYYY-MM-DD.csv。文件名中的日期是文件生成日期。
记录中的字段以制表符分隔，每行包含一个记录。
活动日志中的每条记录都包含每项活动的以下字段：
| 字段 | 格式 | 说明 | 示例 |
|---|---|---|---|
activity_id
|
字符串 | 活动的唯一标识符。 | b422e1d3-ac99-442a-853d-a875d5e61762
|
billing_event_id
|
字符串 | 关联的结算事件的唯一标识符。如果活动未与结算事件相关联（例如，没有相应 delivery_receipt_event 的 text_message），则可以为空。
|
91yeb201-7c3b-412b-98d2-b0a0f7abe536
|
agent_id
|
字符串 | 代理的唯一标识符。 | welcome-bot@rbm.goog
|
user_id
|
字符串 | 用户的 MSISDN。 | 918369110173
|
direction
|
字符串 | 消息的发送方向：
|
MT
|
time
|
YYYY-mm-ddTHH:MM:SS.SSSZ | 事件提交到 RBM 平台的日期和时间（采用世界协调时间 [UTC] 格式）。请参阅时间戳。 | 2019-07-25T00:29:07.033Z
|
type
|
字符串 | 活动类型：
|
text_message
|
size_bytes
|
字符串 | 附加到 activity 的文件的大小（以字节为单位）。 | 912
|
时间戳
活动日志中的时间戳记录了事件提交到 RBM 平台的时间。对于向用户传送内容的事件，系统不会在消息传送之前将该事件记录在活动日志中。
例如，如果您在周三 13:00 向用户发送了 RBM 消息，而收件人一直处于离线状态，直到周日 9:00 才上线，那么该事件将显示在为周日生成的活动日志中，但时间戳将是周三 13:00。
常见问题解答
什么是对话？
在 RBM 中，对话是指用户与对话式 AI 助理在 24 小时内互换的一系列消息。只有采用对话式结算类别的代理才能生成对话，并且会因以下结算事件而产生费用：
- A2P 对话：由商家发起的对话。
- 人机对话：由用户发起的对话。
对话的运作方式
开始：当一方（客服人员或用户）在收到另一方发来的消息后的 24 小时内回复该消息时，对话便会开始（不包括任何现有对话）。
- A2P 对话：从用户回复代理的消息开始。
- 人机对话：从代理回复用户的消息开始。
对话时段：对话在开始后会保持活跃状态 24 小时。对话包括这 24 小时内的所有消息，以及最初回复的第一条消息。
结算：对话式客服人员的计费方式是根据整个对话进行计费，而不是按每条消息计费。这意味着费用与对话会话相关，而不是与其中的消息数量相关。
重要提示：
对话不适用于非对话式智能体。对于采用“基本消息”或“单次消息”结算类别的客服人员，系统会按消息收费，无论用户是否回复。
对于对话式 AI 客服人员，结算事件报告和活动日志的生成最多可能会延迟两天。这样一来，RBM 便可以在计算结算事件之前捕获对话中的所有消息。