छोटे लिंक के गंतव्य पेज की निगरानी

एक छोटा लिंक सही तरीके से रीडायरेक्ट करना जारी रख सकता है, जबकि इसके पीछे के गंतव्य ने आपके अभियान द्वारा वादा किए गए पृष्ठ की सेवा बंद कर दी है। फॉर्म टूट सकता है, उत्पाद गायब हो सकता है, या साइट अपडेट के बाद लॉगिन वॉल दिखाई दे सकती है। निगरानी में केवल यह जाँचना पर्याप्त नहीं है कि सर्वर ने जवाब दिया या नहीं। ग्राहक के अपेक्षित परिणाम को परिभाषित करें, तय करें कि कौन से चेक इसका निरीक्षण कर सकते हैं, और साक्ष्य बदलने पर कार्रवाई के लिए किसी को जिम्मेदारी दें।

शॉर्ट लिंक डेस्टिनेशन मॉनिटरिंग वादे के साथ शुरू होती है

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

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

पहुंच की उपलब्धता और सही ग्राहक अनुभव को अलग-अलग जाँचें

HTTP प्रतिक्रिया अनुरोध के परिणाम के भाग का वर्णन करती है। एक सफल पृष्ठ प्रतिक्रिया यह साबित नहीं करती है कि पृष्ठ में अपेक्षित प्रस्ताव है या इसका फॉर्म सही ढंग से सबमिट किया गया है। ठीक से चल रहा सर्वर भी तुरंत ‘पृष्ठ नहीं मिला’ की प्रतिक्रिया दे सकता है। एक अस्थायी सर्वर त्रुटि, एक कनेक्शन विफलता और एक अप्रत्याशित रीडायरेक्ट अलग-अलग स्थितियाँ हैं जिन्हें अलग से दर्ज किया जाना चाहिए।

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

उस मार्ग का अनुसरण करें जिसे आगंतुक वास्तव में अपनाते हैं

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

रूटिंग की हर शाखा की अलग समीक्षा करें। डेस्कटॉप का गंतव्य सही काम करने से यह साबित नहीं होता कि iPhone का विशेष पता या किसी दूसरी भाषा के लिए बनाया गया नियम भी सही है। डिवाइस रूटिंग गाइड बताता है कि वे शाखाएँ परीक्षण योजना में क्यों हैं। आपके द्वारा वास्तव में कॉन्फ़िगर किए गए मामलों का एक छोटा मैट्रिक्स रखें; आपको दर्जनों संयोजनों का आविष्कार करने की आवश्यकता नहीं है, लेकिन प्रत्येक सुविचारित मार्ग में कम से कम एक सार्थक जाँच होनी चाहिए।

ऐसे चेक चुनें जो आकस्मिक दुष्प्रभावों से बचें

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

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

वास्तविक गंतव्य के रूप में फ़ॉलबैक का परीक्षण करें

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

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

अलर्ट को कार्रवाई योग्य बनाएं और अंतहीन शोर से बचें

अलर्ट में प्रभावित अभियान, देखी गई स्थिति, समय और जिम्मेदार व्यक्ति की पहचान होनी चाहिए। पहला सुरक्षित जांच चरण शामिल करें और अंतिम सफल जांच कहां मिल सकती है। जिम्मेदार व्यक्ति को यह निर्धारित करने में सक्षम होना चाहिए कि क्या गंतव्य जानबूझकर बदला गया है, होस्टिंग सेवा अनुपलब्ध है, या रूटिंग शाखा को कई असंबंधित खातों की खोज किए बिना सुधार की आवश्यकता है।

विफलता और पुनर्प्राप्ति दोनों के लिए योजना बनाएं। बार-बार एक ही बात कहने वाले संदेश किसी महत्वपूर्ण बदलाव को नज़रों से ओझल कर सकते हैं, जबकि एक मौन पुनर्प्राप्ति एक टीम को अनावश्यक रूप से वर्कअराउंड का उपयोग करने के लिए मजबूर कर सकती है। तय करें कि बार-बार आने वाली समस्या कब अगले स्तर के जिम्मेदार व्यक्ति तक पहुँचाना जरूरी है और आप उस घटना को कैसे बंद करेंगे। उपलब्ध निगरानी नियंत्रणों के लिए लिंक सहायता से परामर्श लें; एक अलर्ट कॉन्फ़िगरेशन केवल तभी उपयोगी होता है जब उसके प्राप्तकर्ता के पास अभी भी आवश्यक सुधार करने की जिम्मेदारी और अनुमति हो।

गंतव्य परिवर्तन के बाद परिणाम की समीक्षा करें

जब गंतव्य की मरम्मत या प्रतिस्थापित किया जाता है, तो प्रासंगिक ग्राहक संदर्भ से संक्षिप्त पते का फिर से पालन करें। अपेक्षित पृष्ठ और कार्रवाई की जाँच करें, फिर पुष्टि करें कि विश्लेषणात्मक आयाम अभी भी अभियान का सही वर्णन करते हैं। एक मरम्मत किया गया मार्ग जो चुपचाप एट्रिब्यूशन बदलता है, रिपोर्टिंग में दूसरी समस्या पैदा कर सकता है, भले ही आगंतुक अब पृष्ठ तक पहुंच सकते हैं।

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

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