Inside the Prebid.js wrapper

0:00Welcome, outcomes and key terms

Play from 0:00 हैदराबाद का एक news publisher एक सीधा सा सवाल पूछता है। हमारे ads इतनी देर से क्यों आते हैं?

Play from 0:18 हम उनका wrapper खोलते हैं। Timeout कभी set ही नहीं किया गया था, तो Prebid हर page पर तीन seconds तक इंतज़ार कर सकता है। उनके सबसे धीमे pages पर पहला ad, article के साढ़े तीन seconds बाद आता है। ये एक illustrative case है। तब तक ज़्यादातर readers उस slot से आगे scroll कर चुके होते हैं।

Play from 0:27 Fix बस एक line का था। उसे ढूँढने के लिए पता होना चाहिए था कि देखना कहाँ है। ये Header Bidding Masterclass का Module दो है: Prebid.js wrapper के अंदर।

Play from 0:38 इस module के आख़िर तक आप चार चीज़ें कर पाएँगे।

Play from 0:41 एक पूरा Prebid wrapper line by line पढ़ना, और वो चार गलतियाँ पकड़ना जो चुपचाप पैसा खाती हैं।

Play from 0:48 एक सही split test से timeout चुनना, जिसे हर हज़ार sessions पर revenue से आँका जाए।

Play from 0:55 Ad slots को आपके Core Web Vitals बिगाड़ने से रोकना: LCP, INP और CLS।

Play from 1:01 और consent, identity और data modules को सही order में लगाना, हर एक के time budget के साथ।

Play from 1:10 इस module के आठ terms।

Play from 1:12 bidsBackHandler वो function है जिसे Prebid अपना auction पूरा होने पर call करता है। Failsafe timeout आपका अपना timer है जो कुछ भी गड़बड़ होने पर ad server को call कर देता है। disableInitialLoad, GPT से कहता है कि ads माँगने से पहले आपके signal का इंतज़ार करे। bidderTimeout बताता है कि Prebid bids के लिए कितनी देर इंतज़ार करता है।

Play from 1:35 LCP यानी Largest Contentful Paint बताता है कि main content कितनी जल्दी दिखता है। INP यानी Interaction to Next Paint बताता है कि page एक tap पर कितनी जल्दी react करता है। CLS यानी Cumulative Layout Shift बताता है कि page कितना उछलता है। और auction delay वो समय है जो Prebid auction से पहले रुकता है, ताकि दूसरे modules अपना काम पूरा कर लें।

Play from 2:00 आप आठ में से Module दो में हैं। Module एक ने एक auction को follow किया। ये module वो code खोलता है जो उस auction को चलाता है।

Play from 2:10 उसके बाद Module तीन auction का एक हिस्सा server पर ले जाता है। अगर आप पहले से एक Prebid wrapper maintain करते हैं तो chapter एक आपके लिए revision हो सकता है। Timeouts के लिए सीधे chapter दो पर जाइए।

2:20Read a wrapper, line by line

Play from 2:20 Chapter एक। चलिए एक पूरा wrapper साथ में पढ़ते हैं। ये वही असली wrapper है जो हमारी demo site पर चल रहा है। अगर आप developer नहीं हैं तो चिंता मत कीजिए। हम इसे intent के लिए पढ़ेंगे, syntax के लिए नहीं।

Play from 2:34 ये रहा पूरा wrapper, पाँच blocks में समेटा हुआ।

Play from 2:37 Block एक में दोनों libraries load होती हैं। Block दो में दो numbers set होते हैं और ad units की list बनती है। Block तीन GPT को रुकने के लिए कहता है। Block चार Prebid को configure करता है और auction चलाता है। और block पाँच Ad Manager को काम सौंपता है और slot define करता है।

Play from 2:50 कुल मिलाकर लगभग पचास lines। Prebid और GPT वाले हर page पर इन पाँच blocks का कोई न कोई version होता है।

Play from 3:05 Wrapper की शुरुआत Google Publisher Tag और Prebid को load करने से होती है।

Play from 3:10 दोनों scripts async attribute के साथ load होती हैं। इसका मतलब है कि जब तक ये download होती हैं, browser article बनाता रहता है। आपकी headline ad code का इंतज़ार नहीं करती।

Play from 3:21 फिर आती हैं दो command queues: googletag dot cmd और pbjs dot que। किसी भी library के load होने से पहले ही आप इनमें commands डाल सकते हैं। Library तैयार होते ही वो order में चल जाएँगी।

Play from 3:37 अब दो numbers।

Play from 3:38 PREBID_TIMEOUT, यहाँ एक हज़ार milliseconds। Header auction इतनी देर तक चल सकता है।

Play from 3:44 FAILSAFE_TIMEOUT, तीन हज़ार milliseconds। अगर कुछ भी गड़बड़ हो तो page उस समय ad server को call कर ही देता है।

Play from 3:52 तीन गुना बड़ा क्यों? Failsafe timer तब शुरू होता है जब ये code चलता है, auction शुरू होने पर नहीं। अगर slow connection पर Prebid की file download होने में आठ सौ milliseconds लगें तो auction लगभग एक point आठ seconds पर ख़त्म होगा। Prebid की अपनी guidance बस इतनी है कि failsafe, auction timeout से काफ़ी बड़ा होना चाहिए।

Play from 4:12 फिर ad units। ये आपकी inventory list है।

Play from 4:15 Code, GPT slot से match होना चाहिए। Default रूप से Prebid slot की div ID या उसका Ad Manager ad unit path, दोनों में से कोई भी मान लेता है। ज़्यादातर wrappers div ID इस्तेमाल करते हैं, और हमारा भी।

Play from 4:30 mediaTypes बताता है कि यहाँ क्या दिख सकता है। इस case में तीन सौ बाय दो सौ पचास का एक banner।

Play from 4:36 और bids array हर partner की list देता है, उसके अपने parameters के साथ, जैसे placement ID।

Play from 4:43 Prebid ग्यारह में ये code एक और काम करता है। Viewability मापने के लिए Prebid इसी से page पर slot का element ढूँढता है। अब एक गलत code एक नहीं, दो चीज़ें तोड़ता है।

Play from 4:58 Block तीन बस एक line का है, और यही वो line है जिसे लोग भूल जाते हैं।

Play from 5:03 googletag dot pubads dot disableInitialLoad।

Play from 5:08 इसके बिना, जैसे ही page किसी slot पर display call करता है, GPT एक ad माँग लेता है। ये request Prebid के पास कोई भी bid आने से पहले ही निकल जाती है।

Play from 5:18 इसके साथ display सिर्फ़ slot को draw करता है। जब तक wrapper auction के बाद refresh call नहीं करता, तब तक कोई request नहीं जाती।

Play from 5:27 Block चार Prebid का हिस्सा है।

Play from 5:29 setConfig global settings लगाता है। यहाँ medium price granularity और bidder timeout।

Play from 5:36 addAdUnits inventory को register करता है। requestBids auction शुरू करता है, उसी timeout के साथ और एक और चीज़ के साथ: bidsBackHandler।

Play from 5:45 bidsBackHandler इस wrapper की सबसे ज़रूरी line है। Prebid इसे तब call करता है जब हर bid वापस आ जाए, या timeout हो जाए। यहाँ ये initAdserver नाम का एक function call करता है।

Play from 5:58 आपको एक line और दिखेगी जो test bids on करती है। वो सिर्फ़ हमारे demo के लिए है। Live site पर उसकी कोई जगह नहीं है।

Play from 6:06 setConfig की एक detail जिसमें teams अक्सर फँस जाती हैं।

Play from 6:10 हर call, top level पर दी गई values को replace कर देती है। अगर एक script first-party data object set करती है, और दूसरी script एक और object के साथ setConfig call करती है, तो पहला वाला गायब हो जाता है।

Play from 6:24 जब दो scripts दोनों settings जोड़ती हैं तो उसकी जगह mergeConfig इस्तेमाल कीजिए। ये पहले की वो values रखता है जो आपस में टकराती नहीं हैं।

Play from 6:33 ये रहा initAdserver।

Play from 6:34 सबसे पहले एक guard। अगर ad server पहले ही call हो चुका है तो कुछ मत करो। जब auction और failsafe दोनों fire होते हैं तो ये double requests रोकता है।

Play from 6:43 फिर दोनों queues के अंदर Prebid हर matching slot पर अपनी targeting लिखता है। यही है setTargetingForGPTAsync।

Play from 6:49 और GPT slots को refresh करता है, जिससे request Ad Manager के पास जाती है।

Play from 6:55 आख़िर में failsafe। एक simple timer जो तीन seconds बाद initAdserver को call करता है, चाहे कुछ भी हो।

Play from 7:03 आख़िरी कुछ lines पूरी तरह GPT की हैं।

Play from 7:06 defineSlot, Ad Manager ad unit, size और div का नाम देता है। enableSingleRequest, GPT से कहता है कि page के हर slot को एक ही request में fetch करे। enableServices, GPT को on करता है।

Play from 7:21 और page body में display slot को draw करता है। Initial load disabled है, इसलिए display कुछ fetch नहीं करता। ये काम initAdserver वाला refresh करता है।

Play from 7:32 तो ये रहे वो चार हिस्से जो याद रखने लायक हैं।

Play from 7:35 requestBids parallel auction शुरू करता है। bidsBackHandler signal है कि Prebid का काम हो गया। setTargetingForGPTAsync जीतने वाली bids को key-values में लिखता है। और failsafe timer आपका safety net है, अगर कुछ भी टूट जाए।

Play from 7:46 अगर आप ये चारों किसी colleague को समझा सकते हैं तो Prebid page पर जो होता है उसका ज़्यादातर हिस्सा आप समझते हैं।

Play from 7:59 Wrapper का audit करने के लिए आपको source code की ज़रूरत नहीं है। आप चलते हुए page से ही पूछ सकते हैं।

Play from 8:38 पहला सवाल। ये कौन सा Prebid है? Version ग्यारह point चार नौ। कोई भी documentation पढ़ने से पहले ये जानना ज़रूरी है।

Play from 8:57 असल में कौन सा timeout चल रहा है? एक हज़ार milliseconds। अगर यहाँ तीन हज़ार लिखा होता तो आपको वो default मिल जाता जिसे किसी ने बदला ही नहीं।

Play from 9:07 और price granularity? Medium, यानी दस सेंट के buckets।

Play from 9:12 अब सबसे ज़रूरी check। Prebid के ad unit codes और GPT के slot IDs। दोनों में div-mpu लिखा है। ये match करते हैं।

Play from 9:14 और ये build कितना बड़ा है? लगभग आठ सौ modules। हमारा demo Prebid का full build इस्तेमाल करता है। Demo के लिए ये ठीक है, लेकिन असली site के लिए बहुत बुरा। इस पर हम chapter पाँच में वापस आएँगे।

Play from 9:15 अब एक टूटी हुई copy। वही page, लेकिन Prebid code में div-mpu-1 लिखा है। क्या auction फिर भी चला? हाँ। RediAds जीता, पहले की तरह।

Play from 9:16 लेकिन slot को क्या मिला? कुछ नहीं। एक खाली list। Ad फिर भी serve हुआ, लेकिन Ad Manager ने बिना किसी header bid के फ़ैसला किया। Console में कुछ भी लाल नहीं हुआ। इसीलिए ये गलती महीनों तक बची रहती है।

Play from 9:17 Wrapper की चार गलतियाँ जो हम बार-बार देखते हैं।

Play from 9:20 पहली: ad unit codes जो slot IDs से match नहीं करते। Auction चलता है, लेकिन उसकी bids कभी ad server तक नहीं पहुँचतीं।

Play from 9:30 दूसरी: failsafe है ही नहीं, या failsafe timeout से छोटा है। एक partner अटका और slot खाली रह जाता है। या auction बीच में ही कट जाता है।

Play from 9:39 तीसरी: Prebid का काम ख़त्म होने से पहले ही GPT का ads माँग लेना। आमतौर पर initial load disable नहीं किया गया होता, या कोई theme script बहुत जल्दी refresh call कर देती है।

Play from 9:51 चौथी: नया auction चलाए बिना slot को refresh करना। पुरानी key-values फिर से भेजी जाती हैं, और वही bid बार-बार render हो सकती है। Prebid इसे stale render कहता है।

10:03What a timeout really does

Play from 10:03 Chapter दो। Timeout आपके wrapper का सबसे ज़रूरी नंबर है। चलिए ठीक-ठीक देखते हैं कि जब ये आता है तब क्या होता है।

Play from 10:13 हर Prebid page पर दो घड़ियाँ चलती हैं।

Play from 10:15 Prebid की घड़ी है bidder timeout। ये requestBids call होने पर शुरू होती है, और Prebid का auction ख़त्म करती है।

Play from 10:23 आपकी घड़ी है failsafe। ये wrapper चलने पर शुरू होती है, और Prebid चाहे कुछ भी कर रहा हो, ये ad server को call कर देती है।

Play from 10:31 एक detail। अगर आप requestBids को timeout देते हैं तो उस auction के लिए वही इस्तेमाल होता है। अगर नहीं देते तो Prebid setConfig वाला bidderTimeout इस्तेमाल करता है। और अगर किसी ने कुछ भी set नहीं किया तो default तीन हज़ार milliseconds है।

Play from 10:45 तो जिस पल bidder timeout आता है, उस पल क्या होता है?

Play from 10:49 Prebid इंतज़ार बंद कर देता है, और जो bids उसके पास हैं उन्हीं से अपना auction चलाता है।

Play from 10:54 वो आपके bidsBackHandler को call करता है, और उसे बताता है कि auction का time out हो गया।

Play from 10:59 जो bids अभी रास्ते में हैं वो बाहर रह जाती हैं, चाहे कितनी भी ऊँची हों। Default रूप से Prebid उन अधूरी requests को cancel भी कर देता है, क्योंकि उनके जवाब अब काम नहीं आ सकते।

Play from 11:12 इस deadline के बारे में एक ईमानदार बात।

Play from 11:15 Browsers timers को तब चलाते हैं जब उन्हें मौका मिलता है, millisecond तक सटीक नहीं। एक busy page पर timeout देर से fire हो सकता है।

Play from 11:24 तो जो bid timeout से थोड़ी ज़्यादा देर लगाए वो फिर भी अंदर आ सकती है। Prebid के documentation के मुताबिक threshold के लगभग दो सौ milliseconds बाद आपको एक साफ़ गिरावट दिखनी चाहिए।

Play from 11:36 Practical सबक ये है। एक भारी page सिर्फ़ आपके readers को धीमा नहीं करता। वो आपके timeout को भी कम सटीक बना देता है।

Play from 11:45 ये रहा एक auction, एक हज़ार milliseconds के timeout के साथ। Illustrative timings।

Play from 11:50 Partner A तीन सौ बीस milliseconds पर जवाब देता है। B चार सौ पचास पर। C छह सौ दस पर।

Play from 11:57 Partner D ग्यारह सौ पचास पर जवाब देता है। वो बाहर रह जाता है।

Play from 12:01 आज D ने दो डॉलर साठ की bid की थी, जो table पर सबसे ऊँची price थी। तो इस impression पर आपने साठ सेंट CPM खो दिए।

Play from 12:11 लेकिन D को पकड़ने के लिए हर page पर हर ad को कम से कम डेढ़ सौ milliseconds और रुकना पड़ता। ये फ़ायदे का सौदा है या नहीं, ये सवाल data का है, अंदाज़े का नहीं।

Play from 12:23 अब default की बात। तीन seconds।

Play from 12:26 एक आम article पर reader कुछ ही seconds में तय कर लेता है कि आगे पढ़ना है या scroll करना है। Illustrative। अगर पहला ad साढ़े तीन seconds पर आता है तो जिस reader ने दो seconds पर scroll कर लिया, वो उसे कभी नहीं देखता।

Play from 12:40 जो impression कभी render नहीं होता, वो कुछ नहीं कमाता। कोई भी CPM उस ad की भरपाई नहीं कर सकता जो देखा ही नहीं गया।

Play from 12:49 तो एक लंबा timeout सिर्फ़ page को धीमा नहीं करता। वो उन impressions की गिनती भी घटा सकता है जो आप असल में बेचते हैं।

Play from 12:57 ये रहा यही trade-off, एक तस्वीर में। Illustrative shape, कोई benchmark नहीं।

Play from 13:02 Timeout बढ़ने पर bids से revenue पहले तेज़ी से बढ़ता है, फिर सपाट हो जाता है। धीमे bidders बहुत कम जोड़ते हैं।

Play from 13:09 इस बीच इंतज़ार की कीमत बढ़ती ही रहती है: देर से आते ads, कम देखे गए impressions और धीमा page।

Play from 13:16 आपका सबसे अच्छा timeout वहीं कहीं है जहाँ revenue curve सपाट होने लगता है। उसके आगे आप लगभग कुछ नहीं के बदले speed गँवा रहे हैं। चलिए ये trade-off एक असली page पर देखते हैं।

Play from 13:29 ये एक page है जिसमें एक धीमा partner है। Index दो डॉलर साठ की bid करेगा, जो सबसे अच्छी price है, लेकिन उसे जवाब देने में एक point चार seconds लगते हैं। हमारा timeout एक second है।

Play from 13:57 चलिए auction का final record निकालते हैं। ये लगभग एक हज़ार milliseconds के बाद बंद हुआ। और देखिए इसे कौन सी bids मिलीं: OpenX, Sovrn और RediAds। Index यहाँ नहीं है।

Play from 14:12 क्या Index ने जवाब दिया भी? दिया। दो डॉलर साठ, लगभग चौदह सौ milliseconds पर। बहुत देर हो गई। Auction पहले ही ख़त्म हो चुका था।

Play from 14:19 तो Ad Manager के पास क्या गया? दो point शून्य शून्य, यानी RediAds का bucket।

Play from 14:22 अब वही page, पंद्रह सौ milliseconds के timeout के साथ।

Play from 14:24 इस बार auction में लगभग चौदह सौ milliseconds लगे, क्योंकि उसने Index का इंतज़ार किया, और Index पहुँच गया।

Play from 14:25 और अब Ad Manager को दिखता है दो point छह शून्य।

Play from 14:26 तो बेहतर क्या है? जिन impressions पर Index जीतता है उन पर साठ सेंट ज़्यादा। या हर page पर चार सौ milliseconds जल्दी। एक page ये नहीं बता सकता। एक test बता सकता है, और वही अगला chapter है।

Play from 14:40 आगे बढ़ने से पहले timeout की दो गलतियाँ।

Play from 14:43 पहली: दो timeouts जो आपस में मेल नहीं खाते। कोई setConfig में bidderTimeout बदल देता है, लेकिन requestBids अब भी पुराना नंबर भेज रहा है। कुछ नहीं बदलता, और सबको लगता है कि test fail हो गया।

Play from 14:57 दूसरी: किसी और site का timeout copy करना। उनके partners, उनके readers और उनके pages आपके नहीं हैं। आठ सौ उनके लिए सही हो सकता है और आपके लिए महँगा।

Play from 15:09 आधे रास्ते का check। चाहें तो video pause कर लीजिए।

Play from 15:18 आपका timeout एक हज़ार milliseconds है। RediAds दो डॉलर की bid करता है और समय पर जवाब देता है। Partner D दो डॉलर साठ की bid करता है, लेकिन ग्यारह सौ पचास milliseconds पर जवाब देता है। Ad Manager को hb_pb में क्या दिखता है?

Play from 15:28 दो point शून्य शून्य। Prebid timeout पर अपना auction पहले ही चला चुका था, इसलिए D की bid बाहर रह गई, चाहे कितनी भी ऊँची थी। सिर्फ़ RediAds का bucket Ad Manager के पास गया।

15:41Choose your timeout with a test

Play from 15:42 Chapter तीन। चलिए एक timeout test ठीक से design करते हैं, उसे चलाते हैं, और उसके results पढ़ते हैं।

Play from 15:51 एक अच्छे timeout test के चार हिस्से होते हैं।

Play from 15:54 Arms यानी तीन या चार timeouts। जैसे आठ सौ, एक हज़ार और पंद्रह सौ milliseconds, और control के तौर पर आपकी मौजूदा setting।

Play from 16:04 Assignment। हर reader को random तरीके से एक arm मिलता है, और पूरे test में वही रहता है। हर page view पर नया arm नहीं, वरना एक reader के sessions में arms मिल जाते हैं।

Play from 16:15 Duration। कम से कम एक पूरा हफ़्ता, ताकि weekdays और weekends दोनों उसमें आ जाएँ। दो हफ़्ते और बेहतर हैं।

Play from 16:22 और एक समय पर सिर्फ़ एक बदलाव। Test के बीच में कोई bidder मत जोड़िए।

Play from 16:28 Wrapper में ये split बस कुछ lines का है।

Play from 16:31 एक छोटी script किसी reader को पहली बार देखने पर एक arm चुनती है, और उसे एक first-party cookie में store करती है, जहाँ आपके consent rules इसकी इजाज़त देते हों।

Play from 16:42 वो arm के हिसाब से bidderTimeout set करती है, और वही नंबर requestBids को भी देती है।

Play from 16:48 और वो traffic पर label लगाती है। Arm का नाम अपने analytics को भेजिए, और उसे page-level key-value के तौर पर set कीजिए, ताकि revenue को arm के हिसाब से बाँटा जा सके।

Play from 17:00 Random assignment का एक अच्छा side effect भी है। एक बड़ी match night हर arm में बराबर आती है, इसलिए वो result को धोखा नहीं दे सकती।

Play from 17:09 अब सबसे ज़रूरी फ़ैसला। आप मापते क्या हैं?

Play from 17:12 CPM नहीं। लंबा timeout आमतौर पर CPM बढ़ाता है, क्योंकि धीमी और ऊँची bids अंदर आ जाती हैं।

Play from 17:19 हर हज़ार sessions पर revenue मापिए। ये है impressions per session गुणा CPM।

Play from 17:24 ये दोनों असर एक साथ पकड़ता है: ऊँची prices, और कम देखे गए ads, जब readers ad आने से पहले चले जाते हैं या scroll कर जाते हैं।

Play from 17:33 इसके साथ हर bidder का timeout rate और अपने Core Web Vitals भी देखते रहिए।

Play from 17:40 ये रहा दो हफ़्ते का एक पूरा हुआ test। सारे नंबर illustrative हैं।

Play from 17:45 आठ सौ milliseconds पर हर session में तीन point एक impressions, एक डॉलर बयालीस CPM पर। Revenue हर हज़ार sessions पर चार डॉलर चालीस।

Play from 17:55 एक हज़ार पर तीन point एक impressions, एक डॉलर बावन पर। चार डॉलर इकहत्तर।

Play from 18:01 पंद्रह सौ पर दो point नौ impressions, एक डॉलर साठ पर। चार डॉलर चौंसठ।

Play from 18:06 तीन हज़ार, यानी बिना छुआ default। दो point छह impressions, एक डॉलर छियासठ पर। चार डॉलर बत्तीस।

Play from 18:16 तो ये table क्या कहती है?

Play from 18:17 हर step के साथ CPM बढ़ता है। अगर आप सिर्फ़ CPM देखते तो तीन हज़ार चुनते। Revenue के लिए वही सबसे बुरा arm है।

Play from 18:25 Revenue एक हज़ार पर सबसे ऊपर है, और पंद्रह सौ लगभग उसी के बराबर है।

Play from 18:31 जब दो arms इतने क़रीब हों तो छोटा वाला चुनिए। एक हज़ार उतना ही कमाता है, और हर page आधा second तेज़ होता है।

Play from 18:38 फ़ैसला करने से पहले देखिए कि result दोनों हफ़्तों में टिका रहा या नहीं। अगर arms का order हर हफ़्ते पलटता है तो फ़र्क शायद सिर्फ़ noise है।

Play from 18:47 यही test आपको हर partner की तस्वीर भी दिखाता है। फिर से illustrative नंबर।

Play from 18:51 Partner A median पर तीन सौ बीस milliseconds में जवाब देता है। दो प्रतिशत requests पर उसका timeout होता है, और वो इकतीस प्रतिशत auctions जीतता है।

Play from 19:02 B और C धीमे हैं, लेकिन फिर भी अक्सर जीतते हैं।

Play from 19:06 Partner D ग्यारह सौ पचास milliseconds में जवाब देता है। अड़तीस प्रतिशत requests पर उसका timeout होता है, और वो सिर्फ़ डेढ़ प्रतिशत जीतता है।

Play from 19:14 ये नंबर आप Prebid के events से जमा कर सकते हैं, जैसे bidTimeout और bidWon, एक analytics adapter के ज़रिए।

Play from 19:24 तो partner D का क्या करें?

Play from 19:26 पहला, उनसे बात कीजिए। धीमा response अक्सर उनकी तरफ़ की set-up problem होती है, या उनका data centre आपके readers से दूर होता है।

Play from 19:34 दूसरा, उन्हें server-side auction पर ले जाने के बारे में सोचिए। वो Module तीन है।

Play from 19:39 तीसरा, अगर इन दोनों से बात न बने तो उन्हें हटा दीजिए। जो partner कम ही जीतता है लेकिन अक्सर time out होता है, वो लगभग कुछ नहीं के बदले आपकी speed खा रहा है।

Play from 19:50 इनमें से कोई भी नंबर rule नहीं है। कम win rate वाला partner भी बाकी सबकी prices ऊपर उठा सकता है। फ़ैसला revenue data से कीजिए।

Play from 20:00 Test की तीन गलतियाँ जो हम अक्सर देखते हैं।

Play from 20:03 पहली: दो दिन बाद ही test रोक देना, क्योंकि एक arm आगे दिख रहा है। Test में शुरुआती बढ़त अक्सर गायब हो जाती है।

Play from 20:11 दूसरी: हर page view पर arm assign करना। तब एक reader कई timeouts देखता है, और arms आपस में घुल-मिल जाते हैं।

Play from 20:19 तीसरी: एक बार test करना और फिर कभी नहीं। Partners तेज़ या धीमे होते रहते हैं। Test हर quarter दोहराइए, या अपने bidders में किसी भी बड़े बदलाव के बाद।

20:32Core Web Vitals and ad slots

Play from 20:33 Chapter चार। Google page experience को तीन Core Web Vitals से मापता है। Ads तीनों को बिगाड़ सकते हैं, और इसका ज़्यादातर control ad slot पर ही है।

Play from 20:44 पहले targets।

Play from 20:45 Largest Contentful Paint दो point पाँच seconds के अंदर होना चाहिए।

Play from 20:50 Interaction to Next Paint दो सौ milliseconds या उससे कम होना चाहिए।

Play from 20:55 Cumulative Layout Shift शून्य point एक या उससे कम होना चाहिए।

Play from 20:59 हर एक को असली page loads के पचहत्तरवें percentile पर आँका जाता है, mobile और desktop के लिए अलग-अलग। यानी आपके सबसे धीमे एक चौथाई readers आपका score तय करते हैं।

Play from 21:13 Largest Contentful Paint आमतौर पर आपकी headline या hero image होती है।

Play from 21:19 Ad scripts network के लिए और browser के main thread के लिए उस image से मुक़ाबला करती हैं।

Play from 21:25 तो Prebid और GPT को async load कीजिए, जैसे हमारा wrapper करता है। Page की priority में ad scripts को कभी अपनी hero image से आगे मत रखिए।

Play from 21:36 और अपना build lean रखिए। छोटी Prebid file जल्दी download और parse होती है, इसलिए जल्दी रास्ते से हट जाती है।

Play from 21:45 Interaction to Next Paint मापता है कि reader के tap करने पर page कितनी जल्दी react करता है।

Play from 21:52 अगर tap के वक़्त main thread कोई लंबी script चलाने में busy है तो reaction रुका रहता है। Bid processing और भारी creatives, दोनों से ऐसा हो सकता है।

Play from 22:01 Version दस से Prebid अपनी command queue पर काम करते हुए main thread को बीच-बीच में छोड़ता रहता है। इससे page को steps के बीच जवाब देने की जगह मिलती है।

Play from 22:11 आप इसे बंद कर सकते हैं, लेकिन तभी जब आपके अपने code को सच में Prebid का सारा काम एक ही बार में चाहिए।

Play from 22:19 Layout shift को ads सबसे ज़्यादा नुकसान पहुँचाते हैं। देखिए इसका score कैसे बनता है।

Play from 22:24 हर shift का score है उसका impact fraction गुणा distance fraction। Impact मतलब screen का कितना हिस्सा असर में आया। Distance मतलब चीज़ें कितनी दूर खिसकीं, screen की सबसे लंबी side के मुक़ाबले।

Play from 22:37 Shifts को पाँच seconds तक के bursts में group किया जाता है। आपका CLS सबसे बुरा burst होता है।

Play from 22:44 और ads के लिए यहीं पेच है। Tap या key press के ठीक बाद वाले shifts नहीं गिने जाते। लेकिन scrolling से shift माफ़ नहीं होता। Reader के scroll करते समय जो ad load होता है, उसका shift फिर भी गिना जाता है।

Play from 22:59 ये रहा एक phone पर एक unreserved slot। Illustrative geometry।

Play from 23:03 Screen आठ सौ pixels ऊँची है। Article दो सौ pixels से शुरू होता है। उसके ऊपर वाले ad slot की अभी कोई height नहीं है।

Play from 23:11 Ad आता है, दो सौ पचास pixels ऊँचा, और article को नीचे धकेल देता है।

Play from 23:16 खिसकने वाला content पहले और बाद में screen का तीन चौथाई हिस्सा ढके हुए था। यानी impact fraction शून्य point सात पाँच। वो आठ सौ में से दो सौ पचास pixels खिसका, यानी distance fraction लगभग शून्य point तीन एक।

Play from 23:33 दोनों को गुणा कीजिए। शून्य point दो तीन। एक ad ने good threshold को दोगुने से भी ज़्यादा पार कर दिया।

Play from 23:41 इसका fix है ad आने से पहले जगह reserve करना।

Play from 23:44 Slot container को CSS में एक minimum height दीजिए। तीन सौ बाय दो सौ पचास के लिए दो सौ पचास pixels।

Play from 23:51 अब पहले paint से ही article slot के नीचे शुरू होता है। Ad आने पर कुछ नहीं खिसकता। इस slot से score शून्य है।

Play from 24:00 अगर slot कई sizes ले सकता है तो सबसे छोटा size reserve कीजिए, और बड़े ads के लिए थोड़ा shift मान लीजिए। या multi-size slots को page पर और नीचे रखिए, जहाँ shifts screen के कम हिस्से पर असर डालते हैं।

Play from 24:16 उल्टा कदम भी यही problem पैदा करता है।

Play from 24:18 कुछ sites slot को तब collapse कर देती हैं जब कोई ad उसे fill नहीं करता। जगह गायब हो जाती है, और नीचे की हर चीज़ ऊपर उछल जाती है।

Play from 24:28 Reserved जगह हटाने से layout उतना ही खिसक सकता है जितना ad डालने से।

Play from 24:33 तो ऊपर वाले slots के लिए जगह रखिए और एक placeholder या house ad दिखाइए। ये ख़राब CLS score से सस्ता पड़ता है।

Play from 24:43 ये रहा phone पर हमारा article। Ad slot ठीक byline के नीचे है, और उसकी कोई height reserve नहीं है। Ad आने पर text पर नज़र रखिए।

Play from 25:08 ये देखिए। Hero image और पहला paragraph दो सौ पचास pixels नीचे कूद जाते हैं। लाल outlines वो सब दिखाती हैं जो खिसका।

Play from 25:21 उस एक shift का score शून्य point एक सात सात है, यानी पहले ही शून्य point एक की threshold से ऊपर। और reader ने कुछ किया भी नहीं। Page बस उसकी आँखों के सामने खिसक गया।

Play from 25:27 अब वही page, CSS की एक line के साथ। दो सौ पचास pixels की minimum height।

Play from 25:30 Grey box दिखा? जगह बिल्कुल पहले paint से reserve है, Prebid का काम ख़त्म होने से भी पहले।

Play from 25:32 Ad आता है, और score शून्य पर ही रहता है। वही ad, वही auction, वही timing। बस CSS की एक line।

Play from 25:34 Speed के लिए एक और tool है lazy loading।

Play from 25:37 Page पर बहुत नीचे वाले slots को page load होते ही auction की ज़रूरत नहीं है। उनका auction तब चलाइए जब reader उनके पास पहुँचने लगे।

Play from 25:46 इसका मतलब है main content से मुक़ाबला करने वाली कम requests, और उन ads के लिए कम auctions जिन तक कोई scroll ही नहीं करता।

Play from 25:55 लेकिन lazy slots को भी reserved जगह चाहिए। जो lazy ad reader के scroll करते समय content को धकेलता है, वो ठीक वही shift है जो हमने अभी मापा।

Play from 26:07 Core Web Vitals की तीन गलतियाँ जो हम देखते हैं।

Play from 26:10 पहली: बिना ads के speed test करना। Ads block करके या बिना consent banner के किया गया lab test वो नहीं है जो आपके readers को मिलता है। Real-user data इस्तेमाल कीजिए।

Play from 26:21 दूसरी: mobile पर desktop वाली heights reserve करना। हर screen width पर slot असल में जो size दिखाएगा, वही reserve कीजिए।

Play from 26:29 तीसरी: page के ऊपर वाला slot जो no-fill पर collapse हो जाता है। इससे कुछ pixels बचते हैं, लेकिन हर unfilled impression पर आपका CLS बिगड़ता है।

26:41Lean builds, data and identity

Play from 26:42 आख़िरी chapter। आपकी Prebid file में क्या जाता है, और वो modules जो auction शुरू होने से पहले ही चलते हैं।

Play from 26:50 Prebid modular है। आपके readers जो file download करते हैं, उसमें कौन से हिस्से जाएँगे, ये आप चुनते हैं।

Play from 26:57 एक bloated build हर adapter को ये सोचकर साथ रखता है कि शायद काम आए। वो default timeout रखता है, और ऐसे modules भी जिन्हें किसी ने configure नहीं किया। जैसा आपने देखा, हमारे demo के full build में लगभग आठ सौ modules हैं।

Play from 27:12 एक lean build में सिर्फ़ वो adapters होते हैं जो आप इस्तेमाल करते हैं, वो modules जो आपने configure किए हैं, और एक tested timeout।

Play from 27:20 इसे Prebid के download page से बनाइए, या Prebid के अपने build tool से, हर module का नाम देकर। फिर live page पर pbjs dot installedModules check कीजिए, ताकि पक्का हो कि वही ship हुआ है।

Play from 27:35 Prebid ग्यारह ने एक नया इंतज़ार जोड़ा है जिसके बारे में आपको पता होना चाहिए।

Play from 27:40 Default रूप से Prebid अब auction शुरू होने से पहले एक intersection observer से हर ad unit की viewability मापता है।

Play from 27:48 जब तक observer report नहीं करता, auction शुरू नहीं हो सकता। लंबी scripts से भरे page पर ऐसा तभी होता है जब सबसे लंबी script ख़त्म होती है।

Play from 27:58 boundingBox नाम की एक तेज़ setting है जो इंतज़ार नहीं करती। लेकिन Prebid चेतावनी देता है कि वो कम सटीक है। तो असली fix है आपके page पर कम long tasks।

Play from 28:10 Real-time data modules, यानी RTD, bid requests के निकलने से पहले उनमें जानकारी जोड़ते हैं। जैसे page का topic, या किसी data partner से audience segments।

Play from 28:21 इससे bids बढ़ सकती हैं, क्योंकि buyers impression के बारे में ज़्यादा जानते हैं।

Play from 28:26 आप उन्हें एक time budget देते हैं जिसे auction delay कहते हैं। Default शून्य है, तो वो तभी मदद करते हैं जब उनका data पहले से तैयार हो।

Play from 28:34 आप एक provider को waitForIt से mark कर सकते हैं, ताकि auction उस budget तक उसका इंतज़ार करे। तो ये budget सोच-समझकर रखिए। सौ milliseconds के delay का मतलब है कि कोई भी bid request page से सौ milliseconds बाद ही निकलेगी।

Play from 28:50 अब identity की बात, और इसकी शुरुआत consent से होती है।

Play from 28:54 आपका consent platform, यानी CMP, reader की पसंद record करता है। जहाँ TCF consent लागू होता है, जैसे Europe के readers के लिए, वहाँ Prebid का TCF consent module उसे पढ़ता है।

Play from 29:08 वो module एक timeout के साथ CMP का इंतज़ार करता है। Default दस seconds है। अपना timeout सोच-समझकर set कीजिए, ताकि एक धीमा CMP हर ad को न रोक सके।

Play from 29:20 Indian traffic पर कौन से rules लागू होते हैं, ये आपकी legal team का सवाल है। Wrapper का काम है कि बाकी कुछ भी चलने से पहले आपके पास जो भी signal है, उसे पढ़े।

Play from 29:31 Consent के बाद ही identity modules चलते हैं।

Play from 29:34 SharedID जैसे User ID modules buyers को लौटकर आए reader को पहचानने का एक privacy-safe तरीका देते हैं। पहचाने गए readers पर आमतौर पर ऊँची bids आती हैं।

Play from 29:46 ये सिर्फ़ वहीं चलते हैं जहाँ consent इजाज़त देता है। Prebid ग्यारह point चौदह से, अगर CMP मिलता ही नहीं तो ID modules नहीं चलते।

Play from 29:55 और Prebid नौ से, जब ID modules configure होते हैं तो auction default रूप से उनके लिए पाँच सौ milliseconds तक रुकता है। इसे user sync auction delay कहते हैं। अगर आपकी IDs जल्दी आ जाती हैं तो इसे कम कीजिए।

Play from 30:09 इन सबको एक budget की तरह जोड़िए। Illustrative values।

Play from 30:13 Consent के लिए CMP का पाँच सौ milliseconds तक इंतज़ार, default दस seconds नहीं।

Play from 30:20 Identity के लिए सौ milliseconds, default पाँच सौ नहीं।

Play from 30:24 Real-time data के लिए सौ milliseconds, सिर्फ़ उस एक provider के लिए जिसने अपनी value साबित की है।

Play from 30:30 फिर auction, उन एक हज़ार milliseconds के साथ जो आपके test ने चुने। अगर हर step एक के बाद एक अपना पूरा budget इस्तेमाल करे, तो पहली ad request लगभग एक point सात seconds बाद निकलेगी। तेज़ CMP वाले लौटकर आए reader के लिए ये समय बहुत कम है।

Play from 30:49 अगर आपका wrapper किसी पुराने Prebid के लिए लिखा गया था तो तीन चीज़ें check कीजिए।

Play from 30:53 Prebid दस से getBidResponsesForAdUnitCode जैसे functions एक array लौटाते हैं। जो पुराना code dot bids पढ़ता है, वो अभी के लिए चलता रहता है।

Play from 31:04 Prebid ग्यारह से setTargetingForGPTAsync अपने दूसरे argument में custom slot-matching function नहीं लेता। वो अब customGptSlotMatching नाम की एक top-level setting में है।

Play from 31:16 और Prebid ग्यारह उन bids को reject करता है जिनका media type ad unit से match नहीं करता। Banner-only slot पर आई video bid अब बाहर कर दी जाती है।

Play from 31:27 इस chapter की तीन गलतियाँ।

Play from 31:29 पहली: consent से पहले identity। या तो consent module build में है ही नहीं, या ID modules पहले चलने के लिए configure किए गए हैं। इसमें privacy rules टूटने का risk है, या ऐसी IDs का जो कभी attach ही नहीं होतीं।

Play from 31:43 दूसरी: ऐसा RTD module जिसका auction delay किसी ने मापा ही नहीं। हर page इंतज़ार की कीमत चुकाता है, data मदद करे या न करे।

Play from 31:52 तीसरी: build में ऐसे modules जिन्हें किसी ने configure नहीं किया। वो फिर भी download होते हैं, फिर भी parse होते हैं, और फिर भी आपके readers का समय खाते हैं।

32:03Recap and quick checks

Play from 32:04 ख़त्म करने से पहले तीन myths, जो हम लगभग हर हफ़्ते सुनते हैं।

Play from 32:08 Myth एक: लंबा timeout हमेशा ज़्यादा कमाता है। वो CPM बढ़ाता है। लेकिन curve के सपाट हिस्से के बाद वो हर session का revenue घटाता है।

Play from 32:18 Myth दो: ज़्यादा bidders मतलब हमेशा ज़्यादा revenue। हर bidder requests और काम जोड़ता है। एक धीमा partner जो कम ही जीतता है, speed खाता है और जोड़ता बहुत कम है।

Play from 32:30 Myth तीन: ads और Core Web Vitals साथ नहीं चल सकते। Reserved slots, async scripts और एक lean build ज़्यादातर ad set-ups को thresholds के काफ़ी अंदर रखते हैं।

Play from 32:44 चलिए Module दो को recap करते हैं।

Play from 32:46 हर wrapper को चाहिए matching ad unit codes, disabled initial load, एक bidsBackHandler और एक failsafe।

Play from 32:53 Timeout पर Prebid के पास जो है, वो उसी से अपना auction चलाता है। Late bids बाहर रह जाती हैं।

Play from 32:59 अपना timeout split test से चुनिए, हर हज़ार sessions पर revenue के आधार पर।

Play from 33:04 हर slot के लिए जगह reserve कीजिए, और ऊपर वाले slots में उसे collapse मत कीजिए।

Play from 33:09 पहले consent, फिर identity, फिर data, हर एक का अपना time budget। और build lean रखिए।

Play from 33:17 Quick check। सोचना चाहें तो video pause कर लीजिए।

Play from 33:23 एक script error की वजह से bidsBackHandler कभी fire नहीं होता। तब Google Ad Manager को ad request कौन भेजता है?

Play from 33:28 Failsafe timer भेजता है। वो तीन seconds बाद initAdserver को call करता है, चाहे कुछ भी हो। और initAdserver के अंदर का guard पक्का करता है कि Ad Manager सिर्फ़ एक बार call हो।

Play from 33:40 एक और। एक one-column mobile page पर ऊपर की तरफ़ तीन सौ बाय दो सौ पचास का एक ad है, और कोई जगह reserve नहीं है। CLS शून्य point दो है। पहला fix क्या है?

Play from 33:52 Slot container को दो सौ पचास pixels की minimum height दीजिए। तब article slot के नीचे से शुरू होता है, और ad बिना कुछ खिसकाए आ जाता है।

Play from 34:03 ये था Module दो। अब आप एक wrapper पढ़ सकते हैं, data से timeout चुन सकते हैं, और ads को अपने Core Web Vitals बिगाड़ने से रोक सकते हैं।

Play from 34:19 Module तीन में हम Prebid Server के साथ auction का एक हिस्सा browser से बाहर ले जाएँगे। आप एक असली server request और response देखेंगे, और ये भी कि जब auction page छोड़ता है तो identity के साथ क्या होता है।

Play from 34:27 अपने wrapper पर एक और नज़र डलवाना चाहते हैं? blog dot rediads dot com पर free monetisation health check लीजिए। Module तीन में मिलते हैं।