Na tej stronie opisujemy pliki danych tworzone przez RCS dla firm, które pomagają operatorom w rozliczeniach i audytach.
| Plik | Opis | Kto ma dostęp |
|---|---|---|
| Raport rozliczeniowy | Raport zbiorczy dotyczący zdarzeń podlegających opłacie między uruchomionymi agentami a użytkownikami. | Wszyscy operatorzy, którzy aktywnie korzystają z RCS dla firm. |
| Dziennik aktywności | Dziennik danych pierwotnych aktywności RCS dla firm, w tym zdarzeń podlegających opłacie. | Operatorzy, którzy aktywnie obsługują czaty RCS dla firm i korzystają z usługi Google RCS na podstawie własnych Warunków korzystania z usługi. |
RCS dla firm korzysta z 2 modeli rozliczeń: standardowego modelu rozliczeń w przypadku ruchu spoza Stanów Zjednoczonych i modelu rozliczeń w Stanach Zjednoczonych w przypadku ruchu w Stanach Zjednoczonych. Informacje unikalne dla modelu standardowego lub modelu w Stanach Zjednoczonych (np. różne klasyfikacje zdarzeń podlegających opłacie lub pola raportu) są wyraźnie zaznaczone.
- Szczegółowe informacje o standardowym modelu rozliczeń i podsumowanie różnic między modelami rozliczeń znajdziesz w odpowiedziach na najczęstsze pytania dotyczące płatności.
- Szczegółowe informacje o klasyfikacjach rozliczeń w Stanach Zjednoczonych znajdziesz w przewodniku Model rozliczeń w Stanach Zjednoczonych.
Generowanie pliku
Każdy plik danych zawiera informacje o korzystaniu z RCS dla firm w ciągu jednego dnia według uniwersalnego czasu koordynowanego (UTC). Pliki są generowane codziennie. Proces generowania może potrwać kilka godzin, a czas jego zakończenia może być różny.
W przypadku agentów nieprowadzących rozmów pliki zawierają dane z 24-godzinnego okresu poprzedzającego czas wygenerowania pliku. Jeśli np. raport rozliczeniowy zostanie wygenerowany 5 maja o godzinie 11:00 czasu UTC, będzie zawierać dane z okresu od 4 maja od godziny 11:00 czasu UTC do 5 maja do godziny 11:00 czasu UTC.
W przypadku agentów konwersacyjnych pliki zawierają dane z 24-godzinnego okresu 1–2 dni przed czasem wygenerowania pliku. Jeśli np. raport dotyczący płatności zostanie wygenerowany 5 maja o godzinie 11:00 czasu UTC, może zawierać dane z okresu od 3 maja, godz. 11:00 czasu UTC do 4 maja, godz. 11:00 czasu UTC.
Opóźnienie wynika z tego, że aktywność RCS Business Messaging w przypadku agentów rozmowy jest powiązana z rozmowami, które mogą trwać do 48 godzin. Ten czas oczekiwania umożliwia usłudze RCS Business Messaging rejestrowanie wszystkich wiadomości w rozmowie przed obliczeniem zdarzenia podlegającego opłacie. Więcej informacji o agentach konwersacyjnych znajdziesz w artykule Kategorie rozliczeń za agentów.
Najważniejsze kwestie:
Brak aktywności: jeśli w danym dniu nie wystąpi żadna aktywność na platformie, plik nie jest generowany.
Nazewnictwo: data w nazwie pliku to data wygenerowania pliku, a nie data danych w nim zawartych.
Przechowywanie: pliki są przechowywane przez maksymalnie 63 dni, a następnie usuwane.
Za pomocą tych plików możesz aktualizować hurtownię danych o najnowsze dane o korzystaniu z platformy.
Przechowywanie plików i dostęp do nich
Pliki danych są szyfrowane w spoczynku i podczas przesyłania.
Aby pobierać pliki danych za pomocą protokołu SFTP (Secure File Transfer Protocol), podaj swój klucz publiczny SFTP. Aby wygenerować klucze, przeczytaj artykuł Generowanie pary kluczy SSH do użycia ze skrzynką referencyjną SFTP.
Serwer SFTP to partnerupload.google.com, a połączenie odbywa się na porcie o wysokim numerze (19321), co zapewnia dodatkowe bezpieczeństwo.
Aby uzyskać dostęp do plików danych, możesz użyć tego polecenia:
sftp -i <path_to_private_key> -P 19321 <username>@partnerupload.google.com
Google udostępnia nazwy użytkowników kont w tych formatach:
rbmreports-billableevents-<carrier name>rbmreports-activity-<carrier name>
Google określa <carrier name> i udostępnia osobne konto dla każdego typu raportu.
Dostęp do różnych rodzajów raportów jest możliwy na osobnych kontach.
Dostępność pliku
Jeśli nie wygenerowano jeszcze żadnych plików danych, pojawi się błąd SFTP podobny do remote readdir("/"): No such file or directory. Jest to oczekiwane zachowanie.
Jeśli nie ma ruchu RCS dla firm, który można by uwzględnić w raporcie, plik nie zostanie wygenerowany. Oznacza to, że w niektóre dni nie będą generowane żadne pliki. Jeśli potrzebujesz pustych plików, aby usprawnić proces, napisz na adres rbm-support@google.com.
Raporty rozliczeniowe
Raporty dotyczące płatności to zapisy zdarzeń podlegających opłacie, które są obliczane na podstawie kategorii rozliczeniowej agenta i typu wysyłanych przez niego wiadomości. Raporty dotyczące płatności są dostępne dla wszystkich operatorów, którzy aktywnie korzystają z RCS dla firm.
Raporty rozliczeniowe 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 agentów
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 rodzaju wiadomości, które może wysłać agent. Określa jednak, w jaki sposób agent będzie obciążany opłatami za wiadomości. Dwie główne kategorie rozliczeń zostały opisane w tej tabeli.
| Kategoria fakturowania | Typ agenta | Przykłady użycia | Forma płatności |
|---|---|---|---|
| Niekonwersacyjny | Agenci, którzy wysyłają głównie wiadomości w jedną stronę. |
|
Opłaty są naliczane za każdą wiadomość dostarczoną do użytkownika. |
| Konwersacyjny | Agenty zaprojektowane do interakcji z użytkownikami. |
|
Płatność za rozmowę: jeśli jedna ze stron (agent lub użytkownik) odpowie na wiadomość od drugiej strony w ciągu 24 godzin, rozpocznie się rozmowa. W oknie rozmowy (24 godziny od pierwszej odpowiedzi) agent i użytkownik mogą wymieniać dowolną liczbę wiadomości, a agentowi zostanie naliczona stała opłata za rozmowę. Płatność za wiadomość: jeśli agent wyśle wiadomość, na którą użytkownik nie odpowie w ciągu 24 godzin, agent zostanie obciążony opłatą za tę wiadomość, podobnie jak w przypadku agenta nieprowadzącego rozmowy. |
Na diagramie poniżej przedstawiono przykład sesji rozliczeniowej A2P w przypadku agentów konwersacyjnych:
Agenty konwersacyjne a agenty niekonwersacyjne
Istnieją 2 główne kategorie rozliczeń: konwersacyjne i niekonwersacyjne.
Kluczowa różnica między kategoriami rozliczeń dotyczy agentów konwersacyjnych i niekonwersacyjnych:
Za każdą wiadomość dostarczoną użytkownikowi przez agentów nieprowadzących rozmowy naliczana jest opłata.
- Ta kategoria jest najlepsza w przypadku agentów, którzy nie oczekują częstych odpowiedzi.
Za rozmowy z agentami konwersacyjnymi pobierana jest stała opłata. Rozmowy 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 podlegające rozliczeniu
W raportach rozliczeniowych rejestrowanych jest 5 rodzajów zdarzeń podlegających opłacie. Te zdarzenia obejmują zdarzenia MT i MO, które są określane jako zdarzenia A2P i P2A.
- A2P (Application-to-Person) to MT (Mobile Terminated): wiadomość wysłana przez firmę.
- P2A (Person-to-Application) is MO (Mobile Originated): wiadomość lub działanie zainicjowane przez użytkownika.
W tabeli poniżej opisano każde zdarzenie podlegające rozliczeniu w przypadku agentów nieprowadzących i prowadzących rozmowy.
| Zdarzenie | Opis | Agenty niekonwersacyjne | Agenty konwersacyjne |
|---|---|---|---|
basic_message
|
Wiadomość A2P zawierająca tylko tekst o długości maksymalnie 160 znaków. Jeśli tekst zawiera adres URL witryny z tagami openGraph, wiadomość może wyświetlać podgląd obrazu bez dodatkowych opłat dla partnera. | Zawsze traktowane jako osobne zdarzenie podlegające opłacie, niezależnie od tego, czy użytkownik odpowie. | Traktowane jako osobne zdarzenie podlegające opłacie, chyba że użytkownik odpowie w ciągu 24 godzin. W takim przypadku wiadomość staje się częścią a2p_conversation.
|
single_message
|
Wiadomość A2P, która zawiera treści multimedialne lub jest wiadomością tekstową o długości powyżej 160 znaków. | Zawsze traktowane jako osobne zdarzenie podlegające opłacie, niezależnie od tego, czy użytkownik odpowie. | Traktowane jako osobne zdarzenie podlegające opłacie, 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 odpowie na wiadomość A2P w ciągu 24 godzin od jej otrzymania, poza istniejącą rozmową. | Nie dotyczy. Agenci niekonwersacyjni nigdy nie generują tego typu zdarzeń. | Jeśli wiadomość P2A zostanie dostarczona w ciągu 24 godzin od wysłania wielu wiadomości A2P, do rozpoczęcia rozmowy zostanie użyta tylko wiadomość A2P, która bezpośrednio poprzedza wiadomość P2A. Ta wiadomość A2P i wszystkie wiadomości dostarczone w ciągu następnych 24 godzin są częścią a2p_conversation.
|
p2a_conversation (zainicjowane przez użytkownika)
|
Rozpoczyna się, gdy agent odpowie na wiadomość P2A w ciągu 24 godzin od jej otrzymania, poza istniejącą rozmową. | Nie dotyczy. Agenci niekonwersacyjni 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 rozpoczęcia rozmowy zostanie użyta tylko wiadomość P2A, która bezpośrednio poprzedza wiadomość A2P. Ta wiadomość P2A i wszystkie wiadomości dostarczone w ciągu następnych 24 godzin należą do p2a_conversation.
|
p2a_message
|
wiadomości P2A dowolnego typu; | Zawsze traktowane jako osobne zdarzenie podlegające opłacie, niezależnie od tego, czy agent odpowie. | Traktowane jako osobne zdarzenie podlegające opłacie, chyba że pracownik obsługi klienta odpowie w ciągu 24 godzin. |
Kategorie fakturowania a zdarzenia podlegające rozliczeniu
Rozróżnienie między kategoriami płatności agenta a zdarzeniami podlegającymi opłacie ma kluczowe znaczenie dla zrozumienia, jak naliczane są opłaty za agenta.
- Kategoria płatności to stała klasyfikacja, którą wybierasz podczas tworzenia agenta. Określa metodę rozliczania agenta: za wiadomość (agenci niekonwersacyjni) lub za rozmowę (agenci konwersacyjni).
- Zdarzenia podlegające opłacie to interakcje między agentem RCS dla firm a użytkownikiem, które są śledzone na potrzeby rozliczeń (np.
basic_message,single_message,a2p_conversation).
Generowanie raportu rozliczeniowego
Tylko agenty z ruchem pochodzącym od osób niebędących testerami generują zdarzenia podlegające rozliczeniu. Aktywność z testowych numerów telefonów nie pojawia się w raportach rozliczeniowych.
W tych raportach zakłada się, że zdarzenia są rozliczane po dostarczeniu wiadomości, a nie po ich wysłaniu. Nie dostarczona wiadomość lub wiadomość anulowana przed dostarczeniem nie powoduje zdarzenia podlegającego opłacie.
Format raportu rozliczeniowego
Raporty rozliczeniowe mają format nazwy pliku rbm_billable_events_YYYY-MM-DD.csv.
Data w nazwie pliku to data jego wygenerowania.
Każdy wiersz w raporcie to rekord reprezentujący pojedyncze zdarzenie podlegające rozliczeniu. Pola w rekordzie są rozdzielone tabulatorami. Na przykład 2 rozmowy A2P z tym samym agentem wygenerują 2 osobne zdarzenia podlegające opłacie i 2 rekordy w raporcie rozliczeniowym.
Każdy rekord w raporcie zawiera te informacje o każdym zdarzeniu podlegającym opłacie:
| Pole | Format | Opis | Przykład |
|---|---|---|---|
billing_event_id
|
ciąg znaków | Identyfikator UUID. Losowa liczba generowana dla każdego nowego zdarzenia w momencie jego utworzenia. | 242f1d9f-7c3f-4e5b-ab3f-818f188fa3ff
|
type
|
ciąg znaków | Typ wydarzenia:
Standardowy model płatności Model rozliczeń w Stanach Zjednoczonych |
single_message
|
agent_id
|
ciąg znaków | Unikalny identyfikator agenta, który brał udział 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, który wystawia rachunki za wydarzenia.
|
carrier
|
max_duration_single_message
|
liczba | Maksymalny czas (w godzinach), w którym użytkownik może odpowiedzieć na wiadomość agenta, zanim zamknie się okno rozpoczęcia rozmowy i wiadomość zostanie zaklasyfikowana jako zdarzenie single_message.
|
24
|
max_duration_a2p_conversation
|
liczba | Maksymalny czas trwania rozmowy A2P w godzinach. Mierzony od pierwszej odpowiedzi użytkownika na początkową wiadomość agenta. | 24
|
max_duration_p2a_conversation
|
liczba | Maksymalny czas trwania rozmowy P2A w godzinach. Mierzony od pierwszej wiadomości użytkownika w rozmowie. | 24
|
start_time
|
YYYY-mm-ddTHH:00:00Z | Data i godzina rozpoczęcia wydarzenia w formacie ISO 8601 w strefie czasowej UTC zaokrąglone do najbliższej godziny.
Wiadomości A2P
Wiadomości P2A
|
2019-07-25T08:00:00Z
|
duration
|
liczba | Czas trwania wydarzenia zaokrąglony do najbliższej minuty.
Gdy typ zdarzenia to |
45
|
mt_messages
|
liczba | Liczba wiadomości wysłanych na urządzenia mobilne (A2P) w zdarzeniu. | 11
|
mo_messages
|
liczba | Liczba wiadomości wysłanych z urządzeń mobilnych (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 bajtów). | 912
|
agent_name
|
ciąg znaków |
Nazwa agenta, który uczestniczył w zdarzeniu. |
XYZ Mobile USA
|
owner_name
|
ciąg znaków | Nazwa obecnego właściciela konta partnera, na którym utworzono agenta. | XYZ Mobile
|
segment_count
|
liczba | Dotyczy tylko modelu rozliczeniowego w Stanach Zjednoczonych
Obliczona liczba segmentów dla zdarzeń |
5
|
Przykładowy raport zdarzeń płatności
Przykładowe raporty można pobrać:
- Raport rozliczeniowy dla standardowego modelu rozliczeń
- Raport rozliczeniowy dla modelu rozliczeniowego w Stanach Zjednoczonych
Typowy rozmiar pliku
Rozmiar dziennego raportu od aktywnego partnera RCS Business Messaging zależy od tego, ile aktywności wygenerował on w sieci operatora. Jeśli na przykład raport zawiera 53 tys. rekordów, plik będzie miał około 8 MB.
Historia aktywności
Dzienniki aktywności zawierają nieprzetworzone dane o aktywności na platformie RCS dla firm. Możesz używać tych dzienników do kontrolowania zdarzeń rozliczeniowych i tworzenia zdarzeń niestandardowych.
Uwaga: w dziennikach aktywności uwzględniany jest tylko ruch z numerów telefonów innych niż numery testerów.
Dzienniki aktywności zawierają informacje umożliwiające identyfikację osoby, takie jak szczegółowe informacje o transakcjach i numery MSISDN subskrybentów, dlatego są dostępne tylko wtedy, gdy operator korzysta z RCS na podstawie własnych Warunków usługi. Jeśli w Twoich sieciach występuje ruch RCS dla firm i włączysz aktywność RCS w RCS Google zgodnie z Warunkami korzystania z usług Google, nie będziesz mieć dostępu do dzienników aktywności.
Format historii aktywności
Dzienniki aktywności mają format nazwy pliku rbm_activity_YYYY-MM-DD.csv. Data w nazwie pliku to data jego wygenerowania.
Pola w rekordzie są rozdzielone znakiem tabulacji, a każdy rekord znajduje się w osobnym wierszu.
Każdy rekord w dzienniku aktywności zawiera te pola w przypadku każdej aktywności:
| 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 związanego z płatnościami. Może być puste, jeśli aktywność nie jest powiązana ze zdarzeniem rozliczeniowym, np. text_message bez odpowiedniego 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 | Numer MSISDN użytkownika. | 918369110173
|
direction
|
ciąg znaków | Kierunek, w którym wysyłana jest wiadomość:
|
MT
|
time
|
YYYY-mm-ddTHH:MM:SS.SSSZ | Data i godzina przesłania zdarzenia na platformę RCS dla firm 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ą moment przesłania zdarzenia do platformy RCS for Business. W przypadku zdarzeń, które dostarczają treści do użytkownika, zdarzenie nie zostanie zarejestrowane w dzienniku aktywności, dopóki wiadomość nie zostanie dostarczona.
Jeśli np. wiadomość RCS dla firm zostanie wysłana do użytkownika w środę o 13:00, a odbiorca będzie offline do niedzieli do 9:00, zdarzenie pojawi się w dzienniku aktywności wygenerowanym w niedzielę, ale sygnatura czasowa będzie wskazywać środę o 13:00.