साल 2024 की पहली तिमाही की तिमाही रिपोर्ट, जिसमें Privacy Sandbox के प्रस्तावों और Chrome के जवाब पर, नेटवर्क से मिले सुझाव/राय या शिकायत की खास जानकारी दी गई है.
सीएमए के साथ किए गए अपने वादे के तहत, Google ने अपने निजता सैंडबॉक्स के प्रस्तावों के लिए, हिस्सेदारों के साथ जुड़ाव की प्रोसेस के बारे में सार्वजनिक तौर पर हर तीन महीने की रिपोर्ट देने पर सहमति दी है. समझौते के पैराग्राफ़ 12 और 17(c)(ii) देखें. Privacy Sandbox के सुझाव/राय/शिकायत/राय देने वाले फ़ॉर्म की खास जानकारी वाली ये रिपोर्ट, सुझाव/राय/शिकायत/राय देने वाले फ़ॉर्म की खास जानकारी में बताए गए अलग-अलग सोर्स से मिले सुझाव/राय/शिकायत/राय को इकट्ठा करके जनरेट की जाती हैं. इनमें ये सोर्स शामिल हैं, लेकिन इन तक ही सीमित नहीं हैं: GitHub पर मौजूद समस्याएं, privacysandbox.com पर उपलब्ध सुझाव/राय/शिकायत/राय देने वाला फ़ॉर्म, इंडस्ट्री के हिस्सेदारों के साथ हुई मीटिंग, और वेब स्टैंडर्ड फ़ोरम. Chrome, नेटवर्क से मिले सुझावों/शिकायतों/राय का स्वागत करता है. साथ ही, डिज़ाइन से जुड़े फ़ैसलों में, इन सुझावों/शिकायतों/राय को शामिल करने के तरीकों को लगातार एक्सप्लोर कर रहा है.
सुझाव, शिकायत या राय की थीम को हर एपीआई के हिसाब से, उनकी संख्या के आधार पर रैंक दी जाती है. ऐसा करने के लिए, Chrome की टीम को किसी थीम के बारे में मिले सुझावों, राय या शिकायतों की संख्या को इकट्ठा किया जाता है. इसके बाद, उन्हें संख्या के हिसाब से कम से ज़्यादा के क्रम में लगाया जाता है. आम तौर पर मिलने वाले सुझाव/राय/शिकायत/राय के विषयों की पहचान करने के लिए, सार्वजनिक मीटिंग (W3C, PatCG, IETF), सीधे सुझाव/राय/शिकायत/राय, GitHub, और Google की इंटरनल टीमों और सार्वजनिक फ़ॉर्म से पूछे जाने वाले आम सवालों के विषयों की समीक्षा की गई.
खास तौर पर, वेब स्टैंडर्ड बॉडी की मीटिंग के मिनट की समीक्षा की गई. साथ ही, सीधे फ़ीडबैक के लिए, Google के 1:1 हिस्सेदारों की मीटिंग के रिकॉर्ड, अलग-अलग इंजीनियरों को मिले ईमेल, एपीआई की मेलिंग सूची, और सार्वजनिक फ़ीडबैक फ़ॉर्म को ध्यान में रखा गया. इसके बाद, Google ने इन अलग-अलग आउटरीच गतिविधियों में शामिल टीमों के बीच समन्वय किया, ताकि यह पता लगाया जा सके कि हर एपीआई के लिए, कौनसी थीम सबसे ज़्यादा लोकप्रिय हैं.
Chrome पर मिले सुझाव, शिकायत या राय के जवाबों के बारे में जानकारी, पब्लिश किए गए अक्सर पूछे जाने वाले सवालों, हिस्सेदारों की ओर से उठाई गई समस्याओं के जवाबों, और सार्वजनिक तौर पर रिपोर्ट करने के मकसद से किसी खास बात पर फ़ैसला लेने के आधार पर दी गई है. डेवलपमेंट और टेस्टिंग के मौजूदा फ़ोकस को दिखाते हुए, हमें Topics, Protected Audience, और एट्रिब्यूशन रिपोर्टिंग एपीआई के बारे में खास तौर पर सवाल और सुझाव मिले.
हो सकता है कि रिपोर्टिंग की मौजूदा अवधि खत्म होने के बाद मिले सुझाव/शिकायत/राय पर, Chrome ने अब तक कोई जवाब न दिया हो.
शॉर्ट फ़ॉर्म की ग्लॉसरी
- ARA
- Attribution Reporting API
- सीएचआईपीएस
- कुकीज़ हैविंग इंडिपेंडेंट पार्टिशन्ड स्टेट
- डीएसपी
- डिमांड-साइड प्लैटफ़ॉर्म
- FedCM
- फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट
- एफ़पीएस
- फ़र्स्ट पार्टी सेट
- IAB
- Interactive Advertising Bureau
- IDP
- पहचान की पुष्टि करने वाली सेवा
- आईईटीएफ़
- इंटरनेट इंजीनियरिंग टास्क फ़ोर्स
- आईपी
- इंटरनेट प्रोटोकॉल पता
- openRTB
- रीयल-टाइम बिडिंग
- OT
- Origin ट्रायल
- PAT API
- Protected Audience API (पहले इसे FLEDGE के नाम से जाना जाता था)
- PatCG
- निजी विज्ञापन टेक्नोलॉजी कम्यूनिटी ग्रुप
- आरपी
- भरोसा करने वाली पार्टी
- RWS
- मिलती-जुलती वेबसाइट के सेट (पहले इन्हें पहले पक्ष के सेट कहा जाता था)
- SSP
- सप्लाई-साइड प्लैटफ़ॉर्म
- टीईई
- ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट
- UA
- यूज़र एजेंट स्ट्रिंग
- UA-CH
- User-Agent Client Hints
- W3C
- वर्ल्ड वाइड वेब कंसोर्टियम
- WIPB
- जान-बूझकर आईपी ब्लाइंडनेस
सामान्य सुझाव, राय या शिकायत, किसी खास एपीआई या टेक्नोलॉजी के लिए नहीं
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| मैनेज करना | Privacy Sandbox के लिए, नीति से जुड़े किसी भी अपडेट के लिए सार्वजनिक टिप्पणी करने की अवधि में दिलचस्पी. | हम Privacy Sandbox से जुड़े किसी भी अहम बदलाव के बारे में, हिस्सेदारों से सुझाव, राय या शिकायतें सुनने के लिए तैयार हैं. इनमें Privacy Sandbox के आने वाले समय में होने वाले मैनेजमेंट से जुड़े बदलाव भी शामिल हैं. |
| टेस्ट करना | Chrome की मदद से की जाने वाली मौजूदा टेस्टिंग के 1% के अलावा, 3PCD के लिए टेस्टिंग के अन्य चरण. | हमारा मकसद, जनवरी की शुरुआत से चालू किए गए Chrome के 1% ट्रैफ़िक के अलावा, Chrome की मदद से टेस्टिंग की सुविधा नहीं देना है. |
| वेब से ऐप्लिकेशन | वेब और ऐप्लिकेशन के बीच पूरी तरह से इंटरऑपरेबल होने से पहले, मोबाइल डिवाइसों पर 3PCD नहीं होना चाहिए. | हम इस बात से सहमत हैं कि ऐप्लिकेशन और वेब के बीच इंटरऑपरेबिलिटी की सुविधा देना ज़रूरी है. इसलिए, हमने क्रॉस-ऐप्लिकेशन और वेब एट्रिब्यूशन मेज़रमेंट की सुविधा लॉन्च की है. साथ ही, हम वेब-टू-ऐप्लिकेशन टारगेटिंग के समाधानों को एक्सप्लोर कर रहे हैं. हालांकि, हम मोबाइल वेब पर 3PCD की सुविधा को लॉन्च करने में देरी नहीं करेंगे. हमारा मकसद, 3PCD के आखिर तक 100% कवरेज हासिल करना नहीं है. इसके बजाय, हमें उम्मीद है कि क्रॉस-ऐप्लिकेशन और वेब मेज़रमेंट के लिए, Android पर 3PCD के साथ काम करने की सुविधा काफ़ी हद तक उपलब्ध होगी. साथ ही, समय के साथ यह सुविधा और भी बेहतर होगी, क्योंकि उपयोगकर्ता अपने फ़ोन को अपडेट करते रहेंगे. |
| ब्राउज़र की भूमिका | ऐसा लगता है कि Chrome, विज्ञापन सर्वर या एसएसपी की भूमिका निभा रहा है. | Chrome, विज्ञापन सर्वर या एसएसपी की भूमिका नहीं निभा रहा है. PA API की मदद से, Chrome विज्ञापन सर्वर, एसएसपी, डीएसपी, और अन्य विज्ञापन टेक्नोलॉजी के लिए एक कंटेनर उपलब्ध करा रहा है, ताकि वे अपनी बिडिंग और स्कोरिंग लॉजिक का इस्तेमाल कर सकें. |
| इस्तेमाल के उदाहरण के लिए दिशा-निर्देश | Privacy Sandbox API के इस्तेमाल के उदाहरणों के बारे में साफ़ तौर पर जानकारी. | Privacy Sandbox प्रोजेक्ट की शुरुआत में, डेवलपर दस्तावेज़ का मकसद मुख्य तौर पर डेवलपर को सभी प्रस्तावों के लिए चर्चा और सुझाव/राय देने की प्रोसेस में शामिल करना था. इसका मतलब है कि कॉन्टेंट को आम तौर पर, प्रोजेक्ट के पीछे की वजह और कॉन्सेप्ट को समझने के लिए तैयार किया गया था. इसके बाद, हर प्रस्ताव के लिए शुरुआती डेवलपमेंट और टेस्टिंग की जानकारी दी गई थी. यह प्रस्तावों को तैयार करने में, असली इकोसिस्टम के साथ मिलकर काम करने में मददगार था. हालांकि, एपीआई के सामान्य तौर पर उपलब्ध होने के बाद, डेवलपर की एक नई ऑडियंस है. ये डेवलपर, एपीआई के डेवलपमेंट में योगदान देने के बजाय, मुख्य रूप से एपीआई पर काम करना चाहते हैं. हमने हाल ही में Privacy Sandbox डेवलपर साइट के नेविगेशन को अपडेट किया है, ताकि इसे इस्तेमाल के उदाहरण पर फ़ोकस किया जा सके. इसके लिए, हमने IAB Tech Lab की हाल ही की Privacy Sandbox टास्क फ़ोर्स रिपोर्ट में दी गई कैटगरी का इस्तेमाल किया है. दस्तावेज़ तैयार करने के लिए, इस्तेमाल के उदाहरण के आधार पर तैयार किए गए दस्तावेज़ों का इस्तेमाल जारी रखा जाएगा. |
| लोकल डेवलपमेंट एनवायरमेंट | अगर कुकी SameSite=Secure है और बैकएंड को सीडीएन से फ़्रंट किया गया है, तो हम http://localhost पर अपने फ़्रंटएंड को स्थानीय तौर पर कैसे डेवलप और टेस्ट करते हैं? | हम इस समस्या के बारे में यहां चर्चा कर रहे हैं. साथ ही, हम इस बारे में अन्य सुझाव, राय या शिकायतें भी स्वीकार करते हैं. |
| 3PCD से जुड़ी समस्या को कम करना | क्या प्रोग्राम के हिसाब से यह पता लगाया जा सकता है कि 3PC ब्लॉक किए गए हैं या नहीं या हेयुरिस्टिक्स कब चालू हैं? | Chrome में, सुविधा का पता लगाने की सुविधा और iframe में document.hasStorageAccess, दोनों से डेवलपर को यह पता चलता है कि iframe के ऑरिजिन के पास 3PC का ऐक्सेस है या नहीं. |
| वीडियो की जांच करना | फ़िलहाल, Privacy Sandbox में वीडियो विज्ञापनों की जांच नहीं की जा सकती. | Chrome ने PA API की मदद से वीडियो बनाने के कई संभावित तरीकों के बारे में चर्चा की है और उन्हें डेमो के तौर पर दिखाया है. इन तरीकों के बारे में जानने के लिए, GitHub पर हमारे डेमो रिपॉज़िटरी में 242 और 254 देखें. ध्यान दें कि इनका मकसद, विज्ञापन टेक्नोलॉजी से जुड़ी कंपनियों के लिए सैंपल कोड उपलब्ध कराना नहीं है. बल्कि, इनका मकसद, PA API की मदद से VAST वीडियो रेंडरिंग की सुविधा को काम करने लायक बनाने वाली तकनीकों के बारे में बताना है. इस बातचीत के दौरान, यह भी साफ़ हो गया है कि वीडियो रेंडरिंग की सुविधा पहले से ही उपलब्ध है. हालांकि, Chrome में कुछ बदलाव किए जा सकते हैं, ताकि PA API की मदद से इस सुविधा को लागू करना आसान हो सके. उदाहरण के लिए, मैक्रो बदलने की सुविधा (इसके बारे में यहां बताया गया है) में किए गए अपडेट, वीडियो के इस्तेमाल के उदाहरण में भी फ़ीडबैक को हल करेंगे. हम तीसरे पक्ष के विज्ञापन की पुष्टि करने वाले ब्रैंड सेफ़्टी के इस्तेमाल के उदाहरणों के बारे में फ़ीडबैक के आधार पर, पहले से ही इस समस्या को हल करने की योजना बना रहे थे. अब तक की ज़्यादातर चर्चा, खास तौर पर VAST वीडियो विज्ञापनों को रेंडर करने पर केंद्रित रही है. नेटिव विज्ञापनों को रेंडर करने के लिए, इन तरीकों का इस्तेमाल किया जा सकता है. साथ ही, यह कई तरीकों से आसान है. फ़िलहाल, नेटिव विज्ञापनों को वीडियो विज्ञापनों के मुकाबले कम ध्यान मिल रहा है. हालांकि, यह सिर्फ़ विज्ञापन टेक्नोलॉजी इंडस्ट्री की प्राथमिकता का सवाल है, न कि लागू करने से जुड़ी किसी तकनीकी समस्या का. |
| विज्ञापनों के अलावा अन्य तरीकों से होने वाली आय का आकलन | 3PCD का असर, विज्ञापन से जुड़े नॉन-ऑडियंस मेज़रमेंट सलूशन पर पड़ सकता है. | मेज़रमेंट एपीआई के लिए ज़रूरी नहीं है कि इस्तेमाल का उदाहरण विज्ञापनों से जुड़ा हो. एआरए, विज्ञापन से जुड़ी सामान्य प्रोसेस के लिए ज़्यादा खास है, जबकि निजी एग्रीगेशन का इस्तेमाल कई कामों के लिए किया जा सकता है. इन दो बिल्डिंग ब्लॉक का इस्तेमाल, मेज़रमेंट गतिविधि की एक बड़ी रेंज को हल करने के लिए किया जा सकता है. |
| कॉन्टेंट क्रिएटर्स | प्राइवसी सैंडबॉक्स को इस तरह से बनाया गया है कि कॉन्टेंट क्रिएटर्स को YouTube के लिए ज़्यादा कॉन्टेंट बनाने और अपनी साइटों पर कम कॉन्टेंट बनाने के लिए बढ़ावा मिले. | Privacy Sandbox इनिशिएटिव का मकसद, ओपन और बिना शुल्क वाले इंटरनेट पर लोगों की गतिविधि को निजी रखना है. हम जानते हैं कि पब्लिशर, कॉन्टेंट बनाने और उसे ज़्यादा से ज़्यादा लोगों तक पहुंचाने के लिए विज्ञापनों पर निर्भर रहते हैं. विज्ञापन देने वाले लोग या कंपनियां, लोगों को ऐसे नए प्रॉडक्ट या ऑफ़र खोजने में मदद करती हैं जिनमें उनकी दिलचस्पी हो सकती है. निजता सैंडबॉक्स की सुविधाओं की मदद से, सभी तरह की वेबसाइटें लोगों को काम के विज्ञापन दिखा सकती हैं. इनमें वे वेबसाइटें भी शामिल हैं जो कॉन्टेंट क्रिएटर्स के साथ काम करती हैं. ये वेबसाइटें, लोगों को अलग-अलग पक्षों के साथ की गई उनकी गतिविधि के आधार पर विज्ञापन दिखाती हैं. ऐसा करते समय, वे लोगों की पहचान तीसरे पक्षों को नहीं दिखाती हैं. |
| टाइमलाइन को साफ़ तौर पर देखना | Privacy Sandbox की टेक्नोलॉजी के रिलीज़ शेड्यूल के बारे में ज़्यादा जानकारी. | Privacy Sandbox API के दस्तावेज़ में, एपीआई की स्थिति और उपलब्धता वाले पेज शामिल हैं. इन पेजों पर, आने वाली सुविधाओं और उनकी टाइमलाइन की जानकारी दी गई है. जैसे, PA API, ARA. इन स्थितियों का सेंट्रल व्यू यहां देखा जा सकता है. |
| मशीन लर्निंग | विज्ञापन टेक्नोलॉजी, मशीन लर्निंग मॉडल को तब तक ठीक से ट्रेन नहीं कर पाती, जब तक कि 3PCD 1% से ज़्यादा नहीं हो जाता. | टेस्टिंग के लिए 3PCD को ज़्यादा ब्राउज़र पर उपलब्ध कराने से, इस बात की गारंटी नहीं मिलती कि एपीआई का ज़्यादा इस्तेमाल होगा. ऐसा इसलिए, क्योंकि विज्ञापन टेक्नोलॉजी की टीमें, मशीन लर्निंग मॉडल को ट्रेन करने के लिए, एपीआई का ज़्यादा से ज़्यादा इस्तेमाल करना चाहती हैं. अगर मशीन लर्निंग मॉडल को बेहतर बनाने के लिए, विज्ञापन टेक्नोलॉजी की टीमें बड़े ईकोसिस्टम का इस्तेमाल नहीं करना चाहती हैं, तो 3PCD को बढ़ाने की कोई ज़रूरत नहीं है. ऐसा इसलिए, क्योंकि ज़्यादा ट्रैफ़िक पर मॉडल को ट्रेन करने के लिए, विज्ञापन टेक्नोलॉजी की टीमें आज भी 3PCD को बढ़ाए बिना ऐसा कर सकती हैं. ऐसा तब भी किया जा सकता है, जब Chrome स्टैंडस्टिल मोड खत्म होने से पहले, 3PCD पर आगे बढ़ता हुआ न दिखे. |
| इस्तेमाल का ऐसा उदाहरण जो काम नहीं करता | फ़िलहाल, सेल्फ़-सर्विस डीएसपी के इस्तेमाल के उदाहरणों पर विचार नहीं किया जा रहा है. | कई सेल्फ़-सर्विस डीएसपी, एपीआई के बारे में नियमित तौर पर सार्वजनिक सुझाव/राय/शिकायत दे रहे हैं. सार्वजनिक तौर पर नियमित तौर पर सुझाव/राय देने वाले कई डीएसपी ने खुद को टेस्टर के तौर पर भी शामिल किया है. इसके अलावा, Chrome, वीडियो और तीसरे पक्ष के विज्ञापन सर्वर जैसे सामान्य सेल्फ़-सर्विस डीएसपी विषयों पर भी लगातार काम कर रहा है. हाल ही के हफ़्ते के PA API कॉल में इन विषयों को शामिल किया गया है. |
| ऑरिजिन ट्रायल | 3PCD के लिए ज़्यादा तेज़ी से रैंप अप और टेस्ट कवरेज की ज़रूरत वाली साइटों के लिए, ओटी का अनुरोध. | फ़िलहाल, Chrome एक फ़र्स्ट पार्टी ओटी (ओरिजिन ट्रैक) बना रहा है. इससे ऑरिजिन को 3PC को धीरे-धीरे बंद करने की सुविधा के लिए ऑप्ट-इन करने में मदद मिलेगी. इस ट्रायल के लिए रजिस्टर करने वाले और टोकन डिप्लॉय करने वाले टॉप-लेवल ऑरिजिन के लिए, 3PC को इस तरह ब्लॉक कर दिया जाएगा जैसे उपयोगकर्ता के डिवाइस पर ट्रैकिंग सुरक्षा की सुविधा चालू हो. इस ओटी से, साइटों को 3PC के लंबे समय तक चलने वाले विकल्पों की ज़्यादा टेस्टिंग करने का अहम मौका मिलेगा. यह टेस्टिंग, सीएमए से सलाह लेने के बाद 3PC को पूरी तरह बंद करने से पहले की जाएगी. हम अभी भी ओटी के रोल आउट की टाइमलाइन को फ़ाइनल करने पर काम कर रहे हैं. |
| IAB Tech Lab की रिपोर्ट | IAB Tech Lab की रिपोर्ट से मिले, Privacy Sandbox के बारे में सुझाव/राय या शिकायत. | हमने IAB Tech Lab की रिपोर्ट का जवाब यहां दिया है. हमने यह भी स्वीकार किया कि "इस रिपोर्ट में, अलग-अलग दस्तावेज़ों, व्यावसायिक ज़रूरतों, तीसरे पक्ष के ऑडिट, इंडस्ट्री से जुड़े मान्यता, स्केलेबिलिटी, पारदर्शिता, और आने वाले समय में नीति बनाने के बारे में सवाल उठाए गए हैं. हम इन सवालों पर अपने नेटवर्क के साथ काम करेंगे और इसके हिसाब से, अक्सर पूछे जाने वाले सवालों की सूची को अपडेट करेंगे." हमने पहले अलग-अलग दस्तावेज़ों में मौजूद जानकारी को एक जगह पर इकट्ठा करने की सुविधा दी थी. हम "डेटा की गारंटी" में बताई गई व्यावसायिक ज़रूरतों के बारे में यहां बताते हैं. साथ ही, Google Ads के कुछ प्रॉडक्ट ने अपने तरीके शेयर किए हैं. तीसरे पक्ष के ऑडिट के बारे में यहां बताया गया है. यह जानकारी, "एल्गोरिदम के सही होने की गारंटी" में दी गई है. मान्यता देने के लिए, हम चाहते हैं कि ये निकाय प्रॉडक्ट को मान्यता देते रहें. इसमें, टेक्नोलॉजी के इस्तेमाल के साथ-साथ टेक्नोलॉजी को भी मान्यता दी जा सकती है. स्केलेबिलिटी के बारे में, हम डेवलपर से मिलने वाले ऐसे डेटा को स्वीकार करते रहेंगे जिसमें समस्याओं के बारे में बताया गया हो. पारदर्शिता और गवर्नेंस के लिए, हम GitHub और W3C जैसे फ़ोरम पर सार्वजनिक तौर पर काम करना जारी रखेंगे. साथ ही, हम CMA के साथ किए गए वादे के तहत, CMA के साथ काम करना जारी रखेंगे. |
| Google साइन-इन | Google साइन-इन की सुविधा से, Google को आपके क्रॉस-आइडेंटिफ़िकेशन लॉग-इन डेटा का इस्तेमाल करने का विकल्प मिल सकता है. हालांकि, ऐसा करने से Google की प्रतिबद्धताओं का उल्लंघन होता है. | Google Sign-In की मदद से, Google आपके डेटा का इस्तेमाल, किए गए वादे के मुताबिक ही करता है. |
| इनके साथ काम करता है | Privacy Sandbox के एपीआई के लिए सहायता और फ़ॉरवर्ड / बैकवर्ड कम्पैटिबिलिटी के क्या प्लान हैं? | जब Chrome किसी सुविधा को सभी के लिए उपलब्ध कराता है, तो हमारा मकसद उस सुविधा के लिए सहायता उपलब्ध रखना होता है. हालांकि, यह हमेशा मुमकिन नहीं होता कि किसी एपीआई को पुराने वर्शन के साथ काम करने लायक रखा जाए. ऐसे मामलों में, हम मौजूदा सुविधाओं को बंद करने और हटाने के लिए एक साफ़ प्रक्रिया अपनाते हैं. इस बारे में यहां बताया गया है. हमें उम्मीद है कि समय के साथ, Privacy Sandbox API में और भी सुविधाएं जोड़ी जाएंगी. ऐसा, इस्तेमाल के उन उदाहरणों के बारे में पारिस्थितिकी तंत्र से मिले सुझावों के आधार पर किया जाएगा जिनमें बेहतर सहायता से फ़ायदा होगा. ऐसे मामलों में, हम सुविधा का पता लगाने वाली किसी तकनीक को शामिल करते हैं. इससे, नई सुविधा के साथ प्रयोग करने में दिलचस्पी रखने वाला विज्ञापन टेक्नोलॉजी (विज्ञापन दिखाने से जुड़ी टेक्नोलॉजी) सीधे ब्राउज़र से पूछ सकता है कि सुविधा काम करती है या नहीं. यह तरीका, डेवलपर से Chrome के किसी खास वर्शन की संख्या देखने के लिए कहने से बेहतर है. ऐसा इसलिए, क्योंकि हो सकता है कि कुछ सुविधाएं Chrome के सभी उपयोगकर्ताओं के लिए एक ही समय पर रोल आउट न हों. उदाहरण के लिए, PA API के लिए सुविधाओं का पता लगाने से जुड़ा हमारा काम यहां देखा जा सकता है. |
| सर्वर पर लागू करना | Chrome को अपने तरीके से लागू करने के बजाय, यह बताना चाहिए कि भरोसेमंद सिग्नल सर्वर, एग्रीगेशन सर्वर, और ब्राउज़र के अलावा ज़रूरी अन्य कॉम्पोनेंट को सही तरीके से लागू करने के लिए, कौनसी शर्तें पूरी करनी होंगी. इससे, निजता की सीमाओं के मुताबिक इनोवेशन को बढ़ावा मिलेगा. | हम बाहरी पक्षों की नई सोच का स्वागत करते हैं और उनकी सराहना करते हैं. हमारा मकसद सभी एपीआई और सेवाओं के लिए, विज्ञापन टेक्नोलॉजी को उनके फ़ंक्शन को लागू करने की सुविधा देना है. उदाहरण के लिए, हम विज्ञापन टेक्नोलॉजी को नीलामियों के लिए बिडिंग लॉजिक डिज़ाइन करने में, कारोबार की गोपनीय जानकारी का इस्तेमाल करने की अनुमति देते हैं. इसके अलावा, हम विज्ञापन टेक्नोलॉजी से मिलने वाले सुझावों और राय पर लगातार काम करते हैं. साथ ही, जहां ज़रूरी हो वहां उन्हें अपने डिज़ाइन में शामिल करते हैं. दूसरे लोगों को भरोसेमंद एक्सीक्यूशन एनवायरमेंट में अपना कोड चलाने की अनुमति देने के लिए, Privacy Sandbox को कोड और उसमें किए गए किसी भी बदलाव की समीक्षा करनी होगी. इससे यह पक्का किया जा सकेगा कि वह निजता की गारंटी को पूरा करता है. इसके लिए, Privacy Sandbox की टीम को काफ़ी मेहनत करनी होगी. इसलिए, हम यह जानना चाहते हैं कि हिस्सेदार को कौनसे फ़ायदे चाहिए, जो आज हम नहीं दे पा रहे हैं. |
| ह्यूरिस्टिक्स (तय नियम) | हेयुरिस्टिक्स के लिए लंबे समय के क्या प्लान हैं? | अन्य ब्राउज़र के सुझावों के मुताबिक, हम इन हेयुरिस्टिक्स को हटाने जा रहे हैं. ऐसा इसलिए, क्योंकि अन्य समाधानों का ज़्यादा से ज़्यादा इस्तेमाल किया जा रहा है. हालांकि, इसकी संभावना का विश्लेषण किया जाएगा. हमने इसे यहां शेयर किया है. |
| वॉल्यूम की जांच करना | अलग-अलग डाइमेंशन की तुलना करते समय, ट्रैफ़िक की अलग-अलग संख्या. | 1% एक्सपेरिमेंट में, शामिल न किए जाने की शर्तें शामिल हैं. इन शर्तों की वजह से, Chrome क्लाइंट की अलग-अलग संख्या के बीच, एक्सपेरिमेंट में शामिल होने की ज़रूरी शर्तों में अंतर होता है. उदाहरण के लिए, एक्सपेरिमेंट में Chrome Enterprise के उपयोगकर्ता शामिल नहीं हैं. इसलिए, यह उम्मीद की जाती है कि एक्सपेरिमेंट लेबल वाले ट्रैफ़िक का हिस्सा, शनिवार और रविवार को ज़्यादा होगा. अलग-अलग डेटा स्लाइस (जैसे, भौगोलिक, तारीख, और प्लैटफ़ॉर्म) में ट्रैफ़िक के अलग-अलग प्रतिशत दिखने की उम्मीद है. यह वही डेटा है जो हमें Chrome के डेटा में दिख रहा है. |
| 3PC को मैन्युअल तरीके से फिर से चालू करना | क्या साइटों को यह पता चल पाएगा कि 3PCD लागू होने के बाद, कितने उपयोगकर्ताओं (%) ने मैन्युअल तरीके से कुकी फिर से चालू की हैं? | अगर उपयोगकर्ताओं को कोई समस्या आती है, तो वे साइट लेवल पर उपयोगकर्ता बायपास की सुविधा का इस्तेमाल करके, 3PC ऐक्सेस को फिर से चालू कर सकते हैं. Storage Access API जैसे अन्य तरीकों से भी 3PC को फिर से चालू किया जा सकता है. hasStorageAccess() जैसे तकनीकी उपायों की मदद से, साइटें यह पता लगा सकती हैं कि 3PC चालू हैं या बंद. हालांकि, Chrome, वेबसाइटों को यह जानने की सुविधा नहीं देगा कि उन्हें फिर से चालू करने की वजहें क्या हैं. |
| ट्रैकिंग सुरक्षा | Chrome की ट्रैकिंग सुरक्षा की यूज़र इंटरफ़ेस (यूआई) सुविधा कितने समय तक उपलब्ध रहेगी? | पता बार में ट्रैकिंग की रोकथाम से जुड़ा यूज़र इंटरफ़ेस (यूआई), 3PCs के बंद होने के बाद भी उपलब्ध रहेगा. |
| (पिछली तिमाहियों में भी इसकी शिकायत की गई थी) अलग-अलग ब्राउज़र पर काम करने की सुविधा |
Privacy Sandbox APIs का इस्तेमाल करने वाले अन्य ब्राउज़र वेंडर. | Apple, Mozilla, और Microsoft जैसे अन्य ब्राउज़र वेंडर, सार्वजनिक फ़ोरम में सक्रिय रूप से हिस्सा लेते हैं. इन फ़ोरम में निजता के सिद्धांतों और ब्राउज़र पर आधारित तरीकों के बारे में चर्चा की जाती है. हमें फ़ोरम में मिलकर की गई चर्चाओं से खुशी हो रही है. जैसे, हाल ही में हुई W3C की सालाना TPAC मीटिंग और चल रहे W3C PATCG फ़ोरम. इनमें हमें एक साथ काम करने के संकेत दिख रहे हैं. उदाहरण के लिए, Microsoft Edge ने हाल ही में अपने प्लान के बारे में बताया है. इसका मकसद, PA API और ARA के साथ सिंटैक्टिक (वाक्य-विन्यास) के हिसाब से, ज़्यादा से ज़्यादा काम करना है. साथ ही, इसमें डेवलपर के लिए अन्य सुविधाएं भी दी गई हैं. |
| 3PCD के बाद, काम न करने वाले एम्बेड के लिए फ़ॉलबैक विकल्प | एपीआई हुक दें, ताकि यह पता लगाया जा सके कि तीसरे पक्ष का iframe / एम्बेड, 3PCD का पालन करता है या नहीं. | हम इस अनुरोध पर यहां चर्चा कर रहे हैं. साथ ही, हम इस बारे में नेटवर्क से जुड़े लोगों के सुझाव, राय या शिकायतें भी स्वीकार करते हैं. |
| टेस्ट करना | Chrome के मैनेज किए जा रहे इंस्टेंस में, ऐसे अतिरिक्त फ़्लैग के लिए अनुरोध करना जो उपयोगकर्ता के हिसाब से बनाए गए व्यवहार को कुछ समय के लिए बंद कर दें. | हम Chrome के मैनेज किए जा रहे इंस्टेंस के लिए, इस अनुरोध पर विचार कर रहे हैं. अगर ऐसा फ़्लैग काम का होगा, तो हम नेटवर्क से जुड़े अन्य लोगों के सुझावों का स्वागत करते हैं. |
रजिस्टर करना और पुष्टि करना
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| पुष्टि करने की प्रक्रिया | Google, पुष्टि करने वाले दस्तावेज़ों की पुष्टि कैसे करेगा? | रजिस्टर करने वाले सभी लोगों को एपीआई का इस्तेमाल करते समय, पुष्टि करने वाली फ़ाइल को अप-टू-डेट रखना होगा. Google इस बात की पुष्टि करता है कि फ़ाइल मौजूद है और सिंटैक्स सही है. हालांकि, Google, पुष्टि करने वाली भाषा के हिसाब से विज्ञापन टेक्नोलॉजी के व्यवहार की पुष्टि नहीं करता. |
| Private Aggregation API के लिए रजिस्टर करने की प्रोसेस | क्या Private Aggregation API के रजिस्ट्रेशन की स्थिति की जांच करने का कोई तरीका है? | रजिस्टर करने की पुष्टि होने के बाद, रजिस्टर करने वाले सभी लोगों को रजिस्टर करने से जुड़ी सहायता टीम से ईमेल से सूचना दी जाती है. अगर रजिस्ट्रेंट को इस प्रोसेस के दौरान कोई सवाल पूछना है, तो वह सहायता टीम से संपर्क कर सकता है. रजिस्ट्रेंट को रजिस्ट्रेशन फ़ॉर्म सबमिट करने के बाद, सहायता टीम से संपर्क करने की जानकारी मिलती है. सहायता टीम आपके सवालों के जवाब देगी और ज़रूरत पड़ने पर आपको अन्य निर्देश भी देगी. |
काम का कॉन्टेंट और विज्ञापन दिखाना
विषय
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| (पिछली तिमाहियों में भी रिपोर्ट की गई) क्लासिफ़ायर की टाइमलाइन और दस्तावेज़ |
कॉन्टेंट की कैटगरी तय करने की समीक्षा करने के लिए, कोई ऐसा तरीका होना चाहिए जिससे यह पता चल सके कि कॉन्टेंट की कैटगरी तय करने के लिए, क्लासिफ़िकेशन मोड किस तरह काम करता है. | हमारी पिछली तिमाहियों के जवाब में कोई बदलाव नहीं हुआ है: "साइटों को गलत कैटगरी में डालने से, Topics सिग्नल को सिग्नल के तौर पर थोड़ा कम काम का बना सकता है. हालांकि, गलत कैटगरी में डाली गई साइटों को किसी दूसरी साइटों की तुलना में ज़्यादा या कम नुकसान नहीं होता. ऐसा इसलिए है, क्योंकि किसी साइट की संदर्भ जानकारी, उसकी साइट पर होने वाली नीलामियों के लिए हमेशा उपलब्ध रहेगी. इससे, गलत कैटगरी में डाले जाने के मामले में भी, सही विषय के बारे में तुलना की जा सकने वाली जानकारी मिलती रहेगी. इस विषय पर यहां सुझाव/राय दें या शिकायत करें." |
| Google Ad Manager | Google Ad Manager, ज़्यादातर साइटों पर पहले से ही एम्बेड है. साथ ही, इसमें उपयोगकर्ता के विषयों के बारे में ज़्यादा जानकारी होगी. यह जानकारी, उन प्रतिस्पर्धियों की तुलना में ज़्यादा होगी जो कम साइटों पर मौजूद हैं. | निगरानी की ज़रूरत इसलिए है, ताकि यह पक्का किया जा सके कि Topics API की वजह से, उपयोगकर्ता का डेटा उन इकाइयों के साथ शेयर न किया जाए जो एपीआई की जगह ले रही हैं. इनमें तीसरे पक्ष की कंपनियां भी शामिल हैं. इंडस्ट्री के अन्य सलूशन, जैसे कि Prebid, 10 हज़ार साइटों के साथ काम करते हैं. साथ ही, मार्केट में हिस्सा लेने वाले लोग अपनी टेक्नोलॉजी की मदद से Topics API को कॉल कर सकते हैं. इसके अलावा, यह ध्यान देने वाली बात है कि हर हफ़्ते पांच टॉप विषयों की सीमा से, सभी को एक जैसा फ़ायदा मिल सकता है. ऐसा इसलिए, क्योंकि कई साइटों पर मौजूद मार्केट में हिस्सा लेने वाले लोग, तीन पीसी का इस्तेमाल करके पांच से ज़्यादा विषयों के बारे में जान सकते हैं. हालांकि, अब उन्हें सिर्फ़ पांच विषयों के बारे में ही जानकारी मिलेगी. |
| (पिछली तिमाहियों में भी रिपोर्ट की गई थी) अलग-अलग तरह के हिस्सेदारों के लिए काम की जानकारी |
साइटों के लिए बनाई गई वैल्यू और उस वैल्यू के डिस्ट्रिब्यूशन से जुड़ी चिंताएं. यह वैल्यू, साइटों पर आने वाले ट्रैफ़िक के लेवल या उनके कॉन्टेंट के खास होने के आधार पर तय होती है. | हम जानते हैं कि खास विषयों पर बनी साइटों में, सामान्य विषयों पर बनी साइटों की तुलना में ज़्यादा जानकारी वाले विषयों के बारे में जानकारी देने की संभावना ज़्यादा होती है. हालांकि, सभी खास साइटें, व्यावसायिक तौर पर अहम विषयों पर योगदान नहीं देती हैं. साथ ही, यह डाइनैमिक स्थिति को दिखाता है और यह Chrome में 3PC के लिए सहायता बंद होने से पूरी तरह से अलग है. साथ ही, मौजूदा माहौल में, 3PC पर आधारित विज्ञापन दिखाने के सिस्टम में, कुछ साइटें दूसरों की तुलना में ज़्यादा वैल्यू देती हैं. इसके अलावा, खास विषयों पर काम करने वाली साइटों के लिए, विषयों के बीच आपस में फ़ायदा हो सकता है. ऐसा इसलिए, क्योंकि विज्ञापन देने वाले अलग-अलग विषयों के सेट पर कैंपेन चला सकते हैं और बिडिंग लॉजिक, कई तरह के विषयों पर वैल्यू देख सकता है. |
| होस्टनेम बनाम पूरे यूआरएल | क्या वेबसाइटों के होस्टनेम के आधार पर कैटगरी तय करना काफ़ी असरदार है? क्या इससे पूरे यूआरएल की तुलना में निजता के जोखिम को कम किया जा सकता है? | हमने होस्टनेम के अलावा, जानकारी वाले यूआरएल या पेज के टाइटल का इस्तेमाल करने पर भी विचार किया. हालांकि, हमने पाया कि इससे उपयोगकर्ता की निजता और सुरक्षा को खतरा हो सकता है. उपयोगकर्ता की निजता के जोखिमों के उदाहरण में, यूआरएल या पेज के टाइटल में शामिल संवेदनशील जानकारी को उपयोगकर्ता के विषयों में बांटना शामिल है. |
| सिग्नल के तौर पर विषय | Topics को अन्य सिग्नल के साथ जोड़ने के तरीके के बारे में दिशा-निर्देश पाने का अनुरोध करें. साथ ही, यह भी जानें कि कौनसे अन्य सिग्नल काम के हो सकते हैं. | विज्ञापन टेक्नोलॉजी के समाधान, उपलब्ध सभी टूल को जोड़कर सबसे अच्छे नतीजे दे सकते हैं. जैसे, मशीन लर्निंग और निजता बनाए रखने वाले एपीआई से मिले निजता को सुरक्षित रखने वाले सिग्नल. साथ ही, संदर्भ के हिसाब से डेटा, क्रिएटिव डेटा, और पहले पक्ष (ग्राहक) का डेटा. इस बारे में ज़्यादा जानकारी यहां उपलब्ध है. |
Protected Audience API (पहले इसे FLEDGE के नाम से जाना जाता था)
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| ट्रैफ़िक की संख्या की जांच करना | टेस्टर, PA API नीलामी के लिए बिड रिस्पॉन्स की कम संख्या की शिकायत कर रहे हैं. | 1. बिड डेंसिटी, PA API में नेटवर्क की भागीदारी से जुड़ी होती है. हमें उम्मीद है कि यह 2024 और उसके बाद भी बढ़ती रहेगी. कैंपेन के बजट को कैसे बांटना है, यह तय करने का अधिकार विज्ञापन देने वाले लोगों या कंपनियों, उनकी एजेंसियों, और टेक्नोलॉजी से जुड़ी सेवा देने वाली कंपनियों के पास होता है. हमें उम्मीद है कि पारिस्थितिकी तंत्र में शामिल कुछ लोग, पीएससीडी के बाद तक, PA API के साथ-साथ "बिना कुकी वाले" अलग-अलग समाधानों में निवेश करने में देरी कर सकते हैं. हमें उम्मीद है कि इस समय वे ऐसे समाधानों के लिए, अपने कैंपेन के बजट के बंटवारे को बढ़ा सकते हैं. 2. PA API नीलामियों में बिड रिक्वेस्ट की संख्या पर (1) का असर पड़ सकता है. अगर पब्लिशर और विज्ञापन टेक्नोलॉजी की सेवा देने वाली कंपनियों को लगता है कि मांग कम है, तो वे PA API नीलामियां शुरू न करने का फ़ैसला ले सकती हैं. पब्लिशर यह तय करते हैं कि उन्हें अपने पेजों को अपडेट करने और इस प्रोग्राम में हिस्सा लेने की प्राथमिकता देनी है या नहीं. इन वजहों से, हमें लगता है कि पब्लिशर को टेस्ट करने और ट्रैफ़िक को धीरे-धीरे बढ़ाने में समय लग सकता है. इस रिपोर्ट में, PA API प्रोग्राम में शामिल होने के लिए, Google Ad Manager के पब्लिशर कंट्रोल के बारे में भी जानकारी शामिल है. |
| (पिछली तिमाहियों में भी इसकी शिकायत की गई थी) धोखाधड़ी / गलत इस्तेमाल |
इकोसिस्टम, इन जोखिमों को कैसे कम कर सकता है और बुरे लोगों या खरीदारों को, खुद को काम की ऑडियंस के तौर पर पेश करने से कैसे रोक सकता है? | PA API विज्ञापनों की रिपोर्टिंग के तरीके, आज भी उस जानकारी को सेव रखते हैं जिसका इस्तेमाल, लोगों और बॉट ट्रैफ़िक के बीच अंतर करने के लिए किया जाता है. इसके अलावा, डोमेन को शामिल करने या बाहर रखने के लिए, डोमेन पर आधारित मौजूदा तकनीकों का इस्तेमाल PA API में किया जा सकता है. इस बारे में ज़्यादा जानकारी, Privacy Sandbox से जुड़ी IAB Tech Lab की रिपोर्ट के हमारे जवाब में दी गई है. |
| आईजी के मालिक और बिडिंग लॉजिक यूआरएल पर एक ही ऑरिजिन की पाबंदी | एक ही ऑरिजिन की ज़रूरी शर्त के तहत, IG के मालिक के एंडपॉइंट को एक ही लोड बैलेंसर से गुज़रना होगा. इस वजह से, रीडायरेक्ट अस्वीकार किए जा सकते हैं. | स्क्रिप्ट लोड करने के लिए, एक ही ऑरिजिन की ज़रूरी शर्त, सुरक्षा से जुड़ी एक अहम बात है. यहां एक सुझाए गए समाधान के बारे में कुछ जानकारी दी गई है. यह समाधान, नेटवर्क के फ़ीडबैक और अन्य बातों को ध्यान में रखता है यहां. |
| मल्टी-स्लॉट निजी नीलामी | निजता की सीमाओं के अंदर, मल्टी-स्लॉट प्राइवेट नीलामियों की अनुमति देने के लिए काफ़ी जगह है. इसके लिए, विज्ञापन के मौजूदा तरीकों के साथ ग़ैर-ज़रूरी जानकारी को हटाने और ज़्यादा इंटिग्रेशन का इस्तेमाल किया जा सकता है. | हम इस सुझाव पर विचार कर रहे हैं. साथ ही, इस सुविधा से जुड़ी जटिलता और निजता से जुड़े जोखिमों को ध्यान में रखते हुए, मल्टी-टैग नीलामियों के अनुरोध का आकलन कर रहे हैं. हमने इस समस्या के बारे में ज़्यादा जानकारी यहां दी है. यह जानकारी, PA API वेब इनक्यूबेटर कम्यूनिटी ग्रुप (WICG) के कॉल के दौरान दी गई थी. |
| टॉप लेवल सेलर | PA API के मौजूदा स्ट्रक्चर की मदद से, किसी भी टॉप-लेवल सेलर को पब्लिशर या कॉम्पोनेंट सेलर के मुकाबले, इंप्रेशन की तुलनात्मक वैल्यू के बारे में काफ़ी ज़्यादा डेटा और जानकारी मिलती है. | एक से ज़्यादा सेलर वाली नीलामी में, हर सेलर की एक सबसे अच्छी बिड होगी. इसके अलावा, हमें पारिस्थितिकी तंत्र से पता चला है कि पब्लिशर, उन सभी सेलर की सबसे अच्छी बिड के साथ-साथ, डायरेक्ट-सोल्ड डिमांड को भी ध्यान में रख सकते हैं जिनके साथ वे काम करते हैं. कमाई करने के इन सभी संभावित अवसरों को ध्यान में रखकर यह तय करना ज़रूरी है कि कौनसा विज्ञापन दिखाया जाए. PA API से पहले भी, किसी विज्ञापन को दिखाने के लिए, विज्ञापन देने वाले को विकल्पों का पूरा सेट देखना पड़ता था. PA API, मल्टी-सेलर ऑक्शन और पब्लिशर की उस इच्छा को पूरा करने की कोशिश करता है जिसमें वे सीधे तौर पर बेचे जाने वाले विज्ञापन कैंपेन के साथ-साथ, हर सेलर की सबसे अच्छी बिड को भी शामिल करना चाहते हैं. हालांकि, ऐसा सिर्फ़ तब किया जाता है, जब सीधे तौर पर बेचे जाने वाले विज्ञापन कैंपेन लागू हों. इसका मतलब है कि कमाई करने के उन अवसरों में से किसी एक को चुनने के लिए, आज की तरह ही कोई तरीका होना चाहिए. हम इस बात से सहमत नहीं थे कि ब्राउज़र यह तय करे कि कौनसा विज्ञापन दिखाना है. इसलिए, कई विकल्पों में से सबसे अच्छा विज्ञापन चुनने के लिए, टॉप-लेवल सेलर का कॉन्सेप्ट ज़रूरी है. टॉप लेवल सेलर का लॉजिक, उन सभी सेलर की सबसे अच्छी बिड को ध्यान में रखना चाहिए जिनके साथ पब्लिशर काम करना चाहता है. साथ ही, सेलर के लॉजिक में पब्लिशर के सीधे तौर पर बेचे जाने वाले कैंपेन की जानकारी देने का विकल्प हो सकता है. हालांकि, यह जानकारी तब ही दी जाएगी, जब वह उपलब्ध हो. इस सभी जानकारी को, विज्ञापन चुनने के टॉप-लेवल लॉजिक में शामिल किया जा सकता है. इसका मतलब है कि टॉप-लेवल लॉजिक, PA API नीलामी की सबसे अच्छी बिड देखता है. साथ ही, जहां लागू हो वहां पब्लिशर से सीधे तौर पर बेचे गए विज्ञापन के विकल्पों को देखता है, ताकि यह तय किया जा सके कि कौनसा विज्ञापन दिखाया जाए. Google Ad Manager, "जानकारी का ऐक्सेस" थीम के तहत, इस रिपोर्ट में टॉप-लेवल सेलर के तौर पर PA API को लागू करने के बारे में जानकारी देता है. |
| प्रतिस्पर्धी विज्ञापन को अलग करना | प्रतिस्पर्धी विज्ञापनों को अलग करने का अनुरोध करना. जैसे, प्रतिस्पर्धी ब्रैंड के विज्ञापनों को एक-दूसरे के बगल में दिखने से रोकना. | हम इस बात से अनजान हैं कि आज के प्रोग्रामैटिक, बिड वाले, और कई सेलर वाले डिजिटल विज्ञापन नेटवर्क में, प्रतिस्पर्धा में अलग दिखने का तरीका क्या है. हालांकि, PA API की मदद से सेलर, renderURL और होस्टनेम (पब्लिशर के डोमेन को दिखाता है) के कॉम्बिनेशन के आधार पर, रीयल-टाइम में ज़्यादा सिग्नल फ़ेच कर सकते हैं. इन सिग्नल का इस्तेमाल, क्रिएटिव को स्कोर करते समय scoreAd() के दौरान किया जा सकता है. सेलर इस सुविधा का इस्तेमाल करके, एक-दूसरे से प्रतिस्पर्धा करने वाले ब्रैंड के विज्ञापनों को एक-दूसरे के बगल में दिखने से रोक सकते हैं. हालांकि, इसके लिए यह ज़रूरी है कि पब्लिशर इस नियम को लागू करना चाहता हो. |
| सीमित जानकारी | PA API, पब्लिशर के लिए उपलब्ध जानकारी को कम कर देता है. जैसे, विज्ञापन की वैल्यू, कॉम्पोनेंट के खरीदार का नाम, विज्ञापन देने वाले का नाम, लैंडिंग पेज का यूआरएल, क्रिएटिव का साइज़, रिस्पॉन्स में लगने वाला समय, और बिड रेट. साथ ही, यह हारने वाली बिड की जानकारी भी कम कर देता है. | हमने यहां कुछ संभावित समाधानों का सुझाव दिया है. साथ ही, हम इकोसिस्टम से और सुझाव, राय या शिकायतें पाने के लिए तैयार हैं. |
| इवेंट-लेवल की रिपोर्टिंग | इवेंट-लेवल रिपोर्टिंग PA API के बंद होने के बाद, पब्लिशर को दिखाए गए विज्ञापन के बारे में ज़रूरत के मुताबिक जानकारी नहीं मिल पा रही है. | हम रिपोर्टिंग के इस्तेमाल के अलग-अलग उदाहरणों के बारे में जानते हैं. इवेंट-लेवल रिपोर्टिंग बंद होने के बाद भी, हमें इनका इस्तेमाल जारी रखना होगा. इसलिए, हमने इवेंट-लेवल रिपोर्टिंग को बंद करने की तारीख 2026 से पहले नहीं रखी है. हम आपको इस प्रोसेस में हिस्सा लेने का न्योता देते हैं, ताकि हम इस नेटवर्क के साथ मिलकर, आने वाले समय में निजता को बनाए रखते हुए जानकारी पाने के नए तरीके ढूंढ सकें. |
| एक से ज़्यादा एसएसपी | एक से ज़्यादा एसएसपी का इस्तेमाल करने से, पब्लिशर को मिलने वाली अतिरिक्त वैल्यू बहुत कम होगी. | हमें नहीं लगता कि यह सही है. इस दावे की वजह समझने के लिए, हम इकोसिस्टम से ज़्यादा सुझाव या राय पाना चाहते हैं. |
| क्यूरेशन से जुड़ी गतिविधियां | PA API की मदद से, कलेक्शन बनाने की गतिविधियां नहीं की जा सकतीं. | हमें सेलर के लिए PA API का इस्तेमाल करने की सुविधा के बारे में सुझाव मिले हैं. इससे वे वेब पर खरीदारों को अपनी ऑडियंस की जानकारी दे पाएंगे. इसे ऑडियंस एक्सटेंशन भी कहा जाता है. हमारा मानना है कि कारोबारी समझौतों के साथ-साथ, पीए को काम सौंपने की सुविधा का इस्तेमाल करके, आज भी ऐसा किया जा सकता है. साथ ही, हम इस बात पर लगातार काम कर रहे हैं कि इस तरह के इस्तेमाल के उदाहरणों को बेहतर तरीके से कैसे शामिल किया जा सकता है. |
| खरीदार का ऑप्ट-आउट | खरीदार के डिफ़ॉल्ट रूप से ऑप्ट-आउट करने की वजह से, कॉम्पोनेंट की नीलामियों के नतीजे खराब हो सकते हैं. | एक सेलर या एक से ज़्यादा सेलर वाली पीए नीलामी तय करते समय, सेलर को AuctionConfig के interestGroupBuyers फ़ील्ड में खरीदारों की साफ़ तौर पर सूची बनानी होगी. यह बदलाव, नेटवर्क से मिले सुझावों के आधार पर किया जा रहा है. इन सुझावों के मुताबिक, सेलर कुछ खरीदारों के साथ कानूनी समझौते करते हैं, लेकिन कुछ के साथ नहीं. इसलिए, यह तय करना ज़रूरी है कि नीलामी में किन खरीदारों को शामिल किया जाए. हम GitHub पर इस बारे में आगे की चर्चा के लिए तैयार हैं. |
| विज्ञापन का साइज़ | विज्ञापन के साइज़ और विज्ञापन स्लॉट के साइज़ के आधार पर, पहले से फ़िल्टर नहीं किया जा सकता. | हम इस सुविधा को जोड़ने पर काम कर रहे हैं. इस बारे में ज़्यादा जानकारी यहां उपलब्ध है. |
| इंस्टाग्राम पर नेगेटिव टारगेटिंग की सुविधा | नेगेटिव आईजी टारगेटिंग के लिए एपीआई: सिर्फ़ तब विज्ञापन दिखाना, जब कोई उपयोगकर्ता किसी आईजी से न जुड़ा हो. | GitHub पर मौजूद इस समस्या में, नेगेटिव टारगेटिंग लागू करने का एक अन्य तरीका बताया गया है. इसमें ब्राउज़र, विज्ञापन सर्वर को सीधे तौर पर बताता है कि किसी खास विज्ञापन अनुरोध के लिए, नेगेटिव टारगेटिंग के कौनसे नियम लागू होने चाहिए. यह एक आकर्षक तरीका है. हालांकि, हमने इस आइडिया के सभी वर्शन की जांच की है. इनसे पता चला है कि सर्वर, उपयोगकर्ता की पहचान करने में सक्षम है. |
| डिजिटल सर्विसेज़ ऐक्ट | पब्लिशर, फ़ेंस किए गए फ़्रेम का इस्तेमाल कैसे कर सकता है, लेकिन डिजिटल सर्विसेज़ ऐक्ट के दायरे में आने वाली जानकारी वाले रिस्पॉन्स को रेंडर होने से कैसे रोक सकता है? | किसी भी नई टेक्नोलॉजी की तरह, यह पक्का करना हर कंपनी की ज़िम्मेदारी है कि Privacy Sandbox का इस्तेमाल कानून के मुताबिक हो. Google, दूसरों को कानूनी सलाह नहीं दे सकता. हमने हर एपीआई के लिए, ज़्यादा से ज़्यादा तकनीकी दस्तावेज़ पब्लिश किए हैं. इनसे, ज़रूरी कानूनी आकलन करने में मदद मिलती है. PA API में फ़ेंस किए गए फ़्रेम का इस्तेमाल, 2026 से पहले नहीं किया जा सकता. इससे हिस्सेदारों को यह पक्का करने के लिए ज़्यादा समय मिलता है कि इस टेक्नोलॉजी का इस्तेमाल, सभी ज़रूरी कानूनों का पालन करते हुए किया जा रहा है. |
| दस्तावेज़ | क्या updateAdInterestGroups() कुछ समय के लिए है? | हमने updateAdInterestGroup को बंद करने का कोई एलान नहीं किया है. आने वाले समय में, हम निजता की सुरक्षा के लिए वही तरीके अपना सकते हैं जिनके बारे में हमने सार्वजनिक तौर पर, IG के अपडेट करने के अन्य तरीकों के लिए बताया है. जैसे, आईपी पते और प्रॉक्सी का इस्तेमाल करना और अपडेट होने से पहले कुछ देरी करना. |
| डीएसपी के अलावा अन्य लोगों के लिए, बायसाइड मेटाडेटा और लॉजिक के मालिकाना हक से जुड़ी सहायता | डीएसपी के लिए प्रॉक्सी के तौर पर काम करने का अनुरोध करें. | हम डीएसपी से बाहर के सेगमेंट से मिले इस सुझाव के बारे में जानते हैं और इस अनुरोध पर विचार कर रहे हैं. हमें इस बारे में और सुझाव, शिकायत या राय मिल सकती है. |
| रिपोर्टिंग | निजी एग्रीगेशन रिपोर्टिंग में, सिग्नल बकेट / वैल्यू के लिए कस्टम हैंडलर की सुविधा जोड़ने का अनुरोध. | हम इस सुविधा के बारे में जानते हैं. इस सुविधा के लिए किए गए अनुरोध पर हम आगे काम करेंगे. यहां जाकर, हमें अपने सुझाव/राय/शिकायत भेजें. |
| दस्तावेज़ | क्या कोई ऐसा लिंक है जहां उन सभी रिस्पॉन्स हेडर को देखा जा सकता है जिन्हें विज्ञापन देने वाले और (अधिकार सौंपे गए) मालिक के डोमेन को सेट करना होगा? | हम इस बारे में साफ़ तौर पर बताने के लिए, दस्तावेज़ों में अपडेट करने जा रहे हैं. साथ ही, हम इस बारे में अपने क्रिएटर्स से सुझाव, राय या शिकायतें भी सुनना चाहते हैं. |
| मल्टी-टावर बिडिंग | आर्किटेक्चर / ब्लॉक डायग्राम की मदद से, वर्कफ़्लो (ट्रेनिंग और अनुमान) के बारे में जानकारी का अनुरोध करें. इसमें, PA API के संदर्भ में मल्टी-टावर वाले तरीके के बारे में बताया गया हो. | शिकायत करने या सुझाव/राय देने के लिए धन्यवाद. हमारे पास इस विषय पर कुछ प्रज़ेंटेशन हैं. इनसे हमें ज़्यादा दस्तावेज़ बनाने में मदद मिलेगी. |
| नेगेटिव टारगेटिंग | प्राइवसी सैंडबॉक्स की मदद से, संवेदनशील ऑडियंस और नाबालिगों को आपत्तिजनक विज्ञापनों से बचाया जा सकता है. जैसे, जुए के विज्ञापन. | PA API, दिखाए गए विज्ञापनों के कॉन्टेंट पर ध्यान नहीं देता. यह पीए का इस्तेमाल करने वाले विज्ञापन टेक्नोलॉजी डेवलपर के कंट्रोल में होता है. आम तौर पर, पब्लिशर और विज्ञापन टेक्नोलॉजी की सेवा देने वाली कंपनियां, पेज की संदर्भ जानकारी और पब्लिशर के नियमों के सेट का इस्तेमाल करके, सुरक्षित ऑडियंस की नीलामियों में विज्ञापन क्रिएटिव को ब्लॉक कर सकती हैं. इससे हमें यह समझने में मदद मिलती है कि आज के समय में, नेटवर्क इन चुनौतियों को कैसे हल कर रहा है. खरीदारों के लिए, नीति का पालन करने के कुछ उदाहरणों में, नेगेटिव आईजी टारगेटिंग की सुविधा भी काम की हो सकती है. |
| एपीआई डिज़ाइन | Google इस पर रोक लगा रहा है और विज्ञापन टेक्नोलॉजी की मदद से, यूनिवर्सल बिडिंग फ़ंक्शन का इस्तेमाल करने के लिए कह रहा है. इससे अलग-अलग आईजी में अलग-अलग बिडिंग लॉजिक यूआरएल के बजाय, इंतज़ार का समय बढ़ जाता है. हालांकि, अलग-अलग आईजी में अलग-अलग बिडिंग लॉजिक यूआरएल का इस्तेमाल करने की अनुमति है. | नीलामी में लगने वाले समय के बारे में बातचीत के दौरान, हमने बताया था कि किसी खरीदार के सभी आईजी में एक ही स्क्रिप्ट का फिर से इस्तेमाल करने से, उस खरीदार की बिडिंग तेज़ी से चलेगी. इस बारे में ज़्यादा जानकारी यहां दी गई है. साथ ही, 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 से बाहर के सेलर के साथ PA API नीलामियां चालू कर सकते हैं. इस कंट्रोल के बारे में ज़्यादा जानकारी के लिए, हमारे सहायता केंद्र पर जाएं. |
| (पिछली तिमाहियों में भी रिपोर्ट की गई) टॉप-लेवल की नीलामियां |
Google के पब्लिशर विज्ञापन सर्वर का इस्तेमाल करने की सुविधा, जिसमें GAM को टॉप-लेवल PA API नीलामी का कंट्रोल न दिया गया हो. | Google Ad Manager का जवाब: Google की तीसरी तिमाही 2023 की रिपोर्ट में बताई गई वजहों से, PA API इंटिग्रेशन के लिए GAM के प्लान में, ऐसे पब्लिशर को शामिल नहीं किया गया है जो टॉप-लेवल नीलामी के कंट्रोल के बिना, GAM को अपने पब्लिशर विज्ञापन सर्वर के तौर पर इस्तेमाल करते हैं. |
| जानकारी का ऐक्सेस | GAM के पास, प्रतिस्पर्धियों से मिली अहम जानकारी का ऐक्सेस होता है. इसमें, संदर्भ के हिसाब से नीलामी की कीमतें, PA API नीलामी के लिए खरीदारों से एसएसपी को मिले सिग्नल, और एसएसपी से मिले कॉन्फ़िगरेशन पैरामीटर शामिल हैं. | Google Ad Manager का जवाब: हमने नीलामी में सभी के लिए समानता बनाए रखने पर कई सालों से ध्यान दिया है. साथ ही, हमने यह वादा किया है कि नीलामी में बिड करने से पहले, किसी भी पब्लिशर के ऐसे विज्ञापन स्रोतों की कीमत किसी दूसरे खरीदार के साथ शेयर नहीं की जाएगी जिनके लिए कोई गारंटी नहीं दी जाती. इनमें, गारंटी नहीं वाली लाइन आइटम की कीमतें भी शामिल हैं. हमने बाद में, फ़्रेंच कॉम्पिटीशन अथॉरिटी के साथ किए गए अपने वादे में भी इस बात की पुष्टि की है. PA API नीलामियों के लिए, हम अपना वादा निभाना चाहते हैं. इसलिए, हम मल्टी-सेलर नीलामियों में नीलामी पूरी होने से पहले, नीलामी में हिस्सा लेने वाले किसी भी व्यक्ति की बिड को किसी दूसरे व्यक्ति के साथ शेयर नहीं करेंगे. साफ़ तौर पर बता दें कि हम कॉन्टेक्स्ट के हिसाब से होने वाली नीलामी की कीमत, किसी भी कॉम्पोनेंट की नीलामी के साथ शेयर नहीं करेंगे. इसमें हमारी नीलामी भी शामिल है. इस बारे में इस अपडेट में बताया गया है. इसके अलावा, हम अपनी नीलामी के हिस्से के तौर पर, कॉम्पोनेंट की नीलामी के कॉन्फ़िगरेशन की जानकारी का इस्तेमाल नहीं करते. इसमें, खरीदारों से एसएसपी को मिले सिग्नल भी शामिल हैं. असल में, हम PA API में ऐसे बदलावों का स्वागत करेंगे जिनसे कॉम्पोनेंट सेलर, अपने कॉम्पोनेंट की नीलामी के कॉन्फ़िगरेशन को इस तरह से बता सकें कि टॉप लेवल सेलर को यह जानकारी न दिखे. |
| कॉम्पोनेंट की नीलामियां | टॉप-लेवल ऑक्शन के तौर पर, GAM यह कंट्रोल करेगा कि हर विज्ञापन अवसर के लिए कौनसे एसएसपी, कॉम्पोनेंट ऑक्शन चलाते हैं. | Google Ad Manager का जवाब: पब्लिशर विज्ञापन सर्वर के तौर पर, GAM ऐसे एसएसपी के लिए एक लाइटवाइट एपीआई उपलब्ध कराता है जिनके साथ कोई पब्लिशर काम कर सकता है. इससे, Google पब्लिशर टैग (GPT) एपीआई के ज़रिए, अपने कॉम्पोनेंट की नीलामी के कॉन्फ़िगरेशन तय किए जा सकते हैं. ज़्यादा जानकारी के लिए यहां जाएं. अगर कोई एसएसपी इस एपीआई के ज़रिए कॉम्पोनेंट नीलामी का कॉन्फ़िगरेशन उपलब्ध कराता है, तो उसे उस विज्ञापन अवसर के लिए कॉम्पोनेंट नीलामियों की सूची में शामिल किया जाएगा. GAM, शामिल की गई कॉम्पोनेंट नीलामियों पर कोई पाबंदी नहीं लगाता. अगर कोई एसएसपी कॉम्पोनेंट नीलामी चलाना चाहता है, तो वह ऐसा कर सकता है. हालांकि, इसके लिए ज़रूरी है कि पब्लिशर ने उसे अपने पेज पर ज़रूरी कोड लागू करने की अनुमति दी हो. |
| कॉम्पोनेंट की नीलामियां | GAM, हर कॉम्पोनेंट की नीलामी में जीतने वाली बिड पर, कोई खास और सार्वजनिक नहीं की गई फ़्लोर लागू कर सकता है. | Google Ad Manager का जवाब: GAM ने कई सालों से नीलामी में निष्पक्षता बनाए रखने पर ज़्यादा ध्यान दिया है. नीलामी को निष्पक्ष और पारदर्शी बनाए रखने के लिए, हम ऐसी फ़्लोर प्राइस का इस्तेमाल नहीं करते जो सिर्फ़ डिमांड के खास सेगमेंट पर लागू होती हैं. यह हमारे प्रॉडक्ट का एक बुनियादी सिद्धांत है. यह PA API की नीलामियों के लिए भी लागू होगा. |
| तीसरे पक्ष के विज्ञापन सर्वर | तीसरे पक्ष के विज्ञापन सर्वर के पास, उच्च-लेवल की नीलामी में Google की भागीदारी का ऐक्सेस नहीं होगा. इससे, PA API के संदर्भ में Google एसएसपी की मांग से फ़ायदा पाने की उनकी क्षमता सीमित हो जाएगी. | Google Ad Manager का जवाब: फ़िलहाल, GAM पर कई सेलर के साथ PA API की जांच करने की सुविधा उपलब्ध है. इसके लिए, यहां बताए गए एपीआई का इस्तेमाल किया जाता है. फ़िलहाल, अन्य टॉप-लेवल ऑक्शन में GAM को कॉम्पोनेंट ऑक्शन के तौर पर शामिल नहीं किया जा सकता. |
| (पिछली तिमाहियों में भी रिपोर्ट की गई) PA API नीलामियों की परफ़ॉर्मेंस |
टेस्टर की रिपोर्ट से पता चलता है कि PA API की नीलामियों में इंतज़ार का समय ज़्यादा है. | हमें पता है कि आपको इंतज़ार का समय लंबा लग रहा है. इसलिए, हमने PA API के तहत कई सुविधाएं बनाई हैं. इनकी मदद से, एसएसपी, डीएसपी के इंतज़ार के समय की सीमा तय कर सकते हैं. साथ ही, ऐसे सुधार कर सकते हैं जिनसे इंतज़ार का समय कम हो. हमने हाल ही में, देरी से जुड़े सबसे सही तरीकों की गाइड को अपडेट किया है. इसमें इन सुविधाओं का फ़ायदा पाने के तरीके के बारे में ज़्यादा जानकारी दी गई है. हम इंतज़ार के समय को कम करने के लिए नए तरीके भी लगातार डेवलप कर रहे हैं. इनमें से कुछ तरीकों के बारे में यहां बताया गया है. |
| (पिछली तिमाहियों में भी रिपोर्ट किया गया था) वीडियो रेंडरिंग |
PA API और फ़ेंस किए गए फ़्रेम का इस्तेमाल करके, वीडियो रेंडर करने की सुविधा. | हमने जनवरी में एक डेमो पब्लिश किया था, जिसमें बताया गया था कि पीए नीलामी में इनस्ट्रीम वीडियो कैसे काम कर सकता है. साथ ही, इसमें अन्य तरीकों के बारे में ज़्यादा जानकारी दी गई थी. हम यह भी देख रहे हैं कि नेटवर्क के प्लेयर, उन पार्टनर के लिए वीडियो रेंडरिंग के काम करने के तरीके का सुझाव दे रहे हैं जो उनके साथ इंटिग्रेट होते हैं. जैसे, वीडियो के साथ काम करने वाले रेंडर यूआरएल के निर्माण के लिए GAM के सुझाव या पूरी ई2ई प्रोसेस. इसके अलावा, हम नेटवर्क से जुड़े लोगों के सुझावों को सुन रहे हैं, ताकि हम इस सुविधा को अपनाने के लिए ज़रूरी बदलाव कर सकें. इस तरह के एक बदलाव के बारे में GitHub में बताया गया है. हम नेटवर्क के साथ लगातार जुड़े रहते हैं, ताकि इस सुविधा को अपनाने में आने वाली किसी भी रुकावट का पता चल सके और उसे समय पर ठीक किया जा सके. |
| (पिछली तिमाहियों में भी रिपोर्ट की गई थी) डेटा मैनेज करने की नीति |
आईजी / PA API के लिए, डेटा मैनेज करने की नीति क्या है? | PA API के डिज़ाइन में, आईजी में सेव किया गया सारा डेटा या यह जानकारी कि कौनसे लोग कौनसे आईजी में हैं, (i) डिवाइस पर सेव रहता है या (ii) भरोसेमंद एक्सीक्यूशन एनवायरमेंट (टीईई) में चल रही बिडिंग और नीलामी (बी एंड ए) सेवाओं में प्रोसेस किया जाता है. दोनों ही मामलों में, डेटा को कोई भी तीसरा पक्ष नहीं पढ़ सकता. साथ ही, नीलामी में बिड बनाने के अलावा, इसका इस्तेमाल किसी और काम के लिए नहीं किया जा सकता. Chrome पर निजता को बेहतर बनाने के लिए कुछ सुविधाएं जोड़ी जा रही हैं. इनमें, Google के चलाए जा रहे के-अनामिटी सर्वर के साथ इंटरैक्ट करना शामिल है. इस इंटरैक्शन को सावधानी से डिज़ाइन किया जा रहा है, ताकि उपयोगकर्ताओं की जानकारी शेयर न की जाए. साथ ही, इसे टीईई में चलाया जा सके, ताकि विज्ञापन नेटवर्क के पूरे नेटवर्क में जानकारी एक जैसी हो. Google ने सीएमए को यह वादा किया है कि वह Privacy Sandbox के प्रस्तावों को इस तरह से डिज़ाइन और लागू करेगा कि Google के कारोबार को प्राथमिकता देकर, प्रतिस्पर्धा को नुकसान न पहुंचे. साथ ही, डिजिटल विज्ञापन और पब्लिशर और विज्ञापन देने वालों पर पड़ने वाले असर का ध्यान रखा जाएगा. हम सीएमए के साथ मिलकर काम करते रहते हैं, ताकि यह पक्का किया जा सके कि हमारा काम इन जवाबदेही के मुताबिक हो. |
| (पिछली तिमाहियों में भी रिपोर्ट की गई) IG लाइफ़टाइम |
आईजी की समयसीमा को 30 से 90 दिनों तक बढ़ाने का अनुरोध करें. | इस तरह के बदलाव के लिए, सावधानी से आकलन करना ज़रूरी है. इसमें, Chrome के उपयोगकर्ताओं और अन्य हिस्सेदारों पर पड़ने वाले असर के मुकाबले, इंडस्ट्री को मिलने वाले फ़ायदों को तौलना होता है. हम इस अनुरोध पर विचार कर रहे हैं. अगर आपके पास कोई और सुझाव/राय/शिकायत है, तो यहां बताएं. |
| (पिछली तिमाहियों में भी रिपोर्ट किया गया था) modelingSignals |
modelingSignals के अलावा, नए फ़ील्ड का अनुरोध करें. इस फ़ील्ड में सिर्फ़ डिसप्ले और क्लिक की जानकारी कोड में बदली जा सकती है. | हमने इस सुझाव/राय/शिकायत का जवाब, यहां दिया है. हम इस इंडस्ट्री के साथ लगातार बातचीत कर रहे हैं, ताकि हम उनके सुझावों को समझ सकें. फ़िलहाल, हम इस बात का आकलन कर रहे हैं कि इस बदलाव से इंडस्ट्री को क्या फ़ायदे मिलेंगे और Chrome के उपयोगकर्ताओं और दूसरे हिस्सेदारों पर क्या असर पड़ेगा. |
| reportWin() में अतिरिक्त बिट | 3PCD से पहले, reportWin() में 12 की मौजूदा सीमा के बजाय ज़्यादा बिट दें. | फ़िलहाल, हम इस इस्तेमाल के उदाहरण के लिए, अलग-अलग तरीके आज़मा रहे हैं. इसमें थोड़ा समय लग रहा है, क्योंकि हम ऐसे तरीकों की भी तलाश कर रहे हैं जिनसे यह पक्का किया जा सके कि हमारे पास निजता से जुड़ा लंबे समय तक चलने वाला प्लान हो. |
| नीलामी का डिज़ाइन | एक ऐसी नीलामी के लिए अनुरोध जो रेंडर किए गए यूआरएल और उनके स्कोर के साथ नतीजे दिखाती है. | हमने एक ही PA नीलामी से कई रेंडर यूआरएल और उनके स्कोर शेयर करने पर विचार किया था. हालांकि, निजता से जुड़ी समस्याओं की वजह से, हमने ऐसा नहीं किया. हम समझते हैं कि किसी उपयोगकर्ता को एक ही पेज पर एक ही विज्ञापन कई बार दिखाने से बचना चाहिए. हम GitHub पर इस बारे में आगे की चर्चा के लिए तैयार हैं. |
| reportWin | reportWin() फ़ंक्शन में मनमुताबिक फ़ील्ड लॉग करें. | यह सुविधा, टेस्टिंग की पूरी अवधि के दौरान पहले से ही उपलब्ध है. Chrome के 3PC के लिए सहायता बंद करने के बाद, एपीआई के forDebuggingOnly वर्शन को माइग्रेट कर दिया जाएगा, ताकि डाउनसैंपल की गई डेबगिंग को चालू किया जा सके. इस बारे में यहां बताया गया है. |
| कॉम्पोनेंट बेचने वाले | अपने इंप्रेशन और दूसरे इवेंट की गिनती करने के लिए, उसके पास एक अलग तरीका हो. साथ ही, उसे सिर्फ़ विज्ञापन टेक्नोलॉजी की रिपोर्ट पर निर्भर नहीं रहना चाहिए. | इस सुविधा के लिए किए गए अनुरोध पर, हम आगे काम करेंगे. हमें नहीं लगता कि Chrome की मदद से टेस्टिंग के दौरान, इस समस्या को हल किया जा सकता है. |
| हर क्लिक की लागत (सीपीसी) वाली बिलिंग | PA API में हर क्लिक की लागत (सीपीसी) वाली बिलिंग लागू करें. | हम इस अनुरोध पर यहां विचार कर रहे हैं. फ़िलहाल, हम इसे मौजूदा एपीआई के साथ लागू करने के सुझावों के अनुरोध के तौर पर देख रहे हैं. |
| browserSignals | सेलर के लिए, रिपोर्टिंग ब्राउज़र सिग्नल की खास जानकारी में incomingBidInSellerCurrency जोड़ें. | हम इस अनुरोध पर विचार कर रहे हैं. अगर आपके पास कोई और सुझाव/राय/शिकायत है, तो यहां बताएं. |
| डीएसपी के अलावा अन्य प्लैटफ़ॉर्म के लिए, बाय-साइड मेटाडेटा और लॉजिक के मालिकाना हक से जुड़ी सहायता | एपीआई के मौजूदा डिज़ाइन की वजह से, प्रॉडक्ट-लेवल पर रीटारगेटिंग कैंपेन में काफ़ी बदलाव हो सकता है. ऐसे में, कैंपेन को उन प्लैटफ़ॉर्म पर माइग्रेट करना पड़ सकता है जो डीएसपी और डीसीओ, दोनों के तौर पर काम करते हैं. | हम इस समस्या पर चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव/राय है, तो यहां बताएं. |
| डीएसपी के अलावा अन्य प्लैटफ़ॉर्म के लिए, बाय-साइड मेटाडेटा और लॉजिक के मालिकाना हक से जुड़ी सहायता | ऐसे उदाहरण शेयर करें जिनमें डीएसपी, आईजी का मालिक न हो. | हम समझते हैं कि बिड न करने वाले लोग, आईजी की कुछ सुविधाओं का इस्तेमाल करना चाहेंगे, लेकिन कुछ का नहीं. हम इन इस्तेमाल के उदाहरणों को हल करने के लिए, लगातार विकल्पों का आकलन कर रहे हैं. साथ ही, यहां हमें अपने सुझाव, राय या शिकायत भेजने में खुशी होगी. |
| टाइम आउट कंट्रोल | पब्लिशर यह तय कर सकते हैं कि कितने आईजी इस इवेंट में हिस्सा ले सकते हैं. साथ ही, वे टॉप-लेवल टाइम आउट / ग्लोबल टाइम आउट भी तय कर सकते हैं. | हम समझते हैं कि आपको टॉप-लेवल और कॉम्पोनेंट सेलर के बीच टाइम आउट कंट्रोल और विज़िबिलिटी को बेहतर बनाने की ज़रूरत है. हम इस अनुरोध पर विचार कर रहे हैं. |
| एक से ज़्यादा विज्ञापन साइज़ | कई विज्ञापन साइज़ के इस्तेमाल के उदाहरणों के लिए, PA API की सहायता. | हम इस अनुरोध पर विचार कर रहे हैं. साथ ही, हम इस बारे में अपने प्लैटफ़ॉर्म के उपयोगकर्ताओं से सुझाव, राय या शिकायतें भी स्वीकार करते हैं. |
| दस्तावेज़ | क्या ऐसे IG एट्रिब्यूट की सूची है जिन पर k-anon लागू होता है? | हमने इस सवाल का जवाब यहां दिया है. |
| डीबग करना | PA API के लिए, डीबग करने की बेहतर सुविधाएं. | हम इस बात को समझते हैं कि PA API का इस्तेमाल करने वाले डेवलपर के लिए, डीबग करने वाले बेहतर टूल की ज़रूरत होती है. हम डेवलपर टूल के साथ .well-known फ़ाइल फ़ेच को बेहतर तरीके से इंटिग्रेट करने के तरीकों को एक्सप्लोर करके, डेवलपर के अनुभव को बेहतर बनाने के लिए प्रतिबद्ध हैं. हमारा लक्ष्य, डेवलपमेंट एनवायरमेंट में ज़्यादा जानकारी देना और समस्या हल करने की सुविधाएं उपलब्ध कराना है. हम इस समस्या के बारे में यहां ज़्यादा जानकारी दे रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव, राय या शिकायत है, तो हमें बताएं. |
| लेबल | क्या मोड B के ट्रैफ़िक से जुड़े लेबल में मौजूद सभी उपयोगकर्ताओं के लिए, Privacy Sandbox API चालू हैं? | Chrome एक्सपेरिमेंट ग्रुप असाइनमेंट, उपयोगकर्ता की कॉन्फ़िगर की गई Chrome सेटिंग से अलग और अपने-आप तय होते हैं. यह मुमकिन है कि ये एपीआई, खास ट्रीटमेंट ग्रुप (उदाहरण के लिए, treatment_1.*) में उपयोगकर्ताओं के लिए उपलब्ध हों. हालांकि, Chrome की सेटिंग में जाकर इनकी सुविधा में बदलाव किया जा सकता है या इन्हें बंद किया जा सकता है. मोड B control_2 ग्रुप: इस ग्रुप में शामिल होने से, Privacy Sandbox के काम के होने और मेज़रमेंट एपीआई की सुविधा अपने-आप बंद हो जाती है. साथ ही, उपयोगकर्ता Chrome की सेटिंग में जाकर इस सेटिंग को बदल नहीं सकता. |
| एपीआई प्रयोग | क्या reportWin() को कॉल करने और विज्ञापन को रेंडर करने की प्रोसेस एक साथ हो रही है या एक के बाद एक? | runAdAuction() पूरा होने के बाद, reportWin() को सीधे तौर पर कॉल किया जाता है. साथ ही, नीलामी के नतीजे को iframe या फ़ेंस किए गए फ़्रेम में डालने पर, विज्ञापन रेंडर करने की प्रोसेस शुरू हो सकती है. reportWin() फ़ंक्शन के पूरा होने और विज्ञापन के रेंडर होने के बाद, sendReportTo() फ़ंक्शन में दिए गए यूआरएल फ़ेच कर लिए जाएंगे. |
| (पिछली तिमाहियों में भी रिपोर्ट की गई थी) A/B टेस्टिंग की सहायता |
PA API की A/B टेस्टिंग के लिए सहायता का अनुरोध करें. | हम इस अनुरोध पर यहां चर्चा कर रहे हैं. अगर आपके पास कोई और सुझाव, राय या शिकायत है, तो हमें बताएं. |
| ट्रैफ़िक शेपिंग | Google का यह प्रस्ताव कि ज़रूरी फ़ैसले लेने के लिए, KV सर्वर का इस्तेमाल किया जाए, काम का नहीं है. इसकी वजह यह है कि सेलर अपने बैकएंड के साथ इंटरैक्ट नहीं कर पाते. इससे ट्रैफ़िक को शेप करना मुश्किल हो जाता है. | जैसा कि GitHub की समस्या में बताया गया है, किसी डीएसपी के पास आईजी मौजूद हैं या नहीं, यह बताने से उपयोगकर्ता की फ़िंगरप्रिंट से जुड़ी समस्याएं हो सकती हैं. हमने इस समस्या के लिए अन्य विकल्प सुझाए हैं. साथ ही, हम और सुझाव भी स्वीकार करने के लिए तैयार हैं. |
| ट्रैफ़िक शेपिंग | कैश मेमोरी से जुड़ी प्रोसेस, काम को ज़्यादा मुश्किल बना देती है. साथ ही, डीएसपी को उस ट्रैफ़िक के बारे में सही जानकारी नहीं मिल पाती जिस पर उन्हें बिडिंग करनी होती है. | कैश मेमोरी में सेव करने की सुविधा सिर्फ़ एक सुझाव के तौर पर दी गई थी. AdTech कंपनियां, अपने काम के सुझावों का इस्तेमाल कर सकती हैं. हम यहां इस बारे में ज़्यादा चर्चा करने के लिए तैयार हैं. |
| लेबल | Chrome को खरीदार और सेलर के भरोसेमंद सर्वर के अनुरोधों में, लेबल को पैरामीटर के तौर पर शेयर करना चाहिए. | यह अनुरोध सही है, क्योंकि यह ज़िम्मेदारी के साथ IG डेटा का इस्तेमाल करने के लक्ष्य के मुताबिक है. हालांकि, हम इस अनुरोध पर विचार कर रहे हैं. हालांकि, इसकी समीक्षा हमारी टीम करेगी. साथ ही, इस मामले पर आगे की बातचीत के दौरान, हम इस बारे में सार्वजनिक तौर पर अपडेट देंगे. |
| एपीआई प्रयोग | "टेस्टिंग के लिए तीसरे पक्षों को सीएमए से जुड़े अतिरिक्त दिशा-निर्देश" दस्तावेज़ में, "control_1" ग्रुप की साफ़ तौर पर परिभाषा दी गई है. खास तौर पर, इस बात की चिंता है कि शब्दों में बदलाव करने से, यह गलत तरीके से समझा जा सकता है कि control_1 से सभी Privacy Sandbox APIs को हटाना ज़रूरी है. | हमने इस बारे में इस GitHub थ्रेड में अपने विचार ज़ाहिर किए हैं. हालांकि, हम सीएमए के लिए बोलने की स्थिति में नहीं हैं. हमारा सुझाव है कि टेस्टिंग से जुड़े दिशा-निर्देशों के बारे में कोई भी समस्या सीधे सीएमए से पूछें. |
| एपीआई प्रयोग | क्या Chrome, किसी दूसरे रिसॉर्स पर रीडायरेक्ट करते समय, खाली पेज पर joinAdInterestGroup() को कॉल करने की अनुमति देगा? | अगर कोई उपयोगकर्ता किसी साइट पर जा रहा है, तो साइट का मालिक तीसरे पक्ष को joinAdInterestGroup को कॉल करने की अनुमति दे सकता है. इस तरीके से, तीसरे पक्ष को खाली पेज के ज़रिए किसी भी तरह का रीडायरेक्ट जोड़ने की ज़रूरत नहीं पड़ती. इससे, तीसरे पक्ष को आईजी बनाने में मदद मिलती है. हम तीसरे पक्ष को आईजी बनाने के लिए, रीडायरेक्ट के बीच में किसी दूसरे तरीके का इस्तेमाल करने की वजहों के बारे में सुझाव, शिकायत या राय देने के लिए हमेशा तैयार हैं. |
| एपीआई प्रयोग | एक्सचेंज, उन पब्लिशर के पेजों पर आईजी लिख सकते हैं जिनके साथ वे काम करते हैं. इसके बाद, वे किसी भी खरीदार या डीएसपी को उस आईजी पर बिड करने की अनुमति दे सकते हैं. | हमें आपका सुझाव मिल गया है. हम इस बात का आकलन कर रहे हैं कि इस तरह के अनुरोध को स्वीकार किया जा सकता है या नहीं. हमें इस बारे में और सुझाव, शिकायत या राय मिल सकती है. |
| एपीआई प्रयोग | अगर कोई भी PA API नीलामी नहीं जीतता है, तो डीबगिंग के दौरान होने वाली गड़बड़ी की कोई सूचना नहीं मिलती. | Chrome के reportWin और reportResult फ़ंक्शन, निजता नीलामी (पीए) सिस्टम में इवेंट-लेवल पर जीत की रिपोर्टिंग के लिए डिज़ाइन किए गए हैं. अगर पीए नीलामी के दौरान सभी बिड अस्वीकार कर दी जाती हैं, तो इन फ़ंक्शन को ट्रिगर नहीं किया जाना चाहिए, क्योंकि कोई भी विजेता तय नहीं होता. Chrome के हाल ही के अपडेट की वजह से, हो सकता है कि forDebuggingOnly.reportAdAuctionLoss() फ़ंक्शन में पास किए गए यूआरएल, DevTools के नेटवर्क पैनल में न दिखें. हमारा सुझाव है कि आप Chrome के Canary या डेव चैनल के बिल्ड का इस्तेमाल करके, इस सुविधा की पुष्टि करें. |
| एपीआई प्रयोग | क्या generateBid से मिली adCost की वैल्यू, नेगेटिव हो सकती है (यह पहले से ही स्टोकेस्टिक तरीके से दो बाइट तक राउंड की जाती है)? | AdCost, विज्ञापन देने वाले की क्लिक या कन्वर्ज़न लागत होती है. इसे generateBid() से reportWin() में पास किया जाता है. यह वैल्यू शून्य या डबल हो सकती है. नेगेटिव वैल्यू को अनदेखा कर दिया जाएगा और उन्हें पास नहीं किया जाएगा. वैल्यू पास होने पर, उसे स्टोकेस्टिक तरीके से राउंड किया जाएगा. |
| एपीआई में सुधार | क्या Chrome ब्राउज़र के बजाय, टारगेटिंग / कोहॉर्ट / एट्रिब्यूशन, और नीलामियों को मैनेज करने के लिए, भरोसेमंद और एन्क्रिप्ट किए गए एक्सीक्यूशन सर्वर का इस्तेमाल किया जा सकता है? | हमारा सुझाव है कि आप PA API में टीईई पर आधारित कॉम्पोनेंट और विकल्पों (जैसे, KV सर्वर और B&A सेवाएं) के साथ-साथ एट्रिब्यूशन रिपोर्टिंग और निजी एग्रीगेशन (जैसे, एग्रीगेशन सेवा) के टीईई पर आधारित कॉम्पोनेंट को एक्सप्लोर करें. इनसे इस सवाल का जवाब मिलता है. |
| एपीआई में सुधार | क्या प्राइवसी सैंडबॉक्स की नीलामी का जवाब, विज्ञापन टैग के बजाय बिड रिस्पॉन्स (जैसे, हेडर बिडिंग) हो सकता है? | इस तरह का बदलाव, PA API की निजता प्रॉपर्टी में बुनियादी बदलाव करता है. इसलिए, हम इस पर विचार नहीं कर रहे हैं. |
| पब्लिशर के कंट्रोल | क्या पब्लिशर अपने पेजों पर PA API क्रिएटिव को ब्लॉक कर सकते हैं? | Chrome में रीयल-टाइम क्रिएटिव स्कैनिंग का प्रस्ताव है. हालांकि, इसे अभी टेस्ट करने के लिए उपलब्ध नहीं कराया गया है. यह सुविधा फ़िलहाल उपलब्ध नहीं है. हालांकि, हमने देखा है कि ज़्यादातर एसएसपी ने इसे चालू करने के लिए समाधान तैयार किए हैं. |
| एपीआई प्रयोग | perBuyerSignals की साइज़ की सीमा क्या है? | अपने क्लासिक फ़ॉर्म में, perBuyerSignals में Chrome में साइज़ की कोई सीमा नहीं होती. मुख्य समस्याएं यह हैं कि डेटा, JSON-serializable के तौर पर बना रहे और ज़्यादा मेमोरी का इस्तेमाल न करे. हालांकि, ध्यान रखें कि perBuyerSignals के बहुत बड़े और जटिल होने पर, परफ़ॉर्मेंस पर बुरा असर पड़ सकता है. directFromSellerSignalsHeaderAdSlot के ज़रिए perBuyerSignals को पास करने के लिए, एक अन्य तरीका मौजूद है. इस तरीके से, हेडर में perBuyerSignals भेजे जाते हैं. हालांकि, पूरे हेडर रिस्पॉन्स का साइज़ 10 केबी से ज़्यादा नहीं होना चाहिए. इसके अलावा, अलग-अलग सर्वर, हेडर के ज़्यादा से ज़्यादा साइज़ पर अपनी पाबंदियां लगा सकते हैं. |
| दस्तावेज़ | generateBid में मौजूद, registerAdBeacon कॉल के दस्तावेज़ में बदलाव करना होगा. | हमने इस दस्तावेज़ को 17 फ़रवरी को अपडेट किया था. |
| एपीआई प्रयोग | रजिस्टर किए गए कई विकल्पों में से, reportEvent सही बीकन यूआरएल कैसे चुनता है? | हर नीलामी से एक अलग कॉन्फ़िगरेशन बनता है, जिससे एक अलग रिपोर्टिंग मैप बनता है. अलग-अलग नीलामियां (और उनसे मिलने वाले फ़्रेम) एक-दूसरे से पूरी तरह से अलग होती हैं और डेटा शेयर नहीं करती हैं. "फ़ेंस किए गए फ़्रेम विज्ञापनों की रिपोर्टिंग" के बारे में बताने वाली जानकारी में इस विषय के बारे में ज़्यादा जानकारी मिलती है. |
| Chrome का यूज़र इंटरफ़ेस (यूआई) | Chrome DevTools "ऐप्लिकेशन -> "पसंद के मुताबिक ग्रुप" टैब में फ़िल्टर जोड़ें. इससे, IG के मालिक (या शायद IG के नाम) के हिसाब से फ़िल्टर किया जा सकता है. | हम इस अनुरोध की समीक्षा कर रहे हैं. साथ ही, हम इस बारे में अपने सुझाव, राय या शिकायत भेजने के लिए, सभी को न्योता देते हैं. |
| बिना ग्राफ़िक यूज़र इंटरफ़ेस वाला Chrome | Headless Chrome में PA API की सहायता. | PA API के कुछ कॉम्पोनेंट, Chrome से जुड़े होते हैं. उदाहरण के लिए, Google के सर्वर पर k-anon कॉल, जो "पुराने" Headless Chrome में काम नहीं कर सकते. हमें लगता है कि Chrome 112 में रिलीज़ किए गए Headless Chrome के "नए" वर्शन से इस समस्या को हल किया जा सकता है. |
| एपीआई प्रयोग | reportAdAuctionLoss की मदद से, विज्ञापनों के न दिखने की रिपोर्टिंग के मामले में, हमें कई मामलों में "topLevelWinningBid=0" दिख रहा है. इसका क्या मतलब है? | topLevelWinningBid की वैल्यू, टॉप-लेवल सेलर कॉम्पोनेंट में scoreAd() फ़ंक्शन से मिलती है. यह वैल्यू, टॉप-लेवल नीलामी के नतीजे को तय करने में मदद करती है. एक्सप्लेनर के मुताबिक, topLevelWinningBid की वैल्यू शून्य या कोई भी ऋणात्मक संख्या होने का मतलब है कि उससे जुड़ा विज्ञापन, नीलामी जीतने की ज़रूरी शर्तें पूरी नहीं करता. उदाहरण के लिए, इस तरीके का इस्तेमाल करके, उन विज्ञापनों को फ़िल्टर किया जा सकता है जो दिलचस्पी के ग्रुप के हिसाब से टारगेट किए गए हैं, लेकिन संदर्भ के हिसाब से टारगेट किए गए उम्मीदवार से बेहतर नहीं हैं. शायद शून्य वैल्यू वाली topLevelWinningBid से यह पता चलता हो कि कॉन्टेक्स्ट के हिसाब से होने वाली नीलामी में आपका विज्ञापन जीत गया है. हालांकि, PA API स्पेसिफ़िकेशन में बताया गया है कि इस नतीजे में अन्य फ़ैक्टर भी शामिल हो सकते हैं. |
| मोड A/B टेस्टिंग | मोड B और मोड A के ट्रैफ़िक के विकल्प और ऑप्ट-आउट प्रॉम्प्ट के बारे में जानकारी. | मोड A और मोड B में शामिल होने की शर्तें एक जैसी हैं. हमारा मकसद ऐसे ग्रुप बनाना है जो सामान्य Chrome ट्रैफ़िक के बारे में बताते हों. हालांकि, इसके लिए ज़रूरी है कि वे Privacy Sandbox API और लेबल करने के तरीके के साथ काम करते हों. ऐसा इसलिए, क्योंकि कुछ क्लाइंट कॉन्फ़िगरेशन काम नहीं करते. प्रयोग के लिए, सिर्फ़ लेबल किए गए ट्रैफ़िक की तुलना दूसरे लेबल किए गए ट्रैफ़िक से करना ज़रूरी है. मोड B में उपयोगकर्ताओं के लिए ट्रैकिंग की सुरक्षा की सुविधा चालू होती है. इसलिए, उन्हें इस सुविधा के बारे में सूचना मिलती है. |
| एपीआई में सुधार | क्या "lifetimeMs" को joinAdInterestGroup कॉल में डायरेक्ट प्रॉपर्टी के तौर पर शामिल किया जा सकता है या इसे अलग आर्ग्युमेंट के तौर पर मैनेज किया जा सकता है? | हम PA API के प्रस्ताव में "joinAdInterestGroup" फ़ंक्शन के बारे में, वेब डेवलपमेंट कम्यूनिटी से मिले सुझावों पर ध्यान से विचार कर रहे हैं. चर्चा के दौरान, इंस्टाग्राम पर पोस्ट के लाइफ़साइकल को मैनेज करने के सबसे सही तरीके पर फ़ोकस किया गया. हम "lifetimeMs" पैरामीटर के लिए, अलग-अलग आर्ग्युमेंट के फ़ायदों का आकलन कर रहे हैं. ऐसा इसलिए, क्योंकि इससे आने वाले समय में स्पेसिफ़िकेशन को बेहतर बनाने के लिए, ज़्यादा आसानी से बदलाव किए जा सकते हैं. हम इस समस्या पर यहां चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव, राय या शिकायत है, तो हमें बताएं. |
| एपीआई प्रयोग | कम एन्ट्रॉपी वाले ब्राउज़र आईडी के साथ होने वाली गड़बड़ियों की वजह से, PA API फ़्रेमवर्क में गलत नेगेटिव रेट बढ़ने की संभावना. | Chrome की टीम, PA API फ़्रेमवर्क को बेहतर बनाने के लिए लगातार काम कर रही है. ब्राउज़र आईडी के आपस में मेल खाने की वजह से, गलत तरीके से नतीजे न मिलने की संभावित दरों के बारे में चर्चा करने के लिए आपका धन्यवाद. हम इस सुझाव की ध्यान से समीक्षा कर रहे हैं. साथ ही, हम यह पक्का करने की कोशिश करेंगे कि अपडेट किए गए विश्लेषण में सभी ज़रूरी बातों को शामिल किया गया हो. हमारा मकसद, ऐसा सलूशन उपलब्ध कराना है जो निजता से जुड़े कामों को सटीक और भरोसेमंद तरीके से पूरा करता हो. हम इस समस्या के बारे में यहां चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव/राय है, तो हमें बताएं. |
| एपीआई प्रयोग | क्या कम एन्ट्रापी वाला ब्राउज़र आइडेंटिफ़ायर ज़रूरी है, ताकि क्लाइंट, k-anonymity सिस्टम में एक ही ऑब्जेक्ट के लिए बार-बार "जॉइन" अनुरोध सबमिट न कर सकें? | हम क-निजता सिस्टम लागू करने के लिए, ब्राउज़र आइडेंटिफ़ायर के इस्तेमाल के बारे में चल रही चर्चा को स्वीकार करते हैं और इसकी सराहना करते हैं. हम समझते हैं कि ऐसे आइडेंटिफ़ायर से निजता पर पड़ने वाले संभावित असर को लेकर आपके मन में कई सवाल हैं. शुरुआत में, हमने गलत इस्तेमाल को रोकने के लिए, कम एन्ट्रॉपी वाले आइडेंटिफ़ायर का इस्तेमाल किया था. हालांकि, हम अन्य तकनीकों को भी आज़मा रहे हैं. जैसे, उपयोगकर्ता की पहचान ज़ाहिर न करने वाले काउंटिंग टोकन. इन तकनीकों से सिस्टम की सुरक्षा बनाए रखते हुए, उपयोगकर्ता की निजता को प्राथमिकता दी जा सकती है. हम ऐसे समाधान ढूंढने के लिए प्रतिबद्ध हैं जिनसे डेटा का इस्तेमाल ज़िम्मेदारी के साथ किया जा सके और निजता की सुरक्षा को मज़बूत किया जा सके. साथ ही, हम रिसर्च कम्यूनिटी के साथ लगातार बातचीत करने के लिए तैयार हैं. हम इस बारे में यहां चर्चा कर रहे हैं. साथ ही, हमें इस बारे में और सुझाव, शिकायत या राय भेजने में खुशी होगी. |
| एपीआई प्रयोग | क्या Accelerated Mobile Pages (एएमपी), PA API के साथ काम करता है. | फ़िलहाल, एएमपी में PA API का इस्तेमाल नहीं किया जा सकता. अगर एएमपी की मदद से, ज़्यादा से ज़्यादा लोगों तक पहुंचना आपकी प्राथमिकता है, तो हम एएमपी नेटवर्क से जुड़े लोगों के सुझाव, राय या शिकायतें सुनने के लिए तैयार हैं. |
| एपीआई में सुधार | क-अनामिटी जांच से टाइप हटाएं. | हम के-अनामिटी अनुरोध के स्ट्रक्चर को ऑप्टिमाइज़ करने के बारे में मिले सुझावों पर ध्यान से विचार कर रहे हैं. हम पैरामीटर को एक साथ जोड़ने और प्रोसेस को आसान बनाने के लिए, टाइप को एक साथ जोड़ने के सुझाव को समझते हैं. हमारा मकसद, निजता बनाए रखने के लिए बेहतर और आसान तरीके उपलब्ध कराना है. इसलिए, हम निजता से जुड़े समाधानों को बेहतर बनाने के लिए सभी विकल्पों का आकलन कर रहे हैं. हम इस समस्या पर यहां चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव, राय या शिकायत है, तो हमें बताएं. |
| Chrome का यूज़र इंटरफ़ेस (यूआई) | कम तकनीकी जानकारी वाले उपयोगकर्ताओं के लिए, उन आईजी को आसानी से देखने और मैनेज करने के लिए, एक सुविधा का अनुरोध किया गया है जिनका वे सदस्य हैं. इसमें, ऑप्ट आउट करने के लिए वेबसाइट-लेवल के संभावित कंट्रोल भी शामिल हैं. | हम इस बात को समझते हैं कि आईजी को समझने और मैनेज करने के लिए, उपयोगकर्ता के हिसाब से टूल उपलब्ध कराना कितना ज़रूरी है. हमने अलग-अलग तरीकों को ध्यान से आज़माया है. हमें पता चला है कि जिस वेबसाइट से आईजी को जोड़ा गया था उसके हिसाब से उनकी पहचान करने से, साफ़ तौर पर जानकारी देने और निजता की सुरक्षा के बीच बेहतर संतुलन मिलता है. फ़िलहाल, आईजी को दुनिया भर में मैनेज करने की सुविधा, Chrome की सेटिंग में उपलब्ध है. हम इस क्षेत्र में उपयोगकर्ता अनुभव को और बेहतर बनाने के लिए लगातार नए तरीके खोज रहे हैं. हम इस समस्या के बारे में यहां चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव/राय है, तो हमें बताएं. |
| एपीआई की सुरक्षा | क्या PA API, फ़ेंस किए गए फ़्रेम के संदर्भ में भी, क्रिएटिव विज्ञापन इंटरैक्शन की वजह से निजता के उल्लंघन की आशंका से सुरक्षित है? | हम इस बात से सहमत हैं कि बेहतर विज्ञापन इंटरैक्शन की मदद से, जानकारी लीक हो सकती है. हम फ़ेंस किए गए फ़्रेम, PA API, और संभावित हमले के वेक्टर के बीच के इंटरैक्शन की जांच कर रहे हैं. निजता से जुड़े जोखिमों को कम करना हमारी सबसे बड़ी प्राथमिकता है. साथ ही, हम ऐसे बेहतरीन समाधानों को डेवलप करने के लिए प्रतिबद्ध हैं जिनसे उपयोगकर्ता की सुरक्षा के साथ-साथ, नई सुविधाओं को भी बेहतर बनाया जा सके. हम इस समस्या के बारे में यहां चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव/राय है, तो हमें बताएं. |
| इंतज़ार का समय | क्या खरीदार बिडिंग लॉजिक के लिए, डिफ़ॉल्ट तौर पर 50 मिलीसेकंड का टाइम आउट सही है? | बिडिंग लॉजिक के लिए, स्पेसिफ़िकेशन और नेटवर्क अनुरोधों के समय के बीच संभावित अंतर को लेकर उठाई गई चिंताओं को हम स्वीकार करते हैं. हम स्पेसिफ़िकेशन की समीक्षा कर रहे हैं, ताकि यह पक्का किया जा सके कि वे सही हैं. साथ ही, हम परफ़ॉर्मेंस और संभवता को संतुलित करने के लिए, डिफ़ॉल्ट टाइम आउट की सबसे सही सेटिंग की जांच कर रहे हैं. हम इस समस्या पर यहां चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव, राय या शिकायत है, तो हमें बताएं. |
| दस्तावेज़ | स्पेसिफ़िकेशन में टाइमिंग की संभावित लीक, जहां कोई वेबसाइट यह अनुमान लगा सकती है कि कोई विज्ञापन, के-अनामिटी थ्रेशोल्ड को पूरा नहीं करता है. साथ ही, क्रॉस-साइट ट्रैकिंग के संभावित असर. | हम समय की जानकारी लीक होने की संभावित समस्या को समझते हैं. हमें पता चला है कि स्पेसिफ़िकेशन में अंतर है. हम इस बात को पक्का करने के लिए कदम उठा रहे हैं कि नीलामी से पहले, विज्ञापनों के लिए क-अनामिटी का स्टेटस तय कर लिया जाए, ताकि इस तरह की लीक को रोका जा सके. हम इन समस्याओं को गंभीरता से लेते हैं. साथ ही, इन बदलावों को दिखाने के लिए, स्पेसिफ़िकेशन को अपडेट करेंगे. हम इस समस्या पर यहां चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव, राय या शिकायत है, तो हमें बताएं. |
| एपीआई प्रयोग | PA API में एसएसपी ब्लॉकलिस्ट लागू करने के तरीके. | हम एसएसपी के हिसाब से विज्ञापन पाबंदियों को मैनेज करने के लिए, तरीकों की ज़रूरत को समझते हैं. हमारा सुझाव है कि आप ऐसे समाधानों को एक्सप्लोर करें जो डिवाइस पर होने वाले आकलन को प्राथमिकता देते हों. साथ ही, उपयोगकर्ता की निजता को सुरक्षित रखने के लिए, विज्ञापन के मौजूदा मेटाडेटा का फ़ायदा उठाते हों. हम PA API में सबसे सही तरीकों की पहचान करने के लिए, डेवलपर के साथ काम करने के लिए प्रतिबद्ध हैं. हम इस समस्या के बारे में यहां चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव/राय है, तो हमें बताएं. |
| एपीआई प्रयोग | क्या कोई व्यक्ति अपने ब्राउज़र को PA API का इस्तेमाल करने का दिखावा करने के लिए कह सकता है, ताकि साइटें इसका पता न लगा सकें? | हम मानते हैं कि PA API से ऑप्ट-आउट करने पर, वेबसाइटें इसका पता लगा सकती हैं. हम निजता को बेहतर बनाने और बिना पहचाने ऑप्ट-आउट करने के विकल्प देने के लिए, अतिरिक्त बिड और नेगेटिव टारगेटिंग जैसी सुविधाओं पर काम कर रहे हैं. साथ ही, फ़ेंस किए गए फ़्रेम रेंडर करने की सुविधा पर भी काम किया जा रहा है. हम इस समस्या के बारे में यहां चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव/राय है, तो हमें बताएं. |
| मोड A/B टेस्टिंग | डेटा सेंटर का ऐसा ट्रैफ़िक जो इलाज के तरीके 1.1 का दावा करता है. | Chrome की टीम ने GAM की टीम से पुष्टि की है कि इस ट्रैफ़िक को अब प्रयोग से बाहर रखा जा रहा है. हम इस समस्या के बारे में यहां चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव/राय है, तो हमें बताएं. |
| एपीआई प्रयोग | PA API में interestGroupBuyers को लागू करने की सुविधा की परफ़ॉर्मेंस और निष्पक्षता. | हम PA API नीलामियों में, "interestGroupBuyers" फ़ील्ड की परफ़ॉर्मेंस और निष्पक्षता के बारे में चल रही चर्चा को समझते हैं. हम यह जानते हैं कि बेहतर परफ़ॉर्मेंस, निजता, और बाज़ार में सभी के लिए समान अवसर देने के बीच समझौता करना पड़ता है. सेलर को खरीदारों के साथ कारोबारी संबंध मैनेज करने की ज़रूरत होती है. हालांकि, हम मैच करने की प्रोसेस को ऑप्टिमाइज़ करने के तरीकों पर काम कर रहे हैं. इनमें रीयल-टाइम डेटा और हाइब्रिड मॉडल के आधार पर, डाइनैमिक अडजस्टमेंट शामिल हो सकते हैं. हम ऐसे समाधान ढूंढने के लिए प्रतिबद्ध हैं जो उपयोगकर्ता की निजता को प्राथमिकता देते हैं और विज्ञापन नेटवर्क को बेहतर बनाने में मदद करते हैं. हम इस समस्या के बारे में यहां चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव/राय है, तो हमें बताएं. |
| Chrome का यूज़र इंटरफ़ेस (यूआई) | Chrome में IG इस्तेमाल करने पर, मेमोरी से जुड़ी समस्याएं और यूज़र इंटरफ़ेस (यूआई) की साफ़ तौर पर जानकारी. | हम जानते हैं कि DevTools में आईजी दिखाने को लेकर आपके मन में क्या-क्या सवाल हैं. मौजूदा व्यू में, पुरानी ट्रैकिंग के लिए सभी आईजी इवेंट दिखते हैं. हालांकि, हम स्टोर किए गए आईजी की मौजूदा स्थिति को साफ़ तौर पर दिखाने की अहमियत को समझते हैं. हम डेवलपर की अहम जानकारी को बेहतर बनाने के लिए, यूज़र इंटरफ़ेस (यूआई) में सुधार और उसे ऑप्टिमाइज़ करने के तरीकों को एक्सप्लोर करेंगे. मेमोरी मैनेजमेंट के लिए, IG को इस तरह से डिज़ाइन किया गया है कि मेमोरी लीक न हो. हालांकि, हम संसाधनों के इस्तेमाल को लगातार मॉनिटर और ऑप्टिमाइज़ करते रहते हैं. हम इस समस्या के बारे में यहां चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव/राय है, तो हमें बताएं. |
| दस्तावेज़ | ओरिजनल पोस्टर को "joinAdInterestGroup" फ़ंक्शन के "sizeGroup" फ़ील्ड में, नाम वाले विज्ञापन साइज़ का इस्तेमाल करने में गड़बड़ी आ रही है. वे यह जानना चाहते हैं कि क्या यह सही है. | हम "joinAdInterestGroup" फ़ंक्शन में विज्ञापन कॉन्फ़िगरेशन को आसान बनाने की अहमियत समझते हैं. हम इस समस्या को हल करने के लिए लगातार काम कर रहे हैं. साथ ही, आने वाले समय में होने वाले अपडेट में इस सुविधा को चालू करने की योजना बना रहे हैं. यह बदलाव, डेवलपर को विज्ञापन मैनेज करने के लिए आसान और असरदार टूल उपलब्ध कराने के हमारे वादे के मुताबिक है. हम इस समस्या के बारे में यहां चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव/राय है, तो हमें बताएं. |
| Chrome की मदद से टेस्टिंग का लेबल | sendReportTo में, मोड A बनाम B और सटीक लेबल के बारे में सीधे डेटा पाने का अनुरोध करें, ताकि हम एक्सपेरिमेंट को लगातार ट्रैक कर सकें. | हम इस अनुरोध पर यहां चर्चा कर रहे हैं. साथ ही, हम आपके सुझाव, राय या शिकायतों का स्वागत करते हैं |
| दस्तावेज़ | क्या पुष्टि करने के लिए, सेलर के भरोसेमंद सर्वर को किए गए अनुरोधों में सेलर का डोमेन नेम शामिल है? | हम स्वीकार करते हैं कि Protected Audience KV Server API के दस्तावेज़ में, होस्टनेम पैरामीटर को शुरू में शामिल नहीं किया गया था. हम डेवलपर को भरोसा दिलाना चाहते हैं कि सेलर के भरोसेमंद सर्वर को किए गए अनुरोधों में, सेलर का डोमेन नेम अपने-आप शामिल हो जाता है. विज्ञापन की पुष्टि करने की बेहतर प्रक्रियाओं के लिए, यह सुविधा ज़रूरी है. इस गलती को ठीक करने के लिए, हमने दस्तावेज़ को अपडेट कर दिया है. साथ ही, हम डेवलपर कम्यूनिटी के लिए साफ़ तौर पर जानकारी देने और पारदर्शिता बनाए रखने को प्राथमिकता देते रहेंगे. हम इस समस्या के बारे में यहां चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव/राय है, तो हमें बताएं. |
| एपीआई प्रयोग | रिपोर्टिंग के मकसद से, विज्ञापन इंप्रेशन ट्रैकिंग कॉल में IG का नाम शामिल करने के संभावित तरीके. | हम उपयोगकर्ता की निजता के बुनियादी सिद्धांत के साथ-साथ, रिपोर्टिंग के बेहतर तरीकों की ज़रूरत को पूरा करने के लिए प्रतिबद्ध हैं. विज्ञापन इंप्रेशन ट्रैकिंग में IG नामों को शामिल करने पर, उपयोगकर्ताओं की पहचान ज़ाहिर होने से रोकने के लिए, k-anonymity सुरक्षा का इस्तेमाल किया जाता है. हम निजता से जुड़ी इन पाबंदियों के तहत, रिपोर्टिंग के नए-नए समाधान ढूंढते रहेंगे. हम इस समस्या के बारे में यहां चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव/राय है, तो हमें बताएं. |
| एपीआई की सुविधा | खरीदार के भरोसेमंद सर्वर से क्लाइंट हिंट एचटीटीपी हेडर पाने का अनुरोध. | हम इस सुविधा के अनुरोध को यहां ट्रैक कर रहे हैं. |
| एपीआई प्रयोग | क्या डिलीगेशन फ़ाइल को "Access-Control-Allow-Origin" हेडर को लोड करने की ज़रूरत है, क्योंकि यह ब्राउज़र के लिए IG की सदस्यता के व्यवहार को तय करता है? | हम वेब की सुरक्षा के सबसे सही तरीकों का पालन करने के लिए प्रतिबद्ध हैं. डेलिगेशन फ़ाइलों के लिए "Access-Control-Allow-Origin" हेडर की ज़रूरत होती है. इससे सीओआरएस के सिद्धांतों का पालन होता है और संवेदनशील जानकारी को अनजाने में ज़ाहिर होने से रोका जा सकता है. हम इस प्रोसेस को ऑप्टिमाइज़ करने के तरीकों पर काम कर रहे हैं. साथ ही, हम सुरक्षा को बेहतर बनाए रखने की कोशिश कर रहे हैं. हम इस समस्या के बारे में यहां चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव/राय है, तो हमें बताएं. |
| एपीआई प्रयोग | PA API फ़्रेमवर्क में क्रिएटिव को उपयोगकर्ताओं के हिसाब से बनाने के लिए, विज्ञापन सर्वर को चालू करना. | हम इस बात से सहमत हैं कि क्रिएटिव को उपयोगकर्ताओं के हिसाब से बनाने में, विज्ञापन सर्वर की अहम भूमिका हो सकती है. हम PA API में विज्ञापन सर्वर को बेहतर बनाने के लिए, लगातार समाधान ढूंढ रहे हैं. जैसे, 'जॉइंट आईजी' मॉडल, जिसमें बिडिंग और विज्ञापन क्रिएटिव चुनने के लॉजिक को जोड़ा जा सकता है. हमारा लक्ष्य, विज्ञापन क्रिएटिव की बेहतर सुविधाओं को चालू करने और उपयोगकर्ता की निजता को सुरक्षित रखने के बीच संतुलन बनाना है. हम एपीआई को बेहतर बनाने के लिए, आपके सुझाव, राय या शिकायत का स्वागत करते हैं. इससे हमें सभी हिस्सेदारों की ज़रूरतों को पूरा करने में मदद मिलेगी. इसके लिए, यहां क्लिक करें. |
| गोपनीयता चिंताएँ | अन्य आइडेंटिफ़ायर की उपलब्धता (उदाहरण के लिए, RampID, ID5) का इस्तेमाल करने से, क्रॉस-साइट डेटा इकट्ठा करने में मदद मिलती है. इससे PA API के निजता लक्ष्यों को कम किया जा सकता है. | हम क्रॉस-साइट आइडेंटिफ़ायर और PA API के निजता लक्ष्यों के बीच संभावित तनाव को समझते हैं. पब्लिशर ऐसे आइडेंटिफ़ायर शेयर कर सकते हैं. हालांकि, PA API के डिज़ाइन का मकसद, विज्ञापन चुनने की प्रोसेस को अलग-अलग साइटों पर ट्रैकिंग की ज़रूरत से अलग करना है. हम निजता को ध्यान में रखकर विज्ञापन दिखाने वाले नेटवर्क को बेहतर बनाने के लिए प्रतिबद्ध हैं. साथ ही, हम डेवलपर को PA API के तरीके को प्राथमिकता देने का सुझाव देते हैं. हम इस समस्या के बारे में यहां चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव/राय है, तो हमें बताएं. |
| कैश मेमोरी में सेव करना | क्या कई नीलामियों में बिडिंग स्क्रिप्ट का दोबारा इस्तेमाल होने से रोकने का कोई तरीका है? | हम PA API फ़्रेमवर्क में, बिडिंग स्क्रिप्ट के कैश मेमोरी में सेव होने के व्यवहार को स्वीकार करते हैं. स्टैंडर्ड एचटीटीपी कैश मेकेनिज्म काम करते हैं. हालांकि, डिवाइस के निलंबित होने के व्यवहार और बिडिंग एक्सेक्यूटर के डिज़ाइन की वजह से, सभी नीलामियों में स्क्रिप्ट का फिर से इस्तेमाल किया जा सकता है. हमारी टीम, बिडिंग की रणनीतियों को असरदार तरीके से मैनेज करने के लिए, खरीदारों को स्क्रिप्ट कैश मेमोरी पर ज़्यादा कंट्रोल देने के समाधानों की जांच कर रही है. हम इस समस्या के बारे में यहां चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव/राय है, तो हमें बताएं. |
| एपीआई प्रयोग | उपयोगकर्ता की निजता का सम्मान करते हुए, डीएसपी के लिए सभी आईजी में बिडिंग गतिविधि की रिपोर्टिंग को एक जगह से मैनेज करना. | PA API को डिज़ाइन करते समय, हम उपयोगकर्ता की निजता को प्राथमिकता देते हैं. अलग-अलग बिडिंग इवेंट की सीधे तौर पर रिपोर्टिंग नहीं की जा सकती, क्योंकि अलग-अलग साइटों पर ट्रैकिंग से जुड़े जोखिम होते हैं. हालांकि, हम शेयर किए गए स्टोरेज और निजी एग्रीगेशन जैसे तरीके उपलब्ध कराते हैं. इनकी मदद से डीएसपी, बिडिंग गतिविधि के बारे में इकट्ठा की गई अहम जानकारी पा सकते हैं. ऐसा उपयोगकर्ता की निजता को बनाए रखते हुए किया जाता है. |
| एपीआई प्रयोग | reportResult() में sendReportTo() से फ़ेच करने की प्रोसेस, forDebuggingOnly.reportAdAuctionWin() के साथ रजिस्टर किए गए फ़ेच की तुलना में सिर्फ़ 94% समय होती है. | ऐसा हो सकता है कि दोनों यूआरएल एक ही समय पर फ़ेच न हों, लेकिन दोनों को एक ही समय पर फ़ेच किया जा सकता है. कुछ मामलों में, कॉम्पोनेंट सेलर के वर्कलेट को हटा दिया गया था और reportResult() फ़ंक्शन को चलाने के लिए, उसे फिर से लोड करना पड़ा. हालांकि, स्कोरिंग लॉजिक को फ़ेच करने में लगने वाला समय या वर्कलेट को रीलोड करने में लगने वाला समय, reportResult() के लिए 50 मिलीसेकंड के टाइम आउट पर असर नहीं डालता. कृपया ध्यान दें कि Chrome, फ़ेच करने के व्यवहार को तय करने के लिए, कैश मेमोरी में सेव किए गए हेडर का इस्तेमाल करेगा. ऐसा तब होगा, जब वर्कलेट को रीलोड करना ज़रूरी हो. पीए नीलामी के चरणों के बारे में ज़्यादा जानने के लिए, यहां जाएं. |
| K-anonymity | इस बात की पुष्टि करने का अनुरोध करें कि interestGroup के नाम से, विज्ञापन दिखाने के लिए k-anonymity पर कोई असर नहीं पड़ता. | किसी क्रिएटिव को k-anonymous माना जा सकता है. इसके लिए, आईजी के मालिक के यूआरएल, बिडिंग स्क्रिप्ट के यूआरएल, क्रिएटिव के यूआरएल, और विज्ञापन के साइज़ के टुपल को पिछली समयावधि (w) के दौरान तय किए गए थ्रेशोल्ड (k) को पूरा करना होगा. k-anonymity का स्टेटस समय-समय पर अपडेट किया जाता है (p). |
| Chrome का यूज़र इंटरफ़ेस (यूआई) | "इंटरनल विज़िबिलिटी" का ऐसा टाइप उपलब्ध कराने का प्रस्ताव जो कई MVC, ORM वगैरह फ़्रेमवर्क उपलब्ध कराते हैं. उदाहरण के लिए, Dev Tools --> ऐप्लिकेशन --> ऐप्लिकेशन सेक्शन में, चुने गए इंटरनल इवेंट को नए पैनल में आसानी से लॉग करना शुरू करें | हम इस प्रस्ताव पर यहां चर्चा कर रहे हैं. साथ ही, हम आपके सुझावों, राय या शिकायतों का स्वागत करते हैं. |
| Chrome का यूज़र इंटरफ़ेस (यूआई) | Dev Tools IG joining, प्राथमिकता से जुड़े एलिमेंट नहीं दिखाता. | हमने इस समस्या को यहां ठीक कर दिया है. |
| एपीआई में सुधार | क्रिएटिव विज्ञापन सर्वर को अपने इवेंट ट्रैक करने की अनुमति देना बेहतर होगा. क्या अनुमति वाले ट्रैकिंग डोमेन की सूची को कॉन्फ़िगर किया जा सकता है? | हमने यहां एक प्रस्ताव शेयर किया है. साथ ही, हम इस बारे में अपने सुझाव, राय या शिकायतें भेजने के लिए, सभी को न्योता देते हैं. |
| एपीआई की सुविधा का अनुरोध | क्या PA API को नॉन-आरटीबी मीडिया लेन-देन के साथ काम करने के लिए बढ़ाया जा सकता है और विज्ञापन दिखाने और डीसीओ जैसे अहम इस्तेमाल के उदाहरणों को बनाए रखा जा सकता है? | हम इस समस्या के बारे में यहां चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव, राय या शिकायत है, तो हमें बताएं. |
| पब्लिशर की नीलामी का टाइम आउट | पब्लिशर को नीलामी की अवधि पर कंट्रोल की ज़रूरत होती है, ताकि वे इंप्रेशन को न खोएं. खास तौर पर, हेडर बिडिंग सेटअप में, जहां विज्ञापनों को क्रम से चुना जाता है. | हम इस बात से सहमत हैं कि पब्लिशर को विज्ञापन नीलामी के टाइम आउट पर बेहतर कंट्रोल देना ज़रूरी है. हम "auctionConfig" ऑब्जेक्ट में, ग्लोबल ऑक्शन टाइम आउट की सुविधा को लागू करने के तरीके पर काम कर रहे हैं. साथ ही, हम इस बात का भी ध्यान रख रहे हैं कि यह सुविधा, अलग-अलग तरह के मामले में सही तरीके से काम करे. इस सुविधा का मकसद, पब्लिशर के लिए इंप्रेशन फ़िल-रेट को ऑप्टिमाइज़ करना है. साथ ही, हम सबसे अच्छा समाधान ढूंढने के लिए, कम्यूनिटी के साथ मिलकर काम करते रहेंगे. हम इस समस्या के बारे में यहां चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव, राय या शिकायत है, तो हमें बताएं. |
| एपीआई में सुधार | PA API में IGs के मौजूदा डिज़ाइन की वजह से, लंबे renderURLs की वजह से मेटाडेटा का साइज़ बड़ा हो जाता है. टेस्टर, बेहतर परफ़ॉर्मेंस के लिए इन यूआरएल को कंप्रेस करना चाहेंगे. | हम IG मेटाडेटा के साइज़ को ऑप्टिमाइज़ करने की अहमियत समझते हैं. खास तौर पर, परफ़ॉर्मेंस पर असर डालने वाली विज्ञापन नीलामियों के लिए. हमें लगता है कि टेंप्लेट पर आधारित, रेंडर यूआरएल को कंप्रेस करने का तरीका काफ़ी असरदार है. हम सुझाए गए टेंप्लेट डिज़ाइन की ध्यान से समीक्षा करेंगे. साथ ही, यह पक्का करेंगे कि लागू किए गए किसी भी समाधान में, ब्राउज़र को स्थिर रखने के लिए, गलत इस्तेमाल को रोकने के मज़बूत तरीके शामिल हों. इन बातों को ध्यान में रखते हुए, सबसे सही तरीका बनाने के लिए वेब स्टैंडर्ड कम्यूनिटी के साथ मिलकर काम करना हमारी प्राथमिकता है. हम इस समस्या के बारे में यहां चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव, राय या शिकायत है, तो हमें बताएं. |
| एपीआई प्रयोग | नेटिव विज्ञापन फ़ॉर्मैट को टेस्ट करने वाले लोग, एक ही कॉल में कई विज्ञापन नतीजे हासिल करके, Privacy Sandbox की नीलामी की प्रोसेस को ऑप्टिमाइज़ करना चाहते हैं. इससे नेटवर्क लोड कम होगा और विज्ञापन रेंडर करने की स्पीड बेहतर होगी. | हम Privacy Sandbox में नेटिव विज्ञापन रेंडरिंग के लिए, परफ़ॉर्मेंस से जुड़ी समस्याओं को समझते हैं. हम उपयोगकर्ताओं की निजता की सुरक्षा और बेहतर सुविधाओं के बीच संतुलन बनाने की कोशिश करते हैं. पूरे स्कोर वाले कई विज्ञापन दिखाने से निजता का खतरा होता है. इसलिए, हम नीलामी की प्रोसेस को ऑप्टिमाइज़ करने के तरीकों पर काम कर रहे हैं. हम नेटिव विज्ञापन फ़ॉर्मैट के लिए, PA API की सहायता को बेहतर बनाने के लिए काम कर रहे हैं. साथ ही, प्राइवसी सैंडबॉक्स की निजता से जुड़ी सख्त पाबंदियों के तहत, परफ़ॉर्मेंस को बेहतर बनाने के लिए अन्य तरीकों की जांच कर रहे हैं. हम इस समस्या के बारे में यहां चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव, राय या शिकायत है, तो हमें बताएं. |
| एपीआई प्रयोग | प्राइवसी सैंडबॉक्स में, विज्ञापन बिड को स्कोर करने और क्रम से लगाने के तरीके में बदलाव करने की सुविधा. खास तौर पर, प्राथमिकता के लेवल या निजी मार्केटप्लेस के नियमों को दिखाने के लिए. | हम समझते हैं कि Privacy Sandbox में विज्ञापनों को स्कोर करने और उन्हें क्रम से लगाने की सुविधा को बेहतर तरीके से कंट्रोल करने की ज़रूरत है. खास तौर पर, बिडिंग के जटिल मामलों में. हम ट्यूपल और गणितीय फ़ंक्शन का इस्तेमाल करके, उपयोगकर्ता की निजता को बनाए रखते हुए, अलग-अलग डाइमेंशन में स्कोरिंग करने के लिए सुझाए गए समाधानों को स्वीकार करते हैं. इन तरीकों से डेवलपर के लिए काम ज़्यादा मुश्किल हो सकता है, लेकिन इनसे ज़रूरी जानकारी मिलती है. हम इन प्रोसेस को आसान बनाने के तरीकों को ढूंढने के लिए प्रतिबद्ध हैं. इसके लिए, हम हेल्पर फ़ंक्शन या दिशा-निर्देशों का इस्तेमाल कर सकते हैं. इससे, बेहतर नीलामी लॉजिक के लिए Privacy Sandbox की सुविधाओं का बेहतर तरीके से इस्तेमाल किया जा सकेगा. हम इस समस्या के बारे में यहां चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव/राय है, तो हमें बताएं. |
| reportEvent() | विज्ञापन क्रिएटिव वाला फ़्रेम शुरू होने के बाद, ब्राउज़र से ट्रिगर होने वाला नया रिज़र्व इवेंट (शायद ऑटोमैटिक बीकन) जोड़ें. | हम इस अनुरोध पर यहां चर्चा कर रहे हैं. अगर आपके पास कोई और सुझाव, राय या शिकायत है, तो हमें बताएं. |
| adCost | adCost का ब्रेकडाउन दिखाने की अनुमति देना. | हर लागत वैल्यू, नीलामी से सीमित जानकारी भेजने का मौका है. उन लागतों की पूरी सूची की अनुमति देने से, पूरा उपयोगकर्ता आइडेंटिफ़ायर भेजने के लिए काफ़ी होगा. इससे अलग-अलग साइटों पर ट्रैकिंग की सुविधा चालू हो जाएगी. हम इस बारे में यहां चर्चा कर रहे हैं. अगर आपके पास कोई और सुझाव है, तो हमें बताएं. |
| resolveToConfig | क्या resolveToConfig को टॉप लेवल से इनहेरिट किया जाना चाहिए और browserSignals में दिखाया जाना चाहिए? | हम इस अनुरोध पर यहां चर्चा कर रहे हैं. अगर आपके पास कोई और सुझाव या राय है, तो हमें बताएं. |
| बेहतर टूल | क्या PA API के लिए, chrome://topics-internals जैसा कुछ है? | इसमें कोई भी चीज़ बिलकुल एक जैसी नहीं है. हालांकि, PA API के लिए डेवलपर टूल की सुविधाएं उपलब्ध हैं. |
| लेबल | क्या Chrome, 20% के-अनॉन उपयोगकर्ताओं की पहचान करने के लिए लेबल का इस्तेमाल कर सकता है? | हम इस अनुरोध पर विचार कर रहे हैं. साथ ही, हम इस बारे में अपने प्लैटफ़ॉर्म के उपयोगकर्ताओं से सुझाव, राय या शिकायतें भी स्वीकार करते हैं. |
| दस्तावेज़ | क्या प्राइवसी सैंडबॉक्स की नीलामी वाले वर्कलेट, स्टैंडर्ड वर्कलेट टाइप बन जाएंगे? | निजता और सुरक्षा से जुड़ी खास ज़रूरतों की वजह से, ये वर्कलेट, ब्राउज़र के स्टैंडर्ड वर्कलेट टाइप से काफ़ी अलग होते हैं. इसलिए, हमें नहीं लगता कि ये जल्द ही एचटीएमएल स्पेसिफ़िकेशन में स्टैंडर्ड वर्कलेट टाइप बन जाएंगे. हम ऑक्शन वर्कलेट को लागू करने और उन्हें चलाने के माहौल के बारे में साफ़ तौर पर बताकर, डेवलपर संसाधनों को बेहतर बनाने के लिए प्रतिबद्ध हैं. इससे, निजता सैंडबॉक्स में हिस्सा लेने वाले लोगों के लिए यह जानकारी ज़्यादा आसानी से उपलब्ध हो पाएगी. हमने इस बारे में ज़्यादा जानकारी यहां दी है. |
| 'खुद का सर्वर लाएं' (BYOS) कुंजी-वैल्यू (KV) सर्वर | पार्टियां, BYOS KV सेवा सेटअप में, KV सेवा क्वेरी की मदद से, एक ही मालिक के कई आईजी के बारे में जान सकती हैं. | टीईई में चलने वाले केवी सर्वर के लिए, ऐसा करना अब मुमकिन नहीं होगा. साथ ही, हम यह पक्का कर सकते हैं कि वे पब्लिश किए गए ट्रस्ट मॉडल का पालन कर सकते हैं. |
| userBiddingSignals | "userBiddingSignals" के कुछ हिस्से को अपडेट करें, जबकि अन्य हिस्सों को बनाए रखें. | एपीआई में कोई बदलाव किए बिना भी, ऐसा पहले से ही किया जा सकता है. |
| एपीआई प्रयोग | प्राइवसी सैंडबॉक्स में कई आईजी पर फ़्रीक्वेंसी कैपिंग लागू करें. इसके लिए, KV सर्वर या बदले गए "prevWinsMs" डेटा का इस्तेमाल किया जा सकता है. | हम इस बात से सहमत हैं कि Privacy Sandbox में, फ़्रीक्वेंसी कैपिंग की बेहतर सुविधाएं चाहिए. हम समझते हैं कि सभी आईजी के बीच डेटा शेयर करने पर लगी मौजूदा पाबंदियों की वजह से, इन रणनीतियों को लागू करने में समस्याएं आ सकती हैं. KV सर्वर, निजता की सुरक्षा के लिए सही तरीके से काम करने वाला एक संभावित तरीका उपलब्ध कराता है. हालांकि, हम डेवलपर को एक ही आईजी मॉडल में समाधान ढूंढने का सुझाव देते हैं. हम इस समस्या के बारे में यहां चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव/राय है, तो हमें बताएं. |
| एपीआई प्रयोग | कॉम्पोनेंट सेलर (वे लोग जो प्राइवसी सैंडबॉक्स में नेस्ट की गई नीलामियों में हिस्सा लेते हैं) को अपने कॉन्फ़िगरेशन को ऑप्टिमाइज़ करने और ग़ैर-ज़रूरी देरी से बचने के लिए, टॉप-लेवल नीलामी के टाइम आउट की जानकारी दिखनी चाहिए. | हम समझते हैं कि Privacy Sandbox में, टॉप-लेवल सेलर और कॉम्पोनेंट सेलर के बीच टाइम आउट को बेहतर तरीके से मैनेज करने की ज़रूरत है. हम टाइम आउट के नए तरीके जोड़ने की जांच कर रहे हैं. इनमें पूरी नीलामी के लिए संभावित टाइम आउट शामिल है. साथ ही, हम कॉम्पोनेंट नीलामियों में टॉप-लेवल टाइम आउट लागू करने के तरीकों को एक्सप्लोर कर रहे हैं. हमारा लक्ष्य, प्राइवेसी सैंडबॉक्स की नीलामी की प्रोसेस में हिस्सा लेने वाले सभी लोगों के लिए, नीलामी को ज़्यादा असरदार और अनुमानित बनाना है. हम इस समस्या के बारे में यहां चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव/राय है, तो हमें बताएं. |
Protected Audience API की सेवाएं
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) | क्या ऑन-प्राइमिस विज्ञापन टेक्नोलॉजी डेटा सेंटर के मुकाबले, सार्वजनिक क्लाउड में टीईई चलाने की लागत ज़्यादा है? | हमारा जवाब पिछली तिमाहियों से मिलता-जुलता है: हमारे मौजूदा टीईई सुरक्षा मॉडल को, सार्वजनिक क्लाउड लागू करने के तरीकों से फ़ायदा मिलता है. खास तौर पर, मौजूदा हार्डवेयर-आधारित टीईई, सभी तरह के फ़िज़िकल अटैक से सुरक्षित नहीं रखते. हमारे मौजूदा सार्वजनिक क्लाउड सेवा देने वाली कंपनियों, AWS और Google Cloud ने फ़िज़िकल ऐक्सेस से जुड़े जोखिमों को कम करने के लिए, डिज़ाइन और लागू किया है. इनमें कर्मचारियों से जुड़े जोखिम भी शामिल हैं. ऑन-प्राइमिस सहायता के बारे में यहां दी गई जानकारी देखें. विज्ञापन टेक्नोलॉजी से जुड़े लोगों ने हमें बताया है कि क्लाउड सेवाएं चलाना, ऑन-प्राइमिस विज्ञापन टेक्नोलॉजी डेटा सेंटर से ज़्यादा महंगा है. हम उन स्टेटमेंट का आकलन नहीं कर सकते. हालांकि, हम लागत के बारे में और सुझाव या राय देने के लिए तैयार हैं. साथ ही, हम टीईई के लिए सहायता को बढ़ाने के विकल्पों का आकलन करते रहेंगे. |
| TEEs | सार्वजनिक क्लाउड के अलावा अन्य एनवायरमेंट में टीईई के लिए सहायता | हमारा जवाब पिछली तिमाहियों के जवाब से मिलता-जुलता है: हम पब्लिक क्लाउड-आधारित समाधानों के अलावा अन्य विकल्पों के लिए सहायता का पता लगा रहे हैं. हालांकि, फ़िलहाल हमारे पास ऑन-प्राइमिस टीईई के लिए सहायता देने का कोई प्लान नहीं है. इस समय, Privacy Sandbox की सुरक्षा से जुड़ी ज़रूरी शर्तों और ऑन-प्राइम्स डिप्लॉयमेंट से जुड़ी चुनौतियों को देखते हुए, हमारा मानना है कि क्लाउड-आधारित डिप्लॉयमेंट को बेहतर बनाना और उनका दायरा बढ़ाना, नेटवर्क के लिए सबसे ज़्यादा फ़ायदेमंद है. उदाहरण के लिए, AWS के साथ-साथ Google Cloud के साथ काम करना. हालांकि, हम इस बारे में और सुझाव, राय या टिप्पणियां पाने के लिए तैयार हैं कि निजता और सुरक्षा से जुड़ी पाबंदियों को देखते हुए, यह ज़रूरी और मुमकिन क्यों है. |
| क्लाउड की सेवा देने वाली अन्य कंपनियां | क्लाउड सेवा देने वाली अन्य कंपनियों के लिए सहायता | हम क्लाउड सेवा देने वाली अन्य कंपनियों के सुझावों को हमेशा स्वीकार करते हैं. हालांकि, 3PCD लागू होने पर, हम कम से कम Google Cloud और AWS के साथ काम करने की योजना बना रहे हैं. ज़्यादा जानकारी के लिए, यह एक्सप्लेनर देखें. |
| B&A Services API | B&A Services API के लिए Google का क्या निर्देश है? क्या डिवाइस नीलामियों में, इसे Chrome ब्राउज़र की सुरक्षित ऑडियंस से ऊपर या नीचे प्राथमिकता दी जाएगी? | हमारी जवाब पिछली तिमाहियों की तरह ही है: हम Protected Audience के मौजूदा डिवाइस पर बिडिंग के डिज़ाइन के लिए प्रतिबद्ध हैं. बीए सेवाओं का सुझाव, इस्तेमाल के उन उदाहरणों के सबसेट के लिए संभावित समाधानों को एक्सप्लोर करने के लिए दिया गया है जहां डिवाइस की कंप्यूटिंग पावर या नेटवर्क की स्पीड सीमित हो सकती है. |
| स्टैंडर्डाइज़ेशन | B&A सेवाओं को स्टैंडर्ड बनाने की प्रक्रिया पूरी नहीं हुई है. | B&A Services का प्रस्ताव, स्टैंडर्ड बनाने की प्रोसेस के एक चरण में है. हम इस लक्ष्य को पूरा करने के लिए, ज़्यादा से ज़्यादा लोगों की दिलचस्पी का स्वागत करते हैं. इसकी शुरुआत, पिछले प्रस्तावों के आधार पर एक प्रस्ताव से हुई थी. इसे W3C में सार्वजनिक तौर पर, बड़े पैमाने पर खुली चर्चा के ज़रिए इनक्यूबेट किया जा रहा है. इसमें दिलचस्पी रखने वाले डेवलपर, इस पर प्रयोग कर सकते हैं और सुझाव/राय दे सकते हैं. वेब की सुविधाओं को डेवलप करने का यह सामान्य तरीका है. उदाहरण के लिए, इस बारे में यहां दी गई हमारी ब्लॉग पोस्ट में बताया गया है. |
| KV सर्वर | कॉन्टेंट / संदर्भ / साइट टारगेटिंग के लिए, खरीदार के केवी सर्वर को पूरा यूआरएल दिखाएं. | हम इस अनुरोध पर यहां चर्चा कर रहे हैं. साथ ही, हम इस बारे में अन्य सुझाव, राय या शिकायतें भी स्वीकार करते हैं. |
| दस्तावेज़ | GitHub पर "भरोसेमंद/लागू किए गए कॉम्पोनेंट बनाम वैकल्पिक" के दस्तावेज़ से, कुछ विज्ञापन टेक्नोलॉजी विशेषज्ञों को भ्रम होता है. इनके पास डिप्लॉयमेंट इमेज और इन्फ़्रास्ट्रक्चर का अपना सेट होता है. | हम "भरोसेमंद/लागू किए गए कॉम्पोनेंट बनाम वैकल्पिक कॉम्पोनेंट" के लिए दस्तावेज़ को बेहतर बनाना चाहते हैं. साथ ही, हमें यह जानना है कि क्या इस तरह के काम को प्राथमिकता दी जानी चाहिए. |
| एपीआई में सुधार | किसी KV सर्वर कॉल का एचटीटीपी स्टेटस कोड, scoreAd() फ़ंक्शन के लिए पैरामीटर के तौर पर भी उपलब्ध होना चाहिए. | हम इस अनुरोध की समीक्षा कर रहे हैं. साथ ही, हम इस बारे में अपने सुझाव, राय या शिकायत भेजने के लिए, सभी को न्योता देते हैं. |
| दस्तावेज़ | इस बारे में ज़्यादा जानकारी दें कि यूडीएफ़ के लागू होने पर, JS और WASM वर्कलोड को कैसे मैनेज किया जाएगा. | हम इस जानकारी को उपलब्ध कराने की कोशिश कर रहे हैं. अगर आपका कोई और सुझाव, राय या शिकायत है, तो यहां बताएं. |
| दस्तावेज़ | रिपॉज़िटरी का नाम अपडेट करने का अनुरोध. | हमने इस रिपॉज़िटरी का नाम बदलकर "protected-auction-key-value-service" कर दिया है. यह नाम, इस रिपॉज़िटरी से जुड़ी सेवाओं के कलेक्शन के लिए इस्तेमाल किए जाने वाले शब्द के मुताबिक है. इसमें सुरक्षित ऑडियंस सेवाओं की चर्चा और सुरक्षित नीलामी सेवाओं के दस्तावेज़ जैसे अन्य रिपॉज़िटरी भी शामिल हैं. |
| दस्तावेज़ | bidding_auction_services_gcp_guide.md में, Cloud debugger API का रेफ़रंस हटाएं. | हमने दस्तावेज़ को अपडेट कर दिया है और रेफ़रंस हटा दिया है. |
| एपीआई प्रयोग | KV लुकअप की वजह से लेटेंसी 50 मि॰से॰ से ज़्यादा हो रही है. इसमें करीब 100 मिलीसेकंड लग रहे हैं. क्या आपके पास इस बारे में कोई सलाह है कि दूसरे सेलर को क्या अच्छा नतीजा मिला है? क्या आपके पास टाइम आउट और समय को मेज़र करने के बारे में कोई सुझाव है? |
KV सर्वर कॉल, स्क्रिप्ट रनर के संदर्भ में होता है. इसका मतलब है कि यह कॉल, Chrome ब्राउज़र के अंदर मौजूद खास सुरक्षित एनवायरमेंट में होता है. इसका मकसद, इन स्क्रिप्ट रनर में मौजूद जानकारी को, एपीआई के अलावा किसी भी अन्य तरीके से ऐक्सेस होने से बचाना है. हमने इस बारे में ज़्यादा जानकारी यहां दी है. |
| एपीआई प्रयोग | क्या KV सर्वर के लिए, किसी तय समय में जवाब देने की समयसीमा तय की गई है? | सेलर, नीलामी कॉन्फ़िगरेशन में "perBuyerCumulativeTimeouts" फ़ील्ड की जानकारी दे सकते हैं. इस टाइम आउट में, भरोसेमंद बिडिंग सिग्नल फ़ेच करने में लगने वाला समय भी शामिल होता है. |
| इंतज़ार का समय | प्राइवसी सैंडबॉक्स की टीम, इंतज़ार के समय की समस्या को कैसे हल कर रही है? | हम लैटेंसी को तय सीमा के अंदर रखने के लिए, कई रणनीतियों को आज़मा रहे हैं. इनके बारे में यहां देखें. |
डिजिटल विज्ञापनों की परफ़ॉर्मेंस का आकलन करना
एट्रिब्यूशन रिपोर्टिंग (और अन्य एपीआई)
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| मैन्युअल कैंपेन ऑप्टिमाइज़ेशन | ARA, कैंपेन को मैन्युअल तरीके से ऑप्टिमाइज़ नहीं करता. | हमने विज्ञापन टेक्नोलॉजी के साथ इस स्थिति के बारे में बातचीत की है. साथ ही, मैन्युअल कैंपेन ऑप्टिमाइज़ेशन में मदद करने के लिए, एआरए का इस्तेमाल करने के तरीके भी बताए हैं. ARA को इस तरह से बनाया गया है कि विज्ञापन टेक्नोलॉजी को पसंद के मुताबिक बनाया जा सके. साथ ही, विज्ञापन टेक्नोलॉजी के इस्तेमाल के अलग-अलग उदाहरणों को हल करने के लिए, इसमें बदलाव किया जा सके. कुछ सुझावों में, अलग-अलग तरह के इवेंट-लेवल कॉन्फ़िगरेशन का इस्तेमाल करना शामिल था. साथ ही, इवेंट-लेवल रिपोर्ट का इस्तेमाल, खास जानकारी वाली रिपोर्ट के साथ करना था. इससे, ग़ैर-ज़रूरी डेटा के असर को कम करने के साथ-साथ, मैन्युअल और ऑटोमैटिक ऑप्टिमाइज़ेशन की ज़रूरतों को पूरा किया जा सकता है. हम ARA कॉन्फ़िगरेशन को पसंद के मुताबिक बनाने और उनमें बदलाव करने की सुविधा के बारे में, नेटवर्क से जुड़े ज़्यादा सुझाव, राय या शिकायतें सुनने के लिए तैयार हैं. |
| कन्वर्ज़न टाइप | Google, सिर्फ़ आठ तरह के कन्वर्ज़न टाइप की अनुमति देता है. | हमने इवेंट-लेवल की ज़्यादा सुविधा वाली रिपोर्टिंग का ज़्यादातर हिस्सा लागू कर दिया है. इससे विज्ञापन टेक्नोलॉजी विशेषज्ञों को रिपोर्टिंग विंडो, एट्रिब्यूशन रिपोर्ट, और ट्रिगर डेटा के बिट की संख्या के मामले में ज़्यादा सुविधा मिलती है. विज्ञापन टेक्नोलॉजी विशेषज्ञ, ऐसा कॉन्फ़िगरेशन चुन सकते हैं जिससे 32 अलग-अलग कन्वर्ज़न टाइप को मेज़र किया जा सके. |
| एग्रीगेट की जा सकने वाली रिपोर्ट के इवेंट की सीमा | एग्रीगेट की जा सकने वाली हर रिपोर्ट में कम से कम 20 कन्वर्ज़न इवेंट की संख्या, सीमित बजट वाले छोटे विज्ञापन देने वालों के लिए काम नहीं करती. | एग्रीगेट की जा सकने वाली हर रिपोर्ट के लिए, कन्वर्ज़न इवेंट की कोई तय संख्या नहीं होती. इसके अलावा, विज्ञापन देने वाली छोटी कंपनियों के लिए, एग्रीगेट की जा सकने वाली रिपोर्ट को ऑप्टिमाइज़ करने के लिए, डिज़ाइन से जुड़े कई फ़ैसले लिए जा सकते हैं. जैसे, ट्रैक किए गए मुख्य स्ट्रक्चर / डाइमेंशन में बदलाव करना, एप्सिलॉन के अलग-अलग लेवल की जांच करना, बड़ी बैच फ़्रीक्वेंसी की जांच करना, और मेज़रमेंट लक्ष्यों के बीच योगदान वाले बजट के अलग-अलग बंटवारे की जांच करना. विज्ञापन टेक्नोलॉजी से जुड़ी छोटी कंपनियां, ग़ैर-ज़रूरी डेटा के असर को कम करने के लिए, इवेंट-लेवल रिपोर्ट और खास जानकारी वाली रिपोर्ट को मिलाकर भी प्रयोग कर सकती हैं. |
| रीयल-टाइम डेटा | डीएसपी को रीयल-टाइम डेटा (जैसे, क्लिक, सेशन, और कन्वर्ज़न) से वंचित करना, मौजूदा सुविधाओं को बनाए रखने की प्रतिबद्धता के ख़िलाफ़ है. डीएसपी इस डेटा का इस्तेमाल, बिडिंग की रणनीति में बदलाव करने और कैंपेन की परफ़ॉर्मेंस को बेहतर बनाने के लिए करते हैं. | एआरए के साथ भी, क्लिक और सेशन रीयल टाइम में रहते हैं. साथ ही, 3PCs के साथ भी कन्वर्ज़न हमेशा बाद में रिकॉर्ड होते हैं. |
| फ़ील्ड गुम हैं | फ़ुल फ़्लेक्सिबल इवेंट रोल आउट में ज़रूरी शर्तें मौजूद नहीं हैं: 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 की अन्य सुविधाएं, इस इस्तेमाल के उदाहरण को हल करने में मदद कर सकती हैं या नहीं. |
| एपीआई प्रयोग | एट्रिब्यूशन इवेंट को सभी पार्टनर के साथ शेयर करने के तरीके को एक जैसा करने का मौका. इससे एसएसपी, डीएसपी वगैरह को फ़ायदा होता है. | हम विज्ञापन टेक्नोलॉजी के साथ सिंक करने की योजना बना रहे हैं, ताकि उनके सुझाव, शिकायत या राय को बेहतर तरीके से समझा जा सके. साथ ही, यह भी पता लगाया जा सके कि उन्हें किन समस्याओं का सामना करना पड़ रहा है. |
| ट्रैफ़िक की संख्या की जांच करना | क्या मोड B के लिए, सभी Chrome वर्शन के लिए टेस्ट ट्रैफ़िक स्थिर है? | एक्सपेरिमेंट ग्रुप में शामिल होने पर, Chrome की सेटिंग पर कोई असर नहीं पड़ता. |
| दस्तावेज़ | Pixel फ़ोन के लिए ARA की सुविधा. | हमने इस इस्तेमाल के उदाहरण के बारे में जानकारी पब्लिश की है. साथ ही, हम इकोसिस्टम से इस बारे में ज़्यादा सुझाव, राय या शिकायतें पाने के लिए तैयार हैं. |
| एपीआई प्रयोग | अगर कन्वर्ज़न, लास्ट टच से नहीं होता है, तो हो सकता है कि ई-कॉमर्स प्लैटफ़ॉर्म पर तीसरे पक्ष के सेलर के लिए, ARA को सही सोर्स को एट्रिब्यूट न किया जाए. | कंपनियां गलत एट्रिब्यूशन से बचने के लिए, फ़िल्टर का इस्तेमाल कर सकती हैं. ऐसा करने पर, कोई कन्वर्ज़न रिपोर्ट जनरेट नहीं होगी. हम इस इस्तेमाल के उदाहरण में मदद करने के लिए, एट्रिब्यूशन से पहले फ़िल्टर करने के प्रस्ताव पर भी काम कर रहे हैं. |
| ब्राउज़र के लिए सहायता | क्या ARA अलग-अलग ब्राउज़र पर काम करेगा? | हम अन्य ब्राउज़र को Privacy Sandbox API को अपनाने का न्योता देते हैं. साथ ही, W3C में सार्वजनिक तौर पर अपने तरीके के बारे में चर्चा करने के लिए समय देना जारी रखेंगे. हमने साफ़ तौर पर बताया है कि ARA को लॉन्च करने के लक्ष्य के तौर पर इंटरऑपरेबिलिटी को रखा गया है. ARA का डिज़ाइन, ब्राउज़र पर निर्भर नहीं होना चाहिए. साथ ही, निजता के अलग-अलग रुख वाले वेंडर के लिए, वेंडर की तय की गई वैल्यू में बदलाव किया जा सकता है. अन्य ब्राउज़र, क्रॉस-साइट आइडेंटिफ़ायर के लिए काम के विकल्प उपलब्ध कराने के बारे में अपनी पसंद के हिसाब से फ़ैसला ले रहे हैं. ये विकल्प, कॉन्टेंट और सेवाओं के डिजिटल नेटवर्क को बेहतर बना सकते हैं. हमें यह जानकर खुशी हो रही है कि Microsoft Edge ने बताया है कि वह एआरए के साथ काम करेगा. |
| एपीआई प्रयोग | registerAdBeacon/reportEvent (और navigation_start/commit automatic beacons) के लिए ARA सोर्स रजिस्ट्रेशन के लिए, सोर्स किस तरह का होना चाहिए? | यह इस बात पर निर्भर करता है कि ये बीकन अपने-आप ट्रिगर होते हैं या मैन्युअल तरीके से:
- रिज़र्व किया गया.* (यानी अपने-आप होने वाले) इवेंट, नेविगेशन-सोर्स टाइप के होने चाहिए. - मैन्युअल तरीके से ट्रिगर किए गए इवेंट, इवेंट-सोर्स टाइप के होने चाहिए. |
| एपीआई प्रयोग | क्या हर सोर्स इवेंट के लिए, ज़्यादा से ज़्यादा 20 रिपोर्ट इकट्ठा की जा सकती हैं? क्या यह सीमा दुनिया भर के लिए है या रोज़ाना के हिसाब से है? क्या इस सीमा को बढ़ाने का कोई प्लान है? | हर सोर्स के लिए 20 एग्रीगेट की जा सकने वाली रिपोर्ट की सीमा, एक ग्लोबल सीमा है. इसमें हर सोर्स के लिए 20 एग्रीगेट की जा सकने वाली रिपोर्ट बनाई जा सकती हैं. यह सीमा, ब्राउज़र सेट करता है और इसे कॉन्फ़िगर नहीं किया जा सकता. इस सीमा का मकसद, शून्य रिपोर्ट की मदद से असली एट्रिब्यूशन रिपोर्ट की सुरक्षा का गलत इस्तेमाल करने से रोकना है. हमने इस बारे में ज़्यादा जानकारी यहां दी है. |
| एपीआई प्रयोग | ARA का इस्तेमाल करके ईमेल मार्केटिंग के लिए सहायता. | अगर आपके पास ईमेल होस्टिंग साइट का कंट्रोल नहीं है, तो फ़िलहाल ARA में इस इस्तेमाल के उदाहरण के लिए कोई सीधा सहायता नहीं है. हम इस बारे में यहां चर्चा कर रहे हैं. अगर आपके पास कोई और सुझाव है, तो हमें बताएं. |
| Epsilon | एग्रीगेट एपीआई के लिए, epsilon की वैल्यू कब तय की जाएगी? | विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली कंपनियां, मौजूदा epsilon वैल्यू को Privacy Sandbox के तय किए गए थ्रेशोल्ड तक कॉन्फ़िगर कर सकती हैं. फ़िलहाल, यह थ्रेशोल्ड 64 है. हमारा सुझाव है कि आप अलग-अलग एप्सिलॉन वैल्यू को टेस्ट करें. साथ ही, अपने इस्तेमाल के उदाहरणों के लिए, बदलाव के पॉइंट की पहचान करें और सुझाव/राय दें. हम एप्सीलॉन वैल्यू की रेंज में कोई भी बदलाव करने से पहले, विज्ञापन टेक्नोलॉजी के विशेषज्ञों को इसकी जानकारी ज़रूर देंगे. |
| एपीआई में सुधार | ऐसे इस्तेमाल के उदाहरण के लिए सहायता करें जहां विज्ञापन देने वाला, बाहरी सीआरएम डेटा से मैच करने के लिए, trigger_data फ़ील्ड में आइडेंटिफ़ायर डाल सकता है. इससे विज्ञापन देने वाले, कन्वर्ज़न की क्वालिटी की पुष्टि कर सकते हैं. | हम इस अनुरोध पर विचार कर रहे हैं. यहां हमें अपने सुझाव, राय या शिकायत भेजें. |
| एपीआई प्रयोग | रीडायरेक्ट यूआरएल को डेस्टिनेशन यूआरएल के तौर पर मैनेज करने का तरीका. | विज्ञापन टेक्नोलॉजी विशेषज्ञ, इनमें से कोई एक काम कर सकते हैं: 1. डेस्टिनेशन फ़ील्ड में फ़ाइनल डेस्टिनेशन यूआरएल डालें; 2. डेस्टिनेशन फ़ील्ड में ज़्यादा से ज़्यादा तीन यूआरएल डाले जा सकते हैं. दोनों विकल्पों के लिए, आपको फ़ाइनल डेस्टिनेशन यूआरएल की जानकारी होनी चाहिए. हमने इस बारे में ज़्यादा जानकारी यहां दी है. |
एग्रीगेशन सेवा
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| डिस्कवरी का मुख्य तरीका | पासकोड खोजने के तरीके का अनुरोध करना | हमारे पास प्रॉडक्ट की खोज के लिए एक प्रस्ताव है. हम इस प्रस्ताव पर, इकोसिस्टम से सुझाव/राय या शिकायत का स्वागत करते हैं. |
| एपीआई प्रयोग | एग्रीगेशन सेवा पर निगरानी के लिए रोडमैप | हम ज़्यादा निगरानी करने के विकल्पों की समीक्षा कर रहे हैं. साथ ही, यहां नेटवर्क से जुड़े सुझाव, शिकायत या राय भेजने के लिए हम आपका स्वागत करते हैं. |
| एपीआई में सुधार | रिपोर्ट के लिए फिर से क्वेरी करने का अनुरोध किया जा रहा है. | एग्रीगेशन सेवा, एक ऐसे प्रस्ताव पर काम कर रही है जिसमें विज्ञापन टेक्नोलॉजी हर रिपोर्ट के लिए, अपने एप्सिलॉन को बांट सकती हैं. इससे हर क्वेरी में ज़्यादा गड़बड़ी हो सकती है. हालांकि, इससे विज्ञापन टेक्नोलॉजी को फिर से क्वेरी करने और निजता बनाए रखने में मदद मिलेगी. |
| एपीआई में सुधार | आपको एक ही AWS आईडी से कई ऑरिजिन जोड़ने हैं. | एग्रीगेशन सेवा की मदद से, अब एक ही क्लाउड खाते (Google Cloud या AWS) में कई साइटों को शामिल किया जा सकेगा. इससे विज्ञापन टेक्नोलॉजी कंपनियों को एक ही एग्रीगेशन सर्विस एन्क्लेव का इस्तेमाल करके, एक ही साइट की कई रिपोर्ट और कई ऑरिजिन की रिपोर्ट को प्रोसेस करने में मदद मिलेगी. |
| एपीआई प्रयोग | एग्रीगेट किए जा सकने वाले बैच के पूरा न होने पर, यह पक्का नहीं होता कि बजट खर्च हुआ है या नहीं. साथ ही, यह भी नहीं पता चलता कि बैच को फिर से प्रोसेस किया जा सकता है या नहीं. जब एग्रीगेशन सेवा को डुप्लीकेट रिपोर्ट के लिए बजट से जुड़ी गड़बड़ी का पता चलता है, तो बाकी सभी रिपोर्ट मिट जाती हैं. इस नुकसान को कम कैसे करें? | आम तौर पर, अगर पूरा जॉब पूरा नहीं होता है, तो बजट खर्च नहीं होगा. बजट खत्म होने की वजह से, कभी-कभी विज्ञापन टेक्नोलॉजी से जुड़ी सेवाएं काम नहीं करतीं. ऐसे में, विज्ञापन टेक्नोलॉजी विशेषज्ञ बजट वापस पाने का अनुरोध कर सकते हैं. अगर विज्ञापन टेक्नोलॉजी विशेषज्ञ को बजट खत्म होने की गड़बड़ी की वजह से, बार-बार जॉब पूरा न होने की समस्या आती है, तो उन्हें अपनी बैचिंग की रणनीति की पुष्टि करनी चाहिए. सही तरीके से बैच बनाने और डुप्लीकेट रिपोर्ट और गड़बड़ियों से बचने का तरीका यहां बताया गया है. बजट रिकवरी के बारे में सुझाव/राय देने के लिए, यहां क्लिक करें. |
| एपीआई प्रयोग | यहां बताए गए ट्रिगर के साथ Private Aggregation API का इस्तेमाल करने पर, हर नीलामी के लिए एग्रीगेट की जा सकने वाली रिपोर्ट जनरेट होगी. एग्रीगेशन सेवा की स्केलिंग क्षमताएं क्या हैं? | एग्रीगेशन सेवा, किसी बैच में मौजूद कुंजियों या रिपोर्ट की संख्या पर कोई सीमा नहीं तय करती. हालांकि, ज़रूरी मेमोरी की वजह से, फ़िलहाल 10^14 रिपोर्ट और 10^12 कुंजियों का इस्तेमाल नहीं किया जा सकता. साइज़ तय करने से जुड़ी हमारी गाइड में, उन रेंज के बारे में बताया गया है जिनकी हमने जांच की है. साथ ही, इसमें उम्मीद के मुताबिक लोड और काम करने वाले क्लाउड वर्चुअल मशीन इंस्टेंस टाइप के हिसाब से, बेहतर परफ़ॉर्मेंस के लिए सुझाव भी दिए गए हैं. |
| डेटा प्रोसेसिंग | अगर एन्क्रिप्ट (सुरक्षित) किए गए डेटा में निजी जानकारी शामिल है, तो एग्रीगेशन सेवा को एन्क्रिप्ट किया गया डेटा देने का कानूनी तरीका क्या है? क्या यह पक्का किया जा सकता है कि कोऑर्डिनेटर, एन्क्रिप्ट (सुरक्षित) किए गए डेटा को ऐक्सेस नहीं करेगा? |
एग्रीगेशन सेवा, एग्रीगेटर के साथ एन्क्रिप्ट (सुरक्षित) किया गया / उपयोगकर्ता का डेटा शेयर नहीं करती. एग्रीगेशन सेवा, कुंजी मैनेजमेंट और खाते के लिए कोऑर्डिनेटर का इस्तेमाल करती है. कोऑर्डिनेटर के बारे में कुछ जानकारी यहां मिल सकती है. बजट खर्च करने के लिए, एग्रीगेशन सेवा सिर्फ़ शेयर किया गया आईडी और रिपोर्टिंग ऑरिजिन को PBS के साथ शेयर करती है. कई साइटों के लिए एग्रीगेशन सेवा लॉन्च करने के बाद, हम ऑरिजिन को साइट से बदल देंगे. ध्यान दें कि एग्रीगेशन सेवा, टीईई में चलती है. यह एक ऐसी जगह है जहां क्लाइंट की रिपोर्ट को डिक्रिप्ट किया जा सकता है. टीईई में चलने वाला कोड ओपन सोर्स है. साथ ही, यहां बताए गए तरीके से, बाहरी पक्षों की ओर से इसका ऑडिट किया जाता है. |
Private Aggregation API
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| एपीआई प्रयोग | टीईई में, कई एग्रीगेशन सर्वर को रिपोर्ट भेजने की सुविधा, जो कॉम्पोनेंट सेलर के पास होती है. | निजी एग्रीगेशन एपीआई के मौजूदा स्टेटस में, यह सुविधा काम नहीं करती. हमने इस समस्या के बारे में ज़्यादा जानकारी यहां दी है. |
| दस्तावेज़ | Google के ट्रायल में इस्तेमाल की जाने वाली एप्सिलॉन वैल्यू क्या है? | निजी एग्रीगेशन एपीआई के लिए, एग्रीगेशन सेवा क्वेरी में बताई गई ε वैल्यू, 2^16 के L1 योगदान बजट से मेल खाती है. इसे हर 10 मिनट में लागू किया जाता है. 2^20 का 'बैकस्टॉप' एल1 योगदान बजट भी है. इसे 24 घंटे रोलिंग के आधार पर लागू किया जाता है. इसलिए, असल में निजता पैरामीटर, 10 मिनट के रोलिंग बेसिस पर ε होता है और 24 घंटे के रोलिंग बेसिस पर 16ε होता है (144ε के बजाय). एग्रीगेशन सेवा, फ़िलहाल टेस्टिंग के लिए ε की रेंज (ज़्यादा से ज़्यादा 64) के साथ काम करती है, ताकि अलग-अलग एग्रीगेशन की रणनीतियों के साथ प्रयोग किया जा सके. साथ ही, निजी एग्रीगेशन और अन्य एपीआई के लिए, अलग-अलग निजता पैरामीटर के साथ सिस्टम की उपयोगिता के बारे में सुझाव दिया जा सके. हम समय के साथ, अनुमति वाली ज़्यादा से ज़्यादा एप्सिलॉन वैल्यू की समीक्षा करेंगे. ऐसा इसलिए, क्योंकि हमें टेस्टर से सुझाव/राय/शिकायत मिलती है. साथ ही, हम ऐसी सुविधाएं जोड़ते हैं जिनसे निजता बजट का ज़्यादा बेहतर तरीके से इस्तेमाल किया जा सके. |
गुप्त ट्रैकिंग को सीमित करना
यूज़र-एजेंट रिडक्शन/यूज़र-एजेंट क्लाइंट हिंट
इस तिमाही में कोई सुझाव, राय या शिकायत नहीं मिली.
आईपी प्रोटेक्शन (पहले इसे Gnatcatcher कहा जाता था)
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| रिज़ॉल्यूशन आईडी | Privacy Sandbox को इस बात पर ज़्यादा ध्यान देने की ज़रूरत है कि आईपी पर बनाए जाने वाले रिज़ॉल्यूशन आईडी, विज्ञापन देने वालों के लिए सही नहीं हैं. | प्राइवसी सैंडबॉक्स से यह साफ़ तौर पर पता चलता है कि हमारा मकसद क्रॉस-साइट ट्रैकिंग को कम करना है. कुकी के अलावा, हमारी सार्वजनिक पहलों का प्रमोशन, privacysandbox.com और GitHub, दोनों पर किया जाता है. हम क्रॉस-साइट ट्रैकिंग को कम करने की कोशिश करते हैं. इसमें आईपी पतों के आधार पर की जाने वाली ट्रैकिंग भी शामिल है. हालांकि, यह तय करना कि क्रॉस-साइट ट्रैकिंग को पहले से चालू करना है या नहीं, यह हर वेबसाइट के लिए अलग-अलग होता है. नियमों का पालन करने के लिए, इन दिनों ज़्यादा जांच की जा रही है. ऐसे में, हर कंपनी को यह समझना चाहिए कि सेवा देने वाली कंपनियां कौनसे तरीके अपनाती हैं. |
| Chromecast | क्या आईपी सुरक्षा की सुविधा से Chromecast या अन्य Chrome डिवाइसों पर असर पड़ेगा? | फ़िलहाल, Chromecast डिवाइसों पर आईपी सुरक्षा की सुविधा लागू करने का कोई प्लान नहीं है. |
| आईपी पते की सुरक्षा की सूची | क्या वेब-वाइड क्रॉस-साइट ट्रैकिंग के लिए, आईपी पतों का इस्तेमाल करने वाले तीसरे पक्षों की पहचान की गई सूची पब्लिश की जाएगी? | यहां बताए गए तरीके से, फ़ाइनल होने के बाद सूची पब्लिश की जाएगी. |
बाउंस ट्रैकिंग को कम करने की सुविधा
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| सिंगल साइन-ऑन (एसएसओ) से जुड़ी छूट | छूट पाने के लिए, बाउंस ट्रैकिंग मटिगेशन (बीटीएम) एसएसओ के इस्तेमाल के उदाहरणों की पुष्टि कैसे करेगा? | Chrome के हेयुरिस्टिक्स की मदद से, BTM बंद कर दिया जाएगा. ज़्यादा जानकारी के लिए, एक्सप्लेनर देखें. |
| बंद हो चुकी सुविधा को कुछ समय के लिए इस्तेमाल करने वाला ट्रायल | क्या 3PC के बंद होने के ट्रायल में शामिल साइटों के लिए, BTM चालू है? | नहीं, BTM, बंद होने की प्रक्रिया के ट्रायल के दौरान बनाए गए कुकी अपवादों को मानता है. इस बारे में यहां बताया गया है. |
प्राइवसी बजट
GitHub पर मौजूद प्राइवसी सैंडबॉक्स के बारे में जानकारी और डेवलपर साइट में बताया गया है कि प्राइवसी सैंडबॉक्स के प्रपोज़ल के तहत,प्राइवसी बजट को अब गंभीरता से नहीं लिया जा रहा है.
अलग-अलग साइटों पर निजता की सीमाओं को बेहतर बनाना
मिलती-जुलती वेबसाइट के सेट (पहले इन्हें फ़र्स्ट-पार्टी सेट कहा जाता था)
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| सुविधा का अनुरोध | सीएचआईपी और / या स्टोरेज पार्टिशनिंग को RWS में अपने-आप ऐक्सेस करने की अनुमति है. इसके लिए, Storage Access API की ज़रूरत नहीं होती और न ही उपयोगकर्ता को कुछ करने की ज़रूरत होती है. | हम इस सुविधा को पूरा करने वाली सुविधा के फ़ायदों और इसे उपलब्ध कराने की संभावनाओं पर विचार कर रहे हैं. एक बात यह है कि अलग-अलग ब्राउज़र के साथ काम करने में संभावित अंतर हो सकता है. RWS, Storage Access API का फ़ायदा उठाकर इस अंतर को दूर करता है. फ़िलहाल, अन्य ब्राउज़र पर इस सुविधा के बराबर कोई सुविधा उपलब्ध नहीं है. हम डेवलपर को इस समस्या के बारे में अपने इस्तेमाल के उदाहरण सबमिट करने का सुझाव देते हैं, ताकि इस बारे में यहां चर्चा की जा सके. |
| नीतियों का पालन न करने वाले सेट हटाना | नीति का पालन न करने वाले सेट को रिपॉज़िटरी से हटाने की प्रोसेस क्या है? | हम इसकी प्रोसेस तय करने पर काम कर रहे हैं. अपडेट उपलब्ध होने पर, हम उन्हें शेयर करेंगे. |
| नीति उल्लंघन ठीक करने की प्रक्रिया | आरडब्ल्यूएस लागू करने की प्रोसेस में, Google की भूमिका के बारे में साफ़ तौर पर नहीं बताया गया है. | आरडब्ल्यूएस एक ऐसा प्रोजेक्ट है जो अभी जारी है. हमें अब भी नए सबमिशन मिल रहे हैं. इसलिए, इस प्रोसेस और हमारी शर्तों को अभी तक पूरी तरह से तय नहीं किया गया है. हम इस बात से सहमत हैं कि सबमिशन से जुड़ी हमारी गाइडलाइन में, सबमिशन से जुड़ी ज़रूरी शर्तों के बारे में पूरी जानकारी होनी चाहिए. आने वाले समय में, हम सबमिशन से जुड़ी गाइडलाइन में ज़्यादा जानकारी जोड़ेंगे, ताकि किसी तरह की गड़बड़ी और भ्रम से बचा जा सके. हमारा मकसद यह है कि सबमिशन की प्रोसेस ज़्यादा से ज़्यादा तकनीकी हो, ताकि हम मानवीय हस्तक्षेप को कम कर सकें और पूरी तरह से ऑटोमेटेड जांच पर भरोसा कर सकें. इस तरह के पीआर के लिए, लोगों के साथ ज़्यादा इंटरैक्शन की ज़रूरत होती है, क्योंकि इनमें ऐसे व्यवहार शामिल होते हैं जिनकी हमने उम्मीद नहीं की थी. हालांकि, इनसे हमें ऑटोमेशन के लिए ज़्यादा क्षेत्रों की पहचान करने में मदद मिलती है. साथ ही, आने वाले समय में इन समस्याओं से बचने के लिए, अपने दिशा-निर्देशों को ठीक करने के तरीके भी मिलते हैं. |
| डेटा शेयर करना | ऐसी सुविधा का अनुरोध करना जिसकी मदद से डोमेन के मालिक यह बता सकें कि वे उपयोगकर्ता की सहमति लेकर, तीसरे पक्ष के साथ भी आरडब्ल्यूएस डेटा शेयर करना चाहते हैं. | अनुरोध की गई सुविधा, FedCM और Storage Access API जैसे एपीआई के ज़रिए पहले से ही उपलब्ध है. ये एपीआई, उपयोगकर्ता की अनुमति मिलने के बाद, पुष्टि की गई पहचान का ऐक्सेस चालू करते हैं. हम ऐसे किसी भी इस्तेमाल के उदाहरण के बारे में सुझाव, राय या शिकायत का स्वागत करते हैं जो आपके हिसाब से मुमकिन नहीं है. |
| स्टोरेज के अन्य तरीके | क्या लोकल स्टोरेज या सेशन स्टोरेज में सेव की गई जानकारी को भी तीसरे पक्ष के तौर पर माना जाएगा? | Chrome के 115 वर्शन से, तीसरे पक्ष के कॉन्टेक्स्ट में इस्तेमाल किए जाने पर, लोकल स्टोरेज, सेशन स्टोरेज, और कुकी को छोड़कर स्टोरेज के अन्य तरीकों को अलग-अलग हिस्सों में बांटा गया है. ज़्यादा जानकारी के लिए, यह ब्लॉग पोस्ट देखें. |
| असोसिएट किए गए सेट की सीमा | "ज़्यादा से ज़्यादा पांच साइटें जोड़ी जा सकती हैं" के बावजूद, पांच से ज़्यादा डोमेन सबमिट करने वाले संगठनों का क्या होगा? | ये सेट, GitHub की प्रोसेस के ज़रिए स्वीकार किए जाएंगे. हालांकि, ब्राउज़र (Chrome) सिर्फ़ पहले पांच डोमेन पर, Storage Access API के अपने-आप अनुमति देने के नियमों को लागू करेगा. साथ ही, बाकी डोमेन को अनदेखा करेगा, जैसा कि यहां बताया गया है. |
| find_robots_txt | find_robots_txt जांच, रीडायरेक्ट के साथ काम नहीं करती. | इस समस्या को ठीक करने के लिए, यहां एक सुधार सबमिट किया गया है. |
| उपयोगकर्ता का जेस्चर | accessStorage() के लिए, उपयोगकर्ता के जेस्चर की ज़रूरत को हटाएं. | यह ज़रूरी शर्त, requestStorageAccess API के लिए सभी बड़े ब्राउज़र में मौजूद डिज़ाइन के आधार पर तय की गई है. हम इस GitHub समस्या में ज़्यादा सुझाव, शिकायत या राय देने और इस्तेमाल के उदाहरणों का न्योता देते हैं. इससे हमें इस अनुरोध को प्राथमिकता देने और अलग-अलग ब्राउज़र पर चर्चा करने में मदद मिलेगी. |
| उपयोगकर्ता का जेस्चर | क्या Chrome या OS को रीस्टार्ट करने के बाद, तीसरे पक्ष के स्टोरेज को ऐक्सेस करने की अनुमति देने के लिए, उपयोगकर्ता के जेस्चर की ज़रूरत होती है? | हां, लेकिन हम इस व्यवहार में बदलाव करने के बारे में, यहां इकोसिस्टम से ज़्यादा सुझाव/राय/शिकायतें पाने के लिए तैयार हैं. |
Fenced Frames API
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| adComponent | फ़ेंस किए गए फ़्रेम के साथ AdComponents का इस्तेमाल करने के लिए, दस्तावेज़ और सुविधाओं की कमी. | हम इस इस्तेमाल के उदाहरण के बारे में ज़्यादा दस्तावेज़ शेयर करना चाहते हैं. साथ ही, यह भी बताना है कि विज्ञापन कॉम्पोनेंट, फ़ेंस किए गए फ़्रेम में काम करते हैं. इसके लिए, getNestedConfigs() का इस्तेमाल किया जाता है. इस बारे में ज़्यादा जानकारी यहां दी गई है. |
| (पिछली तिमाहियों में भी रिपोर्ट की गई) adComponent को रेंडर करें |
फ़ेंस किए गए फ़्रेम में adComponents को रेंडर करने के तरीके के सैंपल कोड का अनुरोध करना. | हम यहां कुछ सैंपल कोड शेयर करने पर काम कर रहे हैं. |
| तीसरे पक्ष के विज्ञापन की पुष्टि करना | फ़ेंस किए गए फ़्रेम के संदर्भ में, तीसरे पक्ष की विज्ञापन पुष्टि करने वाली कंपनी की भूमिका के बारे में ज़्यादा जानकारी चाहिए. खास तौर पर, कॉन्टेक्स्ट/ब्रैंड सेफ़्टी के बारे में. | फ़ेंस किए गए फ़्रेम की विज्ञापन रिपोर्टिंग की मदद से, डीएसपी तीसरे पक्ष के विज्ञापन की पुष्टि करने वाले लोगों या कंपनियों को इंप्रेशन और नीलामी इवेंट-लेवल का डेटा भेज सकते हैं. ऐसा, ब्रैंड सुरक्षा की जांच और बिलिंग के बाद किया जाता है. |
| बड़े होने वाले विज्ञापन | बड़े होने वाले विज्ञापनों के साथ काम करने के लिए अनुरोध करना. | अगर विज्ञापन को एक ही आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) वाले दो साइज़ के बीच स्विच करना है और दोनों में फ़ंक्शन के हिसाब से कोई अंतर नहीं है (सिर्फ़ साइज़ में अंतर है), तो एम्बेड करने वाला व्यक्ति, फ़ेंस किए गए फ़्रेम का साइज़, विज्ञापन के दूसरे साइज़ के हिसाब से बदल सकता है. इसके हिसाब से, ब्राउज़र फ़ेंस किए गए फ़्रेम एलिमेंट को स्केल करता है. |
| (पिछली तिमाहियों में भी इसकी शिकायत की गई थी) वीडियो और नेटिव इन्वेंट्री के लिए सहायता |
क्या फ़ेंस किए गए फ़्रेम, वीडियो और नेटिव इन्वेंट्री के साथ काम करते हैं? | हमारा जवाब पिछली तिमाहियों के जवाब से मिलता-जुलता है: PA API, iframes पर आधारित एक तरीके का इस्तेमाल करके वीडियो रेंडरिंग की सुविधा देता है. हालांकि, हमने अब तक वीडियो और नेटिव विज्ञापनों को रेंडर करने के लिए, फ़ेंस किए गए फ़्रेम के साथ काम करने वाला कोई समाधान नहीं बनाया है. इस वजह से, हमने फ़ेंस किए गए फ़्रेम को लागू करने की प्रक्रिया को 2026 तक के लिए टाल दिया है. इसका मतलब है कि अगर कोई पार्टनर अब फ़ेंस किए गए फ़्रेम लागू करने का फ़ैसला करता है, तो उस पार्टनर के लिए वीडियो और नेटिव विज्ञापनों के लिए सहायता उपलब्ध नहीं होगी. |
| एडवाइज़री बोर्ड | नेटिव विज्ञापन वेंडर के लिए सलाहकार बोर्ड बनाने का अनुरोध करता है, ताकि यह पक्का किया जा सके कि फ़ेंस किए गए फ़्रेम को लागू करने के लिए इंडस्ट्री स्टैंडर्ड का पालन किया जा रहा है. | PA API में, फ़ेंस किए गए फ़्रेम का इस्तेमाल 2026 से पहले नहीं किया जा सकता. इस अतिरिक्त समय से, हमें इंडस्ट्री के साथ मिलकर काम करने में मदद मिलेगी. इससे, हम ज़रूरी इस्तेमाल के उदाहरणों की एक बड़ी रेंज के लिए, सहायता को डिज़ाइन और लागू कर पाएंगे. हमने पहले बताया था कि हम फ़ेंस किए गए फ़्रेम को ज़रूरत से पहले बेहतर बना देंगे, ताकि PA API की मदद से वीडियो और नेटिव विज्ञापनों के लिए सहायता जारी रखी जा सके. हमने जो वादे किए हैं उनके मुताबिक, हम इस तरह के किसी भी बदलाव के बारे में सीएमए को बताएंगे और उससे बातचीत करेंगे. साथ ही, फ़ेंस किए गए फ़्रेम की ज़रूरत पड़ने से पहले, हम इस बारे में नेटवर्क से मिलने वाले सुझावों, शिकायतों या राय पर काम करते रहेंगे. W3C और IAB Tech Lab जैसे विज्ञापन स्टैंडर्ड संगठनों के साथ काम करने के हमारे मॉडल की मदद से, इंडस्ट्री के सभी विशेषज्ञ, ज़रूरत पड़ने से पहले डिज़ाइन के बारे में सलाह दे सकते हैं. |
| (पिछली तिमाहियों में भी रिपोर्ट किया गया था) अलग-अलग प्लैटफ़ॉर्म पर साइज़ में अंतर |
फ़ेंस किए गए फ़्रेम में दिखाए गए कॉन्टेंट का साइज़, डेस्कटॉप और स्मार्टफ़ोन पर अलग-अलग दिखने की शिकायत. | यह Chromium की एक समस्या है. हम इसकी जांच कर रहे हैं. यहां हमें अपने सुझाव, शिकायत या राय भेजें. |
| एपीआई में सुधार | क्या फ़ेंस किए गए फ़्रेम की ज़रूरी शर्त को 2025 तक के लिए टाल दिया गया है, ताकि नेटिव विज्ञापनों को अब प्राइवसी सैंडबॉक्स के तहत इस्तेमाल किया जा सके? | हमने सार्वजनिक तौर पर किए गए एलान में बताया था कि फ़ेंस किए गए फ़्रेम की सुविधा को 2026 से पहले लागू नहीं किया जाएगा. हमें पता चला है कि फ़ेंस किए गए फ़्रेम को "इस्तेमाल करने के लिए ज़रूरी बदलाव" किए जा रहे हैं. हां, इनमें से एक नैटिव था, लेकिन यह सिर्फ़ एक वजह नहीं थी. हमारा मकसद, नेटिव के साथ-साथ अन्य मुख्य इस्तेमाल के उदाहरणों के लिए, नेटवर्क को तैयार करने के लिए ज़्यादा समय देना था. |
Shared Storage API
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| परफ़ॉर्मेंस | ऐसा लगता है कि वर्कलेट के बाहर, Shared Storage में मौजूद फ़ाइलों को वापस लाने में लगने वाला समय, वर्कलेट में की गई गतिविधि पर निर्भर करता है. | हम इस टेस्ट के नतीजे के बारे में यहां बात कर रहे हैं. |
| ज़्यादा से ज़्यादा लोगों का इस्तेमाल करना | शेयर किया गया स्टोरेज, पूरे इंडस्ट्री में एक स्टैंडर्ड होना चाहिए और सभी ब्राउज़र पर उपलब्ध होना चाहिए. | हमें आपका सुझाव मिला है. Chrome, WICG के साथ-साथ W3C के फ़ोरम में लगातार हिस्सा ले रहा है. इससे, इस प्रस्ताव को आगे बढ़ाने, सुझाव पाने, और इसे अपनाने में मदद मिलती है. |
| बिडिंग वर्कलेट | क्या क्रॉस-साइट की जानकारी के आधार पर विज्ञापन दिखाने का फ़ैसला लेने / कारोबारी लॉजिक (जैसे, फ़्रीक्वेंसी कैपिंग) लागू करने और विज्ञापनों का सबसेट चुनने के लिए, generateBid (जो पहले से ही वर्कलेट में चल रहा है) में मौजूद शेयर किए गए स्टोरेज से पढ़ा जा सकता है? | नहीं, बिडिंग वर्कलेट में शेयर किए गए स्टोरेज से डेटा नहीं पढ़ा जा सकता. |
सीएचआईपीएस
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| पार्टीशन की क्षमता | बताएं कि पार्टीशन की क्षमता से ज़्यादा डेटा होने पर क्या होगा. | तय सीमा पूरी होने पर, सबसे पुरानी कुकी को मेमोरी खाली करने के लिए, हाल ही में ऐक्सेस की गई कुकी से हटा दिया जाता है. ऐसा तब तक किया जाता है, जब तक कि तय सीमा से ज़्यादा कुकी सेव न हो जाएं. डेवलपर को बाद के अनुरोधों में, अपडेट किया गया कुकी हेडर दिखता है. |
| तीसरे पक्ष के iFrame का ऐक्सेस | तीसरे पक्ष की उसी साइट पर नया टैब/विंडो खोलने वाले एम्बेड किए गए तीसरे पक्ष के iFrame कॉन्टेंट के पास, उसी तरह से बांटी गई कुकी का ऐक्सेस होना चाहिए जिस तरह से ओपनर के पास है. | हम इस इस्तेमाल के उदाहरण पर चर्चा कर रहे हैं. साथ ही, यहां नेटवर्क से जुड़े लोगों के सुझाव, राय या शिकायतें भी स्वीकार कर रहे हैं. |
| डुप्लीकेट कुकी | अगर एक ही नाम वाली एक सेगमेंट वाली कुकी और एक सेगमेंट नहीं वाली कुकी मौजूद है, तो ब्राउज़र किस कुंजी की वैल्यू भेजेगा? | एक ही नाम की दो कुकी (एक को अलग किया गया है और एक को नहीं) होने पर, आपको दोनों कुकी मिल जाएंगी – माफ़ करें, इनमें से किसी एक को अलग करने का कोई तरीका नहीं है. इस बारे में आरएफ़सी स्पेसिफ़िकेशन यहां उपलब्ध है. इसमें बताया गया है कि कुकी भेजने के क्रम पर भरोसा नहीं किया जाना चाहिए. |
| सुविधा का अनुरोध | ऑरिजिन पार्टिशन वाली कुकी के लिए ऑप्ट इन करें. | हम इस अनुरोध पर विचार कर रहे हैं. साथ ही, हम इकोसिस्टम से यहां और सुझाव, राय या शिकायतें पाने के लिए तैयार हैं. |
FedCM
इस तिमाही में कोई सुझाव, राय या शिकायत नहीं मिली.
स्पैम और धोखाधड़ी को रोकना
Private State Token API (और अन्य एपीआई)
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| वेबव्यू | क्या प्राइवेट स्टेट टोकन (पीएसटी), एक ही मोबाइल डिवाइस (प्रोफ़ाइल) पर मौजूद कई वेबव्यू में सेव रहते हैं? | वेबव्यू का इस्तेमाल करने वाले हर ऐप्लिकेशन का अलग-अलग लोकल स्टोरेज होगा. इसका मतलब है कि पीएसटी जारी करने वाले, किसी एक ऐप्लिकेशन के वेबव्यू में टोकन जारी नहीं कर सकते और फिर बाद में किसी दूसरे ऐप्लिकेशन में टोकन रिडीम करने की अनुमति नहीं दे सकते. यह वेबव्यू पर स्थानीय तौर पर सेव किए गए अन्य डेटा के लिए भी सही है, जैसे कि कुकी. फ़िलहाल, वेबव्यू में पीएसटी पूरी तरह से उपलब्ध नहीं हैं. हमें उम्मीद है कि हम इस बारे में दूसरी तिमाही के आखिर तक अपडेट देंगे. |
| नया टोकन टाइप | नए टोकन टाइप का प्रस्ताव. | हम इस प्रस्ताव के लिए आपका धन्यवाद करते हैं. साथ ही, हम पीएसटी के इस्तेमाल और उनके अनुकूल होने के बारे में लगातार खोज कर रहे हैं. हमें उम्मीद है कि साल 2024 की दूसरी तिमाही में होने वाली धोखाधड़ी रोकने के लिए बनी कम्यूनिटी ग्रुप की मीटिंग में, इस प्रस्ताव के बारे में ज़्यादा जानकारी मिलेगी. |
| उपयोगकर्ता की पहचान | उपयोगकर्ता के पास मौजूद किसी खास पीएसटी के आधार पर, उपयोगकर्ताओं की पहचान को कैसे रोका जा सकता है? | फ़िलहाल, किसी साइट पर रिडीम करने की कोशिशों को दो जारीकर्ताओं तक सीमित करके, इस समस्या को कम किया जा रहा है. भले ही, उस जारीकर्ता के पास टोकन उपलब्ध हों या नहीं. आपको जारीकर्ता की संख्या को तय सीमा के हिसाब से गिनना होगा. भले ही, टोकन उपलब्ध न हों, क्योंकि ऐसा न करने पर साइट सभी जारीकर्ताओं को तब तक दोहरा सकती है, जब तक कि कोई मैच न मिल जाए. |
| रजिस्ट्रेशन | पीएसटी के लिए रजिस्ट्रेशन कब तक ज़रूरी होगा? | आने वाले समय में भी रजिस्ट्रेशन करना ज़रूरी रहेगा. इस बारे में ज़्यादा जानकारी यहां दी गई है. |
| Chromium के दूसरे ब्राउज़र के लिए सहायता | क्या Chrome जारी करने वाले के रजिस्ट्रेशन के रिपॉज़िटरी की मदद से, Chromium पर आधारित अन्य ब्राउज़र के लिए, पीएसटी जारी करने वाले के तौर पर रजिस्टर करने की सुविधा काम करेगी? | Chrome, ज़रूरी जवाबों को फ़ेच करता है और उन्हें कॉम्पोनेंट अपेडटर नाम की प्रोसेस के ज़रिए Chrome क्लाइंट को डिस्ट्रिब्यूट करता है. अन्य ब्राउज़र, एपीआई के लिए ज़्यादा बेहतर सहायता जोड़ रहे हैं. इसलिए, उन्हें क्लाइंट से अहम वादे पाने के लिए, कॉम्पोनेंट अपडेटर-स्टाइल के तरीके या किसी अन्य तरीके से एक प्रोसेस तय करनी होगी. इस बारे में ज़्यादा जानकारी यहां दी गई है. |