Ta strona opisuje pliki danych tworzone przez RBM, aby ułatwić operatorom rozliczenia i weryfikację. Odpowiedzi na najczęstsze pytania dotyczące modelu płatności RBM znajdziesz w artykule Odpowiedzi na najczęstsze pytania dotyczące modelu płatności RBM.
| Plik | Opis | Kto ma dostęp |
|---|---|---|
| Raport Zdarzenie rozliczeniowe | Raport zbiorczy o płatnych zdarzeniach między uruchomionymi agentami a użytkownikami. | Wszyscy operatorzy, którzy aktywnie korzystają z RBM (RCS Business Messaging). |
| Dziennik aktywności | Dziennik danych nieprzetworzonych o działalności związanej z modelem RBM, w tym o zdarzeniach podlegających rozliczeniu. | Operatorzy, którzy aktywnie korzystają z usługi RBM (RCS Business Messaging) i obsługują usługę RCS Google zgodnie z własnymi Warunkami korzystania z usługi. |
Generowanie pliku
Każdy plik danych odpowiada 1 dniowi korzystania z usługi RBM według uniwersalnego czasu koordynowanego (UTC). Pliki są generowane codziennie między 10:00 a 12:00 czasu UTC.
W przypadku agentów niekonwersacyjnych pliki zawierają dane z 24-godzinnego okresu bezpośrednio poprzedzającego czas wygenerowania pliku. Jeśli na przykład raport z zdarzeniami rozliczeniowymi zostanie wygenerowany 5 maja o 11:00 UTC, będzie zawierać dane z okresu od 4 maja, 11:00 UTC do 5 maja, 11:00 UTC.
W przypadku agentów konwersacyjnych pliki zawierają dane z okresu 24 godzin (1–2 dni) poprzedzającego wygenerowanie pliku. Jeśli np. raport z zdarzeniami rozliczeniowymi jest generowany 5 maja o godz. 11:00 UTC, może zawierać dane z okresu od 3 maja, godz. 11:00 UTC do 4 maja, godz. 11:00 UTC.
Powodem opóźnienia jest to, że aktywność RBM dla agentów konwersacyjnych jest powiązana z rozmowami, które mogą trwać do 48 godzin. To opóźnienie pozwala RBM rejestrować wszystkie wiadomości w rozmowie przed obliczeniem zdarzenia rozliczeniowego. Więcej informacji o agentach do obsługi rozmów znajdziesz w artykule Kategorie rozliczeń agentów.
Najważniejsze kwestie:
Brak aktywności: jeśli w danym dniu nie ma aktywności na platformie, nie generuje się żaden plik.
Nazwy: data w nazwie pliku to data jego utworzenia, a nie data zawartych w nim danych.
Okres przechowywania: pliki są przechowywane maksymalnie przez 30 dni, a następnie usuwane.
Za pomocą tych plików możesz aktualizować swój magazyn danych o najnowsze dane o użytkowaniu platformy.
Przechowywanie plików i dostęp do nich
Pliki danych są szyfrowane zarówno podczas przechowywania, jak i przesyłania.
Aby pobierać pliki danych za pomocą protokołu Secure File Transfer Protocol (SFTP), podaj klucz publiczny SFTP. Aby wygenerować klucze, zapoznaj się z artykułem Generowanie pary kluczy SSH do użycia ze skrzynką referencyjną SFTP.
Serwer SFTP to partnerupload.google.com, a połączenie jest nawiązywane przez port o wysokim numerze (19321) w celu zapewnienia dodatkowego zabezpieczenia.
Aby uzyskać dostęp do plików danych, użyj tego polecenia:
sftp -i <path_to_private_key> -P 19321 <username>@partnerupload.google.com
Google udostępnia nazwy kont w tych formatach:
rbmreports-billableevents-<carrier name>rbmreports-activity-<carrier name>
Google określa <carrier name> i udostępnia osobne konto na potrzeby każdego typu raportu.
Dostęp do różnych typów raportów mają osobne konta.
Dostępność plików
Jeśli pliki danych nie zostały jeszcze wygenerowane, pojawi się błąd SFTP podobny doremote readdir("/"): No such file or directory, co jest oczekiwane.
Plik nie zostanie wygenerowany, jeśli nie ma ruchu z RBM do zgłoszenia. Oznacza to, że w niektóre dni mogą nie być generowane żadne pliki. Jeśli potrzebujesz pustych plików, aby usprawnić proces, napisz na adres rbm-support@google.com.
Raporty o zdarzeniach rozliczeniowych
Raporty zdarzeń rozliczeniowych to rekordy zdarzeń rozliczeniowych, które są obliczane na podstawie kategorii rozliczeniowej agenta i typu wysyłanych przez niego wiadomości. Raporty zdarzeń związanych z płatnościami są dostępne dla wszystkich operatorów, którzy aktywnie korzystają z RBM (RCS Business Messaging).
Raporty o zdarzeniach związanych z płatnościami zawierają informacje poufne, ale nie zawierają informacji umożliwiających identyfikację użytkownika, takich jak MSISDN, zaszyfrowany MSISDN ani żaden unikalny identyfikator użytkownika.
Kategorie fakturowania agenta
Podczas tworzenia agenta właściciel określa jego kategorię rozliczeniową na podstawie tego, jak agent będzie wchodzić w interakcje z użytkownikami. Kategoria rozliczeniowa nie ogranicza liczby ani typu wiadomości, które może wysyłać pracownik obsługi klienta. Określa ona jednak, jak będą naliczane opłaty za wiadomości. Dwie główne kategorie rozliczeń zostały opisane w tabeli poniżej.
| Kategoria fakturowania | Typ agenta | Przykłady użycia | Forma płatności |
|---|---|---|---|
Niekonwersacyjny (w tym kategorie „Wiadomość podstawowa” i „Pojedyncza wiadomość”) Uwaga: te dwie kategorie nie różnią się już od siebie. Agent z dowolnej kategorii będzie rozliczany jako agent niekonwersacyjny. |
Pracownicy, którzy głównie wysyłają wiadomości w jednym kierunku. |
|
Opłaty są naliczane za każdą wiadomość dostarczoną użytkownikowi. |
| Konwersacyjny | Agenty przeznaczone do wymiany informacji z użytkownikami. |
|
Naliczanie opłat za rozmowę: jeśli jedna strona (agent lub użytkownik) odpowie na wiadomość od drugiej strony w ciągu 24 godzin, rozpocznie się rozmowa. W okresie rozmowy (24 godziny od pierwszej odpowiedzi) agent i użytkownik mogą wymienić dowolną liczbę wiadomości, a agentowi zostanie naliczona stała stawka za rozmowę. Naliczanie opłat za wiadomość: jeśli agent przekaże wiadomość, na którą użytkownik nie odpowie w ciągu 24 godzin, zostanie naliczona opłata za pojedynczą wiadomość, podobnie jak w przypadku agenta niekonwersacyjnego. |
Agenty konwersacyjne a niekonwersacyjne
Istnieją 2 główne kategorie rozliczeń: konwersacyjna i niekonwersacyjna. Kategoria niekonwersacyjna obejmuje kategorie Podstawowa wiadomość i Pojedyncza wiadomość, które są funkcjonalnie identyczne. Za agenta należącego do którejkolwiek z tych kategorii pobierane są opłaty za agenta niekonwersacyjnego.
Najważniejsza różnica w kategoriach rozliczeniowych dotyczy agentów konwersacyjnych i niekonwersacyjnych:
W przypadku agentów niekonwersacyjnych naliczane są opłaty za każdą wiadomość wysłaną do użytkownika.
- Ta kategoria jest najlepsza dla agentów, którzy nie oczekują częstych odpowiedzi.
Za rozmowy z użytkownikami agentom konwersacyjnym nalicza się stała stawka za rozmowy, które obejmują wszystkie wiadomości wymieniane w ciągu 24 godzin.
- Ta kategoria jest najlepsza w przypadku agentów, którzy prowadzą z użytkownikami rozmowy wieloetapowe.
Zdarzenia rozliczeniowe
W raportach o zdarzeniach rozliczeniowych rejestrowanych jest 5 różnych typów zdarzeń rozliczeniowych. Zdarzenia te obejmują wiadomości A2P i P2A.
- A2P (Application-to-Person): wysłane przez firmę.
- P2A (Person-to-Application): wysłane przez użytkownika.
Tabela poniżej opisuje każde zdarzenie rozliczeniowe w przypadku agentów niekonwersacyjnych i konwersacyjnych.
| Zdarzenie | Opis | Agenty inne niż konwersacyjne | Agenty konwersacyjne |
|---|---|---|---|
basic_message
|
wiadomość A2P zawierająca tylko tekst o długości do 160 znaków, Jeśli tekst zawiera adres URL witryny z tagami openGraph, wiadomość może zawierać podgląd obrazu bez dodatkowych opłat dla partnera. | Zawsze traktowane jako indywidualne zdarzenie rozliczeniowe, niezależnie od tego, czy użytkownik odpowie. | Jest traktowane jako osobne zdarzenie rozliczeniowe, chyba że użytkownik odpowie w ciągu 24 godzin. W takim przypadku wiadomość staje się częścią a2p_conversation.
|
single_message
|
wiadomość A2P zawierająca multimedia lub tekst o długości przekraczającej 160 znaków; | Zawsze traktowane jako indywidualne zdarzenie rozliczeniowe, niezależnie od tego, czy użytkownik odpowie. | Jest traktowane jako osobne zdarzenie rozliczeniowe, chyba że użytkownik odpowie w ciągu 24 godzin. W takim przypadku wiadomość staje się częścią a2p_conversation.
|
a2p_conversation (inicjowane przez firmę)
|
Rozpoczyna się, gdy użytkownik odpowiada na wiadomość A2P w ciągu 24 godzin od jej otrzymania, poza istniejącą rozmową. | Nie dotyczy. Agenty niekonwersacyjne nigdy nie generują tego typu zdarzeń. | Jeśli wiadomość P2A została dostarczona w ciągu 24 godzin od wysłania wielu wiadomości A2P, do zainicjowania rozmowy zostanie użyta tylko wiadomość A2P, która bezpośrednio poprzedzała wiadomość P2A. Ta wiadomość A2P i wszystkie wiadomości dostarczone w ciągu 24 godzin są częścią a2p_conversation.
|
p2a_conversation (inicjowane przez użytkownika)
|
Rozpoczyna się, gdy agent odpowiada na wiadomość P2A w ciągu 24 godzin od jej otrzymania, poza istniejącą rozmową. | Nie dotyczy. Agenty niekonwersacyjne nigdy nie generują tego typu zdarzeń. | Jeśli wiadomość A2P zostanie dostarczona w ciągu 24 godzin od wysłania kilku wiadomości P2A, do zainicjowania rozmowy zostanie użyta tylko wiadomość P2A, która bezpośrednio poprzedzała wiadomość A2P. Ta wiadomość P2A i wszystkie wiadomości dostarczone w ciągu 24 godzin są częścią p2a_conversation.
|
p2a_message
|
wiadomość weryfikacji dwuetapowej dowolnego typu. | Zawsze traktowane jako pojedyncze zdarzenie rozliczeniowe, niezależnie od tego, czy pracownik obsługi klienta odpowie. | Jest traktowane jako osobne zdarzenie rozliczeniowe, chyba że pracownik obsługi klienta odpowie w ciągu 24 godzin. |
Zdarzenia płatności a kategorie fakturowania
Zdarzeń rozliczeniowych basic_message i single_message nie należy mylić z kategoriami rozliczeniowymi Podstawowa wiadomość i Pojedyncza wiadomość.
Każdy agent (niezależnie od kategorii rozliczeniowej) może generować zdarzenia rozliczeniowe
basic_messageisingle_message.Kategorie rozliczeniowe Podstawowa wiadomość i Pojedyncza wiadomość służą do klasyfikowania agentów niekonwersacyjnych. Pracownicy obsługi klienta w tych kategoriach rozliczeń nie generują zdarzeń rozliczeniowych w formie czatu (
a2p_conversationsanip2a_conversations). Zamiast tego generują pojedyncze zdarzenia rozliczeniowebasic_message,single_messageip2a_message.
Generowanie raportu rozliczeniowego
Tylko agenci z ruchu niebędącego testowym generują zdarzenia rozliczeniowe. Aktywność z testowych numerów telefonów nie pojawia się w raportach o zdarzeniach związanych z płatnościami.
W tych raportach zakłada się, że zdarzenia są obciążane w momencie dostarczenia wiadomości, a nie jej wysłania. Niedostarczone wiadomości lub wiadomości anulowane przed dostarczeniem nie powodują zdarzenia rozliczeniowego.
Format raportu rozliczeniowego
Raporty zdarzeń rozliczeniowych mają format nazwy pliku rbm_billable_events_YYYY-MM-DD.csv. Data w nazwie pliku to data jego utworzenia.
Każdy wiersz w raporcie to rekord przedstawiający pojedyncze zdarzenie rozliczeniowe. Pola w rekordzie są rozdzielone tabulatorami. Na przykład 2 rozmowy A2P z tym samym pracownikiem obsługi klienta wygenerują 2 zdarzenia rozliczeniowe i 2 rekordy w raporcie Zdarzenia rozliczeniowe.
Każdy rekord w raporcie zawiera te informacje o każdym zdarzeniu rozliczeniowym:
| Pole | Format | Opis | Przykład |
|---|---|---|---|
billing_event_id
|
ciąg znaków | Identyfikator UUID. losowa liczba wygenerowana dla każdego nowego zdarzenia w momencie jego utworzenia; | 242f1d9f-7c3f-4e5b-ab3f-818f188fa3ff
|
type
|
ciąg znaków | Typ zdarzenia:
|
single_message
|
agent_id
|
ciąg znaków | Unikalny identyfikator agenta, który uczestniczył w zdarzeniu. | rbm-welcome-bot@rbm.goog
|
agent_owner
|
ciąg znaków | Adres e-mail obecnego właściciela konta partnera, na którym utworzono agenta. | name@aggregator.com
|
billing_party
|
ciąg znaków | Podmiot wystawiający faktury za zdarzenia.
|
carrier
|
max_duration_single_message
|
liczba | Maksymalny czas (w godzinach), jaki użytkownik ma na odpowiedź na wiadomość od agenta, zanim okno rozpoczęcia rozmowy zamknie się i wiadomość zostanie zaklasyfikowana jako zdarzenie single_message.
|
24
|
max_duration_a2p_conversation
|
liczba | Maksymalny czas trwania rozmowy A2P w godzinach. Czas od pierwszej odpowiedzi użytkownika na pierwszą wiadomość od agenta. | 24
|
max_duration_p2a_conversation
|
liczba | Maksymalny czas trwania rozmowy P2A w godzinach. Liczony od pierwszej wiadomości użytkownika w rozmowie. | 24
|
start_time
|
YYYY-mm-ddTHH:00:00Z | Data i godzina rozpoczęcia zdarzenia w formacie ISO 8601 zaokrąglona do najbliższej godziny.
Wiadomości A2P
Komunikaty P2A
|
2019-07-25T08:00:00Z
|
duration
|
liczba | Czas trwania wydarzenia zaokrąglony do najbliżej minuty.
Gdy typ zdarzenia to |
45
|
mt_messages
|
liczba | Liczba wiadomości A2P w zdarzeniu. | 11
|
mo_messages
|
liczba | Liczba wiadomości wysłanych z urządzenia mobilnego (P2A) w zdarzeniu. | 9
|
size_kilobytes
|
liczba | Rozmiar wszystkich plików załączonych do wiadomości w zdarzeniu, zaokrąglony do najbliższego kilobajta (1 kB = 1024 bajty). | 912
|
agent_name
|
ciąg znaków |
Imię i nazwisko agenta, który uczestniczył w zdarzeniu. |
XYZ Mobile USA
|
owner_name
|
ciąg znaków | Imię i nazwisko obecnego właściciela konta partnera, na którym utworzono agenta. | XYZ Mobile
|
Przykładowy raport o zdarzeniach płatności
Plik przykładowego raportu rozliczeniowego można pobrać.
Typowy rozmiar pliku
Raport dzienny od aktywnego partnera RBM może zawierać około 53 tys. rekordów i mieć rozmiar około 8 MB.
Logi aktywności
Dzienniki aktywności zawierają dane wyjściowe o działaniach na platformie RBM. Z tych dzienników możesz korzystać do sprawdzania zdarzeń rozliczeniowych i tworzenia zdarzeń niestandardowych.
Ponieważ dzienniki aktywności zawierają informacje umożliwiające identyfikację, takie jak szczegółowe informacje o transakcjach i numery MSISDN abonentów, są one dostępne tylko wtedy, gdy operator obsługuje RCS zgodnie z własnymi Warunkami korzystania z usługi. Jeśli masz ruch RBM w swoich sieciach i włączasz aktywność RCS za pomocą usługi RCS Google zgodnie z Warunkami korzystania z usługi Google, nie będziesz mieć dostępu do dzienników aktywności.
Format historii aktywności
Pliki dziennika aktywności mają format rbm_activity_YYYY-MM-DD.csv. Data w nazwie pliku to data jego utworzenia.
Pola w rekordzie są rozdzielone tabulacją, a każdy wiersz zawiera 1 rekord.
Każdy rekord w dzienniku aktywności zawiera te pola:
| Pole | Format | Opis | Przykład |
|---|---|---|---|
activity_id
|
ciąg znaków | Unikalny identyfikator aktywności. | b422e1d3-ac99-442a-853d-a875d5e61762
|
billing_event_id
|
ciąg znaków | Unikalny identyfikator powiązanego zdarzenia rozliczeniowego. Może być puste, jeśli aktywność nie jest powiązana ze zdarzeniem rozliczeniowym, np. text_message bez odpowiadającego zdarzenia delivery_receipt_event.
|
91yeb201-7c3b-412b-98d2-b0a0f7abe536
|
agent_id
|
ciąg znaków | Unikalny identyfikator agenta. | welcome-bot@rbm.goog
|
user_id
|
ciąg znaków | MSISDN użytkownika. | 918369110173
|
direction
|
ciąg znaków | Kierunek wysyłania wiadomości:
|
MT
|
time
|
YYYY-mm-ddTHH:MM:SS.SSSZ | Data i godzina przesłania zdarzenia do platformy RBM w formacie UTC. Zobacz sygnatury czasowe. | 2019-07-25T00:29:07.033Z
|
type
|
ciąg znaków | Rodzaj aktywności:
|
text_message
|
size_bytes
|
ciąg znaków | Rozmiar plików załączonych do aktywności w bajtach. | 912
|
Sygnatury czasowe
Sygnatury czasowe w dziennikach aktywności rejestrują, kiedy zdarzenie zostało przesłane do platformy RBM. W przypadku zdarzeń, które dostarczają użytkownikowi treści, zdarzenie nie zostanie zarejestrowane w dzienniku aktywności, dopóki wiadomość nie zostanie dostarczona.
Jeśli np. wiadomość RBM zostanie wysłana do użytkownika w środę o 13:00, a odbiorca będzie offline do niedzieli o 9:00, zdarzenie pojawi się w dzienniku aktywności wygenerowanym w niedzielę, ale będzie opatrzone sygnaturą czasową środa, 13:00.