यह चुनना कि एक डोमेन DR नंबर किस प्रश्न का उत्तर देने के लिए अनुमत है
डोमेन DR एक छिपे हुए काउंट है। सादा। यह तब बढ़ता है जब अधिक विभेदक साइट्स किसी डोमेन को लिंक करती हैं, और लॉग स्केल हर नए पॉइंट को पिछले से कठिन बनाता है। उस वाक्य को चार्ट नोट्स में रखें।
एक अच्छा टाइल एक प्रश्न का उत्तर देता है: क्या हम तीन प्रतिद्वंद्वियों के करीब पहुंच रहे हैं, क्या पार्टनर्स बढ़ रहे हैं, क्या किसी कैम्पेन ने कुछ बदला। एक बुरा टाइल ट्रैफिक या राजस्व को मिला देता है और एक कारण-प्रभाव कहानी को आमंत्रित करता है जिसका डेटा समर्थन नहीं कर सकता।
कच्चे रेफरिंग-डोमेन काउंट को भी स्टोर करें। यदि स्कोर एक पॉइंट से बदलता है, तो आप देख सकते हैं कि क्या यह 40 नए डोमेन थे या 4,000, और यह बताता है कि क्या चिंता करनी है।
टेबल में क्या होना चाहिए और क्या नहीं
एक सनैपशॉट टेबल एक मेमोरी है। इसमें वह होना चाहिए जो आपको एक साल में चार्ट को समझाने के लिए चाहिए, और कुछ ऐसा नहीं जो गलत व्याख्या को आमंत्रित करे। उस सबसे छोटे कॉलम सेट से शुरू करें जो प्रश्न का उत्तर देता है। तब तक एक और न जोड़ें जब तक कि एक मीटिंग में इसकी मांग न की जाए।
कुछ कॉलम पहले दिन ही अपनी जगह बनाते हैं। आपसे कम। डोमेन, स्कोर, रेफरिंग-डोमेन काउंट, पुल तारीख और स्रोत नाम अधिकांश प्रश्नों को कवर करते हैं। एक ट्रैफिक कॉलम मददगार लगता है, लेकिन यह एक अन्य स्रोत और एक अन्य तारीख से आता है, इसलिए इसे एक अन्य टेबल में होना चाहिए।
उस सबको छोड़ दें जिसे आप बाकी से पुनः कंप्यूट कर सकते हैं। मासिक-से-मासिक बदलाव एक सबट्रैक्शन है, इसलिए इसे एक व्यू में रखें, उसी तथ्य की चौथी कॉपी के रूप में नहीं।
कॉलम लिस्ट को चार्ट नोट्स में भी लिखें। एक पाठक जो एक साल में चार्ट खोलता है, उसे यह दिखना चाहिए कि हर नंबर कहाँ से आया, और किस पुल ने उसे भरा।
दोहरी पंक्तियों को रोकने वाली कुलियां
domain और pull date पर प्राइमरी की न केवल डुप्लिकेट्स को रोकती है। यह यह भी बताती है कि पंक्ति किस पुल से आई, जो एक टाइमआउट के बाद ररन होने पर महत्वपूर्ण है। एक ही महीने में एक ही डोमेन के लिए दो पंक्तियां असंभव होनी चाहिए, और स्कीमा ऐसा कहनी चाहिए।
सोर्स नाम जिन पर आप फिल्टर कर सकते हैं
स्रोत को एक स्थिर लेबल के रूप में लिखें, जैसे rankwiser_bulk_dr, न कि एक फ्री-टेक्स नोट के रूप में। उस लेबल पर एक फिल्टर इस स्कोर को बाद में लोड किए गए किसी भी अन्य स्कोर से अलग रखता है। लेबल लिस्ट छोटी रखें और टेबल के बगल में लिखें।
रन लागत, तीन लिस्ट साइज पर काम की गई
ऊपर दिए गए क्रेडिट मूल्यों से गणना की गई। उदाहरण, माप नहीं।
ट्रैक्ड डोमेन
प्रति माह कॉल
क्रेडिट्स
डॉलर
50
1
1
$0.0001
500
1
1
$0.0001
5,000
3
3
$0.0003
जब रन फेल हो जाए
एक 401 का मतलब एक गायब या गलत कुली है। एक 402 का मतलब है कि क्रेडिट खत्म हो गया है, इसलिए अकाउंट पेज से USDT से टॉप अप करें। किसी भी रिस्पॉन्स पर अलर्ट करें जहां ok सत्य नहीं है, बल्कि चार्ट में ज़ीरो लिखें नहीं।
पेलाइन पर पहले तीन डोमेन पर टेस्ट करें
1
तीन ज्ञात डोमेन चुनें
एक ऐसी साइट का उपयोग करें जिससे आपको अच्छी जानकारी है, एक प्रतिस्पर्धी और एक छोटी साइट। प्रतिक्रिया के स्वरूप को दिखाने के लिए तीन ही पर्याप्त हैं।
2
परीक्षण अनुरोध भेजें
तीन डोमेन के साथ bulk_dr को कॉल करें और कच्ची प्रतिक्रिया को सहेजें, केवल विश्लेषित पंक्तियाँ नहीं।
3
ok और शेष राशि की जाँच करें
सुनिश्चित करें कि ok सत्य है और _credits पढ़ें। कॉल में एक क्रेडिट की लागत आनी चाहिए, और शेष राशि उसी मात्रा से कम होनी चाहिए।
4
एक पंक्ति को हाथ से तुलना करें
इस साइट पर मुफ्त लुकअप के साथ डोमेनों में से एक की जाँच करें। यदि स्कोर उसी से मेल खाता है जो आपके पार्सर ने संग्रहीत किया था, तो पार्सर सही है।
पहले दिन जोड़ने योग्य सुरक्षा सीमाएँ
असफल खींचने की एक दूसरी तालिका बनाए रखें। HTTP स्थिति, समय और प्रतिक्रिया शरीर वाली एक पंक्ति, चार्ट में मौन अंतर से बेहतर है। ok सत्य के अलावा किसी भी चीज़ पर अलर्ट करें।
डोमेन सूची को संस्करण नियंत्रण में पिन करें। छोटे diff मदद करते हैं। जब कोई प्रतिस्पर्धी जोड़ता है, तो diff दिखाता है कि किसने इसे कब जोड़ा, और चार्ट में एक नोट आता है। वरना उस प्रतिस्पर्धी के लिए रेखा अचानक दिखाई देती है और लोग पूछते हैं कि यह मार्च में कैसे शुरू हुई।
स्रोत परिवर्तन की भी योजना बनाएं। यदि आप बाद में Ahrefs या Moz संख्याएँ जोड़ते हैं, तो उन्हें तालिका में अपना अलग स्रोत मान दें, जैसा कि Ahrefs और Majestic की तुलना करते समय चर्चा की गई थी।
हर मासिक रन के लिए एक त्वरित स्वास्थ्य जाँच
चार्ट पर भरोसा करने से पहले, उसे भरने वाले जॉब की जाँच करें। फिर चार्ट देखें। एक स्वस्थ रन ok को सत्य लौटाता है, आपके द्वारा पूछे गए प्रत्येक डोमेन के लिए एक पंक्ति, और एक शेष राशि जो अपेक्षित मात्रा से कम हो गई है। कुछ भी अन्य प्रतिक्रिया पढ़ने का कारण है, चार्ट फिर भी रेखा खींचने का नहीं।
बदली गई पंक्तियों की गिनती करें। यदि एक बड़ा हिस्सा तीन अंक या अधिक से बदला है, तो सूचकांक को दोष देने से पहले डोमेन सूची की जाँच करें। गतियों का अचानक प्रवाह आमतौर पर इसका मतलब सूची बदली गई है, वेब नहीं।
सूची से मेल खाने वाली पंक्तियों की गिनता न्यूनतम है। कम पंक्तियों का मतलब है कि डोमेन फ़ाइल और तालिका के बीच कहीं गिर गया है। अगले रन से पहले इसे खोजें।
एक स्थिर महीना आपको क्या बताता है
लगभग कोई गति नहीं वाला महीना स्थिरता का प्रमाण नहीं है। सूचकाक लगभग एक बार महीने में रीफ्रेश होता है, इसलिए एक स्थिर पंक्ति बस अभी अपडेट नहीं हुई हो सकती। एक शांत महीने को उसके खींचने की तारीख के साथ पढ़ें, और याद रखें कि चार्ट अभी भी कैलेंडर का पालन करता है।
अलर्ट किसको मिलेगा
एक साझा इनबॉक्स को जाने वाला अलर्ट एक महीने में अनदेखा हो जाता है। नौकरी के लिए एक व्यक्ति का नाम दें और दूसरे को उस व्यक्ति की छुट्टियों के लिए। अलर्ट में डोमेन सूची, HTTP स्थिति और समय का नाम होना चाहिए, ताकि पाठक को एक्शन लेने के लिए स्क्रिप्ट खोलने की आवश्यकता न हो।
लाइव जाने से पहले परिवर्तन का परीक्षण
यदि आप सूची या शेड्यूल बदलते हैं, तो एक चक्र के लिए पुरानी और नई संस्करणों को साथ-साथ चलाएं। मेल खाने वाली पंक्तियाँ दिखाती हैं कि परिवर्तन ने कुछ और नहीं किया। एक ऐसा अंतर जिसे आप समझ नहीं सकते, उसे रोलआउट को रोकना चाहिए, चाहे वह कितना भी छोटा दिखे।
दर और लय पर एक नोट
यहाँ कुछ भी गति की जरूरत नहीं है। एक मासिक रन कुछ ही अनुरोधों का है, बड़ी सूचियों के लिए भी, और प्रत्येक प्रतिक्रिया एक JSON दस्तावेज़ के रूप में आती है। यदि आपका शेड्यूलर विफलता पर पुनः प्रयास करता है, तो पुनः प्रयास को idempotent बनाएं, जिसे डोमेन और खींचने की तारीख पर प्राथमिक कुंजी पहले से देती है।
इसकी सस्ती होने के कारण दैनिक रूप से जॉब चलाने की प्रवृत्ति का विरोध करें। ऐसा न करें। हमारा सूचकाक लगभग एक बार महीने में रीफ्रेश होता है। दैनिक खींचने से सप्ताहों तक वही पंक्तियाँ लौटती हैं, और आपका चार्ट स्थिरता जैसा दिखने वाले फ्लैट लाइनों से भर जाता है, जो केवल क्रॉल कैलेंडर को दर्शाता है। अन्य खींचने के लिए Majestic वैकल्पिक रसोइयों को पढ़ें, जैसे कि एंकर और इंटरसेक्शन।
लॉन्च के बाद जॉब का मालिकाना हक
एक मासिक जॉब उस व्यक्ति से ज्यादा समय तक चलता है जिसने इसे बनाया था। छह महीने बाद, कोई नया व्यक्ति cron एंट्री खोलता है और सोचता है कि सूची एक फ़ाइल में क्यों रहती है। एक छोटा नोट लिखें। इसे उद्देश्य, शेड्यूल और क्रेडिट लागत के साथ स्क्रिप्ट के शीर्ष पर रखें। वह नोट उस पर बैठक से सस्ता है।
प्रत्येक तिमाही में डोमेन सूची की समीक्षा करें। उस हटाएं जो अब मायने नहीं रखता, और वे प्रतिस्पर्धी जोड़ें जिन पर एक निर्भरता वास्तव में निर्भर करती है। प्रत्येक परिवर्तन संस्करण नियंत्रण में तारीख के साथ जाता है, ताकि चार्ट परिवर्तन को छिपाने के बजाय दिखा सके।
बजट भी समीक्षा का हिस्सा है। महीने में एक क्रेडिट। लागत बहुत कम रहती है। चार्ट के उसी दिन शेष राशि की जाँच करें, और अगले टॉप-अप तारीख को उसी नोट में लिखें।
लोग मासिक जॉब के बारे में जो प्रश्न पूछते हैं
चार प्रश्न तब आते हैं जब जॉब कुछ महीनों से चल रहा हो। प्रत्येक उत्तर एक नियम है जिसे आप सेटअप नोट में लिख सकते हैं।
क्यों दैनिक न खींचें, चूंकि कॉल सस्ती हैं?
डेटा एक मासिक कैलेंडर पर बदलता है, इसलिए एक दैनिक खींचने से सप्ताहों तक वही पंक्तियाँ दोहराती हैं। लागत छोटी है, लेकिन चार्ट स्थिरता जैसी दिखने वाली फ्लैट लाइनों से भर जाता है। एक बोर्ड को जाने वाले चार्ट के लिए बोर्ड रनबुक फुटनोट की भी आवश्यकता है।
यदि एक प्रतिस्पर्धी सूची से गिर जाता है तो क्या?
इतिहास रखें, डोमेन को हटाया गया चिह्नित करें और उसे खींचना बंद करें। एक लाइन का गायब होना डेटा अंतराल जैसा दिखता है, इसलिए चार्ट के बगल में कारण लिखें।
क्या मैं जॉब को अलग दिन पर चला सकता हूँ?
हाँ, यदि आप एक दिन चुनते हैं और उसे बनाए रखते हैं। बिंदु एक स्थिर लय है। महीने में कुछ दिन की तारीख को खिसकाने से प्रवृत्ति को पढ़ना मुश्किल हो जाता है।
महीने के बीच में 402 के बारे में मैं क्या करूँ?
जॉब रोकें, USDT के साथ अकाउंट पेज से टॉप अप करें, और केवल विफल अनुरोध को पुनः चलाएं। विफल प्रतिक्रिया को अपने लॉग में रखें, ताकि चार्ट में अंतराल का लिखित स्पष्टीकरण हो।
