Auf dieser Seite werden die Datendateien beschrieben, die von RBM erstellt werden, um Mobilfunkanbieter bei der Abrechnung und Prüfung zu unterstützen.
| Datei | Beschreibung | Wer hat Zugriff? |
|---|---|---|
| Bericht zu Abrechnungsereignissen | Aggregierter Bericht zu abrechenbaren Ereignissen zwischen gestarteten Kundenservicemitarbeitern und Nutzern. | Alle Mobilfunkanbieter mit einer unterzeichneten RBM-MDA |
| Aktivitätsprotokoll | Rohdatenprotokoll der RBM-Aktivitäten, einschließlich abrechenbarer Ereignisse. | Mobilfunkanbieter mit einer unterzeichneten RBM-MDA, die den Google RCS-Dienst gemäß ihren eigenen Nutzungsbedingungen betreiben. |
Dateigenerierung
Jede Datendatei entspricht einem Tag der RBM-Nutzung in koordinierter Weltzeit (UTC). Die Dateien werden täglich zwischen 10:00 und 12:00 Uhr UTC generiert.
Bei nicht konversationellen Bots enthalten die Dateien Daten aus den 24 Stunden vor der Dateigenerierung. Wenn beispielsweise am 5. Mai um 11:00 Uhr (UTC) ein Bericht zu Abrechnungsereignissen generiert wird, enthält er Daten vom 4. Mai (11:00 Uhr UTC) bis zum 5. Mai (11:00 Uhr UTC).
Bei konversationsorientierten Bots enthalten die Dateien Daten aus dem 24-Stunden-Zeitraum, der 1–2 Tage vor der Dateigenerierung liegt. Wenn beispielsweise am 5. Mai um 11:00 Uhr (UTC) ein Bericht zu Abrechnungsereignissen generiert wird, enthält er möglicherweise Daten vom 3. Mai (11:00 Uhr UTC) bis zum 4. Mai (11:00 Uhr UTC).
Der Grund für die Verzögerung ist, dass die RBM-Aktivität für Konversationsagenten mit Unterhaltungen verknüpft ist, die bis zu 48 Stunden dauern können. Durch diese Verzögerung können alle Nachrichten in einer Unterhaltung erfasst werden, bevor das Abrechnungsereignis berechnet wird. Weitere Informationen zu Konversations-Agenten finden Sie unter Abrechnungskategorien für Kundenservicemitarbeiter.
Wichtige Punkte:
Keine Aktivität: Wenn an einem bestimmten Tag keine Plattformaktivität erfolgt, wird keine Datei generiert.
Benennung: Das Datum im Dateinamen ist das Datum der Dateigenerierung, nicht das Datum der darin enthaltenen Daten.
Aufbewahrung: Dateien werden maximal 30 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 während der Übertragung verschlüsselt.
Geben Sie Ihren öffentlichen SFTP-Schlüssel an, um Datendateien per SFTP abzurufen. Informationen zum Generieren von Schlüsseln findest du unter SSH-Schlüsselpaar (Secure Shell) für SFTP-Dropbox generieren.
Der SFTP-Server ist partnerupload.google.com und die Verbindung hat eine hohe Portnummer (19321) für zusätzliche Sicherheit.
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 Kontonutzernamen 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 bereit.
Für den Zugriff auf die verschiedenen Berichtstypen werden separate Konten bereitgestellt.
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.
Wenn keine RBM-Zugriffe zu erfassen sind, wird keine Datei generiert. Das bedeutet, dass an manchen Tagen 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
Berichte zu Abrechnungsereignissen enthalten Daten zu Abrechnungsereignissen, die anhand der Abrechnungskategorie des Kundenservicemitarbeiters und der Art der gesendeten Nachrichten berechnet werden. Berichte zu Abrechnungsereignissen sind für alle Mobilfunkanbieter verfügbar, die eine RBM-MDA haben.
Berichte zu Abrechnungsereignissen enthalten vertrauliche Informationen, aber keine personenidentifizierbaren Informationen (PII) wie MSISDN, gehashte MSISDN oder eindeutige Nutzer-IDs.
Abrechnungskategorien für Kundenservicemitarbeiter
Beim Erstellen eines Agents legt der Inhaber die Abrechnungskategorie fest, je nachdem, 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. Sie bestimmt jedoch, wie die Nachrichten dem Kundenservicemitarbeiter in Rechnung gestellt werden. Die beiden Hauptkategorien der Abrechnung werden in der folgenden Tabelle beschrieben.
| Abrechnungskategorie | Agent-Typ | Beispielanwendungsfälle | Abrechnungsmethode |
|---|---|---|---|
Nicht konversationell (Umfasst die Kategorien „Grundlegende Nachricht“ und „Einzelne Nachricht“. Hinweis: Zwischen diesen beiden Kategorien besteht kein Unterschied mehr. Ein Kundenservicemitarbeiter in einer dieser Kategorien wird als nicht konversationeller Kundenservicemitarbeiter abgerechnet.) |
Kundenservicemitarbeiter, die hauptsächlich einseitige Nachrichten senden. |
|
Es wird für jede Nachricht abgerechnet, die an den Nutzer gesendet wird. |
| Ich kann mich unterhalten | Bots, die für den Austausch mit Nutzern konzipiert sind. |
|
Pro Unterhaltung in Rechnung gestellt: 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 für die Unterhaltung ein fester Preis in Rechnung gestellt. Bezahlung pro Nachricht: Wenn der Kundenservicemitarbeiter eine Nachricht sendet, auf die der Nutzer nicht innerhalb von 24 Stunden antwortet, wird ihm die einzelne Nachricht in Rechnung gestellt, ähnlich wie bei einem nicht konversationellen Kundenservicemitarbeiter. |
Konversations-Agenten im Vergleich zu anderen Agenten
Es gibt zwei Hauptkategorien für die Abrechnung: Konversations- und Nicht-Konversationsinteraktionen. Die Kategorie „Nicht konversationell“ umfasst die Kategorien „Einfache Nachricht“ und „Einzelne Nachricht“, die funktional identisch sind. Ein Agent in einer dieser Kategorien wird als nicht konversationeller Agent abgerechnet.
Der Hauptunterschied zwischen den Abrechnungskategorien besteht zwischen Konversations- und Nicht-Konversations-Chatbots:
Für nicht konversationelle Bots wird für jede Nachricht in Rechnung gestellt, die an den Nutzer gesendet wird.
- Diese Kategorie eignet sich am besten für Kundenservicemitarbeiter, die nicht mit häufigen Antworten rechnen.
Für Conversational Agents wird ein Pauschalpreis für Unterhaltungen berechnet. Dazu gehören alle Nachrichten, die innerhalb eines Zeitraums von 24 Stunden ausgetauscht wurden.
- Diese Kategorie eignet sich am besten für Kundenservicemitarbeiter, die mit Nutzern mehrstufige Unterhaltungen führen.
Abrechnungsereignisse
In den Berichten zu Abrechnungsereignissen werden fünf verschiedene Arten von Abrechnungsereignissen erfasst. Dazu gehören A2P- und P2A-Nachrichten.
- A2P (Application-to-Person): Von der Marke gesendet.
- P2A (Person-to-Application): Vom Nutzer gesendet.
In der folgenden Tabelle werden die einzelnen Abrechnungsereignisse für nicht konversationelle und konversationelle Bots 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 entstehen dabei keine zusätzlichen Kosten. | Wird immer als individuelles Abrechnungsereignis behandelt, unabhängig davon, ob der Nutzer antwortet. | Wird als individuelles Abrechnungsereignis behandelt, es sei denn, der Nutzer antwortet innerhalb von 24 Stunden. In diesem Fall wird die Nachricht Teil einer a2p_conversation.
|
single_message
|
A2P-Nachricht mit Multimedia-Inhalten und/oder Text mit mehr als 160 Zeichen. | Wird immer als individuelles Abrechnungsereignis behandelt, unabhängig davon, ob der Nutzer antwortet. | Wird als individuelles Abrechnungsereignis behandelt, es sei denn, der Nutzer antwortet innerhalb von 24 Stunden. In diesem Fall wird die Nachricht Teil einer a2p_conversation.
|
a2p_conversation (von der Marke initiiert)
|
Wird gestartet, wenn ein Nutzer innerhalb von 24 Stunden nach Erhalt einer A2P-Nachricht außerhalb einer bestehenden Unterhaltung darauf antwortet. | – Nicht konversationelle Bots generieren diese Art von Ereignis nie. | 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 gestartet, wenn ein Kundenservicemitarbeiter innerhalb von 24 Stunden nach Erhalt einer P2A-Nachricht außerhalb einer bestehenden Unterhaltung darauf antwortet. | – Nicht konversationelle Bots generieren diese Art von Ereignis nie. | 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 der p2a_conversation.
|
p2a_message
|
P2A-Nachricht beliebigen Typs | Wird immer als individuelles Abrechnungsereignis behandelt, unabhängig davon, ob der Kundenservicemitarbeiter antwortet. | Wird als individuelles Abrechnungsereignis behandelt, es sei denn, der Kundenservicemitarbeiter antwortet innerhalb von 24 Stunden. |
Abrechnungsereignisse und Abrechnungskategorien
Die Abrechnungsereignisse basic_message und single_message dürfen nicht mit den Abrechnungskategorien „Grundlegende Nachricht“ und „Einzelne Nachricht“ verwechselt werden.
Jeder Kundenservicemitarbeiter (unabhängig von seiner Abrechnungskategorie) kann Abrechnungsereignisse vom Typ
basic_messageundsingle_messagegenerieren.Die Abrechnungskategorien „Einfache Nachricht“ und „Einzelne Nachricht“ werden für nicht konversationelle Bots verwendet. Kundenservicemitarbeiter in diesen Abrechnungskategorien generieren keine Abrechnungsereignisse für Unterhaltungen (
a2p_conversationsoderp2a_conversations). Stattdessen generieren sie einzelne Abrechnungsereignisse vom Typbasic_message,single_messageundp2a_message.
Erstellung von Abrechnungsberichten
Nur Kundenservicemitarbeiter, die keinen Tester-Traffic generieren, generieren Abrechnungsereignisse. Aktivitäten von Testtelefonnummern werden nicht in Berichten zu Abrechnungsereignissen aufgeführt.
In diesen Berichten wird davon ausgegangen, dass Ereignisse in Rechnung gestellt werden, wenn Nachrichten zugestellt werden, nicht wenn sie gesendet werden. Eine nicht zugestellte Nachricht oder eine Nachricht, die vor der Zustellung storniert wurde, löst kein Abrechnungsereignis aus.
Format des Abrechnungsberichts
Abrechnungsereignisberichte haben das Dateinamenformat rbm_billable_events_YYYY-MM-DD.csv. Das Datum im Dateinamen ist das Datum der Dateigenerierung.
Jede Zeile im Bericht ist ein Datensatz, der ein einzelnes Abrechnungsereignis darstellt. Felder innerhalb eines Datensatzes sind durch Tabulatoren getrennt. Wenn Sie beispielsweise zwei A2P-Unterhaltungen mit demselben Kundenservicemitarbeiter führen, werden zwei Abrechnungsereignisse und zwei Einträge im Bericht zu Abrechnungsereignissen generiert.
Jeder Eintrag im Bericht enthält für jedes Abrechnungsereignis die folgenden Informationen:
| Feld | Format | Beschreibung | Beispiel |
|---|---|---|---|
billing_event_id
|
String | UUID-Kennung. Eine zufällige Zahl, die beim Erstellen eines neuen Ereignisses generiert wird. | 242f1d9f-7c3f-4e5b-ab3f-818f188fa3ff
|
type
|
String | Ereignistyp:
|
single_message
|
agent_id
|
String | Eindeutige Kennung für den Kundenservicemitarbeiter, der am Ereignis teilgenommen hat. | rbm-welcome-bot@rbm.goog
|
agent_owner
|
String | E-Mail-Adresse des aktuellen Inhabers des Partnerkontos, in dem der Kundenservicemitarbeiter erstellt wurde. | name@aggregator.com
|
billing_party
|
String | Die Partei, die die Rechnung für die Ereignisse stellt.
|
carrier
|
max_duration_single_message
|
Zahl | Die maximale Zeit (in Stunden), innerhalb derer ein Nutzer auf eine Nachricht eines Kundenservicemitarbeiters antworten kann, bevor das Fenster für die Unterhaltungsinitiierung 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 Kundenservicemitarbeiters. | 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 Datum und die Uhrzeit (UTC) des Beginns des Ereignisses im ISO 8601-Format, gerundet auf die nächste Stunde.
|
2019-07-25T08:00:00Z
|
duration
|
Zahl | Dauer des Ereignisses, auf die nächste Minute gerundet.
Wenn der Ereignistyp |
45
|
mt_messages
|
Zahl | Anzahl der an Mobilgeräte gesendeten Nachrichten (A2P) im Ereignis. | 11
|
mo_messages
|
Zahl | Anzahl der von Mobilgeräten stammenden Nachrichten (P2A) 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 Kundenservicemitarbeiters, der am Ereignis teilgenommen hat. |
XYZ Mobile USA
|
owner_name
|
String | Name des aktuellen Inhabers des Partnerkontos, in dem der Kundenservicemitarbeiter erstellt wurde. | XYZ Mobile
|
Beispiel für einen Bericht zu Abrechnungsereignissen
Eine Beispieldatei für Abrechnungsberichte kann hier heruntergeladen werden.
Typische Dateigröße
Ein täglicher Bericht von einem aktiven RBM-Partner kann etwa 53.000 Einträge enthalten und eine Größe von etwa 8 MB haben.
Aktivitätsprotokolle
Aktivitätsprotokolle enthalten Rohdaten zu Aktivitäten auf der RBM-Plattform. Sie können diese Protokolle verwenden, um Abrechnungsereignisse zu prüfen und benutzerdefinierte Ereignisse zu erstellen.
Da Aktivitätsprotokolle personenidentifizierbare Informationen (PII) wie detaillierte Transaktionsinformationen und MSISDNs von Abonnenten enthalten, sind sie nur verfügbar, wenn ein Mobilfunkanbieter RCS gemäß seinen eigenen Nutzungsbedingungen nutzt. Wenn Sie RBM-Traffic in Ihren Netzwerken haben und RCS-Aktivitäten mit Google RCS Cloud gemäß den Nutzungsbedingungen von Google aktivieren, haben Sie keinen Zugriff auf Aktivitätsprotokolle.
Format des Aktivitätsprotokolls
Aktivitätsprotokolle haben das Dateinamenformat rbm_activity_YYYY-MM-DD.csv. Das Datum im Dateinamen ist das Datum der Dateigenerierung.
Die Felder in einem Datensatz sind durch Tabulatoren getrennt und es gibt einen Datensatz pro Zeile.
Jeder Eintrag im Aktivitätsprotokoll enthält für jede Aktivität die folgenden Felder:
| 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 keinem Abrechnungsereignis zugeordnet ist, z. B. eine text_message ohne entsprechende delivery_receipt_event.
|
91yeb201-7c3b-412b-98d2-b0a0f7abe536
|
agent_id
|
String | Eindeutige Kennung für den Kundenservicemitarbeiter. | 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 dem das Ereignis an die RBM-Plattform gesendet wurde, im UTC-Format. Weitere Informationen finden Sie unter Zeitstempel. | 2019-07-25T00:29:07.033Z
|
type
|
String | Aktivitätstyp:
|
text_message
|
size_bytes
|
String | Größe der an die Aktivität angehängten Dateien in Byte. | 912
|
Zeitstempel
Die Zeitstempel in Aktivitätsprotokollen 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 im Aktivitätsprotokoll aufgezeichnet, wenn die Nachricht zugestellt wurde.
Wenn beispielsweise eine RBM-Nachricht am Mittwoch um 13:00 Uhr 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.
FAQ
Was ist eine Unterhaltung?
Bei der Bewertung der Antwortqualität nach der RBM-Methode ist eine Unterhaltung eine Reihe von Nachrichten, die zwischen einem Nutzer und einem Konversationsagenten innerhalb eines Zeitraums von 24 Stunden ausgetauscht werden. Nur Kundenservicemitarbeiter mit einer Abrechnungskategorie für Unterhaltungen können Unterhaltungen generieren und für die folgenden Abrechnungsereignisse in Rechnung gestellt werden:
- A2P-Unterhaltung: Unterhaltung, die von der Marke initiiert wurde.
- P2A-Unterhaltung: Unterhaltung, die vom Nutzer initiiert wurde.
So funktionieren Unterhaltungen
Start: Eine Unterhaltung beginnt, wenn eine Partei (der Kundenservicemitarbeiter oder der Nutzer) innerhalb von 24 Stunden nach Erhalt einer Nachricht von der anderen Partei außerhalb einer bestehenden Unterhaltung darauf antwortet.
- A2P-Unterhaltung: Beginnt, wenn der Nutzer auf die Nachricht des Kundenservicemitarbeiters antwortet.
- P2A-Unterhaltung: Beginnt, wenn der Kundenservicemitarbeiter auf die Nachricht des Nutzers antwortet.
Gesprächsfenster: Das Gespräch bleibt nach Beginn 24 Stunden lang aktiv. Die Unterhaltung enthält alle Nachrichten innerhalb dieses 24-Stunden-Zeitraums sowie die erste Nachricht, auf die ursprünglich geantwortet wurde.
Abrechnung: Anstatt für jede einzelne Nachricht wird für Konversations-Chatbots die gesamte Unterhaltung in Rechnung gestellt. Die Kosten werden also dem Konversations-Thread zugeordnet, nicht der Anzahl der Nachrichten darin.
Wichtig:
Unterhaltungen gelten nicht für nicht konversationelle Kundenservicemitarbeiter. Für Kundenservicemitarbeiter mit der Abrechnungskategorie „Grundlegende Nachricht“ oder „Einzelne Nachricht“ wird pro Nachricht abgerechnet, unabhängig davon, ob der Nutzer antwortet.
Bei Konversations-Agenten kann die Erstellung von Berichten zu Abrechnungsereignissen und Aktivitätsprotokollen um bis zu zwei Tage verzögert werden. Durch diese Verzögerung kann RBM alle Nachrichten in einer Unterhaltung erfassen, bevor das Abrechnungsereignis berechnet wird.