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

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

Marco Prontera

Gilberto Cocchi

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

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

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

PubTech को परफ़ॉर्मेंस की चिंता क्यों करनी चाहिए?

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

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

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

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

आईएनपी को मेज़र करने का तरीका

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);
  });
};

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

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

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

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

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

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

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

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

नतीजे

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

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

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

नतीजा

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

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

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