RBM crée des fichiers de données qui signalent l'activité des utilisateurs et des agents sur les données récapitulatives et aux niveaux transactionnels. Les données sont réparties dans plusieurs fichiers:
| Fichier | Description | Qui a 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 dont les réseaux assurent du trafic RBM |
| Journal d'activité | Données d'activité brutes de la plate-forme RBM | Opérateurs qui enregistrent du trafic RBM sur leurs réseaux et qui activent l'activité RCS avec Jibe Cloud selon ses propres conditions d'utilisation |
Génération
Les rapports sur les événements de facturation et les journaux d'activité ont un délai de deux jours pour être générés.
Google signale un événement d'activité uniquement lorsque la session de facturation à laquelle il appartient est terminé. Une session peut prendre jusqu'à 24 heures. Notre système de facturation s'exécute une fois par jour et ne signale que les sessions de facturation terminés (ils ont donc au moins 24 heures).
Exemple :
Un message est envoyé le d et démarre une session de facturation, mais il n'a manqué l'exécution du pipeline une heure plus tôt. Par conséquent, aucun événement d'activité n'est signalées.
Lorsque le pipeline s'exécute à nouveau le d+1, la session initiée par le message est il n'y a que 23 heures. Par conséquent, aucun événement d'activité n'a été signalé pour ce message. sur d+1.
Lorsque le pipeline s'exécute à nouveau sur d+2, la session est terminée. Par conséquent, l'événement d'activité est consigné avec la session de facturation.
Stockage et accès
Les fichiers de données sont chiffrés au repos et pendant leur transfert.
Pour récupérer des fichiers de données via SFTP, vous devez fournir votre clé publique SFTP. À générer des clés, consultez Générer une paire de clés Secure Shell (SSH) pour un serveur SFTP compte "Envoi sécurisé".
Le serveur SFTP est partnerupload.google.com et la connexion utilise un
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 aux formats suivants:
rbmreports-billableevents-<carrier name>rbmreports-activity-<carrier name>
Google spécifie <carrier name> et fournit un compte distinct pour chaque rapport
de mots clés.
Les différents types de rapports sont accessibles via des comptes distincts.
Disponibilité des fichiers
Si aucun fichier de rapport n'a encore été généré, une erreur SFTP s'affiche.
semblable à remote readdir("/"): No such file or directory. Ce comportement est normal.
Aucun fichier ne sera généré s'il n'y a pas de trafic RBM à signaler. Cela signifie il peut arriver qu'aucun fichier ne soit généré. Contact à l'adresse rbm-support@google.com si vous des fichiers vides doivent être générés dans cette situation pour simplifier votre en cours de traitement.
Actualiser et conserver
Chaque fichier de données représente un jour d'utilisation de la plate-forme dans le fuseau horaire UTC. Enregistrements d'un pour un jour donné sont générées une fois et finalisées dans les 2 jours (48 heures) et la journée se termine. 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é s'il n'y a pas 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é. La les enregistrements du fichier couvrent le jour UTC qui arrive deux jours avant le fichier la date de début.
Le processus d'exportation des fichiers s'exécute entre 2 h et 4 h 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 données sous-jacentes messages en utilisant les 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, identifiant unique de l'utilisateur).
Seuls les agents lancés génèrent des événements de facturation. Activité à lancer pour le moment ou non lancés n'apparaissent pas dans les rapports de facturation.
Les rapports de facturation supposent que les événements sont facturés lors de la distribution des messages, et non lors de l'envoi des messages. Message non distribué ou révoqué avant distribution ne déclenche pas d'événement de facturation.
Chaque agent RBM possède une catégorie de facturation. défini par le développeur de l'agent avant de le soumettre au lancement. L'onglet "Facturation" La catégorie détermine si les messages envoyés par l'agent sont discrètes ou qu'elles puissent être combinées dans des événements de facturation conversationnels.
Il existe cinq types d'événements facturables:
| Événement | Définition |
|---|---|
| Message de base | Un message A2P (application à personne)
Agents conversationnels uniquement: si un message P2A est distribué en tant qu'agent à un message A2P dans les 24 heures, le message de base fait partie d'une conversation A2P ; sinon la session prend fin. A Un message basique est toujours distribué à un utilisateur par un agent. |
| Message unique | Un message A2P (application à personne)
Agents conversationnels uniquement: si un message P2A est distribué dans le Dans les 24 heures suivantes, le message unique est intégré à une conversation A2P. sinon la session prend fin. Un seul message est toujours distribué d'un agent à un utilisateur. |
| Conversation A2P | S'applique uniquement aux agents conversationnels: une conversation A2P est lorsqu'un message P2A est distribué dans les 24 heures Message ou message standard A2P. Notez que si un message P2A est distribué dans 24 heures pour plusieurs messages A2P, uniquement le message A2P qui qui précède le message P2A est utilisé pour créer la session de conversation. Ce A2P Message, ainsi que tous les messages distribués au cours des prochaines 24 heures, font partie de la nouvelle conversation A2P. |
| Conversation P2A | S'applique uniquement aux agents conversationnels: une conversation P2A est lancée alors qu'il n'y a pas de session active (message unique A2P, conversation (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 appartenant à une catégorie de facturation
un message unique ou
un message de base.
Agents conversationnels: message P2A envoyé par un utilisateur vers qu'il n'existe aucune conversation et que l'agent n'a pas renvoyer une réponse. |
Disponibilité
Les rapports sur les événements de facturation sont disponibles pour tous les opérateurs dont le trafic RBM est activé. 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 dans le nom du fichier correspond à la date à laquelle le fichier a été généré. Les enregistrements en le fichier couvre généralement l'activité correspondant à deux jours avant la date de génération.
Les champs d'un enregistrement sont séparés par des tabulations et il y a un enregistrement par ligne.
Il y a un enregistrement pour chaque événement de facturation. Par exemple, deux API A2P les conversations avec le même agent génèrent deux événements de facturation et deux dans le rapport sur la 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 | L'identifiant UUID, un nombre aléatoire, généré pour chaque nouvel événement au niveau à sa création. | |
type
|
chaîne | Type d'événement:
<ph type="x-smartling-placeholder">
|
single_message
|
agent_id
|
chaîne | Identifiant de l'agent qui a participé à l'événement. | rbm-welcome-bot@rbm.goog
|
agent_owner
|
chaîne | L'adresse e-mail du propriétaire actuel du compte partenaire auquel a été créé. Cette valeur provient du "compte Google RBM" champ fourni lorsque le partenaire s'est inscrit pour utiliser RBM. | name@aggregator.com
|
billing_party
|
chaîne | La partie qui facture les événements.
|
carrier
|
max_duration_single_message
|
Nombre | Durée, en heures, avant qu'un message d'un agent ne reçoive une pour identifier une session de message unique. | 24
|
max_duration_a2p_conversation
|
Nombre | Durée maximale d'une session A2P, en heures. Mesuré à partir de la première au message initial de l'agent. | 24
|
max_duration_p2a_conversation
|
Nombre | Durée maximale d'une session P2A, en heures. Mesuré à partir de la première 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 au
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 dont l'arrêt mobile a été interrompu dans l'événement. | 11
|
mo_messages
|
Nombre | Nombre de messages d'origine mobile dans l'événement. | 9
|
size_kilobytes
|
Nombre | Taille de tous les fichiers joints aux messages dans l'événement, arrondie au le kilo-octet le plus proche (1 Ko = 1 024 octets). | 912
|
agent_name
|
chaîne |
Agent ayant participé à l'événement. |
XYZ Mobile USA
|
owner_name
|
chaîne | L'adresse e-mail du propriétaire actuel du compte partenaire auquel a été créé. Cette valeur provient du "compte Google RBM" champ fourni lorsque le partenaire s'est inscrit pour utiliser RBM. | XYZ Mobile
|
Exemple de fichier
Vous pouvez télécharger un exemple de rapport de facturation.
Taille de fichier standard
Un rapport quotidien d'un partenaire actif peut contenir environ 53 000 enregistrements et d'environ 8 Mo.
Journaux d'activité
Les journaux d'activité sont les journaux de données brutes concernant l'activité sur la plate-forme RBM pour la pour auditer les événements facturables et créer des événements personnalisés.
Disponibilité
Les journaux d'activité ne sont disponibles que pour les opérateurs dont le trafic est RBM réseaux sociaux et à activer l'activité RCS avec Jibe Cloud selon leurs propres conditions d'utilisation Service (Conditions d'utilisation). Si vous utilisez Jibe Cloud conformément aux conditions d'utilisation de Jibe, vous n'aurez pas accès à les 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 indiquée dans le nom du fichier correspond à la date à laquelle le fichier a été généré. Les enregistrements en le fichier couvre généralement l'activité de la veille la date de début.
Les champs d'un enregistrement sont séparés par des tabulations et il y a un enregistrement par ligne.
Chaque enregistrement du journal d'activité contient les champs suivants pour chaque 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, un text_message sans delivery_receipt_event correspondant).
|
|
agent_id
|
chaîne | Identifiant de l'agent. | welcome-bot@rbm.goog
|
user_id
|
chaîne | MSISDN de l'utilisateur. | 918369110173
|
direction
|
chaîne | Le sens d'envoi du message:
|
MT
|
time
|
YYYY-mm-ddTHH:MM:SS.SSSZ | Date et heure UTC auxquelles l'événement a été envoyé à la plate-forme RBM. Voir la remarque. | 2019-07-25T00:29:07.033Z
|
type
|
chaîne | Type d'activité:
|
text_message
|
size_bytes
|
chaîne | Taille des fichiers associés à l'activité, en octets. | 912
|
Remarque concernant les codes temporels
Les codes temporels des journaux d'activité enregistrent l'heure à laquelle un événement a été envoyé la plateforme RBM. Pour les événements qui envoient du contenu à un utilisateur, écrit dans le journal d'activité jusqu'à ce que le message ait été distribué.
Par exemple, si un message RBM est envoyé à un utilisateur le mercredi à 13 h 00 et que destinataire est hors connexion jusqu'à dimanche 09 h 00, il apparaîtra dans la section Journal d'activité généré pour dimanche. Le code temporel de l'événement dans l'objet Activity est mercredi à 13 h 00.