Informes de eventos de facturación y registros de actividad

En esta página, se describen los archivos de datos que crea RBM para ayudar a los operadores con la facturación y la auditoría.

Archivo	Descripción	Quién tiene acceso
Informe de eventos de facturación	Informe agregado de eventos facturables entre los agentes iniciados y los usuarios	Todos los operadores con un MDA de RBM firmado
Registro de actividad	Registro de datos sin procesar de la actividad de la RBM, incluidos los eventos facturables	Operadores con una MDA de RBM firmada que operan el servicio de RCS de Google de conformidad con sus propias Condiciones del Servicio (CS)

Generación de archivos

Cada archivo de datos representa un día de uso de la RBM en la hora universal coordinada (UTC). Los archivos se generan todos los días entre las 10:00 y las 12:00 (UTC).

• En el caso de los agentes no conversacionales, los archivos contienen datos del período de 24 horas que precedió inmediatamente al tiempo de generación del archivo. Por ejemplo, si se genera un informe de eventos de facturación a las 11:00 a.m. (UTC) del 5 de mayo, contendrá datos del 4 de mayo a las 11:00 a.m. (UTC) al 5 de mayo a las 11:00 a.m. (UTC).

• En el caso de los agentes conversacional, los archivos contienen datos del período de 24 horas de 1 a 2 días antes de la hora de generación del archivo. Por ejemplo, si se genera un informe de eventos de facturación a las 11:00 a.m. (UTC) del 5 de mayo, es posible que contenga datos del 3 de mayo a las 11:00 a.m. (UTC) al 4 de mayo a las 11:00 a.m. (UTC).

  El motivo del retraso es que la actividad de RBM para agentes conversacionales está vinculada a las conversaciones, que pueden tardar hasta 48 horas en completarse. Esta demora permite que la RBM capture todos los mensajes de una conversación antes de calcular el evento de facturación. Para obtener más información sobre los agentes conversacionales, consulta Categorías de facturación de agentes.

Puntos clave:

• Sin actividad: Si no hay actividad en la plataforma en un día determinado, no se genera ningún archivo.

• Nombres: La fecha en el nombre del archivo es la fecha de generación del archivo, no la fecha de los datos que contiene.

• Retención: Los archivos se almacenan durante un máximo de 30 días antes de que se borren.

Puedes usar estos archivos para actualizar tu almacén de datos con las métricas de uso más recientes de la plataforma.

Almacenamiento y acceso a archivos

Los archivos de datos se encriptan en reposo y en transferencia.

Para recuperar archivos de datos a través de SFTP, proporciona tu clave pública de SFTP. Para generar claves, consulta Cómo generar un par de claves Secure Shell (SSH) para un buzón de SFTP.

El servidor SFTP es partnerupload.google.com y la conexión está en un número de puerto alto (19321) para mayor seguridad.

Puedes usar el siguiente comando para acceder a tus archivos de datos:

sftp -i <path_to_private_key> -P 19321 <username>@partnerupload.google.com

Google proporciona los nombres de usuario de las cuentas en los siguientes formatos:

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

Google especifica <carrier name> y proporciona una cuenta independiente para cada tipo de informe.

Se proporcionan cuentas independientes para acceder a los diferentes tipos de informes.

Disponibilidad de archivos

Si aún no se generaron archivos de datos, verás un error de SFTP similar a remote readdir("/"): No such file or directory, lo cual es esperable.

No se generará un archivo si no hay tráfico de RBM para informar. Esto significa que puede haber algunos días en los que no se generen archivos. Si necesitas archivos vacíos para optimizar tu proceso, comunícate con [e-mail].

Informes de eventos de facturación

Los informes de eventos de facturación son registros de eventos de facturación, que se calculan en función de la categoría de facturación del agente y el tipo de mensajes que envía. Los informes de eventos de facturación están disponibles para todos los operadores que tienen un MDA de RBM implementado.

Los informes de eventos de facturación contienen información confidencial, pero no información de identificación personal (PII) del usuario, como MSISDN, MSISDN con hash o cualquier identificador único del usuario.

Categorías de facturación del agente

Cuando se crea un agente, el propietario establece su categoría de facturación según cómo interactuará el agente con los usuarios. La categoría de facturación no limita la cantidad ni el tipo de mensajes que puede enviar un agente. Sin embargo, determina cómo se facturará al agente por los mensajes. En la siguiente tabla, se describen las dos categorías de facturación principales.

Categoría de facturación	Tipo de agente	Ejemplos de casos de uso	Método de facturación
No conversacional (Incluye las categorías de mensaje básico y mensaje único). Nota: Ya no hay ninguna diferencia entre estas dos categorías. Un agente de cualquiera de las categorías se facturará como un agente no conversacional).	Agentes que envían principalmente mensajes unidireccionales.	OTP Alertas Ofertas promocionales	Se factura por cada mensaje que se entrega al usuario.
Conversacional	Son agentes diseñados para intercambiar mensajes con los usuarios.	Cómo encontrar el producto adecuado Reservar un boleto Cómo solucionar un problema	Facturación por conversación: Si una de las partes (el agente o el usuario) responde un mensaje de la otra parte en un plazo de 24 horas, se inicia una conversación. Durante el período de la conversación (24 horas después de la primera respuesta), el agente y el usuario pueden intercambiar cualquier cantidad de mensajes, y se le facturará al agente una tarifa fija por la conversación. Facturación por mensaje: Si el agente envía un mensaje al que el usuario no responde en un plazo de 24 horas, se le facturará el mensaje individual, similar a un agente no conversacional.

Agentes conversacionales y no conversacionales

Existen dos categorías de facturación principales: conversacional y no conversacional. La categoría no conversacional incluye las categorías Mensaje básico y Mensaje único, que son funcionalmente idénticas. Un agente de cualquiera de estas categorías se factura como un agente no conversacional.

La diferencia clave en las categorías de facturación es entre los agentes conversacionales y los que no lo son:

• Los agentes no conversacionales se facturan por cada mensaje que envían al usuario.

  • Esta categoría es mejor para los agentes que no esperan respuestas frecuentes.

• A los agentes conversacionales se les factura una tarifa fija por las conversaciones, que incluyen todos los mensajes que se intercambian en un período de 24 horas.

  • Esta categoría es ideal para los agentes que participan en conversaciones de varios turnos con los usuarios.

Eventos de facturación

En los informes de eventos de facturación, se registran cinco tipos diferentes de eventos de facturación. Estos eventos incluyen mensajes A2P y P2A.

• A2P (de aplicación a persona): La marca es quien envía los mensajes.
• P2A (persona a aplicación): El usuario lo envía.

En la siguiente tabla, se describe cada evento de facturación según se aplica a los agentes conversacionales y no conversacionales.

Evento	Descripción	Agentes no conversacionales	Agentes conversacionales
basic_message	Es un mensaje A2P que solo incluye texto con 160 caracteres o menos. Si el texto incluye una URL de un sitio web con etiquetas openGraph, es posible que el mensaje muestre una vista previa de la imagen, sin cargo adicional para el socio.	Siempre se considera un evento de facturación individual, independientemente de si el usuario responde.	Se considera un evento de facturación individual, a menos que el usuario responda en un plazo de 24 horas. En ese caso, el mensaje se convierte en parte de un a2p_conversation.
single_message	Mensaje A2P que incluye contenido multimedia o texto con más de 160 caracteres.	Siempre se considera un evento de facturación individual, independientemente de si el usuario responde.	Se considera un evento de facturación individual, a menos que el usuario responda en un plazo de 24 horas. En ese caso, el mensaje se convierte en parte de un a2p_conversation.
a2p_conversation (marca iniciada)	Se inicia cuando un usuario responde un mensaje A2P en un plazo de 24 horas después de recibirlo, fuera de una conversación existente.	N/A. Los agentes no conversacionales nunca generan este tipo de evento.	Si se entrega un mensaje P2A dentro de las 24 horas posteriores a varios mensajes A2P, solo se usa el mensaje A2P que precede inmediatamente al mensaje P2A para iniciar la conversación. Este mensaje A2P y cualquier mensaje que se entregue en las próximas 24 horas forman parte de a2p_conversation.
p2a_conversation (iniciado por el usuario)	Se inicia cuando un agente responde un mensaje de P2A en un plazo de 24 horas después de recibirlo, fuera de una conversación existente.	N/A. Los agentes no conversacionales nunca generan este tipo de evento.	Si se entrega un mensaje A2P dentro de las 24 horas posteriores a varios mensajes P2A, solo se usa el mensaje P2A que precede inmediatamente al mensaje A2P para iniciar la conversación. Este mensaje de P2A y cualquier mensaje que se entregue en las próximas 24 horas forman parte de p2a_conversation.
p2a_message	Mensaje P2A de cualquier tipo	Siempre se considera un evento de facturación individual, independientemente de si el agente responde.	Se considera un evento de facturación individual, a menos que el agente responda en un plazo de 24 horas.

Diferencia entre eventos de facturación y categorías de facturación

No se deben confundir los eventos de facturación basic_message y single_message con las categorías de facturación de mensajes básicos y de un solo mensaje.

• Cualquier agente (sin importar su categoría de facturación) puede generar eventos de facturación basic_message y single_message.

• Las categorías de facturación de mensajes básicos y de un solo mensaje se usan para clasificar a los agentes no conversacionales. Los agentes de estas categorías de facturación no generan eventos de facturación de conversación (a2p_conversations o p2a_conversations). En su lugar, generan eventos de facturación individuales de basic_message, single_message y p2a_message.

Generación de informes de facturación

Solo los agentes con tráfico que no es de verificador generan eventos de facturación. La actividad de los números de teléfono de prueba no aparece en los informes de eventos de facturación.

En estos informes, se supone que los eventos se facturan cuando se entregan los mensajes, no cuando se envían. Un mensaje no entregado o cancelado antes de su entrega no activa un evento de facturación.

Formato del informe de facturación

Los informes de eventos de facturación usan el formato de nombre de archivo rbm_billable_events_YYYY-MM-DD.csv. La fecha en el nombre del archivo es la fecha de generación del archivo.

Cada línea del informe es un registro que representa un solo evento de facturación. Los campos dentro de un registro están separados por tabulaciones. Por ejemplo, dos conversaciones A2P con el mismo agente generarían dos eventos de facturación y dos registros en el informe de eventos de facturación.

Cada registro del informe contiene la siguiente información para cada evento de facturación:

Campo	Formato	Descripción	Ejemplo
billing_event_id	string	Es el identificador UUID. Es un número aleatorio que se genera para cada evento nuevo en el momento de su creación.	242f1d9f-7c3f-4e5b-ab3f-818f188fa3ff
type	string	Tipo de evento: basic_message single_message a2p_conversation p2a_conversation p2a_message	single_message
agent_id	string	Es el identificador único del agente que participó en el evento.	[e-mail]
agent_owner	string	Es la dirección de correo electrónico del propietario actual de la cuenta de socio en la que se creó el agente.	[e-mail]
billing_party	string	Es la parte que factura los eventos. google operador	carrier
max_duration_single_message	número	Es el tiempo máximo (en horas) que se le permite a un usuario responder un mensaje de un agente antes de que se cierre la ventana de inicio de la conversación y el mensaje se clasifique como un evento single_message.	24
max_duration_a2p_conversation	número	Es la duración máxima de una conversación A2P, en horas. Se mide desde la primera respuesta del usuario al mensaje inicial del agente.	24
max_duration_p2a_conversation	número	Es la duración máxima de una conversación de P2A, en horas. Se mide a partir del primer mensaje del usuario en la conversación.	24
start_time	YYYY-mm-ddTHH:00:00Z	Es la fecha y hora UTC en la que comenzó el evento, en formato ISO 8601, redondeada a la hora más cercana. Para los eventos a2p_conversation y p2a_conversation, esta es la hora en que comenzó la conversación. Para los eventos single_message y basic_message, esta es la hora en que se produjo el evento.	2019-07-25T08:00:00Z
duration	número	Es la duración del evento, redondeada al minuto más cercano. Cuando el tipo de evento es single_message o basic_message, el valor es 0.	45
mt_messages	número	Cantidad de mensajes de terminación móvil (A2P) en el evento.	11
mo_messages	número	Cantidad de mensajes originados en dispositivos móviles (P2A) en el evento.	9
size_kilobytes	número	Es el tamaño de todos los archivos adjuntos a los mensajes del evento, redondeado al kilobyte más cercano (1 KB = 1,024 bytes).	912
agent_name	string	Es el nombre del agente que participó en el evento.	XYZ Mobile USA
owner_name	string	Es el nombre del propietario actual de la cuenta de socio en la que se creó el agente.	XYZ Mobile

Ejemplo de informe de eventos de facturación

Hay un archivo de informe de facturación de muestra disponible para descargar.

Tamaño de archivo típico

Un informe diario de un socio de RBM activo puede contener alrededor de 53,000 registros y tener un tamaño de aproximadamente 8 MB.

Registros de actividad

Los registros de actividad proporcionan datos sin procesar sobre la actividad en la plataforma de RBM. Puedes usar estos registros para auditar eventos de facturación y crear eventos personalizados.

Debido a que los registros de actividad contienen información de identificación personal (PII), como información detallada de transacciones y MSISDN de suscriptores, solo están disponibles cuando un operador opera RCS de conformidad con sus propias Condiciones del Servicio. Si tienes tráfico de RBM en tus redes y habilitas la actividad de RCS con Google RCS Cloud de conformidad con los Términos del Servicio de Google, no tendrás acceso a los registros de actividad.

Formato del registro de actividad

Los registros de actividad usan el formato de nombre de archivo rbm_activity_YYYY-MM-DD.csv. La fecha en el nombre del archivo es la fecha de generación del archivo.

Los campos de un registro están separados por tabulaciones y hay un registro por línea.

Cada registro del registro de actividades contiene los siguientes campos para cada actividad:

Campo	Formato	Descripción	Ejemplo
activity_id	string	Es el identificador único de la actividad.	b422e1d3-ac99-442a-853d-a875d5e61762
billing_event_id	string	Es el identificador único del evento de facturación asociado. Puede estar vacío si la actividad no está asociada con un evento de facturación, como un text_message sin el delivery_receipt_event correspondiente.	91yeb201-7c3b-412b-98d2-b0a0f7abe536
agent_id	string	Es el identificador único del agente.	[e-mail]
user_id	string	MSISDN del usuario	918369110173
direction	string	La dirección a la que se envía el mensaje: MT (terminación móvil) para actividades de agente a usuario MO (origen móvil) para actividades de usuario a agente	MT
time	YYYY-mm-ddTHH:MM:SS.SSSZ	Es la fecha y hora en que se envió el evento a la plataforma de RBM en formato UTC. Consulta Marcas de tiempo.	2019-07-25T00:29:07.033Z
type	string	Tipo de actividad: text_message file_transfer rich_card/carousel suggestion_tap delivery_receipt_event read_receipt_event spam_report	text_message
size_bytes	string	Es el tamaño de los archivos adjuntos a la actividad, en bytes.	912

Marcas de tiempo

Las marcas de tiempo de los registros de actividad registran cuándo se envió un evento a la plataforma de RBM. En el caso de los eventos que envían contenido a un usuario, el evento no se registrará en el registro de actividad hasta que se entregue el mensaje.

Por ejemplo, si se envía un mensaje de RBM a un usuario el miércoles a las 13:00 y el destinatario no tiene conexión hasta el domingo a las 9:00, el evento aparecerá en el registro de actividad generado para el domingo, pero la marca de tiempo será el miércoles a las 13:00.

Preguntas frecuentes

¿Qué es una conversación?

En la RBM, una conversación es una serie de mensajes que se intercambian entre un usuario y un agente conversacional durante un período de 24 horas. Solo los agentes con una categoría de facturación conversacional pueden generar conversaciones y se les cobrará por estos eventos de facturación:

• Conversación A2P: Es una conversación que inicia la marca.
• Conversación P2A: Es la conversación que inicia el usuario.

Cómo funcionan las conversaciones

• Inicio: Una conversación comienza cuando una de las partes (el agente o el usuario) responde a un mensaje de la otra parte en un plazo de 24 horas después de recibirlo, fuera de cualquier conversación existente.

  • Conversaci￳n A2P: Comienza cuando el usuario responde el mensaje del agente.
  • Conversaci￳n P2A: Comienza cuando el agente responde el mensaje del usuario.

• Período de la conversación: La conversación permanece activa durante 24 horas después de su inicio. La conversación incluye todos los mensajes de este período de 24 horas, así como el primer mensaje al que se respondió inicialmente.

• Facturación: En lugar de facturar por cada mensaje individual, los agentes conversacionales se facturan en función de toda la conversación. Esto significa que el costo se asocia con la conversación, no con la cantidad de mensajes que contiene.

Importante:

• Las conversaciones no se aplican a los agentes que no son de conversación. Los agentes con una categoría de facturación de mensaje básico o de mensaje único se facturan por mensaje, independientemente de si el usuario responde.

• En el caso de los agentes conversacionales, la generación de informes de eventos de facturación y registros de actividad puede retrasarse hasta dos días. Esta demora permite que la RBM capture todos los mensajes de una conversación antes de calcular el evento de facturación.