साल 2024 की दूसरी और तीसरी तिमाही की तिमाही रिपोर्ट, जिसमें Privacy Sandbox के प्रस्तावों और Chrome के जवाब पर, नेटवर्क से मिले सुझाव, शिकायत या राय के बारे में खास जानकारी दी गई है.
सीएमए के साथ किए गए अपने वादे के तहत, Google ने अपने निजता सैंडबॉक्स के प्रस्तावों के लिए, हिस्सेदारों के साथ जुड़ाव की प्रोसेस के बारे में सार्वजनिक तौर पर हर तीन महीने की रिपोर्ट देने पर सहमति दी है. समझौते के पैराग्राफ़ 12 और 17(c)(ii) देखें. Google ने 22 जुलाई, 2024 को एलान किया था कि वह Chrome पर तीसरे पक्ष की कुकी (3PCs) का इस्तेमाल बंद नहीं करेगा. इसके बजाय, उसने उपयोगकर्ताओं को ज़्यादा विकल्प देने के लिए, एक नया तरीका अपनाने का सुझाव दिया था. इसलिए, सीएमए के समझौते के तहत, Google ने सीएमए को 2024 की दूसरी तिमाही की सार्वजनिक रिपोर्ट सबमिट नहीं की. इससे Google और सीएमए को, Google के एलान के असर पर विचार करने के लिए ज़रूरत के मुताबिक समय मिल सकेगा.
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
- ऑरिजिन ट्रायल
- PAT API
- Protected Audience API (पहले इसे FLEDGE के नाम से जाना जाता था)
- PatCG
- निजी विज्ञापन टेक्नोलॉजी कम्यूनिटी ग्रुप
- आरपी
- भरोसा करने वाली पार्टी
- RWS
- मिलती-जुलती वेबसाइट के सेट (पहले इन्हें पहले पक्ष के सेट कहा जाता था)
- SSP
- सप्लाई-साइड प्लैटफ़ॉर्म
- टीईई
- ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट
- UA
- उपयोगकर्ता एजेंट स्ट्रिंग
- यूक्रेनियन रिव्निया
- User-Agent Client Hints
- W3C
- वर्ल्ड वाइड वेब कंसोर्टियम
- WIPB
- अनजान आईपी ब्लाइंडनेस
सामान्य सुझाव, राय या शिकायत, किसी खास एपीआई/टेक्नोलॉजी के लिए नहीं
| सुझाव की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| तीसरे पक्ष की कुकी का इस्तेमाल बंद होना (3PCD) | 3PCD के लिए Google की क्या योजनाएं हैं और डिजिटल विज्ञापन उद्योग पर लंबे समय में पड़ने वाले असर का आकलन करना चाहिए? | हम एक अपडेट किया गया तरीका सुझा रहे हैं, जो उपयोगकर्ता की पसंद को बढ़ावा देता है. जैसा कि यहां बताया गया है कि 3PC की सुविधा बंद करने के बजाय, हम Chrome में एक नया अनुभव लॉन्च करेंगे. इससे लोग अपनी वेब ब्राउज़िंग के दौरान सोच-समझकर विकल्प चुन पाएंगे और वे किसी भी समय अपनी पसंद में बदलाव कर सकेंगे. हम रेगुलेटर से इस नए तरीके के बारे में बातचीत कर रहे हैं. साथ ही, इसे लॉन्च करने से पहले इंडस्ट्री से जुड़े रहेंगे. |
| उपयोगकर्ता के लिए उपलब्ध | लोगों की पसंद से जुड़े एलान से, प्राइवसी सैंडबॉक्स के समाधानों को अपनाने में नेटवर्क की दिलचस्पी पर असर पड़ा है. उपयोगकर्ता की पसंद से जुड़े एलान को लेकर मिले-जुले सुझाव मिले हैं. इसमें निगरानी करने की क्षमताओं जैसी सुविधाओं के अनुरोध भी शामिल हैं. | उपयोगकर्ताओं को उनकी पसंद के मुताबिक विकल्प देने के लिए, डेवलपर के लिए क्रॉस-साइट आइडेंटिफ़ायर के बजाय, निजता को बेहतर बनाने वाले विकल्प उपलब्ध कराना ज़रूरी है. नया अनुभव कैसा दिखेगा, इस बारे में बताने के लिए हमारे पास अभी जानकारी नहीं है. हालांकि, हमें उम्मीद है कि Chrome में बिना कुकी वाले ट्रैफ़िक में काफ़ी बढ़ोतरी होगी. इसका मतलब है कि Privacy Sandbox के एपीआई, कारोबारों के लिए अहम बने रहेंगे. हम निजता और उपयोगिता को बेहतर बनाने के लिए, Privacy Sandbox टेक्नोलॉजी में लगातार काम करते रहेंगे. |
| लोगों की पसंद का यूज़र इंटरफ़ेस (यूआई) | ऑप्ट-आउट/सहमति की सुविधाओं की टाइमलाइन, उपयोगकर्ता के लिए किस तरह के विकल्प पर विचार किया जा रहा है, और यूज़र इंटरफ़ेस (यूआई) का ऑटोमेटेड टेस्टिंग एनवायरमेंट पर क्या असर पड़ेगा, इस बारे में सवाल. | फ़िलहाल, हमारे पास टाइमलाइन से जुड़े कोई अपडेट शेयर करने के लिए नहीं है. 3PCD को आगे नहीं बढ़ाने का फ़ैसला लेने के बाद, हमने ईकोसिस्टम को जल्द से जल्द इस बारे में अपडेट देना चाहा. उपयोगकर्ताओं को उनके हिसाब से विकल्प देने के लिए, टाइमलाइन से जुड़ा अपडेट मिलते ही हम उसे शेयर करेंगे. |
| Chrome की टेस्टिंग | साल 2024 की पहली छमाही के बाद, 3PCD के मार्केट में अपनाए जाने और आर्थिक असर को मेज़र करने के लिए, Chrome की मदद से टेस्टिंग लेबल की उपलब्धता जारी रखने का अनुरोध. | हम जानते हैं कि टेस्टर, टेस्टिंग और कोऑर्डिनेशन के लिए, लेबल किए गए ब्राउज़र ग्रुप का इस्तेमाल करना जारी रखना चाहेंगे. भले ही, Chrome की मदद से की जाने वाली टेस्टिंग, 2024 की पहली छमाही में खत्म हो गई हो. हम उपयोगकर्ताओं को दी जाने वाली पसंद के बारे में एलान के आधार पर, लेबल के लिए अगले चरणों का आकलन कर रहे हैं. इस दौरान, Chrome टीम ने लेबल किए गए ब्राउज़र ग्रुप के लिए, सहायता बढ़ाने का अनुरोध पब्लिश किया है. यह अनुरोध, जनवरी 2025 तक चलने वाले Chrome माइलस्टोन 132 के ज़रिए किया गया है. |
| Android पर प्राइवसी सैंडबॉक्स | Android और Chrome पर मौजूद Privacy Sandbox एक-दूसरे से जुड़े हुए हैं. इसलिए, Android के बिना Privacy Sandbox का सही तरीके से आकलन नहीं किया जा सकता. ग्राहक के सामान्य सफ़र में, अलग-अलग डिवाइसों और कई टच वाले पहलू शामिल होते हैं. यह Chrome पर Privacy Sandbox और Android पर Privacy Sandbox, दोनों के लिए ज़रूरी है. | कृपया ध्यान दें कि Android पर प्राइवसी सैंडबॉक्स, सीएमए के लिए Google की प्रतिबद्धताओं के दायरे में नहीं आता. अगर सुझाव, खास तौर पर Android की टाइमलाइन और रोल आउट के बारे में हैं, तो फ़िलहाल हमारे पास शेयर करने के लिए कोई अपडेट नहीं है. हालांकि, Android पर हम लगातार काम कर रहे हैं. निजता को बेहतर बनाने के लिए, हम स्वतंत्र वर्कस्ट्रीम मानते हैं. जैसा कि हमने पहले बताया था, Android पर Privacy Sandbox API की उपलब्धता इस बात पर भी निर्भर करेगी कि उपयोगकर्ता अपने डिवाइसों को किस दर से अपडेट करते हैं. यह दर, Google के कंट्रोल में नहीं है. |
| मोड B ट्रैफ़िक सीमित | मोड B से मिलने वाला विज्ञापन नीलामी ट्रैफ़िक, उम्मीद से कम रहा है. | Protected Audience API (PA API) के लिए नीलामी की संख्या उम्मीद से कम होने की कई वजहें हो सकती हैं. उदाहरण के लिए: - हम जिन कंपनियों को जानते हैं कि पीए एपीआई को इंटिग्रेट करने वालों ने सिर्फ़ बैनर फ़ॉर्मैट शामिल किए हैं. - ऐसा ज़रूरी नहीं है कि सेल-साइड प्लैटफ़ॉर्म हमेशा नीलामी की शुरुआत करें. - हो सकता है कि ब्राउज़र में दिलचस्पी के हिसाब से बने ग्रुप (आईजी) न हों. - हो सकता है कि कोई बिड न हो. हालांकि, हमें किसी ऐसे व्यक्ति के बारे में नहीं पता है जिसने PA API की जांच करने की कोशिश की हो और उसे कोई ट्रैफ़िक न मिला हो. |
| आउटेज का दिखना | Privacy Sandbox API पर असर डालने वाली समस्याओं और रुकावटों के बारे में जानकारी. | Privacy Sandbox के उन एपीआई के लिए सार्वजनिक स्टेटस पेज है जिनकी सेवाएं ब्राउज़र के बाहर उपलब्ध हैं. Chrome की टीम, अपने प्लैटफ़ॉर्म और वेब पर मौजूद सभी मुख्य साइटों और सेवाओं के लिए इस्तेमाल किए जाने वाले सभी ज़रूरी एपीआई की भरोसेमंदता को सबसे ज़्यादा अहमियत देती है. इनमें Privacy Sandbox टेक्नोलॉजी भी शामिल हैं. अब तक सिर्फ़ एक बार रुकावट आई है. यह समस्या, 1% पर टेस्ट करने के लिए, कुछ समय के लिए लागू किए गए कॉन्फ़िगरेशन से जुड़ी थी. जल्द ही, इस रुकावट में शामिल एक्सपेरिमेंटल कॉन्फ़िगरेशन की ज़रूरत नहीं होगी. इसलिए, हमें भरोसा है कि Chrome में एपीआई को सामान्य तरीके से चालू करने के बाद, यह समस्या नहीं होगी. |
| कुकी ग्राफ़ की स्टडी | Privacy Sandbox फ़्रेमवर्क में इस पेपर में बताए गए CookieGraph तरीके के बारे में Chrome का क्या नज़रिया है? | इस पेपर में, उपयोगकर्ता के विज़िट किए गए डोमेन से अलग डोमेन से सेट की गई, पहले पक्ष (1P) की कुकी का पता लगाने और उनकी संख्या के बारे में कुछ दिलचस्प बातें बताई गई हैं. पेपर में बताया गया है कि ये कुकी, वेबसाइट के साथ उपयोगकर्ताओं के इंटरैक्शन के आंकड़े और जानकारी इकट्ठा करने के लिए काफ़ी काम की हैं. उपयोगकर्ताओं को बेहतर ब्राउज़िंग अनुभव देने के लिए, डेवलपर के लिए यह डेटा ज़रूरी है. पेपर में दिया गया मुख्य तर्क गलत है, क्योंकि इसमें 1P कुकी को क्रॉस-साइट ट्रैकिंग वेक्टर माना गया है. हालांकि, यह सिर्फ़ पेपर में बताई गई बहुत ही आक्रामक मान्यताओं के तहत सही है:
ध्यान दें कि ये फिर से पहचान करने वाले वेक्टर हैं. इनका इस्तेमाल, पहले पक्ष की कुकी के बिना किया जा सकता है. उदाहरण के लिए, सर्वर-साइड डेटा शेयर करने की सुविधा की मदद से. साथ ही, इन वेक्टर को हमारे मौजूदा प्रयासों से अलग तरीके से ठीक करना होगा. हमारा मौजूदा प्रयास, 3पीसी जैसे स्टेटस पर आधारित ट्रैकिंग मेकेनिज्म पर फ़ोकस करता है. आखिर में, हम यह बताना चाहते हैं कि पेपर में, आंकड़े और विज्ञापन कुकी को ट्रैकिंग कुकी के बराबर और ज़रूरी कुकी को नॉन-ट्रैकिंग कुकी के बराबर बताया गया है. हालांकि, ऐसा ज़रूरी नहीं है. दरअसल, पहले पक्ष के आंकड़े या स्टोर लोकेटर विजेट, चैट विजेट या लोड बैलेंसर कुकी जैसी पार्टिशन-टू-साइट वेंडर सेवाएं, अक्सर सिर्फ़ एक डोमेन तक सीमित हो सकती हैं. इसके उलट, धोखाधड़ी रोकने के मकसद से कुछ ज़रूरी कुकी क्रॉस-साइट ट्रैकिंग का काम कर सकती हैं. |
| उपयोगकर्ता अनुभव में बदलाव | Chrome 112 में यूज़र एक्सपीरियंस (यूएक्स) में हुए बदलावों की वजह से, 1P कुकी कंट्रोल को Chrome की सेटिंग के 'डिवाइस पर मौजूद साइट डेटा' सेक्शन में रखा गया है. इससे, उपयोगकर्ताओं के लिए सभी कुकी को ब्लॉक करना मुश्किल हो सकता है. | यह बदलाव, साइट के अन्य सभी तरह के डेटा से 3PC (या बिना बंटे हुए स्टोरेज) के कंट्रोल को अलग करने और बेहतर बनाने के लिए किया गया था. 3PC कंट्रोल को निजता और सुरक्षा पैनल में ले जाया गया है. वहीं, 1P कुकी और साइट के अन्य सभी तरह के डेटा के कंट्रोल, "डिवाइस पर मौजूद साइट डेटा" में बंडल किए गए हैं. साइट के मुख्य फ़ंक्शन आम तौर पर इन पर निर्भर होते हैं. हम इस विषय पर सुझाव पाना जारी रखेंगे. हालांकि, हमारा मानना है कि निजता सेटिंग को अलग-अलग करने की मौजूदा प्रोसेस, निजता सेटिंग को खोजने लायक बनाने और काम करने वाले ब्राउज़िंग अनुभव को बेहतर बनाने में मदद करती है. |
| बिलिंग और पेमेंट | बिलिंग और पेमेंट की पूरी तरह से जांच नहीं की जा रही है, क्योंकि टेस्टर Privacy Sandbox APIs के दूसरे हिस्सों की जांच में ज़्यादा दिलचस्पी रखते हैं. | डेवलपर और कंपनियां यह तय करती हैं कि उन्हें कब और क्या टेस्ट करना है. एपीआई, आम तौर पर टेस्टिंग के लिए उपलब्ध होते हैं. ये सितंबर 2023 से उपलब्ध हैं. |
| टेस्ट करना | एसएसपी से डीएसपी को मिलने वाले सभी एक्सपेरिमेंटल ट्रैफ़िक को लेबल नहीं किया जाता. कुछ डीएसपी ने सबमिट किया है कि एक्सपेरिमेंटल इंप्रेशन का वह हिस्सा जो लेबल नहीं किया गया है, वह ट्रीटमेंट और कंट्रोल ग्रुप में अलग-अलग हो सकता है. | Chrome यह कंट्रोल नहीं कर सकता कि कंपनियां बिड रिक्वेस्ट में लेबल फ़ॉरवर्ड करें या नहीं. हम ब्राउज़र से लेबल पाने का तरीका बताते हैं. अगर पार्टनर के पास इन लेबल को सीधे तौर पर पढ़ने की अनुमति नहीं है, तो पार्टनर को लेबल भेजने की ज़िम्मेदारी नेटवर्क के पास होती है. |
| Android वेबव्यू पर 3PCD | तीसरे पक्ष की कुकी के इस्तेमाल को रोकने की सुविधा की जांच करने के लिए, Android वेबव्यू में "तीसरे पक्ष की कुकी के फ़ेज़आउट की जांच करें" फ़्लैग को चालू करने के बारे में दिशा-निर्देश पाने का अनुरोध. | Android वेबव्यू में, 3PC डिफ़ॉल्ट रूप से ब्लॉक होते हैं. |
| मॉडल ट्रेनिंग में जोखिमों को कम करने के लिए, डिफ़रेंशियल प्राइवसी | मॉडल ट्रेनिंग में डिफ़रेंशियल प्राइवसी का इस्तेमाल क्यों किया जाता है? | डेटा लीक होने से रोकने और संवेदनशील जानकारी को खतरों से सुरक्षित रखने के लिए, मॉडल को ट्रेनिंग देने के दौरान अलग-अलग निजता का इस्तेमाल करना ज़रूरी है. इसके लिए, ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) का इस्तेमाल किया जाता है. इस तरीके से यह पक्का होता है कि मॉडल के वेट से अलग-अलग उपयोगकर्ता का डेटा नहीं दिखाया जा सकता. |
रजिस्ट्रेशन और प्रमाणित करना
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| रजिस्ट्रेशन | इस बारे में जानकारी देने का अनुरोध है कि रजिस्टर किए गए ऑरिजिन और www सबडोमेन वाले विज्ञापन टेक्नोलॉजी के ऑरिजिन के बीच, पुष्टि करने की प्रोसेस कैसे काम करती है. | विज्ञापन टेक्नोलॉजी को सिर्फ़ https://example.com पर शामिल करना होगा. जब वे https://example.com/.well-known/privacy-sandbox-attestations.json में अपना सर्टिफ़िकेट देते हैं, तब https://www.example.com को शामिल कर लिया जाता है, क्योंकि यह एक सबडोमेन है. |
| एपीआई स्पेसिफ़िकेशन | सुझाव: पुष्टि करने वाली फ़ाइल के लिए, JSON स्कीमा को रिपॉज़िटरी में जोड़ें. | हम इस सुझाव की समीक्षा कर रहे हैं. अगर आपका कोई और सुझाव है, तो यहां बताएं. |
काम का कॉन्टेंट और विज्ञापन दिखाना
विषय
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| विषयों को तय प्राथमिकता देना | Topics में सबसे अहम बात यह समझना है कि किसी सिग्नल की संख्या कितनी है. मौजूदा डिज़ाइन को बेहतर बनाया जाना चाहिए, ताकि निगरानी में रखे गए हर विषय के बगल में, अहमियत की वैल्यू जोड़ी जा सके. किसी ब्राउज़र के लिए किसी विषय का वज़न, उस विषय का तुलनात्मक वज़न होता है. यह वज़न, उस विषय का तुलनात्मक वज़न होता है जिसे सभी ब्राउज़र इस्तेमाल करते हैं. | हम इस बारे में ज़्यादा जानना चाहते हैं कि किसी सिग्नल के दुर्लभ होने की वजह से, उसे सबसे ज़्यादा अहम सिग्नल क्यों माना जाता है. इस इस्तेमाल के उदाहरण के फ़ायदों के बारे में, यहां नेटवर्क से जुड़े लोगों के सुझाव, राय या शिकायतें हमें भेजें. |
| विषयों की भरोसेमंदता | Google को समय के साथ, Topics की भरोसेमंदता के बारे में ज़्यादा भरोसेमंद जानकारी देनी होगी. | हमारे एपीआई में, नेटवर्क से जुड़े सुझाव, शिकायत या राय के आधार पर बदलाव होते रहेंगे. साथ ही, बदलावों से पहले इस बारे में सार्वजनिक तौर पर चर्चा की जाएगी. नए गवर्नेंस स्ट्रक्चर के लिए हमारा प्रस्ताव, आपको और भी भरोसा दिलाएगा. |
| डेटा की कैटगरी तय करने वाला | प्रकाशक की साइटों को अक्सर गलत तरीके से कैटगरी में डाल दिया जाता है या उनके विषय इतने ऊंचे लेवल की असाइन किए जाते हैं कि किसी भी अहम मकसद को पूरा नहीं किया जा सकता. | जैसा कि विषयों की कैटगरी तय करने के बारे में ज़्यादा जानकारी देने वाले हमारे पेज में बताया गया है, साइटों की कैटगरी तय करने के लिए, साइटों की अलग-अलग कैटगरी बनाई जाती है. इन सूची में, सबसे ज़्यादा लोकप्रिय साइटें और डिवाइस पर मौजूद मशीन लर्निंग मॉडल शामिल होते हैं. Chrome, विषयों के लिए अलग-अलग कैटगरी तय करने में मदद करने के लिए, साइटों के विकल्पों का आकलन करता रहता है. किसी भी सुविधा में सुधार करने से पहले, निजता और गलत इस्तेमाल से जुड़े जोखिमों को ध्यान में रखना ज़रूरी है. उदाहरण के लिए, कुछ जोखिमों में ये शामिल हैं: - अलग-अलग (और संवेदनशील) मतलब को विषयों में कोड में बदलने के लिए, खुद को लेबल करने वाले तरीके का इस्तेमाल करने वाली साइटें; और - दूसरों के लिए विषयों की उपयोगिता को कम करने के लिए, उन पर हमला करने वाली साइटें (उदाहरण के लिए, उपयोगकर्ता के विषयों में बेमतलब की बातों को स्पैम करना). आम लोग इन कॉम्पोनेंट की जांच कर सकते हैं. इसके लिए, chrome://topics-internals या इस कोलैब का इस्तेमाल करके उपलब्ध टूल इस्तेमाल किए जा सकते हैं. हमें उम्मीद है कि टेस्टिंग की मदद से, समय के साथ कैटगरी तय करने की प्रोसेस बेहतर होगी. साथ ही, हम उन साइटों के उदाहरणों के सुझावों का स्वागत करते हैं जिन्हें गलत कैटगरी में रखा गया हो. |
| एपीआई से जुड़ा सवाल | Topics API, खराब कॉन्टेंट से कमाई करने वाले एसएसपी को लगातार और प्रतिस्पर्धी फ़ायदे देता है. | 3PC की तरह ही, ब्राउज़र इस बात से कोई फ़र्क़ नहीं करता कि वह Topics को किसके पास भेजता है. हालांकि, यह ज़रूरी है कि वह इकाई रजिस्टर की गई हो और उसकी पुष्टि की गई हो. |
| (पिछली तिमाहियों में भी रिपोर्ट की गई) अलग-अलग तरह के हितधारकों के लिए काम की जानकारी |
फ़िलहाल, विषयों को अलग-अलग करने वाला टूल, पेज के होस्टनेम का इस्तेमाल करके विषयों की जानकारी देता है. इसलिए, अलग-अलग तरह के कॉन्टेंट वाली बड़ी साइटें सामान्य विषयों को शामिल करती हैं, जबकि छोटी साइटें विज्ञापन के लिहाज़ से ज़्यादा अहम विषयों को शामिल करती हैं. | हमारा जवाब पिछली तिमाहियों के जवाब से मिलता-जुलता है: तीन पीसी की तरह, अलग-अलग साइटों से मिली जानकारी की वैल्यू में अंतर होता है. खास विषयों पर बनी साइटों की वैल्यू में अंतर होता है: खास विषयों पर बनी सभी साइटों में व्यावसायिक तौर पर अहम कॉन्टेक्स्ट नहीं होता. इसलिए, इन साइटों की वैल्यू कम होती है. ये ऐसी साइटें हैं जिन्हें Topics API से फ़ायदा मिलेगा. हमने साइट-लेवल के बजाय पेज-लेवल पर कैटगरी तय करने की संभावना पर विचार किया है. हालांकि, इस तरह के कैटगरी तय करने से निजता और सुरक्षा से जुड़ी कई अहम समस्याएं आ सकती हैं. |
| डेटा की कैटगरी तय करने वाला | छोटी साइटों को अक्सर गलत क्लासिफ़िकेशन असाइन किया जाता है या कोई क्लासिफ़िकेशन नहीं किया जाता. इसलिए, वे वैल्यू एक्सचेंज में हिस्सा नहीं ले सकतीं. | नुकसान के दावे के बारे में, जिन साइटों को गलत कैटगरी में रखा गया है उन्हें अन्य साइटों की तुलना में ज़्यादा नुकसान नहीं होता. इसकी वजह यह है कि किसी साइट की कॉन्टेक्स्ट से जुड़ी जानकारी, उसकी नीलामियों के लिए हमेशा उपलब्ध रहेगी. इससे, गलत कैटगरी में रखे जाने के बावजूद, सही विषय के बारे में तुलना की जा सकने वाली जानकारी मिलती रहेगी. आम तौर पर, विषयों का इस्तेमाल अपनी साइटों के बजाय, बाहरी वेबसाइटों से विज्ञापन से जुड़ी काम की जानकारी इकट्ठा करने के लिए किया जाता है. |
| टैक्सनॉमी का वर्शन | पुराने सिस्टम के साथ काम करने की सुविधा को पक्का करने के लिए, हम टेक्सॉनमी वर्शन को कैसे ऐक्सेस करें? | टेक्सॉनमी वर्शन, अनुरोध के हेडर का हिस्सा होता है. इसे विषयों की सुविधा वाले फ़ेच अनुरोध के साथ भेजा जाता है. उदाहरण के लिए, अगर हेडर "(1 2);v=chrome.1:2:5, ();p=P000000000" है, तो वर्शन chrome.1:1:2 है. यहां chrome.1, कॉन्फ़िगरेशन वर्शन है, 2 टैक्सोनॉमी वर्शन है, और 5 मॉडल वर्शन है. इसके बारे में स्पेसिफ़िकेशन में बताया गया है. साथ ही, इसे एक्सप्लेनर में भी जोड़ा गया है. |
| विषयों का डेटा | Topics का डेटा अपडेट करने के तरीके के बारे में जानकारी पाने का अनुरोध. | टैक्सोनॉमी के अपडेट के बारे में जानकारी नहीं दी गई है. इससे ब्राउज़र वेंडर को उन्हें लागू करने में आसानी होती है. हालांकि, Chrome के टैक्सोनॉमी को V1 से V2 में अपडेट करने के बारे में यहां बताया गया है: - V1 और V2, दोनों वर्शन के विषयों के लिए एक ही टैक्सोनॉमी ट्री बनाए रखा जाता है. - एक ही विषय आईडी का मतलब एक ही होता है. - ट्री सिर्फ़ बड़ा होता है – इसमें नए विषय या कनेक्शन जोड़े जाते हैं, कभी छोटा नहीं होता. - हालांकि, किसी वर्शन में कुछ विषय या लिंक "इनऐक्टिव" हो सकते हैं. इससे ऐसा लग सकता है कि उन्हें मिटा दिया गया है या उनका क्रम बदल दिया गया है. उदाहरण: - "पिकअप ट्रक" को अब "ट्रक, वैन, और एसयूवी" के तौर पर इंटरमीडिएट पैरंटल के तौर पर सेट कर दिया गया है. - "विदेशी भाषा सीखना" के लिए, अब "शिक्षा" को दूसरा पैरंट बनाया गया है. साथ ही, इसका मूल पैरंट "रेफ़रंस" बंद हो गया है. "इनऐक्टिव" विषयों का असर: इन विषयों का इस्तेमाल, नए कैटगरी में बांटने के लिए नहीं किया जाएगा. हालांकि, उपयोगकर्ताओं को ब्लॉक करने से जुड़ी नीति को लागू करते समय इन सुविधाओं पर अब भी ध्यान दिया जाता है: अगर किसी उपयोगकर्ता ने वर्शन 1 में किसी विषय को ब्लॉक किया है, तो वर्शन 2 में चाइल्ड विषय ब्लॉक रहेगा. भले ही, वर्शन 2 में चाइल्ड विषय किसी दूसरे पैरंट से जुड़ा हो. |
| डेटा की कैटगरी तय करने वाला | गलत कैटगरी के लिए, वजहों और सुधार के विकल्पों को समझना. | सबसे पहले, हम आपको बताना चाहते हैं कि Chrome किसी साइट के विषयों का पता लगाता है, ताकि वह Topics के एल्गोरिदम में इनपुट के तौर पर इसका इस्तेमाल कर सके. इससे, विज्ञापन दिखाने के लिए उपयोगकर्ता की दिलचस्पी का पता लगाया जा सकता है. इसे अन्य सामान्य कैटगरी के लिए नहीं बनाया गया है. हम चाहते हैं कि हमारा क्लासिफ़िकेशन मॉडल कितना सटीक हो. हम इसे सटीक बनाने या इसे फिर से याद करने की कोशिश करना चाहते हैं. हालांकि, इसे पूरी दुनिया के लिए टारगेट करें, न कि हर साइट को अलग-अलग कैटगरी में बांटने के लेवल पर. ऐसा इसलिए होता है, क्योंकि गलत कैटगरी होने पर उस साइट को कोई नुकसान नहीं पहुंचता है जिसे गलत कैटगरी में रखा गया है. इसके बजाय, इससे दूसरी साइटों पर विज्ञापन चुनते समय विषयों के सिग्नल की क्वालिटी कम हो जाती है. गलत कैटगरी वाली साइट पर विज्ञापन चुनते समय, साइट के असली विषय पहले से ही साइट को पता होते हैं. इनका इस्तेमाल, विज्ञापन क्वेरी के इनपुट के तौर पर किया जा सकता है. अगर आपके पास कोई और सुझाव, शिकायत या राय है, तो यहां हमें बताएं. |
| एपीआई की जांच | क्या Topics और सामान्य तौर पर Privacy Sandbox API को Chromium के साथ टेस्ट किया जा सकता है? | Topics API, Chromium के साथ नहीं आता, बल्कि यह Chrome के साथ आता है. |
| Topics Caller | विज्ञापन टेक्नोलॉजी के लिए टीईई सेवाओं का इस्तेमाल करके, Topics की अतिरिक्त वैल्यू को बेहतर बनाने का अनुरोध. इससे निजता के नियमों का पालन करते हुए, बेहतर विश्लेषण की लागत को कम करने में मदद मिलेगी. | हमने इससे मिलते-जुलते सुझाव का जवाब यहां दिया है. हमने इनवर्स फ़्रीक्वेंसी का इस्तेमाल किया. इनवर्स फ़्रीक्वेंसी को मॉडल करने के बाद, हमें पता चला कि यह विषय की वैल्यू के हिसाब से सही नहीं है. यह वैल्यू, खरीदारों और सेलर की दी गई वैल्यू के हिसाब से होती है. हम यहां आपके और भी सुझाव, शिकायत या राय का स्वागत करते हैं. |
| एपीआई की खास बातें | क्या ब्राउज़र में दिलचस्पी के हिसाब से ग्रुप बनाने की सेटिंग, Topics API को ब्लॉक कर सकती है? | हमने इस सुझाव/राय/शिकायत का जवाब यहां दिया है. Topics API, FLoC का नया वर्शन है और यह FLoC की अनुमतियों से जुड़ी नीति का पालन करता है. एक्सप्लेनर में बताया गया है: "ध्यान दें: FLoC की पुरानी Permissions-Policy: interest-cohort=() से भी विषय का हिसाब लगाने पर पाबंदी लगेगी." |
| विषयों की रैंकिंग | 'सबसे ज़्यादा पूछे गए पांच विषय' की जानकारी पाने के लिए, क्या हम ज़रूरी शर्तें पूरी करने वाले हर कॉलर के आधार पर, वेबसाइट पर आने की फ़्रीक्वेंसी की गिनती करेंगे या हमेशा ब्राउज़र के पूरे विज़िटिंग इतिहास के आधार पर गिनती करेंगे? इसके अलावा, क्या हर कॉलर के लिए विषयों को अलग-अलग रैंक किया जाता है? | यह ब्राउज़िंग इतिहास के सबसेट की फ़्रीक्वेंसी पर आधारित है. ब्राउज़िंग इतिहास की एंट्री (पेज) सिर्फ़ तब दिखाई जा सकती है, जब पेज में कम से कम एक Topics कॉलर हो. विषयों के इतिहास के स्टोरेज के बारे में ज़्यादा जानकारी यहां उपलब्ध है. Topics API में किए गए सुधारों के बारे में एलान में बताया गया है कि रैंकिंग, फ़्रीक्वेंसी और प्राथमिकता के बाइनरी लेवल पर निर्भर करती है. ज़्यादा जानकारी के लिए, यहां और यहां जाएं. हालांकि, यह कॉल करने वालों की संख्या पर निर्भर नहीं करता. कृपया ध्यान दें कि इसका मतलब यह नहीं है कि सभी कॉलर को अगले एपिसोड में, टॉप पांच विषयों में से सभी विषय मिल सकते हैं. जैसा कि एक्सप्लेनर में बताया गया है, "सिर्फ़ ऐसे कॉल करने वाले लोग ही उस विषय को पा सकते हैं जिन्होंने पिछले तीन हफ़्तों में उपयोगकर्ता को उस विषय से जुड़ी साइट पर विज़िट किया था." ब्राउज़र को यह ट्रैक करना होगा कि किस कॉलर ने किन पांच विषयों को देखा. ये विषय, खास जानकारी में दिए गए कॉल करने वाले के डोमेन के साथ सबसे ज़्यादा देखे गए पांच विषय से मेल खाते हैं. इस समस्या के बारे में ज़्यादा जानकारी के लिए, यहां जाएं. |
Protected Audience API (पहले इसे FLEDGE के नाम से जाना जाता था)
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| (पिछली तिमाहियों में भी रिपोर्ट की गई) लागत |
क्या ऑन-प्राइमिस विज्ञापन टेक्नोलॉजी डेटा सेंटर के मुकाबले, सार्वजनिक क्लाउड में टीईई चलाना ज़्यादा महंगा है? | हमारे मौजूदा टीईई सुरक्षा मॉडल को, पब्लिक क्लाउड को लागू करने के तरीके का फ़ायदा मिलता है. ज़्यादा जानकारी के लिए, पब्लिक क्लाउड टीईई की ज़रूरी शर्तों के बारे में जानकारी देखें. उदाहरण के लिए, हार्डवेयर पर आधारित मौजूदा टीईई, सभी शारीरिक हमलों से बचाव नहीं करते हैं. हमारे मौजूदा सार्वजनिक क्लाउड सेवा देने वाली कंपनियों, AWS और GCP ने फ़िज़िकल ऐक्सेस से जुड़े जोखिमों को कम करने के लिए, सुरक्षा के उपाय डिज़ाइन किए हैं और उन्हें लागू किया है. इनमें कर्मचारियों से जुड़े जोखिम भी शामिल हैं. कुछ विज्ञापन टेक्नोलॉजी कंपनियों ने हमें बताया है कि क्लाउड सेवाएं चलाना, ऑन-प्राइमिस विज्ञापन टेक्नोलॉजी डेटा सेंटर से ज़्यादा महंगा है. हालांकि, अन्य विज्ञापन टेक्नोलॉजी कंपनियां, लागत या अन्य फ़ायदों के लिए सार्वजनिक क्लाउड पर काम करती हैं. हम टीईई के साथ काम करने की सुविधा को ज़्यादा से ज़्यादा लोगों तक पहुंचाने के लिए, अलग-अलग विकल्पों का आकलन करते रहते हैं. इसमें सार्वजनिक क्लाउड के अलावा, अन्य क्लाउड भी शामिल हैं. इसके तहत, हम ऑन-प्राइमिस डेटा सेंटर पर रिसर्च कर रहे हैं. साथ ही, इस तरह की सहायता देने के लिए संभावित समाधानों को एक्सप्लोर करने के लिए, नेटवर्क के साथ काम कर रहे हैं. रिसर्च के इस मौजूदा चरण में, हम इस बात की गारंटी नहीं दे सकते कि इससे, इकोसिस्टम के लिए कोई काम का समाधान निकलेगा. |
| PA API और Google Ad Manager (GAM) | GAM के लिए भी बाज़ार में सही नतीजा नहीं मिल पा रहा है. GAM समय पर विज्ञापन नहीं दिखा पाता, वह रिपोर्ट करता है कि PA API का इस्तेमाल करके कितने विज्ञापन दिखाए गए.साथ ही, इससे यह भी तय नहीं होता कि विज्ञापन दिखाने के लिए, कौनसा तरीका चुना जाएगा. जैसे, कुछ स्लॉट के लिए PA API बंद करना. | Google Ad Manager का जवाब: PA API के ज़रिए विज्ञापन दिखाते समय, GAM ने इंतज़ार का समय ऑप्टिमाइज़ करने पर काम किया है और अब भी कर रहा है. इससे, PA API की मांग से पब्लिशर को मिलने वाला अतिरिक्त रेवेन्यू, PA API की नीलामी में इंतज़ार के अतिरिक्त समय की वजह से होने वाली लागत से ज़्यादा हो जाता है. हमारी शुरुआती जांच से पता चलता है कि पब्लिशर को 3PC के बिना ट्रैफ़िक पर, PA API से कुल रेवेन्यू में फ़ायदा मिलता है. इससे पता चलता है कि PA API की अतिरिक्त मांग, इंतज़ार की अवधि की वजह से होने वाली किसी भी लागत से ज़्यादा है. हमारे तरीके के बारे में ज़्यादा जानकारी के लिए, अक्सर पूछे जाने वाले सवाल देखें. इसके अलावा, GAM पब्लिशर को PA API के ज़रिए दिखाए गए विज्ञापनों की रिपोर्टिंग भी उपलब्ध कराता है. इसमें ऐसे विज्ञापन शामिल हैं जो GAM के कॉम्पोनेंट सेलर के तौर पर दिखाए जाते हैं. साथ ही, ऐसे विज्ञापन भी शामिल हैं जो GAM के टॉप-लेवल सेलर के तौर पर, दूसरे कॉम्पोनेंट सेलर के ज़रिए दिखाए जाते हैं. शिकायत करने के बारे में ज़्यादा जानकारी के लिए, हमारे सहायता केंद्र पर जाएं. आखिर में, GAM पब्लिशर को यूज़र इंटरफ़ेस (यूआई) में मौजूद कंट्रोल की मदद से, अपने ट्रैफ़िक पर PA API के इस्तेमाल को चालू या बंद करने की अनुमति देता है. ज़्यादा जानकारी के लिए, हमारा सहायता केंद्र देखें. हम पब्लिशर की ओर से, अन्य कंट्रोल के सुझावों पर विचार करने के लिए तैयार हैं. साथ ही, हम सुविधाओं के लिए किए गए अनुरोधों को प्राथमिकता देंगे. ऐसा, सुविधाओं को प्राथमिकता देने की हमारी स्टैंडर्ड प्रोसेस के मुताबिक किया जाएगा. |
| PA API और GAM/AdX | ऐसा लगता है कि Google ने यह फ़ैसला लिया है कि वह ऐसे किसी भी PA API इंप्रेशन को नहीं खरीदेगा जिसे बेचने का फ़ैसला GAM नहीं करता. यह उसी तरह है जैसे AdWords सिर्फ़ अपने प्लैटफ़ॉर्म से खरीदारी करता है. यह पूरी तरह से बाज़ार में स्थिति का गलत इस्तेमाल माना जाता है, क्योंकि GAM/AdX किसी दूसरे एक्सचेंज की तरह किसी दूसरे टॉप-लेवल सेलर के लिए कॉम्पोनेंट नीलामी कॉन्फ़िगरेशन सबमिट कर सकता है. | Google Ads Platform के मैनेजर का जवाब: Google की यह राय नहीं है. Google के बायसाइड प्लैटफ़ॉर्म (Google Ads और DV360), Google से बाहर के एक्सचेंज से इंप्रेशन खरीदते हैं. यह, पीए एपीआई इंप्रेशन और नॉन-पीए एपीआई इंप्रेशन, दोनों के लिए सही है. |
| मार्केट रिस्पॉन्स | Mozilla की समस्याएं: Google के Protected Audience, विज्ञापन देने वालों (और Google) को आपकी सुरक्षा से कहीं ज़्यादा सुरक्षित रखता है. | हम Mozilla के मूल्यांकन की सराहना करते हैं और सार्वजनिक मानक फ़ोरम में Mozilla के फ़ीडबैक के साथ जुड़े रहेंगे. उनके आकलन की थीम यह है कि PA API के मौजूदा वर्शन में, सुरक्षा से जुड़ी सभी योजनाएं अभी लागू नहीं की गई हैं. PA API का इस्तेमाल करने के अपने लक्ष्य के मुताबिक, जल्द से जल्द निजता सुरक्षा को अपनाने और निजता सुरक्षा को लागू करने के लिए, सही संतुलन बनाने की कोशिश की गई है. इस प्रोसेस के तहत, हमने समय के साथ निजता से जुड़ी पाबंदियां लगाने के लिए एक रोडमैप बनाया है. इससे एपीआई के साथ इंटिग्रेशन को बेहतर बनाने में मदद मिलेगी. साथ ही, हमें ज़्यादा सुझाव, राय या शिकायतें इकट्ठा करने का समय मिलेगा. इन सुझावों, राय या शिकायतों को आने वाले समय में सुरक्षा से जुड़ी सुविधाओं में शामिल किया जा सकता है. जैसे, फ़ेंस किए गए फ़्रेम में VAST सुविधाएं. हम निजता और डिजिटल विज्ञापन के लिए, Mozilla के हाल ही के संचार का भी स्वागत करते हैं: "बिना किसी शुल्क के ओपन वेब उपलब्ध कराने की सुविधा, निजता की कीमत पर नहीं मिलनी चाहिए" और "प्रॉडक्ट और इन्फ़्रास्ट्रक्चर की मदद से, ऑनलाइन विज्ञापन को बेहतर बनाना". |
| (पिछली तिमाही में भी रिपोर्ट किए गए हैं) नीलामी के नतीजे |
किसी एक नीलामी के लिए, उनसे जुड़े स्कोर के साथ कई रेंडर यूआरएल वापस करने का अनुरोध करना. इससे नेटिव विज्ञापन के लिए, उपयोगकर्ता अनुभव और इंतज़ार के समय से जुड़ी समस्याओं से बचना आसान हो जाता है. साथ ही, इनकी डुप्लीकेट कॉपी को हटाना भी आसान हो जाता है. | हमने इस बारे में पिछली तिमाहियों जैसा ही जवाब दिया था: हमने PA API की एक ही नीलामी से जुड़े कई रेंडरयूआरएल और उनसे जुड़े स्कोर शेयर किए हैं. हालांकि, हमने निजता से जुड़ी समस्याओं की वजह से इसे लागू नहीं किया. हम समझते हैं कि आपको एक ही पेज पर किसी उपयोगकर्ता को एक ही विज्ञापन कई बार नहीं दिखाना है. हम इस अनुरोध की समीक्षा कर रहे हैं. नेटिव विज्ञापन के इस्तेमाल के उदाहरण को बेहतर तरीके से इस्तेमाल करने के लिए, PA API में किस तरह की अतिरिक्त सहायता की ज़रूरत है, इस बारे में यहां नेटवर्क से सुझाव, शिकायत या राय का स्वागत किया जाता है. |
| परफ़ॉर्मेंस | PA API पर इंतज़ार का असर. | हमें पता है कि आपको इंतज़ार का समय लंबा लग रहा है. इसलिए, हमने PA API के तहत कई सुविधाएं बनाई हैं. इनकी मदद से, एसएसपी, डीएसपी के इंतज़ार के समय की सीमा तय कर सकते हैं. साथ ही, ऐसे सुधार कर सकते हैं जिनसे इंतज़ार का समय कम हो. हमने हाल ही में, देरी से जुड़े सबसे सही तरीकों की गाइड को अपडेट किया है. इसमें इन सुविधाओं का फ़ायदा पाने के तरीके के बारे में ज़्यादा जानकारी दी गई है. हम इंतज़ार के समय को कम करने के लिए नए तरीके भी बना रहे हैं. इनमें से कुछ तरीकों के बारे में यहां बताया गया है. |
| टॉप लेवल के सेलर | Google को पब्लिशर को, टॉप-लेवल के अन्य PA API नीलामी सेलर चुनने की सुविधा देनी चाहिए. | PA API इस बात का ध्यान नहीं रखता कि वह एक सेलर और एक से ज़्यादा सेलर वाले डिज़ाइन, दोनों में नीलामी की शुरुआत करता है. अलग-अलग कंपनियां यह तय कर सकती हैं कि PA API नीलामियों का इस्तेमाल करना है या नहीं. साथ ही, अगर करना है, तो कैसे करना है. |
| (पिछली तिमाहियों में भी रिपोर्ट की गई) नेगेटिव टारगेटिंग |
इस्तेमाल के ऐसे उदाहरण के लिए अनुरोध करना जिसमें विज्ञापन देने वाला किसी खास ऑडियंस को अपने विज्ञापन नहीं दिखाना चाहता. | हम अतिरिक्त (संदर्भ के हिसाब से) बिड के ज़रिए नेगेटिव IG टारगेटिंग की सुविधा देते हैं. इससे, विज्ञापन देने वाले लोग या कंपनियां कुछ ऑडियंस को विज्ञापन नहीं दिखाना चाहती हैं. इसकी जानकारी, इस एक्सप्लेनर और GitHub पर मौजूद इस समस्या में देखी जा सकती है. हम PA API बिड के लिए, नेगेटिव इंस्टैग्राम टारगेटिंग की सुविधा देने के लिए भी समाधान ढूंढ रहे हैं. साथ ही, यहां हमें अपने सुझाव, शिकायत या राय भेजने में भी खुशी होगी. |
| (पिछली तिमाहियों में भी रिपोर्ट किया गया था) नेटिव विज्ञापन |
नेटिव विज्ञापन के लिए, फ़ेंस किए गए फ़्रेम की सुविधा के लिए अनुरोध करें. | हम इस इस्तेमाल के उदाहरण के लिए सहायता देने पर विचार कर रहे हैं. साथ ही, इस समस्या को हल करने के तरीकों और संभावित समाधानों के बारे में यहां चर्चा कर रहे हैं. |
| WebView | इस स्थिति के बारे में जानकारी चाहिए, जब Chrome पर शामिल किया गया IG, वेबव्यू पर की गई नीलामी के लिए उपलब्ध नहीं था. | निजता से जुड़ा ज़रूरी इंफ़्रास्ट्रक्चर उपलब्ध होने के बाद, हम इन इस्तेमाल के उदाहरणों को शामिल करना चाहते हैं. फ़िलहाल, हमारे पास कोई और एलान करने के लिए नहीं है. हालांकि, यहां हमें आपके सुझाव, राय या शिकायत मिल सकती है. |
| नेगेटिव आईजी | हेडर की नई सुविधा की मदद से, नेगेटिव आईजी को शामिल करने के लिए, यूआरएल प्रोसेसिंग को अपडेट करने का अनुरोध. | हम इस अनुरोध की समीक्षा कर रहे हैं. अगर आपके पास कोई और सुझाव या राय है, तो यहां बताएं. |
| विविधता के हिसाब से फ़िल्टर करना | एक से ज़्यादा सेलर और एक से ज़्यादा नीलामियों के साथ PA API में नेटिव विज्ञापन दिखाते समय, विविधता फ़िल्टर करने के तरीके के बारे में दिशा-निर्देश पाने का अनुरोध. | हम इस अनुरोध के बारे में यहां चर्चा कर रहे हैं. आपके अलावा कोई और सुझाव, शिकायत या राय देने के लिए भी हम आपका स्वागत करते हैं. |
| (पिछली तिमाहियों में भी इसकी शिकायत की गई थी) ब्लॉकिंग फ़िल्टर |
कई सेलर के साथ PA API में नेटिव विज्ञापन दिखाते समय, 'पब्लिशर ब्लॉकिंग' (फ़िल्टर) के नियमों को लागू करने के तरीके के बारे में दिशा-निर्देश का अनुरोध करना. | हमने यहां दिशा-निर्देश शेयर किए हैं. साथ ही, हम आपके सुझाव, राय या शिकायतों का स्वागत करते हैं. |
| पाबंदियां | सबडोमेन के लेवल के बजाय, डोमेन लेवल पर पाबंदियों की अनुमति देने का अनुरोध करें. | सबडोमेन या ऑरिजिन लेवल पर पाबंदियां, वेब के बुनियादी सुरक्षा मॉडल के मुताबिक होती हैं. इसलिए, यह हमारा डिफ़ॉल्ट डिज़ाइन है. इस बारे में ज़्यादा जानकारी के लिए, यहां और यहां जाएं. |
| भरोसेमंद बिडिंग | भरोसेमंद बिडिंग सिग्नल के अनुरोधों में, उपयोगकर्ता एजेंट और उससे जुड़े क्लाइंट के संकेतों के लिए अनुरोध. | हम इस सुविधा के अनुरोध पर नज़र बनाए हुए हैं. साथ ही, हमें इस बारे में और सुझाव, शिकायत या राय देने में खुशी होगी. |
| (पिछली तिमाहियों में भी रिपोर्ट की गई) एक से ज़्यादा आईजी |
एक ही बिड में कई आईजी का इस्तेमाल करें. | फ़िलहाल, PA API में ऐसा नहीं किया जा सकता, क्योंकि इससे निजता मॉडल में बदलाव होगा. हम इस बारे में ज़्यादा बातचीत करने के लिए, यहां आपका स्वागत करते हैं. |
| (पिछली तिमाहियों में भी रिपोर्ट की गई) परफ़ॉर्मेंस |
क्लाइंट में ज़्यादा लॉजिक जोड़ने से, पेज की परफ़ॉर्मेंस और यूज़र एक्सपीरियंस पर असर पड़ सकता है. इससे वेबसाइट के एसईओ स्कोर पर भी असर पड़ सकता है. | हम इस समस्या पर चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव, राय या शिकायत है, तो यहां बताएं. |
| नीलामी में होने वाले उतार-चढ़ाव | PA API, नीलामी की डाइनैमिक (जैसे, कौन हिस्सा लेता है, नीलामी में हर कॉम्पोनेंट कौन जीतता है वगैरह) की जानकारी को कम करता है. इससे पब्लिशर को ट्रैक करने में मुश्किल होती है और यह पता लगाना मुश्किल हो जाता है कि डील पूरी की जा रही हैं या नहीं. | हमने डील को ट्रैक करने का एक तरीका यहां बताया है. हमारी योजना है कि हम कुछ मौजूदा फ़ील्ड में बदलाव करें और IG ऑब्जेक्ट में कुछ नए फ़ील्ड बनाएं, ताकि DealID और SeatID को स्टोर किया जा सके. साथ ही, उन्हें generateBid से ScoreAd या Eडेंस में इवेंट-लेवल रिपोर्टिंग के ज़रिए लागू किया जा सके. इससे डील के इस्तेमाल के उदाहरण के लिए ज़रूरी सहायता मिलनी चाहिए. हम ऐसे दूसरे मेटाडेटा के सुझाव, राय या शिकायतों का स्वागत करते हैं जो विज्ञापन टेक्नोलॉजी के हिसाब से नीलामी की डाइनैमिक के लिए ज़रूरी हैं. साथ ही, हम पब्लिशर के लिए इस ट्रैसेबिलिटी को बनाए रखने के लिए भी सुझाव, राय या शिकायतें स्वीकार करते हैं. हमारा सुझाव है कि विज्ञापन टेक्नोलॉजी विशेषज्ञ, उस मेटाडेटा के खास उदाहरण दें जिसका वे रेफ़र कर रहे हैं. साथ ही, यह भी बताएं कि किस पार्टी से किस पार्टी को यह मेटाडेटा भेजना है. |
| GAM | AdX की मांग को ऐक्सेस करने के लिए, पब्लिशर के विज्ञापन सर्वर के तौर पर GAM का इस्तेमाल करने की ज़रूरत को लेकर चिंताएं. | Google Ad Manager का जवाब: GAM के लिए ज़रूरी नहीं है कि पब्लिशर, एक्सचेंज की सुविधा को ऐक्सेस करने के लिए, उसके विज्ञापन सर्वर की सुविधा का इस्तेमाल करें. |
| (पिछली तिमाहियों में भी रिपोर्ट की गई) कॉम्पोनेंट नीलामी |
PA API कॉम्पोनेंट की नीलामी में जीतने वाले लोग GAM को दिखेंगे. इससे, जानकारी के असमान ऐक्सेस को लेकर चिंता बढ़ती है. | हमारी पिछली तिमाहियों की तुलना में, हमारा जवाब अब भी पहले जैसा ही है: Google Ad Manager का जवाब: "हमने नीलामी को निष्पक्ष बनाने पर कई सालों से ध्यान दिया है. साथ ही, हमने यह वादा भी किया है कि नीलामी में बिड करने से पहले, पब्लिशर के किसी भी ऐसे विज्ञापन स्रोत की कीमत किसी दूसरे खरीदार के साथ शेयर नहीं की जाएगी जिसकी कोई गारंटी नहीं है. इसमें, लाइन आइटम की ऐसी कीमतें भी शामिल हैं जिनकी कोई गारंटी नहीं है. हमने बाद में, फ़्रेंच कॉम्पिटीशन अथॉरिटी के साथ किए गए अपने वादे में इस बात की पुष्टि की है. पीए एपीआई नीलामियों के लिए, हम अपना वादा निभाना चाहते हैं. साथ ही, मल्टी-सेलर नीलामियों में नीलामी पूरी होने से पहले, नीलामी में हिस्सा लेने वाले किसी भी व्यक्ति की बिड को किसी दूसरे व्यक्ति के साथ शेयर नहीं करेंगे. साफ़ तौर पर बता दें कि हम कॉन्टेक्स्ट ऑक्शन की कीमत को किसी भी कॉम्पोनेंट ऑक्शन के साथ शेयर नहीं करेंगे. इसमें हमारी ऑक्शन भी शामिल है. इस बारे में इस अपडेट में बताया गया है. इसके अलावा, हम अपनी नीलामी के हिस्से के तौर पर, कॉम्पोनेंट नीलामी कॉन्फ़िगरेशन की जानकारी का इस्तेमाल नहीं करते. इसमें, खरीदारों से एसएसपी को मिले सिग्नल भी शामिल हैं. असल में, हम PA API में ऐसे बदलावों का स्वागत करेंगे जिनसे कॉम्पोनेंट बेचने वाले, अपने कॉम्पोनेंट की नीलामी के कॉन्फ़िगरेशन को इस तरह से बता सकें कि टॉप लेवल सेलर को यह समझने में मुश्किल हो." |
| GAM | अगर GAM ने आईजी या पीए एपीआई कॉम्पोनेंट नीलामी में हिस्सा नहीं लिया है, तो क्या GAM, टॉप लेवल नीलामियों को चलाने/रिपोर्ट करने के लिए रेवेन्यू के बंटवारे का अनुरोध करेगा? | Google Ad Manager का जवाब: जब पब्लिशर अपने विज्ञापन सर्वर के तौर पर GAM का इस्तेमाल करना चुनते हैं, तो GAM टॉप-लेवल नीलामी चलाएगा और अपने विज्ञापन सर्वर की सुविधा के लिए विज्ञापन दिखाने का शुल्क लेगा. यह वही शुल्क है जो PA API नीलामियों के बाहर लागू होता है. हालांकि, अगर जीतने वाला विज्ञापन किसी गैर-GAM कॉम्पोनेंट सेलर का आता है - इसका मतलब है कि GAM ने आईजी या पीए एपीआई कॉम्पोनेंट नीलामी में हिस्सा नहीं लिया है, तो GAM न तो बिलिंग हैंडल करता है और न ही कोई प्रतिशत मीडिया शुल्क लेता है. |
| क्लिक करने की संभावना | क्या क्लिक इवेंट के रजिस्ट्रेशन पर भी अलग-अलग निजता सेटिंग लागू होती है? | फ़िलहाल, इस सुविधा पर "k-anon" की पाबंदियां लागू नहीं होंगी. इसकी वजह यह है कि "क्लिक की संख्या" सिर्फ़ generateBid() फ़ंक्शन में browserSignal के तौर पर उपलब्ध होगी. यह इवेंट-लेवल रिपोर्टिंग में नए एट्रिब्यूट के तौर पर उपलब्ध नहीं है. |
| परफ़ॉर्मेंस | संदर्भ के हिसाब से बिड करने के अनुरोधों पर बिना किसी शर्त के जवाब देने की वजह से, इग्रेस डेटा ट्रैफ़िक ज़्यादा है. | निजता से जुड़ी चिंताओं की वजह से, हम सीधे तौर पर यह जानकारी नहीं दे सकते कि किन डीएसपी के पास आईजी हैं. हालांकि, हम ऐसे अन्य तरीकों पर काम कर रहे हैं जिनसे निजता को बनाए रखते हुए अहम जानकारी मिल सके. |
| नेटिव और आउटस्ट्रीम विज्ञापन | नेटिव और आउटस्ट्रीम विज्ञापनों के बारे में Chrome के नज़रिए से अपडेट पाने का अनुरोध करें. | Chrome की पोज़िशन, इस्तेमाल के उदाहरण पर निर्भर करती है. वीडियो के मामले में, Chrome का मानना है कि हमारा काम, अपने एपीआई का इस्तेमाल करके नेटवर्क को इनस्ट्रीम वीडियो सलूशन में साथ मिलकर काम करने के लिए बढ़ावा देना है. फ़िलहाल, हमें सिर्फ़ GAM का प्रस्ताव पता है. नेटिव विज्ञापनों के लिए, हम यहां लगातार सुझाव, शिकायत या राय इकट्ठा कर रहे हैं. साथ ही, जल्द ही हम विज्ञापन टेक्नोलॉजी के लिए, डिस्कवरी के ज़्यादा चरणों को जोड़ने की योजना बना रहे हैं. |
| रीयल-टाइम मॉनिटरिंग (RTM) | लेबल किया गया ट्रैफ़िक, आरटीएम रिपोर्ट नहीं भेजता. | हम इस अंतर के बारे में जानते हैं और इसे ठीक करने के लिए काम कर रहे हैं. उपलब्ध होने पर, हम यहां अपडेट शेयर करेंगे. |
| ऑडियंस एक्सटेंशन से जुड़ी सहायता | PA API में ऑडियंस एक्सटेंशन/सेलर की चुनी गई ऑडियंस के लिए सहायता से जुड़े अपडेट का अनुरोध. | हम इस इस्तेमाल के उदाहरण के लिए समाधान देने पर काम कर रहे हैं. हम इस बारे में सुझाव, राय या शिकायतें इकट्ठा कर रहे हैं कि हमें क्या बनाना चाहिए और किसका समर्थन करना चाहिए. उपलब्ध होने पर, हम आपको इसकी जानकारी देंगे. अन्य सुझाव, शिकायत या राय यहां दी जा सकती हैं. |
| डीबग करना | Chrome के डेवलपर टूल में, PA API की परफ़ॉर्मेंस की पूरी जानकारी देखने के लिए कोई पैनल नहीं है. उदाहरण के लिए, आईजी या खरीदारों की संख्या से परफ़ॉर्मेंस पर असर पड़ सकता है. | यह सुझाव, Chrome डेवलपर टूल के यूज़र इंटरफ़ेस (यूआई) की मॉनिटरिंग से जुड़ी सुविधाओं के बारे में है. हालांकि, हमने 7 अक्टूबर को विज्ञापन टेक्नोलॉजी के लिए, कस्टम इवेंट कॉन्फ़िगर करने की सुविधा लॉन्च की है. इन इवेंट का इस्तेमाल, मॉनिटरिंग और चेतावनी देने के लिए किया जा सकता है. ज़्यादा जानकारी यहां उपलब्ध है. हमें उम्मीद है कि इस अपडेट से, इस सुझाव या राय के ज़रूरी हिस्से को पूरा किया जा सकेगा. हम इस सुविधा के बारे में किसी भी तरह के सुझाव, शिकायत या राय का स्वागत करते हैं. भले ही, यह सुझाव, शिकायत या राय, इस्तेमाल किए जा सकने वाले डेटा पॉइंट या GitHub पर की गई उससे जुड़ी चर्चा में डेवलपर के अनुभव से जुड़ी हो. इस चर्चा के बारे में यहां जानें. |
| सिग्नल | इस बारे में चिंता है कि डीएसपी, कॉन्टेक्स्ट के हिसाब से होने वाली नीलामी के नतीजों के आधार पर, perBuyerSignals को एसएसपी को भेज सकते हैं या नहीं. | यह माना जाता है कि संदर्भ के हिसाब से होने वाली नीलामी में, किसी डीएसपी की एक ही बिड को जीतने वाली बिड शामिल होती है. वहीं, दूसरी बिड को बेहतर बनाने के लिए, पीए एपीआई की बाद में होने वाली नीलामी से बेहतर बिड लगाई जा सकती है. PA API फ़्लो के लिए, एसएसपी उन सभी डीएसपी को न्योता भेजता है जिनके पास डिवाइस पर मौजूद आईजी के तौर पर मांग सबमिट करने की सुविधा होती है. यह पूरी तरह से मुमकिन है और असल में इस बात की बहुत संभावना है कि कॉन्टेक्स्टुअल नीलामी में हारने वाले डीएसपी को PA API नीलामी में हिस्सा लेने के लिए "फिर से न्योता" दिया जाए. "फिर से न्योता भेजने" का मतलब है कि अगर डीएसपी इस अनुरोध को स्वीकार करने का फ़ैसला लेता है, तो वह एसएसपी को ऐसा कोई सिग्नल भेजेगा जिसे विज्ञापन की पुष्टि करने वाला व्यक्ति यह पक्का करना चाहेगा कि डीएसपी उस कैंपेन के लिए कोई सिग्नल मौजूद हो या नहीं. दूसरे शब्दों में, PA API नीलामी में DSP के पास, SSP को perBuyerSignals सबमिट करने का हमेशा एक तरीका होता है. भले ही, कॉन्टेक्स्ट के हिसाब से होने वाली नीलामी में क्या हुआ हो. |
| सिग्नल | generatedBid() को पास किए गए browserSignals ऑब्जेक्ट में prevClicks जोड़ने का अनुरोध. |
क्लिक मिलने की संभावना वाले सिग्नल के लिए हमारे प्रस्ताव से, इस अनुरोध को हल किया जा सकता है. हमने इस सुविधा का एलान, हाल ही में पोस्ट की गई अपनी ब्लॉग पोस्ट और उससे जुड़े एक्सप्लेनर में किया था. इस प्रस्ताव के बारे में ज़्यादा जानकारी के लिए यहां जाएं. |
| (पिछली तिमाही में भी रिपोर्ट की गई हैं) मॉडलिंग सिग्नल |
मॉडलिंग सिग्नल के बिट की संख्या को 12 बिट से बढ़ाकर 30 बिट करने का अनुरोध. | हमने इस सुझाव का जवाब, यहां दिए गए कानूनी विरोध के ज़रिए दिया है. हम इस इंडस्ट्री के साथ लगातार बातचीत कर रहे हैं, ताकि हम उनके सुझावों को समझ सकें. फ़िलहाल, हम इस बात का आकलन कर रहे हैं कि इस बदलाव से इंडस्ट्री को क्या फ़ायदे मिलेंगे और Chrome के उपयोगकर्ताओं और अन्य हिस्सेदारों पर क्या असर पड़ेगा. |
| दस्तावेज़ | की/वैल्यू (K/V) सर्वर और टीईई इस्तेमाल करने के तरीके के बारे में दिशा-निर्देश पाने का अनुरोध करें. | K/V के संदर्भ में टीईई के इस्तेमाल से जुड़े दिशा-निर्देश, K/V सेवा के ट्रस्ट मॉडल के डिज़ाइन की जानकारी में यहां उपलब्ध हैं. |
| नेगेटिव आईजी का लाइफ़टाइम | नेगेटिव आईजी की समयसीमा को 365 दिन तक बढ़ाने का अनुरोध करना. | नेगेटिव आईजी का इस्तेमाल, विज्ञापन दिखाने से रोकने के लिए किया जाता है, लेकिन बुरे मकसद से काम करने वाले लोग या ग्रुप, अब भी उपयोगकर्ताओं की जानकारी ज़ाहिर करने के लिए इसका इस्तेमाल कर सकते हैं.इससे, नुकसान पहुंचाने वालों की पहचान का जोखिम बढ़ जाता है. उदाहरण के लिए, बुरे मकसद से काम करने वाले लोगों या ग्रुप को पता लगाने के लिए बार-बार नेगेटिव आईजी के साथ ऊंची बिड लगाएं, ताकि यह पता लगाया जा सके कि कोई उपयोगकर्ता कुछ साइटों पर गया है या नहीं. अगर हम टीटीएल को 365 दिन पर सेट करते हैं, तो बुरे इरादे वाले लोगों के पास नेगेटिव आईजी के बारे में ज़्यादा डेटा होगा. इससे निजता को ज़्यादा खतरा होगा. इसलिए, हम उपयोगकर्ता की निजता की सुरक्षा के लिए, इस अनुरोध को स्वीकार नहीं कर सकते. |
| एपीआई की खास बातें | प्रति खरीदार सिग्नल के हिस्से के रूप में पास की जाने वाली वैल्यू के तौर पर क्या डाला जा सकता है? क्या सेलर इसे मनमुताबिक तय कर सकता है? | perBuyerSignals में, सेलर खरीदारों को वह जानकारी दे सकते हैं जो उन्हें नीलामी में उपलब्ध कराना है. यह तय करना, इकोसिस्टम के लिए है कि वे वहां क्या डालना चाहते हैं. हालांकि, हम यहां इस बारे में ज़्यादा चर्चा करने के लिए तैयार हैं. |
| विज्ञापन के साइज़ के मैक्रो रिप्लेसमेंट | विज्ञापन साइज़ मैक्रो के बदले इस्तेमाल होने वाले विकल्प काम नहीं कर रहे हैं. | हम जल्द ही इस बारे में सार्वजनिक तौर पर ज़्यादा जानकारी शेयर करेंगे. |
| बिड के बाद एसएसपी मैक्रो बदलना: टॉप लेवल यूआरएल को स्पूफ करना | पुष्टि करने वाली कंपनियों को Privacy Sandbox फ़्रेमवर्क में टॉप-लेवल यूआरएल की पुष्टि करने की अनुमति देने के लिए, Chrome कौनसे तरीके अपना सकता है? क्या ऐसे अन्य डेटा पॉइंट या सिग्नल हैं जिनका इस्तेमाल, फ़ेंस किए गए फ़्रेम में किया जा सकता है, ताकि एसएसपी के दिए गए टॉप-लेवल यूआरएल की सटीक जानकारी मिल सके? |
फ़िलहाल, हम इस बारे में यहां चर्चा कर रहे हैं. |
| सुविधा का अनुरोध | updateURL फ़ेच करने और रीयल-टाइम रिपोर्टिंग पोस्टबैक पर, कम एन्ट्रापी वाला UACH उपलब्ध कराने का अनुरोध. | इन अनुरोधों पर यहां चर्चा की जा रही है. हम यहां और यहां अन्य सुझाव, शिकायत या राय का स्वागत करते हैं. |
| सुविधा का अनुरोध | जब किसी क्लाइंट को forDebuggingOnly.reportAdAuctionWin() और forDebuggingOnly.reportAdAuctionLoss() के ज़रिए, सिर्फ़ गड़बड़ी की जांच के लिए, इवेंट-लेवल की रिपोर्ट भेजने के लिए ट्रिगर किया गया हो, तो भरोसेमंद सर्वर की सहमति वाले डीबगिंग डिज़ाइन को चालू करने का अनुरोध करें. |
यह एक चालू अनुरोध है, जिसे फ़िलहाल ट्रैक किया जा रहा है. कोई भी अपडेट उपलब्ध होने पर, हम इसे इकोसिस्टम में अपडेट करेंगे. यहां हमें अपने सुझाव, शिकायत या राय भेजें. |
| एपीआई प्रयोग | यूनीक उपयोगकर्ता रीच और इंप्रेशन रीच की गिनती करने के तरीके के बारे में दिशा-निर्देश पाने का अनुरोध करें. | हम शेयर किए गए स्टोरेज वर्कलेट में आईजी को पढ़ने के तरीके के बारे में चर्चा कर रहे हैं. इसके बाद, आपके पास निजी एग्रीगेट रिपोर्ट भेजने का विकल्प होगा. इस बारे में ज़्यादा जानकारी यहां उपलब्ध है. साथ ही, हम इस प्रस्ताव और इसके लिए ईकोसिस्टम की मददगार भूमिका के बारे में सुझाव, राय या टिप्पणी का स्वागत करते हैं. |
| एपीआई प्रयोग | पब्लिशर को यह साफ़ तौर पर नहीं पता कि उन्हें किस एपीआई की जांच करनी चाहिए, कौनसे एपीआई ज़रूरी हैं, किसे चालू करना चाहिए, और आने वाले समय में क्या होगा. | हम पब्लिशर और उनके लिए उपलब्ध सुविधाओं को बेहतर बनाने की कोशिश कर रहे हैं. |
| एपीआई प्रयोग | क्या विज्ञापन नीलामी वर्कलेट इवेंट में इवेंट लिसनर जोड़े जा सकते हैं? | सामान्य इवेंट की मदद से ऐसा नहीं किया जा सकता. हालांकि, Chrome DevTools प्रोटोकॉल इवेंट से इस इस्तेमाल के उदाहरण को कुछ हद तक हल किया जा सकता है. ध्यान दें कि सामान्य इवेंट से, अलगाव/निजता से जुड़ी प्रॉपर्टी पर असर पड़ सकता है. हालांकि, इस बारे में ज़्यादा जानकारी यहां दी गई है. |
| K-Anonymity | विज्ञापन रेंडरिंग से जुड़ी शर्तों के बारे में बेहतर जानकारी पाना. उदाहरण के लिए, अगर विज्ञापन दिखाने की अनुमति दी जाती, तो कम से कम 50 लोगों ने उसे देखा होता. | डेवलपर दस्तावेज़ में, आने वाले समय में होने वाले बदलावों के बारे में खास जानकारी दी गई है. खास तौर पर, यह बताया गया है कि शुरुआती के-एनॉनिमिटी थ्रेशोल्ड k=10 लोग हैं. blink-dev मेलिंग सूची में, Chrome में लाइव होने वाली चीज़ों के बारे में अपडेट मिलते हैं. k-पहचान की पुष्टि करने वाले ईमेल पाने वाले लोगों की सूची के थ्रेड में दी गई जानकारी के मुताबिक, फ़िलहाल हम प्रयोग के तौर पर, Chrome के करीब एक% स्टेबल ट्रैफ़िक पर के-पहचान की पुष्टि करने की शर्त को लागू कर रहे हैं. साथ ही, इसे कभी भी साफ़ तौर पर लेबल किए गए ("मोड A" और "मोड B") स्लाइस पर लागू नहीं कर रहे हैं. |
| चफ़िंग | क्या टीईई के K/V चफ़िंग को कुछ समय के लिए हटाया जा सकता है या सभी N शर्ड को कॉल करने की ज़रूरत को कम किया जा सकता है, ताकि निजता की सुरक्षा और उपयोगिता के बीच संतुलन बना रहे (यानी, K/V परफ़ॉर्मेंस/लागत)? | इस तरह के अनुरोध, सिर्फ़ उन इंस्टेंस के लिए हैं जो प्रोडक्शन में नहीं हैं. इनमें चफ़िंग को कंट्रोल किया जा सकता है. प्रोडक्शन के मामलों के लिए, चार्ट में जिस तरह से आपने बदलाव किया है उसके लिए चेफ़िंग करना ज़रूरी है. नॉन-प्रोडक्शन ट्रैक के इस्तेमाल से जुड़े सुझाव, शिकायत या राय मिलने के बाद, हम इस स्थिति का आकलन कर सकते हैं. |
| चफ़िंग | डीबग/नॉन-प्रॉडक्शन K/V बाइनरी से चफ़िंग को बंद करने के लिए, फ़्लैग जोड़ने का अनुरोध. | यह फ़्लैग रिलीज़ 1.0.0 के साथ दिया जाता है. |
| एपीआई बग | Chrome 126 में अपग्रेड करने के बाद, एपीआई ने काम करना बंद कर दिया. हालांकि, सेटिंग में एपीआई चालू होने के बावजूद, यह काम नहीं कर रहा था. | यह समस्या "enable-fenced-frames" Chrome फ़्लैग से जुड़ी समस्या मिली थी, जिसे उपयोगकर्ताओं ने डेवलपमेंट के लिए चालू किया था. इस फ़्लैग को डिफ़ॉल्ट पर रीसेट करने से समस्या हल हो जाएगी. |
| रिपोर्टिंग | रीयल-टाइम रिपोर्टिंग API के लिए, खरीदारों को सेलर पर निर्भर न होने वाले ऑप्ट-इन की सुविधा देने का अनुरोध. | इस अनुरोध पर विचार करने के लिए, यहां जाएं. आरटीएम समाधान हाल ही में रिलीज़ किया गया था. हम खास तौर पर, विज्ञापन टेक्नोलॉजी से जुड़ी उन टेक्नोलॉजी से जुड़े सुझाव, शिकायत या राय का स्वागत करते हैं जो इस सुविधा में पहले से शामिल हैं. |
| रिपोर्टिंग | 3P रिपोर्टिंग के लिए अनुरोध; जबकि डीएसपी और एसएसपी को Chrome से इंप्रेशन के नोटिफ़िकेशन मिलते हैं, जबकि मिडल-लेयर टेक्निकल प्रोवाइडर्स को डिफ़ॉल्ट रूप से ऐसा नहीं मिलता. | हम इस अनुरोध पर चर्चा कर रहे हैं और यहां आपके अतिरिक्त सुझाव/राय या शिकायत का स्वागत करते हैं. |
Protected Auction Services
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| TEEs | Google की ओर से तकनीकी मानकों के तहत, मैन्युअल तरीके से शामिल होने की ज़रूरी शर्त, क्लाउड वेंडर चुनने पर एक बड़ी पाबंदी है. लागू किए गए तकनीकी मानकों का पालन, ब्यूरो ऑफ़ क्लाउड प्रोवाइडर की वेबसाइट पर जाने के बिना किया जा सकता है. ऐसा लगता है कि Google ने ऐसा किया है. अन्य सेवा देने वाली कंपनियों को 2025 (सबसे पहले) तक अनुमति नहीं दी जा सकती, क्योंकि इससे नेटवर्क इफ़ेक्ट शुरू हो जाएगा. इससे, Google के समाधानों को इस्तेमाल करने के लिए, लोगों को बढ़ावा मिलेगा. | विज्ञापन टेक्नोलॉजी के इस्तेमाल के कुछ उदाहरणों को हल करने के लिए, एग्रीगेशन सेवा को टीईई सेवा में चलाना ज़रूरी है. एग्रीगेशन सेवा, Amazon Web Services (AWS) और Google Cloud Platform (GCP), दोनों के साथ काम करती है. विज्ञापन टेक्नोलॉजी से जुड़े लोगों से मिले सुझावों के आधार पर, हमें लगता है कि इस चरण में यह सहायता काफ़ी है. अन्य क्लाउड सेवा देने वाली कंपनियों के लिए - Google ने पब्लिक क्लाउड सेवा देने वाली कंपनियों के टीईई के लिए ज़रूरी शर्तों के बारे में पूरी जानकारी पब्लिश की है. इनका मकसद यह पक्का करना है कि टीईई सलूशन, Privacy Sandbox के निजता और सुरक्षा के लक्ष्यों को पूरा करता हो. खास तौर पर, प्राइवसी सैंडबॉक्स टीईई सर्वर, एग्रीगेशन सेवा के लिए पब्लिशर और विज्ञापन देने वाली साइटों से मिला, क्रॉस-साइट उपयोगकर्ता का एन्क्रिप्ट नहीं किया गया डेटा प्रोसेस करते हैं. एपीआई के उपयोगकर्ता की निजता से जुड़े लक्ष्यों को पूरा करने के लिए, इन कुंजियों को सुरक्षित रखना ज़रूरी है. सुरक्षित माहौल इसलिए भी ज़रूरी है, ताकि यह पक्का किया जा सके कि एपीआई कंपनियों के कारोबार की गोपनीय जानकारी को सुरक्षित रखते रहें. उदाहरण के लिए, PA API नीलामी में हिस्सा लेने वाले दूसरे लोगों को खरीदार के कारोबार के मालिकाना हक वाले डेटा को ऐक्सेस करने से रोकना. हमारे हिसाब से, फ़िलहाल ऐसी कोई टीईई टेक्नोलॉजी नहीं है जो उपयोगकर्ता के डेटा को, संभावित रूप से नुकसान पहुंचाने वाले ऑपरेटर से पूरी तरह से सुरक्षित रख सके. इसलिए, हम क्लाउड सेवा देने वाली कंपनी के भरोसेमंद होने की पुष्टि करने के लिए, कई ज़रूरी शर्तें शामिल करते हैं. हम पक्के तौर पर नहीं जानते कि "क्लाउड सेवा देने वाली कंपनियों का ब्यूरो" क्या है. यह ज़रूरी शर्तों का हिस्सा नहीं है. ज़रूरी शर्तों के बारे में आपके किसी भी सुझाव का स्वागत है. हम नए सेवा देने वालों के लिए सहायता का आकलन भी करते रहते हैं. इसमें, एक्सप्लेनर में बताई गई प्रोसेस का इस्तेमाल करके सबमिट किए गए अनुरोधों के आधार पर भी आकलन किया जाता है. अब तक, हमें सिर्फ़ Azure के साथ काम करने का अनुरोध मिला है. हम इसकी समीक्षा कर रहे हैं. |
| B&A | B&A सेवा के डिज़ाइन में लगातार बदलाव हो रहे हैं. इसलिए, इस सेवा की तकनीकी जटिलता और इसे उपलब्ध कराने की संभावना का आकलन करना मुश्किल है. | इन समस्याओं को हल करने के लिए, हमने GitHub पर ज़्यादा जानकारी उपलब्ध कराई है. इसमें B&A के डिज़ाइन के बारे में बताया गया है. साथ ही, PA API के साथ काम करने वाली सुविधाओं का रोडमैप और उपलब्धता की टाइमलाइन पब्लिश की गई हैं. हम उन विज्ञापन टेक्नोलॉजी कंपनियों की मदद कर रहे हैं जो B&A को डिप्लॉय करना चाहती हैं. साथ ही, हम GitHub पर ईकोसिस्टम से सुझाव, शिकायत या राय इकट्ठा कर रहे हैं. |
| B&A | आपको B&A के लिए टीईई का इस्तेमाल शुरू करने या डिवाइस पर मौजूद टीईई से माइग्रेट करने के लिए, इसके इस्तेमाल की लागत का हिसाब लगाने का बेहतर तरीका और दिशा-निर्देश चाहिए. | हमने हाल ही में K/V सर्वर इंस्टेंस के साइज़ तय करने से जुड़ी गाइड पब्लिश की है. इसमें लागत को ज़्यादा सटीक तरीके से मेज़र करने के लिए टूल शामिल हैं. |
| के/वी सर्वर | विज्ञापन की पुष्टि करने वाला टूल, K/V सर्वर से पेज के पूरे यूआरएल का इस्तेमाल करने का अनुरोध कर रहा है, ताकि विज्ञापन की पुष्टि की जा सके. | फ़िलहाल, हम विज्ञापन की पुष्टि करने के लिए, टीईई में चल रहे K/V सर्वर को पूरे पेज का यूआरएल देने की संभावना का आकलन कर रहे हैं. K/V BYOS में, पूरे पेज का यूआरएल उपलब्ध नहीं होगा. |
| नीलामी की सुरक्षा | नीलामी के लिए सुरक्षा से जुड़ी सुविधाओं की तलाश में हैं, ताकि यह पक्का किया जा सके कि बुरे मकसद से काम करने वाले लोग या ग्रुप, संवेदनशील जानकारी को ऐक्सेस न करें या किसी दूसरे के नाम पर काम न करें. ऐसी कौनसी सुविधाएं, नीलामी को रीप्ले हमलों से बचाती हैं और सुरक्षा के उपाय कैसे लागू किए जा सकते हैं? | B&A का मौजूदा सुरक्षा मॉडल, नीलामी की पूरी सुरक्षा कर सकता है. B&A, TEE में चलता है. यह विज्ञापन टेक्नोलॉजी से जुड़े लोगों के सिग्नल और कोड को, नुकसान पहुंचाने वाले लोगों या ग्रुप से सुरक्षित रखता है. B&A आर्किटेक्चर में, एन्क्रिप्ट (सुरक्षित) किया गया B&A अनुरोध पेलोड (अनुरोध का सिफरटेक्स्ट), क्लाइंट से अविश्वसनीय विज्ञापन सर्वर के ज़रिए SellerFrontEnd सेवा (SFE, टीईई में एसएसपी के ज़रिए चलाई जाती है) पर भेजा जाता है. अनुरोध के सिफरटेक्स्ट में, टाइमस्टैंप पर आधारित जनरेशन आईडी शामिल होता है. SFE, अनुरोध के टाइमस्टैंप की जांच करेगा और ऐसे सभी अनुरोधों को अस्वीकार कर देगा जो सर्वर के समय से +/- n सेकंड के अंदर नहीं हैं. इसके अलावा, B&A, सर्वर से सर्वर कम्यूनिकेशन के लिए पैड किए गए तय साइज़ का रिस्पॉन्स पेलोड लौटा सकता है. इन समाधानों की मदद से, सिस्टम में दोबारा अनुरोध करने से जुड़े हमलों को कम किया जा सकता है. ऐसा तब होता है, जब कोई नुकसान पहुंचाने वाला व्यक्ति, अनुरोध के कॉन्टेंट के बारे में ज़्यादा जानने के लिए, उसी अनुरोध को दोबारा भेजने की कोशिश करता है. B&A, सुरक्षा मॉडल को दस्तावेज़ में शामिल करने और उन्हें एक्सप्लेनेटर में अपडेट करने की प्रोसेस में है. |
K/V सर्वर के ज़रिए सिग्नल |
Chrome के भरोसेमंद बिडिंग सिग्नल अनुरोध के हिस्से के तौर पर, K/V सेवा से भेजे गए PerBuyerSignals को शामिल करने का अनुरोध. | हम perBuyerSignals से मिली जानकारी को शामिल करने की संभावना का आकलन कर रहे हैं. यह जानकारी, टीईई में चल रहे K/V सर्वर पर ट्रांसफ़र की जाती है. इसमें पेज का पूरा यूआरएल भी शामिल होता है. |
| K/V सर्वर | K/V और B&A में निजता से जुड़ी पाबंदियों को लागू करने के लिए, चरणों में टाइमलाइन तय करने का अनुरोध. | हम टीकेवी इस्तेमाल करने के लिए, एक ही चरण तक पूरी करने की इच्छा को समझते हैं. साथ ही, हम K/V और B&A से जुड़े आपके खास अनुरोधों की सराहना करते हैं. हालांकि, ध्यान से जांच करने के बाद, हमने फ़िलहाल इन एपीआई में निजता सुरक्षा से जुड़ी शर्तों में कोई बदलाव न करने का फ़ैसला लिया है. हमारा मानना है कि उपयोगकर्ता की निजता को सुरक्षित रखने और प्राइवसी सैंडबॉक्स पर लोगों का भरोसा बनाए रखने के लिए, चफ़िंग जैसे ये उपाय ज़रूरी हैं. |
| K/V सर्वर | साथ काम करने वाले कॉन्फ़िगरेशन की मदद से, K/V स्टोर को स्केल करने के बारे में जानकारी पाना. | हाल ही में पब्लिश की गई K/V सर्वर इंस्टेंस साइज़ करने की गाइड से आपको मदद मिल सकती है. यह टूल, पैरामीटर के हर कॉम्बिनेशन के लिए QPS (एक्सप्लेनर में "RPS" के तौर पर दिखाया गया है) देगा. |
| के/वी सर्वर | K/V सर्वर के अनुरोध में सेलर की जानकारी जोड़ें. | हम इस बारे में चर्चा कर रहे हैं. अगर आपके पास कोई और सुझाव है, तो यहां बताएं. |
| K/V + B&A Services | K/V और B&A के लिए, रिलीज़ की टाइमलाइन या रोडमैप के बारे में बताने का अनुरोध. | K/V और B&A, दोनों के लिए हमारे पास अलग-अलग चरण और टाइमलाइन हैं: डिवाइस पर चलने वाले PA API की नीलामियों (बनाम B&A) के साथ K/V सर्वर के लिए, सार्वजनिक टाइमलाइन यहां उपलब्ध है. K/V के लिए "सामान्य तौर पर उपलब्धता" की परिभाषा कैसे तय की जाती है, यह जानने के लिए रोडमैप सेक्शन देखें. इसमें बीटा और जीए के लिए सुविधा सेट की जानकारी दी गई है. बीएनए के लिए, सार्वजनिक टाइमलाइन यहां और रोडमैप यहां देखें. हम स्केल टेस्टिंग को "पूरी तरह से स्थिर, प्रोडक्शन स्केल टेस्टिंग" के तौर पर परिभाषित करते हैं. इस चरण में मौजूद खास सुविधाओं के बारे में जानने के लिए, यहां जाएं. B&A में ऐल्फ़ा और बीटा चरण भी होते हैं. इसलिए, स्केल टेस्टिंग में, पहले चरणों की सुविधाओं का सुपर-सेट शामिल होगा. K/V और B&A, दोनों के लिए हमें बताएं कि क्या इन चरणों की परिभाषाओं से यह साफ़ तौर पर पता चलता है कि कौनसी सुविधा कब उपलब्ध होगी. अगर अब भी कोई कमी है, तो कृपया हमें बताएं. हमें इन रिपोर्ट को ज़्यादा सटीक बनाने में खुशी होगी, ताकि आपको प्लानिंग करने में मदद मिल सके. |
डिजिटल विज्ञापनों की परफ़ॉर्मेंस का आकलन करना
एट्रिब्यूशन रिपोर्टिंग (और अन्य एपीआई)
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| मार्केट रिस्पॉन्स | प्रतिस्पर्धी एट्रिब्यूशन सिस्टम को सिर्फ़ इवेंट-लेवल की रिपोर्टिंग और खास जानकारी/एग्रीगेट रिपोर्टिंग का इस्तेमाल करने की ज़रूरी शर्त, प्रतिस्पर्धा पर मनमुताबिक पाबंदी है. इससे, इवेंट लेवल पर रीयल टाइम में डिवाइस के हिसाब से रीटारगेटिंग और एट्रिब्यूशन की सुविधा बंद हो जाती है. भले ही, डेटा की सुरक्षा से जुड़ी शर्तों का पालन करने के लिए, सेफ़गार्ड (जैसे, पहचान ज़ाहिर न करने की सुविधा) पहले से लागू हों. | यहां दिया गया डिज़ाइन, एपीआई के निजता लक्ष्यों पर आधारित है. उदाहरण के लिए, एक साइट से दूसरी साइट पर भेजी जा रही क्रॉस-साइट जानकारी को सुरक्षित रखना. उदाहरण के लिए, ARA, इवेंट रिपोर्ट के ज़रिए इवेंट-लेवल एट्रिब्यूशन के साथ काम करता है. इवेंट की रिपोर्ट में कम से कम एक घंटे की देरी होती है. इस वजह से, इवेंट-लेवल की रिपोर्ट को विज्ञापन देने वाले की साइट पर उपयोगकर्ता की पहचान से जोड़ना मुश्किल हो जाता है. इसके लिए टाइमिंग साइड चैनल हमलों का इस्तेमाल किया जाता है, जैसा कि यहां बताया गया है. इसके अलावा, एआरए के अलावा एट्रिब्यूशन करने के और भी तरीके हैं. जैसे, उन उपयोगकर्ताओं से सीधे तौर पर जानकारी इकट्ठा करना जो जान-बूझकर पहचान से जुड़ा डेटा उपलब्ध कराते हैं. हम उन इस्तेमाल के उदाहरणों के बारे में सुझाव, राय या शिकायतें सुनने के लिए तैयार हैं जिन्हें Privacy Sandbox API की मौजूदा निजता सीमाओं के साथ पूरा नहीं किया जा सकता. |
| कई प्लैटफ़ॉर्म | इस बात की पुष्टि करने के लिए अनुरोध करें कि ARA और Shared Storage API को कई जगहों पर इस्तेमाल किया जा सकता है या नहीं. साथ ही, यह भी जानें कि यह सुविधा किन जगहों पर उपलब्ध है. | फ़िलहाल, ARA और शेयर किए गए स्टोरेज में, अलग-अलग प्लैटफ़ॉर्म (अलग-अलग डिवाइस) पर होने वाले कन्वर्ज़न के लिए एट्रिब्यूशन की सुविधा काम नहीं करती. एक ही डिवाइस पर, क्रॉस-ऐप्लिकेशन और वेब एट्रिब्यूशन (ARA के ज़रिए) की सुविधा काम करती है. |
| (पिछली तिमाहियों में भी रिपोर्ट की गई) क्रॉस-डिवाइस |
क्या ARA, क्रॉस-डिवाइस कन्वर्ज़न के साथ काम करता है? | हमारा जवाब पिछली तिमाहियों की तरह ही है: क्रॉस-डिवाइस, 3PC के साथ-साथ निजता से जुड़ी नई चुनौतियां पेश करता है. साथ ही, उपयोगकर्ता के डिवाइसों और प्लैटफ़ॉर्म की रेंज को देखते हुए, टेक्नोलॉजी डिस्ट्रिब्यूशन से जुड़ी चुनौतियां भी पैदा करता है. हम इस समस्या को हल करने के संभावित तरीकों पर काम कर रहे हैं. हालांकि, फ़िलहाल हमारा ध्यान उन अहम इस्तेमाल के उदाहरणों पर है जिनमें ARA की सुविधा काम करती है. साथ ही, फ़िलहाल हमारे पास अलग-अलग डिवाइसों पर इस सुविधा के इस्तेमाल की समयावधि नहीं है. |
| स्केलिंग: | Attribution Report API (ARA) को फ़िलहाल कॉन्फ़िगर किया गया है या नहीं, इससे जुड़ी समस्याएं | फ़िलहाल, ARA सभी Chrome उपयोगकर्ताओं के लिए उपलब्ध है और उम्मीद के मुताबिक काम कर रहा है. साथ ही, हम इसकी भरोसेमंदता और स्केलेबिलिटी की जांच करते रहते हैं. ऐसा इसलिए, क्योंकि ARA को टेस्ट करने वाली विज्ञापन टेक्नोलॉजी कंपनियों की संख्या लगातार बढ़ रही है. हम इस बारे में, यहां नेटवर्क से जुड़े सुझाव, राय या शिकायतें स्वीकार करते हैं. |
| (पिछली तिमाहियों में भी रिपोर्ट की गई) डुप्लीकेट कॉपी हटाने की तकनीक |
ARA, डिवाइसों पर एट्रिब्यूशन मैकेनिज्म को कैसे सीमित करता है, इस बारे में चिंताएं. इस वजह से, पब्लिशर खास जानकारी वाली रिपोर्ट के लिए, पोस्ट-एट्रिब्यूशन लॉजिक को असरदार तरीके से लागू नहीं कर पाते. इसमें, एक ही विज्ञापन क्लिक के लिए एक ही तरह के कई कन्वर्ज़न को डुप्लीकेट के तौर पर हटाना भी शामिल है. | हमारी पिछली तिमाहियों की तुलना में, हमारा जवाब अब भी पहले जैसा है: सभी डिवाइसों और मेज़रमेंट पाइपलाइन से डुप्लीकेट डेटा हटाना एक पुरानी और मौजूदा समस्या है. विज्ञापन टेक्नोलॉजी को आज भी 3PCs से इस समस्या का सामना करना पड़ता है. ARA की मदद से, विज्ञापन टेक्नोलॉजी विशेषज्ञ यह तय कर सकते हैं कि किसी खास कन्वर्ज़न को कब रजिस्टर किया जाए.साथ ही, वे खास मेटाडेटा जोड़ सकते हैं, ताकि यह पता चल सके कि कन्वर्ज़न (यानी एग्रीगेशन बटन का हिस्सा) को ट्रैक करने के लिए, उन्होंने किन मेज़रमेंट पाइपलाइन का इस्तेमाल किया है. इनकी तुलना अन्य मेज़रमेंट पाइपलाइन से की जा सकती है. हम इस बारे में, यहां नेटवर्क से जुड़े सुझाव, राय या शिकायतें स्वीकार करते हैं. |
| कन्वर्ज़न ट्रैकिंग | एक से ज़्यादा डोमेन से कन्वर्ज़न के साथ काम करने की क्षमता का अनुरोध करें. | हम इस अनुरोध के बारे में यहां चर्चा कर रहे हैं. हमारे नेटवर्क पर अन्य सुझाव, शिकायत या राय का स्वागत है. |
| रिपोर्टिंग | ब्राउज़र, कन्वर्ज़न भेजने के लिए कम से कम दो दिन, लेकिन ज़्यादा से ज़्यादा 30 दिन तक इंतज़ार करता है. इस वजह से, विज्ञापन देने वाले ज़्यादातर लोग परेशान हो सकते हैं, क्योंकि वे परफ़ॉर्मेंस के हिसाब से विज्ञापन देते हैं और यह काम रीयल-टाइम में होता है. | इवेंट-लेवल रिपोर्ट की डिफ़ॉल्ट सेटिंग में, रिपोर्टिंग की ये डिफ़ॉल्ट विंडो होती हैं: दो दिन, सात दिन, और 30 दिन. इवेंट-लेवल पर विज्ञापन दिखाने से जुड़ी आसान सुविधाओं की मदद से, रिपोर्टिंग विंडो की संख्या और अवधि को डिफ़ॉल्ट वैल्यू से बदला जा सकता है. रिपोर्टिंग विंडो को कम से कम एक घंटे में बदला जा सकता है. इससे विज्ञापन देने वाले की परफ़ॉर्मेंस के उदाहरणों में मदद मिल सकती है. हम इस बारे में नेटवर्क पर अतिरिक्त सुझाव, राय या शिकायत यहां ले सकते हैं. |
| ऑनलाइन-से-ऑफ़लाइन एट्रिब्यूशन | क्या ARA में, ऑनलाइन से ऑफ़लाइन विज्ञापन दिखाने की सुविधा लागू करने के लिए कोई विकल्प होगा या ऑफ़लाइन से ऑनलाइन एट्रिब्यूशन को मेज़र करने के लिए कोई और सुझाव है? | फ़िलहाल, ARA में ऑनलाइन-टू-ऑफ़लाइन मेज़रमेंट के इस्तेमाल के उदाहरणों को शामिल करने का कोई प्लान नहीं है. इस तरह की सहायता देने के लिए, निजता और सुरक्षा से जुड़ी कई चुनौतियों का ध्यान रखना ज़रूरी है. हम इस सहायता के लिए, इस्तेमाल के उदाहरणों के बारे में नेटवर्क पर अतिरिक्त सुझाव, राय या शिकायत यहां ले सकते हैं. |
| डीबग रिपोर्टिंग | AdID को इस तरह से सेव और/या वापस कैसे लाएं कि वह ऐप्लिकेशन से वेब पर ट्रैकिंग के लिए, Chrome (सोर्स/ट्रिगर) रजिस्ट्रेशन के लिए ऐक्सेस किया जा सके? | डीबग रिपोर्ट को चालू करने के लिए, विज्ञापन टेक्नोलॉजी को हमें यह साबित करना होगा कि ऐप्लिकेशन और वेब पर किसी भी उपयोगकर्ता से जुड़ सकता है. साथ ही, ऐसा यह पक्का करने के लिए किया जाता है कि डीबग रिपोर्ट में कोई नई जानकारी न दिखे. विज्ञापन टेक्नोलॉजी, हर उपयोगकर्ता के लिए यूनीक जॉइन पासकोड देकर, जॉइन होने की पुष्टि कर सकती है. यह 'जॉइन की' AdID हो सकती है या पहले पक्ष की 'जॉइन की' हो सकती है. अगर विज्ञापन टेक्नोलॉजी AdID का इस्तेमाल करती है, तो Chrome ब्राउज़र से AdID को ऐक्सेस नहीं कर सकता. साथ ही, एपीआई को उम्मीद है कि वेब रजिस्टरेशन के दौरान, हर विज्ञापन टेक्नोलॉजी के पास AdID को पास करने का अपना तरीका होगा. |
| बकेट के लेवल की जानकारी | क्या हर विज्ञापन देने वाले के लिए अलग-अलग बकेट रणनीतियों का इस्तेमाल किया जा सकता है? | हमारा सुझाव है कि योगदान के बजट को बढ़ाने के अलग-अलग तरीकों को आज़माएं. इससे आपको अपने इस्तेमाल के उदाहरणों के हिसाब से सबसे सही तरीका चुनने में मदद मिलेगी. ARA को इस मकसद से बनाया गया था कि उसमें ज़रूरत के हिसाब से बदलाव किए जा सकें. साथ ही, विज्ञापन टेक्नोलॉजी से जुड़ी अलग-अलग तरह की सुविधाओं को इस्तेमाल करने की ज़रूरतों को पूरा किया जा सके. इसलिए, हमारा सुझाव है कि आप हर विज्ञापन देने वाले या हर वर्टिकल के लिए, अलग-अलग बकेट करने की रणनीतियों के साथ प्रयोग करें. बकेटिंग की अलग-अलग रणनीतियों का इस्तेमाल करना तब फ़ायदेमंद हो सकता है, जब विज्ञापन देने वाले लोगों या कंपनियों को ट्रैक करने में दिलचस्पी रखने वाली मेज़रमेंट वैल्यू और मेज़रमेंट वैल्यू के वॉल्यूम में अंतर हो. |
| दस्तावेज़ | ARA के लिए, ऐप्लिकेशन<>वेब को लागू करने के लिए ज़्यादा दस्तावेज़ों का अनुरोध करना. | हमने ARA के लिए, ऐप्लिकेशन<>वेब पर यहां दस्तावेज़ जारी किया है. |
| परफ़ॉर्मेंस | ARA से जुड़े अनुरोधों की संख्या, पब्लिशर के सर्वर पर ज़्यादा लोड डाल सकती है. यह लोड, साइट को चालू रखने के लिए ज़रूरी 'कीपऐलिव' अनुरोधों की संख्या के मुकाबले ज़्यादा हो सकता है. सोर्स इवेंट को एक ही अनुरोध में शामिल करने से, सर्वर पर लोड कम करने में मदद मिल सकती है. एक संभावित आइडिया यह है कि JSON में कोड किए गए ऑब्जेक्ट के कलेक्शन को अनुमति दी जाए | एपीआई के साथ JavaScript लॉजिक का इस्तेमाल करके, किसी खास लॉजिक के आधार पर सोर्स इवेंट को कुछ हद तक एक साथ भेजा जा सकता है. फ़िलहाल, हम इस अनुरोध की समीक्षा कर रहे हैं. साथ ही, हम इकोसिस्टम से यहां और सुझाव, शिकायत या राय का इंतज़ार कर रहे हैं. |
| सुविधा का अनुरोध | सर्वर-टू-सर्वर इंटिग्रेशन की सुविधा उपलब्ध न होने की वजह से, समस्या हल करने का सुझाव. | फ़िलहाल, हमारा प्लान ARA में सर्वर-टू-सर्वर इंटिग्रेशन की सुविधा लागू करने का नहीं है. सर्वर-टू-सर्वर इंटिग्रेशन की सुविधा देने के लिए, निजता से जुड़ी कई समस्याओं पर विचार करना होगा. सर्वर-टू-सर्वर सहायता के लिए, इस्तेमाल के अन्य उदाहरणों के बारे में हमें अपने सुझाव, राय भेजें या शिकायत करें. इसके लिए, यहां जाएं. |
| दस्तावेज़ | "तुरंत शुरू करने" से जुड़ी गाइड का अनुरोध करें. इसमें ARA के मुख्य हिस्सों के बारे में बताया गया हो/इस्तेमाल के कुछ आसान उदाहरणों के साथ, इसे शुरू करने और चलाने का तरीका बताया गया हो. | ARA के लिए 'आसानी से सीखें' गाइड यहां उपलब्ध है. हम इस साल इस दस्तावेज़ को और बेहतर बनाने पर काम कर रहे हैं. साथ ही, इस्तेमाल के खास उदाहरणों या उन स्थितियों के बारे में ज़्यादा सुझाव, शिकायत या राय का स्वागत करते हैं जिनके लिए ज़्यादा दस्तावेज़ की ज़रूरत होती है. इसके लिए, यहां जाएं. |
| एपीआई प्रयोग | कई छोटी वैल्यू के लिए, योगदान बढ़ाने के सुझावों का अनुरोध करें. | हमारा सुझाव है कि योगदान के बजट को बढ़ाने के अलग-अलग तरीकों को आज़माएं. इससे आपको अपने इस्तेमाल के उदाहरणों के हिसाब से सबसे सही तरीका चुनने में मदद मिलेगी. कई छोटी वैल्यू के मामले में, हमारा सुझाव है कि आप एप्सिलॉन की अलग-अलग वैल्यू आज़माकर देखें. इससे आपको उन पॉइंट की पहचान करने में मदद मिलेगी जहां आपके इस्तेमाल के उदाहरण के लिए, एप्सिलॉन से आने वाला शोर स्वीकार किया जा सकता है. ज़्यादा जानकारी के लिए, ARA में समरी रिपोर्ट को ऑप्टिमाइज़ करने के बारे में हमारे रिसर्च पेपर को पढ़ें. |
| इवेंट-लेवल पर फ़्लेक्सिबल | फ़्लेक्सिबल इवेंट-लेवल (एक से ज़्यादा ट्रिगर की जानकारी) कब लागू होगा? | फ़िलहाल, फ़्लेक्सिबल इवेंट-लेवल, रजिस्ट्रेशन कॉन्फ़िगरेशन के इन पहलुओं को पसंद के मुताबिक बनाने की सुविधा देता है: हर सोर्स से जनरेट की जा सकने वाली रिपोर्ट की संख्या, रिपोर्टिंग विंडो की संख्या और अवधि, और ट्रिगर डेटा की एलिमेंट की संख्या. फ़िलहाल, हम इवेंट-लेवल पर बेहतर सुविधाओं के बारे में, नेटवर्क से जुड़े लोगों का सुझाव, राय या शिकायत इकट्ठा कर रहे हैं. हालांकि, फ़िलहाल हम इन्हें लागू नहीं करने वाले. इस्तेमाल के उन उदाहरणों के बारे में ज़्यादा सुझाव, शिकायत या राय दें जिनमें यहां दिए गए, इवेंट-लेवल पर किए गए कुछ बेहतर बदलावों से फ़ायदा मिल सकता है. |
| बकेट प्रोसेसिंग | बकेट के साथ काम करने वाले योगदान के साथ-साथ भविष्य के एक्सटेंशन और पुराने सिस्टम के साथ काम करने की सुविधा के लिए, इकट्ठा किए गए योगदान की सीमा तय करने का अनुरोध करें. | हम इस अनुरोध पर विचार कर रहे हैं. अगर आपके पास कोई और सुझाव, राय या शिकायत है, तो यहां बताएं. |
| Epsilon | ARA के सामान्य रूप से उपलब्ध होने पर, एप्सिलॉन रेंज का क्या होता है? | ARA, 2023 की तीसरी तिमाही में Chrome पर सामान्य रूप से उपलब्ध हो गया. इस समय, ऐप्सिलॉन मान विंडो को बदलने की कोई योजना नहीं है. नए गवर्नेंस स्ट्रक्चर के लिए हमारा प्रस्ताव, किसी भी तरह के बदलावों के लिए अतिरिक्त भरोसा दिलाएगा. |
| रिपोर्टिंग | 'गड़बड़ी की जानकारी देना' ट्रिगर से जुड़ी रिपोर्ट के मुख्य हिस्से में, सोर्स एट्रिब्यूट शामिल नहीं होते हैं. | स्पेसिफ़िकेशन में बताया गया है कि trigger-unknown-error के लिए, रिपोर्ट के मुख्य हिस्से में अन्य फ़ील्ड मौजूद होने की ज़रूरत नहीं है. हम मानते हैं कि रिपोर्ट के मुख्य हिस्से में फ़ील्ड की जानकारी देने वाली टेबल, गुमराह करने वाली थी. इसकी वजह यह है कि गड़बड़ी की असल वजह के आधार पर, सोर्स से जुड़े फ़ील्ड मौजूद हो सकते हैं या नहीं. उदाहरण के लिए, सोर्स-मैचिंग लॉजिक से पहले, कोई अंदरूनी गड़बड़ी हो सकती है. इसका मतलब है कि डीबग रिपोर्ट में अपने-आप जानकारी भरने के लिए, कोई सोर्स डेटा उपलब्ध नहीं है. इस बारे में साफ़ तौर पर जानकारी देने के लिए, दस्तावेज़ अब अपडेट कर दिया गया है. |
| एपीआई प्रयोग | दो मेज़रमेंट लक्ष्यों, गिनती और वैल्यू के साथ काम करने पर, क्या योगदान के लिए बजट और ऐपसिलॉन, दोनों को बांटने का संकेत मिलता है? | दो मेज़रमेंट लक्ष्यों के साथ काम करते समय, हमारा सुझाव है कि आप योगदान के बजट को उनके बीच बांटें. |
| रिपोर्टिंग | क्या ARA, मल्टी-टच एट्रिब्यूशन या असिस्ट रिपोर्ट (जिसे योगदान रिपोर्ट भी कहा जाता है) के साथ काम करता है? | फ़िलहाल, ARA में मल्टी-टच एट्रिब्यूशन या असिस्ट रिपोर्ट की सुविधा उपलब्ध नहीं है. फ़िलहाल, इसे लागू करने की हमारी कोई योजना नहीं है. इस्तेमाल के उदाहरणों और उनकी प्राथमिकता के बारे में ज़्यादा सुझाव, राय या शिकायत यहां भेजें. |
| एपीआई बग | ARA के दस्तावेज़ों में बताया गया है कि XOR का इस्तेमाल, सोर्स और एग्रीगेशन की मुख्य चीज़ों को ट्रिगर करने के लिए किया जाता है. हालांकि, असल में OR का इस्तेमाल किया जा रहा है. इस अंतर की वजह से, लागू करने में भ्रम और गड़बड़ियां हो सकती हैं. | दस्तावेज़ को अपडेट कर दिया गया है, ताकि यह पता चल सके कि यह गड़बड़ी है. |
एग्रीगेशन सेवा
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| एग्रीगेशन जॉब | एग्रीगेशन जॉब में एक से ज़्यादा प्रीफ़िक्स इस्तेमाल करने की अनुमति देने का अनुरोध. | हम इस सुझाव की जांच कर रहे हैं. साथ ही, हमने यहां एक प्रस्ताव पोस्ट किया है. इस प्रस्ताव के बारे में यहां सुझाव, राय या शिकायत दें. |
| सुविधा का अनुरोध | terraform स्क्रिप्ट में बदलाव करने का अनुरोध, ताकि अगर service_account_token_creator_list सेट न हो (या खाली हो), तो खाते की आईएएम नीति में बदलाव न किया जाए. | हम इस समस्या की जांच यहां कर रहे हैं. हमारे नेटवर्क पर अन्य सुझाव, शिकायत या राय का स्वागत है. |
| एपीआई प्रयोग | टेराफ़ॉर्म प्लान में हमेशा होने वाले बदलावों के बारे में पूरी जानकारी देना ज़रूरी है. | इस समस्या को AgS 2.8 रिलीज़ में ठीक कर दिया गया है. |
| एपीआई प्रयोग | योगदान को फ़िल्टर करने के लिए, विज्ञापन देने वाले हर व्यक्ति या कंपनी के हिसाब से, एग्रीगेशन फ़्रीक्वेंसी की सेटिंग सेट अप करने के सुझाव चाहिए. | फ़िलहाल, ARA की मदद से विज्ञापन देने वाले के हिसाब से बैच में विज्ञापन दिखाए जा सकते हैं. योगदान को फ़िल्टर करने की सुविधा का इस्तेमाल, ज़्यादा बेहतर मामलों में किया जा सकता है. जैसे, जब कोई विज्ञापन टेक्नोलॉजी किसी रिपोर्ट के योगदान को अलग-अलग फ़्रीक्वेंसी के हिसाब से सेगमेंट करना चाहता है. विज्ञापन टेक्नोलॉजी विशेषज्ञ, एक साथ कई फ़ाइलें अपलोड करने के बारे में यहां और ARA के साथ फ़िल्टर करने वाले आईडी इस्तेमाल करने के बारे में यहां ज़्यादा जान सकते हैं. हम आईडी फ़िल्टर करने के लिए, ज़्यादा दस्तावेज़ों पर भी काम कर रहे हैं. |
| सुविधा का अनुरोध | एग्रीगेशन सेवा (AgS) में `log_sum_exp` के लिए सहायता का अनुरोध करें. | इस्तेमाल के उदाहरण के बारे में ज़्यादा जानकारी के लिए, हमने इस हिस्सेदार से संपर्क किया है. ज़्यादा जानकारी मिलने पर, हम आपको अपडेट देंगे. |
| सुविधा का अनुरोध | AgS में समस्याएं होने पर और डिप्लॉय किए गए AgS में संभावित समस्याएं होने पर, ज़्यादा लॉग/अहम जानकारी/अन्य मेट्रिक देखने का अनुरोध करें. | हमने अपने दस्तावेज़ में अपडेट पब्लिश किए हैं, ताकि ज़्यादा गड़बड़ियों, उन्हें कम करने के तरीकों, और उनके बारे में जानकारी शामिल की जा सके. यहां जाएं. हम उन गड़बड़ियों/मेट्रिक/लॉग वगैरह के बारे में ज़्यादा सुझाव, राय या शिकायत पाना चाहते हैं जिनके बारे में दस्तावेज़ में नहीं बताया गया है या जो उपलब्ध नहीं हैं. साथ ही, हम यह भी जानना चाहते हैं कि यहां कौनसी जानकारी काम की होगी. |
| एपीआई की जांच | टेस्ट पीरियड के बाद, epsilon की फ़ाइनल वैल्यू क्या होगी? | इस समय, ऐप्सिलॉन मान विंडो को बदलने की कोई योजना नहीं है. हम टेस्टर को अलग-अलग पैरामीटर आज़माने और सुझाव देने के लिए बढ़ावा देते हैं. |
| रिपोर्टिंग | रिपोर्ट जनरेट हो रही है, लेकिन रिटर्न कोड में अब भी PRIVACY_BUDGET_AUTHORIZATION_ERROR दिख रहा है. | इस गड़बड़ी से बचने के लिए, हमने रिपोर्टिंग के सही ऑरिजिन और एग्रीगेट की जा सकने वाली रिपोर्ट के बारे में सलाह दी है. हम इस समस्या के बारे में और सुझाव, शिकायत या राय पाना चाहते हैं. खास तौर पर, अगर बार-बार गड़बड़ियां हो रही हैं. |
| मुख्य डिस्कवरी | खोज के अहम प्रस्ताव को लेकर क्या प्लान हैं? | फ़िलहाल, हमने मुख्य खोज के प्रस्ताव को रिलीज़ करने की कोई समयसीमा नहीं तय की है. हालांकि, हम यहां जाकर, प्रस्ताव के बारे में नेटवर्क से सुझाव मांग रहे हैं. |
| कस्टमाइज़ेशन | एग्रीगेशन सेवा को पसंद के मुताबिक बनाने के विकल्प खोजना. | टीईई में एग्रीगेशन सेवा को पसंद के मुताबिक नहीं बनाया जा सकता. हालांकि, टीईई के बाहर के कुछ कॉम्पोनेंट के लिए ऐसा किया जा सकता है. ऐसा इसलिए है, क्योंकि हमें टीईई में निजता और सुरक्षा के मानकों का पालन करना होता है. हम अपने दस्तावेज़ को अपडेट करने पर काम कर रहे हैं, ताकि विज्ञापन टेक्नोलॉजी विशेषज्ञ, आर्किटेक्चर को समझ सकें और यह जान सकें कि किन कॉम्पोनेंट को पसंद के मुताबिक बनाया जा सकता है. हम कुछ कस्टमाइज़ेशन की सुविधा नहीं दे सकते. इसलिए, हम विज्ञापन टेक्नोलॉजी को सुझाव देते हैं कि जहां भी मुमकिन हो, हमारे स्टैंडर्ड कॉन्फ़िगरेशन का इस्तेमाल करें. |
| स्पॉट इंस्टेंस बनाम ऑन-डिमांड इंस्टेंस | क्या सिस्टम की जांच, ऑन-डिमांड इंस्टेंस के बजाय स्पॉट इंस्टेंस का इस्तेमाल करके की गई है? क्या स्पॉट के इंस्टेंस का इस्तेमाल करने में कुछ कमियां हैं, सिर्फ़ कुछ समय के लिए उनकी उपलब्धता न दिखे? | हमने स्पॉट इंस्टेंस पर टेस्टिंग को प्राथमिकता नहीं दी है, क्योंकि हमारा सुझाव है कि विज्ञापन टेक्नोलॉजी की टीमें, ऑन-डिमांड इंस्टेंस का इस्तेमाल करें. स्पॉट इंस्टेंस का नुकसान यह है कि बजट खर्च करने के दौरान, जॉब में रुकावट आ सकती है. अगर बजट खत्म हो गया है और विज्ञापन टेक्नोलॉजी विशेषज्ञ को खास जानकारी वाली रिपोर्ट मिलने से पहले ही जॉब में रुकावट आ जाती है, तो विज्ञापन टेक्नोलॉजी विशेषज्ञ न सिर्फ़ जॉब को फिर से शुरू नहीं कर पाएंगे, बल्कि उन्हें बजट वापस पाने का अनुरोध करना होगा. हमारा सुझाव है कि निजता बनाए रखने के लिए, बजट रिकवरी का इस्तेमाल सिर्फ़ तब करें, जब कोई गंभीर समस्या आ रही हो. हमारा सुझाव है कि विज्ञापन टेक्नोलॉजी विशेषज्ञ, लागत कम करने के लिए ऑटोस्केल करने की सुविधा को कॉन्फ़िगर करें. ऑटोस्केल करने के लिए 0 चुनने का मतलब है कि जब तक किसी जॉब का अनुरोध नहीं किया जाता, तब तक कोई इंस्टेंस नहीं चलेगा. ध्यान दें कि अनुरोध के समय इंस्टेंस शुरू किए जाएंगे, इसलिए इंतज़ार का समय बढ़ सकता है. |
| पहले से जानकारी वाली गड़बड़ियां और उनके समाधान | एग्रीगेशन सेवा की जॉब में "सेवा में गड़बड़ी" दिखने के बारे में जानकारी | इस समस्या को यहां हल कर दिया गया है. हमने गड़बड़ी के अपने कुछ मैसेज को भी अपडेट किया है, ताकि उनकी जानकारी बेहतर तरीके से दी जा सके. उदाहरण के लिए, हमने AWS पर अनुमति/पुष्टि से जुड़ी ज़्यादा सटीक गड़बड़ियां दिखाना शुरू कर दिया है. पहले, ये गड़बड़ियां आंतरिक गड़बड़ियों के तौर पर दिखती थीं. हमने गड़बड़ी के कोड और उन्हें ठीक करने के तरीकों के बारे में दस्तावेज़ यहां अपडेट किए हैं. साथ ही, हम उन गड़बड़ियों के बारे में ज़्यादा सुझाव/राय/शिकायत/राय देने का स्वागत करते हैं जिनके बारे में दस्तावेज़ में नहीं बताया गया है या जो उपलब्ध नहीं हैं. साथ ही, यह भी बताएं कि कौनसी जानकारी आपके काम की होगी यहां. |
Private Aggregation API
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| मुख्य डिज़ाइन | निजी एग्रीगेशन पासकोड के डिज़ाइन से जुड़े दिशा-निर्देशों का अनुरोध करना | हमारे पास निजी एग्रीगेशन के लिए खास तौर पर बनाई गई गाइड नहीं है. हालांकि, एग्रीगेशन सेवा के लोड की जांच करने वाले फ़्रेमवर्क और बेहतर पासकोड मैनेजमेंट गाइड, दोनों का इस्तेमाल संसाधनों के तौर पर किया जा सकता है. |
| योगदान का बजट | योगदान के लिए बजट का हिसाब किस लेवल पर लगाया जाता है और वह किस लेवल पर सीमित होता है? | 10 मिनट की रोलिंग अवधि में योगदान का बजट 2^16 है और 24 घंटे की रोलिंग अवधि में 2^20. |
गुप्त ट्रैकिंग को सीमित करना
यूज़र-एजेंट रिडक्शन/यूज़र-एजेंट क्लाइंट हिंट
इस तिमाही कोई सुझाव नहीं मिला.
आईपी सुरक्षा (पहले इसे Gnatcatcher कहा जाता था)
| सुझाव की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| Android | Android पर आईपी पते की सुरक्षा की सुविधा को रोल आउट करने का प्लान क्या है? | हम Android में गुप्त तरीके से ट्रैकिंग रोकने की सुविधाएं लाने की कोशिश कर रहे हैं. इनमें आईपी प्रोटेक्शन भी शामिल है. हालांकि, फ़िलहाल हमारे पास इस बारे में कोई आधिकारिक जानकारी शेयर करने की योजना नहीं है. |
| एपीआई प्रयोग | क्या आपको यह सवाल पूछना है कि आईपी पते की सुरक्षा के लिए, धोखाधड़ी से जुड़ा कोई अपवाद है या नहीं? | हम उपयोगकर्ताओं को उनके आईपी पते के आधार पर, वेब पर ट्रैक किए जाने से बचाने की कोशिश करते हैं. साथ ही, हम सर्वर के सामान्य कामकाज में होने वाली रुकावट को कम करने की भी कोशिश करते हैं. इसमें, गलत इस्तेमाल को रोकने के लिए आईपी पते का इस्तेमाल करना भी शामिल है. फ़िलहाल, हम इस बारे में ज़्यादा जानकारी नहीं दे सकते. हालांकि, हम आने वाले समय में इस बारे में ज़्यादा जानकारी देंगे. साथ ही, इस बारे में चर्चा जारी रखने के लिए उत्साहित हैं. |
| बुरे मकसद से काम करने वाले लोगों या ग्रुप की पहचान करना | नुकसान पहुंचाने वाले आईपी पतों के ख़िलाफ़, सुरक्षा के पारंपरिक तरीकों के असरदार होने के बारे में चिंता. | आईपी प्रोटेक्शन, 1P अनुरोधों को प्रॉक्सी नहीं करेगा. इसलिए, हमें उम्मीद है कि घुसपैठ का पता लगाने वाले ज़्यादातर सिस्टम पर इसका असर नहीं पड़ेगा. हम आने वाले समय में, गुप्त मोड का इस्तेमाल करने वाले लोगों के लिए, धोखाधड़ी रोकने और साइट के क्रैश होने से जुड़ी समस्याओं के बारे में ज़्यादा जानकारी देंगे. |
| आईपी पते को मास्क करना | अगर समाचार प्रकाशक की साइट (1P) और विज्ञापन साइट (3P) का डोमेन एक ही है, तो क्या दोनों के लिए आईपी पता मास्क रहेगा? अगर ऐसा नहीं है, तो दोनों में अंतर कैसे किया जा सकता है? | फ़िलहाल, आईपी पते की सुरक्षा की सुविधा, सूची पर आधारित तरीके का सुझाव देती है. इससे यह पता चलता है कि तीसरे पक्ष का कौनसा ट्रैफ़िक, प्रॉक्सी के ज़रिए जाता है. हालांकि, भले ही ऑरिजिन उस सूची में हो, लेकिन 1P कॉन्टेक्स्ट में ऐक्सेस करने पर उसे प्रॉक्सी नहीं किया जाएगा. हम इस बात की जानकारी को फ़ाइनल कर रहे हैं कि शुरुआत में किन तीसरे पक्ष के डोमेन को प्राथमिकता दी जाएगी. साथ ही, हम आईपी सुरक्षा के लिए, पहले और तीसरे पक्ष के कॉन्टेक्स्ट को सटीक तरीके से कैसे तय करेंगे. |
| आईपी पते को मास्क करना | आईपी की सुरक्षा और धोखाधड़ी रोकने वाले सिस्टम पर इसके असर से जुड़ी चिंता. | आईपी सुरक्षा के हमारे प्लान का, पहले पक्ष (1P) पर कोई असर नहीं पड़ता. इसलिए, फ़ोरम जैसी साइटों के पास विवाद को हल करने के लिए आईपी पतों का ऐक्सेस होना चाहिए. हम भविष्य में, विज्ञापन धोखाधड़ी की चिंताओं से निपटने के लिए अतिरिक्त जानकारी उपलब्ध कराने की योजना बना रहे हैं. |
| आईपी पते को मास्क करना | क्या जिन डोमेन पर असर हुआ है उनके हेडर में आईपी मास्क किया गया है? | उपयोगकर्ताओं को किसी भौगोलिक इलाके में असाइन किया जाएगा. यह असाइनमेंट, प्री-प्रॉक्सी आईपी पते के आधार पर किया जाएगा. इस पते से, उपयोगकर्ता की मौजूदा जगह की जानकारी मिलती है. आपको ज़्यादा जानकारी यहां मिल सकती है. |
बाउंस ट्रैकिंग को कम करने की सुविधा
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| एपीआई स्पेसिफ़िकेशन | किसी टैब के बंद होने पर, Chrome के एक्सटेंडेड नेविगेशन को मैनेज करने के तरीके के बारे में जानकारी चाहिए. | हमने इस समस्या को यहां हल कर दिया है और इसके हिसाब से स्पेसिफ़िकेशन को अपडेट कर दिया है. |
| नेविगेशन ट्रैकिंग | क्रॉस-साइट अनुरोधों में एंट्रॉपी को कम करने के लिए, लिंक के सीमित सेट वाले ट्रैकिंग को लागू करने के तरीके के बारे में चर्चा की गई. | हम इस विषय पर, ब्राउज़र के अन्य वेंडर के साथ यहां चर्चा कर रहे हैं. साथ ही, हम इस समस्या के बारे में और सुझाव, राय या शिकायतें पाने के लिए तैयार हैं. |
प्राइवसी बजट
GitHub पर प्राइवसी सैंडबॉक्स के बारे में जानकारी और डेवलपर साइट में बताया गया है कि प्राइवसी सैंडबॉक्स के प्रपोज़ल में, प्राइवसी बजट को अब ज़्यादा अहमियत नहीं दी जा रही है
.
अलग-अलग साइटों पर निजता की सीमाओं को बेहतर बनाना
मिलती-जुलती वेबसाइट के सेट (पहले पक्ष के सेट)
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| (पिछली तिमाहियों में भी रिपोर्ट की गई) मिलती-जुलती वेबसाइट के सेट (आरडब्ल्यूएस) के डोमेन की सीमा | RWS में असोसिएटेड डोमेन की सीमा बढ़ाने का अनुरोध | हमारा जवाब पिछली तिमाहियों के जवाब से मिलता-जुलता है: फ़िलहाल, हमें संख्या की सीमा बढ़ाने की उम्मीद नहीं है. यह सीमा, उपयोगकर्ता की निजता को ध्यान में रखते हुए तय की गई है. साथ ही, W3C के नेटवर्क के हिस्सेदारों से मिले सुझावों और अन्य ब्राउज़र में लागू किए गए इसी तरह के फ़ंक्शन के आधार पर भी यह सीमा तय की गई है. ज़्यादा जानकारी के लिए, कृपया हमारी ब्लॉग पोस्ट (1, 2) देखें. हमारा सुझाव है कि ऐसे इस्तेमाल के उदाहरणों की जांच करें जिनमें संख्या की सीमा से ज़्यादा क्रॉस-साइट कुकी ऐक्सेस की ज़रूरत होती है. साथ ही, पहचान के इस्तेमाल के उदाहरणों, पुष्टि किए गए एम्बेड, और विज्ञापन के इस्तेमाल के उदाहरणों के लिए हमारे दिशा-निर्देशों का इस्तेमाल करें. अगर उपयोगकर्ता सेशन, लॉगिन ऐक्शन से जुड़े हैं, तो हमारा सुझाव है कि आप फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट (FedCM) एपीआई का इस्तेमाल करें, ताकि फ़ंक्शन को बनाए रखा जा सके. हम ऐसे अन्य इस्तेमाल के उदाहरणों के बारे में सुझाव, राय या शिकायत स्वीकार करते हैं जिनके लिए यहां संपर्क करें. |
| क्रॉस-साइट कुकी मैनेज करना | किसी सबडोमेन से सेट की गई क्रॉस-साइट कुकी, प्राइमरी डोमेन से आने वाले अनुरोधों में पास नहीं की जा रही हैं. सीओआरएस और क्रेडेंशियल के सही कॉन्फ़िगरेशन के बावजूद भी समस्या बनी रहती है. | हमने requestStorageAccessFor API के सही इस्तेमाल के बारे में यहां दिशा-निर्देश दिए हैं. इसके लिए, आपको पूरा ऑरिजिन (जैसे, सबडोमेन शामिल करना) बताना होगा, ताकि फ़ेच करने के बाद के अनुरोधों पर क्रॉस-साइट कुकी भेजी जा सकें. |
| उपयोगकर्ता के लिए उपलब्ध | उपयोगकर्ताओं को उनकी पसंद का विकल्प देने की सुविधा के रोल आउट के बाद, RWS के ज़रिए इस्तेमाल किए जाने वाले requestStorageAccessFor के बारे में ज़्यादा जानकारी का अनुरोध. खास तौर पर, यह जानना कि उपयोगकर्ता के जिस इशारों से फ़िलहाल तीन पीसी को ऐक्सेस करने की अनुमति मिलती है वे नए सिस्टम में कैसे काम करेंगे. | हमें उम्मीद है कि उपयोगकर्ता की पसंद के किसी भी मोड में आरडब्ल्यूएस का व्यवहार, Chrome में मौजूदा/शिपिंग के व्यवहार के मुताबिक होगा.भले ही, उपयोगकर्ताओं ने अपने 3पीसी को बनाए रखने या सीमित करने का विकल्प चुना हो. 3पीसी को अनुमति देने वाले मोड के मुकाबले, आरडब्ल्यूएस चालू होने पर 3पीसी को ब्लॉक करने वाले मोड में, Chrome का व्यवहार अलग-अलग होगा. आरडब्ल्यूएस चालू होने पर, "मिलती-जुलती साइटों को ग्रुप में आपकी गतिविधि देखने की अनुमति दें" सेटिंग का इस्तेमाल किया जाता है. हमारा सुझाव है कि requestStorageAccess को शुरू करने से पहले, यह देखने के लिए कि एम्बेड के पास पहले से अलग-अलग साइट पर मौजूद अन्य कुकी का ऐक्सेस है या नहीं, पहले hasStorageAccess को शुरू करें. अगर उपयोगकर्ता ने तीन पीसी को अनुमति दी है, तो hasStorageAccess तरीका 'सही' दिखाएगा. अगर तीन पीसी को अनुमति दी गई है, तो फ़िलहाल requestStorageAccessFor के लिए उपयोगकर्ता के जेस्चर की ज़रूरत नहीं है. हमने इस मामले में सही तरीका तय करने के लिए, GitHub पर एक नई समस्या दर्ज की है. हम इस बारे में चर्चा करने के लिए तैयार हैं. साथ ही, हम इकोसिस्टम से इस बारे में और सुझाव/शिकायत/राय पाने के लिए भी तैयार हैं. |
| एपीआई प्रयोग | "व्यावसायिक" मकसदों के लिए आरडब्ल्यूएस के इस्तेमाल के बारे में साफ़ तौर पर जानकारी न होने की वजह से, इसे अपनाने में आने वाली समस्याएं. हिस्सेदार ने टारगेट किए गए विज्ञापनों के लिए पब्लिकेशन को ग्रुप करने में दिलचस्पी दिखाई. | RWS का इस्तेमाल करने का मकसद, साइट के मुख्य फ़ंक्शन और उपयोगकर्ता के अनुभव को बेहतर बनाना है. हम टारगेट किए गए विज्ञापन से जुड़े इस्तेमाल के उदाहरणों के लिए, खास मकसद से बनाए गए विज्ञापन एपीआई का इस्तेमाल करने का सुझाव देते हैं. |
| एपीआई प्रयोग | requestStorageAccess से जुड़ी समस्या की रिपोर्ट, जिसमें localStorage डेटा सेट किया जा सकता था, लेकिन कुकी सेट नहीं की जा सकती थी. | यह समस्या, SameSite एट्रिब्यूट में टाइप होने वाली गड़बड़ी की वजह से हुई थी. पक्का करें कि स्पेलिंग सही हो. साथ ही, तीन पीसी के लिए इसे साफ़ तौर पर 'कोई नहीं' पर सेट करें. |
| एपीआई स्पेसिफ़िकेशन | पूरे रिपॉज़िटरी में JSON स्कीमा में अंतर, जैसे कि "संपर्क" फ़ील्ड का गलत तरीके से इस्तेमाल करना और सुधार के सुझाव. इनमें, "oneOf" कीवर्ड का इस्तेमाल करना शामिल है, ताकि एक जैसी जानकारी दी जा सके. | हम इस सुझाव की जांच कर रहे हैं. साथ ही, आने वाले समय में स्कीमा में ये सुधार करेंगे. अगर आपके पास कोई और सुझाव, शिकायत या राय है, तो यहां हमें बताएं. |
| RWS का तीसरे पक्ष (3P) ऐक्सेस | उपयोगकर्ता की सहमति मिलने पर, आउटलेट को उन तीसरे पक्ष के डोमेन की जानकारी देने की अनुमति दें जिनके पास भी RWS API के डेटा का ऐक्सेस होगा. | तीसरे पक्ष को अपने बिना बंटे हुए डेटा को RWS साइट के डेटा के साथ जोड़ने की अनुमति देने से, Privacy Sandbox की क्रॉस-साइट ट्रैकिंग की सुरक्षा कम हो जाएगी. हालांकि, हम तीसरे पक्ष को आरडब्ल्यूएस में डेटा को अलग-अलग हिस्सों में बांटने की सुविधा देने पर विचार कर रहे हैं. साथ ही, हम इस तरह के समाधान के डिज़ाइन के बारे में सुझाव, शिकायत या राय यहां मांग रहे हैं. |
Fenced Frames API
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| एपीआई से जुड़ा सवाल | बिना नेटवर्क ऐक्सेस वाले फ़ेंस किए गए फ़्रेम, विज्ञापन देने वालों के लिए ब्रैंड की सुरक्षा और धोखाधड़ी से सुरक्षा को कैसे नुकसान पहुंचा सकते हैं. | फ़ेंस किए गए फ़्रेम को लागू करने के अपने प्लान के तहत, हम इस समस्या पर नज़र बनाए हुए हैं. हम जल्द ही, फ़ेंस किए गए फ़्रेम लागू करने के तरीकों पर काम करना शुरू कर देंगे. साथ ही, जब भी हमारे पास कोई ऐसा सुझाव मिलेगा जो काम का होगा, हम उसे शेयर कर देंगे. |
| एपीआई से जुड़े सवाल | क्या Fenced Frames API अब भी 2026 के लिए शेड्यूल है? | हमारे सार्वजनिक एलान में बताया गया है कि फ़ेंस किए गए फ़्रेम का इस्तेमाल, साल 2026 से पहले नहीं करना होगा. |
| एपीआई की गड़बड़ी | जब reportEvent(), क्रॉस-ऑरिजिन सबफ़्रेम से क्लिक डेटा भेजता है, तो setReportEventDataForAutomaticBeacons() टॉप फ़्रेम के डेटा को ओवरराइट नहीं करता. |
हम इस समस्या पर चर्चा कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव/राय है, तो यहां बताएं. |
Shared Storage API
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| ऐप्लिकेशन विज्ञापन | Android पर Privacy Sandbox में, Shared Storage API जैसा कोई एपीआई नहीं है. | हम Android पर, इस्तेमाल के उदाहरण की ज़रूरतों और प्लैटफ़ॉर्म की सीमाओं के आधार पर समाधानों का आकलन कर रहे हैं. फ़िलहाल, इसे शेयर करने का हमारा कोई प्लान नहीं है. हालांकि, हम इस समस्या पर नेटवर्क से मिलने वाले अन्य सुझावों का स्वागत करते हैं. |
| एपीआई प्रयोग | Shared Storage API को लागू करने के लिए, किसी अन्य JavaScript वर्कलेट की ज़रूरत है या नहीं, इस बारे में भ्रम. |
हम इस सुझाव की जांच कर रहे हैं. साथ ही, Share Storage API के लिए अतिरिक्त वर्कलेट स्क्रिप्ट की ज़रूरत के बारे में बताने के लिए, अपने दस्तावेज़ को अपडेट करने पर विचार कर रहे हैं. |
| भरोसेमंद नहीं है | निजता से जुड़ी आलोचनाओं के आधार पर, शेयर किया गया स्टोरेज एपीआई काफ़ी बदल सकता है या उसे हटाया जा सकता है. इससे, इस एपीआई पर भरोसा नहीं किया जा सकता. | शेयर किए गए स्टोरेज के इन्फ़्रास्ट्रक्चर में कोई बड़ा बदलाव करने या इसे छोड़ने की हमारी कोई योजना नहीं है. चुने गए यूआरएल के आउटपुट गेट में मुख्य बदलाव किए गए हैं. यहां फ़ेंस किए गए फ़्रेम की ज़रूरत होगी और इवेंट लेवल की रिपोर्टिंग बंद कर दी जाएगी. हालांकि, ये बदलाव कम से कम 2026 तक लागू नहीं होंगे. |
सीएचआईपीएस
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| पार्टिशन की गई कुकी | Chrome, फ़्रेम के पूर्वजों के आधार पर, पार्टीशन कुंजियों में अंतर नहीं करता. ऐसा Firefox के उलट होता है. इस वजह से, गड़बड़ियां होती हैं. | Chrome ने सुरक्षा से जुड़ी समस्या को हल करने और Firefox के व्यवहार से जुड़ी गड़बड़ी को ठीक करने के लिए, "ऐंसेस्टर चेन बिट" को अपनाया है. हमने इस बारे में ज़्यादा जानकारी यहां दी है. |
| पार्टिशन की गई कुकी | अलग-अलग स्टोरेज ऐक्सेस लेवल वाले एम्बेड किए गए iframe, एक ही पार्टिशन की गई कुकी को शेयर और ओवरराइट करते हैं. इस वजह से, पुष्टि की स्थितियों में अंतर होता है. | इस खास कॉन्फ़िगरेशन के लिए, हमारा सुझाव है कि आप Storage Access API का इस्तेमाल करके, बिना बंटे हुए कुकी का इस्तेमाल करें. हमने इस बारे में ज़्यादा जानकारी यहां दी है. |
| पार्टिशन की गई कुकी | क्या 3PC बंद होने पर, पार्टिशन की गई कुकी के डिब्बे मिट जाएंगे? क्या इस व्यवहार की जांच करने का कोई तरीका है? | फ़िलहाल, हमारे पास कोई जानकारी शेयर करने का कोई प्लान नहीं है. हालांकि, डेवलपर इस सुविधा की जांच कर सकते हैं. इसके लिए, उन्हें Chrome DevTools ऐप्लिकेशन>कुकी पैनल में जाकर, अलग-अलग सेक्शन में बांटी गई कुकी को मैन्युअल तरीके से मिटाना होगा. |
FedCM
| सुझाव की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| आइडेंटिटी प्रोवाइडर (आईडीपी) रजिस्ट्रेशन का दायरा और संगठन चुनने वाला टूल |
आईडीपी रजिस्ट्रेशन को, एक ही ऑरिजिन की मौजूदा नीति से, एक ही साइट की नीति में बदलने के बारे में सवाल. इस बदलाव से, पहचान को ज़्यादा बड़े पैमाने पर और आसानी से मैनेज किया जा सकेगा. उदाहरण के लिए, किसी विश्वविद्यालय के वेलकम पेज पर, सबडोमेन पर आधारित पहचान की पुष्टि करने वाली कई सेवाओं को रजिस्टर किया जा सकेगा. इसके लिए, ऑरिजिन के हिसाब से अलग-अलग रजिस्ट्रेशन की ज़रूरत नहीं होगी. डीबग करने की सुविधा को बेहतर बनाने, साइलेंट मीडिएशन के लिए मंज़ूरी पा चुके क्लाइंट को मैनेज करने, कुकी के व्यवहार के बारे में जानकारी देने, पॉप-अप के शब्दों को पसंद के मुताबिक बनाने, और टाइम आउट से जुड़ी समस्याओं को हल करने के बारे में सुझाव, शिकायत या राय. |
हम इस सुझाव से सहमत हैं और इस पर विचार कर रहे हैं कि FedCM में संगठन चुनने वाले को कैसे शामिल किया जा सकता है. हम इस तरीके को बेहतर बनाने के लिए, नेटवर्क से जुड़े लोगों से ज़्यादा सुझाव, राय या शिकायतें पाने के लिए, यहां मौजूद हैं. |
| आईडीपी कुकी | डिवाइस बाउंड सेशन के क्रेडेंशियल (डीबीएससी) के प्रस्ताव के तहत, कुछ समय के लिए सेशन कुकी लागू करने के असर के बारे में चर्चा. FedCM में उपयोगकर्ता अनुभव को लेकर समस्याएं हैं, जहां आईडीपी (IdP) कुकी की समयसीमा खत्म हो गई है और रिन्यूअल के लिए, उपयोगकर्ता को दिखने वाले मॉडल की ज़रूरत होती है. | डीबीएससी के प्रस्ताव के मुताबिक, उपयोगकर्ता के इंटरैक्शन के बिना कुकी को रिन्यू किया जा सकता है. इससे उपयोगकर्ता को लगातार बेहतर अनुभव मिलता रहेगा. हमने इस समस्या के बारे में ज़्यादा जानकारी यहां दी है. |
| एपीआई स्पेसिफ़िकेशन | FedCM API स्पेसिफ़िकेशन में "NetworkError" का इस्तेमाल सही है या नहीं, इस बारे में सवाल. ऐसा तब होता है, जब "providers" कलेक्शन का साइज़ 1 से ज़्यादा हो. | हम इस बात से सहमत हैं कि इस स्थिति के लिए "TypeError" कोड ज़्यादा सही होगा, क्योंकि यह नेटवर्क की समस्या के बजाय कोडिंग की गड़बड़ी को दिखाता है. हम इस बदलाव पर विचार करेंगे और आने वाले समय में होने वाले अपडेट में इस पाबंदी को हटाने की संभावना तलाश करेंगे. ऐसा इसलिए, क्योंकि हम एक से ज़्यादा आईडीपी के साथ काम करने की सुविधा पर काम कर रहे हैं. हम यहां आपके और भी सुझाव, शिकायत या राय का स्वागत करते हैं. |
स्पैम और धोखाधड़ी से निपटना
Private State Token API (और अन्य एपीआई)
| सुझाव की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| बंद हो चुकी सुविधा को कुछ समय के लिए इस्तेमाल करने वाला ट्रायल और मोड B | बंद किए जाने के ट्रायल, मोड B टेस्टिंग, निजी स्टेटस टोकन (पीएसटी) के बंद होने की संभावना, और धोखाधड़ी रोकने के लिए इस्तेमाल के उदाहरण के हिसाब से, नए एपीआई के बेहतर होने की संभावना से जुड़ी चिंताएं. | बंद करने के ट्रायल और मोड B टेस्टिंग में कोई बदलाव नहीं होगा. हम डेवलपर ब्लॉग के ज़रिए, आपको सभी अपडेट देंगे. हम पीएसटी बंद करने वाले नहीं हैं. साथ ही, हम GitHub पर, सुविधा के डेवलपमेंट और अपडेट के बारे में चर्चा कर रहे हैं. हमने किसी नए एपीआई का एलान नहीं किया है. हालांकि, हम इस बारे में सुझाव, राय या शिकायत देने के लिए आपका स्वागत करते हैं कि पीएसटी, धोखाधड़ी रोकने के लिए इस्तेमाल के उदाहरणों को बेहतर तरीके से कैसे हल कर सकते हैं. |
| एपीआई से जुड़े सुझाव | धोखाधड़ी रोकने के लिए, टोकन रद्द करने की सुविधा का अनुरोध करें. | जारी करने वाला व्यक्ति, इस्तेमाल की जाने वाली कुंजियों को बदलकर सभी टोकन रद्द कर सकता है. हालांकि, एपीआई की मदद से किसी एक टोकन को रद्द नहीं किया जा सकता. ऐसा करने के लिए, जारी करने वाले व्यक्ति को टोकन जारी करने और रिडीम करने की अनुमति देनी होगी. इससे, दोनों इवेंट के बीच ट्रैकिंग को रोकने वाले पीएसटी निजता मॉडल का उल्लंघन होता है. |