इस पेज पर उन डेटा फ़ाइलों के बारे में बताया गया है जिन्हें RBM बनाता है, ताकि कैरियर को बिलिंग और ऑडिटिंग में मदद मिल सके. आरबीएम बिलिंग मॉडल के बारे में आम तौर पर पूछे जाने वाले सवालों के जवाब पाने के लिए, आरबीएम बिलिंग के बारे में अक्सर पूछे जाने वाले सवाल पर जाएं.
| फ़ाइल | ब्यौरा | किसके पास ऐक्सेस है |
|---|---|---|
| बिलिंग इवेंट की रिपोर्ट | लॉन्च किए गए एजेंट और उपयोगकर्ताओं के बीच, बिलिंग के लायक इवेंट की एग्रीगेट रिपोर्ट. | आरबीएम (आरसीएस कारोबार मैसेज सेवा) की सुविधा देने वाले सभी कैरियर. |
| गतिविधि लॉग | आरबीएम गतिविधि का रॉ डेटा लॉग. इसमें बिलिंग वाले इवेंट भी शामिल हैं. | मोबाइल और इंटरनेट सेवा देने वाली ऐसी कंपनियां जो आरबीएम (आरसीएस बिज़नेस मैसेजिंग) की सुविधा को चालू कर रही हैं और Google की आरसीएस सेवा को अपनी सेवा की शर्तों (ToS) के तहत मैनेज कर रही हैं. |
फ़ाइल जनरेट करना
हर डेटा फ़ाइल, कोऑर्डिनेटेड यूनिवर्सल टाइम (यूटीसी) में आरबीएम के इस्तेमाल के एक दिन की जानकारी दिखाती है. फ़ाइलें हर दिन जनरेट होती हैं. जनरेट होने की प्रोसेस में कई घंटे लग सकते हैं. साथ ही, इसे पूरा होने में लगने वाला समय अलग-अलग हो सकता है.
नॉन-बातचीत वाले एजेंट के लिए, फ़ाइलों में फ़ाइल जनरेट होने के समय से ठीक पहले के 24 घंटे की अवधि का डेटा होता है. उदाहरण के लिए, अगर बिलिंग इवेंट की रिपोर्ट 5 मई को सुबह 11:00 बजे यूटीसी जनरेट की जाती है, तो इसमें 4 मई को सुबह 11:00 बजे यूटीसी से 5 मई को सुबह 11:00 बजे यूटीसी तक का डेटा शामिल होगा.
बातचीत वाले एजेंट के लिए, फ़ाइलों में फ़ाइल जनरेट होने के समय से 1-2 दिन पहले के 24 घंटे का डेटा होता है. उदाहरण के लिए, अगर बिलिंग इवेंट की रिपोर्ट 5 मई को सुबह 11:00 बजे यूटीसी जनरेट की जाती है, तो इसमें 3 मई को सुबह 11:00 बजे यूटीसी से 4 मई को सुबह 11:00 बजे यूटीसी तक का डेटा शामिल हो सकता है.
देरी की वजह यह है कि बातचीत वाले एजेंट के लिए आरबीएम गतिविधि, बातचीत से जुड़ी होती है. इसे पूरा होने में 48 घंटे लग सकते हैं. इस देरी की वजह से, आरबीएम को बिलिंग इवेंट का हिसाब लगाने से पहले, बातचीत में मौजूद सभी मैसेज कैप्चर करने का समय मिल जाता है. बातचीत वाले एजेंट के बारे में ज़्यादा जानने के लिए, एजेंट की बिलिंग कैटगरी देखें.
खास बातें:
कोई गतिविधि नहीं: अगर किसी दिन प्लैटफ़ॉर्म पर कोई गतिविधि नहीं होती है, तो कोई फ़ाइल जनरेट नहीं होती.
नाम देना: फ़ाइल के नाम में दी गई तारीख, फ़ाइल जनरेट होने की तारीख होती है, न कि उसमें मौजूद डेटा की तारीख.
निजी डेटा के रखरखाव की अवधि: फ़ाइलों को ज़्यादा से ज़्यादा 30 दिनों तक सेव करके रखा जाता है. इसके बाद, उन्हें मिटा दिया जाता है.
इन फ़ाइलों का इस्तेमाल करके, अपने डेटा वेयरहाउस को प्लैटफ़ॉर्म के इस्तेमाल से जुड़ी नई मेट्रिक के साथ अपडेट किया जा सकता है.
फ़ाइल का स्टोरेज और ऐक्सेस
डेटा फ़ाइलों को ट्रांसफ़र करने के दौरान और स्टोर करने के दौरान, दोनों ही स्थितियों में एन्क्रिप्ट (सुरक्षित) किया जाता है.
सिक्योर फ़ाइल ट्रांसफ़र प्रोटोकॉल (एसएफ़टीपी) की मदद से डेटा फ़ाइलें वापस पाने के लिए, अपनी एसएफ़टीपी सार्वजनिक कुंजी दें. कुंजियां जनरेट करने के लिए, एसएफ़टीपी ड्रॉपबॉक्स के लिए सिक्योर शेल (एसएसएच) कुंजी का जोड़ा जनरेट करना लेख पढ़ें.
एसएफ़टीपी सर्वर 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 जैसी एसएफ़टीपी गड़बड़ी दिखेगी.
अगर रिपोर्ट करने के लिए कोई आरबीएम ट्रैफ़िक नहीं है, तो कोई फ़ाइल जनरेट नहीं होगी. इसका मतलब है कि कुछ दिन ऐसे हो सकते हैं जब कोई फ़ाइल जनरेट न हो. अगर आपको अपनी प्रोसेस को बेहतर बनाने के लिए, खाली फ़ाइलें चाहिए, तो rbm-support@google.com पर संपर्क करें.
बिलिंग इवेंट की रिपोर्ट
बिलिंग इवेंट रिपोर्ट, बिलिंग इवेंट के रिकॉर्ड होते हैं. इनका हिसाब, एजेंट की बिलिंग कैटगरी और भेजे गए मैसेज के टाइप के आधार पर लगाया जाता है. बिलिंग इवेंट की रिपोर्ट, उन सभी कैरियर के लिए उपलब्ध हैं जो आरबीएम (आरसीएस बिज़नेस मैसेजिंग) को चालू कर रहे हैं.
बिलिंग इवेंट की रिपोर्ट में गोपनीय जानकारी होती है, लेकिन इसमें उपयोगकर्ता की व्यक्तिगत पहचान से जुड़ी जानकारी (पीआईआई) नहीं होती. जैसे, एमएसआईएसडीएन, हैश किया गया एमएसआईएसडीएन या उपयोगकर्ता का कोई यूनीक आइडेंटिफ़ायर.
एजेंट की बिलिंग कैटगरी
एजेंट बनाते समय, मालिक उसकी बिलिंग कैटगरी सेट करता है. यह इस बात पर निर्भर करता है कि एजेंट, उपयोगकर्ताओं के साथ कैसे इंटरैक्ट करेगा. बिलिंग कैटगरी से, यह तय नहीं होता कि एजेंट कितने या किस तरह के मैसेज भेज सकता है. हालांकि, इससे यह तय होता है कि मैसेज के लिए एजेंट को कैसे बिल भेजा जाएगा. बिलिंग की दो मुख्य कैटगरी के बारे में यहां दी गई टेबल में बताया गया है.
| बिलिंग की कैटगरी | एजेंट टाइप | इस्तेमाल के उदाहरण | बिलिंग विधि |
|---|---|---|---|
बातचीत वाली नहीं इसमें बेसिक मैसेज और सिंगल मैसेज की कैटगरी शामिल हैं. ध्यान दें: अब इन दोनों कैटगरी के बीच कोई अंतर नहीं है. दोनों कैटगरी के एजेंट का बिल, बातचीत वाले एजेंट के तौर पर भेजा जाएगा.) |
ऐसे एजेंट जो मुख्य रूप से एकतरफ़ा मैसेज भेजते हैं. |
|
उपयोगकर्ता को डिलीवर किए गए हर मैसेज के लिए शुल्क लिया जाता है. |
| बोलचाल वाला | ऐसे एजेंट जिन्हें उपयोगकर्ताओं के साथ बार-बार इंटरैक्ट करने के लिए डिज़ाइन किया गया है. |
|
हर बातचीत के हिसाब से शुल्क: अगर कोई पक्ष (एजेंट या उपयोगकर्ता) दूसरे पक्ष के मैसेज का जवाब 24 घंटे के अंदर देता है, तो बातचीत शुरू हो जाती है. बातचीत की विंडो (पहले जवाब के 24 घंटे बाद) के दौरान, एजेंट और उपयोगकर्ता के बीच कितने भी मैसेज भेजे जा सकते हैं. साथ ही, बातचीत के लिए एजेंट को तय दर पर बिल भेजा जाएगा. हर मैसेज के लिए शुल्क: अगर एजेंट कोई ऐसा मैसेज भेजता है जिसका उपयोगकर्ता 24 घंटे के अंदर जवाब नहीं देता है, तो एजेंट को उस मैसेज के लिए शुल्क लिया जाएगा. यह शुल्क, बातचीत वाले एजेंट के शुल्क जैसा ही होगा. |
बातचीत वाले बनाम बातचीत न करने वाले एजेंट
बिलिंग की दो मुख्य कैटगरी हैं: बातचीत वाली और बातचीत वाली नहीं. बातचीत वाली कैटगरी में, बेसिक मैसेज और सिंगल मैसेज कैटगरी शामिल होती हैं. ये दोनों कैटगरी, काम करने के तरीके में एक जैसी होती हैं. इनमें से किसी भी कैटगरी में शामिल एजेंट को, बातचीत करने वाले एजेंट के तौर पर बिल किया जाता है.
बिलिंग कैटगरी में मुख्य अंतर, बातचीत वाले और बातचीत न करने वाले एजेंट के बीच का है:
बिना बातचीत वाले एजेंट, उपयोगकर्ता को भेजे गए हर मैसेज के लिए शुल्क लेते हैं.
- यह कैटगरी उन एजेंट के लिए सबसे सही है जिन्हें बार-बार जवाब मिलने की उम्मीद नहीं होती.
बातचीत करने वाले एजेंट के लिए, बातचीत के हिसाब से एक तय दर से शुल्क लिया जाता है. इसमें 24 घंटे के अंदर एक्सचेंज किए गए सभी मैसेज शामिल होते हैं.
- यह कैटगरी उन एजेंट के लिए सबसे अच्छी है जो उपयोगकर्ताओं के साथ कई बार बातचीत करते हैं.
बिलिंग इवेंट
बिलिंग इवेंट की रिपोर्ट में, पांच तरह के बिलिंग इवेंट रिकॉर्ड किए जाते हैं. इन इवेंट में A2P और P2A मैसेज शामिल होते हैं.
- A2P (ऐप्लिकेशन-टू-पर्सन): कारोबार से भेजा गया.
- P2A (व्यक्ति से ऐप्लिकेशन): उपयोगकर्ता से भेजा गया.
यहां दी गई टेबल में, हर बिलिंग इवेंट के बारे में बताया गया है, क्योंकि यह बातचीत वाले और बातचीत वाले एजेंट, दोनों पर लागू होता है.
| इवेंट | ब्यौरा | बातचीत वाले एजेंट | बातचीत करने वाले एजेंट |
|---|---|---|---|
basic_message
|
A2P मैसेज, जिसमें सिर्फ़ 160 या उससे कम वर्णों का टेक्स्ट शामिल हो. अगर टेक्स्ट में openGraph टैग वाली वेबसाइट का यूआरएल शामिल है, तो मैसेज में इमेज की झलक दिख सकती है. इसके लिए, पार्टनर को कोई शुल्क नहीं देना होगा. | इसे हमेशा एक अलग बिलिंग इवेंट के तौर पर माना जाता है. भले ही, उपयोगकर्ता ने जवाब दिया हो या नहीं. | जब तक उपयोगकर्ता 24 घंटे के अंदर जवाब नहीं देता, तब तक इसे अलग बिलिंग इवेंट माना जाता है. ऐसे में, मैसेज a2p_conversation का हिस्सा बन जाता है.
|
single_message
|
A2P मैसेज, जिसमें मल्टीमीडिया और/या 160 से ज़्यादा वर्णों वाला टेक्स्ट शामिल हो. | इसे हमेशा एक अलग बिलिंग इवेंट के तौर पर माना जाता है. भले ही, उपयोगकर्ता ने जवाब दिया हो या नहीं. | जब तक उपयोगकर्ता 24 घंटे के अंदर जवाब नहीं देता, तब तक इसे अलग बिलिंग इवेंट माना जाता है. ऐसे में, मैसेज a2p_conversation का हिस्सा बन जाता है.
|
a2p_conversation (कारोबारी ने शुरू किया)
|
यह तब शुरू होता है, जब कोई उपयोगकर्ता किसी मौजूदा बातचीत के अलावा, A2P मैसेज मिलने के 24 घंटों के अंदर उसका जवाब देता है. | यह बात मुझ पर लागू नहीं है. बातचीत वाले एजेंट के अलावा, अन्य एजेंट कभी भी इस तरह का इवेंट जनरेट नहीं करते. | अगर कई A2P मैसेज के 24 घंटे के अंदर P2A मैसेज डिलीवर किया जाता है, तो बातचीत शुरू करने के लिए सिर्फ़ उस A2P मैसेज का इस्तेमाल किया जाता है जो P2A मैसेज से ठीक पहले भेजा गया था. यह A2P मैसेज और अगले 24 घंटों में डिलीवर किए जाने वाले सभी मैसेज, a2p_conversation का हिस्सा हैं.
|
p2a_conversation (उपयोगकर्ता ने शुरू किया)
|
यह तब शुरू होता है, जब कोई एजेंट किसी मौजूदा बातचीत के अलावा, P2A मैसेज मिलने के 24 घंटे के अंदर उसका जवाब देता है. | यह बात मुझ पर लागू नहीं है. बातचीत वाले एजेंट के अलावा, अन्य एजेंट कभी भी इस तरह का इवेंट जनरेट नहीं करते. | अगर एक से ज़्यादा P2A मैसेज के 24 घंटे के अंदर कोई A2P मैसेज डिलीवर किया जाता है, तो बातचीत शुरू करने के लिए सिर्फ़ उस P2A मैसेज का इस्तेमाल किया जाता है जो A2P मैसेज से ठीक पहले भेजा गया था. यह P2A मैसेज और अगले 24 घंटों में डिलीवर किए जाने वाले सभी मैसेज, p2a_conversation का हिस्सा हैं.
|
p2a_message
|
किसी भी तरह का P2A मैसेज. | इसे हमेशा एक अलग बिलिंग इवेंट माना जाता है. भले ही, एजेंट ने जवाब दिया हो या नहीं. | जब तक एजेंट 24 घंटे के अंदर जवाब नहीं देता, तब तक इसे अलग बिलिंग इवेंट माना जाता है. |
बिलिंग इवेंट बनाम बिलिंग कैटगरी
basic_message और single_message बिलिंग इवेंट को बुनियादी मैसेज और एक मैसेज की बिलिंग कैटगरी के साथ नहीं जोड़ा जाना चाहिए.
कोई भी एजेंट (बिलिंग कैटगरी के बावजूद)
basic_messageऔरsingle_messageबिलिंग इवेंट जनरेट कर सकता है.बुनियादी मैसेज और एक मैसेज की बिलिंग कैटगरी का इस्तेमाल, बातचीत वाले एजेंट के अलावा अन्य एजेंट को अलग-अलग कैटगरी में बांटने के लिए किया जाता है. इन बिलिंग कैटगरी में मौजूद एजेंट, बातचीत वाले बिलिंग इवेंट (
a2p_conversationsयाp2a_conversations) जनरेट नहीं करते. इसके बजाय, वे अलग-अलगbasic_message,single_message, औरp2a_messageबिलिंग इवेंट जनरेट करते हैं.
बिलिंग रिपोर्ट जनरेट करना
सिर्फ़ ऐसे एजेंट बिलिंग इवेंट जनरेट करते हैं जिनके पास टेस्टर ट्रैफ़िक नहीं होता. टेस्ट फ़ोन नंबर से की गई गतिविधि, बिलिंग इवेंट की रिपोर्ट में नहीं दिखती.
इन रिपोर्ट में यह माना जाता है कि मैसेज भेजे जाने के बजाय, मैसेज डिलीवर होने पर इवेंट के लिए शुल्क लिया जाता है. डिलीवर न किया गया मैसेज या डिलीवरी से पहले रद्द किया गया मैसेज, बिलिंग इवेंट को ट्रिगर नहीं करता.
बिलिंग रिपोर्ट का फ़ॉर्मैट
बिलिंग इवेंट रिपोर्ट, फ़ाइल नाम के फ़ॉर्मैट
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 फ़ॉर्मैट में. इसे सबसे नज़दीकी घंटे तक राउंड किया गया है.
A2P मैसेज
P2A मैसेज
|
2019-07-25T08:00:00Z
|
duration
|
संख्या | इवेंट की अवधि, जिसे सबसे नज़दीकी मिनट में बदल दिया जाता है.
जब इवेंट टाइप |
45
|
mt_messages
|
संख्या | इवेंट में मोबाइल-टर्मिनेटेड (A2P) मैसेज की संख्या. | 11
|
mo_messages
|
संख्या | इवेंट में मोबाइल से भेजे गए (P2A) मैसेज की संख्या. | 9
|
size_kilobytes
|
संख्या | इवेंट में मैसेज से अटैच की गई सभी फ़ाइलों का साइज़, जो सबसे नज़दीकी किलोबाइट (1 केबी = 1024 बाइट) में बदल दिया जाता है. | 912
|
agent_name
|
स्ट्रिंग |
इवेंट में हिस्सा लेने वाले एजेंट का नाम. |
XYZ Mobile USA
|
owner_name
|
स्ट्रिंग | उस पार्टनर खाते के मौजूदा मालिक का नाम जहां एजेंट बनाया गया था. | XYZ Mobile
|
बिलिंग इवेंट रिपोर्ट का सैंपल
बिलिंग रिपोर्ट की सैंपल फ़ाइल डाउनलोड के लिए उपलब्ध है.
फ़ाइल का सामान्य साइज़
किसी चालू RBM पार्टनर की रोज़ की रिपोर्ट में करीब 53,000 रिकॉर्ड हो सकते हैं और उसका साइज़ करीब 8 एमबी हो सकता है.
गतिविधि लॉग
गतिविधि लॉग, RBM प्लैटफ़ॉर्म पर की गई गतिविधि का रॉ डेटा देते हैं. बिलिंग इवेंट का ऑडिट करने और कस्टम इवेंट बनाने के लिए, इन लॉग का इस्तेमाल किया जा सकता है.
ध्यान दें: गतिविधि के लॉग में, सिर्फ़ उन फ़ोन नंबर से आने वाला ट्रैफ़िक शामिल होता है जो टेस्टर के नहीं हैं.
गतिविधि के लॉग में, व्यक्तिगत पहचान से जुड़ी जानकारी (पीआईआई) होती है. जैसे, लेन-देन की पूरी जानकारी और सदस्य के एमएसआईएसडीएन. ये लॉग सिर्फ़ तब उपलब्ध होते हैं, जब कोई कैरियर अपनी सेवा की शर्तों के तहत आरसीएस की सुविधा दे रहा हो. अगर आपके नेटवर्क पर आरबीएम ट्रैफ़िक है और आपने Google के सेवा की शर्तों के तहत, Google आरसीएस की मदद से आरसीएस गतिविधि चालू की है, तो आपके पास गतिविधि लॉग का ऐक्सेस नहीं होगा.
गतिविधि लॉग का फ़ॉर्मैट
गतिविधि लॉग, फ़ाइल के नाम के फ़ॉर्मैट 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
|
स्ट्रिंग | उपयोगकर्ता का एमएसआईएसडीएन. | 918369110173
|
direction
|
स्ट्रिंग | मैसेज भेजने की दिशा:
|
MT
|
time
|
YYYY-mm-ddTHH:MM:SS.SSSZ | यूटीसी फ़ॉर्मैट में, RBM प्लैटफ़ॉर्म पर इवेंट सबमिट करने की तारीख और समय. टाइमस्टैंप देखें. | 2019-07-25T00:29:07.033Z
|
type
|
स्ट्रिंग | गतिविधि का टाइप:
|
text_message
|
size_bytes
|
स्ट्रिंग | गतिविधि में अटैच की गई फ़ाइलों का साइज़, बाइट में. | 912
|
टाइमस्टैंप
गतिविधि लॉग में मौजूद टाइमस्टैंप से पता चलता है कि RBM प्लैटफ़ॉर्म पर इवेंट कब सबमिट किया गया था. उपयोगकर्ता को कॉन्टेंट डिलीवर करने वाले इवेंट के लिए, इवेंट तब तक गतिविधि लॉग में रिकॉर्ड नहीं किया जाएगा, जब तक मैसेज डिलीवर नहीं हो जाता.
उदाहरण के लिए, अगर किसी उपयोगकर्ता को बुधवार को दोपहर 1:00 बजे आरबीएम मैसेज भेजा जाता है और वह रविवार को सुबह 9:00 बजे तक ऑफ़लाइन रहता है, तो इवेंट रविवार के लिए जनरेट किए गए गतिविधि लॉग में दिखेगा. हालांकि, टाइमस्टैंप बुधवार, दोपहर 1:00 बजे का होगा.