सब्सक्राइबर डेटा और सेगमेंट के लिए टेलीकॉम स्टार्टर

यह गाइड Pushwoosh में एक टेलीकॉम सब्सक्राइबर प्रोफ़ाइल सेट करता है और इसे काम करने वाले सेगमेंट में बदलता है: बंडल समाप्ति रिमाइंडर, कम बैलेंस अलर्ट, टॉप-अप पुष्टि, और रोमिंग स्वागत संदेश। हर सेक्शन को पूरा करें और आपके द्वारा बनाया गया पहला सेगमेंट एक गैर-शून्य ऑडियंस लौटाएगा, इसलिए आपको सहायता से संपर्क करने की आवश्यकता नहीं है।

सबसे आम गलती टैग का प्रकार है। एक Integer टैग में संग्रहीत तारीख टैग सूची में ठीक दिखती है और चुपचाप हर डेट सेगमेंट को शून्य उपयोगकर्ता लौटाती है। पहले प्रकार चुनें, फिर डेटा लोड करें।

आवश्यक शर्तें

आपके Pushwoosh खाते में एक एप्लिकेशन, जिसमें SDK एकीकृत हो या API के माध्यम से डिवाइस पंजीकृत हों।
टैग सेट करने की अनुमति के साथ एक API एक्सेस टोकन।
सर्वर-टू-सर्वर अपडेट जॉब के लिए डेवलपर सहायता।
एक सब्सक्राइबर पहचानकर्ता जिसे आप Pushwoosh से मैप कर सकते हैं: या तो एक User ID (आमतौर पर MSISDN, सब्सक्राइबर का फ़ोन नंबर अंतर्राष्ट्रीय प्रारूप में, या एक आंतरिक सब्सक्राइबर आईडी) या डिवाइस HWID।

एक टेलीकॉम सब्सक्राइबर प्रोफ़ाइल कैसी दिखती है

नीचे दी गई तालिका में वे टैग सूचीबद्ध हैं जो मानक टेलीकॉम परिदृश्यों को कवर करते हैं। पहले डेटा लोड से पहले, ठीक इन्हीं प्रकारों के साथ उन्हें बनाएं।

टैग	प्रकार	उदाहरण मान	यह क्या संचालित करता है
`msisdn`	String	`923001234567`	पहचान और SMS टारगेटिंग
`tariff_plan`	String	`Gold Postpaid`	प्लान-विशिष्ट ऑफ़र
`prepaid_postpaid`	String	`prepaid`	बिलिंग मॉडल के अनुसार बेस को विभाजित करना
`balance`	Integer	`50`	कम बैलेंस अलर्ट
`bundle_id`	String	`DATA_5GB_30D`	रिमाइंडर किस बंडल के बारे में है
`bundle_expiry_date`	Date	`2026-09-20 21:00:00`	बंडल समाप्ति रिमाइंडर
`roaming_status`	Boolean	`true`	रोमिंग स्वागत संदेश और रोमिंग शुल्कों के बारे में चेतावनियाँ

उस तालिका में दो पंक्तियाँ यह तय करती हैं कि परिदृश्य काम करेंगे या नहीं।

bundle_expiry_date को एक Date टैग होना चाहिए। केवल Date टैग को रिलेटिव ऑपरेटर मिलते हैं, जैसे N से M दिन बाद, जो “बंडल तीन दिनों में समाप्त हो रहा है” को हर रात सेगमेंट की पुनर्गणना किए बिना व्यक्त करता है।
bundle_id समाप्ति तिथि से अलग रहता है। एक टैग तारीख रखता है, दूसरा यह रखता है कि यह किस बंडल से संबंधित है। दोनों को एक टैग में संग्रहीत करने के लिए सेगमेंट के अंदर एक स्ट्रिंग को पार्स करने की आवश्यकता होगी, जो सेगमेंट बिल्डर नहीं कर सकता है।

पहले अपलोड से पहले टैग का प्रकार क्यों तय किया जाता है

टैग पहली बार मान आने पर स्वचालित रूप से बनाए जाते हैं, और प्रकार का अनुमान उस पहले मान से लगाया जाता है। एक पूर्ण संख्या Integer बन जाती है, दशमलव बिंदु वाली संख्या Price बन जाती है, एक स्ट्रिंग String बन जाती है (या Date, यदि यह 2024-10-02 22:11 जैसे मान्यता प्राप्त दिनांक-समय प्रारूप से मेल खाती है), एक ऐरे List बन जाता है, और true/false Boolean बन जाता है।

टेलीकॉम डेटा पर अनुमान विफल हो जाता है, क्योंकि समाप्ति तिथियां आमतौर पर यूनिक्स टाइमस्टैम्प के रूप में भेजी जाती हैं:

आप bundle_expiry_date को संख्या 1758393600 के रूप में भेजते हैं। यह एक पूर्ण संख्या है, इसलिए टैग को Integer टैग के रूप में बनाया जाता है। मान सही ढंग से लोड होते हैं, टैग स्वस्थ दिखता है, और इसके लिए कभी भी कोई डेट ऑपरेटर पेश नहीं किया जाता है।
टैग पहले से ही Integer के रूप में मौजूद है और आप बाद में "2026-09-20" भेजने पर स्विच करते हैं। मान अब एक संख्या के रूप में पार्स नहीं होता है, इसलिए इसे बिना किसी त्रुटि के छोड़ दिया जाता है। API अभी भी सफलता के साथ उत्तर देता है, और डिवाइस अपना पुराना मान या कोई भी मान नहीं रखता है।

दोनों ही मामलों का अंत एक ऐसे सेगमेंट के साथ होता है जो शून्य उपयोगकर्ता लौटाता है और इसे समझाने के लिए कहीं कोई त्रुटि नहीं होती है।

बनाने के बाद टैग का प्रकार नहीं बदला जा सकता है। गलत प्रकार को ठीक करने का मतलब है सही प्रकार के साथ एक नया टैग बनाना और मानों को उसमें फिर से लोड करना। पुराना टैग सूची में तब तक रहता है जब तक आप उसे हटा नहीं देते।

दोनों मामलों को रोकने के लिए, प्रकार स्वयं सेट करें:

अपने कंट्रोल पैनल का Tags पेज खोलें।
टैग बनाएं पर क्लिक करें।
टैग का नाम दर्ज करें और सूची से उसका प्रकार चुनें। पहले अपलोड से पहले, उपरोक्त तालिका में प्रत्येक टैग के लिए दोहराएं।
bulkSetTags में, create_missing_tags: false भेजें। एक गुम टैग तब अनुमानित प्रकार के साथ बनाए जाने के बजाय एक त्रुटि लौटाएगा।

प्रोफ़ाइल को सर्वर-टू-सर्वर कैसे अपडेट करें

टेलीकॉम प्रोफ़ाइल डेटा दैनिक रूप से बदलता है, इसलिए इसे मोबाइल SDK से लोड करने के बजाय एक बैच जॉब के रूप में लोड किया जाता है।

अपनी तरफ से दैनिक डेल्टा बनाएं: वे सब्सक्राइबर जिनका बैलेंस, बंडल, या रोमिंग स्थिति पिछली बार चलने के बाद से बदल गई है। हर रात एक पूर्ण बेस रीलोड की शायद ही कभी आवश्यकता होती है और यह आपके अनुरोध की मात्रा को बढ़ाता है।
बैच को bulkSetTags पर भेजें, डिवाइस को user_id द्वारा संबोधित करें जब MSISDN आपकी User ID हो, या अन्यथा hwid द्वारा। एक अनुरोध में कई डिवाइस होते हैं, और विधि कम से कम 50 की अपेक्षा करती है। एक सब्सक्राइबर के लिए, इसके बजाय setTags का उपयोग करें।
जॉब समाप्त होने तक लौटाए गए request_id को bulkSetTags स्थिति के साथ पोल करें। इसे ?detailed=true के साथ अनुरोध करें और परिणाम लॉग करें, क्योंकि एक समाप्त जॉब हर मान के स्वीकार किए जाने के समान नहीं है।
विफल बैचों को उसी पेलोड के साथ पुनः प्रयास करें। एक टैग सेट करना इडेम्पोटेंट है: एक ही मान को दो बार भेजने से वही प्रोफ़ाइल बनी रहती है।

{
  "application": "XXXXX-XXXXX",
  "auth": "your API access token",
  "create_missing_tags": false,
  "devices": [{
    "user_id": "923001234567",
    "tags": {
      "bundle_id": "DATA_5GB_30D",
      "bundle_expiry_date": "2026-09-20 21:00:00",
      "balance": 50,
      "roaming_status": false
    }
  }]
}

एक Date टैग कौन से दिनांक प्रारूप स्वीकार करता है

एक Date टैग यूनिक्स एपोक टाइमस्टैम्प को सेकंड में संग्रहीत करता है। इनमें से एक भेजें:

सेकंड में एक एपोक मान, एक संख्या के रूप में: 1758393600।
सेपरेटर के साथ एक दिनांक-समय स्ट्रिंग: 2026-09-20 21:00:00, 2026-09-20 21:00, या 2026-09-20। बिना समय वाली तारीख का मतलब आधी रात है।
एक ऑफ़सेट के साथ एक ISO 8601 स्ट्रिंग: 2026-09-20T21:00:00+05:00।

दो प्रारूप इस तरह से व्यवहार करते हैं जो अधिकांश इंटीग्रेशन को आश्चर्यचकित करते हैं:

बिना टाइम ज़ोन वाली स्ट्रिंग को UTC के रूप में पढ़ा जाता है। इसे आपके स्थानीय समय में नहीं पढ़ा जाता है। एक बंडल जो कराची में 21:00 बजे समाप्त होता है, वह 2026-09-20T21:00:00+05:00 है, या मेल खाने वाला एपोक मान है। 2026-09-20 21:00:00 वास्तविक समय में तीन घंटे पहले है, जो सब्सक्राइबर्स को दैनिक रिमाइंडर तरंगों के बीच ले जाता है।
अंकों की एक स्ट्रिंग एक एपोक मान है, तारीख नहीं। "20260920" 20 सितंबर, 2026 नहीं है, यह 1970 की ओर इशारा करने वाला एक एपोक टाइमस्टैम्प है। या तो एक वास्तविक एपोक मान भेजें या सेपरेटर के साथ एक स्ट्रिंग।

एक मान जो किसी भी स्वीकृत प्रारूप से मेल नहीं खाता है, उसे अनुरोध को विफल किए बिना छोड़ दिया जाता है। यही कारण है कि उपरोक्त चरण 3 केवल HTTP स्थिति के बजाय जॉब परिणाम की जांच करता है।

सेगमेंट रेसिपी

नीचे दी गई प्रत्येक रेसिपी एक सेगमेंट है। Segments सेक्शन खोलें, बिल्डर खोलने के लिए सेगमेंट बनाएँ पर क्लिक करें, फिर सूचीबद्ध फ़िल्टर जोड़ें। पूर्ण बिल्डर वॉकथ्रू के लिए, टैग द्वारा सेगमेंट बनाएं देखें।

बंडल तीन दिनों में समाप्त हो रहा है

उन सब्सक्राइबर्स को टारगेट करता है जिनका वर्तमान बंडल तीन दिनों में समाप्त हो रहा है, ताकि रिमाइंडर तब पहुंचे जब नवीनीकरण अभी भी समझ में आता हो।

टैग: bundle_expiry_date
ऑपरेटर: ऑपरेटर सूची खोलें, सापेक्ष तिथियां सेक्शन में जाएं, और N से M दिन बाद चुनें
मान: 3 और 3

अंतिम-दिन के रिमाइंडर के लिए दोनों मानों को 1 और 1 में बदलें। जब संदेश विशिष्ट बंडल का नाम देता है तो bundle_id पर एक दूसरा फ़िल्टर जोड़ें।

कम बैलेंस

उन प्रीपेड सब्सक्राइबर्स को टारगेट करता है जो अगले नवीनीकरण के लिए भुगतान नहीं कर सकते।

टैग: balance, ऑपरेटर कम या बराबर, मान 50
टैग: prepaid_postpaid, ऑपरेटर बराबर है, मान prepaid

दोनों शर्तें एक ही समूह में जाती हैं, जिन्हें और के साथ जोड़ा जाता है।

रोमिंग एंट्री

उन सब्सक्राइबर्स को टारगेट करता है जो वर्तमान में विदेश में हैं, स्थानीय दरों के साथ एक स्वागत संदेश के लिए।

टैग: roaming_status, ऑपरेटर हाँ

एक टैग-आधारित सेगमेंट संकलन के समय की स्थिति को दर्शाता है। जब आपको संदेश को रोमिंग शुरू होते ही बाहर भेजने की आवश्यकता होती है, तो इस सेगमेंट को भेजने के बजाय रोमिंग इवेंट से एक कस्टमर जर्नी को ट्रिगर करें।

टॉप-अप पुष्टि और अन्य प्रतिक्रियाएं

टॉप-अप की पुष्टि करना किसी एक सब्सक्राइबर की कार्रवाई की प्रतिक्रिया है, न कि संकलित करने के लिए एक ऑडियंस। अपनी बिलिंग प्रणाली से postEvent के साथ एक कस्टम इवेंट भेजें और इससे एक कस्टमर जर्नी शुरू करें। यही बात बंडल खरीद और प्लान बदलने पर भी लागू होती है।

सेगमेंट शून्य उपयोगकर्ता लौटाता है

इन्हें क्रम में जांचें। पहले तीन अधिकांश मामलों को कवर करते हैं जो सहायता को रिपोर्ट किए जाते हैं।

टैग पेज पर टैग का प्रकार जांचें। यदि bundle_expiry_date Integer है, तो कोई डेट ऑपरेटर कभी लागू नहीं किया गया था और सेगमेंट ने संख्याओं की तुलना की। एक Date टैग बनाएं और मानों को फिर से लोड करें।
जांचें कि मान वास्तव में आए हैं। User Explorer खोलें, एक सब्सक्राइबर खोजें जिसे आप जानते हैं कि बैच में था, और उनके टैग देखें। एक सफल जॉब के बाद एक खाली टैग का मतलब है कि मानों को प्रारूप द्वारा अस्वीकार कर दिया गया था, अक्सर केवल-अंकों वाली स्ट्रिंग्स या एक तारीख जो किसी भी लेआउट से मेल नहीं खाती थी।
ऑपरेटर सेक्शन की जांच करें। वर्षगांठ के तहत N दिन बाद वर्ष को अनदेखा करता है। सापेक्ष तिथियां के तहत N से M दिन बाद ऐसा नहीं करता है।
टाइम ज़ोन की जांच करें। बिना ऑफ़सेट के भेजे गए समाप्ति टाइमस्टैम्प को UTC के रूप में पढ़ा जाता है, जो एक सब्सक्राइबर को आपके रिमाइंडर शेड्यूल के पिछले या अगले दिन में स्थानांतरित कर सकता है।
सेगमेंट की पुनर्गणना करें संख्या पढ़ने से पहले, ताकि आप कैश्ड आकार न देख रहे हों। सेगमेंट आकार की गणना करना देखें।

ध्यान में रखने योग्य सीमाएं

एक टैग प्रकार स्थायी होता है। पहले अपलोड से पहले प्रोफ़ाइल की योजना बनाएं, क्योंकि बाद में एक प्रकार को ठीक करने का मतलब है एक नया टैग और एक पूर्ण रीलोड।
रिलेटिव डेट ऑपरेटर हाई-स्पीड डिलीवरी सेगमेंट में उपलब्ध नहीं हैं। हाई-स्पीड डिलीवरी के लिए कॉन्फ़िगर किए गए एप्लिकेशन अपने सेगमेंट को प्री-कंपाइल करते हैं, और रिलेटिव डेट ऑपरेटर वहां पेश नहीं किए जाते हैं। बंडल समाप्ति रिमाइंडर को साधारण सेगमेंट के रूप में चलना चाहिए।
एक बैच जॉब रियल-टाइम नहीं है। सेगमेंट प्रोफ़ाइल को अंतिम सफल लोड के अनुसार देखते हैं। वे परिदृश्य जिन्हें बैलेंस परिवर्तन के सेकंड के भीतर फायर करना चाहिए, वे एक इवेंट-ट्रिगर जर्नी में आते हैं, न कि एक रात के बैच में।