फ़ील्ड में परफ़ॉर्मेंस को डीबग करना

डीबग की जानकारी के साथ परफ़ॉर्मेंस डेटा को एट्रिब्यूट करने का तरीका जानें. इससे आपको आंकड़ों से जुड़ी असल उपयोगकर्ता की समस्याओं को पहचानने और उन्हें ठीक करने में मदद मिलेगी

Philip Walton

Google, परफ़ॉर्मेंस को मेज़र करने और डीबग करने के लिए, दो कैटगरी के टूल उपलब्ध कराता है:

• लैब टूल: लाइटहाउस जैसे टूल, जिनमें आपका पेज किसी ऐसे सिम्युलेट किए गए माहौल में लोड किया जाता है जो अलग-अलग स्थितियों (उदाहरण के लिए, धीमा नेटवर्क और लो-एंड मोबाइल डिवाइस) की नकल कर सकता है.
• फ़ील्ड टूल: Chrome उपयोगकर्ता अनुभव रिपोर्ट (CrUX) जैसे टूल, जो Chrome से इकट्ठा किए गए असली उपयोगकर्ता के डेटा पर आधारित होते हैं. (ध्यान दें कि PageSpeed के बारे में अहम जानकारी और Search Console जैसे टूल से मिलने वाला फ़ील्ड डेटा, CrUX डेटा से लिया जाता है.)

हालांकि फ़ील्ड टूल ज़्यादा सटीक डेटा देते हैं—ऐसा डेटा जो असल में उपयोगकर्ताओं के अनुभव को दिखाता है, लेकिन लैब टूल अक्सर समस्याओं की पहचान करने और उन्हें ठीक करने में आपकी मदद करने के लिए बेहतर होते हैं.

CrUX डेटा से, आपके पेज की असली परफ़ॉर्मेंस के बारे में बेहतर तरीके से पता चलता है. हालांकि, CrUX स्कोर के बारे में जानकारी होने से शायद ही आपको अपने पेज की परफ़ॉर्मेंस को बेहतर बनाने का तरीका पता चल सके.

वहीं दूसरी ओर, लाइटहाउस समस्याओं का पता लगाएगा और उन्हें बेहतर बनाने के लिए खास सुझाव देगा. हालांकि, लाइटहाउस सिर्फ़ उन परफ़ॉर्मेंस से जुड़ी समस्याओं के लिए सुझाव देगा जो पेज लोड होने के समय पता चलती हैं. यह ऐसी समस्याओं का पता नहीं लगा पाता जो सिर्फ़ उपयोगकर्ता के इंटरैक्शन की वजह से होती हैं. जैसे, पेज पर स्क्रोल या बटन पर क्लिक करना.

इससे एक अहम सवाल उठता है: फ़ील्ड में मौजूद असल उपयोगकर्ताओं से, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी या अन्य मेट्रिक के लिए, डीबग की जानकारी कैसे कैप्चर की जा सकती है?

इस पोस्ट में आपको यह जानकारी मिलेगी कि Core Web Vitals से जुड़ी हर मौजूदा मेट्रिक के लिए, अतिरिक्त डीबगिंग जानकारी इकट्ठा करने के लिए, किन एपीआई का इस्तेमाल किया जा सकता है. साथ ही, आपको अपने मौजूदा Analytics टूल में, इस डेटा को कैप्चर करने का तरीका भी पता चलेगा.

एट्रिब्यूशन और डीबग करने के लिए एपीआई

कुल लेआउट शिफ़्ट (सीएलएस)

वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली सभी मेट्रिक में से, सीएलएस के लिए फ़ील्ड में डीबग की जानकारी इकट्ठा करना सबसे ज़रूरी है. सीएलएस को पेज के पूरे लाइफ़साइकल के दौरान मेज़र किया जाता है. इसलिए, उपयोगकर्ता के पेज से इंटरैक्ट करने के तरीके से, लेआउट शिफ़्ट होने या न होने और किन एलिमेंट के शिफ़्ट होने पर काफ़ी असर पड़ सकता है. जैसे, उपयोगकर्ता ने पेज को कितना स्क्रोल किया, उसने किन चीज़ों पर क्लिक किया वगैरह.

PageSpeed Insights की यह रिपोर्ट देखें:

PageSpeed Insights, फ़ील्ड और लैब, दोनों तरह का डेटा दिखाता है. हालांकि, यह डेटा अलग-अलग हो सकता है

लैब (Lighthouse) से मिली सीएलएस की वैल्यू और फ़ील्ड (CrUX डेटा) से मिली सीएलएस की वैल्यू काफ़ी अलग-अलग होती है. ऐसा इसलिए होता है, क्योंकि हो सकता है कि पेज पर बहुत ज़्यादा इंटरैक्टिव कॉन्टेंट हो, जिसका इस्तेमाल Lighthouse में जांच करते समय नहीं किया जा रहा हो.

अगर आपको पता है कि उपयोगकर्ता के इंटरैक्शन से फ़ील्ड डेटा पर असर पड़ता है, तब भी आपको यह जानने की ज़रूरत होगी कि पेज पर कौनसे एलिमेंट शिफ़्ट हो रहे हैं, ताकि 75वें पर्सेंटाइल पर 0.28 का स्कोर जनरेट हो सके. LayoutShiftAttribution इंटरफ़ेस की मदद से ऐसा किया जा सकता है.

लेआउट शिफ़्ट एट्रिब्यूशन पाएं

LayoutShiftAttribution इंटरफ़ेस, लेआउट Instability API से निकलने वाली हर layout-shift एंट्री पर दिखता है.

इन दोनों इंटरफ़ेस की ज़्यादा जानकारी के लिए, डीबग लेआउट शिफ़्ट देखें. इस पोस्ट के लिए, आपको यह जानने की ज़रूरत है कि एक डेवलपर के तौर पर, आपको पेज पर होने वाले हर लेआउट शिफ़्ट के साथ-साथ यह भी पता होना चाहिए कि कौनसे एलिमेंट शिफ़्ट हो रहे हैं.

यहां कोड का एक उदाहरण दिया गया है, जो हर लेआउट शिफ़्ट के साथ-साथ शिफ़्ट हुए एलिमेंट को भी लॉग करता है:

new PerformanceObserver((list) => {
  for (const {value, startTime, sources} of list.getEntries()) {
    // Log the shift amount and other entry info.
    console.log('Layout shift:', {value, startTime});
    if (sources) {
      for (const {node, curRect, prevRect} of sources) {
        // Log the elements that shifted.
        console.log('  Shift source:', node, {curRect, prevRect});
      }
    }
  }
}).observe({type: 'layout-shift', buffered: true});

ऐसा हो सकता है कि हर लेआउट शिफ़्ट के लिए, अपने आंकड़े जुटाने वाले टूल को डेटा भेजना और उसे मेज़र करना व्यावहारिक न हो. हालांकि, सभी शिफ़्ट पर नज़र रखकर, सबसे खराब शिफ़्ट का ट्रैक रखा जा सकता है और सिर्फ़ उनके बारे में जानकारी दी जा सकती है.

हमारा लक्ष्य, हर उपयोगकर्ता के लिए होने वाले हर लेआउट शिफ़्ट की पहचान करना और उसे ठीक करना नहीं है. हमारा लक्ष्य उन शिफ़्ट की पहचान करना है जिनसे ज़्यादा से ज़्यादा उपयोगकर्ताओं पर असर पड़ता है. साथ ही, ये शिफ़्ट आपके पेज के सीएलएस में 75वें पर्सेंटाइल में सबसे ज़्यादा योगदान देते हैं.

साथ ही, हर बार बदलाव होने पर, आपको सबसे बड़े सोर्स एलिमेंट का हिसाब लगाने की ज़रूरत नहीं है. आपको ऐसा सिर्फ़ तब करना होगा, जब आपको अपने आंकड़ों के टूल में सीएलएस वैल्यू भेजनी हो.

नीचे दिया गया कोड, layout-shift एंट्री की सूची लेता है, जो सीएलएस में योगदान देती हैं. साथ ही, सबसे बड़े शिफ़्ट से सबसे बड़ा सोर्स एलिमेंट दिखाता है:

function getCLSDebugTarget(entries) {
  const largestEntry = entries.reduce((a, b) => {
    return a && a.value > b.value ? a : b;
  });
  if (largestEntry && largestEntry.sources && largestEntry.sources.length) {
    const largestSource = largestEntry.sources.reduce((a, b) => {
      return a.node && a.previousRect.width * a.previousRect.height >
          b.previousRect.width * b.previousRect.height ? a : b;
    });
    if (largestSource) {
      return largestSource.node;
    }
  }
}

सबसे ज़्यादा बदलाव में योगदान देने वाले सबसे बड़े एलिमेंट की पहचान करने के बाद, उसकी शिकायत अपने ऐनलिटिक्स टूल से करें.

किसी पेज के सीएलएस में सबसे ज़्यादा योगदान देने वाला एलिमेंट, हर उपयोगकर्ता के लिए अलग-अलग हो सकता है. हालांकि, अगर इन एलिमेंट को सभी उपयोगकर्ताओं के लिए एग्रीगेट किया जाता है, तो आपके पास ऐसे एलिमेंट की सूची जनरेट करने का विकल्प होगा जो शिफ़्ट होने वाले ऐसे एलिमेंट की सूची जनरेट करेंगे जो सबसे ज़्यादा उपयोगकर्ताओं पर असर डालते हैं.

इन एलिमेंट में हुए बदलावों की असल वजह की पहचान करके उसे ठीक कर लेने के बाद, आपका Analytics कोड आपके पेजों के लिए "सबसे खराब" शिफ़्ट के तौर पर छोटी-छोटी शिफ़्ट रिपोर्ट करना शुरू कर देगा. आखिर में, रिपोर्ट किए गए सभी शिफ़्ट इतने छोटे होंगे कि आपके पेज 0.1 के "अच्छी" थ्रेशोल्ड के अंदर हैं!

सबसे ज़्यादा बदलाव वाले सोर्स एलिमेंट के साथ कैप्चर करने के लिए, कुछ और मेटाडेटा भी काम के हो सकते हैं:

• सबसे ज़्यादा ट्रैफ़िक आने का समय
• सबसे बड़े बदलाव के समय का यूआरएल पाथ (ऐसी साइटों के लिए जो यूआरएल को डाइनैमिक तौर पर अपडेट करती हैं, जैसे कि सिंगल पेज ऐप्लिकेशन).

सबसे बड़ा कॉन्टेंटफ़ुल पेंट (एलसीपी)

फ़ील्ड में एलसीपी को डीबग करने के लिए, आपको जिस मुख्य जानकारी की ज़रूरत होगी वह यह है कि उस खास पेज लोड के लिए कौनसा एलिमेंट सबसे बड़ा एलिमेंट (एलसीपी कैंडिडेट एलिमेंट) था.

ध्यान दें कि ऐसा किया जा सकता है. हालांकि, यह आम बात है कि एलसीपी उम्मीदवार हर उपयोगकर्ता के लिए अलग-अलग होगा, भले ही वह ठीक उसी पेज के लिए हो.

ऐसा कई वजहों से हो सकता है:

• उपयोगकर्ता के डिवाइस के स्क्रीन रिज़ॉल्यूशन अलग-अलग होते हैं, जिसकी वजह से पेज के लेआउट अलग-अलग होते हैं. इस वजह से, व्यूपोर्ट में अलग-अलग एलिमेंट दिखते हैं.
• उपयोगकर्ता हमेशा उन पेजों को लोड नहीं करते जिन्हें सबसे ऊपर तक स्क्रोल किया जाता है. अक्सर लिंक में फ़्रैगमेंट आइडेंटिफ़ायर या टेक्स्ट फ़्रैगमेंट भी होते हैं. इसका मतलब है कि आपके पेजों को पेज पर किसी भी स्क्रोल पोज़िशन पर लोड करके दिखाया जा सकता है.
• मौजूदा उपयोगकर्ता के लिए कॉन्टेंट को पसंद के मुताबिक बनाया जा सकता है. इसलिए, एलसीपी के लिए चुने गए एलिमेंट का टाइप, उपयोगकर्ता के हिसाब से काफ़ी अलग-अलग हो सकता है.

इसका मतलब यह है कि आप इस बात का अनुमान नहीं लगा सकते कि किसी खास पेज के लिए कौनसा एलिमेंट या एलिमेंट का सेट सबसे सामान्य एलसीपी कैंडिडेट एलिमेंट होगा. आपको इसे उपयोगकर्ता के असल व्यवहार के आधार पर मेज़र करना होगा.

ध्यान दें: इन अंतरों के बारे में ज़्यादा जानकारी के लिए, यह देखें: लैब और फ़ील्ड डेटा अलग क्यों हो सकते हैं और इनके लिए क्या किया जा सकता है

एलसीपी के लिए चुने गए एलिमेंट की पहचान करना

JavaScript में एलसीपी के लिए चुने जाने वाले एलिमेंट का पता लगाने के लिए, Largest Contentful Paint API का इस्तेमाल किया जा सकता है. यह वही एपीआई है जिसका इस्तेमाल एलसीपी के समय की वैल्यू का पता लगाने के लिए किया जाता है.

largest-contentful-paint एंट्री को देखते समय, पिछली एंट्री की element प्रॉपर्टी को देखकर, मौजूदा एलसीपी कैंडिडेट एलिमेंट का पता लगाया जा सकता है:

new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const lastEntry = entries[entries.length - 1];

  console.log('LCP element:', lastEntry.element);
}).observe({type: 'largest-contentful-paint', buffered: true});

चेतावनी: एलसीपी मेट्रिक के दस्तावेज़ में बताया गया है कि पेज लोड होने के दौरान, एलसीपी के लिए चुने गए एलिमेंट में बदलाव हो सकता है. इसलिए, एलसीपी के लिए चुने गए "फ़ाइनल" एलिमेंट की पहचान करने के लिए ज़्यादा काम करना पड़ता है. web-vitals JavaScript लाइब्रेरी का इस्तेमाल करके, एलसीपी के लिए "फ़ाइनल" एलिमेंट की पहचान करना और उसे मेज़र करना सबसे आसान तरीका है. इस बारे में उदाहरण में बताया गया है.

एलसीपी के लिए चुने गए एलिमेंट का पता चलने के बाद, उसे मेट्रिक वैल्यू के साथ अपने आंकड़े इकट्ठा करने वाले टूल पर भेजा जा सकता है. सीएलएस की तरह ही, इससे आपको यह पहचानने में मदद मिलेगी कि किन एलिमेंट को ऑप्टिमाइज़ करना सबसे पहले ज़रूरी है.

एलसीपी कैंडिडेट एलिमेंट के अलावा, एलसीपी के सब-पार्ट के समय को मेज़र करना भी मददगार हो सकता है. इससे यह तय करने में मदद मिल सकती है कि आपकी साइट के लिए कौनसे खास ऑप्टिमाइज़ेशन चरण काम के हैं.

पेज के रिस्पॉन्स में लगने वाला समय (आईएनपी)

सलाह: फ़ील्ड डेटा की मदद से INP को डीबग करने के बारे में ज़्यादा जानने के लिए, फ़ील्ड में धीमे इंटरैक्शन ढूंढना लेख पढ़ें.

आईएनपी के लिए फ़ील्ड में कैप्चर की जाने वाली सबसे ज़रूरी जानकारी ये हैं:

1. किस एलिमेंट से इंटरैक्ट किया गया
2. उस व्यक्ति का इंटरैक्शन किस तरह का था
3. यह इंटरैक्शन कब हुआ

इंटरैक्शन में लगने वाले समय की मुख्य वजह, ब्लॉक की गई मुख्य थ्रेड होती है. यह वजह, JavaScript लोड होने के दौरान आम तौर पर दिख सकती है. यह जानना कि ज़्यादातर इंटरैक्शन, पेज लोड होने के दौरान होते हैं या नहीं, इससे यह तय करने में मदद मिलती है कि समस्या को ठीक करने के लिए क्या करना होगा.

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

यह कोड, आईएनपी एंट्री के टारगेट एलिमेंट और समय को लॉग करता है.

function logINPDebugInfo(inpEntry) {
  console.log('INP target element:', inpEntry.target);
  console.log('INP interaction type:', inpEntry.name);
  console.log('INP time:', inpEntry.startTime);
}

ध्यान दें कि इस कोड में यह तय करने का तरीका नहीं बताया गया है कि कौनसी event एंट्री, INP एंट्री है, क्योंकि यह लॉजिक ज़्यादा जटिल है. हालांकि, नीचे दिए गए सेक्शन में बताया गया है कि web-vitals JavaScript लाइब्रेरी का इस्तेमाल करके, यह जानकारी कैसे पाई जा सकती है.

वेब-वाइटल JavaScript लाइब्रेरी के साथ इस्तेमाल

पिछले सेक्शन में, कुछ सामान्य सुझाव और कोड के उदाहरण दिए गए हैं. इनकी मदद से, डीबग की जानकारी कैप्चर की जा सकती है, ताकि Analytics टूल को भेजे जाने वाले डेटा में उसे शामिल किया जा सके.

तीसरे वर्शन में, web-vitals JavaScript लाइब्रेरी में एक एट्रिब्यूशन बिल्ड शामिल होता है. यह इस तरह की पूरी जानकारी के साथ-साथ, कुछ अतिरिक्त सिग्नल भी दिखाता है.

इस कोड के उदाहरण में दिखाया गया है कि डीबग स्ट्रिंग वाला अतिरिक्त इवेंट पैरामीटर (या कस्टम डाइमेंशन) कैसे सेट किया जा सकता है. इससे परफ़ॉर्मेंस की समस्याओं की मूल वजह का पता लगाने में मदद मिलती है.

import {onCLS, onINP, onLCP} from 'web-vitals/attribution';

function sendToGoogleAnalytics({name, value, id, attribution}) {
  const eventParams = {
    metric_value: value,
    metric_id: id,
  }

  switch (name) {
    case 'CLS':
      eventParams.debug_target = attribution.largestShiftTarget;
      break;
    case 'LCP':
      eventParams.debug_target = attribution.element;
      break;
    case 'INP':
      eventParams.debug_target = attribution.interactionTarget;
      break;
  }

  // Assumes the global `gtag()` function exists, see:
  // https://developers.google.com/analytics/devguides/collection/ga4
  gtag('event', name, eventParams);
}

onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);

यह कोड, Google Analytics के लिए खास तौर पर बनाया गया है. हालांकि, इसका सामान्य आइडिया, अन्य आंकड़ों के टूल पर भी लागू होना चाहिए.

यह कोड सिर्फ़ एक डीबग सिग्नल पर रिपोर्ट करने का तरीका भी दिखाता है, लेकिन हर मेट्रिक के लिए कई अलग-अलग सिग्नल को इकट्ठा और रिपोर्ट कर पाना उपयोगी होता है.

उदाहरण के लिए, आईएनपी को डीबग करने के लिए, हो सकता है कि आप इंटरैक्ट किए जा रहे एलिमेंट, इंटरैक्शन टाइप, समय, लोड स्टेट, इंटरैक्शन के चरण वगैरह (जैसे कि लंबी ऐनिमेशन फ़्रेम का डेटा) की जानकारी इकट्ठा करना चाहें.

web-vitals एट्रिब्यूशन बिल्ड, एट्रिब्यूशन की ज़्यादा जानकारी दिखाता है. जैसे, आईएनपी के लिए नीचे दिए गए उदाहरण में दिखाया गया है:

import {onCLS, onINP, onLCP} from 'web-vitals/attribution';

function sendToGoogleAnalytics({name, value, id, attribution}) {
  const eventParams = {
    metric_value: value,
    metric_id: id,
  }

  switch (name) {
    case 'INP':
      eventParams.debug_target = attribution.interactionTarget;
      eventParams.debug_type = attribution.interactionType;
      eventParams.debug_time = attribution.interactionTime;
      eventParams.debug_load_state = attribution.loadState;
      eventParams.debug_interaction_delay = Math.round(attribution.inputDelay);
      eventParams.debug_processing_duration = Math.round(attribution.processingDuration);
      eventParams.debug_presentation_delay =  Math.round(attribution.presentationDelay);
      break;

    // Additional metric logic...
  }

  // Assumes the global `gtag()` function exists, see:
  // https://developers.google.com/analytics/devguides/collection/ga4
  gtag('event', name, eventParams);
}

onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);

दिखाए गए डीबग सिग्नल की पूरी सूची के लिए, वेब-वाइटल एट्रिब्यूशन दस्तावेज़ देखें.

डेटा की रिपोर्ट करना और उसे विज़ुअलाइज़ करना

मेट्रिक की वैल्यू के साथ डीबग की जानकारी इकट्ठा करने के बाद, अगला चरण है डेटा को आपके सभी उपयोगकर्ताओं के लिए इकट्ठा करना, ताकि वे पैटर्न और ट्रेंड खोजना शुरू कर सकें.

जैसा कि पहले बताया गया है, आपको उन सभी समस्याओं को ठीक करने की ज़रूरत नहीं है जिनका सामना उपयोगकर्ताओं को हो रहा है. खास तौर पर, शुरुआत में उन समस्याओं को ठीक करना होगा जो सबसे ज़्यादा उपयोगकर्ताओं पर असर डाल रही हैं. यह ऐसी समस्याएं भी होनी चाहिए जिनसे आपकी वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी के स्कोर पर सबसे ज़्यादा बुरा असर पड़ता हो.

GA4 के लिए, BigQuery का इस्तेमाल करके डेटा को क्वेरी करने और उसे विज़ुअलाइज़ करने के तरीके से जुड़ा लेख पढ़ें.

खास जानकारी

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

अगर आपने अभी-अभी परफ़ॉर्मेंस को मेज़र करना शुरू किया है और आप पहले से ही Google Analytics का इस्तेमाल कर रहे हैं, तो वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली रिपोर्ट टूल का इस्तेमाल करें. यह एक अच्छा विकल्प है, क्योंकि यह वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक के लिए, डीबग करने से जुड़ी जानकारी को रिपोर्ट करने की सुविधा पहले से ही देता है.

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

आखिर में, अगर आपको लगता है कि एपीआई में सुविधाएं या जानकारी मौजूद न होने की वजह से, इन मेट्रिक को डीबग करने में समस्या आ रही है, तो अपने सुझाव, शिकायत या राय [e-mail] पर भेजें.