Auf dieser Seite werden die Datendateien beschrieben, die von RBM erstellt werden, um Mobilfunkanbieter bei der Abrechnung und Prüfung zu unterstützen. In den häufig gestellten Fragen zur RBM-Abrechnung finden Sie Antworten auf häufige Fragen zum RBM-Abrechnungsmodell.
| Datei | Beschreibung | Wer hat Zugriff? |
|---|---|---|
| Bericht zu Abrechnungsereignissen | Zusammengefasster Bericht zu abrechenbaren Ereignissen zwischen eingeführten Agents und Nutzern. | Alle Mobilfunkanbieter, die RBM (RCS Business Messaging) aktiv nutzen. |
| Aktivitätsprotokoll | Rohdatenprotokoll der RBM-Aktivität, einschließlich abrechenbarer Ereignisse. | Mobilfunkanbieter, die RBM (RCS Business Messaging) aktiv betreiben und den Google RCS-Dienst gemäß ihren eigenen Nutzungsbedingungen betreiben. |
Dateigenerierung
Jede Datei enthält Daten zur RBM-Nutzung an einem Tag in koordinierter Weltzeit (UTC). Dateien werden täglich generiert. Die Generierung kann mehrere Stunden dauern. Die Dauer kann variieren.
Bei nicht konversationellen Agents enthalten die Dateien Daten aus dem 24-Stunden-Zeitraum, der unmittelbar vor dem Zeitpunkt der Dateigenerierung lag. Wenn beispielsweise am 5. Mai um 11:00 Uhr (UTC) ein Abrechnungsereignisbericht generiert wird, enthält er Daten vom 4. Mai um 11:00 Uhr (UTC) bis zum 5. Mai um 11:00 Uhr (UTC).
Bei konversationellen Agents enthalten die Dateien Daten aus dem 24-Stunden-Zeitraum, der ein bis zwei Tage vor dem Zeitpunkt der Dateigenerierung liegt. Wenn beispielsweise am 5. Mai um 11:00 Uhr UTC ein Abrechnungsereignisbericht generiert wird, enthält er möglicherweise Daten vom 3. Mai um 11:00 Uhr UTC bis zum 4. Mai um 11:00 Uhr UTC.
Der Grund für die Verzögerung ist, dass RBM-Aktivitäten für Conversational Agents mit Unterhaltungen verknüpft sind, deren Abschluss bis zu 48 Stunden dauern kann. Durch diese Verzögerung kann RBM alle Nachrichten in einer Unterhaltung erfassen, bevor das Abrechnungsereignis berechnet wird. Weitere Informationen zu Konversations-Agents finden Sie unter Abrechnungskategorien für Agents.
Wichtige Punkte:
Keine Aktivität: Wenn es an einem bestimmten Tag keine Plattformaktivität gibt, wird keine Datei generiert.
Benennung: Das Datum im Dateinamen ist das Datum der Dateigenerierung, nicht das Datum der Daten in der Datei.
Aufbewahrung: Dateien werden maximal 63 Tage lang gespeichert, bevor sie gelöscht werden.
Mit diesen Dateien können Sie Ihr Data Warehouse mit den neuesten Messwerten zur Plattformnutzung aktualisieren.
Dateispeicher und ‑zugriff
Datendateien werden im Ruhezustand und bei der Übertragung verschlüsselt.
Wenn Sie Datendateien per Secure File Transfer Protocol (SFTP) abrufen möchten, geben Sie Ihren öffentlichen SFTP-Schlüssel an. Informationen zum Generieren von Schlüsseln finden Sie unter SSH-Schlüsselpaar (Secure Shell) für SFTP-Dropbox generieren.
Der SFTP-Server ist partnerupload.google.com. Die Verbindung erfolgt über einen hohen Port (19321), um die Sicherheit zu erhöhen.
Mit dem folgenden Befehl können Sie auf Ihre Datendateien zugreifen:
sftp -i <path_to_private_key> -P 19321 <username>@partnerupload.google.com
Google stellt Nutzernamen in den folgenden Formaten bereit:
rbmreports-billableevents-<carrier name>rbmreports-activity-<carrier name>
Google gibt <carrier name> an und stellt für jeden Berichtstyp ein separates Konto zur Verfügung.
Für den Zugriff auf die verschiedenen Berichtstypen sind separate Konten erforderlich.
Dateiverfügbarkeit
Wenn noch keine Datendateien generiert wurden, wird ein SFTP-Fehler ähnlich wie remote readdir("/"): No such file or directory angezeigt. Das ist normal.
Eine Datei wird nicht generiert, wenn keine RBM-Zugriffsdaten für Berichte vorhanden sind. Das bedeutet, dass an einigen Tagen möglicherweise keine Dateien generiert werden. Wenn Sie leere Dateien benötigen, um Ihren Prozess zu optimieren, wenden Sie sich an rbm-support@google.com.
Berichte zu Abrechnungsereignissen
Abrechnungsereignisberichte sind Aufzeichnungen von Abrechnungsereignissen, die auf Grundlage der Abrechnungskategorie des Agenten und des Typs der gesendeten Nachrichten berechnet werden. Berichte zu Abrechnungsereignissen sind für alle Mobilfunkanbieter verfügbar, die RBM (RCS Business Messaging) aktiv nutzen.
Berichte zu Abrechnungsereignissen enthalten vertrauliche Informationen, aber keine personenidentifizierbaren Informationen (PII) von Nutzern wie MSISDN, gehashte MSISDN oder eine eindeutige Nutzer-ID.
Abrechnungskategorien für Agenten
Beim Erstellen eines Agents legt der Inhaber die Abrechnungskategorie basierend darauf fest, wie der Agent mit Nutzern interagieren wird. Die Abrechnungskategorie schränkt die Anzahl oder den Typ der Nachrichten, die ein Kundenservicemitarbeiter senden kann, nicht ein. Es bestimmt jedoch, wie dem Agent Nachrichten in Rechnung gestellt werden. Die beiden Hauptabrechnungskategorien werden in der folgenden Tabelle beschrieben.
| Abrechnungskategorie | Agent-Typ | Beispielanwendungsfälle | Abrechnungsmethode |
|---|---|---|---|
Nicht konversationell (Umfasst die Kategorien „Basic Message“ und „Single Message“.) Hinweis: Zwischen diesen beiden Kategorien besteht kein Unterschied mehr. Ein Agent in einer der beiden Kategorien wird als nicht konversationeller Agent abgerechnet.) |
Agents, die hauptsächlich unidirektionale Nachrichten senden. |
|
Die Abrechnung erfolgt für jede Nachricht, die an den Nutzer gesendet wird. |
| Locker und dialogorientiert | Agents, die für den Austausch mit Nutzern entwickelt wurden. |
|
Abrechnung pro Unterhaltung: Wenn eine Partei (der Kundenservicemitarbeiter oder der Nutzer) innerhalb von 24 Stunden auf eine Nachricht der anderen Partei antwortet, beginnt eine Unterhaltung. Während des Unterhaltungszeitraums (24 Stunden nach der ersten Antwort) können der Kundenservicemitarbeiter und der Nutzer beliebig viele Nachrichten austauschen. Dem Kundenservicemitarbeiter wird ein fester Betrag für die Unterhaltung in Rechnung gestellt. Abrechnung pro Nachricht: Wenn der Agent eine Nachricht sendet, auf die der Nutzer innerhalb von 24 Stunden nicht antwortet, wird dem Agent die einzelne Nachricht in Rechnung gestellt, ähnlich wie bei einem nicht konversationellen Agent. |
Das folgende Diagramm zeigt ein Beispiel für eine A2P-Abrechnungssitzung für Conversational Agents:
Konversationelle und nicht konversationelle Agents
Es gibt zwei Hauptabrechnungskategorien: konversationell und nicht konversationell. Die Kategorie „Nicht konversationell“ umfasst die Kategorien „Basic Message“ und „Single Message“, die funktional identisch sind. Ein Agent in einer dieser Kategorien wird als nicht konversationeller Agent abgerechnet.
Der Hauptunterschied zwischen den Abrechnungskategorien liegt zwischen konversationellen und nicht konversationellen Agenten:
Nicht konversationelle Agents werden für jede Nachricht abgerechnet, die sie an den Nutzer senden.
- Diese Kategorie eignet sich am besten für Kundenservicemitarbeiter, die nicht mit häufigen Antworten rechnen.
Für Konversations-Agents wird ein Pauschalpreis für Unterhaltungen berechnet, der alle Nachrichten umfasst, die innerhalb eines Zeitraums von 24 Stunden ausgetauscht werden.
- Diese Kategorie eignet sich am besten für Kundenservicemitarbeiter, die sich in Multi-Turn-Unterhaltungen mit Nutzern austauschen.
Abrechnungsvorgänge
In den Berichten zu Abrechnungsereignissen werden fünf verschiedene Arten von Abrechnungsereignissen erfasst. Dazu gehören A2P- und P2A-Nachrichten.
- A2P (Application-to-Person): Vom Unternehmen gesendet.
- P2A (Person-to-Application): Vom Nutzer gesendet.
In der folgenden Tabelle werden die einzelnen Abrechnungsereignisse für nicht konversationelle und konversationelle Agents beschrieben.
| Ereignis | Beschreibung | Nicht konversationelle Agents | Konversations-Agenten |
|---|---|---|---|
basic_message
|
A2P-Nachricht, die nur Text mit maximal 160 Zeichen enthält. Wenn der Text eine URL für eine Website mit OpenGraph-Tags enthält, wird in der Nachricht möglicherweise eine Bildvorschau angezeigt. Für den Partner fallen dadurch keine zusätzlichen Kosten an. | Wird immer als individuelles Abrechnungsereignis behandelt, unabhängig davon, ob der Nutzer antwortet. | Wird als individuelles Abrechnungsereignis behandelt, sofern der Nutzer nicht innerhalb von 24 Stunden antwortet. In diesem Fall wird die Nachricht Teil einer a2p_conversation.
|
single_message
|
A2P-Nachricht mit Rich Content oder eine reine Textnachricht mit mehr als 160 Zeichen. | Wird immer als individuelles Abrechnungsereignis behandelt, unabhängig davon, ob der Nutzer antwortet. | Wird als individuelles Abrechnungsereignis behandelt, sofern der Nutzer nicht innerhalb von 24 Stunden antwortet. In diesem Fall wird die Nachricht Teil einer a2p_conversation.
|
a2p_conversation (vom Unternehmen initiiert)
|
Wird ausgelöst, wenn ein Nutzer innerhalb von 24 Stunden nach Erhalt einer A2P-Nachricht außerhalb einer bestehenden Unterhaltung darauf antwortet. | – Bei nicht konversationellen Agenten wird dieser Ereignistyp nie generiert. | Wenn eine P2A-Nachricht innerhalb von 24 Stunden nach mehreren A2P-Nachrichten zugestellt wird, wird nur die A2P-Nachricht verwendet, die unmittelbar vor der P2A-Nachricht gesendet wurde, um die Unterhaltung zu starten. Diese A2P-Nachricht und alle Nachrichten, die innerhalb der nächsten 24 Stunden zugestellt werden, sind Teil der a2p_conversation.
|
p2a_conversation (vom Nutzer initiiert)
|
Wird initiiert, wenn ein Agent innerhalb von 24 Stunden nach Erhalt auf eine P2A-Nachricht antwortet, die nicht Teil einer bestehenden Unterhaltung ist. | – Bei nicht konversationellen Agenten wird dieser Ereignistyp nie generiert. | Wenn eine A2P-Nachricht innerhalb von 24 Stunden nach mehreren P2A-Nachrichten zugestellt wird, wird nur die P2A-Nachricht verwendet, die unmittelbar vor der A2P-Nachricht gesendet wurde, um die Unterhaltung zu starten. Diese P2A-Nachricht und alle Nachrichten, die innerhalb der nächsten 24 Stunden zugestellt werden, sind Teil des p2a_conversation.
|
p2a_message
|
P2A-Nachricht eines beliebigen Typs. | Wird immer als individuelles Abrechnungsereignis behandelt, unabhängig davon, ob der Kundenservicemitarbeiter antwortet. | Wird als einzelnes Abrechnungsereignis behandelt, sofern der Kundenservicemitarbeiter nicht innerhalb von 24 Stunden antwortet. |
Abrechnungsvorgänge im Vergleich zu Abrechnungskategorien
Die Abrechnungsvorgänge basic_message und single_message dürfen nicht mit den Abrechnungskategorien „Basismitteilung“ und „Einzelne Mitteilung“ verwechselt werden.
Jeder Agent (unabhängig von seiner Abrechnungskategorie) kann Abrechnungsereignisse für
basic_messageundsingle_messagegenerieren.Die Abrechnungskategorien „Basic Message“ und „Single Message“ werden verwendet, um nicht konversationelle Agents zu klassifizieren. Bei Agents in diesen Abrechnungskategorien werden keine Abrechnungsereignisse für Unterhaltungen (
a2p_conversationsoderp2a_conversations) generiert. Stattdessen werden einzelne Abrechnungsereignisse fürbasic_message,single_messageundp2a_messagegeneriert.
Abrechnungsberichte erstellen
Nur bei Agenten mit Traffic, der nicht von Testern stammt, werden Abrechnungsereignisse generiert. Aktivitäten von Testtelefonnummern werden nicht in Berichten zu Abrechnungsereignissen angezeigt.
In diesen Berichten wird davon ausgegangen, dass Ereignisse abgerechnet werden, wenn Nachrichten zugestellt werden, nicht wenn sie gesendet werden. Eine nicht zugestellte Nachricht oder eine Nachricht, die vor der Zustellung abgebrochen wurde, löst kein Abrechnungsereignis aus.
Format des Abrechnungsberichts
Für Abrechnungsereignisberichte wird das Dateinamenformat rbm_billable_events_YYYY-MM-DD.csv verwendet. Das Datum im Dateinamen ist das Datum, an dem die Datei generiert wurde.
Jede Zeile im Bericht ist ein Datensatz, der ein einzelnes Abrechnungsereignis darstellt. Felder in einem Datensatz sind tabulatorgetrennt. Wenn beispielsweise zwei A2P-Konversationen mit demselben Kundenservicemitarbeiter stattfinden, werden zwei Abrechnungsereignisse und zwei Einträge im Abrechnungsereignisbericht generiert.
Jeder Datensatz im Bericht enthält die folgenden Informationen für jedes Abrechnungsereignis:
| Feld | Format | Beschreibung | Beispiel |
|---|---|---|---|
billing_event_id
|
String | UUID-Kennung. Eine Zufallszahl, die für jedes neue Ereignis zum Zeitpunkt seiner Erstellung generiert wird. | 242f1d9f-7c3f-4e5b-ab3f-818f188fa3ff
|
type
|
String | Art des Ereignisses:
|
single_message
|
agent_id
|
String | Eindeutige Kennung für den Agent, der an dem Ereignis teilgenommen hat. | rbm-welcome-bot@rbm.goog
|
agent_owner
|
String | E-Mail-Adresse des aktuellen Inhabers des Partnerkontos, in dem der Agent erstellt wurde. | name@aggregator.com
|
billing_party
|
String | Die Partei, die Veranstaltungen in Rechnung stellt.
|
carrier
|
max_duration_single_message
|
Zahl | Maximale Zeit (in Stunden), die ein Nutzer hat, um auf eine Nachricht eines Kundenservicemitarbeiters zu antworten, bevor das Zeitfenster für die Konversationsinitiierung geschlossen wird und die Nachricht als single_message-Ereignis klassifiziert wird.
|
24
|
max_duration_a2p_conversation
|
Zahl | Maximale Dauer einer A2P-Unterhaltung in Stunden. Gemessen ab der ersten Nutzerantwort auf die erste Nachricht des Agents. | 24
|
max_duration_p2a_conversation
|
Zahl | Maximale Dauer einer P2A-Unterhaltung in Stunden. Gemessen ab der ersten Nutzernachricht in der Unterhaltung. | 24
|
start_time
|
YYYY-mm-ddTHH:00:00Z | Das UTC-Datum und die UTC-Uhrzeit, zu der das Ereignis begonnen hat, im ISO 8601-Format, gerundet auf die nächste Stunde.
A2P-Nachrichten
P2A-Nachrichten
|
2019-07-25T08:00:00Z
|
duration
|
Zahl | Die Dauer des Ereignisses, auf die nächste Minute gerundet.
Wenn der Ereignistyp |
45
|
mt_messages
|
Zahl | Anzahl der mobil empfangenen (A2P-)Nachrichten im Ereignis. | 11
|
mo_messages
|
Zahl | Anzahl der vom Mobilgerät gesendeten (P2A) Nachrichten im Ereignis. | 9
|
size_kilobytes
|
Zahl | Größe aller Dateien, die an Nachrichten im Ereignis angehängt sind, gerundet auf das nächste Kilobyte (1 KB = 1.024 Byte). | 912
|
agent_name
|
String |
Name des Agents, der an dem Ereignis teilgenommen hat. |
XYZ Mobile USA
|
owner_name
|
String | Name des aktuellen Inhabers des Partnerkontos, in dem der Agent erstellt wurde. | XYZ Mobile
|
Beispiel für einen Bericht zu Abrechnungsvorgängen
Eine Beispielabrechnungsberichtsdatei ist zum Herunterladen verfügbar.
Typische Dateigröße
Die Größe eines täglichen Berichts eines aktiven RBM-Partners hängt davon ab, wie viele Aktivitäten er im Netzwerk des Mobilfunkanbieters generiert hat. Wenn der Bericht beispielsweise 53.000 Datensätze enthält, hat die Datei eine Größe von etwa 8 MB.
Aktivitätsprotokolle
Aktivitätsprotokolle enthalten Rohdaten zu Aktivitäten auf der RBM-Plattform. Sie können diese Logs verwenden, um Abrechnungsereignisse zu prüfen und benutzerdefinierte Ereignisse zu erstellen.
Hinweis: In Aktivitätsprotokollen ist nur Traffic von Telefonnummern enthalten, die nicht zu Testzwecken verwendet werden.
Da Aktivitätslogs personenidentifizierbare Informationen (PII) wie detaillierte Transaktionsinformationen und MSISDNs von Abonnenten enthalten, sind sie nur verfügbar, wenn ein Mobilfunkanbieter RCS gemäß seinen eigenen Nutzungsbedingungen betreibt. Wenn Sie RBM-Traffic in Ihren Netzwerken haben und RCS-Aktivitäten mit Google RCS gemäß den Nutzungsbedingungen von Google aktivieren, haben Sie keinen Zugriff auf Aktivitätsprotokolle.
Format des Aktivitätsprotokolls
Für Aktivitätsprotokolle wird das Dateinamenformat rbm_activity_YYYY-MM-DD.csv verwendet. Das Datum im Dateinamen ist das Datum, an dem die Datei generiert wurde.
Felder in einem Datensatz sind tabulatorgetrennt und es gibt einen Datensatz pro Zeile.
Jeder Eintrag im Aktivitätsprotokoll enthält die folgenden Felder für jede Aktivität:
| Feld | Format | Beschreibung | Beispiel |
|---|---|---|---|
activity_id
|
String | Eindeutige Kennung für die Aktivität. | b422e1d3-ac99-442a-853d-a875d5e61762
|
billing_event_id
|
String | Eindeutige Kennung für das zugehörige Abrechnungsereignis. Kann leer sein, wenn die Aktivität nicht mit einem Abrechnungsereignis verknüpft ist, z. B. ein text_message ohne entsprechendes delivery_receipt_event.
|
91yeb201-7c3b-412b-98d2-b0a0f7abe536
|
agent_id
|
String | Eindeutige Kennung für den Agent. | welcome-bot@rbm.goog
|
user_id
|
String | MSISDN des Nutzers. | 918369110173
|
direction
|
String | Die Richtung, in die die Nachricht gesendet wird:
|
MT
|
time
|
YYYY-mm-ddTHH:MM:SS.SSSZ | Datum und Uhrzeit, zu der das Ereignis in UTC-Format an die RBM-Plattform gesendet wurde. Weitere Informationen finden Sie unter Zeitstempel. | 2019-07-25T00:29:07.033Z
|
type
|
String | Art der Aktivität:
|
text_message
|
size_bytes
|
String | Größe der an die Aktivität angehängten Dateien in Byte. | 912
|
Zeitstempel
Die Zeitstempel in Aktivitätslogs geben an, wann ein Ereignis an die RBM-Plattform gesendet wurde. Bei Ereignissen, bei denen Inhalte an einen Nutzer gesendet werden, wird das Ereignis erst dann im Aktivitätsprotokoll aufgezeichnet, wenn die Nachricht zugestellt wurde.
Wenn beispielsweise am Mittwoch um 13:00 Uhr eine RBM-Nachricht an einen Nutzer gesendet wird und der Empfänger bis Sonntag um 9:00 Uhr offline ist, wird das Ereignis im Aktivitätsprotokoll für Sonntag angezeigt, der Zeitstempel ist jedoch Mittwoch, 13:00 Uhr.