WhatsApp मेट्रिक्स
Bird डैशबोर्ड में Metrics पेज दिखाता है कि आपका WhatsApp चैनल कैसा प्रदर्शन कर रहा है: कितने संदेश प्राप्तकर्ता के डिवाइस तक पहुँचे, क्या आपकी विफलता दर बदल रही है, और सब कुछ कितनी तेज़ी से हुआ। यह गाइड उस पेज, हर संख्या के अर्थ, और कब कार्रवाई करनी है, इसकी व्याख्या करती है।
मेट्रिक्स आपके वर्कस्पेस द्वारा भेजी गई हर चीज़ का समग्र दृश्य हैं। किसी एक संदेश की स्थिति जानने के लिए (क्या इस नंबर ने इसे प्राप्त किया, और कब), WhatsApp लॉग और इवेंट्स देखें।
अपनी मेट्रिक्स पढ़ें
Metrics पेज Bird डैशबोर्ड में WhatsApp → Metrics पर स्थित है; यह उन वर्कस्पेस सदस्यों को दिखता है जिनके पास WhatsApp read और Analytics read दोनों अनुमतियाँ हैं। हर संख्या रेंज पिकर का पालन करती है (पिछले 24 घंटे, 7, 30, या 90 दिन)। नए इवेंट एग्रीगेशन और रेप्लिकेशन के बाद दिखते हैं, इसलिए सबसे हालिया अवधि के आँकड़े अभी अंतिम नहीं होते।
आउटबाउंड दरें हर संदेश के स्वीकृति समय का उपयोग करती हैं। आज आने वाली डिलीवरी रसीद जो कल स्वीकृत संदेश के लिए है, उस संदेश के अपने accepted के साथ कल में गिनी जाती है। इसलिए हर रेंज अपने भीतर स्वीकृत संदेशों को ट्रैक करती है जैसे-जैसे अवलोकन आते हैं। हालिया घंटों में delivered कम दिख सकती है जब तक रसीदें आ रही हों। accepted डिलीवरी और विफलता दर कार्ड्स का हर (denominator) है।
काउंट्स हर अवलोकित इवेंट के लिए अलग-अलग संदेशों का प्रतिनिधित्व करते हैं और बड़े पैमाने पर अनुमानित हो सकते हैं। ये एक अनिवार्य फ़नल नहीं हैं: एक read रसीद बिना delivered रसीद के मौजूद हो सकती है, और छूटे हुए अवलोकन चरणों के बीच अंतर छोड़ सकते हैं। ग्रुप स्टैटिस्टिक्स भी संदेश गिनते हैं, प्राप्तकर्ता नहीं; पहली अवलोकित प्रतिभागी डिलीवरी delivered काउंट बढ़ा सकती है इससे पहले कि ग्रुप के हर सदस्य ने संदेश प्राप्त किया हो।
सारांश टाइल्स
शीर्ष पर टाइल्स की पंक्ति आपकी त्वरित स्वास्थ्य जाँच है:
- Delivery rate: स्वीकृत संदेशों में से डिलीवर हुए संदेशों का हिस्सा। 95% से ऊपर टाइल Healthy दिखाती है। इसके बराबर या नीचे होने पर कुछ डिवाइसों तक नहीं पहुँच रहा: अमान्य नंबर, समाप्त केयर विंडो, या टेम्पलेट समस्या। विफलता-कारण हिस्टोग्राम (Failure rate and its causes देखें) बताता है कि कौन-सा कारण है।
- Failure rate: स्वीकृत संदेशों में से failed पर समाप्त हुए संदेशों का हिस्सा। टाइल आपकी दर को प्रोग्रेस बार के साथ 5% सीमा के सामने दिखाती है; इस तक पहुँचने पर टाइल Risk में बदल जाती है। लगातार उच्च विफलता दर आमतौर पर सूची की गुणवत्ता, समाप्त ग्राहक सेवा विंडो, या Meta रेट लिमिट की ओर इशारा करती है।
- Accepted: रेंज में स्वीकृत संदेशों की कुल संख्या, साथ ही WhatsApp नेटवर्क को सौंपी गई संख्या (sent)।
95% और 5% थ्रेशोल्ड वे गार्डरेल हैं जिनसे हम टाइल्स को रंग देते हैं। ये जानबूझकर रूढ़िवादी हैं; एक टाइल Healthy दिखा सकती है और फिर भी सुधार की गुंजाइश हो सकती है।
समय के अनुसार डिलीवरी
डिलीवरी चार्ट रेंज भर में accepted, delivered, और failed वॉल्यूम प्लॉट करता है ताकि आप ट्रेंड्स और एक बार के स्पाइक्स पहचान सकें: एक खराब कैम्पेन, गलत नंबर-लिस्ट इम्पोर्ट, या कोई टेम्पलेट जो रिजेक्ट होने लगा। बकेट साइज़ रेंज के अनुसार होता है (24 घंटों के लिए प्रति घंटा, लंबी विंडो के लिए दैनिक)।
विफलता दर और उसके कारण
Metrics पेज पर डिलीवरी चार्ट के नीचे, एक failure-rate लाइन पूरी रेंज में प्रति-बकेट विफलता दर दिखाती है, जबकि Failure rate सारांश टाइल पूरी विंडो का आँकड़ा रखती है। एक हिस्टोग्राम विफलताओं को सामान्यीकृत error code के अनुसार तोड़ता है, जिसमें प्रत्येक कोड की विफल संदेशों में हिस्सेदारी के साथ गिनती के अनुसार रैंकिंग होती है। WhatsApp के विफलता कारण एक खुला सेट हैं, इसलिए हिस्टोग्राम किसी निश्चित सूची के बजाय रेंज में वास्तव में आए कोड दिखाता है; किसी एक कोड पर बढ़ती हुई बार आपको सीधे समाधान की ओर ले जाती है।
डिलीवरी विलंब
विलंब तालिका तीन चरणों को p50, p95 और p99 पर्सेंटाइल पर दिखाती है:
- Processing: संदेश स्वीकृत होने से लेकर WhatsApp प्रोवाइडर को सफलतापूर्वक सबमिट करने तक। यहाँ एक धीमा पर्सेंटाइल भेजने के पथ की जाँच की माँग करता है, जिसमें प्रोवाइडर सबमिशन शामिल है।
- Delivery: सबमिशन से लेकर WhatsApp द्वारा डिलीवरी की पुष्टि तक, यह हिस्सा WhatsApp नेटवर्क और प्राप्तकर्ता के डिवाइस का होता है।
- Total: शुरू से अंत तक, संदेश स्वीकार होने से लेकर WhatsApp द्वारा प्राप्तकर्ता के डिवाइस पर डिलीवरी की पुष्टि तक। Total और Processing के बीच का अंतर WhatsApp नेटवर्क और प्राप्तकर्ता के डिवाइस का है, जो हमारे नियंत्रण में नहीं है। एक घंटे तक ऑफ़लाइन रहने वाला फ़ोन Total को बढ़ा देता है जबकि Processing अपरिवर्तित रहता है।
सबसे अधिक समय लेने वाले संदेशों की पहचान के लिए p95/p99 का उपयोग करें: एक स्वस्थ मीडियन के साथ धीमा p99 आमतौर पर किसी एक टेम्पलेट या गंतव्य के धीमेपन की ओर इशारा करता है। विलंब पूरी विंडो का आँकड़ा है; कोई चरण या पर्सेंटाइल जिसके लिए रेंज में डेटा नहीं है, एक प्लेसहोल्डर दिखाता है।
ब्रेकडाउन
Breakdowns पैनल उन्हीं डिलीवरी आँकड़ों को अलग-अलग आयामों में बाँटता है ताकि आप समस्या को उसके स्रोत तक सीमित कर सकें:
- नंबर के अनुसार: हर भेजने वाले बिज़नेस नंबर का accepted, delivered, और failed वॉल्यूम उसकी delivery rate के साथ, ताकि आप भेजने वालों की आपस में तुलना कर सकें।
- टेम्पलेट के अनुसार: वही विभाजन प्रति टेम्पलेट, उस एक टेम्पलेट को खोजने के लिए जो दर को नीचे खींच रहा है।
- टेम्पलेट कैटेगरी के अनुसार: Meta की टेम्पलेट कैटेगरीज़ में वही विभाजन, वह वर्गीकरण जो आपके खर्च को भी प्रभावित करता है।
- टैग के अनुसार: वे टैग जो आप भेजते समय लगाते हैं, विश्लेषण का सबसे लचीला वर्गीकरण: कैम्पेन, टेम्पलेट, या प्रयोग वेरिएंट को टैग करें और सीधे तुलना करें।
- देश के अनुसार: वही विभाजन प्रति गंतव्य देश, यह देखने के लिए कि डिलीवरी समस्या किसी बाज़ार से जुड़ी है या किसी भेजने वाले या टेम्पलेट से। जिस प्राप्तकर्ता का देश पता नहीं लगाया जा सका (एक नंबर जो फ़ोन नंबर जैसा दिखता है लेकिन किसी देश का नहीं है, या फ़्रीफ़ोन जैसी अंतर्राष्ट्रीय रेंज) उसे ZZ के अंतर्गत गिना जाता है, वही प्लेसहोल्डर जो SMS देश ब्रेकडाउन उपयोग करता है। ग्रुप में भेजे गए संदेश बाहर रखे जाते हैं क्योंकि एक ग्रुप कई देशों में फैल सकता है और उसका कोई एकल गंतव्य नहीं होता। इस ब्रेकडाउन के शुरू होने से पहले का ऐतिहासिक देश कवरेज अधूरा हो सकता है, जिसमें मिलान करने वाले accepted काउंट्स के बिना delivered या read अवलोकन शामिल हैं। समग्र इतिहास 30-दिन की संदेश-विवरण विंडो से अधिक समय तक रहता है; 30 दिन प्रतीक्षा करने से पहले स्वीकार किए गए संदेशों के उन समूहों के अधूरे आँकड़े पूरे नहीं होते।
हर पंक्ति को अपनी डिलीवरी और विफलता दरों के आधार पर एक व्युत्पन्न स्थिति (Healthy, Watching, या Throttled) भी मिलती है, ताकि एक संघर्षरत नंबर या कैटेगरी बिना हर कॉलम पढ़े अलग दिख जाए। हर टैब रेंज के लिए शीर्ष पंक्तियों को रैंक करता है; जब किसी डाइमेंशन के अलग-अलग मान समा नहीं पाते, तो पैनल "Top N of M" नोट करता है।
प्रोग्रामेटिक एक्सेस
इस पेज के पीछे के एग्रीगेट्स एक सार्वजनिक API भी हैं। टाइप्ड मेथड्स TypeScript, Python, PHP, और Go SDKs में bird.whatsapp.stats के अंतर्गत उपलब्ध हैं, bird CLI उन्हें bird whatsapp stats <verb> के रूप में एक्सपोज़ करता है, और एक एजेंट उन तक whatsapp_stats_* MCP tools के माध्यम से पहुँचता है। पूर्ण request और response स्कीमा API संदर्भ में हैं।
एग्रीगेट और टाइम सीरीज़
GET /v1/whatsapp/stats/summary विंडो के लिए एक समग्र पंक्ति लौटाता है: संदेश स्थिति गणनाएँ (accepted, sent, delivered, failed, rejected) डिलीवरी और विफलता दरों के साथ, एंगेजमेंट (read, read_rate), और तीन चरणों (processing, delivery, और total) के लिए विलंब पर्सेंटाइल (p50, p95, p99)। /daily और /hourly वही स्थिति और read गणनाएँ प्रति कैलेंडर दिन या घंटे की एक पंक्ति में लौटाते हैं, हर एक के अपने विलंब पर्सेंटाइल होते हैं; केवल दरें (delivery_rate, failure_rate, read_rate) पूरी-विंडो के आँकड़े हैं, इन्हें /summary से पढ़ें। तीनों एक बार में एक डाइमेंशन फ़िल्टर स्वीकार करते हैं: template, category, tag, या phone_number। यहाँ phone_number एक एकल बिज़नेस सेंडर तक सीमित करता है, E.164 फ़ॉर्मेट में, न कि वह कॉन्टैक्ट जिससे यह GET /v1/whatsapp/messages के deprecated phone_number पैरामीटर पर फ़िल्टर करता है।
read rate read / delivered है, जबकि डिलीवरी और विफलता दरें accepted का उपयोग करती हैं। शून्य denominator null लौटाता है, अर्थात दर की गणना नहीं हो सकती। read rate 100% पर सीमित नहीं है, इसलिए छूटे हुए delivered अवलोकन एक उच्चतर मान उत्पन्न कर सकते हैं; यह जाँच योग्य एक अवलोकन अंतर है, इसका प्रमाण नहीं कि कुल प्राप्तकर्ताओं से भी ज़्यादा लोगों ने संदेश पढ़ा।
विलंब पर्सेंटाइल रिकॉर्ड किए गए सैंपल्स का उपयोग करते हैं। अनुपस्थित delivery-latency सैंपल का अर्थ शून्य विलंब नहीं है, और total विलंब तब भी मौजूद हो सकता है जब बीच का sent टाइमस्टैम्प अनुपलब्ध था। अलग-अलग बकेट्स के अंतिम पर्सेंटाइल का औसत न निकालें। रीप्ले किए गए इवेंट्स विलंब वितरण को प्रभावित कर सकते हैं भले ही अलग-अलग संदेश काउंट्स डिडुप्लिकेटेड रहें।
उपस्थित होने पर, data_as_of एग्रीगेशन की ताज़गी रिपोर्ट करता है। यह इस बात का प्रमाण नहीं है कि सभी प्रोवाइडर कॉलबैक आ चुके हैं या बिलिंग अंतिम रूप ले चुकी है। null ताज़गी मान का अर्थ है कि यह उस प्रतिक्रिया के लिए अनुपलब्ध था।
विंडो चुनना
from और to एक कैलेंडर दिन या RFC 3339 इंस्टेंट स्वीकार करते हैं, लेकिन कौन-सा एंडपॉइंट कौन-सा फ़ॉर्म लेता है, यह अलग-अलग है:
| एंडपॉइंट | बाउंड्स | अधिकतम विंडो |
|---|---|---|
| /summary | दोनों कैलेंडर दिन, या दोनों RFC 3339 इंस्टेंट | 365 दिन, या इंस्टेंट पर 720 घंटे |
| /daily | केवल कैलेंडर दिन | 365 दिन |
| /hourly | केवल RFC 3339 इंस्टेंट | 720 घंटे (30 दिन) |
/summary पर, एक day बाउंड को एक instant बाउंड के साथ मिलाने पर 422 लौटता है। Instant बाउंड्स /summary और /hourly पर घंटे तक राउंड डाउन होते हैं, केवल ये दोनों ही उन्हें स्वीकार करते हैं। timezone को एक IANA आइडेंटिफ़ायर पर सेट करें ताकि दिन और घंटे की सीमाएँ UTC के बजाय स्थानीय रूप से कैलकुलेट हों; एक बार सेट होने पर, instant बाउंड में +05:45 जैसा न्यूमेरिक UTC ऑफ़सेट अस्वीकार कर दिया जाता है। पिछली समान-लंबाई विंडो और उसके विरुद्ध बदलाव के लिए /summary में compare=previous_period जोड़ें।
ब्रेकडाउन
छह एंडपॉइंट उन्हीं डिलीवरी संख्याओं को एक डाइमेंशन के अनुसार रैंक करते हैं, हर एक पहले से सिंगल-डाइमेंशन है इसलिए कोई फ़िल्टर नहीं लेता: नंबर के अनुसार, टेम्पलेट के अनुसार, टेम्पलेट कैटेगरी के अनुसार, टैग के अनुसार, और error code के अनुसार (केवल विफल संदेश, सामान्यीकृत विफलता कारण के अनुसार समूहित)। पंक्तियाँ accepted वॉल्यूम (error codes पर failure count) के अनुसार रैंक होती हैं और limit पर सीमित हैं (डिफ़ॉल्ट 50, अधिकतम 200)। किसी डाइमेंशन के लिए बिना मान वाला भेजा गया संदेश उस ब्रेकडाउन से अनुपस्थित होता है: एक फ़्री-फ़ॉर्म भेजा गया संदेश कोई टेम्पलेट रिज़ॉल्व नहीं करता, और बिना टैग वाला भेजा गया संदेश कोई टैग नहीं। कई टैग वाला एक संदेश कई टैग पंक्तियों में दिख सकता है, इसलिए उन पंक्तियों को जोड़ने से अद्वितीय वर्कस्पेस वॉल्यूम नहीं मिलता। किसी ब्रेकडाउन की तुलना समय के साथ स्वयं से करें। error-code पंक्ति के अलावा हर पंक्ति के अपने latency पर्सेंटाइल भी होते हैं। छठा, देश के अनुसार, उन्हीं संख्याओं को प्राप्तकर्ता के गंतव्य बाज़ार के अनुसार समूहित करता है; जिस प्राप्तकर्ता का देश रिज़ॉल्व नहीं हो सकता उसे ZZ के अंतर्गत गिना जाता है, और ग्रुप में भेजे गए संदेश अनुपस्थित हैं क्योंकि एक भेजा गया संदेश कई देशों में फैल सकता है।
प्राप्त संदेश
/v1/whatsapp/stats/inbound/ के अंतर्गत चार एंडपॉइंट बताते हैं कि आपके नंबरों ने भेजने की बजाय क्या प्राप्त किया: सारांश, दैनिक, प्रति घंटा, और फ़ोन नंबर के अनुसार। हर पंक्ति में केवल एक received गणना होती है और यह इनकमिंग संदेश के occurrence समय का अनुसरण करती है। प्राप्त संदेश में आगे विश्लेषण के लिए कोई आउटबाउंड डिलीवरी स्थिति नहीं होती। SDKs में ये bird.whatsapp.stats.inbound के अंतर्गत और CLI में bird whatsapp stats inbound <verb> के अंतर्गत नेस्टेड हैं।
प्रति-संदेश मिलान
Stats एंडपॉइंट समग्र प्रश्नों का उत्तर देते हैं; ये प्रति-संदेश लुकअप की जगह नहीं लेते। किसी एक संदेश के साथ क्या हुआ यह पुष्टि करने के लिए, webhook events को वास्तविक समय में कंज़्यूम करें, या GET /v1/whatsapp/messages और प्रत्येक संदेश के events endpoint को पेज करें, जिनके फ़िल्टर (स्टेटस, प्राप्तकर्ता, टैग, समय विंडो) अधिकांश मिलान कार्यों को कवर करते हैं।
अगले कदम
- WhatsApp एनालिटिक्स: संदेश अवलोकनों को पुष्ट ग्राहक परिणामों से जोड़ें
- WhatsApp लॉग: समग्र संख्याओं के पीछे का प्रति-संदेश दृश्य
- इवेंट्स: संदेश स्थिति इवेंट्स जिनसे मेट्रिक्स प्राप्त होती हैं
- WhatsApp संदेश भेजना: कैटेगरीज़, टैग, और प्रति-संदेश लागत मॉडल
संबंधित संसाधन
इस विषय के लिए दस्तावेज़, गाइड और उदाहरणों के साथ आगे बढ़ें।