Reports and logs

RBM creates data files that report user and agent activity on summary and transactional levels. Data is separated into multiple files:

File	Description	Who has access
Billing event report	A record of billable events between launched agents and users	All carriers that have RBM traffic on their networks
Activity log	Raw RBM platform activity data	Carriers that have RBM traffic on their networks and enable RCS activity with Jibe Cloud under their own Terms of Service (ToS)

Storage and access

Data files are encrypted at rest and in transfer.

To retrieve data files by SFTP, you need to provide your SFTP public key. To generate keys, see Generate a Secure Shell (SSH) key pair for an SFTP dropbox.

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 <path_to_private_key> -P 19321 <username>@partnerupload.google.com

Google provides account usernames in the following formats:

• rbmreports-billableevents-<carrier name>
• rbmreports-activity-<carrier name>

Google specifies <carrier name>and provides separate account for each report type.

Separate accounts are provided for accessing the different report types.

Note: If no report files have been generated yet you will see an SFTP error similar to remote readdir("/"): No such file or directory. This is expected.

Refresh and retention

Each data file represents one day of platform usage in UTC time. Records for a given day are generated once and finalized within 2 days (48 hours) after the day ends. If you load these files into a data warehouse, you can update the current month's metrics.

A file is not generated if there is no activity to account for.

The date in the name of each file is the date that the file was generated. The records in the file will cover the UTC day that comes 2 days before the file date.

The export process generating the files executes between 2 and 4am PST.

Data files are retained for a maximum of 30 days before being deleted.

Billing event reports

Billing event reports are records of billable events calculated from underlying messages using the suggested units of billing. Billable events are session- based and contain confidential information, but no user PII (e.g., no MSISDN, hashed MSISDN or any user unique identifier).

Only launched agents generate billing events. Activity from yet to be launched or unlaunched agents doesn't appear in billing reports.

The billing reports assume that sessions are billed on delivery of messages, not when messages are sent. An undelivered or revoked message before delivery doesn't trigger a session.

There are three types of billable events:

Event	Definition
Basic Message	An application-to-person (A2P) message that is up to 160 characters contains only text isn't part of a person-to-application (P2A) or A2P conversation If a P2A message is delivered in the next 24 hours, the Basic Message becomes part of an A2P conversation; otherwise, the session terminates. A Basic Message is always delivered from an agent to a user.
Single Message	An application-to-person (A2P) message that contains multimedia or text with more than 160 characters isn't part of a person-to-application (P2A) or A2P conversation If a P2A message is delivered in the next 24 hours, the Single Message becomes part of an A2P conversation; otherwise, the session terminates. A Single Message is always delivered from an agent to a user.
A2P Conversation	An A2P Conversation is initiated when a P2A message is delivered within 24 hours of an A2P Single Message. All messages delivered 24 hours before that are not part of previous sessions, and all messages delivered in the following 24 hours, are part of the new A2P Conversation Session.
P2A Conversation	A P2A Conversation is initiated when there is no active session (A2P Single Message, A2P Conversation, or P2A Conversation) and a P2A message is delivered.

Availability

Billing event reports are available to all carriers that have RBM traffic on their networks.

Format

Billing event reports use the filename format YYYY/MM/DD/rbm_billable_events_YYYY-MM-DD.csv.

The date in the filename is the date that the file is generated. The records in the file will generally cover activity for the day that was 2 days before this date.

Fields in a record are tab-separated, and there is one record per line.

Each record in the billable event report contains the following information for each event:

Field	Format	Description	Example
billing_event_id	string	The UUID identifier, a random number, generated for each new event at the time it is created.
type	string	The type of event: basic_message single_message a2p_conversation p2a_conversation	single_message
agent_id	string	The identifier of the agent that participated in the event.	[e-mail]
agent_owner	string	The email of the owner of the agent that participated in the event. This is the party that registered the RBM agent, in most cases the aggregator, but in some rare cases it may be the brand. This value is taken from the 'RBM Google account' field provided when the developer registered to use RBM.	[e-mail]
billing_party	string	The party who bills for events. google carrier	carrier
max_duration_single_message	number	The duration, in hours, for an agent's message to go without receiving a response to identify a single message session.	4
max_duration_a2p_conversation	number	The maximum duration of an A2P session, in hours. Measured from the first user response to the agent's initial message.	24
max_duration_p2a_conversation	number	The maximum duration of a P2A session, 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.	2019-07-25T08:00:00Z
duration	number	The duration of the event, rounded to the nearest minute. When type is single_message, always 0.	45
mt_messages	number	The number of mobile-terminated messages in the event.	11
mo_messages	number	The number of mobile-originated messages in the event.	9
size_kilobytes	number	The size of all files attached to messages in the event, rounded to the nearest kilobyte (1kB = 1024 bytes).	912
agent_name	string	The name of the agent that participated in the event.	XYZ Mobile USA
owner_name	string	The name of the owner of the agent that participated in the event. This is the party that registered the RBM agent, in most cases the aggregator, but in some rare cases it may be the brand. This value is taken from the 'Name of your organisation' field provided when the developer registered to use RBM.	XYZ Mobile

Sample file

A sample billing report file is available for download.

Typical file size

A daily report file from an active partner may be around 53,000 records and approximately 8Mb in size.

Activity logs

Activity logs are the raw data log of activity on the RBM platform for the purposes of auditing billable events and constructing custom events.

Availability

Activity logs are only available to carriers that have RBM traffic on their networks and enable RCS activity with Jibe Cloud under their own Terms of Service (ToS). If you use Jibe Cloud under Jibe's ToS, you won't have access to activity logs.

Note: Activity logs contain detailed transaction information and subscriber MSISDNs. Because activity logs contain Personal Identifiable Information (PII), they are only available when a carrier is operating RCS under their own Terms of Service.

Format

Activity logs use the filename format YYYY/MM/DD/rbm_activity_YYYY-MM-DD.csv.

The date in the filename is the date that the file is generated. The records in the file will generally cover activity for the day that was 2 days before this date.

Fields in a record are tab-separated, and there is one record per line.

Each record in the activity log contains the following fields for each activity event.

Field	Format	Description	Example
activity_id	string	The identifier for the activity.
billing_event_id	string	The identifier for the billing event the activity took place in.
agent_id	string	The identifier of the agent.	[e-mail]
user_id	string	The MSISDN of the user.	918369110173
direction	string	The direction that the message was 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	The UTC date/time the activity took place in ISO 8601 format.	2019-07-25T00:29:07.033Z
type	string	The 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	The size of files attached to the activity, in bytes.	912