मुख्य लैंडिंग पेज
उत्पाद, सेवा या अभियान का परिचय देने वाले पेज की निगरानी करें क्योंकि धीमा पहला अनुभव खोज और कन्वर्ज़न दोनों प्रभावित कर सकता है।
Core Web Vitals निगरानी
प्रोजेक्ट डोमेन के चुने सार्वजनिक पेजों के LCP, CLS और लोडिंग संकेत देखें। हर URL के पाँच मीट्रिक और अलग होमपेज सारांश में Speed Index पढ़ें; केंद्रित सुधार को बाद के लैब परिणाम से जाँचें। ये नियंत्रित परीक्षण हैं, वास्तविक उपयोगकर्ताओं का फ़ील्ड डेटा नहीं।
Core Web Vitals जाँच
LCP
ऐसे चुने URL खोजें जिनमें मुख्य सामग्री देर से दिखती है।
CLS
चुने URL पर अप्रत्याशित लेआउट हलचल जाँचें।
दैनिक लैब जाँच
वर्तमान मान दर्ज करें और केंद्रित सुधार के बाद अगला लैब परिणाम देखें।
Largest Contentful Paint की निगरानी करें
Largest Contentful Paint मापता है कि परीक्षण के दिखाई देने वाले क्षेत्र में सबसे बड़ा योग्य चित्र, टेक्स्ट ब्लॉक या वीडियो कब दिखता है। निगरानी वाले हर URL के LCP से चुनें कि किस पेज की लोडिंग को अधिक विस्तार से जाँचना चाहिए।
- Screpy LCP सेकंड में दिखाता है: 2.5 सेकंड तक अच्छा, 2.5 से अधिक और 4 सेकंड तक सुधार आवश्यक, तथा 4 सेकंड से अधिक खराब है।
- तेज़ FCP के बाद धीमा LCP बताता है कि मुख्य तत्व से पहले कुछ सामग्री दिखी थी। पूरे पेज के खाली रहने का अनुमान लगाने के बजाय उस तत्व की डिलीवरी और रेंडरिंग जाँचें।
- डेवलपर के प्रदर्शन विश्लेषण से संबंधित चित्र, फ़ॉन्ट या रेंडरिंग विलंब की पुष्टि करें। अकेला आँकड़ा तत्व की पहचान नहीं करता और सुधार तय नहीं करता।
example.comलैब
LCP2.1 s
Cumulative Layout Shift मापें
पेज जल्दी लोड होने पर भी कोई बटन या अनुच्छेद अचानक खिसक सकता है। Cumulative Layout Shift निगरानी वाले हर URL का लैब स्थिरता स्कोर देता है, ताकि इस हलचल को लोडिंग गति से अलग जाँचा जा सके।
- CLS समय की इकाई नहीं है: Screpy में 0.1 तक अच्छा, 0.1 से अधिक और 0.25 तक सुधार आवश्यक, तथा 0.25 से अधिक खराब है।
- चित्रों, विज्ञापनों और एम्बेड सामग्री के लिए आरक्षित जगह तथा फ़ॉन्ट बदलने की जाँच करें। ये संभावित कारण हैं; Screpy का स्कोर खिसके हुए तत्व की पहचान नहीं करता।
- लोडिंग परीक्षण में कम CLS आने से विज़िट के बाद के हिस्से में हलचल न होने की पुष्टि नहीं होती। लोडिंग के बाद समस्या दिखे तो वास्तविक इंटरैक्शन और फ़ील्ड डेटा भी देखें।
CLS
0.04Total Blocking Time जाँचें
Total Blocking Time मुख्य थ्रेड के उस काम को पहचानने में मदद करता है जो लोडिंग के दौरान इनपुट का जवाब देने में देर कर सकता है। TBT को LCP और FCP के साथ पढ़ें: सामग्री जल्दी दिखना पेज के जल्दी प्रतिक्रिया देने की गारंटी नहीं है।
- TBT मिलीसेकंड में दिखता है: 200 ms तक अच्छा, 200 से अधिक और 600 ms तक सुधार आवश्यक, तथा 600 ms से अधिक खराब है।
- ब्लॉकिंग समय मापन अवधि में लंबे कार्यों के 50 ms से अधिक वाले हिस्सों का योग है। यह JavaScript चलने का कुल समय नहीं है।
- TBT अधिक हो तो कोड बदलने से पहले डेवलपर टूल से लंबे कार्यों और अनावश्यक स्क्रिप्ट का विश्लेषण करें। डैशबोर्ड का आँकड़ा किसी विशेष स्क्रिप्ट को विलंब का कारण नहीं बताता।
- TBT, INP नहीं है। INP इंटरैक्शन मापता है और उन इंटरैक्शन को करके लैब में भी जाँचा जा सकता है; Screpy का यह फ़ीचर INP मापन नहीं देता।
example.comलैब
TBT180 ms
FCP और TTFB की तुलना करें
First Contentful Paint पहली दिखाई देने वाली सामग्री का समय बताता है; Time to First Byte रिस्पॉन्स शुरू होने का समय बताता है। एक URL के दोनों मान पढ़ने से शुरुआती रिस्पॉन्स विलंब को स्क्रीन पर सामग्री दिखाने में लगने वाले समय से अलग कर सकते हैं।
- FCP सेकंड में दिखता है: 1.8 सेकंड तक अच्छा, 1.8 से अधिक और 3 सेकंड तक सुधार आवश्यक, तथा 3 सेकंड से अधिक खराब है।
- TTFB मिलीसेकंड में दिखता है: 800 ms तक अच्छा, 800 से अधिक और 1,800 ms तक सुधार आवश्यक, तथा 1,800 ms से अधिक खराब है। कनेक्शन, रीडायरेक्ट और रिस्पॉन्स का व्यवहार इसे प्रभावित कर सकते हैं।
- TTFB कम और FCP धीमा हो तो पहली सामग्री दिखने में बाधा जाँचें। रिस्पॉन्स धीमा हो तो पहले डिलीवरी देखें; कोई एक मान सर्वर या रेंडरिंग से जुड़ा कारण सिद्ध नहीं करता।
लैब2,100 ms
TTFB450 ms
FCP1,100 ms
LCP2,100 ms
TBT95 ms
महत्वपूर्ण वेबसाइट पेजों की निगरानी करें
एक होमपेज के परिणाम को पूरी वेबसाइट का परिणाम मानने के बजाय प्रोजेक्ट के चुनिंदा सार्वजनिक पेजों की निगरानी करें। प्लान में प्रोजेक्ट की सीमा उन पेजों पर इस्तेमाल करें जहाँ लोडिंग या लेआउट की समस्या सबसे अधिक असर डालती है।
- प्रोजेक्ट बनाते समय उसका होमपेज जोड़ा जाता है। प्लान में निगरानी उपलब्ध हो तो प्रोजेक्ट के डोमेन या सबडोमेन के अन्य सार्वजनिक URL जोड़ें।
- उत्पाद, श्रेणी, लेख और कन्वर्ज़न प्रवेश पेजों से प्रतिनिधि URL चुनें। दोहराई गई टेम्पलेट समस्या व्यापक जाँच का कारण हो सकती है, लेकिन एक URL का परीक्षण उस टेम्पलेट के हर पेज को नहीं मापता।
- URL जोड़ते समय प्रोटोकॉल और होस्ट का रूप मानकीकृत होता है, अनुपस्थित HTTPS जुड़ता है और फ़्रैगमेंट हटते हैं। पाथ और क्वेरी पैरामीटर महत्वपूर्ण रहते हैं; समान मानकीकृत URL दोबारा स्वीकार नहीं होता।
- जोड़ा गया पेज परिणाम तालिका में दिखने से पहले पहली निर्धारित जाँच का इंतज़ार करता है। URL जोड़ने से तुरंत परीक्षण नहीं चलता।
- हटाने की पुष्टि करके पेज की निगरानी रोकें और सीमा में जगह खाली करें। निगरानी का रिकॉर्ड हटता है, आपकी वेबसाइट या Google से पेज नहीं।
example.comलैब
/1.4 s/shop/linen2.8 s/guides/seo1.9 sहोमपेज का प्रदर्शन देखें
URL तालिका के ऊपर का सारांश प्रोजेक्ट के जाँचे हुए होमपेज का इस्तेमाल करता है। इसमें Speed Index सहित वर्तमान लैब मापन साथ मिलते हैं; नीचे की तालिका अपने पाँच दिखाई देने वाले मीट्रिक हर निगरानी URL से अलग-अलग जोड़ती है।
- होमपेज सारांश में FCP, LCP, CLS, TTFB, TBT और Speed Index पढ़ें। ये होमपेज के मान हैं, निगरानी वाले पेजों का औसत नहीं।
- Speed Index बताता है कि लोडिंग के दौरान दिखाई देने वाली सामग्री कितनी जल्दी बनती है। Screpy सेकंड दिखाता है: 3.4 तक अच्छा, 3.4 से अधिक और 5.8 तक सुधार आवश्यक, तथा 5.8 से अधिक खराब है।
- हर बार वर्तमान मापन दर्शाता है। यह सहेजा गया रुझान चार्ट, विज़िटर प्रतिशत या Google के फ़ील्ड डेटा का 75वाँ पर्सेंटाइल नहीं है।
- होमपेज का जाँचा हुआ परिणाम न हो तो सारांश उपलब्ध नहीं है। किसी दूसरे निगरानी URL का परिणाम उसकी जगह नहीं दिखाया जाता।
example.comलैब
LCP2.1 s
TBT180 ms
CLS0.04
दैनिक लैब जाँचों पर नज़र रखें
योग्य सक्रिय पेज एक दिन बाद अगली निर्धारित जाँच के पात्र होते हैं। किसी केंद्रित बदलाव के बाद वर्तमान परिणाम देखें; बिल्कुल तय समय पर परीक्षण की अपेक्षा के बजाय प्लान की पात्रता और जाँच पूरी होने की उपलब्धता ध्यान में रखें।
- परिणामों को पेज URL या CWV स्थिति के अनुसार क्रम दें। हर जाँचे URL के FCP, LCP, CLS, TTFB और TBT दिखाई देते हैं।
- CWV बैज उपलब्ध LCP, CLS और TBT में सबसे खराब वर्गीकरण इस्तेमाल करता है। पास का अर्थ है कि उपलब्ध ये मान अच्छे हैं; FAIL में सुधार आवश्यक और खराब दोनों परिणाम आते हैं।
- पंक्ति में पास होने पर भी अनुपस्थित मान जाँचें। किसी मीट्रिक का न होना स्वस्थ मापन नहीं माना जाता; बैज Google के फ़ील्ड LCP, INP और CLS मूल्यांकन को प्रमाणित नहीं करता।
- कोई डेटा नहीं है का अर्थ है कि लैब निष्कर्ष उपलब्ध नहीं है। अनुपस्थित मान शून्य नहीं है और असफल जाँच स्वस्थ पेज का प्रमाण नहीं है।
- सुधार प्रकाशित करने से पहले वर्तमान मान दर्ज करें, फिर उसी URL के बाद के परिणाम से तुलना करें। तालिका वर्तमान परिणाम दिखाती है, बदलाव से पहले और बाद का सहेजा इतिहास नहीं।
दैनिक09:00
123456789101112131415161718192021
SEO MCP से प्रदर्शन डेटा पढ़ें
होमपेज का सहेजा गया लैब सारांश AI बातचीत या REST इंटीग्रेशन में लें। उपलब्ध मापन का स्पष्टीकरण और केंद्रित जाँच का सुझाव माँगें, लेकिन प्रमाण को प्रस्तावित सुधार से अलग रखें।
- पहचान सत्यापित करें और वह प्रोजेक्ट चुनें जिस तक आपकी पहुँच है। REST पहुँच के लिए प्रोजेक्ट के प्लान में Core Web Vitals उपलब्ध होना भी आवश्यक है।
- उत्तर में होमपेज URL, सहेजा जाँच समय और उपलब्ध FCP, LCP, CLS, TTFB, TBT तथा Speed Index मान होते हैं। यह होमपेज का डेटा है, सभी निगरानी पेजों की सूची नहीं।
- जाँचा हुआ होमपेज न हो तो सारांश नहीं मिलता; अलग-अलग अनुपस्थित मापन अनुपलब्ध ही रहते हैं। निष्कर्ष निकालने से पहले सहायक से डेटा की कमी बताने को कहें।
- Core Web Vitals MCP टूल सहेजा डेटा पढ़ता है। यह नया परीक्षण नहीं चलाता, पेज नहीं जोड़ता, जिम्मेदार तत्व नहीं पहचानता और TBT को INP नहीं बनाता।
GET
/projectsJSON{
"data": [
{ "domain": "example.com" }
]
}Core Web Vitals पर बात करें। SEO MCP के साथ।
SEO MCP से प्रोजेक्ट के होमपेज का सहेजा लैब सारांश पढ़ें। URL और जाँच समय के साथ उपलब्ध मीट्रिक समझें और जाँच चुनें; सभी पेजों की रिपोर्ट या नया परीक्षण मिलने का अनुमान न लगाएँ।
- Screpy: नमस्ते! example.com के लिए Core Web Vitals देखें। आप क्या जानना चाहते हैं?
- आप: example.com के होमपेज के सहेजे लैब परिणाम समझाओ और बताओ कि क्या अभी अज्ञात है।
- Screpy: होमपेज के इस उदाहरण में LCP 3.2 सेकंड है और सुधार चाहिए; CLS 0.04 है और अच्छा है। मान इस्तेमाल करने से पहले सहेजा URL और जाँच समय देखें। ये दो आँकड़े हर मीट्रिक नहीं दिखाते, INP नहीं मापते और जिम्मेदार तत्व नहीं पहचानते। जाँच सुझा सकता हूँ, नया परीक्षण नहीं कर सकता। होमपेज के लैब मान का उदाहरण: LCP: 3.2 सेकंड. CLS: 0.04.
- आप: इसे एक छोटी कार्ययोजना में बदलो।
- Screpy: मैं निष्कर्ष और सुझाव अलग रखूँगा। प्रमाण देखें, एक बदलाव चुनें और बाद में नतीजे जाँचें। आपके अगले कदम: समीक्षा: हर निष्कर्ष का स्रोत और तारीख जाँचें।. निर्णय: पहला बदलाव चुनें।. सत्यापन: बदलाव के बाद नतीजों की तुलना करें।.
- आप: क्या प्रमाण को सरल भाषा में समझा सकते हो?
- Screpy: हाँ। किसी समर्थित परिणाम के बारे में पूछें। मैं बताऊँगा कि वह क्या दिखाता है, कहाँ से आया है और क्या अनिश्चित है। अनुपलब्ध डेटा अनुपलब्ध ही रहता है; सुझाव अपने-आप किए गए सुधार नहीं हैं।
धीमे URL को जाँचे जा सकने वाले प्रदर्शन सुधार में बदलें।
URL और मापन विधि स्थिर रखें, सबसे कमजोर मीट्रिक से जाँच सीमित करें और बाद की जाँच से एक बदलाव सत्यापित करें।
-
प्रतिनिधि सार्वजनिक URL चुनें
प्रोजेक्ट डोमेन या सबडोमेन के सार्वजनिक URL चुनें। प्रोजेक्ट की सीमा में होमपेज, कन्वर्ज़न प्रवेश पेज और किसी महत्वपूर्ण टेम्पलेट के प्रतिनिधि URL से शुरू करें।
-
निर्धारित लैब जाँच से आधारभूत आँकड़े बनने दें
योग्य सक्रिय URL की नियमित निर्धारित लैब जाँच होती है। पहली कोशिश के बाद जाँचे URL के उपलब्ध FCP, LCP, CLS, TTFB और TBT देखें; अलग होमपेज सारांश में Speed Index भी शामिल है।
-
कमजोर मीट्रिक से केंद्रित परिकल्पना बनाएँ
कमज़ोर मीट्रिक के आधार पर केंद्रित जाँच चुनें: मुख्य सामग्री के लिए LCP, अप्रत्याशित हलचल के लिए CLS, ब्लॉकिंग काम के लिए TBT और शुरुआती लोडिंग के लिए FCP तथा TTFB। होमपेज का Speed Index दृश्य प्रगति का संदर्भ देता है, कारण सिद्ध नहीं करता।
-
एक कारण बदलें और फिर मापें
केंद्रित बदलाव से पहले वर्तमान मान दर्ज करें, URL स्थिर रखें और बाद का निर्धारित परिणाम तुलना करें। पैनल वर्तमान मापन दिखाता है: पिछली आधाररेखा अलग रखें और एक उतार-चढ़ाव को प्रमाण मानने के बजाय दोहराए बदलाव जाँचें।
उन पेज की निगरानी करें जहाँ नई गिरावट का सबसे अधिक असर होगा।
कम महत्वपूर्ण पेज से भरे डैशबोर्ड की तुलना में छोटा प्रतिनिधि URL समूह जाँचना आसान है। व्यवसाय की महत्वपूर्ण यात्राओं और दोबारा इस्तेमाल वाले टेम्पलेट से शुरू करें।
साझा पेज टेम्पलेट
एक प्रतिनिधि उत्पाद, श्रेणी, लेख या दस्तावेज़ URL चुनें ताकि उसी टेम्पलेट में दोहराई जा सकने वाली प्रदर्शन समस्याएँ दिखें।
कन्वर्ज़न के रास्ते
स्क्रिप्ट, एम्बेड, प्रयोग या तीसरे पक्ष के टैग प्रदर्शन बदलें तो कीमत, साइनअप, लीड और चेकआउट प्रवेश पेज पर नज़र रखें।
रिलीज़ से प्रभावित पेज
वही पैटर्न व्यापक रूप से लागू करने से पहले रीडिज़ाइन, फ़्रेमवर्क बदलाव, नए मीडिया, टैग मैनेजर अपडेट या डिलीवरी बदलाव से प्रभावित URL ट्रैक करें।
लैब परिणामों का अर्थ बढ़ा-चढ़ाकर न बताएँ।
Screpy नियमित प्रदर्शन जाँच को कार्रवाई योग्य बनाने के लिए है। जब असली प्रश्न फ़ील्ड डेटा, कारण का निदान या रैंकिंग प्रभाव हो, ये सीमाएँ परिणाम का सही अर्थ बनाए रखती हैं।
लैब डेटा, फ़ील्ड डेटा नहीं
Screpy नियंत्रित पेज परीक्षण चलाता है। परिणाम Chrome UX Report या Google Search Console में दिखने वाले पिछली अवधि के वास्तविक उपयोगकर्ता डेटासेट का प्रतिनिधित्व नहीं करता।
TBT, INP नहीं है
TBT मापी गई लोडिंग अवधि के ब्लॉकिंग काम को बताता है। INP के लिए इंटरैक्शन मापन चाहिए और इंटरैक्शन करके इसे लैब में भी जाँचा जा सकता है; Screpy का यह फ़ीचर INP नहीं देता और वास्तविक उपयोगकर्ता प्रतिक्रिया के प्रमाण की जगह नहीं लेता।
निष्कर्ष मूल कारण नहीं है
खराब मीट्रिक बताता है कि कहाँ जाँचना है। बदलाव तय करने से पहले वास्तविक तत्व, अनुरोध, स्क्रिप्ट, टेम्पलेट या सर्वर व्यवहार की पुष्टि करें।
प्रदर्शन रैंकिंग की गारंटी नहीं है
अच्छा पेज अनुभव उपयोगकर्ता और खोज गुणवत्ता में मदद करता है लेकिन प्रासंगिक सामग्री, क्रॉल किए जा सकने, इंडेक्सिंग, लिंक या अन्य खोज संकेतों की जगह नहीं लेता।
प्रश्न के अनुरूप प्रदर्शन कार्यप्रवाह इस्तेमाल करें।
नियमित लैब परिणामों के लिए चुने URL की निगरानी करें, बार-बार के तकनीकी पैटर्न के लिए व्यापक वेबसाइट ऑडिट करें या Screpy की तुलना किसी फ़ील्ड डेटा रिपोर्ट से करने से पहले मापन विधि पढ़ें।
प्रोजेक्ट के चुने सार्वजनिक URL की नियमित लैब जाँच करें: तालिका में पाँच और अलग होमपेज सारांश में छह मीट्रिक देखें।
प्रभावित URL या टेम्पलेट के आसपास लिंक, चित्र और पेज की समस्याओं के लिए साइट क्रॉल करें। निष्कर्षों को तकनीकी संदर्भ मानें, प्रदर्शन का विस्तृत रिकॉर्ड नहीं।
वास्तविक उपयोगकर्ता फ़ील्ड रिपोर्ट से तुलना से पहले Screpy लैब डेटा का दायरा, समय और सीमाएँ समझें।
Screpy दस्तावेज़
लैब प्रदर्शन जाँच समझना सीखें
URL चुनने, लैब मीट्रिक पढ़ने और फ़ील्ड डेटा से अलग करने के लिए गाइड इस्तेमाल करें। केंद्रित सुधार को बाद के परिणाम से जाँचने से पहले शुरुआती आधाररेखा अलग दर्ज करें।
Core Web Vitals के सामान्य प्रश्न
लैब और फ़ील्ड डेटा का अंतर, LCP, CLS, TBT, सहायक गति मीट्रिक, दैनिक जाँच, URL चयन, निष्कर्ष और पेज अनुभव के दावों की सीमाएँ समझें।
पहले किन पेज की निगरानी करूँ?
होमपेज, महत्वपूर्ण सार्वजनिक लैंडिंग पेज, कन्वर्ज़न प्रवेश और हर महत्वपूर्ण टेम्पलेट के एक प्रतिनिधि URL से शुरू करें। जोड़े URL प्रोजेक्ट डोमेन या सबडोमेन के होने चाहिए और प्लान सीमा में आने चाहिए। टेम्पलेट का एक नमूना उसके सभी पेजों को नहीं जाँचता।
Screpy INP के बजाय TBT क्यों दिखाता है?
यह फ़ीचर लोडिंग मापता है और ब्लॉकिंग का संकेत TBT देता है; INP के लिए ज़रूरी इंटरैक्शन नहीं मापता। इंटरैक्शन करके INP को लैब में भी जाँच सकते हैं, लेकिन TBT मान INP नहीं है और लोडिंग के बाद हर इंटरैक्शन नहीं बताता।
Screpy Core Web Vitals Monitoring क्या मापता है?
Screpy की URL तालिका में लैब FCP, LCP, CLS, TTFB और TBT दिखते हैं। जाँचे हुए होमपेज का सारांश Speed Index जोड़ता है। तालिका पास/FAIL का निष्कर्ष देती है; प्रमाणित API और MCP उत्तर में होमपेज URL तथा सहेजा जाँच समय भी होता है। ये वास्तविक उपयोगकर्ता मापन नहीं हैं।
क्या Screpy Core Web Vitals डेटा वास्तविक उपयोगकर्ताओं पर आधारित है?
नहीं। Screpy जाँचे URL के नियंत्रित लैब मापन बताता है। Chrome UX Report या Google Search Console का फ़ील्ड डेटा लगातार बदलती संग्रह अवधि की वास्तविक विज़िट दर्शाता है और डिवाइस, नेटवर्क, भूगोल तथा उपयोगकर्ता व्यवहार अलग होने से भिन्न हो सकता है।
निगरानी URL कितनी बार जाँचे जाते हैं?
योग्य सक्रिय URL एक दिन बाद अगली निर्धारित जाँच के पात्र होते हैं। प्रोजेक्ट का प्लान और जाँच पूरी होने की उपलब्धता समय प्रभावित करते हैं; हर दिन एक ही समय पर परिणाम की गारंटी नहीं है। नया URL पहली जाँच की कोशिश के बाद तालिका में दिखता है।
आधिकारिक Core Web Vitals कौन से मीट्रिक हैं?
Google वर्तमान में Largest Contentful Paint, Interaction to Next Paint और Cumulative Layout Shift को Core Web Vitals मानता है। Screpy लैब जाँच में LCP और CLS मापता है तथा FCP, TTFB और Speed Index के साथ TBT को लैब प्रतिक्रिया क्षमता का निदान संकेत बताता है। यह TBT को INP नहीं बताता।
क्या Core Web Vitals सुधारने से बेहतर रैंकिंग की गारंटी है?
नहीं। Google उपयोगकर्ता और खोज के लिए अच्छे Core Web Vitals सुझाता है, लेकिन पेज अनुभव बहुत बड़े संकेत समूह का केवल एक हिस्सा है। कमजोर पेज अनुभव के साथ भी प्रासंगिक सामग्री रैंक कर सकती है और तेज़ पेज की रैंकिंग की गारंटी नहीं है।
क्या Screpy में पास का मतलब URL Google Core Web Vitals में भी पास है?
नहीं। तालिका का निष्कर्ष उपलब्ध लैब LCP, CLS और TBT में सबसे खराब वर्गीकरण इस्तेमाल करता है और कुछ मान अनुपस्थित हो सकते हैं। Google INP सहित वास्तविक उपयोगकर्ता Core Web Vitals डेटा अपनी डेटा उपलब्धता और पर्सेंटाइल संबंधी शर्तों के अनुसार आँकता है। निष्कर्ष से पहले उपलब्ध मीट्रिक और संबंधित फ़ील्ड रिपोर्ट देखें।