Apple Messages के व्यावसायिक परिणाम मापें
मैसेजिंग गतिविधि और प्रोसेसिंग मापने के लिए Bird के चैनल मेट्रिक्स का उपयोग करें। व्यावसायिक परिणाम तय करने के लिए उस सिस्टम का उपयोग करें जिसके पास ऑर्डर, बुकिंग, भुगतान या केस का स्वामित्व है।
किसी संदेश की Sent स्थिति पुष्टि करती है कि Apple के गेटवे ने उसे स्वीकार कर लिया है। फ़ॉर्म का उत्तर या चुना गया समय ग्राहक की एक इंटरैक्शन दर्ज करता है। इनमें से कोई भी यह साबित नहीं करता कि कोई व्यावसायिक कार्रवाई पूरी हुई।
रिपोर्ट करने से पहले परिणाम परिभाषित करें
ऐसा परिणाम चुनें जिसकी पुष्टि आपका स्रोत सिस्टम कर सके, जैसे रिज़र्वेशन बनना, ऑर्डर का भुगतान होना या सेवा केस का हल होना। वह टाइमस्टैम्प, रिकॉर्ड पहचानकर्ता और वे शर्तें लिख लें जिनसे परिणाम मान्य होता है।
किसी अपॉइंटमेंट के लिए इन अवलोकनों को अलग-अलग रखें:
| अवलोकन | प्रमाण |
|---|---|
| समय के विकल्प दिए गए | भेजे गए संदेश का रिकॉर्ड। |
| ग्राहक ने समय चुना | आने वाला नेटिव जवाब। |
| अपॉइंटमेंट आरक्षित हुआ | बुकिंग सिस्टम का सफल आरक्षण रिकॉर्ड। |
| पुष्टि भेजी गई | अलग से भेजा गया पुष्टि संदेश। |
| अपॉइंटमेंट में उपस्थिति | सर्विस टीम का उपस्थिति रिकॉर्ड, अगर यह दर्ज किया जाता है। |
ऐसा हर (denominator) चुनें जो आपके सवाल का जवाब दे। उदाहरण के लिए, आरक्षणों को उन ग्राहकों की संख्या से भाग देना जिन्हें समय विकल्प दिए गए, एक अलग चरण मापता है, बनिस्बत आरक्षणों को प्राप्त समय चयनों से भाग देने के। परिणाम के साथ अवधि और बाहर रखे गए मामलों का उल्लेख करें।
रिकॉर्ड जोड़ें
अपने इंटीग्रेशन में Bird बातचीत और संदेश ID के साथ एक केस या ऑपरेशन संदर्भ सहेजकर रखें। API से भेजे गए संदेशों के लिए, संदेश भेजने के अनुबंध के अनुसार समर्थित metadata या रिपोर्टिंग लेबल का उपयोग करें। रिपोर्टिंग लेबल अनुमति, सप्रेशन या फिर से प्रयास करने के व्यवहार को नहीं बदलता।
URL या संदेश टैग में ग्राहक की गोपनीय जानकारी डालने के बजाय अपने सिस्टम का संदर्भ इस्तेमाल करें। दर्ज करें कि हर टाइमस्टैम्प और परिणाम किस सिस्टम से आया। जोड़े गए डेटा पर अपने रिटेंशन और एक्सेस नियम लागू करें।
दोहराव और देर से आने वाले परिणामों को संभालें
वेबहुक डिलीवरी और व्यावसायिक कार्रवाइयों की डुप्लिकेट प्रविष्टियाँ अलग-अलग हटाएँ। एक ही इवेंट की दोबारा डिलीवरी से दूसरा आरक्षण नहीं बनना चाहिए। ग्राहक का जानबूझकर किया गया दूसरा अनुरोध एक अलग ऑपरेशन हो सकता है।
टाइमआउट के बाद जो कार्रवाइयाँ अनिश्चित रहती हैं, उनका मिलान करें। प्रदाता से देर से आने वाले परिणामों को नए रूपांतरण के रूप में गिनने के बजाय मूल ऑपरेशन को अपडेट करने दें। जब रिपोर्टिंग के प्रश्न के लिए ज़रूरी हो, तो रद्दीकरण और रिवर्सल भी शामिल करें।
रिपोर्ट की ईमानदारी से व्याख्या करें
बंद बातचीत ग्राहक जीवनचक्र की एक घटना है; यह समाधान का स्कोर नहीं है। पहला जवाब जल्दी आने से यह साबित नहीं होता कि जवाब सही था। अगर डिवाइस से रीड रसीद नहीं मिली है, तो गेटवे की स्वीकृति को पढ़ा जाना मानकर उस कमी को पूरा नहीं किया जा सकता।
जहाँ उपयोगी हो, परिणामों की तुलना समर्थित एंट्री-पॉइंट इंटेंट या अपनी केस श्रेणियों के आधार पर करें। सफल परिणामों के साथ-साथ अनसुलझे अनुरोधों और विफल रास्तों की भी समीक्षा करें। इस व्यावसायिक रिपोर्ट को Bird के मैसेजिंग डैशबोर्ड से अलग रखें, ताकि पाठक देख सकें कि हर संख्या क्या स्थापित करती है।