PubTech के सहमति मैनेजमेंट प्लैटफ़ॉर्म ने अपने ग्राहकों की वेबसाइटों पर आईएनपी में 64% तक की कमी कैसे की. साथ ही, विज्ञापन दिखने से जुड़े आंकड़ों में भी 1.5% तक की बढ़ोतरी हुई

कैसे PubConsent सीएमपी ने अपने ग्राहकों के लिए आईएनपी को 64% तक कम कर दिया. यह एक ऐसी अच्छी रणनीति का इस्तेमाल करता है जो Chrome DevTools का इस्तेमाल करके, रिस्पॉन्सिवनेस से जुड़ी समस्याओं को ठीक करने के लिए, ब्राउज़र के शेड्यूलर एपीआई का इस्तेमाल करती है.

Marco Prontera

Gilberto Cocchi

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

PubConsent सीएमपी, PubTech का नया प्रॉडक्ट है. PubConsent सीएमपी को परफ़ॉर्मेंस पर खास ध्यान देने के लिए डिज़ाइन किया गया है. यह कम वज़न और उपयोगकर्ता को बेहतर अनुभव देने के लिए डिज़ाइन किया गया है. साथ ही, यह वेबसाइट की पूरी परफ़ॉर्मेंस पर कम से कम असर डालता है.

इंटरैक्शन टू नेक्स्ट पेंट (आईएनपी) मेट्रिक लॉन्च करने से, PubTech को हमारे सीएमपी के रिस्पॉन्सिव होने से जुड़ी समस्याओं का पता चला. इस केस स्टडी में, PubTech ने दिखाया कि उन्होंने अपने PubConsent सीएमपी प्लैटफ़ॉर्म में रिस्पॉन्सिवनेस से जुड़ी समस्याओं को कैसे हल किया. साथ ही, मार्च 2024 में वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली रिपोर्ट में शामिल होने से पहले, उन्होंने आईएनपी में सुधार कैसे किया. यह दिखाता है कि उन्होंने सीएमपी प्रॉडक्ट की सबसे अच्छी परफ़ॉर्मेंस देने का वादा किया है.

PubTech ने परफ़ॉर्मेंस पर ध्यान क्यों दिया?

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

बेहतर परफ़ॉर्मेंस को प्राथमिकता देने और PubConsent सीएमपी स्क्रिप्ट को सामान्य बनाए रखने से, वेबसाइट के मालिक सहमति मैनेजमेंट से जुड़ी अहम सुविधाएं इस्तेमाल करने के साथ-साथ उपयोगकर्ता अनुभव को भी बरकरार रख सकते हैं.

सीएमपी से मिलने वाली सुविधाओं और परफ़ॉर्मेंस पर पड़ने वाले असर को ध्यान में रखते हुए, PubTech ने ये लक्ष्य तय किए हैं:

आईएनपी पर PubConsent सीएमपी प्रॉडक्ट के असर को कम करें.
सीएमपी प्रॉडक्ट से जुड़े लंबे टास्क कम करें.
टोटल ब्लॉकिंग टाइम (टीबीटी) को कम करें. इससे किसी पेज के आईएनपी पर गलत असर पड़ सकता है.

आईएनपी को कैसे मापा जाता है

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

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

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

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

PubTech ने बटन और लिंक के लिए, आईएनपी को कैसे ऑप्टिमाइज़ किया

आईएनपी को बेहतर बनाने के लिए, PubConsent सीएमपी में यील्ड से जुड़ी अलग-अलग रणनीतियां अपनाई गईं.

ज़्यादा प्राथमिकता वाले टास्क उपलब्ध कराएं

नीचे दिए गए कोड स्निपेट में दिखाए गए yieldToMainUiBlocking तरीके को इस तरह से डिज़ाइन किया गया है कि ज़्यादा प्राथमिकता वाले JavaScript टास्क ऑप्टिमाइज़ किए जा सकें. इसके लिए, उपलब्ध होने पर scheduler.yield दिया जाता है. हालांकि, postTask उपलब्ध होने पर, user-blocking (ज़्यादा) प्राथमिकता के साथ postTask पर वापस जाकर काम किया जाता है. हालांकि, इसके बाद भी कोई बदलाव नहीं होता.

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

function yieldToMainUiBlocking () {
  return new Promise((resolve) => {
    if ('scheduler' in window) {
      if ('yield' in window.scheduler) {
        return window.scheduler.yield().then(() => resolve(true));
      }

      if ('postTask' in window.scheduler) {
        return window.scheduler.postTask(() => resolve(true), { priority: 'user-blocking' });
      }
    }

    resolve(false);
  });
};

मीडियम और बैकग्राउंड में होने वाले टास्क से फ़ायदा पाएं

इस कोड स्निपेट में दिखाए गए yieldToMainBackground तरीके का इस्तेमाल, ऐसे लंबे टास्क को अलग करने के लिए किया जाता है जिनकी प्राथमिकता user-visible (मीडियम) या background है. उपलब्ध होने पर लॉजिक, scheduler.yield() को लागू करता है. हालांकि, यह मध्यम प्राथमिकता के साथ postTask का इस्तेमाल करने की वजह से अलग हो जाता है. इसके बाद, बिना Chromium वाले ब्राउज़र पर यह setTimeout पर वापस आ जाता है.

function yieldToMainBackground () {
  return new Promise((resolve) => {
    if ('scheduler' in window) {
      if ('yield' in window.scheduler) {
        return window.scheduler.yield().then(() => resolve(true));
      }

      if ('postTask' in window.scheduler) {
        return window.scheduler.postTask(() => resolve(true), { priority: 'user-visible' });
      }
    }

    setTimeout(() => { resolve(true) }, 0);
  });
};

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

इस फ़्लो में यह दिखाया जाता है कि किसी उपयोगकर्ता के 'सभी स्वीकार करें' पर क्लिक करने के बाद, यूज़र इंटरफ़ेस को अपडेट होने से कितनी देर तक चलने वाले टास्क की वजह से उसे कितनी देर तक अपडेट होने से रोका गया PubConsent सीएमपी में बटन को ऑप्टिमाइज़ किया गया है. अब पांच चरण संभव होने पर जनरेट होते हैं, जिससे यूज़र इंटरफ़ेस अपनी रेंडरिंग को जल्दी अपडेट कर पाता है. — `yieldToMainBackground` का इस्तेमाल करके फ़ायदे को विज़ुअल तौर पर दिखाने से, ब्राउज़र अगले पेंट (इस मामले में सीएमपी यूज़र इंटरफ़ेस को बंद करना) को जल्दी रेंडर कर पाता है.

PubTech ने रेंडरिंग लेआउट को ऑप्टिमाइज़ करके, टीबीटी को कैसे कम किया

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

Chrome DevTools में परफ़ॉर्मेंस पैनल का स्क्रीनशॉट, जिसमें ट्रेस का एक सेक्शन दिख रहा है. इसमें गतिविधि का एक कॉल स्टैक मौजूद है, जो PubConsent सीएमपी में यूज़र इंटरफ़ेस (यूआई) डायलॉग को बंद करने के लिए दिख रहा है. यूज़र इंटरफ़ेस (यूआई) डायलॉग को बंद करने वाला टास्क, ऐसे डीओएम नोड को हटाने के लिए ट्रिगर करता है जो इंटरैक्शन के प्रज़ेंटेशन में देरी करते हैं.

डीओएम से एलिमेंट को हटाने के लिए, रेंडरिंग के काम की संख्या में बढ़ोतरी होना ज़रूरी है. इस समस्या को हल करने के लिए, टीम ने "लेज़ी डी-रेंडरिंग" नाम का एक समाधान पेश किया. इस तरीके से, सीएमपी के सहमति वाले डायलॉग बॉक्स पर सबसे पहले display: none सीएसएस नियम लागू होता है. ऐसा तब होता है, जब उपयोगकर्ता इस नियम को छिपाने के लिए सहमति देता है. इसके बाद, सीएमपी डायलॉग से जुड़े डीओएम नोड को हटाने पर, वे बाद के समय पर शिफ़्ट हो जाते हैं. ऐसा तब होता है, जब ब्राउज़र requestIdleCallback का इस्तेमाल करके कुछ समय से इस्तेमाल में नहीं है. जब उपयोगकर्ता ने सहमति वाला डायलॉग बॉक्स बंद किया, तब यह तरीका डीओएम नोड को हटाने की तुलना में ज़्यादा तेज़ था.

Chrome DevTools में परफ़ॉर्मेंस पैनल का स्क्रीनशॉट, जिसमें पहले की तरह ही ट्रेस दिख रहा है, लेकिन उसे ऑप्टिमाइज़ किया गया है. PubConsent सीएमपी का डायलॉग बंद होने पर, सबसे पहले सीएसएस डिसप्ले का इस्तेमाल करके उसे छिपाया जाता है: कोई नियम नहीं. इसके बाद, जब ब्राउज़र कुछ समय से इस्तेमाल में नहीं होता है, तो डीओएम नोड को हटाया जाता है. — डीओएम हटाने वाले टास्क को शिफ़्ट करके, आईएनपी में सुधार को हाइलाइट करने वाला DevTools स्क्रीनशॉट.

किस तरह PubTech ने IAB टीसीएफ़ लाइब्रेरी को बेहतर बनाकर आईएनपी को कम किया

सीएमपी की रिस्पॉन्सिवनेस से जुड़ी ज़्यादातर समस्याओं को हल करने के बाद, इसकी एक मुख्य डिपेंडेंसी में सुधार करने के अवसरों की पहचान की गई: IAB पारदर्शिता और सहमति फ़्रेमवर्क (TCF) लाइब्रेरी.

इस लाइब्रेरी के सबसे महंगे कॉम्पोनेंट "बिल्ड स्ट्रिंग" थे और "सहमति भेजें" शामिल हैं. ये कॉम्पोनेंट, IAB टीसीएफ़ लाइब्रेरी के अहम हिस्से हैं. इन कॉम्पोनेंट के लिए नीचे दिए गए ऑप्टिमाइज़ेशन, खास तौर पर PubTech की ज़रूरतों के लिए एक अलग फ़ोर्क में लागू किए गए थे:

डिकोड करने की प्रोसेस के लिए, आपके दिए गए फ़ॉर्मूला के आधार पर तैयार किए गए नतीजों का दोबारा इस्तेमाल करना. इन्हें तीसरे पक्ष के हर उस कॉलबैक के लिए लागू किया जाता है जिसे उपयोगकर्ता की सहमति पढ़ने की ज़रूरत होती है.
पब्लिशर की पाबंदियों को कोड में बदलने की प्रोसेस में, ग़ैर-ज़रूरी लूप से बचा गया और उन्हें कम किया गया. यह प्रोसेस, उपयोगकर्ता की सहमति मिलने के बाद लागू होती है.

इनमें से पहले ऑप्टिमाइज़ेशन से, सीएमपी के लिए तीसरे पक्ष के हर उस कॉलबैक में लगने वाले समय को कम किया गया जो IAB टीसीएफ़ लाइब्रेरी से जुड़े हुए थे. दूसरे ऑप्टिमाइज़ेशन ने "बिल्ड स्ट्रिंग" की प्रोसेसिंग के समय को कम कर दिया है कॉम्पोनेंट. असल में, इस ऑप्टिमाइज़ेशन की मदद से लूप के 60% तक कम किए जा सकते हैं, जो हर बार किसी उपयोगकर्ता की सहमति मिलने पर किए जाते थे.

नतीजे

पहले उपलब्ध रणनीतियों और रेंडरिंग लेआउट के नए ऑप्टिमाइज़ेशन की वजह से, सीएमपी के आईएनपी में 65%तक की बढ़ोतरी हुई. इस वजह से, PubConsent सीएमपी के उपयोगकर्ता अनुभव के रिस्पॉन्स में बहुत सुधार हुआ. साथ ही, विज्ञापनों का अनुरोध किए जाने पर ऑप्टिमाइज़ करने से, कुछ विज्ञापनों के विज्ञापन दिखने से जुड़े आंकड़ों में 1.5% की बढ़ोतरी हुई.

इन सुधारों के अलावा, IAB की टीसीएफ़ लाइब्रेरी में यह देखा गया कि जिन ग्राहकों पर इस समस्या का असर पड़ा था उनके मोबाइल पर आईएनपी में 77% तक की बढ़ोतरी हुई. इसकी वजह यह है कि टीसीएफ़ से मिलने वाले लंबे टास्क में 85% तक की कमी आई. इससे, किसी पेज के पूरे लाइफ़साइकल के दौरान लागू किए गए, तीसरे पक्ष के हर कॉलबैक के ओवरहेड को कम करने में मदद मिली.

PubConsent सीएमपी का इस्तेमाल करते समय, आईएनपी से पास होने वाले ऑरिजिन की संख्या 400% से ज़्यादा हो गई. यह संख्या मोबाइल पर 13% से बढ़कर 55% हो गई. PubTech SDK टूल के ऑप्टिमाइज़ेशन की वजह से, कुछ ग्राहकों के लिए पेज आईएनपी को 470 मिलीसेकंड से बढ़ाकर 230 मिलीसेकंड कर दिया गया.

PubTech सीएमपी का इस्तेमाल करने वाली साइटों के लिए, ऑरिजिन आईएनपी पास रेट का स्क्रीनशॉट. डेस्कटॉप पर, पास रेट करीब 84% से बढ़कर 99.12% हो गया है. मोबाइल पर, पास रेट करीब 22% से बढ़कर 55.46% हो गया है. — एचटीटीपी संग्रह और Chrome के उपयोगकर्ता अनुभव से जुड़ी रिपोर्ट (CrUX) की रिपोर्ट के मुताबिक, PubTech सीएमपी का इस्तेमाल करने वाली साइटों के लिए, ऑरिजिन आईएनपी पास रेट.

एक डैशबोर्ड का स्क्रीनशॉट, जिसमें 75वें पर्सेंटाइल पर आरयूएम डेटा से आईएनपी को दिखाया गया है. जुलाई/अगस्त 2023 से, आईएनपी 500 मिलीसेकंड से सिर्फ़ नीचे है, लेकिन फ़रवरी 2024 के मध्य तक, आईएनपी 200 मिलीसेकंड से सिर्फ़ नीचे चला गया है. इसलिए, आईएनपी इसे 'अच्छा' की सूची में रख देता है थ्रेशोल्ड. — PubConsent के ग्राहक के मोबाइल आईएनपी डेटा में सुधार का रुझान. यह रुझान, इस केस स्टडी में बताए गए SDK टूल के बदलावों से जुड़ा है.

नतीजा

PubTech के ग्राहकों ने हमारे ऑप्टिमाइज़ेशन की कोशिशों की वजह से, आईएनपी की परफ़ॉर्मेंस और कारोबार की मेट्रिक के सकारात्मक नतीजों को जल्दी पहचान लिया है. साथ ही, PubConsent के सीएमपी की परफ़ॉर्मेंस में और सुधार किए जा रहे हैं. इसके लिए, वे अपने ग्राहकों से मिलने वाले, असली उपयोगकर्ता मॉनिटर (आरयूएम) डेटा का इस्तेमाल कर रहे हैं. यह डेटा, रिग्रेशन और परफ़ॉर्मेंस में हुए बदलावों, दोनों को बारीकी से ट्रैक करता है. इससे PubTech ने लगातार सुधार करने की कोशिश की है.

तीसरे पक्ष के तौर पर, PubTech को यह एहसास हुआ कि वे बड़े पैमाने पर वेब की परफ़ॉर्मेंस को बेहतर बना सकते हैं और रिस्पॉन्स को भी बेहतर बना सकते हैं. साथ ही, वे कारोबार के केपीआई पर खराब असर से बचा सकते हैं. इस तरह के सुधारों को लागू करने में कभी देर नहीं होती!

इस इनोवेशन में मदद करने के लिए, PubTech सीटीओ लूका कोपोला और Google के जेरेमी वैगनर, माइकल मोक्नी, और रिक विस्कोमी को धन्यवाद.