Cette page décrit les fichiers de données que RBM crée pour aider les opérateurs à effectuer la facturation et l'audit.
| Fichier | Description | Qui a accès |
|---|---|---|
| Rapport sur les événements de facturation | Rapport agrégé sur les événements facturables entre les agents lancés et les utilisateurs. | Tous les opérateurs disposant d'un MDA RBM signé |
| Journal d'activité | Journal des données brutes de l'activité RBM, y compris les événements facturables. | Opérateurs disposant d'un MDA RBM signé qui exploitent le service RCS de Google conformément à leurs propres conditions d'utilisation (CGU). |
Génération de fichiers
Chaque fichier de données représente un jour d'utilisation de RBM en temps universel coordonné (UTC). Les fichiers sont générés tous les jours entre 10h00 et 12h00 UTC.
Pour les agents non conversationnels, les fichiers contiennent les données de la période de 24 heures qui a immédiatement précédé la génération du fichier. Par exemple, si un rapport sur les événements de facturation est généré à 11h00 UTC le 5 mai, il contiendra les données du 4 mai à 11h00 UTC au 5 mai à 11h00 UTC.
Pour les agents conversationnels, les fichiers contiennent les données de la période de 24 heures précédant la génération du fichier, soit 1 à 2 jours. Par exemple, si un rapport sur les événements de facturation est généré à 11h UTC le 5 mai, il peut contenir des données du 3 mai à 11h UTC au 4 mai à 11h UTC.
Ce délai s'explique par le fait que l'activité RBM des agents conversationnels est liée aux conversations, qui peuvent prendre jusqu'à 48 heures. Ce délai permet à RBM de capturer tous les messages d'une conversation avant de calculer l'événement de facturation. Pour en savoir plus sur les agents conversationnels, consultez la section Catégories de facturation des agents.
Points essentiels :
Aucune activité: si aucune activité n'est enregistrée sur la plate-forme un jour donné, aucun fichier n'est généré.
Noms: la date indiquée dans le nom du fichier correspond à la date de génération du fichier, et non à la date des données qu'il contient.
Conservation: les fichiers sont stockés pendant 30 jours maximum avant d'être supprimés.
Vous pouvez utiliser ces fichiers pour mettre à jour votre entrepôt de données avec les dernières métriques d'utilisation de la plate-forme.
Stockage et accès aux fichiers
Les fichiers de données sont chiffrés au repos et en cours de transfert.
Pour récupérer des fichiers de données via SFTP, fournissez votre clé publique SFTP. Pour générer des clés, consultez Générer une paire de clés Secure Shell (SSH) pour une boîte de dépôt SFTP.
Le serveur SFTP est partnerupload.google.com, et la connexion se fait sur un numéro de port élevé (19321) pour plus de sécurité.
Vous pouvez utiliser la commande suivante pour accéder à vos fichiers de données:
sftp -i <path_to_private_key> -P 19321 <username>@partnerupload.google.com
Google fournit les noms d'utilisateur des comptes aux formats suivants:
rbmreports-billableevents-<carrier name>rbmreports-activity-<carrier name>
Google spécifie <carrier name> et fournit un compte distinct pour chaque type de rapport.
Des comptes distincts sont fournis pour accéder aux différents types de rapports.
Disponibilité des fichiers
Si aucun fichier de données n'a encore été généré, une erreur SFTP semblable à remote readdir("/"): No such file or directory s'affiche, ce qui est normal.
Aucun fichier n'est généré si aucun trafic RBM n'est à signaler. Par conséquent, il est possible qu'aucun fichier ne soit généré certains jours. Si vous avez besoin de fichiers vides pour simplifier votre processus, contactez rbm-support@google.com.
Rapports sur les événements de facturation
Les rapports sur les événements de facturation sont des enregistrements des événements de facturation, qui sont calculés en fonction de la catégorie de facturation de l'agent et du type de messages qu'il envoie. Les rapports sur les événements de facturation sont disponibles pour tous les opérateurs qui ont mis en place un MDA RBM.
Les rapports sur les événements de facturation contiennent des informations confidentielles, mais aucune information permettant d'identifier personnellement l'utilisateur, comme le MSISDN, le MSISDN haché ou tout autre identifiant unique de l'utilisateur.
Catégories de facturation des agents
Lors de la création d'un agent, le propriétaire définit sa catégorie de facturation en fonction de la manière dont l'agent interagira avec les utilisateurs. La catégorie de facturation ne limite pas le nombre ni le type de messages qu'un agent peut envoyer. Toutefois, il détermine la façon dont les messages seront facturés à l'agent. Les deux principales catégories de facturation sont décrites dans le tableau suivant.
| Catégorie de facturation | Type d'agent | Exemples de cas d'utilisation | Mode de facturation |
|---|---|---|---|
Non conversationnel (inclut les catégories "Message de base" et "Message unique"). Remarque: Il n'y a plus de différence entre ces deux catégories. Un agent appartenant à l'une ou l'autre de ces catégories sera facturé en tant qu'agent non conversationnel.) |
Agents qui envoient principalement des messages à sens unique. |
|
Facturation pour chaque message envoyé à l'utilisateur. |
| Je le parle avec une aisance moyenne me permettant de suivre une conversation | Agents conçus pour les échanges avec les utilisateurs. |
|
Facturation par conversation: si l'une des parties (l'agent ou l'utilisateur) répond à un message de l'autre partie dans les 24 heures, une conversation commence. Pendant la période de la conversation (24 heures après la première réponse), l'agent et l'utilisateur peuvent échanger un nombre illimité de messages. L'agent sera facturé à un tarif fixe pour la conversation. Facturation par message : si l'agent envoie un message auquel l'utilisateur ne répond pas dans les 24 heures, il sera facturé pour ce message individuel, comme un agent non conversationnel. |
Agents conversationnels et non conversationnels
Il existe deux catégories de facturation principales: conversationnelle et non conversationnelle. La catégorie "Non conversationnel" inclut les catégories "Message de base" et "Message unique", qui sont fonctionnellement identiques. Un agent appartenant à l'une de ces catégories est facturé comme un agent non conversationnel.
La principale différence entre les catégories de facturation concerne les agents conversationnels et non conversationnels:
Les agents non conversationnels sont facturés pour chaque message qu'ils envoient à l'utilisateur.
- Cette catégorie est idéale pour les agents qui ne s'attendent pas à des réponses fréquentes.
Les agents conversationnels sont facturés à un tarif fixe pour les conversations, qui incluent tous les messages échangés sur une période de 24 heures.
- Cette catégorie est idéale pour les agents qui engagent des conversations multitours avec les utilisateurs.
Événements de facturation
Cinq types d'événements de facturation différents sont enregistrés dans les rapports sur les événements de facturation. Ces événements incluent les messages A2P et P2A.
- A2P (Application-to-Person): envoyé par la marque.
- P2A (Person-to-Application): envoyé par l'utilisateur.
Le tableau suivant décrit chaque événement de facturation tel qu'il s'applique aux agents non conversationnels et conversationnels.
| Événement | Description | Agents non conversationnels | Agents conversationnels |
|---|---|---|---|
basic_message
|
Message A2P ne contenant que du texte de 160 caractères maximum. Si le texte inclut l'URL d'un site Web avec des balises openGraph, le message peut afficher un aperçu d'image, sans frais supplémentaires pour le partenaire. | Toujours traité comme un événement de facturation individuel, que l'utilisateur réponde ou non. | Traité comme un événement de facturation individuel, sauf si l'utilisateur répond dans les 24 heures. Dans ce cas, le message fait partie d'un a2p_conversation.
|
single_message
|
Message A2P incluant du contenu multimédia et/ou un texte de plus de 160 caractères. | Toujours traité comme un événement de facturation individuel, que l'utilisateur réponde ou non. | Traité comme un événement de facturation individuel, sauf si l'utilisateur répond dans les 24 heures. Dans ce cas, le message fait partie d'un a2p_conversation.
|
a2p_conversation (créé par la marque)
|
Déclenché lorsqu'un utilisateur répond à un message A2P dans les 24 heures suivant sa réception, en dehors d'une conversation existante. | N/A. Les agents non conversationnels ne génèrent jamais ce type d'événement. | Si un message P2A est envoyé dans les 24 heures suivant plusieurs messages A2P, seul le message A2P qui a immédiatement précédé le message P2A est utilisé pour lancer la conversation. Ce message A2P et tous les messages envoyés au cours des 24 prochaines heures font partie de l'a2p_conversation.
|
p2a_conversation (déclenché par l'utilisateur)
|
Déclenchée lorsqu'un agent répond à un message P2A dans les 24 heures suivant sa réception, en dehors d'une conversation existante. | N/A. Les agents non conversationnels ne génèrent jamais ce type d'événement. | Si un message A2P est envoyé dans les 24 heures suivant plusieurs messages P2A, seul le message P2A qui a immédiatement précédé le message A2P est utilisé pour lancer la conversation. Ce message P2A et tous les messages envoyés au cours des 24 prochaines heures font partie de l'p2a_conversation.
|
p2a_message
|
Message P2A de n'importe quel type. | Toujours traité comme un événement de facturation individuel, que l'agent réponde ou non. | Il est traité comme un événement de facturation individuel, sauf si l'agent répond dans les 24 heures. |
Événements de facturation par rapport aux catégories de facturation
Les événements de facturation basic_message et single_message ne doivent pas être confondus avec les catégories de facturation "Message de base" et "Message unique".
N'importe quel agent (quelle que soit sa catégorie de facturation) peut générer des événements de facturation
basic_messageetsingle_message.Les catégories de facturation "Message de base" et "Message unique" permettent de classer les agents non conversationnels. Les agents de ces catégories de facturation ne génèrent pas d'événements de facturation par conversation (
a2p_conversationsoup2a_conversations). Ils génèrent plutôt des événements de facturationbasic_message,single_messageetp2a_messageindividuels.
Génération de rapports sur la facturation
Seuls les agents dont le trafic n'est pas généré par des testeurs génèrent des événements de facturation. L'activité des numéros de téléphone de test n'apparaît pas dans les rapports sur les événements de facturation.
Ces rapports supposent que les événements sont facturés lorsque les messages sont distribués, et non lorsqu'ils sont envoyés. Un message non distribué ou un message annulé avant la distribution ne déclenche pas d'événement de facturation.
Format du rapport de facturation
Les rapports sur les événements de facturation utilisent le format de nom de fichier rbm_billable_events_YYYY-MM-DD.csv. La date indiquée dans le nom du fichier correspond à la date de génération du fichier.
Chaque ligne du rapport est un enregistrement représentant un événement de facturation unique. Les champs d'un enregistrement sont séparés par une tabulation. Par exemple, deux conversations A2P avec le même agent génèrent deux événements de facturation et deux enregistrements dans le rapport sur les événements de facturation.
Chaque enregistrement du rapport contient les informations suivantes pour chaque événement de facturation:
| Champ | Format | Description | Exemple |
|---|---|---|---|
billing_event_id
|
chaîne | Identifiant UUID. Nombre aléatoire généré pour chaque nouvel événement au moment de sa création. | 242f1d9f-7c3f-4e5b-ab3f-818f188fa3ff
|
type
|
chaîne | Type d'événement :
|
single_message
|
agent_id
|
chaîne | Identifiant unique de l'agent ayant participé à l'événement. | rbm-welcome-bot@rbm.goog
|
agent_owner
|
chaîne | Adresse e-mail du titulaire actuel du compte partenaire dans lequel l'agent a été créé. | name@aggregator.com
|
billing_party
|
chaîne | Partie qui facture les événements.
|
carrier
|
max_duration_single_message
|
Nombre | Durée maximale (en heures) pendant laquelle un utilisateur peut répondre à un message d'agent avant que la fenêtre d'initiation de la conversation ne se ferme et que le message ne soit classé comme événement single_message.
|
24
|
max_duration_a2p_conversation
|
Nombre | Durée maximale d'une conversation A2P, en heures. Mesuré à partir de la première réponse de l'utilisateur au message initial de l'agent. | 24
|
max_duration_p2a_conversation
|
Nombre | Durée maximale d'une conversation P2A, en heures. Mesuré à partir du premier message de l'utilisateur dans la conversation. | 24
|
start_time
|
YYYY-mm-ddTHH:00:00Z | Date/heure UTC de début de l'événement au format ISO 8601 arrondie à l'heure la plus proche.
|
2019-07-25T08:00:00Z
|
duration
|
Nombre | Durée de l'événement, arrondie à la minute la plus proche.
Lorsque le type d'événement est |
45
|
mt_messages
|
Nombre | Nombre de messages A2P (terminés sur mobile) dans l'événement. | 11
|
mo_messages
|
Nombre | Nombre de messages envoyés depuis un mobile (P2A) dans l'événement. | 9
|
size_kilobytes
|
Nombre | Taille de tous les fichiers joints aux messages de l'événement, arrondie au kilo-octet le plus proche (1 ko = 1 024 octets). | 912
|
agent_name
|
chaîne |
Nom de l'agent ayant participé à l'événement. |
XYZ Mobile USA
|
owner_name
|
chaîne | Nom du titulaire actuel du compte partenaire dans lequel l'agent a été créé. | XYZ Mobile
|
Exemple de rapport sur les événements de facturation
Vous pouvez télécharger un exemple de fichier de rapport de facturation.
Taille de fichier type
Un rapport quotidien d'un partenaire RBM actif peut contenir environ 53 000 enregistrements et mesurer environ 8 Mo.
Journaux d'activité
Les journaux d'activité fournissent des données brutes sur l'activité sur la plate-forme RBM. Vous pouvez utiliser ces journaux pour auditer les événements de facturation et créer des événements personnalisés.
Étant donné que les journaux d'activité contiennent des informations permettant d'identifier personnellement les utilisateurs (PII), telles que des informations détaillées sur les transactions et les MSISDN des abonnés, ils ne sont disponibles que lorsqu'un opérateur gère le RCS conformément à ses propres conditions d'utilisation. Si vous avez du trafic RBM sur vos réseaux et que vous activez l'activité RCS avec Google RCS Cloud conformément aux conditions d'utilisation de Google, vous n'aurez pas accès aux journaux d'activité.
Format du journal d'activité
Les journaux d'activité utilisent le format de nom de fichier rbm_activity_YYYY-MM-DD.csv. La date du nom de fichier correspond à la date de génération du fichier.
Les champs d'un enregistrement sont séparés par une tabulation, et un enregistrement correspond à une ligne.
Chaque enregistrement du journal d'activité contient les champs suivants pour chaque activité:
| Champ | Format | Description | Exemple |
|---|---|---|---|
activity_id
|
chaîne | Identifiant unique de l'activité. | b422e1d3-ac99-442a-853d-a875d5e61762
|
billing_event_id
|
chaîne | Identifiant unique de l'événement de facturation associé. Peut être vide si l'activité n'est pas associée à un événement de facturation, par exemple un text_message sans delivery_receipt_event correspondant.
|
91yeb201-7c3b-412b-98d2-b0a0f7abe536
|
agent_id
|
chaîne | Identifiant unique de l'agent. | welcome-bot@rbm.goog
|
user_id
|
chaîne | MSISDN de l'utilisateur. | 918369110173
|
direction
|
chaîne | Direction du message:
|
MT
|
time
|
YYYY-mm-ddTHH:MM:SS.SSSZ | Date et heure d'envoi de l'événement à la plate-forme RBM au format UTC. Consultez la section Codes temporels. | 2019-07-25T00:29:07.033Z
|
type
|
chaîne | Type d'activité:
|
text_message
|
size_bytes
|
chaîne | Taille des fichiers joints à l'activité, en octets. | 912
|
Codes temporels
Les codes temporels des journaux d'activité indiquent quand un événement a été envoyé à la plate-forme RBM. Pour les événements qui transmettent du contenu à un utilisateur, l'événement n'est pas enregistré dans le journal d'activité tant que le message n'a pas été envoyé.
Par exemple, si un message RBM est envoyé à un utilisateur le mercredi à 13h et que le destinataire est hors connexion jusqu'au dimanche à 9h, l'événement apparaîtra dans le journal d'activité généré pour le dimanche, mais le code temporel sera le mercredi 13h.
Questions fréquentes
Qu'est-ce qu'une conversation ?
Dans RBM, une conversation est une série de messages échangés entre un utilisateur et un agent conversationnel sur une période de 24 heures. Seuls les agents disposant d'une catégorie de facturation "Conversational" peuvent générer des conversations et être facturés pour ces événements de facturation:
- Conversation A2P: conversation initiée par la marque.
- Conversation P2A: conversation initiée par l'utilisateur.
Fonctionnement des conversations
Début: une conversation commence lorsqu'une partie (l'agent ou l'utilisateur) répond à un message de l'autre partie dans les 24 heures suivant sa réception, en dehors de toute conversation existante.
- Conversation A2P: commence lorsque l'utilisateur répond au message de l'agent.
- Conversation P2A: commence lorsque l'agent répond au message de l'utilisateur.
Fenêtre de conversation: la conversation reste active pendant 24 heures après son début. La conversation inclut tous les messages de cette période de 24 heures, ainsi que le tout premier message auquel vous avez répondu.
Facturation: au lieu de facturer chaque message individuellement, les agents conversationnels sont facturés en fonction de l'ensemble de la conversation. Cela signifie que le coût est associé au fil de discussion, et non au nombre de messages qu'il contient.
Important :
Les conversations ne s'appliquent pas aux agents non conversationnels. Les agents dont la catégorie de facturation est "Message de base" ou "Message unique" sont facturés par message, que l'utilisateur réponde ou non.
Pour les agents conversationnels, la génération de rapports sur les événements de facturation et des journaux d'activité peut être retardée de deux jours maximum. Ce délai permet à RBM de capturer tous les messages d'une conversation avant de calculer l'événement de facturation.