फ़ीडबैक रिपोर्ट - 2024 की पहली तिमाही

साल 2024 की पहली तिमाही की तिमाही रिपोर्ट में, प्राइवसी सैंडबॉक्स के प्रपोज़ल और Chrome से मिले रिस्पॉन्स के बारे में मिले ईकोसिस्टम के बारे में खास जानकारी.

सीएमए के साथ हुए अपने वादे के तहत, Google ने प्राइवसी सैंडबॉक्स के अपने प्रस्तावों के लिए, हिस्सेदार की दिलचस्पी की प्रक्रिया को तीन महीने में तीन महीने में सार्वजनिक तौर पर रिपोर्ट देने की सहमति दी है. इन रिपोर्ट में समझौते के पैराग्राफ़ 12 और 17(c)(ii) देखें. प्राइवसी सैंडबॉक्स के बारे में फ़ीडबैक की खास जानकारी वाली ये रिपोर्ट, सुझाव की खास जानकारी में दिए गए अलग-अलग सोर्स से, Chrome को मिले सुझाव, शिकायत या राय को इकट्ठा करके जनरेट की जाती हैं. इनमें GitHub से जुड़ी समस्याएं, privacysandbox.com पर उपलब्ध सुझाव, शिकायत या राय भेजने के लिए फ़ॉर्म, इंडस्ट्री के हिस्सेदारों के साथ की गई मीटिंग, और वेब स्टैंडर्ड फ़ोरम शामिल हैं. हालांकि, इनमें और भी चीज़ें शामिल हो सकती हैं. Chrome, नेटवर्क से मिलने वाले सुझाव, शिकायत या राय का स्वागत करता है. साथ ही, वह डिज़ाइन से जुड़े फ़ैसलों में लर्निंग को शामिल करने के तरीक़ों को खोज रहा है.

सुझाव, शिकायत या राय की थीम, हर एपीआई की लोकप्रियता के हिसाब से रैंक की जाती हैं. इसके लिए, किसी थीम के आधार पर Chrome की टीम को मिले सुझाव, शिकायत या राय को इकट्ठा करके और उन्हें घटते क्रम में रखा जाता है. फ़ीडबैक से जुड़े सामान्य विषयों की पहचान करने के लिए, सार्वजनिक मीटिंग (W3C, PatCG, IETF), डायरेक्ट सुझाव, GitHub, और अक्सर पूछे जाने वाले सवालों की समीक्षा की गई. ये सवाल Google की इंटरनल टीम और सार्वजनिक फ़ॉर्म की मदद से दिखाए गए.

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

फ़ीडबैक पर Chrome ने क्या जवाब दिए, इसकी जानकारी, पब्लिश किए गए अक्सर पूछे जाने वाले सवालों, हिस्सेदारों की समस्याओं पर की गई असल प्रतिक्रियाओं, और सार्वजनिक रिपोर्टिंग के इस मकसद के लिए एक स्थिति तय करके तैयार की गई है. हम डेवलपमेंट और टेस्टिंग के मौजूदा फ़ोकस को दिखाते हुए, खास तौर पर Topics, Protected Audience, और Attribution Reporting API से जुड़े सवाल और सुझाव, राय या शिकायत पर मिले.

हो सकता है कि मौजूदा रिपोर्टिंग अवधि के खत्म होने के बाद मिलने वाले फ़ीडबैक को अभी तक Chrome के जवाब के तौर पर शामिल न किया गया हो.

संक्षिप्त नाम की शब्दावली

एआरए

Attribution Reporting API

सीएचआईपीएस

कुकी हैविंग इंडिपेंडेंट पार्टिशन्ड स्टेट

डीएसपी

मांग-साइड प्लैटफ़ॉर्म

FedCM

फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट

FPS (फ़्रेम प्रति सेकंड)

पहले पक्ष के सेट

IAB

इंटरैक्टिव विज्ञापन ब्यूरो

आईडीपी

पहचान देने वाली कंपनी

आईईटीएफ़

इंटरनेट इंजीनियरिंग टास्क फ़ोर्स

IP

इंटरनेट प्रोटोकॉल पता

openRTB

रीयल-टाइम बिडिंग

OT

ऑरिजिन ट्रायल

PAT एपीआई

Protected Audience API (पुराना नाम FLEDGE है)

PatCG

प्राइवेट विज्ञापन टेक्नोलॉजी कम्यूनिटी ग्रुप

RP

भरोसेमंद पार्टी

आरडब्ल्यूएस

मिलती-जुलती वेबसाइट के सेट (पहले पक्ष के सेट कहा जाता था)

एसएसपी

सप्लाई-साइड प्लैटफ़ॉर्म

TEE

भरोसेमंद एक्ज़ीक्यूशन एनवायरमेंट

UA

उपयोगकर्ता एजेंट स्ट्रिंग

UA-CH

उपयोगकर्ता-एजेंट क्लाइंट हिंट

W3C

वर्ल्ड वाइड वेब कंसोर्टियम

डब्ल्यूआईपीबी

विलफ़ुल आईपी ब्लाइंडनेस

सामान्य सुझाव, कोई खास एपीआई या टेक्नोलॉजी नहीं

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
मैनेज करना	प्राइवसी सैंडबॉक्स के मैनेजमेंट से जुड़े किसी भी अपडेट के लिए, सार्वजनिक टिप्पणी करने की अवधि में दिलचस्पी.	हम प्राइवसी सैंडबॉक्स से जुड़े किसी भी अहम बदलाव के बारे में, हिस्सेदारों से सुझाव पाने के लिए तैयार हैं. इसमें, आने वाले समय में प्राइवसी सैंडबॉक्स को मैनेज करना भी शामिल है.
टेस्ट करना	Chrome की सुविधा वाली मौजूदा 1% टेस्टिंग के अलावा, 3PCD के लिए टेस्टिंग के अन्य चरण.	हम जनवरी की शुरुआत से, Chrome ट्रैफ़िक के मौजूदा 1% के अलावा, Chrome की सुविधा वाली टेस्टिंग को उपलब्ध नहीं कराना चाहते हैं.
वेब से ऐप्लिकेशन	वेब और ऐप्लिकेशन के बीच पूरी इंटरऑपरेबिलिटी (दूसरे सिस्टम के साथ काम करना) से पहले, मोबाइल डिवाइसों पर 3PCD नहीं होनी चाहिए.	हम इस बात से सहमत हैं कि ऐप्लिकेशन और वेब इंटरऑपरेबिलिटी के साथ काम करना ज़रूरी है. साथ ही, हमने क्रॉस ऐप्लिकेशन और वेब एट्रिब्यूशन मेज़रमेंट को लॉन्च किया है. साथ ही, हम वेब-टू-ऐप्लिकेशन टारगेटिंग सलूशन एक्सप्लोर कर रहे हैं. हालांकि, हम मोबाइल वेब पर 3PCD में देरी नहीं करने वाले हैं. हमारा ऐसा लक्ष्य नहीं है कि 3PCD के खत्म होने पर, हमारा लक्ष्य 100% हो. इसके बजाय, हम उम्मीद करते हैं कि 3PCD में क्रॉस ऐप्लिकेशन और वेब मेज़रमेंट के लिए Android पर काम करना काफ़ी बेहतर होगा. समय के साथ, जैसे-जैसे उपयोगकर्ता अपने फ़ोन अपडेट करते जाएंगे वैसे-वैसे हम भी इसमें बढ़ोतरी होती जाएगी.
ब्राउज़र की भूमिका	ऐसा लगता है कि Chrome किसी विज्ञापन सर्वर या SSP की भूमिका निभा रहा है.	Chrome किसी विज्ञापन सर्वर या SSP की भूमिका नहीं निभा रहा है. PA API की मदद से Chrome, विज्ञापन सर्वर, SSP, DSP, और विज्ञापन टेक्नोलॉजी को इस्तेमाल करने वाली दूसरी टेक्नोलॉजी को कंटेनर उपलब्ध करा रहा है, ताकि वे बिडिंग और स्कोरिंग लॉजिक को अपनी ज़रूरत के हिसाब से उपलब्ध करा सकें.
केस दिशा-निर्देश का इस्तेमाल करना	Privacy Sandbox APIs से, इस्तेमाल के किन उदाहरणों के बारे में साफ़ तौर पर बताया जाएगा.	प्राइवसी सैंडबॉक्स प्रोजेक्ट की शुरुआत में, डेवलपर दस्तावेज़ का मुख्य मकसद डेवलपर को सभी प्रस्तावों के लिए चर्चा और सुझाव, शिकायत या राय की प्रक्रिया में शामिल करना था. इसका मतलब था कि इस कॉन्टेंट से प्रोजेक्ट के पीछे की प्रेरणा और सिद्धांतों को समझा जा सकता है. इसके बाद, हर प्रस्ताव के शुरुआती डेवलपमेंट और टेस्टिंग की जानकारी की जानकारी दी जाएगी. यह प्रपोज़ल बनाने के लिए, नेटवर्क के साथ मिलकर काम करने में काफ़ी मददगार साबित हुआ. हालांकि, जैसे-जैसे एपीआई सामान्य रूप से उपलब्ध हुए, ऐसे नए डेवलपर मौजूद हैं जो मुख्य रूप से एपीआई बनाने के लिए तैयार हैं. हमने हाल ही में, Developers.google.google.com पर प्राइवसी सैंडबॉक्स की रिपोर्ट का इस्तेमाल करके, हाल ही में अपने संगठन के प्राइवसी सैंडबॉक्स की रिपोर्ट अपडेट की है. हम आने वाले समय में, दस्तावेज़ बनाने के लिए, केस-आधारित तरीके का इस्तेमाल करेंगे.
लोकल डेवलपमेंट एनवायरमेंट	अगर कुकी SameSite=Secure है और बैकएंड किसी CDN के ज़रिए हो, तो हम http://localhost पर स्थानीय रूप से अपने फ़्रंटएंड को डेवलप करना और टेस्ट करना कैसे जारी रखेंगे?	हम इस समस्या पर यहां चर्चा कर रहे हैं. साथ ही, नेटवर्क के अन्य सुझावों का भी स्वागत है.
3पीसीडी के प्रतिबंध को कम करना	क्या प्रोग्राम के हिसाब से यह पता करने का कोई तरीका है कि 3PC ब्लॉक हैं या अनुभव आधारित हैं या नहीं?	Chrome में, iframe में कॉल की गई सुविधा का पता लगाने और document.hasStorageAccess, दोनों का इस्तेमाल करके डेवलपर यह जान सकते हैं कि iframe के ऑरिजिन के पास 3PC का ऐक्सेस है या नहीं.
वीडियो टेस्टिंग	फ़िलहाल, प्राइवसी सैंडबॉक्स में वीडियो विज्ञापनों की जांच नहीं की जा सकती.	Chrome ने PA API की मदद से वीडियो बनाने के कई संभावित तरीकों पर चर्चा की. साथ ही, उन तरीकों के बारे में जानकारी दी (GitHub पर हमारे डेमो रिपॉज़िटरी में 242 और 254 देखें). ध्यान दें कि इन्हें सैंपल कोड के तौर पर नहीं बनाया गया है, ताकि विज्ञापन टेक्नोलॉजी थोक को अपनाएं. इसकी जगह, ऐसी तकनीकों के प्रमाण और प्रदर्शन के रूप में दी गई है जिनसे PA API के साथ VAST वीडियो रेंडरिंग में मदद मिल सके. इस चर्चा के दौरान, यह भी साफ़ हुआ है कि आज वीडियो रेंडरिंग भी संभव है, लेकिन Chrome में कुछ ऐसे बदलाव किए गए हैं जिनसे PA API को इस्तेमाल करना आसान हो जाएगा. उदाहरण के लिए, हम तीसरे पक्ष के विज्ञापन की पुष्टि करने वाले ब्रैंड सुरक्षा के इस्तेमाल के उदाहरणों के बारे में मिले सुझाव, शिकायत या राय के आधार पर, मैक्रो सब्सिटिट्यूशन (इसके बारे में यहां चर्चा की गई) के अपडेट के बारे में सोच रहे थे. ये अपडेट, वीडियो के इस्तेमाल के उदाहरण में फ़ीडबैक को भी शामिल करेंगे. यहां खरीदार, रेंडरिंग में किस विक्रेता मैक्रो का इस्तेमाल करना चाहता है. अब तक की ज़्यादातर बातचीत का फ़ोकस, VAST वीडियो विज्ञापनों को रेंडर करने पर रहा है. नेटिव विज्ञापन बनाने से उसी तरीके का इस्तेमाल किया जा सकता है और यह कई मायनों में आसान है. ऐसा लगता है कि वीडियो की तुलना में नेटिव उपयोगकर्ताओं पर कम ध्यान दिया जा रहा है, लेकिन यह सवाल सिर्फ़ विज्ञापन टेक्नोलॉजी उद्योग को प्राथमिकता देने का है, न कि इसे लागू करने में कोई तकनीकी रुकावट पैदा करने का.
विज्ञापनों के अलावा दूसरे तरीकों का मेज़रमेंट	3PCD से, विज्ञापनों से जुड़े ऑडियंस मेज़रमेंट के तरीकों पर असर पड़ सकता है.	मेज़रमेंट एपीआई के लिए यह ज़रूरी नहीं है कि इस्तेमाल के उदाहरण के लिए, विज्ञापन दिखाए जाएं. ARA, किसी सामान्य विज्ञापन दिखाने के मकसद से खास तौर पर काम करता है. वहीं, निजी तौर पर इकट्ठा करना एक सामान्य मकसद है. इन दो बिल्डिंग ब्लॉक का इस्तेमाल, मेज़रमेंट से जुड़ी कई गतिविधियों को मैनेज करने के लिए किया जा सकता है.
कॉन्टेंट क्रिएटर	प्राइवसी सैंडबॉक्स, कॉन्टेंट क्रिएटर्स को YouTube पर ज़्यादा और अपनी साइटों पर कम कॉन्टेंट बनाने के लिए बढ़ावा देता है.	प्राइवसी सैंडबॉक्स इनिशिएटिव का मुख्य मकसद, बिना किसी शुल्क के उपलब्ध इंटरनेट पर लोगों की गतिविधि को निजी बनाए रखना है. हम जानते हैं कि पब्लिशर, कॉन्टेंट बनाने और उसे ज़्यादा से ज़्यादा लोगों के लिए उपलब्ध कराने के लिए, विज्ञापनों पर भरोसा करते हैं. विज्ञापन देने वाले, लोगों को ऐसे नए प्रॉडक्ट या ऑफ़र खोजने में मदद करते हैं जो उनके काम के हो सकते हैं. प्राइवसी सैंडबॉक्स की सुविधाओं की मदद से, सभी तरह की वेबसाइटें ऐक्सेस की जा सकती हैं. इनमें, कॉन्टेंट क्रिएटर्स के साथ काम करने वाली वेबसाइटें भी शामिल हैं. इनकी मदद से, लोगों को अलग-अलग पक्षों के साथ उनकी गतिविधि के आधार पर, काम के विज्ञापन दिखाए जा सकते हैं. साथ ही, इन वेबसाइटों को उपयोगकर्ताओं की पहचान ज़ाहिर नहीं की जाती.
साफ़ तौर पर टाइमलाइन	प्राइवसी सैंडबॉक्स टेक्नोलॉजी के लिए, रिलीज़ के शेड्यूल ज़्यादा साफ़ और बेहतर.	Privacy Sandbox API के दस्तावेज़ में, एपीआई के स्टेटस और उपलब्धता की जानकारी वाले पेज शामिल होते हैं. इन पेजों पर, आने वाली सुविधाओं और उनकी टाइमलाइन की सूची होती है. उदाहरण के लिए, PA API, ARA. इन स्थितियों की एक खास जानकारी यहां दी गई है.
मशीन लर्निंग	विज्ञापन टेक्नोलॉजी, मशीन लर्निंग मॉडल को तब तक सही तरीके से ट्रेनिंग नहीं देतीं, जब तक कि 3PCD 1% से ज़्यादा नहीं हो जाता.	टेस्टिंग के लिए 3PCD को ज़्यादा ब्राउज़र में उपलब्ध कराने से, इस बात की गारंटी नहीं मिलती कि एपीआई का ज़्यादा इस्तेमाल होगा. यह अनुमान है कि विज्ञापन टेक्नोलॉजी को इस बात की ज़रूरत है, ताकि मशीन लर्निंग मॉडल को और बेहतर बनाया जा सके. अगर विज्ञापन टेक्नोलॉजी का इस्तेमाल बड़े पैमाने पर विज्ञापन टेक्नोलॉजी की मदद से, मशीन लर्निंग मॉडल को और बेहतर बनाने के लिए नहीं किया जाता, तो 3PCD को बड़ा करने की कोई ज़रूरत नहीं है. इसकी वजह यह है कि विज्ञापन टेक्नोलॉजी, मॉडल को ज़्यादा ट्रैफ़िक पर ट्रेनिंग देना चाहती है. ऐसा तब तक किया जा सकता है, जब तक Chrome इंस्टॉल करने की प्रोसेस खत्म होने से पहले 3PCD पर आगे नहीं बढ़ता.
इस्तेमाल का उदाहरण	डीएसपी से सेल्फ़-सर्विस वाले इस्तेमाल के उदाहरणों पर, फ़िलहाल विचार नहीं किया जा रहा है.	ऐसे कई सेल्फ़-सर्विस वाले DSP हैं, जो नियमित रूप से API के बारे में सार्वजनिक फ़ीडबैक देते हैं. नियमित रूप से लोगों को सुझाव देने वाले कई डीएसपी ने भी खुद को टेस्टर के तौर पर शामिल किया है. इसके अलावा, Chrome आम तौर पर सेल्फ़-सर्विस वाले DSP से जुड़े विषयों, जैसे कि वीडियो और तीसरे पक्ष के विज्ञापन सर्वर पर लगातार काम कर रहा है. हाल ही के, हर हफ़्ते के PA API कॉल में इन विषयों को कवर किया गया है.
ऑरिजिन ट्रायल	उन साइटों के लिए ओटी का अनुरोध जो 3PCD के लिए, ज़्यादा बेहतर रैंप अप और टेस्ट कवरेज की कामना कर रही हैं.	फ़िलहाल, Chrome पहले-पक्ष का ओटी डेवलप कर रहा है. इससे ऑरिजिन, 3PC फ़ेज़आउट बिहेवियर के लिए ऑप्ट-इन कर सकेंगे. इस ट्रायल के लिए रजिस्टर और टोकन डिप्लॉय करने वाले टॉप लेवल ऑरिजिन के 3PC ब्लॉक हो जाएंगे, क्योंकि उपयोगकर्ता के डिवाइस में ट्रैकिंग सुरक्षा की सुविधा चालू होती है. यह ओटी, साइटों को 3PC की तुलना में लंबे समय तक चलने वाले अलग-अलग विकल्पों की बड़े पैमाने पर टेस्टिंग करने का मौका देगा. इससे पहले कि सीएमए के साथ सलाह मिलने के बाद, 3पीसी के लिए यह चरण खत्म होने वाला है. हम अब भी ओटी को लॉन्च करने की टाइमलाइन तय करने पर काम कर रहे हैं.
IAB Tech Lab की रिपोर्ट	IAB Tech Lab रिपोर्ट से, प्राइवसी सैंडबॉक्स के बारे में सुझाव/राय या शिकायत मिली.	हमने IAB Tech Lab की रिपोर्ट के बारे में यहां ज़्यादा जानकारी के साथ जवाब दिया है. हमने यह भी स्वीकार किया है कि "रिपोर्ट में फ़्रैगमेंट दस्तावेज़, व्यावसायिक ज़रूरतें, तीसरे पक्ष के ऑडिट, इंडस्ट्री की मान्यता, बढ़ाए जा सकने की योग्यता, पारदर्शिता, और आने वाले समय में लागू होने वाले गवर्नेंस से जुड़े सवाल हैं. इसके आधार पर हम नेटवर्क से जुड़े रहेंगे और हमारे सार्वजनिक अक्सर पूछे जाने वाले सवालों को उसी हिसाब से अपडेट करेंगे." हम फ़्रैगमेंट वाले दस्तावेज़ पहले ही ठीक कर चुके हैं. हम यहां "डेटा की गारंटी" के तहत, व्यावसायिक ज़रूरी शर्तों के बारे में बताते हैं. साथ ही, Google विज्ञापन के कुछ प्रॉडक्ट ने अपने तरीके शेयर किए हैं. हम यहां "एल्गोरिदम इंटिग्रिटी गारंटी" के तहत, तीसरे पक्ष के ऑडिट की समस्याओं को हल करते हैं. मान्यता के मामले में, हम उम्मीद करते हैं कि वे संस्थाएं, टेक्नोलॉजी के बजाय, अन्य प्रॉडक्ट को मान्यता देती रहेंगी. इनमें टेक्नोलॉजी का इस्तेमाल भी शामिल है. बढ़ाए जा सकने की योग्यता को ध्यान में रखते हुए, हम उन डेवलपर से मिलने वाले डेटा के लिए हमेशा तैयार रहते हैं जिनमें समस्याएं दिखी हैं. पारदर्शिता और मैनेजमेंट के लिए, हम GitHub पर और W3C जैसे फ़ोरम पर, डेटा शेयर करने के तरीकों पर लगातार काम कर रहे हैं. साथ ही, कमिटमेंट के तहत सीएमए के साथ मिलकर काम कर रहे हैं.
Google साइन-इन	Google में साइन इन करने से इस बात की संभावना बढ़ जाती है कि Google, तय की गई शर्तों के उलट, दूसरी पहचानों वाले लॉग-इन डेटा का इस्तेमाल करे.	'Google साइन-इन' की मदद से Google, तय किए गए नियमों के उलट डेटा इस्तेमाल कर सकता है.
इनके साथ काम करता है	प्राइवसी सैंडबॉक्स एपीआई के साथ काम करने और फ़ॉरवर्ड / पिछले वर्शन के साथ काम करने के क्या प्लान हैं?	Chrome के किसी सुविधा को सामान्य रूप से उपलब्ध कराने के लिए लॉन्च करने के बाद, हमारा मकसद उस सुविधा के लिए सहायता बनाए रखना होता है. हालांकि, पुराने सिस्टम के साथ काम करने की सुविधा को बनाए रखना हमेशा मुमकिन नहीं होता. ऐसे मामलों में, हमारे पास मौजूदा सुविधाओं को बंद करने और उन्हें हटाने की साफ़ प्रोसेस है, जिसके बारे में यहां बताया गया है. हम समय के साथ प्राइवसी सैंडबॉक्स एपीआई में और सुविधाएं जोड़ते रहेंगे. हमें उम्मीद है कि हम समय के साथ प्राइवसी सैंडबॉक्स के एपीआई में और सुविधाएं जोड़ते रहेंगे. इनका इस्तेमाल, बेहतर सहायता से फ़ायदा मिलने पर किया जाएगा. हम ऐसे मामलों में, सुविधा का पता लगाने की तकनीक को शामिल करते हैं, ताकि नई सुविधा के साथ प्रयोग करने में दिलचस्पी रखने वाली विज्ञापन टेक्नोलॉजी, ब्राउज़र से सीधे पूछ सके कि यह सुविधा काम करती है या नहीं. Chrome के किसी खास वर्शन नंबर की जांच करने के लिए, डेवलपर से अनुरोध करने से बेहतर है. ऐसा इसलिए, क्योंकि हो सकता है कि कुछ सुविधाएं एक साथ Chrome के सभी उपयोगकर्ताओं के लिए रोल आउट न की जाएं. उदाहरण के लिए, PA API के लिए उपलब्ध सुविधा की पहचान करने का काम यहां देखा जा सकता है.
सर्वर को लागू करना	अपनी प्रोसेस को लागू करने के बजाय, Chrome को उन व्यवहार के बारे में बताना चाहिए जो किसी भरोसेमंद सिग्नल सर्वर, एग्रीगेशन सर्वर, और बिना ब्राउज़र वाले किसी भी दूसरे ज़रूरी कॉम्पोनेंट के लागू करने के तरीके के मुताबिक होने चाहिए. यह स्वीकार किए जाने वाले निजता सीमाओं के भीतर इनोवेशन को बढ़ावा देगा.	हम बाहरी पक्षों की इनोवेशन की इच्छा की सराहना करते हैं और उसका स्वागत करते हैं. सभी एपीआई और सेवाओं के लिए, हमारा मकसद विज्ञापन टेक्नोलॉजी से जुड़ी ऐसी सुविधाएं उपलब्ध कराना है जिनकी मदद से वे अपनी सुविधाओं को बेहतर तरीके से लागू कर सकें. उदाहरण के लिए, हम विज्ञापन टेक्नोलॉजी को नीलामी के लिए बिडिंग का लॉजिक डिज़ाइन करने के लिए, कारोबार की गोपनीय जानकारी का इस्तेमाल करने की अनुमति देते हैं. इसके अलावा, हम विज्ञापन टेक्नोलॉजी से मिलने वाले सुझावों पर लगातार काम करते हैं और ज़रूरत पड़ने पर उन्हें अपने डिज़ाइन में शामिल करते हैं. भरोसेमंद एक्ज़ीक्यूशन एनवायरमेंट में अन्य लोग अपना कोड चला सकें, इसके लिए प्राइवसी सैंडबॉक्स को कोड और उससे जुड़े सभी बदलावों की समीक्षा करनी होगी, ताकि यह पक्का किया जा सके कि वह निजता की गारंटी का पालन करता है. इसके लिए, प्राइवसी सैंडबॉक्स की टीम को काफ़ी मेहनत करनी पड़ेगी. इसलिए, हम जानना चाहते हैं कि हिस्सेदार किन फ़ायदों को पाना चाहता है, जो आज हमें नहीं मिल पा रहे हैं.
अनुमान के बारे में जानकारी	अनुमान के हिसाब से लंबे समय के लिए कौनसे प्लान का इस्तेमाल किया जा सकता है?	दूसरे ब्राउज़र के मुताबिक, हम इन अनुमानित तरीकों को बंद कर देते हैं, क्योंकि आने वाले समय में ये वैकल्पिक समाधानों का ज़्यादा इस्तेमाल किया जाता है. साथ ही, आगे संभाव्यता के विश्लेषण की ज़रूरत पड़ती है. हमने इसे यहां शेयर किया है.
टेस्टिंग वॉल्यूम	अलग-अलग डाइमेंशन की तुलना करते समय, ट्रैफ़िक की अलग-अलग संख्या.	1% एक्सपेरिमेंट में एक्सक्लूज़न की ज़रूरी शर्तें मौजूद हैं. इस वजह से, Chrome के अलग-अलग उपयोगकर्ताओं को एक्सपेरिमेंट के लिए मंज़ूरी मिलने में अंतर हो सकता है. उदाहरण के लिए, एक्सपेरिमेंट में Chrome Enterprise के उपयोगकर्ताओं को शामिल नहीं किया जाता. इसलिए, हो सकता है कि वीकेंड में, एक्सपेरिमेंट लेबल वाले ट्रैफ़िक का प्रतिशत ज़्यादा हो. आपको डेटा के अलग-अलग हिस्सों (जैसे, भौगोलिक, तारीख, और प्लैटफ़ॉर्म) में ट्रैफ़िक का अलग-अलग प्रतिशत दिख सकता है. यह संख्या, Chrome के डेटा के हिसाब से है.
3PC को मैन्युअल तरीके से फिर से चालू करें	क्या साइटों को यह जानने में मदद मिलेगी कि 3PCD लागू होने के बाद, कितने उपयोगकर्ताओं (%) ने मैन्युअल तौर पर कुकी को दोबारा चालू किया है?	अगर उपयोगकर्ताओं को समस्या आती है, तो वे यूज़र बायपास के ज़रिए साइट लेवल पर 3PC ऐक्सेस को फिर से चालू कर पाएंगे. स्टोरेज ऐक्सेस एपीआई जैसे अन्य तरीकों की मदद से भी 3PC को फिर से चालू किया जा सकता है. hasStorageAccess() जैसे तकनीकी उपाय, जिनसे साइटों को यह पता लगाने की अनुमति मिलती है कि 3PC चालू हैं या बंद. हालांकि, Chrome वेबसाइटों को फिर से चालू किए जाने की वजहों के बारे में जानने का तरीका उपलब्ध नहीं कराएगा.
ट्रैकिंग सुरक्षा	Chrome की ट्रैकिंग सुरक्षा यूज़र इंटरफ़ेस (यूआई) की सुविधा कब तक उपलब्ध रहेगी?	3PC के बंद होने के बाद भी, पता बार में ट्रैकिंग सुरक्षा यूज़र इंटरफ़ेस (यूआई) उपलब्ध रहने की उम्मीद है.
(पिछली तिमाहियों में भी रिपोर्ट की गई) क्रॉस-ब्राउज़र सहायता	प्राइवसी सैंडबॉक्स एपीआई का इस्तेमाल करने वाले अन्य ब्राउज़र वेंडर.	Apple, Mozilla, और Microsoft जैसे ब्राउज़र वेंडर, सार्वजनिक फ़ोरम पर सक्रिय हैं. वहां निजता के सिद्धांतों और ब्राउज़र पर आधारित तरीकों पर चर्चा की जा रही है. हाल ही में हुई W3C की सालाना TPAC मीटिंग और W3C PATCG फ़ोरम जैसे फ़ोरम में, साथ मिलकर काम करने से हमें बहुत खुशी हुई. उदाहरण के लिए, Microsoft Edge ने हाल ही में अपने प्लान का एलान किया है, जिसका मकसद PA API और ARA के साथ "वाक्यों के साथ काम करने की क्षमता को बेहतर करना" है. साथ ही, डेवलपर के लिए अतिरिक्त सुविधाएं भी ऑफ़र की गई हैं.
3PCD के बाद, काम न करने वाले एम्बेड के लिए फ़ॉलबैक का विकल्प	एपीआई हुक उपलब्ध कराएं, ताकि यह पता लगाया जा सके कि तीसरे पक्ष का iframe / एम्बेड, 3PCD का पालन करता है या नहीं.	हम इस अनुरोध के बारे में यहां चर्चा कर रहे हैं. साथ ही, नेटवर्क से मिले सुझावों का भी स्वागत है.
टेस्ट करना	Chrome के मैनेज किए गए इंस्टेंस में ज़्यादा फ़्लैग के लिए अनुरोध करें, जो आपके हिसाब से किए गए व्यवहार को कुछ समय के लिए बंद कर देते हैं.	हम Chrome के मैनेज किए जा रहे इंस्टेंस के लिए इस अनुरोध पर विचार कर रहे हैं. साथ ही, अगर ऐसा फ़्लैग उपयोगी साबित हो सकता है, तो हम नेटवर्क से अतिरिक्त इनपुट का स्वागत करते हैं.

रजिस्ट्रेशन और प्रमाणित करना

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
प्रमाणित करने की पुष्टि	Google यह कैसे पक्का करेगा कि प्रमाणित किए गए दस्तावेज़ सही हैं?	सभी रजिस्ट्रेंट को एपीआई इस्तेमाल करते समय, प्रमाणित करने वाली फ़ाइल को अपने हिसाब से रखना होगा. Google इस बात की पुष्टि करता है कि फ़ाइल सही जगह पर है और सिंटैक्स सही है. हालांकि, Google, पुष्टि करने की भाषा के हिसाब से विज्ञापन टेक्नोलॉजी के काम करने के तरीके की पुष्टि नहीं करता.
निजी एग्रीगेशन एपीआई रजिस्टर करने की प्रक्रिया	क्या Private एग्रीगेशन एपीआई के रजिस्ट्रेशन की स्थिति जांचने का कोई तरीका है?	नाम रजिस्टर होने की पुष्टि होने के बाद, जिन लोगों को रजिस्टर करने की अनुमति मिल जाती है उन्हें रजिस्ट्रेशन की सहायता टीम से ईमेल के ज़रिए सूचना दी जाती है. अगर इस प्रक्रिया के दौरान रजिस्ट्रेंट को कुछ पूछना है, तो वे सहायता टीम से संपर्क कर सकते हैं. सहायता टीम, रजिस्ट्रेशन फ़ॉर्म सबमिट करने पर उनसे संपर्क करती है. सहायता टीम जवाब देगी और सवालों के जवाब देगी. साथ ही, ज़रूरत पड़ने पर कोई और मदद भी करेगी.

काम का कॉन्टेंट और विज्ञापन दिखाएं

विषय

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
(पिछली तिमाहियों में भी रिपोर्ट की गई) क्लासिफ़ायर की टाइमलाइन और दस्तावेज़	कैटगरी तय करने के मोड की समीक्षा के लिए या कैटगरी तय करने के तरीके के बारे में कम से कम अतिरिक्त पारदर्शिता ज़रूर होनी चाहिए.	हमारे जवाब में पिछली तिमाही के मुकाबले कोई बदलाव नहीं हुआ है: "साइटों का गलत वर्गीकरण, सिग्नल के तौर पर दिखाए गए सिग्नल के लिए थोड़ा कम उपयोगी हो सकता है. हालांकि, जो साइटें गलत कैटगरी में आती हैं उन पर दूसरी साइटों के मुकाबले कोई ज़्यादा नुकसान नहीं होता. ऐसा इसलिए है, क्योंकि किसी साइट की प्रासंगिक जानकारी उनकी साइट पर नीलामी के लिए हमेशा उपलब्ध रहेगी. इससे, गलत वर्गीकरण होने पर भी सही विषय के साथ तुलना करने वाली जानकारी मिलेगी. हम इस विषय पर आपके सुझाव, शिकायत या राय का यहां स्वागत करते हैं."
Google Ad Manager	Google Ad Manager को ज़्यादातर साइटों पर पहले से ही एम्बेड किया गया है. इसमें, कम साइटों पर मौजूद प्रतिस्पर्धियों की तुलना में, उपयोगकर्ताओं के विषयों की ज़्यादा जानकारी होगी.	निगरानी से जुड़ी ज़रूरी शर्त यह पक्का करती है कि Topics API से, उपयोगकर्ता का डेटा, एपीआई की जगह ले रही टेक्नोलॉजी (इनमें 3PC शामिल हैं) से ज़्यादा इकाइयों के साथ शेयर न करे. Prebid जैसे अन्य उद्योग समाधान 10,000 साइटों के साथ काम करते हैं और बाज़ार में हिस्सा लेने वाले लोगों को अपनी टेक्नोलॉजी की मदद से Topics API को कॉल करने की सुविधा देते हैं. इसके अलावा, यह ध्यान देने वाली बात है कि हर हफ़्ते ज़्यादा से ज़्यादा पांच लोकप्रिय विषयों को शामिल करने का बराबरी का असर हो सकता है, क्योंकि कई साइटों पर मौजूद बाज़ार में हिस्सा लेने वाले लोग 3PC का इस्तेमाल करके पांच से ज़्यादा विषय सीख सकते हैं.
(पिछली तिमाहियों में भी रिपोर्ट की गई है) अलग-अलग तरह के हिस्सेदारों के लिए उपयोगिता	साइटों के ट्रैफ़िक के लेवल या उनके कॉन्टेंट के खास होने के आधार पर, साइटों के लिए उस वैल्यू को बनाने और उसके डिस्ट्रिब्यूशन को लेकर चिंता.	हम मानते हैं कि सामान्य रुचि वाले डोमेन की तुलना में, खास साइटें ज़्यादा जानकारी देती हैं. हालांकि, सभी विशेषज्ञ साइटें व्यावसायिक रूप से अहम विषयों का योगदान नहीं देतीं. साथ ही, यह डायनामिक स्थिति को दर्शाता है और Chrome में 3PC के लिए समर्थन की समाप्ति से पूरी तरह से स्वतंत्र है. साथ ही, मौजूदा माहौल में कुछ साइटें अन्य के मुकाबले 3PC आधारित विज्ञापन प्रासंगिकता सिस्टम के मुकाबले ज़्यादा फ़ायदेमंद साबित होती हैं. इसके अलावा, अलग-अलग तरह की साइटों से जुड़े विषय एक-दूसरे के लिए फ़ायदेमंद हो सकते हैं. इसकी वजह यह है कि विज्ञापन देने वाले अलग-अलग तरह के विषयों पर कैंपेन चला सकते हैं. साथ ही, बिडिंग के लॉजिक की मदद से अलग-अलग विषयों की अहमियत को समझा जा सकता है.
होस्टनाम बनाम पूरे यूआरएल	क्या वेबसाइटों के होस्टनेम के हिसाब से डेटा को अलग-अलग कैटगरी में बांटने की सुविधा काफ़ी असरदार है और क्या पूरे यूआरएल की तुलना में, निजता से जुड़े जोखिम को कम किया जाता है?	हमने होस्टनेम के साथ-साथ, जानकारी वाले यूआरएल या पेज के टाइटल का इस्तेमाल करने के बारे में सोचा. साथ ही, यह तय किया कि इससे मिलने वाले संभावित फ़ायदों पर, उपयोगकर्ता की निजता और सुरक्षा से जुड़े जोखिमों की वजह से ज़्यादा असर पड़ेगा. उपयोगकर्ता की निजता से जुड़े जोखिमों के एक उदाहरण में, उपयोगकर्ता के विषयों में मौजूद यूआरएल या पेज के टाइटल में शामिल संवेदनशील जानकारी का वर्गीकरण शामिल है.
सिग्नल के तौर पर विषय	विषयों को दूसरे सिग्नल के साथ जोड़ने के तरीके और दूसरे सिग्नल से क्या काम आ सकता है, इसके बारे में जानने के लिए अनुरोध करें.	विज्ञापन टेक्नोलॉजी से जुड़ी सुविधाओं की मदद से, सबसे अच्छे नतीजे पाए जा सकते हैं. इसके लिए, ये सभी उपलब्ध टूल का इस्तेमाल कर सकते हैं. जैसे, मशीन लर्निंग और निजता बनाए रखने वाले एपीआई के उपयोगकर्ता की निजता को बनाए रखने वाले सिग्नल. साथ ही, काम का डेटा, क्रिएटिव डेटा, और पहले पक्ष (ग्राहक) का डेटा. इस बारे में और दिशा-निर्देश यहां उपलब्ध हैं.

Protected Audience API (पहले इसका नाम FLEDGE था)

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
ट्रैफ़िक वॉल्यूम की जांच करें	टेस्टर, PA API नीलामी के लिए बिड रिस्पॉन्स के कम वॉल्यूम की रिपोर्ट कर रहे हैं.	1. बिड डेंसिटी, पीए एपीआई में नेटवर्क की भागीदारी से जुड़ी है. हमें उम्मीद है कि यह 2024 और उसके बाद भी बढ़ती रहेगी. यह फ़ैसला विज्ञापन देने वालों, उनकी एजेंसियों, और टेक्नोलॉजी से जुड़ी सेवा देने वाली कंपनियों पर निर्भर करता है कि कैंपेन के लिए बजट कैसे तय किया जाए. हमें उम्मीद है कि नेटवर्क में शामिल कुछ लोग, बिना कुकी वाले कई तरह के समाधानों में अपने निवेश को 3PCD (3PCD) तक के लिए टाल सकते हैं. इनमें PA API भी शामिल है. हमें उम्मीद है कि उस समय वे इन समाधानों के लिए, अपने कैंपेन के बजट को बढ़ा सकते हैं. 2. PA API नीलामियों में बिड रिक्वेस्ट की संख्या पर इन चीज़ों का असर पड़ सकता है (1). इस वजह से, पब्लिशर और विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली कंपनियां, मांग कम होने पर PA API नीलामी शुरू न करने का फ़ैसला ले सकती हैं. यह पब्लिशर पर निर्भर करता है कि वे अपने पेजों को अपडेट करने की प्राथमिकता तय करते हैं या नहीं. हमारा अनुमान है कि इन वजहों से पब्लिशर के लिए, ट्रैफ़िक की जांच करने और उसे धीरे-धीरे बढ़ाना पड़ सकता है. इस रिपोर्ट में, Google Ad Manager से मिला जवाब भी शामिल है. इसमें यह जानकारी दी गई है कि PA API में हिस्सा लेने के लिए, पब्लिशर के कंट्रोल क्या हैं.
(पिछली तिमाहियों में भी शिकायत की गई है) धोखाधड़ी या गलत इस्तेमाल	नेटवर्क, सुरक्षा से जुड़े जोखिमों को कैसे कम कर सकता है और बुरे मकसद से काम करने वाले लोगों या खरीदारों को, सही ऑडियंस के तौर पर अपनी पहचान बनाने से कैसे रोक सकता है?	PA API विज्ञापनों की शिकायत करने के तरीके, उस जानकारी को बनाए रखते हैं जिसका इस्तेमाल, लोगों और बॉट ट्रैफ़िक से अलग करने के लिए किया जाता है. इसके अलावा, PA API में डोमेन शामिल करने या बाहर रखने की मौजूदा डोमेन-आधारित तकनीकों का इस्तेमाल किया जा सकता है. प्राइवसी सैंडबॉक्स से जुड़ी IAB टेक लैब की रिपोर्ट के हमारे जवाब में, इस बारे में ज़्यादा जानकारी दी गई है.
आईजी के मालिक और बिडिंग लॉजिक के यूआरएल पर, एक ही ऑरिजिन से जुड़ी पाबंदी	एक जैसे ऑरिजिन की ज़रूरी शर्त के तहत, आईजी खाते के मालिक के एंडपॉइंट को, एक ही लोड बैलेंसर से गुज़रना होगा. इस वजह से, रीडायरेक्ट अस्वीकार किए जा सकते हैं.	स्क्रिप्ट लोड करने के लिए, एक ही ऑरिजिन से जुड़ी सुरक्षा एक अहम सुरक्षा सुविधा है. प्रस्तावित समाधान के बारे में कुछ जानकारी दी गई है, जो यहां नेटवर्क के फ़ीडबैक और दूसरी ज़रूरी बातों के बीच संतुलन बनाता है.
मल्टी-स्लॉट निजी नीलामी	निजता की सीमा को ध्यान में रखते हुए, मल्टी-स्लॉट वाली निजी नीलामी को अनुमति देने के लिए, आपके पास काफ़ी मौके हैं. इसके लिए, विज्ञापन देने के मौजूदा तरीकों में ग़ैर-ज़रूरी आवाज़ों का इस्तेमाल करके, इन्हें और भी बेहतर तरीके से इंटिग्रेट करना होगा.	हम इस सुझाव पर विचार कर रहे हैं. साथ ही, कई टैग वाली नीलामियों के अनुरोध की समीक्षा कर रहे हैं, ताकि इस सुविधा से जुड़े डेटा की जटिलता और निजता से जुड़े खतरों में बढ़ोतरी हो सके. हमने PA API Web Incubator कम्यूनिटी ग्रुप (डब्ल्यूआईसीजी) के साथ यहां कॉल के दौरान इस समस्या के बारे में और बातचीत की थी.
टॉप-लेवल के विक्रेता	PA API के मौजूदा स्ट्रक्चर से, टॉप लेवल के किसी सेलर को पब्लिशर या कॉम्पोनेंट सेलर की तुलना में, ज़्यादा डेटा और इंप्रेशन की वैल्यू की बेहतर जानकारी मिलती है.	एक से ज़्यादा सेलर वाली नीलामी में, हर सेलर की बिड सबसे अच्छी होगी. इसके अलावा, हमने उस नेटवर्क से सीख लिया है जिसके साथ पब्लिशर काम करते समय, हर सेलर की सबसे अच्छी बिड के साथ-साथ, सीधे तौर पर बेचे जाने वाले प्रॉडक्ट की मांग पर विचार करना चाहते हैं. कौनसा विज्ञापन दिखाया जाना चाहिए, यह तय करने के लिए कमाई करने के इन सभी संभावित अवसरों को देखना ज़रूरी है. इस मामले में, जब कुछ कलाकारों को विज्ञापन दिखाने के लिए सभी विकल्पों को देखना ज़रूरी होता है, तब PA API को पहले से ही अपडेट कर दिया जाता है. PA API, मल्टी-सेलर नीलामियों और पब्लिशर की यह इच्छा रखने के लिए काम करता है कि वे सीधे तौर पर बेचे जाने वाले विज्ञापन कैंपेन के बगल में, हर सेलर की सबसे अच्छी बिड पर विचार करें, जहां बाद में भी बिड लागू हो. इसका मतलब है कि कमाई करने के उन अवसरों में से किसी एक को चुनने का तरीका होना चाहिए जो आज के समय में उपलब्ध हैं. हमें नहीं लगता कि दिखाया जाने वाला विज्ञापन चुनने के लिए, ब्राउज़र की भूमिका होनी चाहिए. इसलिए, कई संभावनाओं में से किसी अच्छे विज्ञापन को चुनने के लिए, टॉप लेवल सेलर का कॉन्सेप्ट दिखाना ज़रूरी है. उस टॉप-लेवल सेलर का लॉजिक, हर उस सेलर के लिए सबसे अच्छी बिड के बारे में सोच सकता है जिसके साथ पब्लिशर काम करता है. साथ ही, उस विक्रेता का लॉजिक, पब्लिशर के सीधे तौर पर बेचे जाने वाले कैंपेन के बारे में जानकारी उपलब्ध कराने का विकल्प चुन सकता है. इस पूरी जानकारी को विज्ञापन चुनने के टॉप लेवल के लॉजिक में शामिल किया जा सकता है. इसका मतलब है कि टॉप लेवल लॉजिक, पीए एपीआई नीलामी की सबसे अच्छी बिड और जहां लागू हो वहां विजेता का पता लगाने के लिए, पब्लिशर की ओर से सीधे तौर पर बेचे जाने वाले विज्ञापन के विकल्प देखता है. Google Ad Manager इस रिपोर्ट में "जानकारी का ऐक्सेस" थीम के तहत, टॉप लेवल सेलर के तौर पर PA API को लागू करने के बारे में जानकारी देता है.
कॉम्पटिटिव विज्ञापन को अलग करना	दूसरे ब्रैंड के विज्ञापनों को अलग-अलग दिखाने का अनुरोध करना. जैसे, आपके जैसे दूसरे ब्रैंड के विज्ञापनों को एक-दूसरे के बगल में दिखने से रोकना.	हमें यह पता नहीं है कि आज के प्रोग्राम के हिसाब से, बिडिंग वाले, एक से ज़्यादा सेलर वाले डिजिटल विज्ञापन नेटवर्क में कॉम्पटिटिव अलग-अलग तरीके अपनाए जा सकते हैं. हालांकि, PA API, सेलर को ऐसे रेंडर यूआरएल और होस्टनेम (जो पब्लिशर के डोमेन को दिखाता है) के कॉम्बिनेशन के आधार पर, अतिरिक्त रीयल-टाइम सिग्नल फ़ेच करने में मदद करता है. इनका इस्तेमाल क्रिएटिव स्कोर करने के लिए ScoreAd() के दौरान किया जा सकता है. सेलर इसका इस्तेमाल, प्रतिस्पर्धी ब्रैंड के विज्ञापनों को एक-दूसरे के बगल में दिखाने से रोकने के लिए कर सकते हैं. ऐसा तब किया जाता है, जब पब्लिशर इस नियम को लागू करना चाहता है.
सीमित जानकारी	PA API, पब्लिशर के लिए उपलब्ध जानकारी को कम करता है. जैसे, विज्ञापन की वैल्यू, कॉम्पोनेंट के खरीदार का नाम, विज्ञापन देने वाले का नाम, लैंडिंग पेज यूआरएल, क्रिएटिव का साइज़, जवाब देने में लगने वाला समय, और बिड रेट. साथ ही, यह बिड में होने वाली कमी को भी कम करती है.	हमने कुछ संभावित समाधानों के बारे में यहां बताया है. हमें नेटवर्क से अन्य सुझावों का भी स्वागत है.
इवेंट-लेवल रिपोर्टिंग	इवेंट-लेवल रिपोर्टिंग PA API के बंद होने के बाद, पब्लिशर को विज्ञापन के बारे में पूरी जानकारी नहीं मिल पाती.	हम रिपोर्टिंग के इस्तेमाल के अलग-अलग उदाहरणों के बारे में जानते हैं. इवेंट-लेवल पर रिपोर्टिंग की सुविधा बंद होने के बाद भी, हमें अपना काम जारी रखना होगा. इसलिए, हमने इवेंट-लेवल रिपोर्टिंग को बंद करने की तारीख 2026 से पहले की तारीख पर सेट की है. अभी से लेकर तब के बीच, हम ईकोसिस्टम के साथ जुड़ने के लिए, लंबे समय तक चलने वाले तरीकों पर काम कर रहे हैं. इस दौरान, हम निजता की सुरक्षा के लिए, जानकारी हासिल करने के नए आइडिया भी दे सकते हैं.
एक से ज़्यादा SSP	एक से ज़्यादा एसएसपी होने की वजह से, पब्लिशर के लिए वैल्यू बहुत कम हो जाएगी.	हम इसे सही नहीं मानते. इस दावे की वजह को समझने के लिए, नेटवर्क से और सुझाव, शिकायत या राय मांगी जा सकती है.
क्यूरेशन गतिविधियां	PA API के साथ क्यूरेशन गतिविधियां संभव नहीं हैं.	हमें इस बारे में फ़ीडबैक मिले हैं कि क्या विक्रेता PA API का इस्तेमाल कर सकते हैं, ताकि वे वेब पर मौजूद खरीदारों को ऑडियंस की जानकारी दे सकें (यानी कि ऑडियंस एक्सटेंशन). हमारा मानना है कि फ़िलहाल ऐसा किया जा सकता है. इसके लिए, हम कारोबार के समझौतों के साथ-साथ पीए के क्रेडेंशियल असाइन करने की सुविधा का इस्तेमाल करते हैं. साथ-साथ, हम इस पर सक्रियता से विचार कर रहे हैं कि क्या हम इस तरह के इस्तेमाल के मामलों में बेहतर सुविधाएं दे सकते हैं या नहीं.
खरीदार ऑप्ट-आउट	खरीदार के लिए, डिफ़ॉल्ट तौर पर ऑप्ट-आउट करने से, कॉम्पोनेंट नीलामियों के नतीजे कम हो सकते हैं.	किसी एक सेलर या एक से ज़्यादा सेलर वाली पीए नीलामी के बारे में, सेलर को नीलामी के लिए कॉन्फ़िगर किए गए formatGroupBuyers फ़ील्ड में, खरीदारों की सूची साफ़ तौर पर देनी होगी. यह नेटवर्क से मिले सुझाव के आधार पर है. इसमें बताया गया है कि सेलर ने कुछ खरीदारों के साथ कानूनी समझौते किए हैं और कुछ के साथ नहीं. इसलिए, हमें इस बात का साफ़ तौर पर कंट्रोल चाहिए होगा कि नीलामी में कौनसे खरीदारों को शामिल किया जाए. GitHub पर हम आगे बातचीत का स्वागत करते हैं.
विज्ञापन बनाएं	adsize और adSlotSize के आधार पर प्री-फ़िल्टर नहीं किया जा सका.	हम इस सुविधा को जोड़ने पर काम कर रहे हैं. इसके बारे में ज़्यादा जानकारी यहां उपलब्ध है.
नेगेटिव आईजी टारगेटिंग के लिए सहायता	नेगेटिव आईजी टारगेटिंग के साथ काम करने वाला एपीआई: विज्ञापन सिर्फ़ तब दिखाना, जब कोई उपयोगकर्ता किसी आईजी से जुड़ा न हो.	GitHub की इस समस्या में, नेगेटिव टारगेटिंग को लागू करने का एक अन्य तरीका पेश किया गया है. इसमें ब्राउज़र सीधे विज्ञापन सर्वर को बताता है कि किसी खास विज्ञापन अनुरोध के लिए कौनसे नेगेटिव टारगेटिंग नियम लागू होने चाहिए. यह तरीका दिलचस्प लग रहा है. हालांकि, हमने जिन आइडिया की जांच की है उनके सभी वर्शन सामने आए, ताकि सर्वर अलग से उपयोगकर्ता की पहचान कर सके.
डिजिटल सर्विसेज़ ऐक्ट	कोई पब्लिशर, फ़ेंस किए गए फ़्रेम का इस्तेमाल करके, डिजिटल सर्विसेज़ ऐक्ट के तहत आने वाली जानकारी वाले जवाबों को रेंडर होने से कैसे रोक सकता है?	किसी भी नई टेक्नोलॉजी की तरह, हर कंपनी यह पक्का करने के लिए ज़िम्मेदार होती है कि प्राइवसी सैंडबॉक्स का इस्तेमाल कानून के मुताबिक हो. Google दूसरों को कानूनी सलाह नहीं दे सकता. हर एक एपीआई के लिए, हमने व्यापक तकनीकी दस्तावेज़ प्रकाशित किए हैं, जिन्हें ज़रूरी कानूनी आकलन करने के लिए आधार मिलना चाहिए. साल 2026 से पहले, पीए एपीआई में फ़ेंस्ड फ़्रेम इस्तेमाल करने की ज़रूरत नहीं है. इससे हिस्सेदारों को और समय मिलेगा, ताकि वे यह पक्का कर सकें कि वे इस टेक्नोलॉजी का इस्तेमाल, सभी ज़रूरी कानून के मुताबिक कर रहे हैं.
दस्तावेज़	क्या अपडेटAdInterestGroups() अस्थायी है?	हमने अपडेटAdInterestGroup को बंद करने के किसी प्लान का एलान नहीं किया है. आने वाले समय में, हम इसी तरह की निजता सुरक्षा लागू कर सकते हैं, जैसा कि हमने दूसरे IG अपडेट तरीकों के बारे में सार्वजनिक तौर पर बात की है. उदाहरण के लिए, आईपी पते का इस्तेमाल करके प्रॉक्सी का इस्तेमाल करना और अपडेट होने से पहले कुछ देरी करना.
डीएसपी से बाहर के लोगों के लिए, बायसाइड मेटाडेटा और लॉजिक के मालिकाना हक के लिए सहायता	DSP के लिए प्रॉक्सी के तौर पर काम करने के तरीके का अनुरोध करें.	हमें गैर-डीएसपी सेगमेंट के इस सुझाव के बारे में पता है और हम इस अनुरोध पर विचार कर रहे हैं. हम नेटवर्क से अतिरिक्त सुझाव, शिकायत या राय का स्वागत करते हैं.
रिपोर्ट करना	निजी एग्रीगेशन रिपोर्टिंग में, सिग्नल बकेट / वैल्यू के लिए कस्टम हैंडलर की सुविधा जोड़ने का अनुरोध करें.	हमें इस बात की जानकारी है और इस सुविधा का अनुरोध आगे की खोज के लिए सूची में है. हम यहां नेटवर्क से अतिरिक्त फ़ीडबैक का स्वागत करते हैं.
दस्तावेज़	क्या कोई ऐसा लिंक है जहां उन सभी रिस्पॉन्स हेडर को देखा जा सकता हो जिन्हें विज्ञापन देने वाले और (वह व्यक्ति जिसे प्रॉपर्टी का मालिकाना हक सौंपा गया है) को सेट करने की ज़रूरत होती है?	इसे साफ़ तौर पर बताने और नेटवर्क से हमें अन्य सुझाव मिलने के लिए, हम दस्तावेज़ में बदलाव करने का प्लान बना रहे हैं.
मल्टी-टावर बिडिंग	पीए एपीआई के संदर्भ में एक से ज़्यादा टावर बनाने की सोच कैसे बनाई जाती है, इस बारे में आर्किटेक्चर / ब्लॉक डायग्राम की मदद से वर्कफ़्लो (ट्रेनिंग और अनुमान) की जानकारी का अनुरोध करें.	शिकायत करने या सुझाव/राय देने के लिए धन्यवाद. हमारे पास इस विषय पर कुछ प्रज़ेंटेशन हैं. इन प्रज़ेंटेशन से हम अतिरिक्त दस्तावेज़ तैयार कर सकते हैं.
नेगेटिव टारगेटिंग	संवेदनशील दर्शकों और नाबालिगों को आपत्तिजनक विज्ञापनों से सुरक्षित रखने के लिए, प्राइवसी सैंडबॉक्स की सुविधा. जैसे, जुए वाले विज्ञापन.	PA API, दिखाए गए विज्ञापनों के कॉन्टेंट पर विचार नहीं करता. यह कंट्रोल, पीए का इस्तेमाल करने वाले विज्ञापन टेक्नोलॉजी डेवलपर के पास होता है. आम तौर पर, पब्लिशर और विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली कंपनियां, सुरक्षित ऑडियंस की नीलामियों में विज्ञापन क्रिएटिव को ब्लॉक कर सकती हैं. इसके लिए, वे पेज से ली गई, काम की जानकारी और पब्लिशर के नियमों के सेट का इस्तेमाल कर सकती हैं. यह आज की इन चुनौतियों को लेकर हमारी नेटवर्क की समझ को दिखाता है. खरीदारों के लिए, नेगेटिव IG टारगेटिंग फ़ंक्शन, अनुपालन से जुड़े कुछ मामलों में भी काम आ सकता है.
एपीआई डिज़ाइन	Google इस पहल को खारिज कर रहा है और चाहता है कि विज्ञापन टेक्नोलॉजी, Universal बिडिंग के फ़ंक्शन का इस्तेमाल करें. इससे इंतज़ार का समय बढ़ाया जा सके, न कि अलग-अलग IG में अलग-अलग बिडिंगLogicURL का.	नीलामी में लगने वाले समय की चर्चा के दौरान, हमने खास तौर पर बताया है कि किसी खरीदार के सभी IG में एक ही स्क्रिप्ट का दोबारा इस्तेमाल करने से, उस खरीदार की बिडिंग तेज़ हो जाएगी. PA API नीलामी में लगने वाले समय को बेहतर बनाने के लिए, हमारे अन्य सुझावों के साथ-साथ, इस बारे में ज़्यादा जानकारी यहां दी गई है.
खाते पर आधारित मार्केटिंग	खाता आधारित मार्केटिंग के इस्तेमाल के उदाहरणों के लिए, PA API एक क्लीन एपीआई नहीं है.	अगर हमें लगता है कि किसी तरह के काम के उदाहरण नहीं दिए जा सकते, तो नेटवर्क से मिलने वाले सुझावों का हम स्वागत करते हैं. हम नेटवर्क में शामिल लोगों को, GitHub पर डेटा स्टोर करने की सार्वजनिक जगह या हर हफ़्ते कॉल करके, इस चर्चा को जारी रखने के लिए बढ़ावा देते हैं.
A/B टेस्ट	किसी पब्लिशर के लिए GAM में PA API को कॉन्फ़िगर किए जाने पर, यह ज़रूरी है कि वह सभी इन्वेंट्री के लिए चालू हो या किसी के लिए भी न हो. इससे पब्लिशर के पास A/B टेस्ट करने की बेहतर क्षमता होती है.	Google Ad Manager से मिला जवाब: Google Ad Manager (GAM) में PA API कंट्रोल, GAM के एपीआई इस्तेमाल करने की क्षमता पर असर डालता है. हालांकि, इसके लिए ज़रूरी है कि एपीआई इस्तेमाल करने के लिए उपलब्ध हो. इसलिए, पब्लिशर Chrome की अनुमतियों से जुड़ी नीति के फ़ंक्शन का इस्तेमाल करके, A/B टेस्ट कर सकते हैं. इससे, ट्रैफ़िक के किसी सबसेट पर एपीआई का इस्तेमाल बंद किया जा सकता है, ताकि A/B टेस्ट के लिए, कंट्रोल ग्रुप के तौर पर इस्तेमाल किया जा सके.
मशीन लर्निंग	पब्लिशर को GAM की ओर से मशीन लर्निंग के सुझाए गए इस्तेमाल पर ज़्यादा नियंत्रण की ज़रूरत है.	Google Ad Manager से मिला जवाब: हमने जनवरी 2024 में एक कंट्रोल लॉन्च किया था. इसकी मदद से पब्लिशर, मशीन लर्निंग थ्रॉटलर को बंद कर सकते हैं. साथ ही, वे अपने पूरे ट्रैफ़िक पर, Google से बाहर के सेलर के लिए, पीए एपीआई नीलामियों को चालू कर सकते हैं. इस कंट्रोल के बारे में ज़्यादा जानकारी हमारे सहायता केंद्र में देखी जा सकती है.
(पिछली तिमाहियों में भी रिपोर्ट की गई है) टॉप-लेवल नीलामी	GAM को टॉप-लेवल PA API नीलामी का कंट्रोल दिए बिना, Google के पब्लिशर विज्ञापन सर्वर का इस्तेमाल करने की सुविधा.	Google Ad Manager से मिला जवाब: Google की 2023 की तीसरी तिमाही की रिपोर्ट में बताई गई वजहों के हिसाब से, GAM अपने PA API इंटिग्रेशन के लिए प्लान बना रहा है. इसमें उन पब्लिशर को शामिल नहीं किया गया है जो टॉप लेवल की नीलामी को कंट्रोल किए बिना, GAM का इस्तेमाल पब्लिशर विज्ञापन सर्वर के तौर पर करते हैं.
जानकारी का ऐक्सेस	GAM के पास प्रतिस्पर्धी कंपनियों से मिलने वाली अहम जानकारी का ऐक्सेस होता है. इसमें, नीलामी के हिसाब से कीमतें, PA API नीलामी के लिए SSP को खरीदारों से मिले सिग्नल, और SSP के कॉन्फ़िगरेशन पैरामीटर शामिल होते हैं.	Google Ad Manager से मिला जवाब: हमने सालों तक नीलामी में निष्पक्षता पर फ़ोकस बनाए रखा है. इसमें यह वादा भी शामिल है कि किसी भी पब्लिशर के बिना गारंटी वाले विज्ञापन सोर्स से मिलने वाली कीमत को नीलामी में बिड करने से पहले किसी दूसरे खरीदार के साथ शेयर नहीं किया जाएगा. इसके बाद, हमने फ़्रेंच कॉम्पिटिशन अथॉरिटी के लिए अपनी प्रतिबद्धताओं की फिर से पुष्टि की. इसमें, बिना गारंटी वाले लाइन आइटम की कीमतें भी शामिल हैं. पीए एपीआई से जुड़ी नीलामियों के लिए, हमारा मकसद बरकरार रहना है. साथ ही, मल्टी-सेलर नीलामियों में नीलामी पूरी होने से पहले, नीलामी में हिस्सा लेने वाले किसी भी अन्य व्यक्ति की बिड को शेयर नहीं करना है. साफ़ तौर पर बता दें कि हम कॉन्टेक्स्ट के हिसाब से होने वाली नीलामी की कीमत, हमारी साइट के साथ-साथ किसी दूसरी नीलामी के साथ शेयर नहीं करेंगे, जैसा कि इस अपडेट में बताया गया है. इसके अलावा, हम कॉम्पोनेंट की नीलामी के कॉन्फ़िगरेशन की जानकारी का इस्तेमाल नहीं करते. इसमें, नीलामी में खरीदारों से एसएसपी को दिए गए सिग्नल भी शामिल होते हैं. असल में, हम पीए एपीआई में हुए बदलावों का स्वागत करेंगे. इस सुविधा की मदद से, कॉम्पोनेंट सेलर अपने कॉम्पोनेंट नीलामी के कॉन्फ़िगरेशन को इस तरह तय कर सकते हैं कि टॉप लेवल सेलर के डेटा को समझना और समझना आसान हो.
घटक नीलामी	टॉप-लेवल नीलामी के तौर पर, GAM यह कंट्रोल करेगा कि कौनसे SSP हर विज्ञापन अवसर के लिए कॉम्पोनेंट की नीलामियां करेंगे.	Google Ad Manager से मिला जवाब: पब्लिशर के विज्ञापन सर्वर के तौर पर, GAM, SSP के लिए एक लाइटवेट एपीआई ऑफ़र करता है. इसकी मदद से पब्लिशर, Google Publisher Tag (GPT) API के ज़रिए अपने कॉम्पोनेंट के ऑक्शन कॉन्फ़िगरेशन की जानकारी दे सकते हैं. ज़्यादा जानकारी के लिए यहां जाएं. अगर कोई SSP, इस एपीआई की मदद से कॉम्पोनेंट नीलामी का कॉन्फ़िगरेशन उपलब्ध कराती है, तो उसे विज्ञापन के इस अवसर के लिए कॉम्पोनेंट नीलामियों की सूची में शामिल किया जाता है. GAM, शामिल की गई कॉम्पोनेंट की नीलामियों पर कोई पाबंदी नहीं लगाता. अगर किसी एसएसपी को कॉम्पोनेंट नीलामी चलाने की ज़रूरत है, तो वह ऐसा कर सकता है. हालांकि, इसके लिए ज़रूरी है कि पब्लिशर ने उसे पब्लिशर के पेज पर ज़रूरी कोड चलाने की अनुमति दी हो.
घटक नीलामी	GAM, हर कॉम्पोनेंट के लिए नीलामी जीतने वाली बिड के लिए, एक खास फ़्लोर लागू कर सकता है. इसकी जानकारी नहीं दी गई है.	Google Ad Manager से मिला जवाब: GAM ने सालों से नीलामी में निष्पक्षता को बनाए रखा है. निष्पक्ष और पारदर्शी नीलामी बनाए रखने की वजह से, हम उस कम से कम कीमत की सुविधा नहीं देते जो सिर्फ़ मांग के खास सेगमेंट पर लागू होती हैं. हमारे प्रॉडक्ट में यह नियम पहले जैसा ही है और PA API नीलामियों के लिए भी ऐसा ही रहेगा.
तीसरे पक्ष के विज्ञापन सर्वर	तीसरे पक्ष के विज्ञापन सर्वर के पास, उच्च-लेवल की नीलामी में Google की भागीदारी का ऐक्सेस नहीं होगा. इससे, PA API के मामले में Google SSP की डिमांड का फ़ायदा सीमित हो जाएगा.	Google Ad Manager से मिला जवाब: फ़िलहाल, GAM पर यहां बताए गए एपीआई की मदद से, एक से ज़्यादा सेलर के साथ PA API को टेस्ट किया जा सकता है. फ़िलहाल, दूसरे टॉप लेवल की नीलामियों में कॉम्पोनेंट नीलामी के तौर पर, GAM में हिस्सा नहीं लिया जा सकता.
(पिछली तिमाहियों में भी रिपोर्ट की गई है) PA API नीलामियों की परफ़ॉर्मेंस	जांच करने वाले लोगों से मिली रिपोर्ट कि PA API नीलामियों में इंतज़ार का समय ज़्यादा होता है.	हमें इंतज़ार के समय के बारे में समस्याओं के बारे में पता चला है. इसी वजह से, हमने PA API के हिस्से के तौर पर कई सुविधाएं डेवलप की हैं. इसकी मदद से, SSP के लिए डीएसपी इंतज़ार के समय की सीमा सेट करने के साथ-साथ सुधार भी किए जा सकेंगे. इससे इंतज़ार का समय कम हो सकता है. हमने हाल ही में, इंतज़ार का समय खत्म करने के सबसे सही तरीकों की गाइड को अपडेट किया है. इसमें, इन सुविधाओं का फ़ायदा पाने के तरीकों के बारे में ज़्यादा जानकारी दी गई है. साथ ही, हम इंतज़ार के समय में नए सुधार कर रहे हैं, जिनमें से कुछ यहां देखे जा सकते हैं.
(पिछली तिमाहियों में भी रिपोर्ट की गई) वीडियो रेंडरिंग	PA API और फ़ेंस किए गए फ़्रेम का इस्तेमाल करके, वीडियो रेंडरिंग के लिए सहायता.	जनवरी में, हमने पीए नीलामी में इनस्ट्रीम वीडियो के काम करने के तरीके का डेमो पब्लिश किया था. साथ ही, इसमें वैकल्पिक तरीकों के बारे में ज़्यादा जानकारी भी दी थी. हमें नेटवर्क के प्लेयर यह भी बता रहे हैं कि उनके साथ इंटिग्रेट किए गए पार्टनर के लिए, वीडियो रेंडरिंग कैसे काम करती है. जैसे, वीडियो के साथ काम करने वाले रेंडर यूआरएल बनाने के लिए GAM के प्रस्ताव या पूरी E2E प्रोसेस. इसके अलावा, हम ऐसे बदलावों पर नेटवर्क से जुड़े सुझाव सुन रहे हैं जिन्हें हम GitHub में लागू कर सकते हैं. और ऐसा बदलाव GitHub में किया गया है. हम उन्हें समय पर लागू करने में आने वाली अन्य रुकावटों की पहचान करने के लिए, नेटवर्क में लगातार काम कर रहे हैं.
(पिछली तिमाही में भी रिपोर्ट की गई है) डेटा मैनेज करने से जुड़ी नीति	आईजीएस / पीए एपीआई के लिए डेटा मैनेज करने की नीति क्या है?	PA API डिज़ाइन में, आईजी में सेव किया गया सारा डेटा या इस बारे में जानकारी कि लोग किन चीज़ों से जुड़े हैं, (i) डिवाइस पर मौजूद रहता है या (ii) भरोसेमंद एक्ज़ीक्यूशन एनवायरमेंट (टीईई) में चल रही बिडिंग और नीलामी (B&A) सेवाओं में प्रोसेस किया जाता है. दोनों ही मामलों में, डेटा को कोई दूसरा पक्ष नहीं पढ़ सकता. इसके अलावा, इसका इस्तेमाल नीलामी में बिड लगाने के अलावा किसी अन्य तरीके से नहीं किया जा सकता. Chrome, निजता को बेहतर बनाने के जिन तरीकों को एक्सप्लोर कर रहा है उनमें Google के k-एनॉनिमिटी सर्वर के साथ इंटरैक्शन शामिल है. उस इंटरैक्शन को ध्यान से तैयार किया जा रहा है, ताकि उपयोगकर्ताओं के बारे में जानकारी शेयर न की जा सके. साथ ही, इसे टीईई में चलाया जा सके, ताकि विज्ञापन नेटवर्क में एक जैसी जानकारी हो. Google ने CMA के लिए, प्राइवसी सैंडबॉक्स के प्रपोज़ल को इस तरह डिज़ाइन और लागू करने के लिए प्रतिबद्ध है कि वह खुद के हिसाब से मुकाबला न करे. साथ ही, डिजिटल विज्ञापन के साथ-साथ पब्लिशर और विज्ञापन देने वालों पर भी असर डाले. हम यह पक्का करने के लिए सीएमए के साथ काम करते रहते हैं कि हमारा काम इन जवाबदेही का पालन करे.
(पिछली तिमाही में भी रिपोर्ट किया गया) IG लाइफ़टाइम	आईजीएस की सेवा की अवधि को 30 से बढ़ाकर 90 दिन करने का अनुरोध करें.	इस तरह के बदलाव के लिए, Chrome के उपयोगकर्ताओं और अन्य हिस्सेदारों पर पड़ने वाले असर की तुलना में इंडस्ट्री को होने वाले फ़ायदों का ध्यान से आकलन करना ज़रूरी होता है. हम इस अनुरोध पर विचार कर रहे हैं और यहां अतिरिक्त सुझाव, शिकायत या राय का स्वागत कर रहे हैं.
(पिछली तिमाही में भी रिपोर्ट किया गया) modelingSignals	मॉडलिंग सिग्नल के अलावा एक नए फ़ील्ड का अनुरोध करें, जो सिर्फ़ डिसप्ले और क्लिक की जानकारी को कोड में बदल सकता है.	हमने यहां एक कानूनी प्रस्ताव के साथ इस सुझाव का जवाब दिया है. हम अपने प्रस्ताव पर इंडस्ट्री के विचार समझने के लिए उससे लगातार काम कर रहे हैं. साथ ही, हम Chrome के उपयोगकर्ताओं और अन्य हिस्सेदारों पर पड़ने वाले असर की तुलना में इंडस्ट्री को मिलने वाले फ़ायदों को अहमियत दे रहे हैं.
reportWin() में अतिरिक्त बिट	3PCD से पहले की 12 की मौजूदा सीमा से, reportWin() में अतिरिक्त बिट दें.	फ़िलहाल, हम इस तरह के मामलों को सुलझाने के तरीके खोज रहे हैं. इसमें कुछ समय लग रहा है, क्योंकि हम ऐसे तरीके भी ढूंढ रहे हैं जिनसे यह पक्का हो सके कि हमारे पास लंबे समय तक निजता की योजना हो.
नीलामी का डिज़ाइन	सिंगल नीलामी के लिए अनुरोध करना, जो रेंडर होने वाले यूआरएल को उनसे जुड़े स्कोर के साथ दिखाती है.	एक ही पीए नीलामी से कई रेंडर यूआरएल और उनसे जुड़े स्कोर शेयर करने पर हमने विचार किया, लेकिन निजता की समस्याओं की वजह से इसे लागू नहीं किया. हम किसी उपयोगकर्ता को एक ही पेज पर, एक ही विज्ञापन को कई बार दिखाने से बचना चाहते हैं. इसलिए, हम GitHub पर आगे की चर्चा का स्वागत करते हैं.
reportWin	reportWin() फ़ंक्शन में आर्बिट्रेरी फ़ील्ड लॉग करें.	टेस्टिंग की अवधि के दौरान, यह बदलाव आज पहले से ही हो रहा है. जब Chrome 3PC के लिए सहायता बंद कर देगा, तब एपीआई के forDebuggingOnly वर्शन को डाउनसैंपल किए गए डीबग को चालू करने के लिए माइग्रेट किया जाएगा. इसकी जानकारी यहां दी गई है.
कॉम्पोनेंट सेलर	आपके पास अपने इंप्रेशन और अन्य इवेंट की गिनती करने का एक स्वतंत्र तरीका होना चाहिए. साथ ही, वह पूरी तरह से विज्ञापन टेक्नोलॉजी की रिपोर्ट पर निर्भर नहीं होना चाहिए.	सुविधा का यह अनुरोध, आगे की खोज के लिए हमारी सूची में शामिल है. Chrome की सुविधा वाली टेस्टिंग अवधि के दौरान, हमें इस बारे में पता नहीं चलता.
हर क्लिक की लागत (सीपीसी) वाली बिलिंग	PA API में, हर क्लिक की लागत (सीपीसी) बिलिंग लागू करें.	हम यहां इस अनुरोध पर विचार कर रहे हैं. फ़िलहाल, हम यह अनुरोध मानते हैं कि इसे एपीआई के मौजूदा प्लैटफ़ॉर्म पर लागू करने के तरीके क्या हैं.
browserSignals	सेलर के लिए browserSignals की खास जानकारी की रिपोर्टिंग में,इनकमिंगBidInSellerCurrency जोड़ें.	हम इस अनुरोध पर विचार कर रहे हैं और यहां अतिरिक्त सुझाव, शिकायत या राय का स्वागत कर रहे हैं.
डीएसपी से बाहर के लोगों के लिए बाय-साइड मेटाडेटा और लॉजिक के मालिकाना हक के लिए सहायता	एपीआई के मौजूदा डिज़ाइन से, प्रॉडक्ट-लेवल पर फिर से टारगेट करने वाले कैंपेन में अहम बदलाव हो सकते हैं. यहां कैंपेन को उन प्लैटफ़ॉर्म पर माइग्रेट करना पड़ सकता है जो डीएसपी और डीसीओ, दोनों की सेवा देते हैं.	हम इस समस्या पर चर्चा कर रहे हैं और हमें कुछ और सुझाव, शिकायत या राय का स्वागत है. इसके लिए यहां क्लिक करें.
डीएसपी से बाहर के लोगों के लिए बाय-साइड मेटाडेटा और लॉजिक के मालिकाना हक के लिए सहायता	ऐसे उदाहरण शेयर करें जिनमें डीएसपी, आईजी का मालिक न हो.	हम समझते हैं कि बिडिंग नहीं करने वाले लोग, आईजी की कुछ सुविधाओं का इस्तेमाल करना चाहेंगे, लेकिन अन्य नहीं. हम इस्तेमाल के इन उदाहरणों को ठीक करने के लिए, विकल्पों का लगातार आकलन कर रहे हैं. यहां अन्य सुझावों का स्वागत है.
टाइम आउट कंट्रोल	पब्लिशर को यह तय करने की सुविधा होनी चाहिए कि कितने आईजी, इवेंट में हिस्सा ले सकते हैं और जिनमें टॉप-लेवल टाइम आउट / ग्लोबल टाइम आउट की संख्या शामिल है.	हम समझते हैं कि टॉप-लेवल और कॉम्पोनेंट सेलर के बीच, बेहतर टाइम आउट कंट्रोल और विज़िबिलिटी की इच्छा है. इसलिए, हम इस अनुरोध पर विचार कर रहे हैं.
कई विज्ञापन साइज़	कई विज्ञापन साइज़ के इस्तेमाल के मामलों में PA API से जुड़ी सहायता.	हम इस अनुरोध पर विचार कर रहे हैं और नेटवर्क से अतिरिक्त सुझाव, शिकायत या राय का स्वागत कर रहे हैं.
दस्तावेज़	क्या ऐसे IG एट्रिब्यूट की कोई सूची है जो k-anon के तहत आती हैं?	हमने इस सवाल का जवाब यहां दिया है.
डीबग करना	PA API के लिए डीबग करने की बेहतर सुविधाएं.	हम PA API के साथ काम करने वाले डेवलपर के लिए, डीबग करने के बेहतर टूल की अहमियत को समझते हैं. हम डेवलपर टूल के साथ .well-known फ़ाइल फ़ेच करने की सुविधा को बेहतर तरीके से इंटिग्रेट करके, डेवलपर के अनुभव को बेहतर बनाने के लिए प्रतिबद्ध हैं. हमारा लक्ष्य डेवलपमेंट एनवायरमेंट में ज़्यादा पारदर्शिता और समस्या हल करना है. हम इस समस्या के बारे में यहां ज़्यादा चर्चा कर रहे हैं. हमें अन्य सुझावों का भी स्वागत है.
लेबल	क्या मोड बी ट्रीटमेंट लेबल के सभी उपयोगकर्ताओं के लिए, प्राइवसी सैंडबॉक्स एपीआई चालू है?	Chrome के एक्सपेरिमेंट ग्रुप के असाइनमेंट, उपयोगकर्ता के लिए कॉन्फ़िगर की गई Chrome सेटिंग से किसी भी क्रम में तय किए जाते हैं और उनसे अलग होते हैं. ये एपीआई चुनिंदा ट्रीटमेंट ग्रुप (जैसे, ट्रीटमेंट_1.*) के उपयोगकर्ताओं के लिए उपलब्ध हो सकते हैं. हालांकि, Chrome की सेटिंग में जाकर, इनके फ़ंक्शन में बदलाव किया जा सकता है या उन्हें बंद किया जा सकता है. मोड B Control_2 ग्रुप: इस ग्रुप में शामिल करने से, प्राइवसी सैंडबॉक्स के और मेज़रमेंट एपीआई को बंद कर दिया जाता है. Chrome की सेटिंग में जाकर, उपयोगकर्ता इस सेटिंग को नहीं बदल सकता.
एपीआई प्रयोग	क्या reportWin() और विज्ञापन रेंडरिंग साथ-साथ हो रही है या एक के बाद एक?	playAdनीलामी() के पूरा होने के बाद reportWin() को कॉल किया जाता है. साथ ही, उस समय विज्ञापन रेंडरिंग की प्रोसेस तब शुरू हो सकती है, जब नीलामी के नतीजे को iframe या Fenced Frame में रखा जाता है. reportWin() की प्रोसेस पूरी होने और विज्ञापन रेंडर होना शुरू होने के बाद, sendreportTo() के लिए दिए गए यूआरएल फ़ेच किए जाएंगे.
(पिछली तिमाहियों में भी रिपोर्ट की गई है) A/B टेस्टिंग सहायता	PA API A/B टेस्टिंग के लिए सहायता पाने का अनुरोध करें.	हम इस अनुरोध के बारे में यहां चर्चा कर रहे हैं और आपके कुछ और सुझाव, शिकायत या राय का स्वागत है.
ट्रैफ़िक को आकार देने वाला	केवी सर्वर से ज़रूरी फ़ैसले लेने के लिए, Google का प्रपोज़ल काम का नहीं होता, क्योंकि सेलर अपने बैकएंड से इंटरैक्ट नहीं कर पाते. इस वजह से, ट्रैफ़िक को आकार देने में मुश्किल होती है.	जैसा कि GitHub से जुड़ी समस्या में बताया गया है, अगर किसी डीएसपी में आईजी मौजूद हैं, तो उन्हें उपयोगकर्ताओं के फ़िंगरप्रिंट की समस्या हो सकती है. हमने इस समस्या के अन्य विकल्पों के सुझाव दिए हैं. साथ ही, हम इस पर और भी सुझाव दे सकते हैं.
ट्रैफ़िक को आकार देने वाला	कैश मेमोरी में सेव करने के तरीके बहुत जटिल हो जाते हैं. इसकी वजह से, डीएसपी को यह पता नहीं चल पाता है कि असल में वे किस ट्रैफ़िक पर बिडिंग करेंगे.	कैश मेमोरी में सेव करने का तरीका, सिर्फ़ सुझाव के तौर पर दिया गया था. AdTech चाहें, तो उन सुझावों का इस्तेमाल कर सकते हैं जो उनके इस्तेमाल के हिसाब से सही हों. हम यहां पर चर्चा करने का स्वागत करते हैं.
लेबल	Chrome को खरीदार और विक्रेता के भरोसेमंद सर्वर को किए जाने वाले अनुरोधों में, लेबल को पैरामीटर के तौर पर शेयर करना चाहिए.	यह सही अनुरोध लग रहा है, क्योंकि इसका मकसद IG के डेटा को ज़िम्मेदारी के साथ इस्तेमाल करना है. हालांकि, हम इस अनुरोध पर विचार कर रहे हैं. इसे अंदरूनी समीक्षा के हिसाब से प्रोसेस किया जाएगा. बातचीत आगे बढ़ने पर, हम आपको इस बारे में सार्वजनिक अपडेट देंगे.
एपीआई प्रयोग	"टेस्टिंग को लेकर तीसरे पक्षों के लिए अतिरिक्त CMA दिशा-निर्देश" में, "control_1" ग्रुप की साफ़ तौर पर परिभाषा बताई गई है. खास तौर पर, इस बात को लेकर चिंता है कि शब्दों में बदलाव का गलत मतलब निकाला जा सकता है कि इसे Control_1 से सभी प्राइवसी सैंडबॉक्स एपीआई को बाहर रखना ज़रूरी है.	हमने इस बारे में इस GitHub थ्रेड में अपने विचार बताए हैं. हालांकि, हम सीएमए के बारे में बात नहीं कर सकते. हमारा सुझाव है कि टेस्टिंग से जुड़े उनके दिशा-निर्देशों की व्याख्या के बारे में सीधे सीएमए से बात करें.
एपीआई प्रयोग	क्या Chrome किसी दूसरे संसाधन पर रीडायरेक्ट करते समय, खाली पेज परjoinAdInterestGroup() को कॉल करने की अनुमति देगा?	अगर कोई उपयोगकर्ता किसी साइट पर जा रहा है, तो साइट का मालिक किसी तीसरे पक्ष को addAdInterestGroup को कॉल करने की अनुमति दे सकता है. इस डेलिगेशन की मदद से, तीसरे पक्ष को किसी खाली पेज से किसी भी तरह का रीडायरेक्ट जोड़े बिना ही आईजी बनाने की सुविधा मिलती है. हम सुझाव/शिकायत/राय का स्वागत करते हैं, ताकि उन्हें दूसरे वेबलिंक पर भेजने के दौरान ही आईजी बनाया जा सके. इसके लिए, सही डेलिगेशन सिस्टम इस्तेमाल न किया जाए.
एपीआई प्रयोग	एक्सचेंज के पास उन पब्लिशर के मालिकाना हक वाले पेजों पर IG लिखने की अनुमति होनी चाहिए जिनके साथ वे काम करते हैं. इसके बाद, वे किसी खरीदार या DSP को उस IG पर बिड करने की अनुमति दे सकते हैं.	हमें सुझाव मिल गया है और हम इस बात का आकलन कर रहे हैं कि इस तरह का अनुरोध स्वीकार किया जा सकता है या नहीं. हम नेटवर्क से अतिरिक्त सुझाव, शिकायत या राय का स्वागत करते हैं.
एपीआई प्रयोग	अगर कोई भी PA API नीलामी में नहीं जीतता है, तो डीबग करने से होने वाले नुकसान की कोई सूचना नहीं भेजी जाएगी.	Chrome के reportWin और reportresults फ़ंक्शन, निजता नीलामी (पीए) सिस्टम में इवेंट-लेवल पर जीत की रिपोर्टिंग के लिए डिज़ाइन किए गए हैं. जिन मामलों में पीए नीलामी के दौरान सभी बिड अस्वीकार कर दी जाती हैं, उन मामलों में इन फ़ंक्शन के शुरू होने की उम्मीद नहीं होती, क्योंकि कोई विजेता नहीं तय होता. Chrome में हाल ही में किए गए अपडेट की वजह से उन अंतर की जानकारी मिल सकती है जिनकी वजह से fordebuggingOnly.reportAdनीलामीLoss() को पास किए गए यूआरएल, DevTools नेटवर्क पैनल में नहीं दिख रहे हैं. हमारा सुझाव है कि इस सुविधा की पुष्टि करने के लिए, Chrome के कैनरी या डेव चैनल बिल्ड का इस्तेमाल करें.
एपीआई प्रयोग	क्या GenBid से लौटाया गया adCost नेगेटिव हो सकता है (यह पहले से ही स्टैंडर्ड तौर पर 2 बाइट का है)?	AdCost, विज्ञापन देने वाले का वह क्लिक या कन्वर्ज़न की लागत है जिसे generateबिड() से reportWin() में भेजा जाता है. यह वैल्यू शून्य या दोगुनी हो सकती है. नेगेटिव वैल्यू को अनदेखा कर दिया जाएगा और इन्हें पास नहीं किया जाएगा. पास होने पर, वैल्यू को स्थिर रूप से राउंड ऑफ़ कर दिया जाएगा.
एपीआई में सुधार	क्या टारगेटिंग (विज्ञापन के लिए सही दर्शक चुनना) / कोहॉर्ट / एट्रिब्यूशन और नीलामी को मैनेज करने के लिए, Chrome ब्राउज़र के बजाय भरोसेमंद और एन्क्रिप्ट किए गए एक्ज़ीक्यूशन सर्वर का इस्तेमाल किया जा सकता है?	हमारा सुझाव है कि PA API (जैसे कि केवी सर्वर और B&A सेवाएं) में टीईई पर आधारित कॉम्पोनेंट और विकल्पों के साथ-साथ, एट्रिब्यूशन रिपोर्टिंग और प्राइवेट एग्रीगेशन (उदाहरण के लिए, एग्रीगेशन सर्विस) के टीई-आधारित कॉम्पोनेंट के बारे में जानें, जो इस सवाल के जवाब देते हैं.
एपीआई में सुधार	क्या प्राइवसी सैंडबॉक्स नीलामी के रिस्पॉन्स को, विज्ञापन रिस्पॉन्स (जैसे, विज्ञापन टैग) के बजाय बिड रिस्पॉन्स (जैसे, हेडर बिडिंग) की तरह इस्तेमाल किया जा सकता है?	इस तरह के बदलाव से, PA API की निजता से जुड़ी प्रॉपर्टी बुनियादी तौर पर बदल जाती है. इसलिए, हम इस पर विचार नहीं कर रहे हैं.
पब्लिशर के कंट्रोल	क्या पब्लिशर अपने पेजों पर, पीए एपीआई वाले क्रिएटिव को ब्लॉक कर सकते हैं?	Chrome में रीयल-टाइम में क्रिएटिव स्कैनिंग की सुविधा का एक प्रस्ताव है, जो फ़िलहाल टेस्ट के लिए उपलब्ध नहीं है. हालांकि, यह सुविधा अभी उपलब्ध नहीं है, लेकिन ज़्यादातर SSP ने इसे चालू करने के समाधान बनाए हैं.
एपीआई प्रयोग	PerBuyerSignals पर साइज़ की सीमा क्या है?	अपने क्लासिक रूप में, PerBuyerSignals में Chrome की कोई स्वाभाविक साइज़ सीमा नहीं होती है. सबसे अहम बात यह है कि डेटा, JSON के क्रम में बना रहता है और इससे मेमोरी का ज़्यादा इस्तेमाल नहीं होता. हालांकि, यह ध्यान रखना चाहिए कि बहुत बड़े और जटिल PerBuyerSignals से परफ़ॉर्मेंस पर बुरा असर पड़ सकता है. directFromSellerSignalsHeaderAdSlot के ज़रिए PerBuyerSignals को पास करने के लिए, एक अन्य तरीका भी मौजूद है. यह तरीका हर खरीदार के लिए एक हेडर में सिग्नल भेजता है. यह जानकारी पूरे हेडर रिस्पॉन्स के लिए, ज़्यादा से ज़्यादा 10 केबी की साइज़ की सीमा के हिसाब से भेजी जाती है. इसके अलावा, हेडर के ज़्यादा से ज़्यादा साइज़ पर अलग-अलग सर्वर अपने हिसाब से पाबंदियां लगा सकते हैं.
दस्तावेज़	जनरेटिव बिड के अंदर मौजूद कॉल रजिस्टर AdBeacon पर मौजूद दस्तावेज़ को बदलना होगा.	हमने इस दस्तावेज़ को 17 फ़रवरी को अपडेट किया था.
एपीआई प्रयोग	reportEvent, रजिस्टर किए गए कई विकल्पों में से सही बीकन यूआरएल कैसे चुनता है?	हर नीलामी का एक अलग कॉन्फ़िगरेशन होता है, जिससे एक अलग रिपोर्टिंग मैप बन जाता है. अलग-अलग नीलामियां (और उनसे मिलने वाले फ़्रेम) एक-दूसरे से पूरी तरह अलग होती हैं. साथ ही, इनमें डेटा शेयर नहीं किया जाता है. "फ़ेंस्ड फ़्रेम वाले विज्ञापनों की रिपोर्टिंग" में इस विषय के बारे में ज़्यादा जानकारी दी गई है.
Chrome का यूज़र इंटरफ़ेस (यूआई)	Chrome DevTools के "ऐप्लिकेशन -> "दिलचस्पी के ग्रुप" टैब में फ़िल्टर जोड़ें. इससे, IG के मालिक या IG के नाम के हिसाब से भी फ़िल्टर को फ़िल्टर किया जा सकता है.	हम इस अनुरोध की समीक्षा कर रहे हैं. हमें नेटवर्क से मिलने वाले अन्य सुझावों का भी स्वागत है.
बिना ग्राफ़िक यूज़र इंटरफ़ेस वाला Chrome	बिना ग्राफ़िक यूज़र इंटरफ़ेस वाले Chrome में PA API की सहायता.	PA API के कुछ कॉम्पोनेंट Chrome से जुड़े होते हैं. उदाहरण के लिए, Google के सर्वर को k-anon कॉल किया जाता है, जो शायद "पुराने" बिना ग्राफ़िक यूज़र इंटरफ़ेस वाले Chrome में काम न करे. हमें लगता है कि यह समस्या, Chrome 112 में रिलीज़ किए गए बिना ग्राफ़िक यूज़र इंटरफ़ेस वाले Chrome के "नए" वर्शन से मिल सकती है.
एपीआई प्रयोग	reportAdनीलामीLoss के साथ होने वाले नुकसान की रिपोर्टिंग के मामले में, हमें कई मामलों में "toplevelW ट्रांज़िशनBid=0" दिख रहे होंगे. इसका क्या मतलब है?	ToplevelWingBid की वैल्यू, टॉप लेवल सेलर कॉम्पोनेंट में मौजूद ScoreAd() फ़ंक्शन से शुरू होती है. यह वैल्यू, टॉप-लेवल की नीलामी के नतीजे तय करने में भूमिका निभाती है. जानकारी देने वाले के मुताबिक, शून्य या किसी भी नेगेटिव संख्या की ToplevelWingBid की वैल्यू होने का मतलब है कि संबंधित विज्ञापन नीलामी जीतने की ज़रूरी शर्तें पूरी नहीं करता है. उदाहरण के लिए, इस तरीके का इस्तेमाल रुचि के हिसाब से टारगेट किए गए उन विज्ञापनों को फ़िल्टर करने के लिए किया जा सकता है जो संदर्भ के हिसाब से टारगेट किए गए कैंडिडेट से पार नहीं होते. भले ही, शून्य वैल्यू वाली ToplevelWingBid से यह पता चलता है कि संदर्भ के हिसाब से नीलामी हो चुकी है, लेकिन PA API की शर्तों में यह स्वीकार किया गया है कि अन्य वजहों से इस नतीजे पर असर पड़ सकता है.
मोड A/B टेस्टिंग	मोड बी और मोड A ट्रैफ़िक चुनने और ऑप्ट-आउट करने के प्रॉम्प्ट के बारे में जानकारी.	मोड A और मोड B में शामिल करने की शर्तें एक जैसी हैं. इसका मकसद ऐसे ग्रुप बनाना है जो Chrome के सामान्य ट्रैफ़िक के प्रतिनिधि हों. हालांकि, ऐसा तब तक होगा, जब तक वे Privacy Sandbox APIs और लेबल करने के तरीके के साथ काम करते हों. ऐसा इसलिए, क्योंकि कुछ क्लाइंट कॉन्फ़िगरेशन साथ काम नहीं करते. प्रयोग के लिए, यह ज़रूरी है कि लेबल किए गए ट्रैफ़िक की तुलना, लेबल किए गए दूसरे ट्रैफ़िक से की जाए. मोड B में मौजूद उपयोगकर्ताओं के डिवाइस में ट्रैकिंग सुरक्षा की सुविधा चालू होती है और उन्हें इस सुविधा के बारे में सूचना मिलती है.
एपीआई में सुधार	क्या "lifetimeMs" को engagementAdInterestGroup कॉल में डायरेक्ट प्रॉपर्टी के तौर पर शामिल किया जा सकता है या किसी अलग तर्क के तौर पर मैनेज किया जा सकता है?	हम PA API प्रस्ताव में "joinAdInterestGroup" फ़ंक्शन के बारे में वेब डेवलपमेंट समुदाय से मिलने वाले सुझावों पर सावधानी से विचार कर रहे हैं. यहां बातचीत का एक अहम पॉइंट है, जो IG के लाइफ़टाइम को मैनेज करने के लिए सबसे सही तरीके पर फ़ोकस करता है. हम "lifetimeMs" पैरामीटर के लिए एक अलग तर्क के फ़ायदों का आकलन कर रहे हैं. इससे आने वाले समय में, स्पेसिफ़िकेशन में किए जाने वाले बदलावों को लागू करने और उनमें आसानी से बदलाव करने को बढ़ावा मिलता है. हम इस समस्या पर यहां चर्चा कर रहे हैं और हमें कुछ और सुझाव, शिकायत या राय भेजनी चाहिए.
एपीआई प्रयोग	लो-एंट्रॉपी ब्राउज़र आईडी के साथ टकराव की वजह से, पीए एपीआई फ़्रेमवर्क में गलत नेगेटिव रेट बढ़ने की संभावना.	Chrome टीम, PA API फ़्रेमवर्क को बेहतर बनाने के लिए लगातार काम कर रही है. हम ब्राउज़र आईडी टकराव से पैदा होने वाली संभावित गलत नेगेटिव दरों के बारे में चर्चा की सराहना करते हैं. हम इस सुझाव, शिकायत या राय का ध्यान से आकलन कर रहे हैं. हम यह पक्का करने के लिए काम करेंगे कि अपडेट किए गए विश्लेषण में सभी ज़रूरी बातें पूरी तरह से शामिल की जाएं. हमारी कोशिश है कि हम ऐसा समाधान उपलब्ध कराएं जिससे उपयोगकर्ताओं की निजता को बनाए रखते हुए, उनके काम करने के तरीके को सटीक और भरोसेमंद बनाए रखा जा सके. हम इस समस्या पर यहां चर्चा कर रहे हैं. हमें अन्य सुझावों का भी स्वागत है.
एपीआई प्रयोग	क्या लो-एंट्रॉपी ब्राउज़र आइडेंटिफ़ायर, क्लाइंट को एक ही ऑब्जेक्ट के लिए, k-ऐनॉमिटी सिस्टम में बार-बार "शामिल हों" अनुरोध सबमिट करने से रोकने के लिए ज़रूरी है?	हम k-anonymity सिस्टम को लागू करने में ब्राउज़र आइडेंटिफ़ायर के इस्तेमाल को लेकर चल रही चर्चा को स्वीकार करते हैं और इसकी सराहना करते हैं. हम इस तरह के आइडेंटिफ़ायर के संभावित निजता से जुड़े असर को लेकर चिंताओं को समझते हैं. हमने शुरुआत में, डेटा के गलत इस्तेमाल को रोकने के लिए लो-एंट्रॉपी आइडेंटिफ़ायर का इस्तेमाल किया था. हालांकि, हम पहचान छिपाने वाले काउंटिंग टोकन जैसी अन्य तकनीकों को एक्सप्लोर कर रहे हैं. ये तरीके, सिस्टम को सुरक्षित बनाए रखते हुए, उपयोगकर्ता की निजता को प्राथमिकता देते हैं. हम ऐसे समाधान ढूंढने के लिए प्रतिबद्ध हैं जो निजता सुरक्षा के साथ-साथ ज़िम्मेदारी से इस्तेमाल किए जाने वाले डेटा के इस्तेमाल के बीच संतुलन बनाते हों. साथ ही, हम रिसर्च कम्यूनिटी के साथ लगातार बातचीत का स्वागत करते हैं. हम इस बारे में यहां चर्चा कर रहे हैं. साथ ही, अन्य सुझावों का स्वागत है.
एपीआई प्रयोग	क्या एएमपी (Accelerated Mobile Pages) PA API के साथ काम करता है.	फ़िलहाल, एएमपी पर PA API का इस्तेमाल नहीं किया जा सकता. अगर एएमपी पर दी जाने वाली सहायता हमारे लिए सबसे ज़्यादा ज़रूरी है, तो नेटवर्क से मिलने वाले सुझाव, शिकायत या राय का हम स्वागत करते हैं.
एपीआई में सुधार	टाइप को k-ऐनॉमिमिटी की जांच से हटाने के बारे में सोचें.	हम के-ऐनॉमिटी के अनुरोध स्ट्रक्चर को ऑप्टिमाइज़ करने से जुड़े सुझाव, शिकायत या राय पर सावधानी से विचार कर रहे हैं. हम पैरामीटर को एक साथ लाने और प्रोसेस को आसान बनाने के लिए, टाइप के सुझाव को समझते हैं. हमारा लक्ष्य यह है कि हम इस बात का ध्यान रखें कि प्रॉडक्ट की परफ़ॉर्मेंस बेहतर हो और वह पहले से ज़्यादा बना रहे. साथ ही, हम सभी विकल्पों का आकलन कर रहे हैं, ताकि निजता की सुरक्षा के लिए लगातार काम कर रहे हैं. हम इस समस्या पर यहां चर्चा कर रहे हैं और हमें कुछ और सुझाव, शिकायत या राय भेजनी चाहिए.
Chrome का यूज़र इंटरफ़ेस (यूआई)	कम तकनीकी उपयोगकर्ताओं के लिए ऐसे तरीकों का अनुरोध करना, ताकि वे अपने आईजीएस को आसानी से देख और मैनेज कर सकें. इसमें ऑप्ट आउट करने के लिए वेबसाइट के लेवल के संभावित कंट्रोल भी शामिल हैं.	हम IGs को समझने और मैनेज करने के लिए, लोगों के लिए आसान टूल उपलब्ध कराने की अहमियत को समझते हैं. हमने अलग-अलग तरीकों पर सावधानी से विचार किया है. साथ ही, हमने पाया है कि जिस वेबसाइट में वे शामिल हुए थे उससे आईजी की पहचान करने से, हमें साफ़ तौर पर जानकारी मिलती है. साथ ही, निजता सुरक्षा भी मिलती है. फ़िलहाल, IG का ग्लोबल मैनेजमेंट Chrome की सेटिंग में मौजूद है. हम इस क्षेत्र में उपयोगकर्ता अनुभव को और बेहतर बनाने के लिए लगातार नए तरीके खोज रहे हैं. हम इस समस्या पर यहां चर्चा कर रहे हैं. हमें अन्य सुझावों का भी स्वागत है.
एपीआई की सुरक्षा	क्या फ़ेंस किए गए फ़्रेम के मामले में भी, क्रिएटिव विज्ञापन इंटरैक्शन की वजह से PA API, निजता से जुड़ी जानकारी को लीक कर सकता है?	हम असरदार विज्ञापन इंटरैक्शन की मदद से, जानकारी के लीक होने की संभावना को स्वीकार करते हैं. हम फ़ेंस किए गए फ़्रेम, PA API, और संभावित अटैक वेक्टर के बीच होने वाले इंटरैक्शन की जांच कर रहे हैं. निजता से जुड़े जोखिमों को कम करना हमारे लिए सबसे अहम है. साथ ही, हम ऐसे बेहतरीन समाधान बनाने के लिए लगातार काम कर रहे हैं जो उपयोगकर्ता की सुरक्षा और इनोवेशन के बीच संतुलन बना रहे. हम इस समस्या पर यहां चर्चा कर रहे हैं. हमें अन्य सुझावों का भी स्वागत है.
इंतज़ार का समय	क्या खरीदार की बिडिंग के लॉजिक के लिए, 50 मि॰से॰ के टाइम आउट की डिफ़ॉल्ट वैल्यू सही है?	हम बिडिंग लॉजिक के लिए, स्पेसिफ़िकेशन और नेटवर्क अनुरोधों के समय में अंतर होने से जुड़ी समस्याओं को स्वीकार करते हैं. हम स्पेसिफ़िकेशन की समीक्षा कर रहे हैं, ताकि यह पक्का किया जा सके कि ये सही हों. साथ ही, परफ़ॉर्मेंस और संभावना के बीच संतुलन बनाने के लिए, हम टाइम आउट की सबसे सही डिफ़ॉल्ट सेटिंग की जांच कर रहे हैं. हम इस समस्या पर यहां चर्चा कर रहे हैं और हमें कुछ और सुझाव, शिकायत या राय भेजनी चाहिए.
दस्तावेज़	जानकारी में संभावित समय का लीक होना, जिसकी वजह से वेबसाइट यह अनुमान लगा सकती है कि कोई विज्ञापन, के-ऐनेमिटी थ्रेशोल्ड को पूरा नहीं कर पाया है. साथ ही, इससे क्रॉस-साइट ट्रैकिंग पर इसका असर भी पड़ सकता है.	हम संभावित टाइम लीक से जुड़ी समस्या के बारे में जानते हैं. हमने विज्ञापनों की जानकारी में अंतर की पुष्टि की है. साथ ही, हम यह पक्का करने के लिए कदम उठा रहे हैं कि विज्ञापनों की पहचान छिपाने की स्थिति को नीलामी से पहले तय किया जाए, ताकि इस तरह की जानकारी लीक होने से रोका जा सके. हम इन समस्याओं को गंभीरता से लेते हैं और इन बदलावों को दिखाने के लिए, खास जानकारी को अपडेट करेंगे. हम इस समस्या पर यहां चर्चा कर रहे हैं और हमें कुछ और सुझाव, शिकायत या राय भेजनी चाहिए.
एपीआई प्रयोग	PA API में, SSP की ब्लॉकलिस्ट लागू करने के तरीके.	हम जानते हैं कि विज्ञापन से जुड़ी पाबंदियों को मैनेज करने के लिए, एसएसपी की ज़रूरतें पूरी करनी होंगी. हम ऐसे समाधान एक्सप्लोर करने को बढ़ावा देते हैं जो डिवाइस पर आकलन को प्राथमिकता देते हैं. साथ ही, विज्ञापन के मौजूदा मेटाडेटा का इस्तेमाल करके, उपयोगकर्ता की निजता की सुरक्षा करते हैं. साथ ही, ज़रूरत के हिसाब से बदलाव भी करते हैं. हम डेवलपर के साथ काम करने के लिए प्रतिबद्ध हैं, ताकि PA API में सबसे सही तरीकों की पहचान की जा सके. हम इस समस्या पर यहां चर्चा कर रहे हैं. हमें अन्य सुझावों का भी स्वागत है.
एपीआई प्रयोग	क्या कोई अपने ब्राउज़र को PA API का इस्तेमाल करने का ऐसा दिखावा कर सकता है जिसका पता साइटें न लगा पाएं?	हम यह स्वीकार करते हैं कि अपने मौजूदा फ़ॉर्मैट में, PA API से ऑप्ट आउट करने पर वेबसाइटें, इसका पता लगा सकती हैं. हम निजता को बेहतर बनाने और ऑप्ट-आउट करने के ऐसे विकल्प उपलब्ध कराने पर काम कर रहे हैं जिनकी पहचान न की जा सके. इसके लिए, हम फ़ेंस किए गए फ़्रेम के साथ-साथ, अतिरिक्त बिड और नेगेटिव टारगेटिंग जैसी सुविधाओं पर काम कर रहे हैं. हम इस समस्या पर यहां चर्चा कर रहे हैं. हमें अन्य सुझावों का भी स्वागत है.
मोड A/B टेस्टिंग	ट्रीटमेंट 1.1 होने के हिसाब से डेटा सेंटर का ट्रैफ़िक.	Chrome टीम ने GAM टीम से पुष्टि की है कि इस ट्रैफ़िक को अब प्रयोग से फ़िल्टर किया जा रहा है. हम इस समस्या पर यहां चर्चा कर रहे हैं. हमें अन्य सुझावों का भी स्वागत है.
एपीआई प्रयोग	PA API में ब्याज समूह-खरीदारों की लागू होने की क्षमता और निष्पक्षता.	हम PA API नीलामियों में, "interestGroupBuyers" फ़ील्ड की परफ़ॉर्मेंस और निष्पक्षता को लेकर चल रही चर्चा को समझते हैं. हम परफ़ॉर्मेंस, निजता, और मार्केट फ़ेयरनेस के बीच के अंतर को स्वीकार करते हैं. सेलर को, खरीदारों के साथ कारोबारी संबंध मैनेज करने होंगे. हालांकि, हम मैचिंग प्रोसेस को बेहतर बनाने के तरीके एक्सप्लोर कर रहे हैं. इनमें रीयल-टाइम डेटा और हाइब्रिड मॉडल के आधार पर, डाइनैमिक अडजस्टमेंट शामिल हो सकते हैं. हम उपयोगकर्ता की निजता को प्राथमिकता देने और प्रतिस्पर्धी विज्ञापन नेटवर्क की मदद करने वाले समाधान खोजने के लिए लगातार काम कर रहे हैं. हम इस समस्या पर यहां चर्चा कर रहे हैं. हमें अन्य सुझावों का भी स्वागत है.
Chrome का यूज़र इंटरफ़ेस (यूआई)	Chrome में IG से जुड़ी मेमोरी की समस्याएं और यूज़र इंटरफ़ेस (यूआई) की साफ़ तौर पर जानकारी.	हम DevTools में आईजी दिखाने से जुड़ी समस्याओं को समझते हैं. मौजूदा व्यू में, पुरानी ट्रैकिंग के सभी IG इवेंट दिखते हैं. हालांकि, हम स्टोर किए गए IGs की मौजूदा स्थिति को साफ़ तौर पर देखने की अहमियत स्वीकार करते हैं. हम डेवलपर की इनसाइट को बेहतर बनाने के लिए, ऑप्टिमाइज़ेशन और यूज़र इंटरफ़ेस (यूआई) में संभावित सुधारों पर काम करेंगे. मेमोरी मैनेजमेंट के लिए, IG को लागू करने के तरीके को मेमोरी लीक को रोकने के लिए डिज़ाइन किया गया है. हालांकि, हम संसाधन के इस्तेमाल पर लगातार नज़र रखते हैं और उसे ऑप्टिमाइज़ करते रहते हैं. हम इस समस्या पर यहां चर्चा कर रहे हैं. हमें अन्य सुझावों का भी स्वागत है.
दस्तावेज़	"joinAdInterestGroup" फ़ंक्शन के "sizeGroup" फ़ील्ड में सीधे नाम वाले विज्ञापन साइज़ का इस्तेमाल करने की कोशिश करते समय, मूल पोस्ट करने वाले को गड़बड़ी का सामना करना पड़ रहा है. वे जानना चाहते हैं कि क्या यह गलत व्यवहार है.	हम "joinAdInterestGroup" फ़ंक्शन में विज्ञापन कॉन्फ़िगरेशन को व्यवस्थित करने की वैल्यू को समझते हैं. हम इस समस्या को दूर करने के लिए लगातार काम कर रहे हैं. साथ ही, आने वाले समय में अपडेट में इस सुविधा को चालू करने की योजना बना रहे हैं. यह सुविधा, डेवलपर को विज्ञापन मैनेज करने के लिए सुविधाजनक और बेहतर टूल उपलब्ध कराने की हमारी प्रतिबद्धता को पूरा करती है. हम इस समस्या पर यहां चर्चा कर रहे हैं. हमें अन्य सुझावों का भी स्वागत है.
Chrome की सुविधा वाला टेस्टिंग लेबल	यह अनुरोध करें कि आपको मोड ए बनाम बी के बारे में डेटा को सीधे तौर पर ऐक्सेस करना चाहिए. साथ ही, sendReportTo में सटीक लेबल का इस्तेमाल करना चाहिए, ताकि हम एक्सपेरिमेंट को लगातार ट्रैक कर सकें.	हम इस अनुरोध के बारे में यहां चर्चा कर रहे हैं. साथ ही, हम आपको कुछ और सुझाव भी दे रहे हैं
दस्तावेज़	क्या विक्रेता का डोमेन नाम सत्यापन उद्देश्यों के लिए विक्रेता के विश्वसनीय सर्वर पर किए गए अनुरोधों में शामिल किया जाता है?	हम Protected Audience KV Server API से जुड़े दस्तावेज़ में, होस्टनेम पैरामीटर को हटाए जाने की पुष्टि करते हैं. हम डेवलपर को यह भरोसा दिलाना चाहते हैं कि सेलर के भरोसेमंद सर्वर को किए जाने वाले अनुरोधों में, सेलर का डोमेन नेम अपने-आप शामिल हो जाता है. विज्ञापन की पुष्टि करने की बेहतर प्रोसेस के लिए, यह सुविधा ज़रूरी है. हमने इस समस्या को हल करने के लिए दस्तावेज़ अपडेट किए हैं. साथ ही, डेवलपर कम्यूनिटी के लिए, साफ़ तौर पर जानकारी देने और पारदर्शिता को प्राथमिकता देते रहेंगे. हम इस समस्या पर यहां चर्चा कर रहे हैं. हमें अन्य सुझावों का भी स्वागत है.
एपीआई प्रयोग	रिपोर्टिंग के मकसद से, विज्ञापन इंप्रेशन ट्रैकिंग कॉल में IG का नाम शामिल करने के संभावित तरीके.	हम रिपोर्टिंग करने के बेहतर तरीकों और उपयोगकर्ता की निजता के बुनियादी सिद्धांतों के बीच संतुलन बनाने के लिए प्रतिबद्ध हैं. विज्ञापन इंप्रेशन ट्रैकिंग में IG के नामों को शामिल करने पर, लोगों की पहचान ज़ाहिर होने से रोकने के लिए बनाए गए सुरक्षा उपाय लागू होते हैं. ये सुरक्षा उपाय, लोगों की पहचान को रोकने के लिए बनाए गए हैं. हम निजता की सुरक्षा को ध्यान में रखते हुए, रिपोर्टिंग से जुड़े नए समाधान खोजना जारी रखेंगे. हम इस समस्या पर यहां चर्चा कर रहे हैं. हमें अन्य सुझावों का भी स्वागत है.
एपीआई की सुविधा	खरीदार के भरोसेमंद सर्वर से, क्लाइंट हिंट के एचटीटीपी हेडर पाने का अनुरोध करें.	हम सुविधा के इस अनुरोध को यहां ट्रैक कर रहे हैं.
एपीआई प्रयोग	क्या डेलिगेशन फ़ाइल को लोड करने के लिए "Access-Control-Allow-Origin" हेडर की ज़रूरत होनी चाहिए. हालांकि, यह इसलिए ज़रूरी है, क्योंकि यह ब्राउज़र की IG सदस्यता के व्यवहार को तय करती है?	हम वेब पर सुरक्षा के सबसे सही तरीकों को अपनाने के लिए प्रतिबद्ध हैं. डेटा ऐक्सेस करने वाली फ़ाइलों के लिए "Access-Control-Allow-Origin" हेडर की ज़रूरत, यह पक्का करती है कि सीओआरएस से जुड़े सिद्धांतों का पालन हो रहा हो और संवेदनशील जानकारी को अनजाने में सार्वजनिक होने से रोका जा सके. हम सुरक्षा को मज़बूत बनाने के साथ-साथ इस प्रक्रिया को ऑप्टिमाइज़ करने के तरीके खोज रहे हैं. हम इस समस्या पर यहां चर्चा कर रहे हैं. हमें अन्य सुझावों का भी स्वागत है.
एपीआई प्रयोग	PA API फ़्रेमवर्क में क्रिएटिव को लोगों के हिसाब से बनाने के लिए, विज्ञापन सर्वर चालू करें.	हम समझते हैं कि क्रिएटिव को मनमुताबिक बनाने में विज्ञापन सर्वर की भूमिका हो सकती है. हम PA API में विज्ञापन सर्वर को बेहतर बनाने के लिए लगातार समाधान ढूंढ रहे हैं. जैसे, 'जॉइंट IG' मॉडल, जहां बिडिंग और विज्ञापन क्रिएटिव चुनने के लॉजिक को एक साथ इस्तेमाल किया जा सकता है. हमारा लक्ष्य, विज्ञापन क्रिएटिव बनाने की बेहतर क्षमताओं को चालू करने और उपयोगकर्ता की निजता की सुरक्षा के बीच संतुलन बनाना है. हम यहां सभी हिस्सेदारों की ज़रूरतों को पूरा करने के लिए, इस एपीआई को बेहतर बनाने पर मिलकर काम करने और सुझाव, शिकायत या राय का स्वागत करते हैं.
गोपनीयता चिंताएँ	वैकल्पिक आइडेंटिफ़ायर की उपलब्धता (उदाहरण के लिए, संदर्भ के हिसाब से बिड रिक्वेस्ट में RampID, ID5) का इस्तेमाल करने से, PA API के निजता के लक्ष्यों को कम किया जा सकता है. ऐसा करने से, क्रॉस-साइट डेटा इकट्ठा करने में मदद मिलती है.	हम क्रॉस-साइट आइडेंटिफ़ायर और PA API के निजता से जुड़े मकसद के बीच होने वाले संभावित तनाव को समझते हैं. पब्लिशर इस तरह के आइडेंटिफ़ायर शेयर कर सकते हैं. हालांकि, PA API के डिज़ाइन का मकसद, विज्ञापन चुनने के विकल्प को क्रॉस-साइट ट्रैकिंग की ज़रूरत से अलग करना है. हम निजता पर आधारित विज्ञापन नेटवर्क को बढ़ावा देने के लिए प्रतिबद्ध हैं. साथ ही, हम डेवलपर को पीए एपीआई के तरीके को प्राथमिकता देने के लिए बढ़ावा देते हैं. हम इस समस्या पर यहां चर्चा कर रहे हैं. हमें अन्य सुझावों का भी स्वागत है.
कैश मेमोरी में सेव करना	क्या एक से ज़्यादा नीलामियों में, बिडिंग स्क्रिप्ट का फिर से इस्तेमाल होने से रोकने का कोई तरीका है?	हम पीए एपीआई फ़्रेमवर्क में, बिडिंग वाली स्क्रिप्ट के कैश मेमोरी में सेव होने के व्यवहार को स्वीकार करते हैं. हालांकि, एचटीटीपी कैश मेमोरी में डेटा सेव करने के स्टैंडर्ड तरीके काम करते हैं, लेकिन डिवाइस के निलंबन और बिडिंग एक्ज़ीक्यूट करने वालों के डिज़ाइन की वजह से, सभी नीलामियों में स्क्रिप्ट का फिर से इस्तेमाल किया जा सकता है. टीम, खरीदारों को स्क्रिप्ट को कैश मेमोरी में सेव करने की सुविधा पर ज़्यादा कंट्रोल देने के लिए, समाधान ढूंढ रही है, ताकि वे बिडिंग की रणनीतियों को बेहतर तरीके से मैनेज कर सकें. हम इस समस्या पर यहां चर्चा कर रहे हैं. हमें अन्य सुझावों का भी स्वागत है.
एपीआई प्रयोग	उपयोगकर्ता की निजता को ध्यान में रखते हुए, किसी डीएसपी के लिए सभी आईजी में बिडिंग से जुड़ी गतिविधियों की रिपोर्टिंग एक ही जगह पर करें.	PA API डिज़ाइन करते समय, हम उपयोगकर्ता की निजता को प्राथमिकता देते हैं. हालांकि, क्रॉस-साइट ट्रैकिंग के जोखिमों की वजह से, बिडिंग के अलग-अलग इवेंट की सीधे तौर पर रिपोर्टिंग नहीं की जा सकती. हालांकि, हम शेयर किए गए स्टोरेज और निजी एग्रीगेशन जैसे तरीकों की सुविधा देते हैं. इसकी मदद से, डीएसपी को बिडिंग की गतिविधि के बारे में अहम जानकारी मिलती है, ताकि उपयोगकर्ता की निजता को सुरक्षित रखा जा सके.
एपीआई प्रयोग	report Report() में sendReportTo() से फ़ेच करने की प्रोसेस, सिर्फ़ 94% मामलों में होती है. इसके लिए, forDebuggingOnly.reportAdनीलामीWin() में रजिस्टर किया जाता है.	ऐसा हो सकता है कि दोनों यूआरएल का समय एक जैसा न हो. हालांकि, दोनों यूआरएल को एक ही समय पर फ़ेच किया जा सकता है. कुछ मामलों में, कॉम्पोनेंट सेलर का वर्कलेट हटाया जाता है. इसके बाद, इसे report रिज़ल्ट() फ़ंक्शन को चलाने के लिए, फिर से लोड करना होता है. हालांकि, न तो स्कोरिंग लॉजिक को फ़ेच करने में और न ही वर्कलेट को फिर से लोड करने में लगने वाले समय, reportresults() के 50 मिलीसेकंड टाइम आउट पर असर डालते हैं. कृपया ध्यान दें कि Chrome उन मामलों में अपने फ़ेच करने का व्यवहार तय करने के लिए कैशिंग हेडर का इस्तेमाल करेगा जहां वर्कलेट को फिर से लोड करने की ज़रूरत होती है. यहां PA नीलामी के चरणों के बारे में ज़्यादा जानें.
के-ऐनिमिटी	इस बात की पुष्टि करने का अनुरोध कि इंटरेस्ट ग्रुप के नाम से, विज्ञापन दिखाने की k-ऐनामिटी पर कोई असर नहीं पड़ता.	किसी क्रिएटिव को k-अनाम (k-अनाम) तब माना जाता है, जब IG के मालिक का यूआरएल, बिडिंग स्क्रिप्ट का यूआरएल, क्रिएटिव यूआरएल, और विज्ञापन के साइज़ का टपल, पिछली समयावधि (w) में तय की गई सीमा (k) के अंदर हो. के-अनामता की स्थिति समय-समय पर अपडेट की जाती है (p).
Chrome का यूज़र इंटरफ़ेस (यूआई)	MVC, ORM वगैरह के फ़्रेमवर्क में मिलने वाली "इंटरनल विज़िबिलिटी" की सुविधा देने का प्रस्ताव. उदाहरण के लिए, डेवलपर टूल --> ऐप्लिकेशन --> ऐप्लिकेशन सेक्शन में एक नए पैनल में चुने गए इंटरनल इवेंट को आसानी से लॉग करने के साथ शुरू करें	हम इस प्रस्ताव के बारे में यहां चर्चा कर रहे हैं और अन्य सुझावों का स्वागत है.
Chrome का यूज़र इंटरफ़ेस (यूआई)	Dev टूल IG में, प्राथमिकता से जुड़े एलिमेंट नहीं दिखते.	हमने इस समस्या को यहां हल किया है.
एपीआई में सुधार	बेहतर होगा कि क्रिएटिव विज्ञापन सर्वर अपने इवेंट ट्रैक करने की अनुमति दे. क्या अनुमति वाले ट्रैकिंग डोमेन की सूची को कॉन्फ़िगर किया जा सकता है?	हमने यहां एक प्रस्ताव शेयर किया है. हमें नेटवर्क से अन्य सुझावों का भी स्वागत है.
API सुविधा का अनुरोध	क्या पीए एपीआई को गैर-आरटीबी मीडिया लेन-देन के साथ-साथ विज्ञापन दिखाने और डीसीओ जैसे ज़रूरी इस्तेमाल को बनाए रखने के लिए बढ़ाया जा सकता है?	हम इस समस्या पर यहां चर्चा कर रहे हैं और अन्य सुझावों का स्वागत है.
पब्लिशर की नीलामी का टाइम आउट	इंप्रेशन को खत्म होने से रोकने के लिए, पब्लिशर को नीलामी की अवधि पर कंट्रोल की ज़रूरत होती है. खास तौर पर, हेडर बिडिंग सेटअप में विज्ञापनों को क्रम से चुना जाता है.	हम पब्लिशर को विज्ञापन नीलामी के टाइम आउट पर पूरा कंट्रोल देने की अहमियत को स्वीकार करते हैं. हम इस बारे में लगातार पता लगा रहे हैं कि किनारे के मामलों पर सावधानी से विचार करते हुए, हम "नीलामी के लिए कॉन्फ़िगरेशन" ऑब्जेक्ट में, दुनिया भर में नीलामी का टाइम आउट होने की प्रोसेस को कैसे लागू कर सकते हैं. इस सुविधा का मकसद, पब्लिशर के लिए इंप्रेशन भरने के रेट को ऑप्टिमाइज़ करना है. साथ ही, हम सबसे अच्छा हल ढूंढने के लिए समुदाय के साथ मिलकर काम करते रहेंगे. हम इस समस्या पर यहां चर्चा कर रहे हैं और अन्य सुझावों का स्वागत है.
एपीआई में सुधार	PA API में IG के मौजूदा डिज़ाइन से, रेंडर करने में लगने वाले लंबे यूआरएल की वजह से मेटाडेटा का साइज़ बड़ा हो जाता है. जांच करने वाले लोग बेहतर परफ़ॉर्मेंस के लिए, इन यूआरएल को कंप्रेस करने का तरीका जानना चाहते हैं.	हम IG मेटाडेटा के साइज़ को ऑप्टिमाइज़ करने की अहमियत को समझते हैं. खास तौर पर, ऐसी विज्ञापन नीलामियों के लिए जिनमें परफ़ॉर्मेंस की संभावना को ध्यान में रखा गया हो. हमें लगता है कि रेंडर यूआरएल को कंप्रेस करने के लिए, टेंप्लेट पर आधारित समाधान की मदद से काफ़ी संभावना होती है. हम प्रस्तावित टेम्प्लेट डिज़ाइन का ध्यान से आकलन करेंगे और यह पक्का करेंगे कि लागू किए गए सभी समाधान में ब्राउज़र की स्थिरता बनाए रखने के लिए बेहतरीन गलत इस्तेमाल को रोकने के तरीके शामिल हों. इन बातों को ध्यान में रखते हुए, वेब मानकों वाली कम्यूनिटी के साथ मिलकर काम करना हमारी प्राथमिकता है. हम इस समस्या पर यहां चर्चा कर रहे हैं और अन्य सुझावों का स्वागत है.
एपीआई प्रयोग	नेटिव विज्ञापन फ़ॉर्मैट को मैनेज करने वाले टेस्टर, प्राइवसी सैंडबॉक्स की नीलामी की प्रोसेस को ऑप्टिमाइज़ करना चाहते हैं. इसके लिए, उन्हें एक ही कॉल में कई विज्ञापन नतीजे मिलते हैं. इससे नेटवर्क लोड कम होता है और विज्ञापन को रेंडर करने की स्पीड बेहतर होती है.	हम प्राइवसी सैंडबॉक्स में, नेटिव विज्ञापन रेंडरिंग की परफ़ॉर्मेंस से जुड़ी समस्याओं को समझते हैं. हम परफ़ॉर्मेंस और उपयोगकर्ता की निजता सुरक्षा के बीच संतुलन बनाने के लिए प्रतिबद्ध हैं. पूरे स्कोर के साथ कई विज्ञापन दिखाने से निजता की सुरक्षा होती है. हालांकि, हम नीलामी की प्रक्रिया को ऑप्टिमाइज़ करने के अलग-अलग तरीके एक्सप्लोर कर रहे हैं. हम नेटिव विज्ञापन फ़ॉर्मैट के लिए, PA API से जुड़ी सहायता को बेहतर बनाने और प्राइवसी सैंडबॉक्स की निजता से जुड़ी पाबंदियों के तहत, काम करने के अन्य तरीकों की जांच करने की कोशिश कर रहे हैं. हम इस समस्या पर यहां चर्चा कर रहे हैं और अन्य सुझावों का स्वागत है.
एपीआई प्रयोग	प्राइवसी सैंडबॉक्स में, विज्ञापन बिड को स्कोर करने और क्रम से लगाने के तरीके में सुविधा. खास तौर पर, प्रायॉरिटी लेवल या प्राइवेट मार्केटप्लेस के नियमों को दिखाने के लिए ऐसा किया जाता है.	हम जानते हैं कि प्राइवसी सैंडबॉक्स में, विज्ञापनों के लिए स्कोरिंग और क्रम में लगाने की ज़रूरत होती है. खास तौर पर, बिडिंग से जुड़े मुश्किल मामलों में. हम उपयोगकर्ता की निजता को गंवाए बिना बहु-आयामी स्कोर हासिल करने के लिए, टूल और गणितीय फ़ंक्शन का इस्तेमाल करके प्रस्तावित समाधान स्वीकार करते हैं. इन तरीकों से डेवलपर को समझना मुश्किल हो सकता है. हालांकि, इन तरीकों से डेवलपर को कई ज़रूरी जानकारी मिलती है. हम हेल्पर फ़ंक्शन या दिशा-निर्देशों की मदद से, इन प्रोसेस को आसान बनाने के तरीके खोजने के लिए लगातार काम कर रहे हैं. इससे, यह पक्का किया जा सकेगा कि नीलामी के बेहतर लॉजिक के लिए, प्राइवसी सैंडबॉक्स की सुविधाओं का इस्तेमाल ज़्यादा से ज़्यादा हो. हम इस समस्या पर यहां चर्चा कर रहे हैं. हमें अन्य सुझावों का भी स्वागत है.
reportEvent()	किसी विज्ञापन क्रिएटिव वाला फ़्रेम शुरू होने के बाद, ब्राउज़र से ट्रिगर किया गया एक नया रिज़र्व इवेंट (शायद ऑटोमैटिक बीकन) जोड़ें.	हम इस अनुरोध के बारे में यहां चर्चा कर रहे हैं और आपके कुछ और सुझाव, शिकायत या राय का स्वागत है.
adCost	विज्ञापन की लागत को अलग-अलग दिखाने की अनुमति दी गई है.	हर लागत वैल्यू एक मौका है, जिसकी मदद से नीलामी से एक सीमित जानकारी भेजी जा सकती है. उन लागतों की पूरी सूची N की अनुमति देना ही एक पूरा उपयोगकर्ता आइडेंटिफ़ायर भेजने के लिए काफ़ी होगा, जिससे क्रॉस-साइट ट्रैकिंग चालू हो जाएगी. हम इस बारे में यहां चर्चा कर रहे हैं और अन्य सुझावों का स्वागत है.
resolveToConfig	क्या preventToConfig को टॉप लेवल से इनहेरिट करके, ब्राउज़र सिग्नल में दिखाया जाना चाहिए?	हम इस अनुरोध के बारे में यहां चर्चा कर रहे हैं और आपके कुछ और सुझाव, शिकायत या राय का स्वागत है.
बेहतर टूल	क्या chrome://topics-internals जैसा कुछ है, लेकिन PA API के लिए है?	वास्तव में कुछ भी एक जैसा नहीं होता. हालांकि, PA API के लिए डेवलपर के लिए बड़े पैमाने पर टूल उपलब्ध हैं .
लेबल	क्या Chrome 20% k-anon जनसंख्या की पहचान करने के लिए लेबल का इस्तेमाल कर सकता है?	हम इस अनुरोध पर विचार कर रहे हैं और नेटवर्क से अतिरिक्त सुझाव, शिकायत या राय का स्वागत कर रहे हैं.
दस्तावेज़	क्या प्राइवसी सैंडबॉक्स की नीलामी के वर्कलेट, स्टैंडर्ड वर्कलेट टाइप में बदल जाएंगे?	निजता और सुरक्षा से जुड़ी खास ज़रूरतों की वजह से, ये वर्कलेट स्टैंडर्ड ब्राउज़र वर्कलेट के टाइप से काफ़ी अलग होते हैं. इसलिए, हमें नहीं लगता कि ये वर्कलेट जल्द ही एचटीएमएल स्पेसिफ़िकेशन के मुताबिक स्टैंडर्ड वर्कलेट टाइप में बदल जाएंगे. हम अपने डेवलपर रिसॉर्स को बेहतर बनाने के लिए प्रतिबद्ध हैं. साथ ही, हम नीलामी वाले वर्कलेट को लागू करने और उसे चलाने के तरीके के बारे में साफ़ तौर पर जानकारी देते हैं, ताकि प्राइवसी सैंडबॉक्स में हिस्सा लेने वाले लोगों के लिए यह जानकारी ज़्यादा आसानी से ऐक्सेस की जा सके. हमने इस बारे में यहां ज़्यादा चर्चा की है.
Bring-Your-खुद-सर्वर (BYOS) की-वैल्यू (KV) सर्वर	BYOS KV सेवा सेटअप में केवी सेवाओं की क्वेरी के ज़रिए, कोई भी पक्ष एक से ज़्यादा IG (एक ही मालिक से) को सीख सकता है.	जब टीईई में केवी सर्वर चलते हैं, तो ऐसा नहीं किया जा सकता. साथ ही, हम यह पक्का कर सकते हैं कि वे पब्लिश किए गए ट्रस्ट मॉडल का पालन करें.
userBiddingSignals	अन्य उपयोगकर्ताओं को मैनेज करते हुए, "userबिडिंगSignals" के कुछ हिस्से को अपडेट करें.	एपीआई में बिना किसी बदलाव के यह पहले से ही मुमकिन है.
एपीआई प्रयोग	प्राइवसी सैंडबॉक्स में, कई आईजी पर फ़्रीक्वेंसी कैपिंग लागू करें. इसके लिए, केवी सर्वर या बदले गए "prevWinsMs" डेटा का इस्तेमाल किया जा सकता है.	हम प्राइवसी सैंडबॉक्स में, फ़्रीक्वेंसी कैपिंग की बेहतर सुविधाओं की ज़रूरत को स्वीकार करते हैं. हम मानते हैं कि IG के सभी प्लैटफ़ॉर्म पर डेटा शेयर करने पर लगी मौजूदा पाबंदियों की वजह से, इन रणनीतियों को लागू करते समय चुनौतियां आ सकती हैं. केवी सर्वर पर निजता के सुरक्षा के सही उपायों के लिए बेहतरीन उपाय उपलब्ध हैं. हालांकि, हम डेवलपर को सुझाव देते हैं कि वे सिंगल IG मॉडल में समाधान एक्सप्लोर करें. हम इस समस्या पर यहां चर्चा कर रहे हैं. हमें अन्य सुझावों का भी स्वागत है.
एपीआई प्रयोग	कॉम्पोनेंट सेलर (जो प्राइवसी सैंडबॉक्स में नेस्ट की गई नीलामियों में हिस्सा लेते हैं), को अपने कॉन्फ़िगरेशन को ऑप्टिमाइज़ करने और बेवजह की देरी से बचने के लिए, नीलामी के टॉप-लेवल के टाइम आउट में जानकारी की ज़रूरत होती है.	हम जानते हैं कि प्राइवसी सैंडबॉक्स में, टॉप लेवल सेलर और कॉम्पोनेंट सेलर के बीच, टाइम आउट को बेहतर तरीके से मैनेज करने की ज़रूरत है. हम टाइम आउट के नए तरीके जोड़ने की सक्रिय रूप से जांच कर रहे हैं. इनमें पूरी नीलामी का संभावित टाइम आउट शामिल है. साथ ही, हम कॉम्पोनेंट नीलामियों के लिए टॉप-लेवल टाइम आउट लागू करने के तरीके एक्सप्लोर कर रहे हैं. हमारा लक्ष्य, प्राइवसी सैंडबॉक्स की नीलामी की प्रोसेस में हिस्सा लेने वाले सभी लोगों के लिए, परफ़ॉर्मेंस को बेहतर करना और अनुमान लगाने की क्षमता को बेहतर बनाना है. हम इस समस्या पर यहां चर्चा कर रहे हैं. हमें अन्य सुझावों का भी स्वागत है.

सुरक्षित ऑडियंस की सेवाएं

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई)	क्या TEE को विज्ञापन टेक्नोलॉजी के डेटा सेंटर में चलाने के बजाय, सार्वजनिक क्लाउड पर चलाना ज़्यादा महंगा है?	हमारा जवाब पिछली तिमाहियों से मिलता-जुलता है: हमारे मौजूदा टीईई सुरक्षा मॉडल को, सार्वजनिक क्लाउड लागू करने के तरीकों से फ़ायदा मिलता है. खास तौर पर, हार्डवेयर पर आधारित मौजूदा टीईई, सभी तरह के शारीरिक हमलों से बचाव नहीं करते. हमारी मौजूदा सार्वजनिक क्लाउड सेवा देने वाली कंपनियां, AWS और GCP ने कर्मचारियों के साथ-साथ फ़िज़िकल ऐक्सेस से जुड़े जोखिमों को कम करने के तरीके तैयार किए हैं और उन्हें लागू किया है. कंपनी की इमारत में दी जाने वाली सहायता के बारे में ज़्यादा जानकारी नीचे दी गई है. विज्ञापन टेक्नोलॉजी ने हमें बताया है कि क्लाउड सेवाएं चलाना, विज्ञापन टेक्नोलॉजी के डेटा सेंटर की तुलना में ज़्यादा महंगा होता है. हालांकि, हम इस जानकारी का आकलन नहीं कर सकते, लेकिन हम कीमतों को लेकर अतिरिक्त सुझाव, शिकायत या राय का स्वागत करते हैं. हम टीईई से जुड़ी अपनी सहायता को बढ़ाने के लिए, विकल्पों का आकलन करते रहते हैं.
टीईई	निजी क्लाउड प्लैटफ़ॉर्म में टीईई के लिए सहायता	हमारा जवाब पिछली तिमाही की तरह ही है: हम सार्वजनिक क्लाउड-आधारित समाधानों के अलावा, अन्य विकल्पों के लिए लगातार काम कर रहे हैं. फ़िलहाल, हमारी कंपनी की इमारत में मौजूद टीईई को सपोर्ट करने की कोई योजना नहीं है. प्राइवसी सैंडबॉक्स की सुरक्षा से जुड़ी ज़रूरी शर्तों और कंपनी में डिप्लॉयमेंट की वजह से आने वाली अहम चुनौतियों को देखते हुए, इस चरण में हमारा मानना है कि क्लाउड-आधारित डिप्लॉयमेंट (उदाहरण के लिए, AWS के साथ-साथ Google Cloud के साथ-साथ काम करना) का दायरा बढ़ाते रहना और उसमें सुधार करना सबसे ज़्यादा फ़ायदेमंद है. हालांकि, निजता और सुरक्षा की सीमाओं को ध्यान में रखते हुए, इस तरह की ज़रूरी शर्त को पूरा करना ज़रूरी क्यों है, इस बारे में हम आपसे और सुझाव, शिकायत या राय का स्वागत करते हैं.
क्लाउड की सेवा देने वाली अन्य कंपनियां	क्लाउड सेवा देने वाली अन्य कंपनियों के लिए सहायता	हम क्लाउड की सेवा देने वाली अन्य कंपनियों के सुझावों के लिए हमेशा तैयार रहते हैं. हालांकि, 3PCD लागू होने पर, हम कम से कम GCP और AWS के साथ काम करने की योजना बना रहे हैं. ज़्यादा जानकारी के लिए, यह जानकारी देखें.
B&A सेवाओं का एपीआई	B&A Services API के लिए Google का निर्देश क्या है? क्या डिवाइस की नीलामियों में इसे Chrome ब्राउज़र की सुरक्षित ऑडियंस के ऊपर या नीचे प्राथमिकता दी जाएगी?	हमारा जवाब पिछली तिमाही जैसा ही है: हम मौजूदा Protected Audience on-डिवाइस बिडिंग डिज़ाइन के लिए प्रतिबद्ध हैं. बीऐंडए सेवाओं को इस्तेमाल के उन मामलों में मदद करने के लिए संभावित समाधान खोजने का प्रस्ताव दिया गया है जहां डिवाइस की कंप्यूटेशनल पावर या नेटवर्क स्पीड सीमित हो सकती है.
मानक तय करना	बीऐंडए सेवाओं के लिए स्टैंडर्ड तय करने की प्रक्रिया पूरी नहीं हुई है.	बीऐंडए सेवाओं का प्रस्ताव, मानक तय करने की प्रक्रिया के एक चरण के बीच में है. हम उस लक्ष्य को पूरा करने के लिए, इसमें और लोगों की दिलचस्पी का स्वागत करते हैं. इसकी शुरुआत एक प्रस्ताव (पिछले प्रस्तावों के आधार पर) के साथ की गई है. इसे W3C में व्यापक बातचीत के ज़रिए सार्वजनिक तौर पर शामिल किया जा रहा है. इसमें दिलचस्पी रखने वाले डेवलपर, इसके साथ प्रयोग करना शुरू कर सकते हैं और सुझाव दे सकते हैं. यह वेब सुविधाओं के डेवलपमेंट का सामान्य पैटर्न है, जैसा कि हमारी ब्लॉग पोस्ट में यहां बताया गया है.
केवी सर्वर	कॉन्टेंट / कॉन्टेक्स्ट के हिसाब से / साइट टारगेटिंग के लिए, खरीदार के केवी सर्वर पर पूरा यूआरएल दिखाएं.	हम इस अनुरोध के बारे में यहां चर्चा कर रहे हैं. साथ ही, नेटवर्क से हमें अन्य सुझाव, शिकायत या राय भी मिल सकती है.
दस्तावेज़	GitHub पर "भरोसेमंद/लागू किए गए कॉम्पोनेंट बनाम वैकल्पिक" के दस्तावेज़ से कुछ विज्ञापन टेक्नोलॉजी के लिए भ्रम की स्थिति होती है. इन टेक्नोलॉजी के पास, डिप्लॉयमेंट इमेज और इन्फ़्रास्ट्रक्चर का अपना सेट होता है.	हम "भरोसेमंद/लागू किए गए कॉम्पोनेंट बनाम वैकल्पिक" के दस्तावेज़ को और बेहतर बनाना चाहते हैं. साथ ही, हम नेटवर्क से इसकी जानकारी पाना चाहते हैं, अगर इस तरह के काम को प्राथमिकता देने की ज़रूरत हो.
एपीआई में सुधार	KV सर्वर कॉल का एचटीटीपी स्टेटस कोड, पैरामीटर के तौर पर ScoreAd() फ़ंक्शन में भी उपलब्ध होना चाहिए.	हम इस अनुरोध की समीक्षा कर रहे हैं. हमें नेटवर्क से मिलने वाले अन्य सुझावों का भी स्वागत है.
दस्तावेज़	इस बारे में ज़्यादा जानकारी दें कि यूडीएफ़ एक्ज़ीक्यूशन के साथ JS और WASM वर्कलोड सही तरीके से कैसे हैंडल किए जाएंगे.	हम इस जानकारी को उपलब्ध कराने के लिए काम कर रहे हैं. साथ ही, हम आपको यहां अन्य सुझाव, शिकायत या राय ज़रूर भेज सकते हैं.
दस्तावेज़	रेपो का नाम अपडेट करने का अनुरोध करें.	हमने डेटा स्टोर करने की जगह का नाम बदलकर "सुरक्षित नीलामी-की-वैल्यू-सेवा" कर दिया है. यह डेटा, इससे जुड़ी सेवाओं के कलेक्शन के लिए तय किए गए शब्द के मुताबिक है. इसके अन्य स्टोर भी हैं, जैसे कि Protected Audience Services की चर्चा, और Protected ऑक्शन Services के दस्तावेज़ डेटा स्टोर करने की जगहें.
दस्तावेज़	Bidding_नीलामी_services_gcp_guide.md में, Cloud डीबगर एपीआई का रेफ़रंस हटाएं.	हमने दस्तावेज़ में बदलाव किया है और रेफ़रंस हटा दिया है.
एपीआई प्रयोग	केवी लुकअप के ज़रिए पेश की गई इंतज़ार के समय में 50 मि॰से॰ से ज़्यादा समय लग रहा है. इसमें करीब 100 मिलीसेकंड लग रहे हैं. क्या आपके पास इस बारे में कोई सुझाव है कि दूसरे सेलर को कौनसी चीज़ें पसंद आ रही हैं? क्या आपके पास टाइम आउट और समय मापने के तरीके के बारे में कोई सुझाव है?	केवी सर्वर कॉल, स्क्रिप्ट रनर के संदर्भ में होता है. इसका मतलब है कि Chrome ब्राउज़र में एक खास सुरक्षित एनवायरमेंट है. इसका मकसद, इन स्क्रिप्ट रनर की जानकारी को गैर-एपीआई ऐक्सेस से सुरक्षित रखना है. हमने इस बारे में पूरी जानकारी यहां दी है.
एपीआई प्रयोग	क्या केवी सर्वर पर किसी खास समय पर जवाब देने के लिए टाइम आउट है?	विक्रेता, नीलामी के कॉन्फ़िगरेशन में "per एक्सेस रीच के टाइम आउट" फ़ील्ड के बारे में बता सकते हैं. इस टाइम आउट में वह समय शामिल है जो बिडिंग के भरोसेमंद सिग्नल को फ़ेच करने के लिए ज़रूरी है.
इंतज़ार का समय	प्राइवसी सैंडबॉक्स की टीम, इंतज़ार के समय से निपटने के लिए कैसे काम कर रही है?	इंतज़ार के समय को तय सीमा में रखने के लिए, हम जिन रणनीतियों पर काम कर रहे हैं उनके बारे में जानने के लिए यहां जाएं.

डिजिटल विज्ञापनों का आकलन करना

एट्रिब्यूशन रिपोर्टिंग (और अन्य एपीआई)

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
मैन्युअल अभियान ऑप्टिमाइज़ेशन	ARA में, मैन्युअल तौर पर कैंपेन ऑप्टिमाइज़ेशन की सुविधा काम नहीं करती.	हमने विज्ञापन टेक्नोलॉजी से इस स्थिति पर चर्चा की है. साथ ही, मैन्युअल कैंपेन ऑप्टिमाइज़ेशन में ARA को इस्तेमाल करने के तरीके बताए हैं. ARA को इस तरह से बनाया गया है कि विज्ञापन टेक्नोलॉजी को पसंद के मुताबिक बनाया जा सके. साथ ही, इससे विज्ञापन टेक्नोलॉजी से जुड़ी कई तरह की समस्याओं को हल करने में मदद मिलती है. हमने कुछ सुझाव दिए थे, जो अलग-अलग सुविधाजनक इवेंट-लेवल कॉन्फ़िगरेशन का इस्तेमाल करके दिए गए थे. इनमें, खास जानकारी वाली रिपोर्ट के साथ इवेंट-लेवल की रिपोर्ट का इस्तेमाल किया गया था. इससे शोर के असर को कम करने के साथ-साथ, मैन्युअल और ऑटोमैटिक ऑप्टिमाइज़ेशन की ज़रूरतें पूरी की जा सकती थीं. हम ARA कॉन्फ़िगरेशन को पसंद के मुताबिक बनाने और उनके लचीलेपन के बारे में अन्य नेटवर्क से जुड़े सुझाव, शिकायत या राय पाने के लिए तैयार हैं.
रूपांतरण प्रकार	Google सिर्फ़ आठ कन्वर्ज़न टाइप की अनुमति दे रहा है, जो सीमित है.	हमने सुविधाजनक इवेंट-लेवल रिपोर्टिंग में से ज़्यादातर को लागू किया है. इससे विज्ञापन टेक्नोलॉजी को रिपोर्टिंग विंडो की संख्या, एट्रिब्यूशन रिपोर्ट की संख्या, और ट्रिगर डेटा के कुछ हिस्सों के हिसाब से ज़्यादा सहूलियत मिलती है. विज्ञापन टेक्नोलॉजी, 32 अलग-अलग तरह के कन्वर्ज़न को मेज़र करने के लिए कॉन्फ़िगरेशन चुन सकती हैं.
एग्रीगेटेबल रिपोर्ट इवेंट की सीमा	इकट्ठा की जा सकने वाली रिपोर्ट में, कम से कम 20 कन्वर्ज़न इवेंट होने चाहिए. यह सुविधा, विज्ञापन देने वाले उन छोटे लोगों या कंपनियों के लिए काम नहीं करती जिनका बजट सीमित है.	एग्रीगेट की जा सकने वाली रिपोर्ट के लिए, कम से कम कन्वर्ज़न इवेंट की ज़रूरत नहीं होती. इसके अलावा, विज्ञापन देने वाले छोटे लोगों के लिए एग्रीगेटेड रिपोर्ट को ऑप्टिमाइज़ करने के लिए, डिज़ाइन से जुड़े कई फ़ैसले लिए जा सकते हैं. जैसे, मुख्य स्ट्रक्चर / डाइमेंशन को ट्रैक करना, ऐप्लिकेशन के अलग-अलग लेवल को टेस्ट करना, लंबे बैच की फ़्रीक्वेंसी को टेस्ट करना, और मेज़रमेंट के लक्ष्यों के बीच अलग-अलग योगदान बजट के आवंटन को टेस्ट करना. छोटे विज्ञापन टेक्नोलॉजी वाले नतीजों की रिपोर्ट को अलग-अलग परफ़ॉर्मेंस रिपोर्ट के साथ प्रयोग करके प्रयोग किया जा सकता है.
रीयल-टाइम डेटा	डीएसपी को रीयल-टाइम डेटा (जैसे कि क्लिक, सेशन, और कन्वर्ज़न से जुड़ा डेटा) उपलब्ध न कराने पर भी, मौजूदा सुविधाओं का रखरखाव नहीं किया जाता. ऐसा इसलिए, क्योंकि डीएसपी को अपनी बिडिंग की रणनीति में बदलाव करने और कैंपेन की परफ़ॉर्मेंस को बेहतर बनाने के लिए इस्तेमाल किया जाता है.	ARA में भी, क्लिक और सेशन रीयल टाइम होते हैं. साथ ही, 3PC के साथ भी कन्वर्ज़न हमेशा इस तथ्य के बाद होते हैं.
फ़ील्‍ड गुम हैं	सुविधाजनक इवेंट के रोल आउट में ज़रूरी शर्तें पूरी नहीं की गई हैं: i) मुद्रा वाला फ़ील्ड और ii) orderID / TransactionID फ़ील्ड.	फ़िलहाल, हम किसी मुद्रा फ़ील्ड या ऑर्डर आईडी / लेन-देन आईडी फ़ील्ड को पूरे सुविधाजनक इवेंट-लेवल के हिस्से के तौर पर इस्तेमाल नहीं करना चाहते हैं, क्योंकि ऐसा करने के लिए मौजूदा इवेंट-लेवल रिपोर्टिंग के पहले से ही तरीके उपलब्ध हैं. हम इन फ़ील्ड के बारे में अन्य सुझाव देने के लिए तैयार हैं. साथ ही, हम उन मामलों पर फिर से विचार करेंगे जिनके लिए ये फ़ील्ड ज़रूरी हैं. ARA के मौजूदा डिज़ाइन को इस्तेमाल करके, मुद्रा और ऑर्डर आईडी जैसी जानकारी का पता लगाने के तरीके: 1. सुझाव के आधार पर, मुद्रा उपयोगकर्ता की जगह के आधार पर तय की जाती है. इसे source_event_id के हिस्से के तौर पर जोड़ा जा सकता है, ताकि यह पता लगाया जा सके कि कौनसी मुद्रा इस्तेमाल की गई है. 2. सुझाव के आधार पर, ऑर्डर आईडी फ़ील्ड को यह पक्का करने के लिए ऑर्डर आईडी फ़ील्ड की ज़रूरत होती है कि कन्वर्ज़न और वैल्यू की गिनती गलती से न हो. ऐसा डुप्लीकेट कॉपी हटाने की सुविधा का इस्तेमाल करके किया जा सकता है.
निजता बजट	ARA के प्राइवसी बजट से, कई डाइमेंशन में आकलन करने की सुविधा पर असर पड़ता है	ARA को इस तरह से डिज़ाइन किया गया है कि विज्ञापन से जुड़ी टेक्नोलॉजी, अलग-अलग एट्रिब्यूशन स्थितियों को ध्यान में रखते हुए ARA कॉन्फ़िगरेशन को अपनी पसंद के मुताबिक बना सकें. मौजूदा ARA डिज़ाइन में, विज्ञापन टेक्नोलॉजी को समझने के लिए इस बात का ध्यान रखना होगा कि उनके लिए कौनसा डाइमेंशन सबसे अहम है. साथ ही, उन्हें इस बात का भी ध्यान रखना होगा कि उनके डेटा पर, ग़ैर-ज़रूरी आवाज़ों का क्या असर पड़ता है. मेज़र किए जा रहे डाइमेंशन की जानकारी के हिसाब से, डेटा में गै़र-ज़रूरी डेटा शामिल करना निजता के लिए ज़रूरी है. हम अलग-अलग डाइमेंशन के लिए नेटवर्क से जुड़े अन्य सुझाव पाने के लिए तैयार हैं. हालांकि, हमें इस्तेमाल के उन खास मामलों को समझने की ज़रूरत है जिनके लिए इस डेटा की ज़रूरत होती है.
स्पेसिफ़िकेशन को अपडेट करें	हालांकि, Google ने कहा है कि यह तय किए गए इवेंट रिपोर्टिंग विंडो में तय समय के हिसाब से काम कर रहा है. हालांकि, Google की तकनीकी जानकारी में इस जानकारी को नहीं दिखाया गया है. फ़िलहाल, इसमें सिर्फ़ एक घंटे की समयावधि शामिल है.	सुविधाजनक इवेंट-लेवल रिपोर्टिंग, फ़िलहाल विज्ञापन टेक्नोलॉजी को हर सोर्स इवेंट के लिए एट्रिब्यूशन रिपोर्ट की संख्या, ट्रिगर डेटा के बिट, और रिपोर्टिंग विंडो की संख्या/अवधि बदलने की अनुमति देती है. ARA में अब भी इवेंट-लेवल की रिपोर्ट के लिए, कम से कम एक घंटे की रिपोर्टिंग विंडो है. यह डेटा, निजता को बनाए रखने और कुछ खास तरह के इतिहास को फिर से बनाने के हमलों को कम करने के लिए ज़रूरी है. खास जानकारी वाली रिपोर्ट में पूरी तरह से जानकारी दी जाती है. इसलिए, विज्ञापन टेक्नोलॉजी के इस्तेमाल के उदाहरण में ज़रूरत पड़ने पर, वे तुरंत एग्रीगेट रिपोर्ट पाने के लिए ऑप्ट-इन कर सकते हैं.
एपीआई डिज़ाइन	इस बात को लेकर चिंता है कि कन्वर्ज़न रिपोर्ट में जानकारी कम करने और ग़ैर-ज़रूरी आवाज़ें जोड़ने से, Google के अलावा नेटवर्क पर भी ज़्यादा असर हो सकता है.	Google ने प्राइवसी सैंडबॉक्स के प्रपोज़ल को डिज़ाइन और लागू करने के लिए प्रतिबद्ध है. साथ ही, वह प्राइवसी सैंडबॉक्स के प्रपोज़ल को इस तरह से डिज़ाइन और लागू करने के लिए प्रतिबद्ध है कि Google के अपने कारोबार को प्राथमिकता देते हुए प्रतिस्पर्धा की वजह से कोई गड़बड़ी न हो. साथ ही, वह डिजिटल विज्ञापन के साथ-साथ, छोटे-बड़े पब्लिशर और विज्ञापन देने वाले लोगों या कंपनियों पर पड़ने वाले मुकाबले के असर को भी ध्यान में रखे.
एट्रिब्यूशन में सुधार	ARA, तकनीक से जुड़ी सेवा देने वाली कंपनी को सही एट्रिब्यूशन को कंट्रोल करने और उसकी पुष्टि करने की अनुमति नहीं देता है.	ARA में ऐसे कई समाधान हैं जो पुष्टि करने की सुविधाएं देते हैं: 1. विज्ञापन टेक्नोलॉजी से यह पुष्टि की जा सकती है कि ARA का व्यवहार उनकी उम्मीदों पर खरा उतरता है: – ARA क्लाइंट-साइड कोड ओपन सोर्स होता है. – ARA सर्वर-साइड कोड भी ओपन सोर्स होता है. साथ ही, कोऑर्डिनेटर यह पक्का करते हैं कि एग्रीगेशन सेवा के सिर्फ़ ऐसे वर्शन ही डिक्रिप्ट और प्रोसेस कर सकें जिन्हें अनुमति मिली हो. 2. Chrome ने एट्रिब्यूशन के व्यवहार की पुष्टि करने के लिए, विज्ञापन की टेक्नोलॉजी को सिम्युलेशन लाइब्रेरी की सुविधा के साथ उपलब्ध कराया है. यहां विज्ञापन टेक्नोलॉजी से यह पता लगाया जा सकता है कि मॉक एनवायरमेंट में ARA, एट्रिब्यूशन की परफ़ॉर्मेंस कैसे करता है. 3. ARA, कई डीबग सिग्नल के साथ काम करता है. इनसे यह पुष्टि करने में मदद मिलती है कि अनुमानित प्रोसेसिंग हो रही है या नहीं और क्यों नहीं हुई है.
(पिछली तिमाही में भी रिपोर्ट किया गया) शोर	आपको यह बताना होगा कि गै़र-ज़रूरी डेटा बहुत ज़्यादा है और इसकी वजह से रिपोर्टिंग की ज़रूरत पर असर पड़ रहा है.	हमने इन्हीं सुझावों के आधार पर, विज्ञापन टेक्नोलॉजी से जुड़ी कंपनियों से बातचीत की है. इससे हमें उन तरीकों का पता चला जिनसे ARA को शोर में भी अपनी ज़रूरत के मुताबिक बनाया जा सकता है. हमारे पास डेवलपर दस्तावेज़ हैं. इनमें डिज़ाइन से जुड़े ज़्यादातर फ़ैसले और कस्टमाइज़ेशन शामिल हैं, जिन पर हमने विज्ञापन टेक्नोलॉजी से जुड़ी चर्चा की है. ARA को इस तरह से डिज़ाइन किया गया है कि विज्ञापन टेक्नोलॉजी से जुड़ी कंपनियां, अपने ARA कॉन्फ़िगरेशन को पसंद के मुताबिक बना सकें. ऐसा करने से, वे कई तरह के एट्रिब्यूशन मॉडल को कवर कर पाएंगे. हालांकि, विज्ञापन टेक्नोलॉजी को मापने के लिए सबसे ज़रूरी डाइमेंशन और उनके डेटा पर नॉइज़ के असर के बीच संतुलन बनाना होगा. हम शोर के असर के बारे में नेटवर्क से अतिरिक्त सुझाव पाने के लिए तैयार हैं. साथ ही, हम ARA लीवर पर अतिरिक्त दिशा-निर्देश दे सकते हैं, जिसका इस्तेमाल शोर के असर को बदलने के लिए किया जा सकता है.
क्रॉस-डोमेन एट्रिब्यूशन	क्रॉस डोमेन वाले एट्रिब्यूशन को कैसे ट्रैक करें?	इस्तेमाल के इस उदाहरण को हल करने के लिए, विज्ञापन तकनीकें, रिपोर्टिंग के अलग-अलग यूआरएल पर रीडायरेक्ट कर सकती हैं. हम ARA के इस डिज़ाइन के पहलू को लेकर, नेटवर्क से जुड़े अन्य सुझाव देने के लिए तैयार हैं.
एपीआई में सुधार	ARA की खास जानकारी वाली रिपोर्ट के लिए, एट्रिब्यूशन को रजिस्टर करते समय इस्तेमाल किए जाने वाले स्केलिंग फ़ैक्टर को नियमित रूप से बदलें.	GitHub पर हुई बातचीत को देखकर, ऐसा लगता है कि एग्रीगेशन सर्विस में स्केलिंग फ़ैक्टर को हैंडल करने से खास जानकारी वाली रिपोर्ट में ज़्यादा ग़ैर-ज़रूरी आवाज़ें जुड़ सकती हैं. हम एग्रीगेट की जा सकने वाली रिपोर्ट में चीज़ों को स्केल करने से जुड़े सुझाव, शिकायत या राय के लिए तैयार हैं. हालांकि, हम ज़्यादा शोर के साथ संभावित डील को शामिल करना चाहते हैं. हम यह भी आकलन कर रहे हैं कि आने वाले समय में ARA की अन्य सुविधाएं, इस्तेमाल के इस उदाहरण को हल करने में मदद कर सकती हैं या नहीं.
एपीआई प्रयोग	यह बताने का अवसर कि एट्रिब्यूशन इवेंट, हिस्सा लेने वाले सभी लोगों के साथ कैसे शेयर किए जाते हैं, जो SSP, DSP वगैरह के लिए फ़ायदेमंद होता है.	हम विज्ञापन टेक्नोलॉजी के साथ सिंक करने की योजना बना रहे हैं, ताकि लोगों के सुझाव, शिकायत या राय को बेहतर तरीके से समझा जा सके. साथ ही, यह भी पता लगाया जा सके कि इस टेक्नोलॉजी का इस्तेमाल किन सीमाओं के तहत किया जा सकता है.
ट्रैफ़िक वॉल्यूम की जांच करें	क्या सभी Chrome के लिए, मोड B का टेस्ट ट्रैफ़िक स्थिर है?	एक्सपेरिमेंट ग्रुप में शामिल किए जाने पर, Chrome की सेटिंग का कोई असर नहीं पड़ता.
दस्तावेज़	पिक्सल के लिए ARA की सुविधा दें.	हमने इस बारे में जानकारी पब्लिश की है कि इस्तेमाल के इस उदाहरण को कैसे मदद दी जा सकती है. साथ ही, नेटवर्क से मिलने वाले अन्य सुझावों का स्वागत है.
एपीआई प्रयोग	अगर आखिरी बार टच करने पर कन्वर्ज़न नहीं होता, तो ई-कॉमर्स प्लैटफ़ॉर्म पर तीसरे पक्ष के सेलर के लिए, ARA को सही सोर्स से एट्रिब्यूट नहीं किया जा सकता.	कंपनियां फ़िल्टर का इस्तेमाल करके, गलत एट्रिब्यूशन को रोक सकती हैं, क्योंकि ऐसा करने पर कोई कन्वर्ज़न रिपोर्ट जनरेट नहीं होगी. इस्तेमाल के इस उदाहरण में मदद के लिए, हम प्री-एट्रिब्यूशन फ़िल्टर के एक प्रस्ताव पर भी काम कर रहे हैं.
ब्राउज़र सहायता	क्या ARA अलग-अलग ब्राउज़र पर काम करेगा?	हम अन्य ब्राउज़र का स्वागत करते हैं, ताकि वे प्राइवसी सैंडबॉक्स एपीआई को अपना सकें. साथ ही, W3C में सबके सामने होने वाले हमारे तरीके के बारे में बात करना जारी रख सकें. हमने साफ़ तौर पर बताया है कि ARA और ARA के डिज़ाइन को शिपिंग के लक्ष्य के तौर पर, ब्राउज़र-ऐग्नोस्टिक के हिसाब से बनाया गया है. वेंडर की निजता के हिसाब से अलग-अलग प्लैटफ़ॉर्म के लिए अलग-अलग प्लैटफ़ॉर्म उपलब्ध हैं. अन्य ब्राउज़र, अलग-अलग डिजिटल कॉन्टेंट या सेवाओं को अपनी पसंद के मुताबिक बना रहे हैं. हमारी सलाह है कि Microsoft Edge ने बताया है कि यह ARA के साथ काम करेगा.
एपीआई प्रयोग	रजिस्टरAdBeacon/reportEvent (और नेविगेशन_start/commit ऑटोमैटिक बीकन) के लिए ARA सोर्स रजिस्ट्रेशन के लिए, अनुमानित सोर्स किस तरह का होना चाहिए?	यह इस बात पर निर्भर करता है कि ये बीकन अपने-आप हैं या मैन्युअल: - रिज़र्व.* नेविगेशन सोर्स टाइप के इवेंट (जैसे कि ऑटोमैटिक) होने चाहिए. - मैन्युअल रूप से ट्रिगर किए गए इवेंट, इवेंट सोर्स के टाइप के होने चाहिए.
एपीआई प्रयोग	क्या हर सोर्स इवेंट के लिए, हर सोर्स रिपोर्ट की ज़्यादा से ज़्यादा सीमा 20 तक हो सकती है? यह सीमा ग्लोबल है या हर रोज़? क्या इस सीमा को बढ़ाने की कोई योजना है?	हर सोर्स के लिए 20 एग्रीगेट रिपोर्ट की सीमा एक ग्लोबल सीमा है. इसमें हर सोर्स के लिए 20 एग्रीगेट रिपोर्ट बनाई जा सकती हैं. यह सीमा ब्राउज़र से तय होती है और इसे कॉन्फ़िगर नहीं किया जा सकता. इस सीमा का मकसद शून्य रिपोर्ट के साथ असली एट्रिब्यूशन रिपोर्ट की सुरक्षा का गलत इस्तेमाल होने से रोकना है. हमने इस बारे में यहां ज़्यादा चर्चा की है.
एपीआई प्रयोग	ARA का इस्तेमाल करके ईमेल मार्केटिंग के लिए सहायता.	फ़िलहाल, ARA में इस्तेमाल के इस उदाहरण के लिए, सीधे तौर पर कोई सहायता उपलब्ध नहीं है. हालांकि, अगर आपके पास ईमेल होस्ट करने वाली साइट का कंट्रोल नहीं है, तो यह सहायता उपलब्ध नहीं है. हम इस बारे में यहां चर्चा कर रहे हैं और अन्य सुझावों का स्वागत है.
Epsilon	Aggregate API के लिए, Epsilon की वैल्यू कब तय होगी?	विज्ञापन टेक्नोलॉजी से जुड़ी मौजूदा एपिसोड की वैल्यू को प्राइवसी सैंडबॉक्स (फ़िलहाल, 64 है) में तय किए गए थ्रेशोल्ड के हिसाब से कॉन्फ़िगर किया जा सकता है. हमारा सुझाव है कि आप अलग-अलग Epsilon की वैल्यू की जांच करें. साथ ही, अपने इस्तेमाल के मामलों में, इन्फ़्लेक्शन पॉइंट की पहचान करें. साथ ही, अपने सुझाव, शिकायत या राय दें. हम इस बात का ध्यान रखेंगे कि एपसिलॉन की वैल्यू में कोई भी बदलाव होने से पहले ही, हम विज्ञापन टेक्नोलॉजी को इसकी जानकारी दे देंगे.
एपीआई में सुधार	इस्तेमाल के ऐसे मामले में मदद करें जहां विज्ञापन देने वाला, बाहरी सीआरएम डेटा से मिलान करने के लिए ट्रिगर_डेटा फ़ील्ड में आइडेंटिफ़ायर डाल सकता है. इससे, विज्ञापन देने वाले, कन्वर्ज़न की क्वालिटी की पुष्टि कर सकते हैं.	हम यहां इस अनुरोध पर चर्चा कर रहे हैं और आपके कुछ और सुझाव, शिकायत या राय का स्वागत है.
एपीआई प्रयोग	रीडायरेक्ट यूआरएल को डेस्टिनेशन यूआरएल के तौर पर कैसे मैनेज करें.	विज्ञापन टेक्नोलॉजी में इनमें से कोई भी काम किया जा सकता है: 1. डेस्टिनेशन फ़ील्ड में फ़ाइनल डेस्टिनेशन यूआरएल डालें; 2. डेस्टिनेशन फ़ील्ड में तीन यूआरएल डाले जा सकते हैं. इससे, फ़ील्ड में कई यूआरएल डाले जा सकते हैं. दोनों विकल्पों के लिए, फ़ाइनल डेस्टिनेशन यूआरएल (विज्ञापन के लैंडिंग पेज का यूआरएल) की जानकारी होना ज़रूरी है. हमने इसके बारे में यहां ज़्यादा चर्चा की है.

एग्रीगेशन सेवा

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
कुंजी का पता लगाने का तरीका	खोज के मुख्य तरीके के लिए अनुरोध करना	हमारे पास मुख्य खोज के लिए एक प्रस्ताव है और इस प्रस्ताव पर नेटवर्क के सुझाव का स्वागत है.
एपीआई प्रयोग	एग्रीगेशन सेवा की निगरानी के लिए रोडमैप	हम यहां नेटवर्क से मिले सुझावों की समीक्षा कर रहे हैं, ताकि ज़्यादा से ज़्यादा लोगों पर निगरानी रखी जा सके और उन्हें सुझाव या राय दी जा सके.
एपीआई में सुधार	रिपोर्ट फिर से क्वेरी करने में सक्षम होने के लिए अनुरोध करना.	एग्रीगेशन सेवा, क्वेरी करने के एक प्रस्ताव पर काम कर रही है. इस प्रस्ताव में, विज्ञापन टेक्नोलॉजी से जुड़ी हर रिपोर्ट के लिए अपने ऐपसिलॉन को बांटा जा सकता है. इससे हर क्वेरी के लिए ज़्यादा ग़ैर-ज़रूरी डेटा मिल सकता है, लेकिन इससे विज्ञापन टेक्नोलॉजी से जुड़ी क्वेरी करने की सुविधा का इस्तेमाल किया जा सकेगा और निजता बनाए रखी जा सकेगी.
एपीआई में सुधार	एक से ज़्यादा ऑरिजिन को एक ही AWS आईडी से असोसिएट करना है.	एग्रीगेशन सेवा, अब एक ही क्लाउड खाते (GCP या AWS) पर एक से ज़्यादा साइटों को शामिल करने की अनुमति देगी. इससे विज्ञापन टेक्नोलॉजी को एक ही साइट के कई ऑरिजिन और कई साइटों से रिपोर्ट प्रोसेस करने के लिए, एक ही एग्रीगेशन सर्विस एनक्लेव का इस्तेमाल करने की अनुमति मिल जाएगी.
एपीआई प्रयोग	जब एग्रीगेट किए जा सकने वाले बैच काम नहीं करते, तो पक्का करें कि बजट खर्च हुआ है या नहीं. साथ ही, यह भी पता करें कि वे अपने बैच को फिर से प्रोसेस कर सकते हैं या नहीं. जब किसी एग्रीगेशन सेवा को डुप्लीकेट रिपोर्ट के लिए बजट से जुड़ी गड़बड़ी का सामना करना पड़ता है, तो बाकी बची रिपोर्ट हट जाती हैं. इस नुकसान को कैसे कम करें?	किसी सामान्य स्थिति में, अगर पूरा काम पूरा नहीं हो पाता है, तो आपका बजट भी खर्च नहीं होगा. कभी-कभी अगर बजट का इस्तेमाल हो जाता है, तो विज्ञापन टेक्नोलॉजी से बजट बढ़ाने का अनुरोध किया जा सकता है. अगर विज्ञापन टेक्नोलॉजी का बजट खत्म होने की वजह से काम बार-बार फ़ेल हो जाते हैं, तो उन्हें बैच बनाने की अपनी रणनीति की पुष्टि करनी चाहिए. डुप्लीकेट रिपोर्ट और गड़बड़ियों से बचने और सही तरीके से एक साथ कई अनुरोध करने के तरीके के बारे में निर्देश यहां दिए गए हैं. बजट वापस पाने के बारे में आपके सुझाव, यहां दिए गए हैं.
एपीआई प्रयोग	यहां बताए गए ट्रिगर के साथ निजी एग्रीगेशन एपीआई का इस्तेमाल करने से, हर नीलामी के लिए एग्रीगेट की जा सकने वाली रिपोर्ट बनेगी. एग्रीगेशन सेवा की स्केलिंग क्षमताएं क्या हैं?	एग्रीगेशन सेवा खुद ही किसी बैच में कुंजियों या रिपोर्ट की संख्या के लिए ऊपरी सीमा नहीं तय करती. हालांकि, ज़रूरी मेमोरी की वजह से 10^14 रिपोर्ट और 10^12 कुंजियों का स्केल फ़िलहाल काम नहीं करता. साइज़ से जुड़े हमारे दिशा-निर्देश से, उन रेंज के बारे में पता चलता है जिन्हें हमने टेस्ट किया है. साथ ही, ये अनुमानित लोड और काम करने वाले क्लाउड वीएम इंस्टेंस टाइप को ध्यान में रखते हुए, बेहतर परफ़ॉर्मेंस के लिए सुझाव देते हैं.
डेटा प्रोसेसिंग	अगर एन्क्रिप्ट (सुरक्षित) किए गए किसी डेटा में निजी जानकारी है, तो एग्रीगेशन सेवा में एन्क्रिप्ट (सुरक्षित) किया गया डेटा देने का कानूनी तरीका क्या है? क्या आप इस बात की गारंटी दे सकते हैं कि कोऑर्डिनेटर एन्क्रिप्ट (सुरक्षित) किए गए डेटा को ऐक्सेस नहीं कर पाएगा?	एग्रीगेशन सेवा, एन्क्रिप्ट (सुरक्षित) किए गए / उपयोगकर्ता के डेटा को कोऑर्डिनेटर के साथ शेयर नहीं करती. एग्रीगेशन सेवा, की मैनेजमेंट और अकाउंटिंग के लिए कोऑर्डिनेटर का इस्तेमाल करती है. कोऑर्डिनेटर के बारे में कुछ जानकारी यहां मिल सकती है. अकाउंटिंग के लिए, एग्रीगेशन सेवा, बजट के इस्तेमाल के लिए सिर्फ़ शेयर किए गए आईडी और रिपोर्टिंग के ऑरिजिन को पीबीएस के साथ शेयर करती है. एक से ज़्यादा साइट लॉन्च करने के बाद, हम ऑरिजिन को साइट से बदल देंगे. ध्यान दें कि एग्रीगेशन सेवा टीईई में चलती है. यह एक ऐसी जगह है जहां क्लाइंट की रिपोर्ट को डिक्रिप्ट किया जा सकता है. टीईई में चलने वाला कोड, यहां बताए गए तरीके से ओपन सोर्स किया गया है. साथ ही, संगठन से बाहर के लोग इसका ऑडिट भी करते हैं.

Private Aggregation API

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
एपीआई प्रयोग	कॉम्पोनेंट सेलर की किसी टीईई में कई एग्रीगेशन सर्वर को रिपोर्ट भेजने की सुविधा.	फ़िलहाल, Private एग्रीगेशन एपीआई के स्टेटस में यह सुविधा काम नहीं करती. हमने इस समस्या के बारे में यहां ज़्यादा चर्चा की है.
दस्तावेज़	Google को मुफ़्त में आज़माने के लिए, Epsilon की वैल्यू कितनी इस्तेमाल की जाती है?	Private एग्रीगेशन एपीआई के लिए, एग्रीगेशन सेवा क्वेरी में दी गई é वैल्यू, 2^16 के L1 योगदान के बजट से मेल खाती है. इस बजट को 10 मिनट के रोलिंग आधार पर लागू किया जाता है. L1 योगदान का 2^20 का बजट भी 'बैकस्टॉप' है, जिसे 24 घंटे के रोलिंग के आधार पर लागू किया जाता है. इसलिए, निजता पैरामीटर 10 मिनट के रोलिंग के हिसाब से é होता है और 144 \r के बजाय, 24 घंटे के रोलिंग आधार पर 16US होता है. एग्रीगेशन सेवा फ़िलहाल, अलग-अलग एग्रीगेशन रणनीतियों के साथ प्रयोग करने, निजी एग्रीगेशन और अन्य एपीआई के लिए अलग-अलग निजता पैरामीटर के साथ सिस्टम की उपयोगिता के बारे में सुझाव, शिकायत या राय देने के लिए, अलग-अलग तरह की जांच (64 तक) के साथ काम करती है. जांच करने वाले लोगों से सुझाव मिलने के बाद, हम इनमें ऐसी सुविधाएं जोड़ने की कोशिश करेंगे जिनकी मदद से, निजता के बजट के ज़्यादा से ज़्यादा इस्तेमाल को बढ़ाया जा सके.

सीमित कवर ट्रैकिंग

उपयोगकर्ता एजेंट को कम करना/उपयोगकर्ता एजेंट क्लाइंट हिंट

इस तिमाही में कोई सुझाव नहीं मिला.

IP Protection (पहले इसका नाम Gnatcatcher था)

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
रिज़ॉल्यूशन आईडी	इसलिए, प्राइवसी सैंडबॉक्स को ज़्यादा साफ़ तौर पर आवाज़ बुलंद करनी चाहिए, ताकि विज्ञापन देने वालों के लिए, आईपी पर बनाए गए रिज़ॉल्यूशन आईडी सही न हों.	प्राइवसी सैंडबॉक्स से साफ़ तौर पर पता चला है कि हम क्रॉस-साइट ट्रैकिंग को कम करना चाहते हैं. हमारी सार्वजनिक पहल का मकसद, कुकी के अलावा अन्य प्लैटफ़ॉर्म पर भी कॉन्टेंट बनाना है. इसका प्रमोशन privacysandbox.com और GitHub, दोनों पर होता है. हम आईपी पतों के आधार पर क्रॉस-साइट ट्रैकिंग को भी कम करने की कोशिश कर रहे हैं. हालांकि, किसी वेबसाइट के लिए क्रॉस-साइट ट्रैकिंग को चालू करने या न करने का फ़ैसला पूरी तरह से अलग-अलग वेबसाइटों पर निर्भर करता है. कानून के पालन की जांच के दौर में, अलग-अलग कंपनियों के लिए यह समझना ज़रूरी है कि सेवा देने वाली कंपनियां किन तरीकों का इस्तेमाल करती हैं.
Chromecast	क्या आईपी सुरक्षा की वजह से Chromecast या Chrome के दूसरे डिवाइसों पर असर पड़ेगा?	फ़िलहाल, Chromecast डिवाइसों पर आईपी सुरक्षा की सुविधा लागू करने का कोई प्लान नहीं है.
आईपी सुरक्षा सूची	क्या वेब-वाइड क्रॉस-साइट ट्रैकिंग के लिए, आईपी पतों का इस्तेमाल करने वाले तीसरे पक्षों की सूची पब्लिश की जाएगी?	यहां दी गई जानकारी के हिसाब से, सूची को फ़ाइनल कर दिए जाने के बाद, उसे पब्लिश कर दिया जाएगा.

बाउंस ट्रैकिंग पर लागू होने वाली पाबंदियां

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
सिंगल साइन ऑन (एसएसओ) पर छूट	बाउंस ट्रैकिंग पर लागू होने वाली पाबंदियां (बीटीएम), इस बात की पुष्टि कैसे करेंगी कि एसएसओ (SSO) छूट के लिए कौनसे उदाहरण इस्तेमाल किए जाएं?	Chrome के अनुभव के आधार पर, BTM को बंद कर दिया जाएगा. ज़्यादा जानकारी के लिए यहां देखें.
रुका हुआ ट्रायल	क्या 3PC को रोकने के अनुरोध में शामिल साइटों के लिए, बीटीएम को चालू किया गया है?	नहीं, जैसा कि यहां बताया गया है, बीटीएम में, एपीआई को बंद करने की प्रोसेस के दौरान बनाए गए कुकी के अपवादों पर कोई कार्रवाई नहीं की जाती.

निजता बजट

जैसा कि GitHub के बारे में जानकारी देने वाला लेख और डेवलपर साइट में बताया गया है,प्राइवसी बजट को अब प्राइवसी सैंडबॉक्स के प्रपोज़ल में नहीं माना जाता.

क्रॉस-साइट की निजता की सीमाओं को मज़बूत बनाएं

मिलती-जुलती वेबसाइट के सेट (पहले पक्ष के सेट थे)

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
सुविधा का अनुरोध	सीएचआईपी और / या स्टोरेज पार्टीशन को आरडब्ल्यूएस में अपने-आप ऐक्सेस करने की अनुमति होती है. इसके लिए, Storage Access API या उपयोगकर्ता के इंटरैक्शन की ज़रूरत नहीं होती.	हम इस फ़ंक्शन को पूरा करने वाली सुविधा के फ़ायदों और क्षमताओं पर विचार कर रहे हैं. एक बात यह है कि क्रॉस-ब्राउज़र इंटरऑपरेबिलिटी (दूसरे सिस्टम के साथ काम करना) में अंतर हो सकता है. आरडब्ल्यूएस, Storage Access API का इस्तेमाल करके समस्या को ठीक करता है. अनुरोध की गई इस सुविधा के जैसा कोई मौजूदा वर्शन नहीं है जो अन्य ब्राउज़र पर काम करता हो. हम डेवलपर को सुझाव देते हैं कि वे इस समस्या पर अपने इस्तेमाल के उदाहरण सबमिट करें, ताकि उनके बारे में यहां बातचीत की जा सके.
नीति का पालन नहीं करने वाले सेट को हटाना	डेटा स्टोर करने की जगह से, शर्तों का पालन न करने वाले सेट को हटाने की प्रोसेस क्या है?	हम इसके लिए एक प्रोसेस तय कर रहे हैं. जैसे ही अपडेट उपलब्ध होंगे, हम उन्हें शेयर करेंगे.
नीति उल्लंघन ठीक करने की प्रक्रिया	आरडब्ल्यूएस को लागू करने में Google की भूमिका साफ़ तौर पर नहीं दिख रही है.	आरडब्ल्यूएस का प्रोजेक्ट चल रहा है और हमें लगातार नए अनुरोध मिल रहे हैं. इसलिए, प्रक्रिया के पहलुओं और हमारे नियमों को अब भी बेहतर बनाया जा रहा है. हम इस बात से सहमत हैं कि सबमिशन से जुड़े हमारे दिशा-निर्देशों के लिए, सबमिशन से जुड़ी ज़रूरी शर्तों के बारे में पूरी जानकारी देना ज़रूरी है. आने वाले समय में, हम सबमिशन से जुड़े दिशा-निर्देशों में ज़्यादा जानकारी शामिल करेंगे, ताकि आपको गड़बड़ी और भ्रम न हो. हमारा मकसद, सबमिशन की प्रोसेस को ज़्यादा से ज़्यादा तकनीकी बनाना है, ताकि हम मैन्युअल तरीके से जांच करने की सुविधा से पूरी तरह से बच सकें. इस तरह की पीआर में, ज़्यादा लोगों से बातचीत करने की ज़रूरत होती है, क्योंकि इनमें ऐसी गतिविधियां शामिल होती हैं जिनका हमने अनुमान नहीं लगाया था. हालांकि, इनसे हमें ऑटोमेशन के ज़्यादा क्षेत्रों की पहचान करने में मदद मिलती है. साथ ही, आने वाले समय में इन समस्याओं से बचने के लिए, अपने दिशा-निर्देशों को ठीक करने के तरीकों का पता चलता है.
डेटा शेयर करना	ऐसी सुविधा के लिए अनुरोध जो डोमेन के मालिकों को यह बताने की अनुमति देती है कि वे चाहते हैं कि कोई तीसरा पक्ष, उपयोगकर्ता की सहमति से आरडब्ल्यूएस डेटा भी शेयर करे.	अनुरोध की गई सुविधा, FedCM और Storage Access API जैसे एपीआई पर पहले से ही उपलब्ध है. ये फ़ंक्शन, उपयोगकर्ता के अनुमति के अनुरोध को स्वीकार करने के बाद, पुष्टि की गई पहचान को ऐक्सेस करने की सुविधा देते हैं. अगर हमें लगता है कि इस तरह के कॉन्टेंट को इस्तेमाल करना मुमकिन नहीं है, तो हम नेटवर्क से मिलने वाले सुझावों का स्वागत करते हैं.
स्टोरेज के दूसरे तरीके	क्या लोकल स्टोरेज या सेशन के स्टोरेज में सेव की गई जानकारी को भी 3PC के तौर पर माना जाएगा?	Chrome के 115 और इसके बाद के वर्शन से, Chrome में लोकल स्टोरेज, सेशन स्टोरेज, और तीसरे पक्ष के लिए इस्तेमाल किए जाने वाले बिना कुकी वाले अन्य तरह के स्टोरेज को अलग-अलग हिस्सों में बांटा गया है. ज़्यादा जानकारी के लिए यह ब्लॉग पोस्ट देखें.
जुड़े हुए सेट की सीमा	"पांच से जुड़ी साइटें सीमित की गई" के बावजूद, पांच से ज़्यादा डोमेन सबमिट करने वाले संगठनों पर क्या होगा?	इन सेट को GitHub प्रोसेस के ज़रिए स्वीकार किया जाएगा. हालांकि, ब्राउज़र (Chrome), स्टोरेज ऐक्सेस एपीआई को अपने-आप अनुमति देने वाले नियम सिर्फ़ पहले पांच डोमेन पर लागू करेगा. साथ ही, बाकी डोमेन को अनदेखा कर देगा, जैसा कि यहां बताया गया है.
find_robots_txt	Find_robots_txt जांच, रीडायरेक्ट के साथ काम नहीं करती.	इस समस्या को हल करने के लिए, यहां हल सबमिट किया गया है.
उपयोगकर्ता के जेस्चर	accessStorage() के लिए, उपयोगकर्ता के जेस्चर की ज़रूरी शर्त हटाएं.	यह शर्त, requestStorageAccess API के सभी मुख्य ब्राउज़र में मौजूद मिलते-जुलते डिज़ाइन के आधार पर तय की गई है. GitHub की इस समस्या में, हम आपको सुझाव/राय देने या शिकायत करने का न्योता देते हैं और इसके इस्तेमाल के उदाहरण देते हैं. इससे हमें इस अनुरोध को प्राथमिकता देने और अलग-अलग ब्राउज़र पर चर्चा करने की सुविधा चालू करने में मदद मिलेगी.
उपयोगकर्ता के जेस्चर	क्या Chrome या OS को रीस्टार्ट करने के बाद, तीसरे पक्ष के स्टोरेज का ऐक्सेस देने के लिए उपयोगकर्ता के जेस्चर की ज़रूरत होती है?	हां, लेकिन इस व्यवहार में बदलाव करने के लिए, हमें नेटवर्क से कुछ और सुझाव, शिकायत या राय का स्वागत है. इसके लिए, यहां क्लिक करें.

फ़ेंस किए गए फ़्रेम का एपीआई

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
adComponent	फ़ेंस किए गए फ़्रेम वाले Adकॉम्पोनेंट का इस्तेमाल करने के लिए, दस्तावेज़ बनाने की क्षमता और ज़रूरत के हिसाब से कम.	हम इस्तेमाल के इस उदाहरण से जुड़े और दस्तावेज़ शेयर करना चाहते हैं. साथ ही, इन्हें जोड़ने के लिए, getNestedConfigs() का इस्तेमाल करके फ़ेंस किए गए फ़्रेम में विज्ञापन कॉम्पोनेंट काम करते हैं, जिसे यहां दिए गए स्पेसिफ़िकेशन में बताया गया है.
(पिछली तिमाही में भी रिपोर्ट किया गया) रेंडर विज्ञापन कॉम्पोनेंट	फ़ेंस किए गए फ़्रेम में विज्ञापन कॉम्पोनेंट को रेंडर करने के तरीके के बारे में सैंपल कोड का अनुरोध.	हम यहां कुछ सैंपल कोड शेयर करने पर काम कर रहे हैं.
विज्ञापन की मदद से पुष्टि करने वाला तीसरे पक्ष का विकल्प	फ़ेंस किए गए फ़्रेम के मामले में, तीसरे पक्ष के विज्ञापन की पुष्टि करने से जुड़ी और जानकारी की ज़रूरत है. खास तौर पर, कॉन्टेक्स्ट/ब्रैंड की सुरक्षा के बारे में.	फ़िलहाल, फ़ेंस्ड फ़्रेम विज्ञापन रिपोर्टिंग की मदद से डीएसपी, ब्रैंड सुरक्षा की जांच और बिलिंग के लिए 3P विज्ञापन की पुष्टि करने वाली कंपनियों को इंप्रेशन और नीलामी से जुड़े इवेंट लेवल का डेटा भेज सकते हैं.
बड़े होने वाले विज्ञापन	बड़े होने वाले विज्ञापनों के साथ काम करने का अनुरोध करें.	अगर विज्ञापन को एक ही आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) वाले दो साइज़ के बीच स्विच करना है और दोनों के बीच कोई फ़ंक्शनल फ़र्क़ नहीं है (सिर्फ़ साइज़), तो एम्बेडर, फ़ेंस किए गए फ़्रेम का साइज़ दूसरे विज्ञापन साइज़ के साथ बदल सकता है. इसके बाद, ब्राउज़र, फ़ेंस किए गए फ़्रेम के एलिमेंट का साइज़ बदल सकता है.
(पिछली तिमाहियों में भी रिपोर्ट की गई) वीडियो और नेटिव इन्वेंट्री के लिए सहायता	क्या फ़ेंस किए गए फ़्रेम में, वीडियो और नेटिव इन्वेंट्री काम करती है?	हमारा जवाब पिछली तिमाहियों जैसा ही है: PA API, iframe पर निर्भर करने वाले तरीके का इस्तेमाल करके, वीडियो रेंडरिंग की सुविधा देता है. हालांकि, हमने अभी तक वीडियो और नेटिव विज्ञापन रेंडरिंग के लिए ऐसा समाधान नहीं बनाया है जो फ़ेंस किए गए फ़्रेम के साथ काम कर सके. इस वजह से, हमने फ़ेंस किए गए फ़्रेम की नीति को लागू करने की तारीख को 2026 से हटाने का फ़ैसला किया था. इसका मतलब है कि अगर कोई पार्टनर अभी फ़ेंस्ड फ़्रेम लागू करने का फ़ैसला लेता है, तो उस पार्टनर को वीडियो और नेटिव विज्ञापन के लिए सहायता नहीं मिलेगी.
एडवाइज़री बोर्ड	नेटिव विज्ञापन वेंडर के लिए एक एडवाइज़री बोर्ड बनाने का अनुरोध किया जाता है, ताकि यह पक्का किया जा सके कि फ़ेंस किए गए फ़्रेम का इस्तेमाल, इंडस्ट्री स्टैंडर्ड के मुताबिक हो.	साल 2026 से पहले, पीए एपीआई में इस्तेमाल के लिए फ़ेंस किए गए फ़्रेम की ज़रूरत नहीं है. यह अतिरिक्त समय मिलने पर, हम इंडस्ट्री के साथ मिलकर काम कर पाते हैं, ताकि हम इस्तेमाल के ज़्यादा से ज़्यादा उदाहरणों के लिए, सहायता को डिज़ाइन और लागू कर सकें. हमने पहले बताया था कि PA API की मदद से वीडियो और नेटिव विज्ञापनों के लिए, सहायता बनाए रखने के लिए हम फ़ेंस किए गए फ़्रेम को उनकी ज़रूरत से पहले ही बेहतर बनाएंगे. हमारी प्रतिबद्धता के मुताबिक, हम ऐसे किसी भी बदलाव के बारे में CMA से बात करेंगे और उन्हें इसकी जानकारी देंगे. साथ ही, फ़ेंस किए गए फ़्रेम की ज़रूरत को पूरा करने के लिए, हम नेटवर्क के सुझाव, शिकायत या राय पर लगातार काम करते रहेंगे. W3C में नेटवर्क एंगेजमेंट मॉडल और IAB Tech Lab जैसे विज्ञापन मानक संगठनों की मदद से, सभी तरह के इंडस्ट्री के विशेषज्ञों को डिज़ाइन की ज़रूरत से पहले ही गाइड करने की सुविधा मिलती है.
(पिछली तिमाहियों में भी रिपोर्ट की गई) अलग-अलग प्लैटफ़ॉर्म के बीच साइज़ का अंतर	यह रिपोर्ट कि फ़ेंस किए गए फ़्रेम में दिखाए गए कॉन्टेंट का साइज़, डेस्कटॉप और स्मार्टफ़ोन पर अलग-अलग दिख सकता है.	यह Chromium से जुड़ी एक आम समस्या है जिसकी हम जांच कर रहे हैं. हम आपके सुझाव, शिकायत या राय का यहां स्वागत करते हैं.
एपीआई में सुधार	क्या फ़ेंस किए गए फ़्रेम से जुड़ी ज़रूरी शर्तों को 2025 में लागू किया गया है, ताकि नेटिव विज्ञापन अब प्राइवसी सैंडबॉक्स के साथ काम करें?	जैसा कि हमने फ़ेंस किए गए फ़्रेम को लागू करने के बारे में 2026 से पहले, अपने सार्वजनिक एलान में बताया था, हमें फ़ेंस किए गए फ़्रेम को लागू करने के लिए बहुत सारी "ज़रूरी कोशिशों" का पता चला. इनमें से एक तरीका नेटिव था, लेकिन सिर्फ़ यही एक वजह नहीं थी. इसका मकसद यह पक्का करना था कि हमें ज़्यादा समय मिले, ताकि यह पक्का किया जा सके कि इस्तेमाल के अहम उदाहरणों के लिए, नेटवर्क का इस्तेमाल करने के लिए तैयार हो जाएं. इसमें स्थानीय पकवान के अलावा, और भी चीज़ें शामिल हो सकती हैं.

Shared Storage API

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
परफ़ॉर्मेंस	ऐसा लगता है कि वर्कलेट के अलावा, शेयर किए गए स्टोरेज को लौटाने में लगने वाला समय, वर्कलेट में की गई गतिविधि पर निर्भर करता है.	हम जांच के इस नतीजे के बारे में यहां चर्चा कर रहे हैं.
व्यापक रूप से अपनाना	शेयर किया गया स्टोरेज, एक इंडस्ट्री स्टैंडर्ड होना चाहिए और सभी ब्राउज़र पर उपलब्ध होना चाहिए.	हम इस सुझाव, शिकायत या राय का स्वागत करते हैं और इसकी पुष्टि करते हैं. इस प्रस्ताव को सही साबित करने, सुझाव पाने, और इसे अपनाने के लिए Chrome ने लगातार W3C फ़ोरम में हिस्सा लिया है. इसमें WICG भी शामिल है.
बिडिंग वर्कलेट	क्या दूसरी साइट की जानकारी के आधार पर विज्ञापन के फ़ैसले / कारोबार के लॉजिक (जैसे कि फ़्रीक्वेंसी कैपिंग) को लागू करने और विज्ञापनों के किसी सबसेट को चुनने के लिए, generateबिड (जो पहले से वर्कलेट में चल रहा है) में शेयर किए गए स्टोरेज से जानकारी हासिल की जा सकती है?	नहीं, बिडिंग वर्कलेट में शेयर किए गए स्टोरेज से जानकारी नहीं पढ़ी जा सकती.

सीएचआईपीएस

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
पार्टीशन कपैसिटी	बंटवारे की क्षमता से ज़्यादा होने पर व्यवहार की जानकारी दें.	क्षमता पूरी हो जाने पर, सबसे पुरानी कुकी को सबसे कम हाल ही में ऐक्सेस की गई कुकी से फ़्री मेमोरी तक निकाल दिया जाता है. यह सीमा पार हो जाती है. डेवलपर को बाद के अनुरोधों में अपडेट किया गया कुकी हेडर दिखता है.
तीसरे पक्ष का iframe ऐक्सेस	उसी तीसरे पक्ष की साइट पर नया टैब/विंडो खोलने के लिए इस्तेमाल किए गए तीसरे पक्ष के iframe कॉन्टेंट के पास, उन कुकी का ऐक्सेस होना चाहिए जो ओपनर को पहले से अलग-अलग मिली हुई हैं.	हम यहां नेटवर्क के इस इस्तेमाल के उदाहरण पर चर्चा कर रहे हैं और हमें नेटवर्क के अन्य सुझावों, राय या शिकायतों का स्वागत है.
डुप्लीकेट कुकी	अगर दो हिस्सों में बांटी गई कुकी और एक ही नाम वाली कुकी मौजूद है, तो ब्राउज़र कौनसा कुंजी मान भेजता है?	एक ही नाम वाली दो कुकी (एक पार्टिशन्ड और दूसरी नहीं) होने पर, आपको दोनों कुकी मिलेंगी – माफ़ करें, दोनों के बीच अंतर करने का कोई तरीका नहीं है. इस बारे में आरएफ़सी की खास जानकारी यहां दी गई है, जिसमें बताया गया है कि कुकी को भेजे जाने के क्रम पर भरोसा नहीं किया जाना चाहिए.
सुविधा का अनुरोध	ऑरिजिन-पार्टिशन्ड कुकी के लिए ऑप्ट इन करें.	हम इस अनुरोध पर विचार कर रहे हैं और यहां नेटवर्क से अतिरिक्त फ़ीडबैक का स्वागत करते हैं.

FedCM

इस तिमाही में कोई सुझाव नहीं मिला.

स्पैम और धोखाधड़ी को रोकना

प्राइवेट स्टेट टोकन एपीआई और अन्य एपीआई

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
वेबव्यू	क्या प्राइवेट स्टेट टोकन (पीएसटी) एक ही मोबाइल डिवाइस (प्रोफ़ाइल) पर कई वेबव्यू पर मौजूद हैं?	वेबव्यू का इस्तेमाल करने वाले हर ऐप्लिकेशन के लिए अलग-अलग लोकल स्टोरेज होगा. इसका मतलब है कि पीएसटी जारी करने वाले, एक ऐप्लिकेशन के वेबव्यू में टोकन जारी नहीं कर सकते और फिर बाद में किसी अलग ऐप्लिकेशन में, टोकन रिडीम करने की अनुमति नहीं दे सकते. ऐसा वेबव्यू पर स्थानीय तौर पर स्टोर किए गए अन्य तरह के डेटा के लिए भी होता है, जैसे कि कुकी. पीएसटी समय तक वेबव्यू में पूरी तरह से उपलब्ध नहीं है. हमें दूसरी तिमाही के आखिर तक, इस बारे में अपडेट देने की उम्मीद है.
नया टोकन टाइप	नए टोकन टाइप का प्रस्ताव.	हम इस प्रस्ताव के लिए शुक्रगुज़ार हैं. हमने पीएसटी के हिसाब से, आवेदन करने और इसमें बदलाव करने की प्रक्रिया को जारी रखा. हमें उम्मीद है कि साल 2024 की दूसरी तिमाही में धोखाधड़ी रोकने वाले कम्यूनिटी ग्रुप की मीटिंग में, इस प्रस्ताव के बारे में ज़्यादा जानकारी मिलेगी.
उपयोगकर्ता की पहचान	उपयोगकर्ताओं को उनके खास पीएसटी के आधार पर पहचाने जाने से कैसे रोका जाए?	फ़िलहाल, साइट को रिडीम करने की कोशिशों को दो पक्षों तक सीमित करके, इसे कम किया जा रहा है. भले ही, कंपनी के पास टोकन उपलब्ध हों या नहीं. आपको सीमा के हिसाब से, जारी करने वाले की गिनती करनी होगी, भले ही टोकन उपलब्ध न हों. ऐसा न करने पर, साइट सभी जारी करने वाली कंपनियों की ओर से तब तक कार्रवाई कर सकती है, जब तक वह एक पॉज़िटिव मैच नहीं करता.
रजिस्ट्रेशन	पीएसटी के लिए कितने समय तक रजिस्ट्रेशन करना होगा?	आने वाले समय में, रजिस्ट्रेशन की ज़रूरत होगी. इस बारे में ज़्यादा जानकारी यहां दी गई है.
Chromium के अन्य ब्राउज़र के साथ काम करता है	क्या अन्य Chromium-आधारित ब्राउज़र के लिए पीएसटी जारी करने वाले का रजिस्ट्रेशन, Chrome जारी करने वाले रजिस्ट्रेशन का डेटा स्टोर करने की जगह की मदद से काम करेगा?	Chrome, मुख्य प्रतिबद्धताओं को फ़ेच करता है और उन्हें कॉम्पोनेंट अपडेटर नाम के एक तरीके के ज़रिए Chrome क्लाइंट को डिस्ट्रिब्यूट करता है. जैसे-जैसे अन्य ब्राउज़र, एपीआई के लिए बेहतर तरीके से काम करते हैं, उन्हें क्लाइंट से अहम प्रतिबद्धताएं पाने के लिए एक प्रोसेस सेट अप करनी होगी. इसके लिए, या तो कॉम्पोनेंट अपडेटर-स्टाइल वाला तरीका इस्तेमाल करना होगा या कोई दूसरा तरीका इस्तेमाल करना होगा. इस बारे में ज़्यादा जानकारी यहां दी गई है.