Running Prebid Server in production

0:00Welcome, outcomes and key terms

Play from 0:00 आपकी app team को आज रात एक bidder की placement ID बदलनी है। App store review में कई दिन लगेंगे।

Play from 0:07 और आपके AMP pages पर Prebid.js चल ही नहीं सकता।

Play from 0:11 दोनों problems का जवाब एक ही है, और वो Prebid Server पर है। Module तीन में आपने देखा कि एक Prebid Server auction कैसे काम करता है। अब हम इसे असल में चलाते हैं।

Play from 0:21 RediAds Academy की Header Bidding Masterclass में फिर से स्वागत है। ये है Module चार: Prebid Server को production में चलाना।

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

Play from 0:34 ये समझाना कि Prebid Cache क्या करता है, और ऐसा cache time-to-live set करना जिससे blank ads न आएँ।

Play from 0:42 एक stored request बनाना, और ठीक-ठीक check करना कि Prebid Server ने उससे क्या बनाया।

Play from 0:47 एक header bid को AMP page और app, दोनों में trace करना।

Play from 0:51 और एक Prebid Server set-up का size और cost निकालकर उसे चुनना, self-hosted या managed। एक checklist के साथ जिसे आप meeting में ले जा सकें।

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

Play from 1:05 Prebid Cache creatives को store करता है, ताकि ad render होते समय उन्हें fetch किया जा सके। hb_cache_id वो key-value है जो cached creative की ID ad server तक ले जाती है। TTL, यानी time-to-live, बताता है कि cache उसे कितनी देर रखेगा। Stored request वो configuration है जो server पर रखी जाती है और आने वाली requests में merge होती है।

Play from 1:29 Resolved request वो है जो उस merge के बाद Prebid Server असल में बनाता है। Stored response एक saved जवाब है, जो testing के लिए इस्तेमाल होता है। rtc-config, AMP ad tag का वो हिस्सा है जो Prebid Server को call करता है। और managed host आपके लिए Prebid Server चलाता है।

Play from 1:48 हम यहाँ हैं। Module तीन में देखा कि hybrid auction कैसे काम करता है। Module चार उसे production में चलाने के बारे में है। इसके बाद Module पाँच और छह Google Ad Manager को आपकी bids इस्तेमाल करने के लिए set up करते हैं, उन creatives समेत जो cache से पढ़ते हैं।

2:07Prebid Cache

Play from 2:07 Chapter एक: Prebid Cache। एक छोटी सी service जो चुपचाप video, AMP और apps को चलने लायक बनाती है।

Play from 2:17 Module दो में winning creative page पर Prebid.js के अंदर इंतज़ार करता था, render होने के लिए तैयार। ये हमेशा काम नहीं करता।

Play from 2:25 Video player को ad markup नहीं चाहिए। उसे एक URL चाहिए जो VAST XML लौटाए।

Play from 2:31 AMP page को Prebid Server से सिर्फ़ key-values वापस मिलती हैं। Page पर कोई Prebid.js नहीं है जो creative को पकड़कर रखे।

Play from 2:38 और app में हर creative को memory में लेकर घूमना, बस इस उम्मीद में कि शायद जीत जाए, बर्बादी है।

Play from 2:45 तीनों को एक ही चीज़ चाहिए। Creative को एक बार store करो, और उसकी जगह एक छोटा सा pointer भेजो। यही है Prebid Cache।

Play from 2:54 Caching आप Prebid Server वाली request में माँगते हैं, ext dot prebid dot cache के नीचे।

Play from 3:04 ``json "ext": { "prebid": { "targeting": { "includewinners": true }, "cache": { "bids": { "ttlseconds": 300 }, "vastxml": { "ttlseconds": 300, "returnCreative": false } } } } ``

Play from 3:15 bids पूरी winning bid को cache करता है, उसके markup समेत। उसकी ID key-value hb_cache_id के रूप में वापस आती है।

Play from 3:22 vastxml सिर्फ़ video bids का VAST XML cache करता है। वो ID hb_uuid के रूप में वापस आती है।

Play from 3:30 ttlseconds बताता है कि cache उसे कितनी देर रखे। returnCreative, false, creative को cache में रखता है लेकिन response से बाहर। इससे bandwidth बचती है।

Play from 3:42 एक पेच है। जब तक request में targeting भी set न हो, caching कुछ नहीं करती। Prebid Server cache की location key-values के रूप में लौटाता है, इसलिए उसे targeting चालू चाहिए।

Play from 3:55 चलिए एक cached creative को follow करते हैं।

Play from 3:57 Prebid Server winning creative को Prebid Cache में store करता है, और बदले में एक unique ID पाता है।

Play from 4:04 वो ID ad server तक एक key-value के रूप में जाती है, hb_cache_id, hb_pb और hb_bidder के साथ। दो और keys, hb_cache_host और hb_cache_path, बताती हैं कि cache कहाँ है।

Play from 4:19 Google Ad Manager में Prebid line item जीतता है। उसका creative, यानी Prebid Universal Creative, इन तीन values से cache से creative fetch करता है।

Play from 4:29 और उसे render करता है। Video के लिए player उसी तरह के URL से VAST XML fetch करता है।

Play from 4:36 Prebid Cache एक अलग, open-source service है, जिसका काम बहुत छोटा है।

Play from 4:40 Writes, slash cache पर एक POST होते हैं, एक या ज़्यादा values के साथ। हर value या तो XML होती है या JSON। जवाब में हर एक के लिए एक UUID आता है।

Play from 4:53 Reads, slash cache question mark uuid equals उस ID पर एक GET होते हैं।

Play from 4:58 इसके पीछे एक तेज़ store होता है, जैसे Redis, Aerospike, Cassandra या Apache Ignite। Cache servers को ख़ुद बहुत कम CPU या memory चाहिए। असली काम store करता है।

Play from 5:11 TTL कितना होना चाहिए? ये नंबर illustrative हैं।

Play from 5:15 नियम ये है। TTL, auction और fetch के बीच के सबसे लंबे normal gap से ज़्यादा चलना चाहिए। अगर आपका player कभी-कभी auction के चार मिनट बाद VAST fetch करता है, तो साठ second के TTL का मतलब है उन plays पर blank ads।

Play from 5:30 लेकिन लंबा TTL memory खाता है। Store में लगभग इतना data रहता है: writes per second, गुणा TTL, गुणा object size। पचास writes हर second, तीन सौ seconds के लिए, पाँच kilobytes हर एक, यानी लगभग पचहत्तर megabytes।

Play from 5:46 TTL को एक घंटा कर दीजिए तो उसी traffic के लिए ये लगभग नौ सौ megabytes हो जाता है।

Play from 5:51 और TTL best effort है, जिसकी एक maximum host तय करता है। इसे एक target मानिए, वादा नहीं।

Play from 5:58 तीन Prebid Cache गलतियाँ जो हम देखते हैं।

Play from 6:01 पहली: किसी example से copy किया गया TTL, जो render तक के असली gap से छोटा है। आपको blank ads मिलते हैं जो creative की problem जैसे दिखते हैं।

Play from 6:11 दूसरी: ये मान लेना कि cache keys हमेशा मौजूद होंगी। अगर cache भरा हुआ है या पहुँच से बाहर है, तो Prebid Server hb_cache_id छोड़ सकता है। और आपके Ad Manager line items जो उसे target करते हैं, match नहीं होंगे।

Play from 6:27 तीसरी: एक पुराना cache URL browser में paste करके cached creative को test करना। वो शायद expire हो चुका है। एक fresh auction चलाइए, फिर fetch कीजिए।

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

Play from 6:45 Prebid Server से serve हुए कुछ video ads blank render होते हैं। Player auction के कुछ मिनट बाद VAST fetch करता है। आप सबसे पहले कौन सी setting देखेंगे?

Play from 6:52 Cache request में ttlseconds। अगर cached VAST, player के माँगने से पहले expire हो जाता है, तो ad blank रहता है।

7:00Stored requests and stored responses

Play from 7:01 Chapter दो। वो feature जिस पर ops teams सबसे ज़्यादा निर्भर हो जाती हैं: stored requests। फिर उनका testing वाला जुड़वाँ, stored responses।

Play from 7:11 Idea ये है।

Play from 7:12 आने वाली request पतली होती है। उसमें page या app की details, ad slots और एक ID होती है।

Play from 7:18 Server पर वो ID stored JSON की तरफ़ point करती है: bidders, उनके params, price granularity और caching settings।

Play from 7:27 Prebid Server किसी भी bidder को call करने से पहले दोनों को merge करके एक पूरी OpenRTB request बनाता है।

Play from 7:33 इसके दो levels हैं। Top-level stored request में पूरी request की settings होती हैं। Impression-level वाली में एक slot के bidders होते हैं।

Play from 7:43 चलिए The Monsoon Times के लिए एक बनाते हैं। IDs और params illustrative हैं। Page या app से ये आता है।

Play from 8:00 ``json { "id": "req-7781", "site": { "page": "https://monsoontimes.example/markets/sensex" }, "imp": [{ "id": "div-mpu", "banner": { "format": [{ "w": 300, "h": 250 }] }, "ext": { "prebid": { "storedrequest": { "id": "monsoon-mpu" } } } }], "ext": { "prebid": { "storedrequest": { "id": "monsoon-web" } } } } ``

Play from 8:16 Impression के अंदर एक stored request ID: monsoon dash mpu। ये इस slot की settings हैं।

Play from 8:23 Top level पर एक और ID: monsoon dash web, उन settings के लिए जो पूरी site में shared हैं।

Play from 8:29 देखिए क्या missing है। एक भी bidder नहीं। जो कुछ live है वो यहाँ है, यानी page, slot और उसका size। जो कुछ ops control करता है वो server पर है।

Play from 8:40 ये है monsoon dash web, server पर stored।

Play from 8:49 ``json { "cur": ["USD"], "ext": { "prebid": { "targeting": { "pricegranularity": "medium", "includewinners": true }, "cache": { "bids": { "ttlseconds": 300 } } } } } ``

Play from 8:58 Currency। वो price granularity जो Prebid Server को hb_pb के लिए इस्तेमाल करनी है। और caching, ताकि winner को hb_cache_id मिले।

Play from 9:07 इसमें से कुछ भी एक slot के बारे में नहीं है। इसे एक बार बदलिए, और यहाँ point करने वाली हर request उसे उठा लेती है।

Play from 9:17 और monsoon dash mpu।

Play from 9:26 ``json { "ext": { "prebid": { "bidder": { "sovrn": { "tagid": "403370" }, "ix": { "siteId": "300" }, "pubmatic": { "publisherId": "156209", "adSlot": "mpu_300x250" } } } } } ``

Play from 9:35 तीन bidders, हर एक अपने params के साथ। ये वही block है जो आपने Module तीन के request walk-through में देखा था। बस अब ये server पर रहता है।

Play from 9:44 चौथा bidder जोड़ने के लिए आप ये record edit करते हैं। कोई page release नहीं, और app के लिए कोई app store update नहीं।

Play from 9:53 Prebid Server इसे जोड़ता है।

Play from 10:14 ``json { "id": "req-7781", "cur": ["USD"], "site": { "page": "https://monsoontimes.example/markets/sensex" }, "imp": [{ "id": "div-mpu", "banner": { "format": [{ "w": 300, "h": 250 }] }, "ext": { "prebid": { "bidder": { "sovrn": { "tagid": "403370" }, "ix": { "siteId": "300" }, "pubmatic": { "publisherId": "156209", "adSlot": "mpu_300x250" } } } } }], "ext": { "prebid": { "targeting": { "pricegranularity": "medium", "includewinners": true }, "cache": { "bids": { "ttlseconds": 300 } } } } } ``

Play from 10:36 Page से आए live हिस्से। Stored impression से slot के bidders। और stored top-level request से site settings।

Play from 10:43 Bidders के adapters असल में इसी पर काम करते हैं। और आप इसे ख़ुद देख सकते हैं।

Play from 10:49 ऐसे।

Play from 10:50 Top level पर test equals one के साथ एक request भेजिए। तब Prebid Server के response में ext dot debug dot resolvedrequest आता है। यानी stored data merge होने के बाद की request।

Play from 11:01 Prebid.js से आप इसे ortb2 config से set कर सकते हैं: test, one।

Play from 11:07 जब भी कोई stored field और कोई live field overlap कर सकते हों, इसे इस्तेमाल कीजिए। याद के भरोसे मत निकालिए कि कौन जीतेगा। Resolved request देखिए।

Play from 11:17 और बाद में test बंद कर दीजिए। Bidders test requests को non-billable मानते हैं।

Play from 11:24 monsoon dash mpu असल में रहता कहाँ है?

Play from 11:27 हर server पर files में, जो testing के लिए ठीक है। आमतौर पर एक database में, जो हर Prebid Server के बीच shared होता है और हर region में replicate होता है। या फिर एक HTTP service के पीछे।

Play from 11:40 Prebid Server इन्हें memory में cache करता है, और source पर सिर्फ़ नई या पुरानी पड़ चुकी entries के लिए जाता है। ये तेज़ है, लेकिन एक edit को हर server तक पहुँचने में समय लग सकता है। "Instant" का वादा करने से पहले refresh settings check कीजिए।

Play from 11:57 और Go version की एक detail। Stored data recursively apply नहीं होता। अगर एक stored request में ऐसे impressions हैं जिनकी अपनी stored IDs हैं, तो वो अंदर वाली IDs resolve नहीं होंगी।

Play from 12:10 तो stored requests को edit कौन करता है, और किस चीज़ से?

Play from 12:14 Prebid Server के साथ कोई editor नहीं आता। Prebid की अपनी hosting guide कहती है कि उस database को भरने के लिए कोई open-source tools नहीं हैं। Hosts अपना interface या API ख़ुद बनाते हैं।

Play from 12:25 अगर आप self-host करते हैं तो ये एक tool है जिसे आपकी team बनाती और संभालती है।

Play from 12:31 दोनों में से कोई भी रास्ता हो, stored requests को code की तरह treat कीजिए। JSON को version control में रखिए, changes review कीजिए, और roll back का रास्ता रखिए। एक shared record में एक गलत param, उसकी तरफ़ point करने वाले हर slot को तोड़ देता है।

Play from 12:46 Stored responses testing वाले जुड़वाँ हैं। Configuration store करने की बजाय आप जवाब store करते हैं।

Play from 12:53 Stored auction response एक impression का पूरा result बदल देता है। किसी bidder को call ही नहीं किया जाता। एक जानी-पहचानी, बार-बार दोहराई जा सकने वाली bid के साथ अपना Ad Manager set-up और rendering check करने के लिए ये बढ़िया है।

Play from 13:09 Stored bid response ज़्यादा सीमित है। Auction चलता है, लेकिन जिन bidders का आप नाम देते हैं उनके adapter में एक saved response डाला जाता है। इसी से आप असली demand का इंतज़ार किए बिना एक adapter की parsing test करते हैं।

Play from 13:25 Prebid Mobile SDK की test config IDs भी ऐसे ही काम करती हैं। इनमें से कोई भी normal production traffic में नहीं होना चाहिए।

Play from 13:35 Stored requests की तीन गलतियाँ जो हम देखते हैं।

Play from 13:38 पहली: समय बचाने के लिए हर placement का एक ही stored impression। फिर कोई उसे homepage के लिए edit करता है, और app भी बदल जाता है। हर placement को उसका अपना record दीजिए।

Play from 13:51 दूसरी: record edit करके तुरंत result check करना। Servers शायद अब भी अपनी cached copy इस्तेमाल कर रहे हों। Refresh का इंतज़ार कीजिए, या कुछ servers पर resolved request check कीजिए।

Play from 14:03 तीसरी: testing के बाद किसी live ad unit पर stored auction response ID छोड़ देना। हर reader को वही test bid दिखती है, और किसी असली bidder को call नहीं होता।

Play from 14:15 The Monsoon Times के इस version में page पर कोई bidder नहीं है। Prebid.js से ad unit की bids पूछिए: एक entry है, और उसका bidder null है।

Play from 14:26 ये रही Prebid Server को जाने वाली request। दो stored request IDs: एक इस slot के लिए, एक site के लिए। Bidders के बारे में और कुछ नहीं।

Play from 14:36 अब response। Page ने test को one पर set किया है, इसलिए Prebid Server resolved request वापस भेजता है। ये रहे तीनों bidders और उनके params, stored impression से आए हुए। और price granularity और caching, site record से।

Play from 14:55 अब एक ops change करते हैं। हम stored impression में rubicon जोड़ेंगे। असली host पर ये उनका interface या आपका database होगा। यहाँ ये हमारे mock को एक call है। Page reload कीजिए। Page का code बिल्कुल नहीं बदला। और resolved request में अब चार bidders हैं। Rubicon auction में है।

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

Play from 15:21 आप एक bidder जोड़ने के लिए stored impression edit करते हैं। दो मिनट बाद कुछ page views में नया bidder दिखता है और कुछ में नहीं। इसकी संभावित वजह क्या है?

Play from 15:29 Caching। हर Prebid Server stored requests को memory में रखता है और अपने schedule पर refresh करता है। जब तक हर server refresh नहीं कर लेता, कुछ auctions पुरानी copy इस्तेमाल करते हैं।

15:42AMP and app SDKs

Play from 15:43 Chapter तीन। दो environments जहाँ Prebid Server optional नहीं है: AMP pages और mobile apps।

Play from 15:52 AMP आपको page पर Prebid.js, या कोई भी custom JavaScript, चलाने नहीं देता। तो auction को कहीं और होना पड़ता है।

Play from 16:00 AMP का जवाब है real-time config, यानी RTC। AMP runtime ad server से ad माँगने से पहले कुछ vendors को call कर सकता है, और जो वो लौटाएँ उसे ad request में जोड़ सकता है।

Play from 16:13 Prebid Server उन vendors में से एक है, एक अलग endpoint के ज़रिए: slash openrtb2 slash amp।

Play from 16:23 पाँच steps।

Play from 16:24 एक। amp-ad tag में एक rtc-config होता है जो AMP runtime को Prebid Server call करने को कहता है।

Play from 16:31 दो। Runtime slash openrtb2 slash amp को call करता है, एक tag ID, slot के size और page URL के साथ।

Play from 16:39 तीन। Prebid Server उस tag ID की stored request load करता है, URL में आई चीज़ें जोड़ता है, और auction चलाता है।

Play from 16:47 चार। वो winners को Prebid Cache में store करता है, और सिर्फ़ targeting key-values लौटाता है, cache ID समेत।

Play from 16:54 पाँच। AMP उन key-values को Google Ad Manager request में जोड़ता है। अगर Prebid line item जीतता है तो उसका creative cache से winner को fetch करके render करता है।

Play from 17:07 ये है एक simplified amp-ad tag, screen में fit होने के लिए wrap किया हुआ। ये उस form में है जो किसी भी Prebid Server host के साथ काम करता है।

Play from 17:12 ``html ``

Play from 17:17 tag_id, stored request ID है। Bidders के बारे में सब कुछ वहीं रहता है।

Play from 17:22 ATTR width, CANONICAL_URL और CONSENT_STRING जैसे macros से AMP आपके लिए slot, page और consent string भर देता है।

Play from 17:31 और timeoutMillis बताता है कि AMP इस callout का कितनी देर इंतज़ार करेगा। Prebid के अपने example में ये पाँच सौ है।

Play from 17:42 कुछ बड़े hosts AMP के साथ named vendors के रूप में registered हैं, तो उनके tags और भी छोटे होते हैं। क्योंकि AMP page सिर्फ़ एक tag ID भेज सकता है, ये सबसे साफ़ example है कि stored requests क्यों हैं।

Play from 17:54 उस tag ID के पीछे की stored request के कुछ नियम हैं।

Play from 17:57 उसमें ठीक एक impression होना चाहिए, और कोई app object नहीं। एक AMP slot, एक stored request।

Play from 18:05 अंदर होते हैं उस impression पर bidders और उनके params, price granularity, currency, और आपका supply chain object।

Play from 18:13 और ext dot prebid dot cache dot bids। इसके बिना कोई cache ID नहीं, और AMP creative के पास fetch करने को कुछ नहीं।

Play from 18:23 AMP पर identity का क्या? वहाँ slash cookie underscore sync को call करने के लिए कोई Prebid.js नहीं है।

Play from 18:30 उसकी जगह आप एक one-by-one amp-iframe जोड़ते हैं, जो Prebid का एक छोटा page load करता है, जिसका नाम है load-cookie dot html। ये Prebid Server के लिए sync चलाता है।

Play from 18:43 Iframe को ऐसा sandbox चाहिए जो scripts और same-origin allow करे। और AMP तय करता है कि एक page पर कितने छोटे iframes हो सकते हैं, तो शायद आपको एक ही मिले।

Play from 18:54 अगर आपका page consent tool इस्तेमाल करता है और आपका host पुराना load-cookie page चलाता है, तो Prebid की guide आपको एक consent-aware version की तरफ़ भेजती है।

Play from 19:06 Apps भी मिलता-जुलता pattern follow करते हैं, iOS और Android के लिए Prebid Mobile SDK के ज़रिए।

Play from 19:14 एक। Start-up पर app SDK को आपके Prebid Server के address और आपकी account ID के साथ initialise करता है।

Play from 19:22 दो। App में हर ad unit एक config ID के साथ बनती है। वो config ID एक stored request ID है।

Play from 19:29 तीन। SDK slash openrtb2 slash auction पर एक OpenRTB request भेजता है। ये वही endpoint है जो Prebid.js इस्तेमाल करता है। Prebid Server stored request merge करता है, bidders को call करता है और creatives cache करता है।

Play from 19:45 चार। Ad Manager के साथ, SDK key-values को ad request में जोड़ता है, और अगर Prebid जीतता है तो creative cache से आता है। SDK winner को ख़ुद भी render कर सकता है, या mediation के ज़रिए काम कर सकता है।

Play from 19:59 तो ops नया app version ship किए बिना क्या बदल सकता है?

Play from 20:03 Stored requests में जो कुछ भी है: bidders, params, price granularity और cache TTL।

Play from 20:09 जिसके लिए अब भी release चाहिए: app में नई ad unit या format, SDK upgrade, और app में ही रखी settings, जैसे SDK का अपना timeout।

Play from 20:19 ये config IDs को शुरू में ही ध्यान से design करने की एक मज़बूत वजह है। हर placement को उसकी अपनी ID मिले, चाहे दो placements एक ही bidders से शुरू हों।

Play from 20:31 ये रहे तीनों, साथ-साथ।

Play from 20:32 Web पर Prebid.js slash openrtb2 slash auction को call करता है। Bidder config page पर रहता है, या stored requests में।

Play from 20:42 AMP पर AMP runtime slash openrtb2 slash amp को call करता है। Bidder config सिर्फ़ stored requests में रहता है।

Play from 20:51 Apps में Prebid SDK slash openrtb2 slash auction को call करता है। यहाँ भी bidder config stored requests में रहता है।

Play from 20:59 एक ही server, तीन दरवाज़े।

Play from 21:02 AMP और app की तीन गलतियाँ जो हम देखते हैं।

Play from 21:05 पहली: cache block के बिना AMP stored request। Auction चलता है, bids आती हैं, और ads blank render होते हैं।

Play from 21:13 दूसरी: SDK की test config IDs के साथ ही app build ship कर देना। हर reader को वही stored test response मिलता है।

Play from 21:21 तीसरी: AMP page से ही AMP को debug करने की कोशिश। वहाँ debug output नहीं मिल सकता। slash openrtb2 slash amp वाली call copy कीजिए और उसे debug equals one के साथ ख़ुद चलाइए। हमारा अगला demo बिल्कुल यही है।

Play from 21:37 ये रहा अभी वाला AMP tag। Bidders के बारे में ये Prebid Server को सिर्फ़ एक चीज़ बताता है: tag ID।

Play from 21:49 AMP page पर AMP debug output नहीं मिलता। तो चलिए वही करते हैं जो troubleshooting guide कहती है। वही call ख़ुद करते हैं, debug equals one के साथ। जवाब एक targeting object है, साथ में कुछ debug detail, क्योंकि हमने माँगी थी।

Play from 22:01 Targeting खोलिए। hb_pb, hb_bidder, hb_size, और cache ID, host और path। AMP, Ad Manager request में बस इतना ही जोड़ेगा। इसमें creative बिल्कुल नहीं है।

Play from 22:15 तो चलिए वो करते हैं जो Prebid creative करता। Host, path और cache ID से Prebid Cache से winner को fetch करते हैं। और ये रहा: price और creative markup। Key-values ad server को, creative cache से।

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

Play from 22:36 आपके AMP pages की Ad Manager request में Prebid key-values दिखती हैं, और Prebid line items जीतते हैं, लेकिन ads blank हैं। आप कहाँ देखेंगे?

Play from 22:43 Cache में। Check कीजिए कि AMP stored request, ext dot prebid dot cache dot bids माँगती है। कि hb_cache_id मौजूद है। और जब creative उसे fetch करता है, तब cached creative अब भी मौजूद है।

22:58Cost, capacity and latency

Play from 22:59 Chapter चार। Prebid Server चलाने में असल में क्या लगता है, उसे कितना बड़ा होना चाहिए, और location इतनी मायने क्यों रखती है।

Play from 23:09 "Prebid Server चलाने" का मतलब एक server से कहीं ज़्यादा है।

Play from 23:13 एक global load balancer, ताकि हर reader सबसे नज़दीकी region तक पहुँचे। Regional load balancers, जो secure connections भी संभालते हैं, क्योंकि Prebid Server और Prebid Cache ख़ुद SSL terminate नहीं करते।

Play from 23:26 Prebid Servers, जिनमें network और CPU दोनों का काम होता है। Prebid Cache, अपने पीछे तेज़ store के साथ। और accounts और stored requests के लिए एक replicated database।

Play from 23:37 इन सबके लिए monitoring। Go version metrics को InfluxDB या Prometheus पर report कर सकता है। Java version InfluxDB, Graphite, Prometheus या console पर।

Play from 23:49 और upgrades। Prebid की hosting guide hosts से कहती है कि कम से कम हर तिमाही updates check करें। लगभग हर हफ़्ते नई releases आती हैं।

Play from 23:59 कितना बड़ा? Prebid के docs sizing के आँकड़े नहीं देते, तो चलिए ख़ुद एक हिसाब लगाते हैं। यहाँ हर नंबर illustrative है।

Play from 24:07 महीने में तीन करोड़ page views, यानी रोज़ लगभग दस लाख।

Play from 24:12 मान लीजिए हर page view पर डेढ़ Prebid Server requests, refreshes और infinite scroll की वजह से। यानी रोज़ पंद्रह लाख requests, या average में लगभग सत्रह हर second।

Play from 24:25 Traffic एक जैसा नहीं रहता। सुबह की news और एक बड़ा cricket match इसे तीन गुना कर सकते हैं। तो peak पर लगभग पचास हर second के लिए plan कीजिए।

Play from 24:34 फिर headroom जोड़िए, ताकि एक region दूसरे का traffic संभाल सके। इसे दोगुना कीजिए: लगभग सौ requests हर second।

Play from 24:42 और ये तो सिर्फ़ अंदर आने वाला traffic है। ये भी illustrative है।

Play from 24:46 हर request हर server-side bidder तक जाती है। पचास requests हर second पर छह bidders, यानी हर second लगभग तीन सौ outbound bidder calls।

Play from 24:57 हर bidder request लगभग तीन kilobytes की हो, तो peak पर आपके servers से लगभग सात megabits हर second बाहर जाते हैं, किसी भी response से पहले।

Play from 25:06 एक महीने में average rate पर ये लगभग आठ सौ gigabytes है, जो bidders को भेजा जाता है।

Play from 25:12 तो capacity peak fan-out पर plan कीजिए, page views पर नहीं। यहाँ एक server-side bidder जोड़ने से outbound traffic रातों-रात छठा हिस्सा बढ़ जाता है।

Play from 25:23 अब खर्च की lines।

Play from 25:24 Compute, जो peak requests गुणा bidders के साथ बढ़ता है। Data transfer: हर auction आपके network से हर bidder को एक request भेजता है, तो अपने cloud की outbound pricing check कीजिए। Cache store की memory, जो writes गुणा TTL के साथ बढ़ती है।

Play from 25:41 Logs। Raw auction logs, जिनमें हर bidder call हो, बाकी सबसे बड़े हो सकते हैं। तय कीजिए कि आप क्या रखेंगे, और कितनी देर।

Play from 25:50 और लोग: upgrades, on-call, stored request tool और privacy reviews। बहुत से छोटे और मझोले publishers के लिए ये सबसे बड़ी line है।

Play from 26:01 Regions ज़्यादातर लोगों की सोच से ज़्यादा मायने रखते हैं। ये round-trip times illustrative हैं।

Play from 26:07 Mumbai का एक reader अगर Mumbai के Prebid Server को call करे, तो एक round trip में लगभग बीस milliseconds लग सकते हैं। Frankfurt में लगभग एक सौ बीस। US east coast पर लगभग दो सौ।

Play from 26:19 और page की पहली call को एक से ज़्यादा round trip चाहिए। नया secure connection बनने में लगभग दो round trips लगते हैं, फिर जवाब के लिए एक और। मान लीजिए तीन।

Play from 26:31 तीन सौ milliseconds के network budget में Mumbai साठ इस्तेमाल करता है। Frankfurt तीन सौ साठ, यानी पहले ही budget से ऊपर। US east coast छह सौ।

Play from 26:42 तो आप कोई भी रास्ता चुनें, Prebid Server को अपनी audience के पास रखिए। Indian audience के लिए इसका मतलब है India।

Play from 26:50 Server के अंदर की एक और timing detail।

Play from 26:53 Prebid Server हर bidder को पूरा tmax नहीं देता। वो कुछ समय अपनी processing और network के लिए रोक लेता है, ताकि bidders के जवाब समय पर पहुँचें।

Play from 27:03 Go और Java versions ये अलग-अलग settings से करते हैं, और hosts इन्हें हर region के हिसाब से tune करते हैं। धीमे region में bidders को छोटा हिस्सा मिलता है।

Play from 27:13 तो सात सौ milliseconds के tmax वाले bidder को असल में शायद छह सौ मिलें। Illustrative। अगर उसके response times उस line के आसपास हैं, तो server पर उसका time out आपकी उम्मीद से ज़्यादा बार होगा।

Play from 27:26 तो आप क्या देखें? ये examples हैं, नियम नहीं। अपनी baselines ख़ुद set कीजिए।

Play from 27:32 हर region के लिए: requests हर second, error rate, और auction response times का धीमा सिरा। सिर्फ़ average नहीं।

Play from 27:40 हर bidder के लिए: response के ext से response time और timeout rate, और bid rate। Return all bid status माँगने से हर उस bidder के लिए एक reason code जुड़ जाता है जिसने bid नहीं की, जैसे timeout।

Play from 27:53 और plumbing: cache write failures, fail होने वाले stored request lookups, और ये कि आप latest release से कितने versions पीछे हैं।

Play from 28:03 Production की तीन गलतियाँ जो हम देखते हैं।

Play from 28:05 पहली: readers से दूर सिर्फ़ एक region, क्योंकि cloud console में वही default था। पूरा network budget दूरी में चला जाता है।

Play from 28:13 दूसरी: average traffic से sizing करना। पहला बड़ा match day आपको limit ख़ुद दिखा देता है।

Play from 28:20 तीसरी: एक साल तक वही version चलाना। Bidder adapters, privacy rules और OpenRTB spec बदलते रहते हैं, और आपका server भी बदलना चाहिए।

Play from 28:30 ये फिर से हमारा hybrid page है। एक second का bidder timeout, और server के लिए सात सौ milliseconds। हमारा mock Prebid Server थोड़ी सी delay जोड़ रहा है, जैसे उसी शहर का कोई server हो। Call timeout के काफ़ी अंदर वापस आ जाती है। और sovrn की server bid auction में है, browser bidders से मुक़ाबला करती हुई।

Play from 28:51 अब वही page, लंबी delay के साथ, जैसे दूसरे महाद्वीप का कोई server हो। एक second पर Prebid.js इंतज़ार बंद कर देता है और call cancel कर देता है। सिर्फ़ दो client-side bids बचती हैं। और Prebid.js server bidders को timed out दिखाता है।

Play from 29:02 यहाँ कुछ टूटा नहीं है। Server ने अपना auction चलाया। Bids बस बहुत देर से आईं, क्योंकि दूरी ने network budget खा लिया।

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

Play from 29:20 आपके ज़्यादातर readers India में हैं, लेकिन आपका Prebid Server Frankfurt में चलता है। आपका bidder timeout एक हज़ार है, और server timeout सात सौ। Reader के पहले page view पर क्या होता है?

Play from 29:28 Frankfurt तक set-up वाले round trips, तीन सौ milliseconds के network budget से ज़्यादा ले सकते हैं। तो server bids अक्सर बहुत देर से पहुँचती हैं। Timeouts को छूने से पहले server को पास लाइए।

29:41Build versus managed

Play from 29:42 आख़िरी chapter। आपने देखा कि Prebid Server चलाने में क्या लगता है। अब practical सवाल। इसे आप ख़ुद चलाएँ, या किसी और से चलवाएँ?

Play from 29:51 अगर आप self-host करते हैं तो पहले code base चुनना होगा।

Play from 29:55 Prebid Server के दो versions हैं। Go, जो original है, और Java, जो बाद में बना port है। दोनों Prebid.org के तहत maintain होते हैं।

Play from 30:05 इनके features मिलते-जुलते हैं, लेकिन एक जैसे नहीं। चुनने से पहले feature list में हर वो चीज़ check कीजिए जिस पर आप निर्भर हैं, जैसे कोई ख़ास bidder, module या privacy feature।

Play from 30:16 Managed host ये चुनाव आपके लिए कर चुका है। पूछिए कि कौन सा, और वो latest release से कितना पीछे चलते हैं।

Play from 30:24 ये रही एक neutral तुलना।

Play from 30:26 Cost। Self-hosting का मतलब है servers, bandwidth, storage और engineering time का खर्च। Managed host आमतौर पर एक fee या revenue share लेता है।

Play from 30:38 Operations। Self-hosted में pager आपकी team का है। Managed में host का।

Play from 30:43 Regions। Self-hosted में आप तय करते हैं कि कहाँ deploy करें, लेकिन हर region पर पैसा लगता है। Managed host शायद पहले से आपके readers के पास हो। या शायद न हो।

Play from 30:54 Data और control। Self-hosting से आपको raw logs और पूरा control मिलता है। Managed host के साथ check कीजिए कि आपको कौन सा data वापस मिलता है, और उसे और कौन देखता है।

Play from 31:07 अगर आप managed hosts से बात कर रहे हैं, तो ये रही तीन हिस्सों में एक checklist। पहला, performance।

Play from 31:15 आपके regions कहाँ हैं, और मेरे readers के शहरों से आप कितना round-trip time मापते हैं? Mumbai, Delhi, Chennai, जहाँ भी आपकी audience है, वहाँ के नंबर माँगिए।

Play from 31:26 Go या Java, और आप latest release से कितना पीछे चलते हैं? Adapter और privacy updates कितनी जल्दी production तक पहुँचते हैं?

Play from 31:34 क्या आप मेरे इस्तेमाल किए हर bidder को support करते हैं, और क्या मैं अपनी seats और params ला सकता हूँ?

Play from 31:42 दूसरा, रोज़ के operations।

Play from 31:45 हम stored requests को कैसे edit करेंगे: एक interface, एक API, या support ticket से? Edits को हर server तक पहुँचने में कितना समय लगता है, और क्या कोई change history है जिससे मैं roll back कर सकूँ?

Play from 31:59 क्या मेरी team debug करते समय test requests इस्तेमाल कर सकती है और resolved request देख सकती है?

Play from 32:05 मुझे कौन सी reporting मिलती है: raw logs, एक analytics feed, या सिर्फ़ dashboards?

Play from 32:12 तीसरा, contract।

Play from 32:14 Privacy: आप कौन से consent frameworks support करते हैं, और logs और IDs कितनी देर रखते हैं? India के data protection rules नवंबर दो हज़ार पच्चीस में notify हुए, और दो हज़ार सत्ताईस तक चरणों में लागू होंगे। तो इसमें अपने lawyers को शामिल कीजिए।

Play from 32:31 पैसा: ये fee है या revenue share, और bill किसके नंबरों पर बनता है? Uptime commitment क्या है, और incidents के बारे में आप मुझे कैसे बताते हैं?

Play from 32:42 और exit: क्या मैं अपनी stored requests और account settings ऐसे form में export कर सकता हूँ जिसे कहीं और load किया जा सके? ये sign करने से पहले पूछिए, छोड़ते समय नहीं।

Play from 32:54 और चार सवाल आपकी अपनी team के लिए।

Play from 32:57 क्या आपके पास ऐसे engineers हैं जो चौबीसों घंटे, सातों दिन चलने वाली service संभाल सकें? आपके readers कहाँ हैं, और क्या आप उनके पास servers का खर्च उठा सकते हैं? क्या आपको raw auction logs चाहिए, या reports काफ़ी हैं? और आपको AMP या app support कितनी जल्दी चाहिए?

Play from 33:16 अगर ज़्यादातर जवाब "अभी नहीं" हैं, तो managed host एक समझदार शुरुआत है। RediAds में हम यही करते हैं। हमारा Prebid wrapper, RediWrap, आपके लिए server-to-server bidding चलाता है, तो आपको Prebid Server खुद host नहीं करना पड़ता। Team और scale हो तो self-hosting आपको पूरा control देती है। बहुत से publishers managed से शुरू करते हैं और बाद में in-house आ जाते हैं।

Play from 33:41 चलिए इसे लागू करते हैं। ये publisher illustrative है।

Play from 33:44 एक news site। महीने में तीन करोड़ page views, पचासी प्रतिशत readers India में, दो developers, रात में कोई on call नहीं, और छह महीने में एक app launch।

Play from 33:54 चौबीसों घंटे वाली service के लिए engineers: अभी नहीं। Readers के पास servers: एक Indian region चाहिए। Raw logs: हों तो अच्छा। Apps: जल्द ही।

Play from 34:04 तो फ़ैसला: Indian region वाला एक managed host, जिसे उनके readers के शहरों से मापा गया हो। ऐसी stored requests जिन्हें ad ops team edit कर सके। और एक export clause।

Play from 34:15 और diary में बारह महीने बाद की एक तारीख़, ताकि असली traffic numbers के साथ चारों सवाल फिर से पूछे जाएँ।

Play from 34:24 इस फ़ैसले में तीन गलतियाँ जो हम देखते हैं।

Play from 34:26 पहली: अपने readers के शहरों से latency मापे बिना, सिर्फ़ price पर host चुनना।

Play from 34:33 दूसरी: कोई exit plan नहीं। आपकी stored requests ही आपकी configuration हैं। अगर आप उन्हें export नहीं कर सकते, तो आप छोड़ नहीं सकते।

Play from 34:42 तीसरी: software free है, इसलिए self-host करना। Software free है। Servers, bandwidth और लोग नहीं।

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

Play from 34:56 Myth एक: cache creatives को उतनी देर रखता है जितना TTL कहता है। ये best effort है। इसे margin के साथ set कीजिए, और blanks पर नज़र रखिए।

Play from 35:06 Myth दो: managed का मतलब है कोई झंझट नहीं। Host servers चलाता है। Stored requests, bidder mix, Ad Manager set-up और testing अब भी आपकी ज़िम्मेदारी हैं।

Play from 35:17 Myth तीन: अगर server तेज़ है तो एक region काफ़ी है। Data centre के अंदर की speed, दुनिया के दूसरे छोर पर बैठे reader की मदद नहीं करती। दूरी सबसे पहले network budget से कटती है।

Play from 35:31 चलिए Module चार को recap करते हैं।

Play from 35:32 Prebid Cache, video, AMP और apps के लिए creatives रखता है। उसकी ID hb_cache_id के रूप में जाती है, और TTL को render तक के gap से ज़्यादा चलना चाहिए।

Play from 35:45 Stored requests, bidder configuration को server पर रखती हैं। Merge का अंदाज़ा लगाने की बजाय resolved request check कीजिए।

Play from 35:52 AMP एक tag ID के साथ slash openrtb2 slash amp को call करता है, और apps config IDs इस्तेमाल करते हैं। दोनों stored requests और cache पर निर्भर हैं।

Play from 36:04 Peak fan-out के हिसाब से size कीजिए, servers को readers के पास रखिए, और उन्हें upgraded रखिए।

Play from 36:11 Build करें या buy, साफ़ नज़र से तय कीजिए: cost, operations, regions, data और एक exit plan।

Play from 36:19 ये था Module चार, और course के Prebid Server वाले हिस्से का अंत। अब आप जानते हैं कि cache, stored requests, AMP और apps कैसे एक साथ जुड़ते हैं, और ये सब चलाने में क्या लगता है।

Play from 36:37 Module पाँच में हम Google Ad Manager को ऐसे set up करेंगे कि वो सच में आपकी header bids इस्तेमाल करे: key-values, price granularity और line items।

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

Play from 36:51 और जब भी इनमें से किसी काम के लिए partner चाहिए, RediAds की team rediads dot com पर मिलेगी। Module पाँच में मिलते हैं।