Prebid Server and hybrid auctions

0:00Welcome, outcomes and key terms

Play from 0:00 Module दो में आपने एक Prebid.js wrapper को line by line पढ़ा: ad units, bidders, timeout, और Ad Manager को hand-off।

Play from 0:10 इनमें से हर bidder को reader के अपने browser से call किया गया था।

Play from 0:14 ये module पूछता है कि जब आप इनमें से कुछ को browser से निकालकर एक server पर ले जाते हैं तो क्या होता है।

Play from 0:22 एक reader की कल्पना कीजिए जो train में है। Mid-range phone है और signal आता-जाता है। आपके page को आठ bidders की prices चाहिए, और phone पहले से ही जूझ रहा है।

Play from 0:33 एक हद के बाद browser और बोझ नहीं उठा सकता। ये module auction को ऐसी जगह ले जाने के बारे में है जो ये बोझ उठा सके।

Play from 0:43 RediAds Academy की Header Bidding Masterclass में फिर से स्वागत है। ये है Module तीन: Prebid Server और hybrid auctions।

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

Play from 0:56 ये समझाना कि client-side header bidding एक ceiling से क्यों टकराता है, और वो ceiling किन चीज़ों से बनी है।

Play from 1:03 एक s2sConfig block पढ़कर ठीक-ठीक बताना कि कौन सा bidder कहाँ चलता है, और server को कितना समय मिलता है।

Play from 1:11 एक Prebid Server request और response को field by field पढ़ना।

Play from 1:15 और एक cookie sync को शुरू से आख़िर तक follow करना। ताकि आप जानें कि server-side bidders आपके readers को पहचानना क्यों खो देते हैं, और उसमें से कुछ वापस कैसे मिलता है।

Play from 1:27 पहले आठ terms। हर एक example के साथ दोबारा आएगा।

Play from 1:30 S2S मतलब server-to-server: auction browser में नहीं, servers के बीच चलता है। PBS है Prebid Server, वो open-source server जो इसे चलाता है। s2sConfig, Prebid.js का वो block है जो bidders को Prebid Server के हवाले करता है। Hybrid auction में कुछ bidders browser में होते हैं और कुछ server पर, एक ही auction में।

Play from 1:51 OpenRTB, bid requests और responses का industry standard format है। tmax वो time limit है जो OpenRTB request के अंदर लिखी होती है। Cookie sync वो तरीका है जिससे server सीखता है कि हर bidder किस user ID को जानता है। और match rate उन requests का हिस्सा है जहाँ bidder सच में user को पहचानता है।

Play from 2:13 हम यहाँ हैं। Module एक और दो browser वाले auction के बारे में थे। Module तीन और चार इसे server पर ले जाते हैं: ये कैसे काम करता है, और फिर इसे कैसे चलाएँ।

Play from 2:24 फिर Ad Manager, और फिर debugging और monitoring। Key-values, price buckets और ad server का फ़ैसला, सब वैसे ही रहते हैं। बदलता बस ये है कि bidding कहाँ होती है।

2:37The browser bottleneck

Play from 2:37 Chapter एक। जो auction ठीक चल रहा है उसे browser से बाहर ले जाएँ ही क्यों? क्योंकि browser की सीमाएँ हैं, और हर extra bidder आपको उनके और क़रीब ले जाता है।

Play from 2:49 ये एक page है जो आठ bidders client-side चला रहा है।

Play from 2:52 Browser हर bidder से सीधे पूछता है, और हर bidder अपने अलग domain पर रहता है।

Play from 2:58 तो हर एक पर एक DNS lookup, एक नया connection और एक secure handshake लग सकता है। वो भी bid request का एक भी byte जाने से पहले।

Play from 3:06 और browser एक साथ अनगिनत connections नहीं खोलता। आपकी bid requests network को आपकी images, fonts, analytics और content के साथ बाँटती हैं। काफ़ी bidders जोड़ दीजिए तो requests लाइन में लगने लगती हैं।

Play from 3:20 तो एक और bidder का मतलब सिर्फ़ एक और request नहीं है। उसके चार खर्च हैं।

Play from 3:25 Network: एक और domain, एक और connection, queue में एक और request।

Play from 3:29 Code: आपकी Prebid.js file में एक और adapter, जिसे हर reader को download और parse करना पड़ता है।

Play from 3:37 Processing: request बनाना, response पढ़ना और bid को auction से गुज़ारना। ये सब main thread पर।

Play from 3:43 और syncing: ज़्यादातर bidders user-sync pixels या iframes भी चलाना चाहते हैं। यानी auction के बाद और requests।

Play from 3:49 अकेले में कोई भी बड़ा नहीं है। आठ या बारह bidders पर ये जुड़ जाते हैं।

Play from 3:57 चलिए एक page view के लिए इन्हें गिनते हैं। ये नंबर illustrative हैं।

Play from 4:01 आठ client-side bidders: आठ bid requests, आठ तक नए domains पर।

Play from 4:07 Auction के बाद मान लीजिए उनमें से छह user sync चलाते हैं। छह और requests, जिनमें से कुछ एक दूसरे domain पर redirect होती हैं।

Play from 4:16 तो एक ad auction का मतलब आपके page के ऊपर चौदह या उससे ज़्यादा requests हो सकता है। Fibre पर आपको मुश्किल से पता चलेगा। Train वाले phone पर हर request अपनी बारी का इंतज़ार करती है।

Play from 4:28 अब hybrid version। दो bidders browser में रहते हैं, और छह Prebid Server पर जाते हैं। दो bid requests, साथ में Prebid Server को एक request, और एक cookie sync call।

Play from 4:39 Syncs ग़ायब नहीं होते। Prebid Server अब भी browser से उन bidders को sync करवाता है जिन्हें वो अभी नहीं जानता। लेकिन वो सिर्फ़ वही IDs माँगता है जो उसके पास नहीं हैं, जबकि client-side syncs हर page पर नए सिरे से तय होते हैं। ये आप अगले chapter के demo में देखेंगे।

Play from 5:00 और ये खर्च बराबर नहीं बँटते। ये नंबर भी illustrative हैं।

Play from 5:04 एक तेज़ laptop पर पूरा client-side auction लगभग तीन सौ milliseconds का main-thread time ले सकता है।

Play from 5:11 एक mid-range phone पर वही code तीन या चार गुना ज़्यादा समय ले सकता है। Processor धीमा है, और network कम भरोसेमंद।

Play from 5:20 ये समय आपके reader के scroll करने, tap करने और पढ़ने से टकराता है। इसमें battery भी खर्च होती है। और ज़्यादातर Indian publishers का ज़्यादातर traffic mobile पर ही है।

Play from 5:33 और आप एक चक्कर में फँस जाते हैं।

Play from 5:34 आप ज़्यादा competition के लिए bidders जोड़ते हैं। ज़्यादा competition से prices बढ़नी चाहिए। लेकिन ज़्यादा bidders का मतलब है device पर ज़्यादा latency। और ज़्यादा latency का मतलब है कि ज़्यादा bids timeout miss करती हैं। या timeout बढ़ाएँ तो page धीमा।

Play from 5:49 तो जो bidders आपने जोड़े वो मदद करना बंद कर देते हैं। यही client-side header bidding का catch-22 है। जो चीज़ yield बढ़ाती है वही उस page को धीमा करती है जो कमाई करता है। Prebid Server ये चक्कर तोड़ता है, ज़्यादातर काम device से हटाकर।

Play from 6:05 इस chapter के दायरे में दो गलतियाँ जो हम देखते हैं।

Play from 6:08 पहली: किसी bidder को उसकी वादा की गई prices के लिए जोड़ देना, बिना ये check किए कि page पर उसकी क्या कीमत पड़ती है। पहले और बाद में page speed और हर हज़ार sessions पर revenue मापिए, जैसे आपने Module दो में timeouts के साथ किया था।

Play from 6:24 दूसरी: सिर्फ़ bid requests गिनना। Sync requests भी network time खाती हैं, और किसी dashboard में शायद ही दिखती हैं।

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

Play from 6:39 आप चार और client-side bidders जोड़ते हैं। Revenue मुश्किल से हिलता है, और pages धीमे लगते हैं। इसकी सबसे संभावित वजह क्या है?

Play from 6:45 Catch-22। Extra bidders device पर latency बढ़ाते हैं, तो ज़्यादा bids timeout miss करती हैं। और जो समय पर आती हैं वो इतना नहीं जोड़तीं कि धीमे page की भरपाई हो सके।

6:58Hybrid auctions and s2sConfig

Play from 6:58 Chapter दो। जब आप bidders को Prebid Server पर ले जाते हैं तो असल में क्या बदलता है? पहले architecture, फिर वो एक config block जो इसे चालू करता है, line by line।

Play from 7:11 Client-side में browser हर bidder से ख़ुद बात करता है। छह bidders, छह domains, एक phone से छह round trips।

Play from 7:19 Server-side में browser Prebid Server को एक request भेजता है।

Play from 7:23 फिर Prebid Server एक data centre से bidders को call करता है। Parallel में, तेज़ और stable connections पर।

Play from 7:30 Prebid Server में aliases गिनकर सैकड़ों bidder adapters आते हैं। तो जो partners आप client-side इस्तेमाल करते हैं उनमें से ज़्यादातर का server-side version भी है। Move plan करने से पहले हर एक को check कीजिए।

Play from 7:45 Prebid.js में एक block इसे चालू करता है: s2sConfig। आपके Prebid.js build में Prebid Server bid adapter module भी होना चाहिए।

Play from 8:03 ये है एक पूरा, चलने वाला shape। हम इसे थोड़ी-थोड़ी lines करके देखेंगे।

Play from 8:12 ``js pbjs.setConfig({ bidderTimeout: 1000, s2sConfig: { accountId: '1001', enabled: true, bidders: ['sovrn', 'ix'], endpoint: 'https://pbs.example.com/openrtb2/auction', syncEndpoint: 'https://pbs.example.com/cookie_sync', timeout: 700 } }); ``

Play from 8:22 accountId, Prebid Server host पर आपका account है। ये host आपको देता है। Prebid.js इसे request में publisher ID के रूप में भी लिखता है, जब तक आपने ख़ुद कोई set न किया हो।

Play from 8:34 enabled, true। इसका default false है, तो इसके बिना block कुछ भी नहीं करता।

Play from 8:39 bidders बताता है कि कौन से bidders server पर चलते हैं। जो इस list में नहीं है वो browser में रहता है। यहाँ sovrn और ix server पर जाते हैं। आपकी ad units के बाकी bidders client-side रहते हैं।

Play from 8:51 endpoint, server का auction URL है, जो slash openrtb2 slash auction पर ख़त्म होता है।

Play from 8:59 syncEndpoint उसका cookie sync URL है, जो slash cookie underscore sync पर ख़त्म होता है। Chapter चार पूरा इसी के बारे में है।

Play from 9:08 दोनों एक object भी हो सकते हैं, दो URLs के साथ। p1Consent उन readers के लिए जिन्होंने अपने device पर जानकारी store करने की consent दी। और noP1Consent उनके लिए जिन्होंने नहीं दी। European traffic के लिए ये मायने रखता है। अगर आप object form इस्तेमाल करते हैं तो दोनों define कीजिए। अगर एक missing है तो readers के उस group की requests भेजी ही नहीं जातीं।

Play from 9:33 और timeout बताता है कि server-side auction कितनी देर चल सकता है। चलिए इसका हिसाब लगाते हैं। ये timings illustrative हैं।

Play from 9:41 आपका Prebid.js bidder timeout बाहरी deadline है: एक हज़ार milliseconds।

Play from 9:46 Server-side auction को इसके अंदर ख़त्म होना है। यहाँ उसे सात सौ मिलते हैं। Prebid.js ये नंबर Prebid Server को tmax के रूप में भेजता है।

Play from 9:56 बीच का फ़ासला, तीन सौ milliseconds, आपका network budget है। यानी request के Prebid Server तक पहुँचने और bids के वापस आने का समय। Prebid docs दो से तीन सौ छोड़ने की सलाह देते हैं।

Play from 10:08 अगर आप timeout छोड़ देते हैं तो Prebid.js bidder timeout का पचहत्तर प्रतिशत इस्तेमाल करता है। यहाँ, सात सौ पचास। इस default की एक ऊपरी सीमा भी है, जिसे maxTimeout कहते हैं। Prebid.js ग्यारह के code में ये पंद्रह सौ milliseconds है। कुछ documentation में अब भी सात सौ पचास लिखा है। एक second से कम के timeouts में असर पचहत्तर प्रतिशत वाले नियम का ही होता है।

Play from 10:35 असल में ज़्यादातर web set-ups hybrid होते हैं।

Play from 10:38 आपकी ad unit में अब भी हर bidder अपने params के साथ listed है।

Play from 10:43 s2sConfig में जिन bidders के नाम हैं वो एक साथ, एक request में Prebid Server पर जाते हैं। Prebid.js उनके params आगे भेज देता है, इसलिए build में उनके client-side adapters की ज़रूरत नहीं।

Play from 10:56 बाकी को पहले की तरह browser से call किया जाता है।

Play from 10:59 Bids के दोनों sets एक ही Prebid.js auction में पहुँचते हैं। सबसे ऊँची price जीतती है, चाहे वो कहीं से भी आई हो।

Play from 11:06 आप कई Prebid Server configs define कर सकते हैं, बशर्ते हर bidder सिर्फ़ एक में हो।

Play from 11:13 s2sConfig के साथ चार गलतियाँ जो हम देखते हैं।

Play from 11:16 पहली: enabled, true नहीं है। Block ignore हो जाता है, और हर bidder चुपचाप client-side ही रहता है।

Play from 11:23 दूसरी: server timeout, client timeout के बराबर या उससे बड़ा। कोई network budget नहीं बचता। तो server bids तब आती हैं जब Prebid.js इंतज़ार बंद कर चुका होता है।

Play from 11:35 तीसरी: Prebid Server bid adapter module के बिना build। Config मौजूद है, लेकिन उस पर अमल करने वाला कोई नहीं।

Play from 11:42 चौथी: किसी bidder का client-side adapter हटा देना, और फिर fallback के तौर पर उसे browser में वापस चाहना। Build और config को साथ में plan कीजिए।

Play from 11:53 ये रहा The Monsoon Times, आठ bidders के साथ, सब browser में। Network panel देखिए। हर bidder को अपनी request मिलती है, अपने domain पर।

Play from 12:02 कुछ seconds बाद ये आए user syncs। Auction के बाद और requests। Console summary दिखाती है कि एक ad slot के लिए reader के phone ने क्या भेजा।

Play from 12:17 वही page, वही आठ bidders। इस बार छह s2sConfig में listed हैं और हमारे local Prebid Server पर जाते हैं। एक auction call जिसमें छहों हैं, और एक cookie sync call। कुछ sync pixels अब भी चलते हैं, क्योंकि ये browser Prebid Server के लिए नया है। अगले page पर वो दोबारा नहीं पूछेगा। फिर भी total काफ़ी कम है।

Play from 12:32 और ये अब भी एक ही auction है। Prebid.js हर bidder का रास्ता record करता है। Browser वाले दो के लिए client, server वाले छह के लिए s2s। Device से कम requests, और सबसे ऊँची price अब भी वही Prebid.js चुनता है।

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

Play from 12:55 आपका Prebid.js bidder timeout एक हज़ार milliseconds है, और s2sConfig में कोई timeout नहीं है। Server-side auction को कितना समय मिलता है, और कितना network budget बचता है?

Play from 13:02 सात सौ पचास milliseconds, यानी एक हज़ार का पचहत्तर प्रतिशत। इससे Prebid Server तक जाने और वापस आने के लिए दो सौ पचास बचते हैं।

13:15Inside one /openrtb2/auction call

Play from 13:15 Chapter तीन। Prebid Server कोई black box नहीं है। हर server-side auction एक HTTP request अंदर और एक response बाहर है। और दोनों सादा OpenRTB JSON हैं जिसे आप पढ़ सकते हैं। चलिए पढ़ते हैं।

Play from 13:32 ये है उस request का shape जो Prebid.js slash openrtb2 slash auction पर post करता है। चार हिस्से।

Play from 13:41 imp: हर ad unit की एक entry, sizes और हर server bidder के params के साथ।

Play from 13:47 site और device: page, publisher और reader का device।

Play from 13:51 regs और user: privacy signals, और कोई भी user IDs।

Play from 13:55 और top-level controls: एक id, tmax, और ext dot prebid नाम का एक block। इसमें सिर्फ़ Prebid Server के लिए instructions हैं।

Play from 14:06 ये है हमारे article के एक slot का imp। Values illustrative हैं।

Play from 14:19 ``json "imp": [{ "id": "div-mpu", "banner": { "format": [{ "w": 300, "h": 250 }] }, "ext": { "prebid": { "adunitcode": "div-mpu", "bidder": { "sovrn": { "tagid": "403370" }, "ix": { "siteId": "300", "size": [300, 250] } } } } }] ``

Play from 14:32 id, ad unit code है। इसी से bids सही slot तक वापस पहुँचती हैं।

Play from 14:37 banner dot format में mediaTypes वाले sizes आते हैं।

Play from 14:40 और ext dot prebid dot bidder में हर server-side bidder के params होते हैं। बिल्कुल वही params जो आपकी ad unit में हैं। Prebid Server हर bidder को सिर्फ़ उसका अपना block देता है।

Play from 14:54 site में page URL, domain और publisher होते हैं, आपके account ID के साथ।

Play from 14:59 device में वो होता है जो browser बता सकता है: user agent, screen size और language।

Play from 15:06 regs और user में आपके consent signals होते हैं, जैसे GDPR, US privacy और GPP strings। Prebid Server किसी को भी call करने से पहले इन्हें पढ़ता है।

Play from 15:17 और user ही वो जगह है जहाँ user IDs भी चलती हैं। ये chapter पाँच में काम आएगा।

Play from 15:24 अब top-level controls।

Play from 15:32 ``json "tmax": 700, "ext": { "prebid": { "targeting": { "includewinners": true, "includebidderkeys": false }, "channel": { "name": "pbjs", "version": "11.49.0" }, "debug": true } } ``

Play from 15:40 tmax: सात सौ, सीधे आपके s2sConfig timeout से।

Play from 15:44 targeting, Prebid Server से कहता है कि winning bid पर hb key-values लगाए, लेकिन हर bidder का पूरा set नहीं। आख़िरी फ़ैसला अब भी Prebid.js करता है, इसलिए उसे उनकी ज़रूरत नहीं।

Play from 15:57 channel बताता है कि request कहाँ से आई। Prebid.js से, और कौन से version से।

Play from 16:01 और debug, true, तब आता है जब आप page को pbjs underscore debug equals true के साथ load करते हैं। ये Prebid Server से कहता है कि response में extra detail डाले।

Play from 16:14 Request और response के बीच ये होता है।

Play from 16:15 वो request और आपकी account settings पढ़ता है, और कोई भी stored configuration उसमें जोड़ देता है। ये Module चार का विषय है।

Play from 16:23 वो consent signals से privacy rules लागू करता है। इसका मतलब IDs हटाना या bidders को skip करना हो सकता है।

Play from 16:30 वो हर bidder का user ID अपनी cookie में देखता है, अपने domain पर। ये बात chapter चार के लिए याद रखिए।

Play from 16:38 वो हर bidder के server-side adapter तक parallel में जाता है। हर adapter request को उस bidder के अपने format में बदलता है।

Play from 16:45 वो tmax तक इंतज़ार करता है, थोड़ा safety margin घटाकर। फिर bids इकट्ठा करता है, currency convert करता है और targeting set करता है।

Play from 16:55 अब response। Values illustrative हैं।

Play from 17:09 ``json "seatbid": [{ "seat": "sovrn", "bid": [{ "impid": "div-mpu", "price": 1.90, "adm": "…creative…", "crid": "cr-881", "w": 300, "h": 250, "adomain": ["example-advertiser.com"], "ext": { "prebid": { "type": "banner", "targeting": { "hb_pb": "1.90", "hb_bidder": "sovrn", "hb_size": "300x250" } } } }] }] ``

Play from 17:24 हर seat एक bidder है। जिन bidders ने bid नहीं की वो बस दिखते ही नहीं।

Play from 17:28 impid, bid को slot से वापस जोड़ता है। price, CPM है।

Play from 17:33 adm, creative markup है। और adomain advertiser का domain है, जो आप blocked advertisers check करते समय इस्तेमाल करेंगे।

Play from 17:42 Bid के ext के अंदर Prebid Server ने पहले ही key-values set कर दी हैं: hb_pb, hb_bidder और hb_size। ये सिर्फ़ हर slot की winning bid को मिलती हैं, क्योंकि request ने सिर्फ़ winners माँगे थे।

Play from 17:55 Prebid.js इन्हें bid में पढ़ लेता है। फिर वो client और server bids पर अपना auction चलाता है, और Ad Manager के लिए final targeting set करता है। बिल्कुल Module दो की तरह।

Play from 18:07 जिन formats को ज़रूरत होती है उनके लिए response में एक cache ID भी आ सकता है। वो Prebid Cache है, Module चार का पहला chapter।

Play from 18:16 आख़िरी block वो है जिसे ops teams को सबसे ज़्यादा पढ़ना चाहिए।

Play from 18:24 ``json "ext": { "responsetimemillis": { "sovrn": 212, "ix": 655 }, "errors": { "ix": [{ "code": 1, "message": "timeout" }] } } ``

Play from 18:32 responsetimemillis हर bidder का response time देता है, जो server पर मापा गया है। ix ने छह सौ पचपन milliseconds लिए। सात सौ के tmax के सामने ये बहुत क़रीब है।

Play from 18:44 errors हर bidder की problems list करता है। Code एक का मतलब timeout। Code दो का मतलब bad input, अक्सर गलत या missing param।

Play from 18:53 तो जब कोई server bidder चुप हो जाए तो आपको अंदाज़ा लगाने की ज़रूरत नहीं। Response बताता है कि उसका time out हुआ, वो fail हुआ, या उसने बस bid नहीं की।

Play from 19:03 हर server bid एक आम Prebid.js bid बन जाती है, बस एक extra marker के साथ। उसका source client की जगह s2s होता है।

Play from 19:12 वो उन्हीं price buckets, उन्हीं currency rules और उसी highest-price-wins logic से गुज़रती है।

Play from 19:18 और अगर Prebid Server का जवाब bidder timeout के बाद आता है तो उसकी bids late हैं। बिल्कुल एक धीमे client-side bidder की तरह।

Play from 19:28 तीन गलतियाँ जो हम देखते हैं जब teams server traffic पढ़ती हैं।

Play from 19:32 पहली: किसी server bidder को सिर्फ़ Ad Manager reports से आँकना। पहले response के errors और response times check कीजिए। Report में param error भी "no demand" जैसा दिखता है।

Play from 19:44 दूसरी: production में test चालू छोड़ देना। Test equals one bidders को बताता है कि request एक test है, और test requests का bill नहीं बनना चाहिए।

Play from 19:53 तीसरी: server bidders को browser के network panel में ढूँढना। वहाँ Prebid Server को सिर्फ़ एक request जाती है। वही पढ़िए।

Play from 20:03 ये है article, hybrid mode में। दो bidders browser में, दो हमारे local Prebid Server पर। चलिए वो एक request खोलते हैं जो server पर गई।

Play from 20:11 imp की id, ad unit code है, div dash mpu। ext dot prebid dot bidder के नीचे सिर्फ़ दो server bidders हैं, sovrn और ix, अपने params के साथ। tmax सात सौ है, हमारा s2sConfig timeout। और channel बताता है कि ये Prebid.js ग्यारह point चार नौ से आई है।

Play from 20:32 अब response। एक seat, sovrn, एक डॉलर नब्बे की bid के साथ। Prebid Server ने उस पर पहले ही hb_pb, hb_bidder और hb_size लगा दिए हैं, क्योंकि server side पर वही winner है। ये रहे हर bidder के response times। और ये रही वजह कि ix की कोई bid क्यों नहीं है। Error code एक, यानी timeout। Server पर उसका समय ख़त्म हो गया।

Play from 20:52 Console में वापस, slot के लिए तीन bids। दो पर client लिखा है, एक पर s2s। और overall winner है rediads, दो डॉलर पर, browser से। Prebid Server की सबसे अच्छी bid ने उसी auction में मुक़ाबला किया, और हार गई।

Play from 21:08 आधा रास्ता पूरा। चाहें तो video pause कर लीजिए।

Play from 21:14 एक server-side bidder कभी नहीं जीतता, और Ad Manager reports में उसके impressions लगभग न के बराबर हैं। आप सबसे पहले कहाँ देखेंगे?

Play from 21:20 कुछ page views का Prebid Server response, यानी ext dot errors और ext dot responsetimemillis। अगर code एक है तो server पर उसका time out हो रहा है। अगर code दो है तो उसके params गलत हैं। अगर दोनों नहीं, तो वो bid कर रहा है, बस बाकियों से कम।

21:38Identity and cookie sync

Play from 21:39 Chapter चार, और server-side जाने का सबसे बड़ा trade-off: identity।

Play from 21:45 Problem ये है।

Play from 21:46 Client-side में bid request browser से सीधे bidder के domain पर जाती है। जहाँ browser इजाज़त देता है वहाँ वो उस bidder की अपनी cookie साथ लगा देता है। तो bidder जानता है कि वो किस पर bid कर रहा है।

Play from 22:00 Server-side में request उसकी जगह Prebid Server के domain पर जाती है। Browser सिर्फ़ वही cookies भेजता है जो उस domain की हैं।

Play from 22:07 तो जब Prebid Server bidder को call करता है तो bidder की cookie वहाँ नहीं होती। हर user बिल्कुल नया लगता है। और अनजान users पर आमतौर पर कम bids आती हैं।

Play from 22:18 कितनी कम? ये नंबर illustrative हैं।

Play from 22:20 मान लीजिए एक bidder पहचाने हुए readers पर दो डॉलर CPM देता है, और अनजान readers पर एक डॉलर बीस।

Play from 22:28 Client-side में, ऐसे browser में जो third-party cookies allow करता है, वो सत्तर प्रतिशत readers को पहचानता है। उसकी average bid लगभग एक डॉलर छिहत्तर है।

Play from 22:38 उसे बिना किसी sync के server-side ले जाइए, तो वो लगभग किसी को नहीं पहचानता। उसकी average bid एक डॉलर बीस की तरफ़ गिर जाती है।

Play from 22:48 इसीलिए server-side bidders को user तक वापस पहुँचने का रास्ता चाहिए। Classic तरीका है cookie syncing।

Play from 22:56 Cookie syncing में पाँच steps होते हैं, तीन parties के बीच: browser, Prebid Server, और हर bidder।

Play from 23:03 Step एक। Page के पहले auction पर Prebid.js slash cookie underscore sync पर post करता है। Body में server-side bidders, आपका account और consent strings होते हैं।

Play from 23:16 ``json { "bidders": ["sovrn", "ix"], "account": "1001", "gdpr": 0 } ``

Play from 23:22 वो इसे पहली auction request के साथ भेजता है, उससे पहले नहीं। ये याद रखिए। Timing के लिए ये मायने रखता है।

Play from 23:30 Step दो। Prebid Server अपनी ख़ुद की cookie पढ़ता है, जिसका नाम uids है। ये देखने के लिए कि किन bidders की ID उसके पास पहले से है। फिर वो हर उस bidder के लिए sync URL भेजता है जिसे अब भी ID चाहिए।

Play from 23:45 ``json { "status": "ok", "bidder_status": [{ "bidder": "sovrn", "no_cookie": true, "usersync": { "url": "https://sync.bidder.example/u?redir=…", "type": "redirect" } }] } ``

Play from 24:00 type बताता है कि इसे कैसे call करना है। Redirect मतलब इसे image pixel की तरह load करो। Iframe मतलब इसे एक hidden iframe में load करो।

Play from 24:09 Step तीन। Prebid.js उन URLs को एक के बाद एक load करता है, उसी order में जिसमें Prebid Server ने भेजे।

Play from 24:16 हर एक, bidder के अपने domain पर request है। तो browser bidder की अपनी cookie साथ लगाता है, जहाँ उसे इजाज़त है।

Play from 24:22 Default रूप से हर sync को load होने के लिए एक second तक मिलता है। ये s2sConfig की syncTimeout setting है।

Play from 24:31 Step चार। Bidder अपनी cookie पढ़ता है, या अगर नहीं है तो नई ID बनाता है। फिर browser को Prebid Server के slash setuid endpoint पर वापस redirect करता है।

Play from 24:42 Redirect दो चीज़ें लेकर आता है। ये कौन सा bidder है, और इस reader के लिए उस bidder की ID। Consent strings भी साथ आती हैं।

Play from 24:51 Step पाँच। Prebid Server privacy rules फिर से check करता है। अगर इजाज़त है तो वो bidder की ID अपनी uids cookie में save करता है, अपने domain पर।

Play from 25:02 अगर rules इजाज़त नहीं देते तो कुछ save नहीं होता। setuid call जवाब तो देती है, लेकिन cookie नहीं लिखी जाती।

Play from 25:08 तो sync के एक round के बाद उस एक cookie में एक छोटी सी list होती है। ये bidder इस reader को इस ID से जानता है।

Play from 25:16 अगले auction पर ये मेहनत काम आती है।

Play from 25:19 Browser auction request के साथ uids cookie भेजता है, क्योंकि वो cookie Prebid Server के domain की है।

Play from 25:25 Prebid Server उसमें से हर bidder की ID पढ़ता है, और उसे उस bidder की request में user dot buyeruid के रूप में डालता है। अब bidder reader को फिर से पहचान लेता है।

Play from 25:36 लेकिन यहाँ एक पेच है। uids cookie Prebid Server के domain पर रहती है। आपके page पर वो एक third-party cookie है।

Play from 25:45 चलिए एक बिल्कुल नए reader के लिए पूरी timing जोड़कर देखते हैं।

Play from 25:49 Page एक। Cookie sync call और पहला auction साथ में जाते हैं। Auction syncs का इंतज़ार नहीं कर सकता, तो server bidders को एक अनजान reader दिखता है।

Play from 25:59 इस बीच sync pixels चलते हैं और uids cookie भरती जाती है।

Play from 26:04 Page दो। Auction request में uids cookie जाती है, और matched bidders को buyeruid मिलता है।

Play from 26:10 तो syncing दूसरे page view से मदद करना शुरू करती है। जिन sites पर बहुत सारी one-page visits होती हैं उन्हें ये सबसे ज़्यादा महसूस होता है।

Play from 26:21 अब, कौन से browsers इसमें से कुछ भी होने देते हैं?

Play from 26:24 Safari और Firefox default रूप से third-party cookies को block या partition करते हैं। तो वहाँ uids cookie काम नहीं कर सकती।

Play from 26:32 Prebid.js ग्यारह point बीस से, Prebid.js Safari, Firefox और iOS वाले Chrome में cookie sync call skip कर देता है। और तब भी, जब cookies disabled या denied हों।

Play from 26:45 Desktop और Android वाला Chrome अब भी default रूप से third-party cookies allow करता है। अप्रैल दो हज़ार पच्चीस में Google ने इसे बदलने का अपना plan छोड़ दिया।

Play from 26:55 ईमानदारी से कहें तो Safari और Firefox में client-side bidders भी अपनी third-party cookies खो देते हैं। Client और server matching के बीच का फ़र्क ज़्यादातर Chrome की कहानी है।

Play from 27:08 तीन settings syncing का तरीका बदलती हैं।

Play from 27:10 userSyncLimit तय करता है कि Prebid Server हर call में ज़्यादा से ज़्यादा कितने sync URLs लौटाए। बारह server bidders और चार की limit के साथ, एक नए reader को सबको sync करने में कई page views लगते हैं।

Play from 27:25 coopSync default रूप से on है। ये Prebid Server को उन bidders को भी sync करने देता है जो आपके page पर नहीं हैं। एक ही server पर चलने वाले publishers एक-दूसरे के match rates में मदद करते हैं।

Play from 27:38 और आपकी Prebid.js user sync filter settings, जैसे iframes allowed हैं या नहीं, आगे भेजी जाती हैं। तो Prebid Server सिर्फ़ वही sync types लौटाता है जिनकी आप इजाज़त देते हैं।

Play from 27:51 तीन cookie sync गलतियाँ जो हम देखते हैं।

Play from 27:54 पहली: Safari में test करके report करना कि cookie sync टूटा हुआ है। Prebid.js ग्यारह point बीस और उसके बाद वहाँ ये call जानबूझकर skip होती है। Desktop Chrome में test कीजिए।

Play from 28:07 दूसरी: नए move किए गए bidder को पहले ही दिन आँकना। Match rates readers के लौटने के साथ बढ़ते हैं। फ़ैसला करने से पहले उसे एक-दो हफ़्ते दीजिए।

Play from 28:16 तीसरी: ऐसा syncEndpoint जो आपके auction endpoint से अलग Prebid Server host पर point करता है। IDs एक host की cookie में पहुँचती हैं, और auctions दूसरे पर चलते हैं।

Play from 28:28 ये एक बिल्कुल नया reader है। एक fresh browser, जिसमें कोई cookie नहीं। ये है cookie sync endpoint पर पहली call। Prebid.js दोनों server bidders list करता है। और Prebid Server हर एक के लिए sync URL के साथ जवाब देता है, क्योंकि वो अभी दोनों में से किसी को नहीं जानता।

Play from 28:46 अब browser उन URLs को load करता है। हर एक bidder के अपने sync domain पर जाता है। और हर bidder सीधे Prebid Server के setuid पर redirect करता है, URL में इस reader के लिए अपनी ID के साथ। वहीं Prebid Server उन्हें अपनी uids cookie में लिखता है।

Play from 29:11 लेकिन इस page का auction देखिए। Debug on है, तो Prebid Server हमें वो exact request दिखाता है जो उसने sovrn को भेजी। उसमें कोई buyeruid नहीं है। Sync auction के साथ-साथ चला, तो ये page view अब भी anonymous था।

Play from 29:23 चलिए reload करते हैं, जैसे reader ने दूसरा article खोला हो। Cookie sync का जवाब अब खाली है। Sync करने को कुछ नहीं बचा। और sovrn वाली request में ये रहा: user dot buyeruid, bidder की अपनी ID। पहले page ने sync की कीमत चुकाई। दूसरे page को उसका फ़ायदा मिलता है।

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

Play from 29:43 आप एक मज़बूत bidder को client-side से server-side ले जाते हैं। Desktop Chrome में पहले हफ़्ते उसकी bids गिरती हैं, फिर धीरे-धीरे वापस आती हैं। क्या हो रहा है?

Play from 29:50 Match rate। Server पर bidder अपनी cookie नहीं पढ़ सकता, तो उसे cookie syncs चाहिए। और वो सिर्फ़ reader के अगले page view से काम आते हैं। जैसे-जैसे लौटने वाले readers sync होते हैं, bidder उनमें से ज़्यादा को पहचानता है, और उसकी bids वापस आ जाती हैं।

30:06IDs in the request, and where each bidder runs

Play from 30:07 आख़िरी chapter। Cookie syncing सिर्फ़ वहीं काम करती है जहाँ third-party cookies करती हैं। तो लंबे समय का जवाब क्या है? और आप कैसे तय करें कि कौन से bidders move करने हैं?

Play from 30:19 लंबे समय का जवाब third-party cookies पर बिल्कुल निर्भर नहीं करता।

Play from 30:24 Prebid.js के user ID modules, जैसे SharedID, आपके अपने domain पर first-party storage में identifiers बनाते या पढ़ते हैं। वहाँ, जहाँ consent इजाज़त देती है।

Play from 30:36 Prebid.js इन्हें server request में extended IDs के रूप में जोड़ता है, जिन्हें eids कहते हैं। बाकी user data के साथ।

Play from 30:45 Prebid Server इन्हें उन bidders तक पहुँचाता है जिन्हें ये पाने की इजाज़त है।

Play from 30:50 न sync, न third-party cookie। ID request के अंदर ही सफ़र करती है। असल में आप दोनों चलाएँगे। जहाँ cookie syncing काम करती है वहाँ वो, और ID modules हर जगह। Module दो वाले order में set up, पहले consent।

Play from 31:05 ये आमतौर पर ऐसे होता है। ये नंबर illustrative हैं।

Play from 31:09 Desktop Chrome में syncing और IDs के साथ, एक server bidder ज़्यादातर लौटने वाले readers को पहचान सकता है। Safari और Firefox में वो उन first-party IDs पर निर्भर करता है जो वो accept करता है, तो दोनों रास्तों पर match rates कम होते हैं। और एक बिल्कुल नए reader का पहला page कहीं भी ज़्यादातर unmatched होता है।

Play from 31:29 तो एक ही bidder एक हिस्से पर मज़बूत और दूसरे पर कमज़ोर दिख सकता है। Move को आँकने से पहले results को browser के हिसाब से बाँटिए।

Play from 31:39 तो कौन से bidders कहाँ जाएँ? ये रहा ईमानदार trade-off।

Play from 31:43 Server-side, page weight और device के काम में जीतता है। कई की जगह एक request, और page धीमा किए बिना ज़्यादा bidders की गुंजाइश।

Play from 31:52 Client-side, Chrome में matching पर जीतता है, क्योंकि हर bidder अपनी cookie पढ़ता है। ये transparency में भी जीतता है। हर request browser में दिखती है।

Play from 32:00 एक आम pattern कुछ top partners को client-side रखता है, जहाँ उनके match rates सबसे ज़्यादा मायने रखते हैं। और long tail को server पर ले जाता है। फिर आप test करते हैं, एक बार में एक bidder।

Play from 32:13 एक test ऐसा दिखता है। सारे नंबर illustrative हैं।

Play from 32:16 एक mid-sized bidder चुनिए। Page views को पचास-पचास बाँटिए। आधे में वो client-side रहता है, आधे में s2sConfig से जाता है। कम से कम दो हफ़्ते चलाइए, ताकि लौटने वाले readers को sync होने का समय मिले।

Play from 32:31 हर हज़ार sessions पर revenue मापिए, bidder का अपना CPM नहीं। मान लीजिए control चार डॉलर बीस कमाता है, और test चार डॉलर उनतीस।

Play from 32:40 फिर अंदर देखिए। Move किए गए bidder की अपनी average bid Chrome में लगभग दस प्रतिशत गिरी। लेकिन page हल्का हुआ, तो बाकी bidders में से ज़्यादा ने timeout के अंदर जवाब दिया।

Play from 32:51 इसे browser के हिसाब से भी बाँटिए। Chrome लगभग flat है, और Safari थोड़ा ऊपर, क्योंकि वहाँ खोने को matching थी ही कम।

Play from 33:00 तो क्या ये जीत है?

Play from 33:01 दो प्रतिशत का lift छोटा है। इसे जीत कहने से पहले check कीजिए कि ये हर दिन टिकता है, सिर्फ़ total में नहीं।

Play from 33:08 Page speed भी check कीजिए। अगर आपके Core Web Vitals सुधरे तो वो इस test के revenue से अलग value है।

Play from 33:14 अगर ये टिकता है तो move रखिए और अगला bidder test कीजिए। अगर हर हज़ार sessions पर revenue गिरता है तो bidder को वापस ले आइए। दो हफ़्तों के सिवा कुछ नहीं खोया।

Play from 33:25 Hybrid पर जाते समय तीन गलतियाँ जो हम देखते हैं।

Play from 33:28 पहली: हर bidder को एक ही release में server पर ले जाना। जब revenue हिलता है तो आप नहीं बता सकते कि किस bidder की वजह से।

Play from 33:36 दूसरी: move को bidder के अपने CPM से आँकना। तेज़ page के साथ कम CPM का मतलब कुल मिलाकर फिर भी ज़्यादा revenue हो सकता है।

Play from 33:46 तीसरी: user ID modules को skip करना, क्योंकि Chrome में cookie syncing काम करती दिखती है। आपके Safari और Firefox readers traffic का असली हिस्सा हैं, और syncing उनके लिए कुछ नहीं करती।

Play from 34:00 Wrap up से पहले, Prebid Server के बारे में तीन myths।

Play from 34:04 Myth एक: server-side हमेशा तेज़ होता है। Page कम काम करता है, लेकिन round trip और server timeout फिर भी गिने जाते हैं। एक दूर का, overloaded server एक lean client-side set-up से हार सकता है।

Play from 34:18 Myth दो: bidders को server-side ले जाना मुफ़्त का पैसा है। कम match rates का मतलब कम bids हो सकता है। एक बार में एक move कीजिए, और मापिए।

Play from 34:28 Myth तीन: Prebid Server, Prebid.js की जगह ले लेता है। Web पर ऐसा नहीं है। Prebid.js अब भी ad units, final auction और ad server call चलाता है। Prebid Server बस वो जगह है जहाँ कुछ bidders रहते हैं।

Play from 34:43 चलिए Module तीन को recap करते हैं।

Play from 34:46 Browser की एक ceiling है। हर bidder का खर्च है network, code, processing और syncs में, और सबसे ज़्यादा phones चुकाते हैं।

Play from 34:55 s2sConfig आपके चुने हुए bidders को Prebid Server के हवाले करता है, client timeout के अंदर एक server timeout के साथ।

Play from 35:03 एक OpenRTB request slash openrtb2 slash auction पर जाती है, और एक response वापस आता है। किसी bidder को आँकने से पहले उसके errors और response times पढ़िए।

Play from 35:15 Server-side bidders अपनी cookies खो देते हैं। जहाँ browsers इजाज़त देते हैं, वहाँ cookie syncing अगले page view से कुछ वापस दिलाती है। User IDs हर जगह request के अंदर सफ़र करती हैं।

Play from 35:27 और आप bidders को एक-एक करके move करते हैं, हर हज़ार sessions पर revenue से मापकर।

Play from 35:35 ये था Module तीन। अब आप जानते हैं कि browser में जगह क्यों ख़त्म हो जाती है, hybrid auction कैसे काम करता है, एक Prebid Server call कैसी दिखती है, और server-side जाने पर identity में क्या कीमत चुकानी पड़ती है।

Play from 35:51 Module चार में हम Prebid Server को production में चलाएँगे। Prebid Cache, stored requests, AMP और apps, cost और capacity, और ये कि इसे ख़ुद host करें या नहीं।

Play from 35:59 पहले practice करना चाहते हैं? RediAds Academy में header bidding levels खेलिए, blog dot rediads dot com पर।

Play from 36:04 Module चार में मिलते हैं।