इस पेज पर, उन डेटा फ़ाइलों के बारे में बताया गया है जिन्हें RCS for Business, मोबाइल और इंटरनेट सेवा देने वाली कंपनियों की बिलिंग और ऑडिटिंग में मदद करने के लिए बनाता है.
| फ़ाइल | ब्यौरा | किसके पास ऐक्सेस है |
|---|---|---|
| बिलिंग रिपोर्ट | लॉन्च किए गए एजेंट और उपयोगकर्ताओं के बीच, बिल किए जा सकने वाले इवेंट की एग्रीगेट की गई रिपोर्ट. | सभी मोबाइल और इंटरनेट सेवा देने वाली कंपनियां, जो RCS for Business का इस्तेमाल कर रही हैं. |
| गतिविधि लॉग | RCS for Business की गतिविधि का रॉ डेटा लॉग. इसमें बिल किए जा सकने वाले इवेंट शामिल हैं. | मोबाइल और इंटरनेट सेवा देने वाली ऐसी कंपनियां जो RCS for Business की सुविधा चालू रखती हैं और Google RCS Service को अपनी सेवा की शर्तों (टीओएस) के तहत मैनेज करती हैं. |
RCS for Business, अमेरिका से बाहर के ट्रैफ़िक के लिए स्टैंडर्ड बिलिंग मॉडल का इस्तेमाल करता है. ज़्यादा जानकारी के लिए, बिलिंग से जुड़े अक्सर पूछे जाने वाले सवाल देखें.
फ़ाइल जनरेट करना
हर डेटा फ़ाइल में, पैसिफ़िक स्टैंडर्ड टाइम (पीएसटी) के हिसाब से, एक दिन के लिए RCS for Business के इस्तेमाल की जानकारी होती है. फ़ाइलें हर दिन जनरेट होती हैं. इनमें पिछले 24 घंटों (आधी रात से आधी रात तक) की गतिविधि दिखती है. जनरेट करने की प्रोसेस में कई घंटे लग सकते हैं. साथ ही, इसे पूरा होने में लगने वाला समय अलग-अलग हो सकता है.
- बातचीत नहीं करने वाले एजेंट के लिए, फ़ाइलों में उस 24 घंटे की अवधि का डेटा होता है जो फ़ाइल जनरेट होने के दिन से ठीक पहले की होती है. उदाहरण के लिए, 5 मई को जनरेट की गई रिपोर्ट में, 4 मई को रात 12 बजे से लेकर 5 मई को रात 12 बजे तक का डेटा शामिल होता है. यह समय, पीएसटी टाइमज़ोन के हिसाब से दिया गया है.
बातचीत वाले एजेंट के लिए, फ़ाइलों में फ़ाइल जनरेट होने के समय से एक से दो दिन पहले के 24 घंटे का डेटा होता है. उदाहरण के लिए, 5 मई को जनरेट की गई रिपोर्ट में, 2 मई या 3 मई के 24 घंटे का डेटा शामिल होता है. तय किया गया समय, पीएसटी टाइमज़ोन के हिसाब से है.
देर होने की वजह यह है कि बातचीत करने वाले एजेंट के लिए, RCS for Business की गतिविधि, सेशन से जुड़ी होती है. इसे पूरा होने में 24 घंटे लग सकते हैं. इस देरी से, RCS for Business को बिल किए जाने वाले इवेंट का हिसाब लगाने से पहले, बातचीत में शामिल सभी मैसेज कैप्चर करने में मदद मिलती है. कन्वर्सेशनल एजेंट के बारे में ज़्यादा जानकारी के लिए, एजेंट की बिलिंग कैटगरी पर जाएं.
खास बातें:
- कोई गतिविधि नहीं: डिफ़ॉल्ट रूप से, अगर किसी दिन प्लैटफ़ॉर्म पर कोई गतिविधि नहीं होती है, तो कोई फ़ाइल जनरेट नहीं होती है. हालांकि, अगर आपको खाली फ़ाइलें चाहिए, तो उन्हें पाने के लिए ऑप्ट इन किया जा सकता है. ऑप्ट इन करने के लिए, rbm-support@google.com पर संपर्क करें.
- नाम: फ़ाइल के नाम में दी गई तारीख, फ़ाइल जनरेट होने की तारीख होती है. यह फ़ाइल में मौजूद डेटा की तारीख नहीं होती.
- डेटा सेव करके रखने की अवधि: फ़ाइलें मिटाने से पहले, ज़्यादा से ज़्यादा 63 दिनों तक सेव करके रखी जाती हैं.
इन फ़ाइलों का इस्तेमाल करके, अपने डेटा वेयरहाउस को प्लैटफ़ॉर्म के इस्तेमाल से जुड़ी नई मेट्रिक के साथ अपडेट किया जा सकता है.
फ़ाइल स्टोरेज और ऐक्सेस
डेटा फ़ाइलों को एक जगह पर सेव करके रखे जाने के दौरान एन्क्रिप्ट (सुरक्षित) किया जाता है. साथ ही, उन्हें एक जगह से दूसरी जगह भेजने के दौरान भी एन्क्रिप्ट किया जाता है.
सिक्योर फ़ाइल ट्रांसफ़र प्रोटोकॉल (एसएफ़टीपी) से डेटा फ़ाइलें पाने के लिए, अपनी एसएफ़टीपी सार्वजनिक कुंजी दें. कुंजियां जनरेट करने के लिए, एसएफ़टीपी ड्रॉपबॉक्स के लिए सिक्योर शेल (एसएसएच) कुंजी का जोड़ा जनरेट करना लेख पढ़ें.
एसएफ़टीपी सर्वर partnerupload.google.com है. साथ ही, ज़्यादा सुरक्षा के लिए कनेक्शन, ज़्यादा पोर्ट नंबर (19321) पर है.
अपनी डेटा फ़ाइलों को ऐक्सेस करने के लिए, इस कमांड का इस्तेमाल करें:
sftp -i <path_to_private_key> -P 19321 <username>@partnerupload.google.com
Google, खाते के उपयोगकर्ता नाम इन फ़ॉर्मैट में उपलब्ध कराता है:
rbmreports-billableevents-<carrier name>rbmreports-activity-<carrier name>
Google, <carrier name> तय करता है और हर रिपोर्ट टाइप के लिए अलग खाता उपलब्ध कराता है.
अलग-अलग तरह की रिपोर्ट ऐक्सेस करने के लिए, अलग-अलग खाते दिए जाते हैं.
फ़ाइल की उपलब्धता
अगर अब तक कोई डेटा फ़ाइल जनरेट नहीं हुई है, तो आपको एसएफ़टीपी से जुड़ी गड़बड़ी दिखेगी. यह गड़बड़ी remote readdir("/"): No such file or directory जैसी होगी. यह गड़बड़ी दिखना सामान्य है.
अगर रिपोर्ट करने के लिए कोई RCS for Business ट्रैफ़िक नहीं है, तो फ़ाइल जनरेट नहीं होगी. इसका मतलब है कि कुछ दिनों तक कोई फ़ाइल जनरेट नहीं होगी. अगर आपको प्रोसेस को आसान बनाने के लिए, खाली फ़ाइलों की ज़रूरत है, तो RCS for Business की सहायता टीम से संपर्क करें.
बिलिंग रिपोर्ट
बिलिंग रिपोर्ट, बिलिंग के लायक इवेंट के रिकॉर्ड होते हैं. इनका हिसाब, एजेंट की बिलिंग कैटगरी और उसके भेजे गए मैसेज के टाइप के आधार पर किया जाता है. बिलिंग रिपोर्ट उन सभी कैरियर के लिए उपलब्ध हैं जो RCS for Business का इस्तेमाल कर रहे हैं.
बिलिंग रिपोर्ट में गोपनीय जानकारी होती है. हालांकि, इसमें उपयोगकर्ता की व्यक्तिगत पहचान से जुड़ी कोई जानकारी (पीआईआई) नहीं होती. जैसे, एमएसआईएसडीएन, हैश किया गया एमएसआईएसडीएन या उपयोगकर्ता का कोई यूनीक आइडेंटिफ़ायर.
एजेंट की बिलिंग कैटगरी
एजेंट बनाते समय, मालिक यह तय करता है कि एजेंट, उपयोगकर्ताओं के साथ कैसे इंटरैक्ट करेगा. इसके आधार पर, वह एजेंट की बिलिंग कैटगरी सेट करता है. बिलिंग कैटगरी से, एजेंट के भेजे जाने वाले मैसेज की संख्या या टाइप पर कोई पाबंदी नहीं लगती. हालांकि, इससे यह तय होता है कि एजेंट को मैसेज के लिए बिल कैसे भेजा जाएगा. बिलिंग की दो मुख्य कैटगरी के बारे में यहां दी गई टेबल में बताया गया है.
| बिलिंग कैटगरी | एजेंट का टाइप | इस्तेमाल के उदाहरण | बिलिंग विधि |
|---|---|---|---|
| सूचनाओं वाले मैसेज | ऐसे एजेंट जो मुख्य रूप से एकतरफ़ा मैसेज भेजते हैं. |
|
उपयोगकर्ता को भेजे गए हर मैसेज के लिए बिल किया जाता है. |
| Conversational | ऐसे एजेंट जो उपयोगकर्ताओं के साथ बार-बार बातचीत करने के लिए डिज़ाइन किए गए हैं. |
|
हर बातचीत के लिए बिल किया जाता है: अगर कोई पक्ष (एजेंट या उपयोगकर्ता), दूसरे पक्ष के मैसेज का जवाब 24 घंटे के अंदर देता है, तो बातचीत शुरू हो जाती है. बातचीत की अवधि (पहले जवाब के 24 घंटे बाद) के दौरान, एजेंट और उपयोगकर्ता जितने चाहें उतने मैसेज भेज सकते हैं. साथ ही, एजेंट से बातचीत के लिए तय की गई दर के हिसाब से शुल्क लिया जाएगा. हर मैसेज के हिसाब से बिल किया जाता है: अगर एजेंट ऐसा मैसेज भेजता है जिसका जवाब उपयोगकर्ता 24 घंटे के अंदर नहीं देता है, तो एजेंट को उस मैसेज के लिए बिल किया जाएगा. यह बिल, बातचीत न करने वाले एजेंट के लिए किए जाने वाले बिल जैसा ही होगा. |
नीचे दिए गए डायग्राम में, बातचीत करने वाले एजेंट के लिए A2P बिलिंग सेशन का उदाहरण दिखाया गया है:
बातचीत वाले एजेंट बनाम सूचनाएं देने वाले एजेंट
बिलिंग की दो मुख्य कैटगरी होती हैं: बातचीत वाली और बिना बातचीत वाली.
बिलिंग कैटगरी में मुख्य अंतर, बातचीत वाले एजेंट और बातचीत नहीं करने वाले एजेंट के बीच होता है:
बातचीत न करने वाले एजेंट को, उपयोगकर्ता को भेजे गए हर मैसेज के लिए बिल भेजा जाता है.
- यह कैटगरी उन एजेंट के लिए सबसे सही है जिन्हें बार-बार जवाब मिलने की उम्मीद नहीं होती.
बातचीत करने वाले एजेंट से, बातचीत के लिए एक तय शुल्क लिया जाता है. इसमें 24 घंटे की अवधि में एक्सचेंज किए गए सभी मैसेज शामिल होते हैं.
- यह कैटगरी उन एजेंट के लिए सबसे सही है जो लोगों के साथ सिलसिलेवार बातचीत करते हैं.
बिल किए जा सकने वाले इवेंट
बिलिंग रिपोर्ट में, बिलिंग के लिए ज़रूरी पांच तरह के इवेंट रिकॉर्ड किए जाते हैं. इन इवेंट में MT और MO इवेंट शामिल हैं. इन्हें A2P और P2A इवेंट कहा जाता है.
- A2P (ऐप्लिकेशन से व्यक्ति तक) MT (मोबाइल टर्मिनेटेड) होता है: यह कारोबार की ओर से भेजा गया मैसेज होता है.
- P2A (व्यक्ति से ऐप्लिकेशन) MO (मोबाइल से शुरू होने वाली कार्रवाई) है: यह उपयोगकर्ता की ओर से शुरू किया गया मैसेज या कार्रवाई होती है.
इस टेबल में, बिल किए जाने वाले हर इवेंट के बारे में बताया गया है. यह जानकारी, बातचीत वाले और बिना बातचीत वाले एजेंट, दोनों पर लागू होती है.
| इवेंट | ब्यौरा | सूचनाएं देने वाले एजेंट | बातचीत वाले एजेंट |
|---|---|---|---|
basic_message
|
ऐसा A2P मैसेज जिसमें सिर्फ़ टेक्स्ट शामिल हो और उसमें 160 या इससे कम वर्ण हों. अगर टेक्स्ट में openGraph टैग वाली वेबसाइट का यूआरएल शामिल है, तो मैसेज में इमेज का पूर्वावलोकन दिख सकता है. इसके लिए, पार्टनर को कोई अतिरिक्त शुल्क नहीं देना होगा. | इसे हमेशा बिल किया जाने वाला एक इवेंट माना जाता है. भले ही, उपयोगकर्ता जवाब दे या न दे. | इसे बिल किया जा सकने वाला एक अलग इवेंट माना जाता है. हालांकि, अगर उपयोगकर्ता 24 घंटे के अंदर जवाब देता है, तो ऐसा नहीं होगा. ऐसे में, मैसेज a2p_conversation का हिस्सा बन जाता है.
|
single_message
|
ए2पी मैसेज, जिसमें रिच कॉन्टेंट होता है या जो सिर्फ़ टेक्स्ट वाला मैसेज होता है और उसमें 160 से ज़्यादा वर्ण होते हैं. | इसे हमेशा बिल किया जाने वाला एक इवेंट माना जाता है. भले ही, उपयोगकर्ता जवाब दे या न दे. | इसे बिल किया जा सकने वाला एक अलग इवेंट माना जाता है. हालांकि, अगर उपयोगकर्ता 24 घंटे के अंदर जवाब देता है, तो ऐसा नहीं होगा. ऐसे में, मैसेज a2p_conversation का हिस्सा बन जाता है.
|
a2p_conversation (कारोबार की ओर से शुरू की गई बातचीत)
|
यह तब शुरू होती है, जब कोई व्यक्ति किसी मौजूदा बातचीत के अलावा, किसी A2P मैसेज का जवाब उसे मिलने के 24 घंटे के अंदर देता है. | यह बात मुझ पर लागू नहीं है. बातचीत न करने वाले एजेंट, इस तरह का इवेंट कभी जनरेट नहीं करते. | अगर कई A2P मैसेज के 24 घंटे के अंदर कोई P2A मैसेज डिलीवर किया जाता है, तो बातचीत शुरू करने के लिए सिर्फ़ उस A2P मैसेज का इस्तेमाल किया जाता है जो P2A मैसेज से ठीक पहले भेजा गया था. यह A2P मैसेज और अगले 24 घंटों में डिलीवर किए गए सभी मैसेज, a2p_conversation का हिस्सा हैं.
|
p2a_conversation (उपयोगकर्ता ने इसकी प्रोसेस शुरू की)
|
यह तब शुरू होता है, जब कोई एजेंट, P2A मैसेज मिलने के 24 घंटे के अंदर उसका जवाब देता है. ऐसा किसी मौजूदा बातचीत के बाहर किया जाता है. | यह बात मुझ पर लागू नहीं है. बातचीत न करने वाले एजेंट, इस तरह का इवेंट कभी जनरेट नहीं करते. | अगर कोई A2P मैसेज, एक से ज़्यादा P2A मैसेज के 24 घंटे के अंदर डिलीवर किया जाता है, तो बातचीत शुरू करने के लिए सिर्फ़ उस P2A मैसेज का इस्तेमाल किया जाता है जो A2P मैसेज से ठीक पहले भेजा गया था. यह P2A मैसेज और अगले 24 घंटों में डिलीवर किए गए सभी मैसेज, p2a_conversation का हिस्सा हैं.
|
p2a_message
|
किसी भी तरह का पी2ए मैसेज. | इसे हमेशा एक बिल किया जाने वाला इवेंट माना जाता है. भले ही, एजेंट जवाब दे या न दे. | इसे बिल किया जा सकने वाला एक इवेंट माना जाता है. हालांकि, अगर एजेंट 24 घंटे के अंदर जवाब देता है, तो ऐसा नहीं माना जाता. |
बिलिंग कैटगरी बनाम बिल किए जा सकने वाले इवेंट
एजेंट की बिलिंग कैटगरी और बिल किए जा सकने वाले इवेंट के बीच का अंतर समझना ज़रूरी है. इससे यह पता चलता है कि आपके एजेंट के लिए बिलिंग कैसे की जाती है.
- बिलिंग कैटगरी एक तय किया गया क्लासिफ़िकेशन होता है. इसे एजेंट बनाते समय चुना जाता है. इससे यह तय होता है कि आपके एजेंट को किस तरीके से बिल भेजा जाएगा: हर मैसेज के हिसाब से (बातचीत न करने वाले एजेंट) या हर बातचीत के हिसाब से (बातचीत करने वाले एजेंट).
- बिलिंग के लिए ट्रैक किए जाने वाले इवेंट, RCS for Business एजेंट और उपयोगकर्ता के बीच होने वाली बातचीत होती है. उदाहरण के लिए,
basic_message,single_message,a2p_conversation.
बिलिंग रिपोर्ट जनरेट करना
सिर्फ़ ऐसे एजेंट बिल करने लायक इवेंट जनरेट करते हैं जिनके पास टेस्टर ट्रैफ़िक नहीं होता. टेस्ट फ़ोन नंबर से की गई गतिविधि, बिलिंग रिपोर्ट में नहीं दिखती.
इन रिपोर्ट में यह माना जाता है कि मैसेज डिलीवर होने पर इवेंट के लिए बिल भेजा जाता है, न कि मैसेज भेजे जाने पर. अगर कोई मैसेज डिलीवर नहीं होता है या डिलीवरी से पहले रद्द कर दिया जाता है, तो बिलिंग वाला इवेंट ट्रिगर नहीं होता.
बिलिंग रिपोर्ट का फ़ॉर्मैट
बिलिंग रिपोर्ट में, फ़ाइल के नाम के लिए rbm_billable_events_YYYY-MM-DD.csv फ़ॉर्मैट का इस्तेमाल किया जाता है.
फ़ाइल के नाम में दी गई तारीख, फ़ाइल जनरेट होने की तारीख होती है.
रिपोर्ट की हर लाइन एक रिकॉर्ड है. यह बिल किए गए किसी एक इवेंट के बारे में बताती है. किसी रिकॉर्ड में मौजूद फ़ील्ड, टैब से अलग किए जाते हैं. उदाहरण के लिए, एक ही एजेंट के साथ हुई दो A2P बातचीत से, बिलिंग के लिए दो अलग-अलग इवेंट जनरेट होंगे. साथ ही, बिलिंग रिपोर्ट में दो रिकॉर्ड दिखेंगे.
रिपोर्ट के हर रिकॉर्ड में, बिल किए जा सकने वाले हर इवेंट के लिए यह जानकारी शामिल होती है.
| फ़ील्ड | फ़ॉर्मैट | ब्यौरा | उदाहरण |
|---|---|---|---|
billing_event_id
|
स्ट्रिंग | जनरेट किया गया आईडी, जो बिल किए जा सकने वाले इवेंट को अलग करता है. | 242f1d9f-7c3f-4e5b-ab3f-818f188fa3ff
|
type
|
स्ट्रिंग | इवेंट का टाइप:
|
single_message
|
agent_id
|
स्ट्रिंग | इवेंट में हिस्सा लेने वाले एजेंट के लिए यूनीक आइडेंटिफ़ायर. | rbm-welcome-bot@rbm.goog
|
agent_owner
|
स्ट्रिंग | उस पार्टनर खाते के मौजूदा मालिक का ईमेल पता जहां एजेंट बनाया गया था. | name@aggregator.com
|
billing_party
|
स्ट्रिंग | वह पार्टी जो इवेंट के लिए बिलिंग करती है.
|
carrier
|
max_duration_single_message
|
संख्या | वह ज़्यादा से ज़्यादा समय (घंटों में), जिसमें उपयोगकर्ता को एजेंट के मैसेज का जवाब देना होता है. इसके बाद, बातचीत शुरू करने वाली विंडो बंद हो जाती है और मैसेज को single_message इवेंट के तौर पर क्लासिफ़ाई किया जाता है.
|
24
|
max_duration_a2p_conversation
|
संख्या | A2P बातचीत की ज़्यादा से ज़्यादा अवधि, घंटों में. इसे एजेंट के शुरुआती मैसेज पर उपयोगकर्ता के पहले जवाब से मापा जाता है. | 24
|
max_duration_p2a_conversation
|
संख्या | P2A बातचीत की ज़्यादा से ज़्यादा अवधि, घंटों में. इसे बातचीत में उपयोगकर्ता के पहले मैसेज से मेज़र किया जाता है. | 24
|
start_time
|
YYYY-mm-ddTHH:00:00Z | यूटीसी में इवेंट शुरू होने की तारीख/समय. इसे ISO 8601 फ़ॉर्मैट में लिखा जाता है और सबसे नज़दीकी घंटे के हिसाब से राउंड किया जाता है.
ए2पी मैसेज
P2A मैसेज
|
2019-07-25T08:00:00Z
|
duration
|
संख्या | इवेंट की अवधि, जिसे सबसे नज़दीकी मिनट में बदल दिया जाता है.
बातचीत से जुड़े इवेंट के अलावा किसी अन्य इवेंट के लिए, वैल्यू 0 होती है. |
45
|
mt_messages
|
संख्या | इवेंट में, मोबाइल पर भेजे गए (A2P) मैसेज की संख्या. | 11
|
mo_messages
|
संख्या | इवेंट में, मोबाइल से भेजे गए (P2A) मैसेज की संख्या. | 9
|
size_kilobytes
|
संख्या | इवेंट में मौजूद मैसेज में अटैच की गई सभी फ़ाइलों का साइज़. इसे सबसे नज़दीकी किलोबाइट में बदला जाता है (1 केबी, 1024 बाइट के बराबर होता है). | 912
|
agent_name
|
स्ट्रिंग |
इवेंट में हिस्सा लेने वाले एजेंट का नाम. |
XYZ Mobile USA
|
owner_name
|
स्ट्रिंग | उस पार्टनर खाते के मौजूदा मालिक का नाम जहां एजेंट बनाया गया था. | XYZ Mobile
|
बिलिंग रिपोर्ट का सैंपल
सैंपल रिपोर्ट डाउनलोड करने के लिए उपलब्ध हैं:
फ़ाइल का सामान्य साइज़
आरसीएस फ़ॉर बिज़नेस पार्टनर की रोज़ाना की रिपोर्ट का साइज़, इस बात पर निर्भर करता है कि उन्होंने कैरियर के नेटवर्क पर कितनी गतिविधि की है. उदाहरण के लिए, अगर रिपोर्ट में 53,000 रिकॉर्ड हैं, तो फ़ाइल का साइज़ करीब 8 एमबी होगा.
गतिविधि लॉग
गतिविधि लॉग से, RCS for Business प्लैटफ़ॉर्म पर की गई गतिविधि के बारे में रॉ डेटा मिलता है. इन लॉग का इस्तेमाल, बिल किए जा सकने वाले इवेंट की ऑडिट करने और कस्टम इवेंट बनाने के लिए किया जा सकता है.
गतिविधि के लॉग में व्यक्तिगत पहचान से जुड़ी जानकारी (पीआईआई) होती है. जैसे, लेन-देन की पूरी जानकारी और सदस्य के एमएसआईएसडीएन. इसलिए, ये लॉग सिर्फ़ तब उपलब्ध होते हैं, जब कोई कैरियर अपनी सेवा की शर्तों के तहत आरसीएस की सुविधा दे रहा हो. अगर आपके नेटवर्क पर RCS for Business का ट्रैफ़िक है और आपने Google की सेवा की शर्तों के तहत, Google RCS के साथ आरसीएस गतिविधि चालू की है, तो आपके पास गतिविधि के लॉग का ऐक्सेस नहीं होगा.
गतिविधि लॉग का फ़ॉर्मैट
गतिविधि के लॉग, rbm_activity_YYYY-MM-DD.csv फ़ाइल नाम के फ़ॉर्मैट का इस्तेमाल करते हैं. फ़ाइल के नाम में मौजूद तारीख, फ़ाइल जनरेट होने की तारीख होती है.
किसी रिकॉर्ड में मौजूद फ़ील्ड को टैब से अलग किया जाता है. साथ ही, हर लाइन में एक रिकॉर्ड होता है.
गतिविधि लॉग में मौजूद हर रिकॉर्ड में, हर गतिविधि के लिए ये फ़ील्ड शामिल होते हैं:
| फ़ील्ड | फ़ॉर्मैट | ब्यौरा | उदाहरण |
|---|---|---|---|
activity_id
|
स्ट्रिंग | गतिविधि के लिए यूनीक आइडेंटिफ़ायर. | b422e1d3-ac99-442a-853d-a875d5e61762
|
billing_event_id
|
स्ट्रिंग | बिल किए गए इवेंट के लिए यूनीक आइडेंटिफ़ायर. अगर गतिविधि, बिलिंग वाले इवेंट से जुड़ी नहीं है, तो यह फ़ील्ड खाली हो सकता है. जैसे, text_message से जुड़ा कोई delivery_receipt_event न हो.
|
91yeb201-7c3b-412b-98d2-b0a0f7abe536
|
agent_id
|
स्ट्रिंग | एजेंट के लिए यूनीक आइडेंटिफ़ायर. | welcome-bot@rbm.goog
|
user_id
|
स्ट्रिंग | उपयोगकर्ता का MSISDN. | 918369110173
|
direction
|
स्ट्रिंग | मैसेज किस दिशा में भेजा गया है:
|
MT
|
time
|
YYYY-mm-ddTHH:MM:SS.SSSZ | यूटीसी फ़ॉर्मैट में, RCS for Business प्लैटफ़ॉर्म पर इवेंट सबमिट करने की तारीख और समय. टाइमस्टैंप देखें. | 2019-07-25T00:29:07.033Z
|
type
|
स्ट्रिंग | गतिविधि का टाइप:
|
text_message
|
size_bytes
|
स्ट्रिंग | गतिविधि में अटैच की गई फ़ाइलों का साइज़, बाइट में. | 912
|
टाइमस्टैंप
गतिविधि लॉग में मौजूद टाइमस्टैंप से पता चलता है कि किसी इवेंट को RCS for Business प्लैटफ़ॉर्म पर कब सबमिट किया गया था. किसी उपयोगकर्ता को कॉन्टेंट डिलीवर करने वाले इवेंट के लिए, मैसेज डिलीवर होने तक इवेंट को गतिविधि लॉग में रिकॉर्ड नहीं किया जाएगा.
उदाहरण के लिए, अगर किसी उपयोगकर्ता को बुधवार को दोपहर 1:00 बजे RCS for Business मैसेज भेजा जाता है और वह रविवार सुबह 9:00 बजे तक ऑफ़लाइन रहता है, तो यह इवेंट रविवार के लिए जनरेट किए गए गतिविधि लॉग में दिखेगा. हालांकि, टाइमस्टैंप बुधवार दोपहर 1:00 बजे का होगा.