This page describes the data files that RCS for Business creates to assist carriers with billing and auditing. | File | Description | Who has access | |---|---|---| | [Billing report](https://developers.google.com/business-communications/rcs-business-messaging/carriers/billing/reports#billing-event-reports) | Aggregated report of billable events between launched agents and users. | All carriers who are actively operating RCS for Business. | | [Activity log](https://developers.google.com/business-communications/rcs-business-messaging/carriers/billing/reports#activity) | Raw data log of RCS for Business activity, including billable events. | Carriers who are actively operating RCS for Business and operate the Google RCS Service under their own Terms of Service (ToS). | RCS for Business uses a standard billing model for non-US traffic. For details, refer to the [Billing FAQ](https://developers.google.com/business-communications/rcs-business-messaging/carriers/billing/rbm-billing-faq). ## File generation Each data file represents one day of RCS for Business usage in Pacific Standard Time (PST). Files are generated daily and reflect activity from the previous 24-hour period (midnight to midnight). The generation process can take several hours, and the completion time may vary. - For **non-conversational** agents, the files contain data from the 24-hour period that immediately preceded the day when the file was generated. For example, a report generated on May 5 covers data from 12:00 AM May 4 to 12:00 AM May 5. The time specified is in the PST timezone. - For **conversational** agents, the files contain data from the 24-hour period 1-2 days prior to the file generation time. For example, a report generated on May 5 covers data from the 24-hour window of May 2 or May 3. The time specified is in the PST timezone. The reason for the delay is that RCS for Business activity for conversational agents is linked to sessions, which can take up to 24 hours to complete. This delay allows RCS for Business to capture all messages within a conversation before calculating the billable event. For more information about conversational agents, refer to [Agent billing categories](https://developers.google.com/business-communications/rcs-business-messaging/carriers/billing/reports#agent-billing-categories). > [!NOTE] > **Note:** Reports may also contain data from the previous 30 days (both for conversational and non-conversational agents). As billing is based on the delivery time, in this case if a message was sent on April 10, but got delivered on May 4 it will be in the report generated on May 5. Key points: - **No activity**: By default, no file is generated if there's no platform activity on a given day. However, you can opt in to receive empty files if needed. To opt in, contact rbm-support@google.com. - **Naming**: The date in the filename is the file generation date, not the date of the data within. - **Retention**: Files are stored for a maximum of 63 days before being deleted. You can use these files to update your data warehouse with the latest platform usage metrics. ## File storage and access Data files are encrypted at rest and in transfer. To retrieve data files by Secure File Transfer Protocol (SFTP), provide your SFTP public key. To generate keys, see [Generate a Secure Shell (SSH) key pair for an SFTP dropbox](https://support.google.com/youtube/answer/3071034). The SFTP server is `partnerupload.google.com`, and connection is on a high port number (19321) for additional security. You can use the following command to access your data files: `sftp -i -P 19321 @partnerupload.google.com` Google provides account usernames in the following formats: - `rbmreports-billableevents-` - `rbmreports-activity-` Google specifies `` and provides separate account for each report type. Separate accounts are provided for accessing the different report types. ### File availability If no data files have been generated yet, you'll see an SFTP error similar to `remote readdir("/"): No such file or directory`, which is expected. A file won't be generated if there is no RCS for Business traffic to report. This means there may be some days when no files are generated. If you need empty files to streamline your process, [contact the RCS for Business support team](https://developers.google.com/business-communications/rcs-business-messaging/support/overview/contact). ## Billing reports Billing reports are records of [billable events](https://developers.google.com/business-communications/rcs-business-messaging/carriers/billing/reports#billing-events), which are calculated based on the agent's [billing category](https://developers.google.com/business-communications/rcs-business-messaging/guides/build/agents?model=legacy#billingCategory) and the type of messages it sends. Billing reports are available to all carriers who are actively operating RCS for Business. Billing reports contain confidential information, but no user Personal Identifiable Information (PII), such as MSISDN, hashed MSISDN, or any user unique identifier. > [!NOTE] > **Note:** Partners also receive aggregated daily summary reports to help them manage traffic, providing them with valuable analytics and necessary visibility into their traffic data. For more information, see [Partner billing reports](https://developers.google.com/business-communications/rcs-business-messaging/guides/learn/partner-billing-reports). ### Agent billing categories When creating an agent, the owner sets its [billing category](https://developers.google.com/business-communications/rcs-business-messaging/guides/build/agents#billingCategory) based on how the agent will interact with users. The billing category does not restrict the number or type of messages an agent can send. But it does determine how the agent will be billed for messages. The two main billing categories are described in the following table. | Billing category | Agent type | Example use cases | Billing method | |---|---|---|---| | Non-conversational | Agents that primarily send one-way messages. | - OTPs - Alerts - Promotional offers | Billed for each message delivered to the user. | | Conversational | Agents that are designed for back-and-forth exchanges with users. | - Finding the right product - Booking a ticket - Troubleshooting an issue | **Billed per conversation**: If one party (the agent or user) replies to a message from the other party within 24 hours, a conversation starts. During the conversation window (24 hours after the first reply), the agent and user can exchange any number of messages, and the agent will be billed a fixed rate for the conversation. **Billed per message**: If the agent delivers a message that the user doesn't reply to within 24 hours, the agent will be billed for the individual message, similar to a non-conversational agent. | The following diagram shows an example of an A2P billing session for conversational agents: ![Billing diagram](https://developers.google.com/static/business-communications/rcs-business-messaging/guides/images/billing_diagram.png) #### Conversational versus non-conversational agents There are two main billing categories: conversational and non-conversational. The key difference in the billing categories is between conversational and non-conversational agents: - Non-conversational agents are billed for each message they deliver to the user. - This category is best for agents that don't expect frequent replies. - Conversational agents are billed a flat rate for [conversations](https://developers.google.com/business-communications/rcs-business-messaging/carriers/billing/rbm-billing-faq#expandable-8), which include all messages exchanged within a 24-hour period. - This category is best for agents that engage in multi-turn conversations with users. ### Billable events Five types of billable events are recorded in the billing reports. These events include MT and MO events, which are referred to as A2P and P2A events. - **A2P (Application-to-Person) is MT (Mobile Terminated)**: A message sent by the business. - **P2A (Person-to-Application) is MO (Mobile Originated)**: A message or action initiated by the user. The following table describes each billable event as it applies to non-conversational and conversational agents. | Event | Description | Non-conversational agents | Conversational agents | |---|---|---|---| | `basic_message` | A2P message that includes only text with 160 characters or less. If the text includes a URL for a website with [openGraph tags](https://ogp.me), the message may show an image preview, at no added charge to the partner. | Always treated as an individual billable event, regardless of whether the user replies. | Treated as an individual billable event, unless the user replies within 24 hours. In that case, the message becomes part of an `a2p_conversation`. | | `single_message` | A2P message that either has rich content or is a text-only message over 160 characters. | Always treated as an individual billable event, regardless of whether the user replies. | Treated as an individual billable event, unless the user replies within 24 hours. In that case, the message becomes part of an `a2p_conversation`. | | `a2p_conversation` (business-initiated) | Initiated when a user responds to an A2P message within 24 hours of receiving it, outside of an existing conversation. | N/A. Non-conversational agents never generate this type of event. | If a P2A message is delivered within 24 hours of multiple A2P messages, only the A2P message that immediately preceded the P2A message is used to initiate the conversation. This A2P message, and any messages delivered within the next 24 hours, are part of the `a2p_conversation`. | | `p2a_conversation` (user initiated) | Initiated when an agent responds to a P2A message within 24 hours of receiving it, outside of an existing conversation. | N/A. Non-conversational agents never generate this type of event. | If an A2P message is delivered within 24 hours of multiple P2A messages, only the P2A message that immediately preceded the A2P message is used to initiate the conversation. This P2A message, and any messages delivered within the next 24 hours, are part of the `p2a_conversation`. | | `p2a_message` | P2A message of any type. | Always treated as an individual billable event, regardless of whether the agent replies. | Treated as an individual billable event, unless the agent replies within 24 hours. | #### Billing categories versus billable events The distinction between agent [billing categories](https://developers.google.com/business-communications/rcs-business-messaging/carriers/billing/rbm-billing-faq#select-billing-category) and [billable events](https://developers.google.com/business-communications/rcs-business-messaging/carriers/billing/rbm-billing-faq#what-are-billing-events) is key to understanding how your agent is billed. - **Billing category** is a fixed classification you choose when creating your agent. It determines the *method* by which your agent is billed: per message (Non-conversational agents) or per [conversation](https://developers.google.com/business-communications/rcs-business-messaging/carriers/billing/rbm-billing-faq#conversation) (Conversational agents). - **Billable events** are interactions between an RCS for Business agent and a user that are tracked for billing purposes (for example, `basic_message`, `single_message`, `a2p_conversation`). ### Billing report generation Only agents with non-tester traffic generate billable events. Activity from test phone numbers doesn't appear in billing reports. These reports assume that events are billed when messages are delivered, not when messages are sent. An undelivered message or a message canceled before delivery doesn't trigger a billable event. ### Billing report format Billing reports use the filename format `rbm_billable_events_YYYY-MM-DD.csv`. The date in the filename is the file generation date. Each line in the report is a record representing a single billable event. Fields within a record are tab separated. For example, two A2P conversations with the same agent would generate two separate billable events and two records in the billing report. Files are UTF-8 encoded without a byte order mark and use line feeds for line endings. The first line of each file is a header row with the field names. Each record in the report contains the following information for each billable event. | Field | Format | Description | Example | |---|---|---|---| | `billing_event_id` | string | Generated ID that distinguishes the billable event. | `242f1d9f-7c3f-4e5b-ab3f-818f188fa3ff` | | `type` | string | Type of event: - `basic_message` - `single_message` - `a2p_conversation` - `p2a_conversation` - `p2a_message` | `single_message` `p2a_rich_message` | | `agent_id` | string | Unique identifier for the agent that participated in the event. | `rbm-welcome-bot@rbm.goog` | | `agent_owner` | string | Email address of the current owner of the partner account where the agent was created. | `name@aggregator.com` | | `billing_party` | string | Party who bills for events. - carrier | `carrier` | | `max_duration_single_message` | number | Maximum time (in hours) allowed for a user to respond to an agent message before the conversation initiation window closes and the message is classified as a `single_message` event. | `24` | | `max_duration_a2p_conversation` | number | Maximum duration of an A2P conversation, in hours. Measured from the first user response to the agent's initial message. | `24` | | `max_duration_p2a_conversation` | number | Maximum duration of a P2A conversation, in hours. Measured from the first user message in the conversation. | `24` | | `start_time` | YYYY-mm-ddTHH:00:00Z | The UTC date/time the event started in ISO 8601 format rounded to the nearest hour. **A2P messages** - For the `single_message` and `basic_message` events, this is the time when the message is delivered to the user. - For the `a2p_conversation` event, this is the time when the first message in the conversation is delivered to the user. **P2A messages** - For the `single_message` and `basic_message` events, this is the time when the message is sent by the user. - For the `p2a_conversation` event, this is the time when the first message in the conversation is sent by the user. | `2019-07-25T08:00:00Z` | | `duration` | number | Event duration, rounded to the nearest minute. The value is 0 for any non-conversational event. | `45` | | `mt_messages` | number | Number of mobile-terminated (A2P) messages in the event. | `11` | | `mo_messages` | number | Number of mobile-originated (P2A) messages in the event. | `9` | | `size_kilobytes` | number | Size of all files attached to messages in the event, rounded to the nearest kilobyte (1kB is equal to 1024 bytes). | `912` | | `agent_name` | string | Name of the agent that participated in the event. | `XYZ Mobile USA` | | `owner_name` | string | Name of the current owner of the partner account where the agent was created. | `XYZ Mobile` | ### Sample billing report Sample reports are available for download: - [Billing report for standard billing model](https://developers.google.com/static/business-communications/rcs-business-messaging/carriers/files/rbm_billable_events_2022-05-26.csv) ### Typical file size The size of a daily report from an active RCS for Business partner depends on how much activity they've generated on the carrier's network. For example, if there are 53,000 records in the report, the file will be approximately 8Mb in size. ## Activity logs Activity logs provide raw data about activity on the RCS for Business platform. You can use these logs to audit billable events and create custom events. > [!NOTE] > **Note:** Only traffic from non-tester phone numbers is included in activity logs. Because activity logs contain Personally Identifiable Information (PII), such as detailed transaction information and subscriber MSISDNs, they are only available when a carrier is operating RCS under their own Terms of Service. If you have RCS for Business traffic on your networks and enable RCS activity with Google RCS under Google's ToS, you won't have access to activity logs. ### Activity log format Activity logs use the filename format `rbm_activity_YYYY-MM-DD.csv`. The date in the filename is the file generation date. Fields in a record are tab separated, and there is one record per line. Files are UTF-8 encoded without a byte order mark and use line feeds for line endings. The first line of each file is a header row with the field names. Each record in the activity log contains the following fields for each activity: | Field | Format | Description | Example | |---|---|---|---| | `activity_id` | string | Unique identifier for the activity. | `b422e1d3-ac99-442a-853d-a875d5e61762` | | `billing_event_id` | string | Unique identifier for the associated billable event. Can be empty if the activity is not associated with a billable event, such as a `text_message` without corresponding `delivery_receipt_event`. | `91yeb201-7c3b-412b-98d2-b0a0f7abe536` | | `agent_id` | string | Unique identifier for the agent. | `welcome-bot@rbm.goog` | | `user_id` | string | MSISDN of the user. | `918369110173` | | `direction` | string | The direction where the message is sent: - `MT` (mobile terminating) for agent-to-user activities - `MO` (mobile originating) for user-to-agent activities | `MT` | | `time` | YYYY-mm-ddTHH:MM:SS.SSSZ | Date and time when the event was submitted to the RCS for Business platform in UTC format. See [Timestamps](https://developers.google.com/business-communications/rcs-business-messaging/carriers/billing/reports#timestamps). | `2019-07-25T00:29:07.033Z` | | `type` | string | Type of activity: - `text_message` - `file_transfer` - `rich_card/carousel` - `suggestion_tap` - `delivery_receipt_event` - `read_receipt_event` - `spam_report` | `text_message` | | `size_bytes` | string | Size of files attached to the activity, in bytes. | `912` | ### Timestamps The timestamps in activity logs record when an event was submitted to the RCS for Business platform. For events that deliver content to a user, the event won't be recorded in the activity log until the message is delivered. For example, if an RCS for Business message is sent to a user on Wednesday at 13:00, and the recipient is offline until Sunday 9:00, the event will appear in the activity log generated for Sunday, but the timestamp will be Wednesday, 13:00.