RBM crée des fichiers de données qui enregistrent l'activité des utilisateurs et des agents au niveau récapitulatif et transactionnel. Les données sont réparties dans plusieurs fichiers:
| File | Description | Autorisations d'accès |
|---|---|---|
| Rapport sur les événements de facturation | Enregistrement des événements facturables entre les agents lancés et les utilisateurs | Tous les opérateurs qui ont du trafic RBM sur leurs réseaux |
| Journal d'activité | Données d'activité brutes de la plate-forme RBM | Opérateurs qui ont du trafic RBM sur leurs réseaux et activent l'activité RCS avec Jibe Cloud selon leurs propres conditions d'utilisation |
Génération
Un délai de deux jours est nécessaire pour générer les rapports sur les événements de facturation et les journaux d'activité.
Google ne signale un événement d'activité que lorsque la session de facturation à laquelle il appartient est terminée. Une session peut prendre jusqu'à 24 heures. Notre pipeline de facturation s'exécute une fois par jour et n'enregistre que les sessions de facturation qui sont sûres (qui datent d'au moins 24 heures).
Exemple :
Un message est envoyé le d et lance une session de facturation, mais l'exécution du pipeline a été manquée une heure plus tôt. Par conséquent, aucun événement d'activité n'est signalé.
Lorsque le pipeline s'exécute à nouveau le d+1, la session lancée par le message date de seulement 23 heures. Par conséquent, aucun événement d'activité pour ce message n'est signalé le d+1.
Lorsque le pipeline s'exécute à nouveau le d+2, la session est terminée. L'événement d'activité est donc signalé avec la session de facturation.
Stockage et accès
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, vous devez fournir votre clé publique SFTP. Pour générer des clés, consultez l'article 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 est établie 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 de compte dans les 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 disponibles pour accéder aux différents types de rapports.
Disponibilité des fichiers
Si aucun fichier de rapport n'a encore été généré, une erreur SFTP semblable à celle de remote readdir("/"): No such file or directory s'affiche. Ce comportement est normal.
Aucun fichier ne sera généré s'il n'y a pas de trafic RBM à signaler. Cela signifie qu'il peut s'écouler certains jours avant que les fichiers ne soient générés. Contactez rbm-support@google.com si vous souhaitez que des fichiers vides soient générés dans ce cas afin de simplifier le traitement.
Actualiser et conserver les données
Chaque fichier de données représente une journée d'utilisation de la plate-forme en temps UTC. Les enregistrements d'un jour donné sont générés une fois et finalisés dans les deux jours (48 heures) après la fin de la journée. Si vous chargez ces fichiers dans un entrepôt de données, vous pouvez mettre à jour les métriques du mois en cours.
Un fichier n'est pas généré en l'absence d'activité à prendre en compte.
La date figurant dans le nom de chaque fichier correspond à la date à laquelle le fichier a été généré. Les enregistrements du fichier couvrent le jour UTC deux jours avant la date du fichier.
Le processus d'exportation qui génère les fichiers s'exécute entre 2h et 4h PST.
Les fichiers de données sont conservés pendant 30 jours au maximum avant d'être supprimés.
Rapports sur les événements de facturation
Les rapports sur les événements de facturation sont des enregistrements d'événements facturables calculés à partir des messages sous-jacents à l'aide des unités de facturation suggérées. Les événements facturables contiennent des informations confidentielles, mais pas d'informations permettant d'identifier personnellement l'utilisateur (par exemple, pas de MSISDN, de MSISDN haché ou d'identifiant unique d'utilisateur).
Seuls les agents lancés génèrent des événements de facturation. L'activité à lancer ou les agents non lancés n'apparaissent pas dans les rapports sur la facturation.
Les rapports de facturation supposent que les événements sont facturés à la livraison des messages, et non à leur envoi. Un message non distribué ou révoqué avant la distribution ne déclenche pas d'événement de facturation.
Chaque agent RBM possède une catégorie de facturation, définie par le développeur de l'agent avant son lancement. La catégorie de facturation détermine si les messages envoyés par l'agent sont discrets ou s'ils peuvent être combinés dans des événements de facturation conversationnelle.
Il existe cinq types d'événements facturables:
| Événement | Définition |
|---|---|
| Message de base | Un message A2P (application-to-person) qui
Agents conversationnels uniquement: si un message P2A est distribué en tant que réponse à un message A2P dans les prochaines 24 heures, le message de base fait partie d'une conversation A2P. Sinon, la session se termine. Un agent transmet toujours un message de base à un utilisateur. |
| Message unique | Un message A2P (application-to-person) qui
Agents conversationnels uniquement: si un message P2A est distribué dans les 24 heures suivantes, le message unique fait partie d'une conversation A2P. Sinon, la session se termine. Un agent envoie toujours un message unique à un utilisateur. |
| Conversation A2P | S'applique uniquement aux agents conversationnels: une conversation A2P est lancée lorsqu'un message P2A est distribué dans les 24 heures suivant un message unique A2P ou un message de base A2P. Notez que si un message P2A est distribué dans les 24 heures suivant plusieurs messages A2P, seul le message A2P qui précède immédiatement le message P2A est utilisé pour créer la session de conversation. Ce message A2P, ainsi que tous les messages distribués dans les prochaines 24 heures, font partie de la nouvelle conversation A2P. |
| Conversation P2A | S'applique uniquement aux agents conversationnels: une conversation P2A est lancée en l'absence de session active (message unique A2P, conversation A2P ou conversation P2A), et qu'un message P2A est distribué et que l'établissement répond dans les 24 heures. |
| Message P2A | Agents non conversationnels: message P2A envoyé par un utilisateur vers un agent dont la catégorie de facturation est "Message unique" ou "Message de base".
Agents conversationnels: message P2A envoyé par un utilisateur vers un agent pour lequel il n'existe pas de conversation existante et où l'agent ne renvoie pas de réponse. |
Garantie de disponibilité
Les rapports sur les événements de facturation sont disponibles pour tous les opérateurs qui enregistrent du trafic RBM sur leurs réseaux.
Format
Les rapports sur les événements de facturation utilisent le format de nom de fichier YYYY/MM/DD/rbm_billable_events_YYYY-MM-DD.csv.
La date figurant dans le nom du fichier correspond à la date à laquelle le fichier a été généré. Les enregistrements du fichier couvrent généralement l'activité de deux jours avant cette date.
Les champs d'un enregistrement sont séparés par une tabulation. Il existe un enregistrement par ligne.
Il y aura un enregistrement pour chaque événement de facturation. Autrement dit, deux conversations A2P avec le même agent généreront deux événements de facturation et deux enregistrements dans le rapport de facturation.
Chaque enregistrement du rapport sur les événements facturables contient les informations suivantes pour chaque événement:
| Champ | Format | Description | Exemple |
|---|---|---|---|
billing_event_id
|
chaîne | Identifiant UUID, à savoir un nombre aléatoire, généré pour chaque nouvel événement au moment de sa création. | |
type
|
chaîne | Type d'événement :
|
single_message
|
agent_id
|
chaîne | Identifiant de l'agent ayant participé à l'événement. | rbm-welcome-bot@rbm.goog
|
agent_owner
|
chaîne | Adresse e-mail du propriétaire de l'agent ayant participé à l'événement. Il s'agit de la partie qui a enregistré l'agent RBM (dans la plupart des cas, l'agrégateur, mais dans de rares cas, il peut s'agir de la marque). Cette valeur provient du champ "Compte Google RBM" fourni lorsque le développeur s'est inscrit pour utiliser RBM. | name@aggregator.com
|
billing_party
|
chaîne | Partie qui facture les événements.
|
carrier
|
max_duration_single_message
|
number | Durée, en heures, avant qu'un message d'un agent ne reçoive de réponse permettant d'identifier une seule session de messages. | 24
|
max_duration_a2p_conversation
|
number | Durée maximale d'une session A2P, en heures. Mesurée depuis la première réponse de l'utilisateur jusqu'au message initial de l'agent. | 24
|
max_duration_p2a_conversation
|
number | Durée maximale d'une session P2A, en heures. Mesurée à partir du premier message utilisateur de la conversation. | 24
|
start_time
|
YYYY-mm-ddTHH:00:00Z | Date et 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
|
number | Durée de l'événement, arrondie à la minute la plus proche.
Si le type d'événement est |
45
|
mt_messages
|
number | Nombre de messages de l'événement clôturés sur mobile. | 11
|
mo_messages
|
number | Nombre de messages envoyés depuis un mobile dans l'événement. | 9
|
size_kilobytes
|
number | 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 |
Agent qui a participé à l'événement. |
XYZ Mobile USA
|
owner_name
|
chaîne | Propriétaire de l'agent ayant participé à l'événement. Il s'agit de la partie qui a enregistré l'agent RBM. Dans la plupart des cas, il s'agit de l'agrégateur. Dans de rares cas, il peut s'agir de la marque. Cette valeur est issue du "Nom à afficher préféré pour votre compte partenaire" fourni lorsque le développeur s'est inscrit pour utiliser RBM. | XYZ Mobile
|
Exemple de fichier
Vous pouvez télécharger un exemple de fichier de rapport de facturation.
Taille de fichier habituelle
Un fichier de rapport quotidien provenant d'un partenaire actif peut contenir environ 53 000 enregistrements et une taille d'environ 8 Mo.
Journaux d'activité
Les journaux d'activité sont les journaux de données bruts de l'activité sur la plate-forme RBM. Ils permettent d'auditer les événements facturables et de créer des événements personnalisés.
Garantie de disponibilité
Les journaux d'activité ne sont disponibles que pour les opérateurs qui ont du trafic RBM sur leurs réseaux et qui activent l'activité RCS avec Jibe Cloud selon leurs propres conditions d'utilisation. Si vous utilisez Jibe Cloud conformément aux conditions d'utilisation de Jibe, vous n'aurez pas accès aux journaux d'activité.
Format
Les journaux d'activité utilisent le format de nom de fichier YYYY/MM/DD/rbm_activity_YYYY-MM-DD.csv.
La date figurant dans le nom du fichier correspond à la date à laquelle le fichier a été généré. Les enregistrements du fichier couvrent généralement l'activité de deux jours avant cette date.
Les champs d'un enregistrement sont séparés par une tabulation. Il existe un enregistrement par ligne.
Chaque enregistrement du journal d'activité contient les champs suivants pour chaque événement d'activité.
| Champ | Format | Description | Exemple |
|---|---|---|---|
activity_id
|
chaîne | Identifiant de l'activité. | |
billing_event_id
|
chaîne | Identifiant de l'événement de facturation dans lequel l'activité a eu lieu. Ce champ peut être vide si l'activité n'est associée à aucune session (par exemple, text_message sans delivery_receipt_event correspondant).
| |
agent_id
|
chaîne | Identifiant de l'agent. | welcome-bot@rbm.goog
|
user_id
|
chaîne | Fichier MSISDN de l'utilisateur. | 918369110173
|
direction
|
chaîne | Direction d'envoi du message:
|
MT
|
time
|
YYYY-mm-ddTHH:MM:SS.SSSZ | Date/heure UTC de soumission de l'événement à la plate-forme RBM. Voir la remarque ci-dessous. | 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
|
Remarque sur les codes temporels
Les horodatages des journaux d'activité enregistrent l'heure à laquelle un événement a été envoyé à la plate-forme RBM. Les événements qui fournissent du contenu à un utilisateur ne sont pas écrits dans le journal d'activité tant que le message n'a pas été distribué.
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. L'horodatage de l'événement dans le journal d'activité sera le mercredi 13h.