گزارش بازخورد - 2024 Q1

گزارش فصلی برای سه ماهه اول سال 2024، خلاصه بازخورد اکوسیستم دریافت شده در مورد پیشنهادات جعبه ایمنی حریم خصوصی و پاسخ Chrome.

به‌عنوان بخشی از تعهدات خود به CMA، Google موافقت کرده است که گزارش‌های فصلی فرآیند تعامل با ذینفعان را برای پیشنهادات جعبه ایمنی حریم خصوصی خود به صورت عمومی ارائه کند (به پاراگراف‌های 12 و 17(c)(ii) تعهدات مراجعه کنید). این گزارش‌های خلاصه بازخورد جعبه ایمنی حریم خصوصی با جمع‌آوری بازخوردهای دریافتی توسط Chrome از منابع مختلف که در نمای کلی بازخورد فهرست شده است، ایجاد می‌شوند، از جمله اما نه محدود به: مشکلات GitHub، فرم بازخورد موجود در privacysandbox.com ، جلسات با سهامداران صنعت، و انجمن استانداردهای وب Chrome از بازخوردهای دریافتی از اکوسیستم استقبال می کند و به طور فعال در حال بررسی راه هایی برای ادغام آموخته ها در تصمیمات طراحی است.

مضامین بازخورد بر اساس شیوع در هر API رتبه‌بندی می‌شوند. این کار با جمع‌آوری مقدار بازخوردی که تیم Chrome در مورد یک موضوع خاص دریافت کرده و به ترتیب نزولی از نظر سازماندهی انجام می‌شود. مضامین رایج بازخورد با بررسی موضوعات بحث از جلسات عمومی (W3C، PatCG، IETF)، بازخورد مستقیم، GitHub و سوالات متداول مطرح شده از طریق تیم‌های داخلی Google و فرم‌های عمومی شناسایی شدند.

به طور خاص، صورتجلسات جلسات بدنه استاندارد وب بررسی شد و برای بازخورد مستقیم، سوابق Google از جلسات 1:1 ذینفعان، ایمیل‌های دریافتی توسط مهندسان فردی، فهرست پستی API و فرم بازخورد عمومی در نظر گرفته شد. سپس گوگل بین تیم‌های درگیر در این فعالیت‌های ارتباطی مختلف هماهنگ کرد تا شیوع نسبی موضوعات در حال ظهور در رابطه با هر API را تعیین کند.

توضیحات پاسخ‌های Chrome به بازخورد از پرسش‌های متداول منتشر شده، پاسخ‌های واقعی به مسائل مطرح‌شده توسط ذینفعان و تعیین موقعیت به‌ویژه برای اهداف این گزارش گزارش عمومی ایجاد شده است. با توجه به تمرکز فعلی توسعه و آزمایش، سؤالات و بازخوردها به ویژه در رابطه با موضوعات، مخاطبین محافظت شده و APIهای گزارش اسناد دریافت شد.

بازخورد دریافت شده پس از پایان دوره گزارش فعلی ممکن است هنوز پاسخی در نظر گرفته شده برای Chrome نداشته باشد.

واژه نامه کلمات اختصاری

آرا

Attribution Reporting API

چیپس

کوکی هایی که دارای حالت تقسیم شده مستقل هستند

DSP

پلتفرم سمت تقاضا

FedCM

مدیریت اعتبار فدرال

FPS

مجموعه های مهمانی اول

IAB

دفتر تبلیغات تعاملی

بیجاشدگان داخلی

ارائه دهنده هویت

IETF

نیروی ضربت مهندسی اینترنت

IP

آدرس پروتکل اینترنت

openRTB

مناقصه در زمان واقعی

OT

آزمایش مبدا

PAT API

API مخاطب محافظت شده (FLEDGE سابق)

PatCG

گروه اجتماعی فناوری تبلیغات خصوصی

RP

حزب اتکا

RWS

مجموعه‌های وب‌سایت مرتبط (سست‌های شخص اول سابق)

SSP

پلت فرم سمت عرضه

TEE

محیط اجرای مورد اعتماد

UA

رشته عامل کاربر

UA-CH

نکات مشتری عامل کاربر

W3C

کنسرسیوم وب جهانی

WIPB

کوری IP ارادی

بازخورد عمومی، بدون API یا فناوری خاص

موضوع بازخورد	خلاصه	پاسخ کروم
حکومت	علاقه به یک دوره نظر عمومی برای هر گونه به روز رسانی حاکمیتی به جعبه ایمنی حریم خصوصی.	ما آماده بازخورد منطقی ذینفعان در مورد هر گونه پیشرفت مهم در مورد Privacy Sandbox، از جمله حاکمیت آینده Privacy Sandbox هستیم.
آزمایش کردن	مراحل آزمایش اضافی برای 3PCD علاوه بر آزمایش فعلی 1٪ با تسهیل کروم.	ما قصد نداریم آزمایشی با تسهیل Chrome را فراتر از 1٪ ترافیک فعلی Chrome که از اوایل ژانویه فعال شده است، ارائه دهیم.
وب به برنامه	3PCD در دستگاه های تلفن همراه نباید قبل از دستیابی به قابلیت همکاری کامل بین وب و برنامه اتفاق بیفتد.	ما موافقیم که پشتیبانی از قابلیت همکاری برنامه و وب مطلوب است و اندازه‌گیری اسناد بین برنامه‌ها و وب را راه‌اندازی کرده‌ایم و در حال بررسی راه‌حل‌های هدف‌یابی وب به برنامه هستیم. با این حال، ما قصد نداریم 3PCD را در وب تلفن همراه به تاخیر بیندازیم. ما هدفی برای پوشش 100٪ در پایان 3PCD نداریم. در عوض، ما انتظار داریم که سازگاری در Android برای اندازه‌گیری بین برنامه‌ها و وب در 3PCD به میزان معقولی بالا باشد و به مرور زمان با به‌روزرسانی گوشی‌های کاربران افزایش یابد.
نقش مرورگر	به نظر می رسد کروم نقش یک سرور تبلیغاتی یا SSP را بر عهده می گیرد.	کروم نقش یک سرور تبلیغاتی یا SSP را بر عهده نمی گیرد. کروم با PA API محفظه‌ای برای سرورهای تبلیغات، SSP، DSP و سایر فناوری‌های تبلیغاتی فراهم می‌کند تا منطق امتیازدهی و پیشنهاد قیمت خود را ارائه دهند.
از راهنمای موردی استفاده کنید	راهنمای واضح‌تر در مورد موارد استفاده توسط APIهای Privacy Sandbox پشتیبانی می‌شود.	در ابتدای پروژه Privacy Sandbox، مستندات توسعه‌دهنده عمدتاً بر روی آوردن توسعه‌دهندگان به فرآیندهای بحث و بازخورد برای همه پیشنهادات متمرکز بود. این بدان معناست که محتوا به طور کلی حول درک انگیزه و مفاهیم پشت پروژه و به دنبال جزئیات توسعه اولیه و جزئیات آزمایش برای هر پیشنهاد ساخته شده است. این در ایجاد همکاری اکوسیستم واقعی در توسعه پیشنهادها مؤثر بود، اما با پیشرفت APIها تا دسترسی عمومی، مخاطبان جدیدی از توسعه دهندگان وجود دارند که در اینجا عمدتاً به جای مشارکت در توسعه اساسی آنها، بر اساس APIها ساخته شده اند. ما اخیراً ناوبری developer.google.com/privacy-sandbox را به‌روزرسانی کرده‌ایم تا روی موارد استفاده متمرکز شود، با استفاده از دسته‌بندی‌های مشابه با آزمایشگاه فناوری IAB در گزارش اخیر گروه وظیفه حریم‌کاری Sandbox. این رویکرد مبتنی بر موارد استفاده برای مستندات چیزی است که ما به آینده ادامه خواهیم داد.
محیط توسعه محلی	وقتی کوکی SameSite=Secure است و باطن با CDN جلو می رود، چگونه به توسعه و آزمایش ظاهر خود به صورت محلی در http://localhost ادامه دهیم؟	ما در اینجا در حال بحث در مورد این موضوع هستیم و از بازخورد اضافی از اکوسیستم استقبال می کنیم.
کاهش 3 PCD	آیا روشی برنامه‌ریزی برای دانستن اینکه 3PC مسدود شده‌اند یا زمانی که اکتشافی‌ها فعال هستند وجود دارد؟	در Chrome، هم تشخیص ویژگی و هم document.hasStorageAccess فراخوانی شده در iframe به برنامه‌نویس اجازه می‌دهد بداند مبدأ در iframe به 3 رایانه شخصی دسترسی دارد یا خیر.
تست ویدیویی	در حال حاضر نمی توان تبلیغات ویدیویی را در جعبه ایمنی حریم خصوصی آزمایش کرد.	کروم بحث و نشانی از چندین روش احتمالی را که می‌توان با PA API انجام داد، امروز ارسال کرد (به 242 و 254 در مخزن نمایشی ما در GitHub مراجعه کنید). توجه داشته باشید که اینها به‌عنوان کد نمونه‌ای در نظر گرفته نشده‌اند که فناوری‌های تبلیغاتی آن را به صورت عمده‌فروشی اتخاذ کنند، بلکه بیشتر به‌عنوان اثبات مفهوم و نمایش تکنیک‌هایی هستند که می‌توانند از رندر ویدیوی VAST با PA API پشتیبانی کنند. در طول این بحث، همچنین مشخص شد که در حالی که رندر ویدیو در حال حاضر امکان پذیر است، تغییراتی وجود دارد که Chrome می تواند انجام دهد که پیاده سازی با PA API را ساده می کند. به‌عنوان مثال، به‌روزرسانی‌های جایگزینی کلان ( که در اینجا بحث شده است) که قبلاً قصد داشتیم به آن‌ها بر اساس بازخورد در مورد موارد استفاده ایمنی نام تجاری تأییدکننده آگهی شخص ثالث رسیدگی کنیم، همچنین به بازخورد در مورد استفاده از ویدیو می‌پردازد، جایی که خریدار به دنبال کدام ماکروهای فروشنده است. برای استفاده در رندرینگ بیشتر بحث ها تا به امروز به ویژه بر روی ارائه تبلیغات ویدیویی VAST متمرکز بوده است. ارائه تبلیغات بومی می تواند از همین رویکردها استفاده کند و از بسیاری جهات آسان تر است. به نظر می رسد که Native در حال حاضر کمتر از ویدیو مورد توجه قرار گرفته است، اما این فقط یک مسئله اولویت بندی صنعت فناوری تبلیغات است، نه هیچ مانع فنی برای پیاده سازی.
اندازه گیری بدون تبلیغات	3PCD ممکن است راه حل های سنجش مخاطب غیر مرتبط با تبلیغات را تحت تاثیر قرار دهد.	API های اندازه گیری نیازی ندارند که مورد استفاده با تبلیغات مرتبط باشد. در حالی که ARA بیشتر مختص یک سفر تبلیغاتی معمولی است، تجمیع خصوصی یک هدف کلی است. این دو بلوک ساختمانی را می توان برای رسیدگی به طیف وسیعی از فعالیت های اندازه گیری استفاده کرد.
سازندگان محتوا	جعبه ایمنی حریم خصوصی به گونه‌ای طراحی شده است که سازندگان محتوا را تشویق کند تا محتوای بیشتری برای YouTube و کمتر در سایت‌های خود تولید کنند.	طرح Privacy Sandbox بر خصوصی نگه داشتن فعالیت افراد در اینترنت آزاد و آزاد متمرکز است. ما می دانیم که ناشران برای تولید محتوا و در دسترس قرار دادن آن تا حد امکان به تبلیغات متکی هستند. تبلیغ‌کنندگان به افراد کمک می‌کنند تا محصولات یا پیشنهادهایی را که ممکن است بخواهند کشف کنند. ویژگی‌های جعبه ایمنی حریم خصوصی به همه نوع وب‌سایت‌ها، از جمله آن‌هایی که با تولیدکنندگان محتوا کار می‌کنند، این امکان را می‌دهد تا تبلیغات مفیدی را بر اساس فعالیت‌هایشان با احزاب مختلف به افراد نشان دهند، بدون اینکه هویت کاربر را برای آن طرف‌ها فاش کنند.
جدول زمانی واضح تر	برنامه‌های انتشار واضح‌تر و دقیق‌تر برای فناوری‌های جعبه ایمنی حریم خصوصی.	اسناد API Sandbox Privacy شامل وضعیت API و صفحات در دسترس بودن است. این صفحات ویژگی های آینده و جدول زمانی آنها را فهرست می کنند (مانند PA API ، ARA ). یک نمای مرکزی از این وضعیت ها در اینجا وجود دارد.
فراگیری ماشین	تا زمانی که 3PCD از 1% فراتر نرود، فناوری‌های تبلیغاتی قادر به آموزش صحیح مدل‌های یادگیری ماشین نیستند.	گسترش 3PCD به مرورگرهای بیشتر برای آزمایش، تضمین نمی‌کند که APIها استفاده بیشتری را ببینند، که احتمالاً همان چیزی است که فناوری‌های تبلیغاتی برای آموزش بیشتر مدل‌های یادگیری ماشین به دنبال آن هستند. اگر استفاده گسترده‌تر از اکوسیستم چیزی نیست که فناوری‌های تبلیغاتی برای آموزش بیشتر مدل‌های یادگیری ماشینی به دنبال آن هستند، پس دلیلی برای گسترش 3PCD وجود ندارد زیرا یک فناوری تبلیغاتی که مایل به آموزش مدل‌هایی با ترافیک بیشتر است، امروز می‌تواند بدون افزایش 3PCD این کار را انجام دهد. این کار را می‌توان بدون اینکه کروم قبل از پایان Standstill روی 3PCD جلو برود انجام داد.
مورد استفاده پشتیبانی نشده	موارد استفاده از DSP سلف سرویس در حال حاضر در نظر گرفته نمی شود.	چندین DSP سلف سرویس وجود دارد که به طور منظم بازخورد عمومی را در مورد API ها ارائه می دهند. تعدادی از آن DSP ها که بازخورد عمومی منظمی ارائه می دهند نیز خود را به عنوان آزمایش کننده فهرست کرده اند. علاوه بر این، Chrome به طور فعال در موضوعات DSP خودسرویس معمولی مانند ویدئو و سرورهای تبلیغات شخص ثالث درگیر است. تماس های هفتگی اخیر PA API این موضوعات را پوشش داده است.
آزمایشی مبدا	درخواست برای OT برای سایت هایی که مایل به افزایش سطح شیب دار و پوشش آزمایشی برای 3PCD هستند.	Chrome در حال حاضر در حال توسعه یک OT شخص اول است که به شرکت‌های اصلی اجازه می‌دهد تا رفتار حذف مرحله‌ای 3PC را انتخاب کنند. مبداهای سطح بالایی که برای این آزمایشی ثبت نام می‌کنند و توکن‌ها را به کار می‌گیرند، 3 رایانه شخصی مسدود می‌شوند، گویی که دستگاه کاربر محافظت ردیابی را فعال کرده است. این OT فرصت ارزشمندی را برای سایت‌ها فراهم می‌کند تا آزمایش‌های گسترده‌تری را در مورد جایگزین‌های بلندمدت برای 3PC انجام دهند، قبل از خروج نهایی 3PC که پس از مشورت با CMA برنامه‌ریزی شده است. ما هنوز در حال کار برای نهایی کردن جدول زمانی برای عرضه OT هستیم.
گزارش آزمایشگاه فناوری IAB	بازخورد درباره جعبه ایمنی حریم خصوصی از گزارش آزمایشگاه فناوری IAB دریافت شد.	ما در اینجا به گزارش IAB Tech Lab به تفصیل پاسخ دادیم. ما همچنین اذعان کردیم که "این گزارش سوالاتی را در مورد اسناد پراکنده، الزامات تجاری، ممیزی های شخص ثالث، اعتبار بخشی صنعت، مقیاس پذیری، شفافیت و حاکمیت آینده مطرح می کند، که ما با اکوسیستم درگیر خواهیم شد و سوالات متداول عمومی خود را بر این اساس به روز خواهیم کرد." ما قبلاً به اسناد پراکنده پرداختیم. ما در اینجا به الزامات تجاری تحت «ضمانت‌های داده» می‌پردازیم و برخی از محصولات تبلیغاتی Google رویکردهای خود را به اشتراک گذاشته‌اند . ما در اینجا به حسابرسی های شخص ثالث تحت «ضمانت یکپارچگی الگوریتم» می پردازیم. در مورد اعتباربخشی، ما انتظار داریم که آن نهادها به اعتبار بخشیدن به محصولات، از جمله استفاده از فناوری‌ها، به جای استفاده از فناوری‌ها توسط خودشان، ادامه دهند. با توجه به مقیاس‌پذیری، ما همچنان پذیرای داده‌های توسعه‌دهندگانی هستیم که مشکلاتی را نشان می‌دهند. با توجه به شفافیت و حکمرانی، ما به توسعه در گیت هاب و در انجمن هایی مانند W3C ادامه می دهیم و در عین حال با CMA تحت تعهدات درگیر هستیم.
ورود به سیستم گوگل	ورود به سیستم Google منجر به این امکان برای Google می شود که از داده های ورود به سیستم شناسایی متقابل برخلاف تعهدات استفاده کند.	Google Sign-In Google را قادر نمی‌سازد که از داده‌ها برخلاف تعهدات استفاده کند.
سازگاری	برنامه‌هایی برای پشتیبانی از APIهای Sandbox Privacy و سازگاری رو به جلو و عقب چیست؟	هنگامی که Chrome یک ویژگی را در دسترس عموم قرار داد، هدف ما حفظ پشتیبانی از آن ویژگی است. البته همیشه نمی‌توان سازگاری با عقب را حفظ کرد و در چنین مواردی ما یک فرآیند واضح برای حذف و حذف ویژگی‌های موجود داریم که در اینجا توضیح داده شده است. ما انتظار داریم در طول زمان، در پاسخ به بازخورد اکوسیستم در مورد موارد استفاده که از پشتیبانی بهبودیافته بهره می‌برند، به افزودن ویژگی‌های بیشتری به APIهای Sandbox Privacy ادامه دهیم. در چنین مواردی، ما تمایل داریم که نوعی تکنیک تشخیص ویژگی را در نظر بگیریم، به طوری که یک فناوری تبلیغاتی که علاقه مند به آزمایش یک ویژگی جدید است، بتواند مستقیماً از مرورگر بپرسد که آیا این ویژگی پشتیبانی می شود یا خیر. این بهتر از این است که از توسعه دهندگان بخواهید شماره نسخه خاصی از Chrome را بررسی کنند، زیرا ممکن است برخی از ویژگی ها به طور همزمان برای همه کاربران Chrome ارائه نشوند. برای مثال، کار تشخیص ویژگی ما برای API PA را می‌توانید در اینجا پیدا کنید.
پیاده سازی سرور	به‌جای اتصال به پیاده‌سازی خود، Chrome باید رفتارهایی را مشخص کند که اجرای رضایت‌بخش سرور سیگنال‌های معتمد، سرور تجمع و سایر اجزای غیر مرورگر مورد نیاز باید رعایت شود. این امر نوآوری را در محدوده های قابل قبول حریم خصوصی امکان پذیر می کند.	ما از تمایل به نوآوری توسط طرف های خارجی قدردانی و استقبال می کنیم. برای همه APIها و سرویس‌ها، هدف ما ارائه انعطاف‌پذیری فناوری تبلیغات برای اجرای عملکرد آنها است. به عنوان مثال، ما به فناوران تبلیغات اجازه می دهیم از اطلاعات تجاری محرمانه در طراحی منطق مناقصه برای مزایده ها استفاده کنند. علاوه بر این، ما به طور مداوم با بازخورد فناوری های تبلیغاتی درگیر هستیم و در صورت موجه بودن، آن را در طرح های خود وارد می کنیم. برای اینکه دیگران بتوانند کد خود را در Trusted Execution Environments اجرا کنند، Privacy Sandbox باید کد (و هرگونه تغییر) را بررسی کند تا تأیید کند که ضمانت‌های حریم خصوصی را رعایت می‌کند. این به تلاش قابل توجهی از طرف تیم Privacy Sandbox نیاز دارد. بنابراین، ما می‌خواهیم بدانیم که ذینفعان به دنبال دستیابی به چه مزایایی هستند که امروزه توسط ما برآورده نشده است.
اکتشافی	برنامه های بلند مدت برای اکتشافی چیست؟	مطابق با آنچه مرورگرهای دیگر نشان داده اند، ما قصد داریم در نهایت با استفاده گسترده از راه حل های جایگزین، این اکتشافی ها را کنار بگذاریم، مشروط به تحلیل امکان سنجی بیشتر. ما این را در اینجا به اشتراک گذاشته ایم.
حجم تست	حجم ترافیک متفاوت هنگام مقایسه ابعاد مختلف.	آزمایش 1٪ دارای معیارهای خروج است که منجر به تفاوت در صلاحیت برای آزمایش، بین جمعیت های مختلف مشتریان Chrome می شود. برای مثال، آزمایش کاربران Chrome Enterprise را مستثنی می‌کند ، بنابراین انتظار می‌رود که کسری از ترافیک با برچسب‌های آزمایشی در آخر هفته‌ها بیشتر باشد. مشاهده درصدهای مختلف ترافیک در بخش‌های مختلف داده (مانند جغرافیا، تاریخ و پلتفرم) قابل انتظار است، و این مطابق با آنچه در داده‌های کروم می‌بینیم است.
3PC را به صورت دستی دوباره فعال کنید	آیا سایت ها می توانند بدانند که چند کاربر (٪) پس از اجرای 3PCD کوکی ها را به صورت دستی دوباره فعال کرده اند؟	کاربران می توانند در صورت مواجهه با شکستگی، دسترسی 3PC را در سطح سایت از طریق User Bypass دوباره فعال کنند. رایانه‌های شخصی 3 نیز ممکن است با اقدامات دیگری مانند Storage Access API دوباره فعال شوند. اقدامات فنی مانند hasStorageAccess() وجود دارد که به سایت ها اجازه می دهد تشخیص دهند که آیا 3PC ها فعال یا غیرفعال هستند. با این حال، Chrome راهی را برای وب‌سایت‌ها برای دانستن دلایل فعال‌سازی مجدد تسهیل نمی‌کند.
حفاظت ردیابی	ویژگی رابط کاربری حفاظت از ردیابی Chrome تا چه زمانی در دسترس خواهد بود؟	پیش‌بینی می‌شود که رابط کاربری Tracking Protection در نوار آدرس پس از منسوخ شدن 3PC باقی بماند.
(در فصل های گذشته نیز گزارش شده است) پشتیبانی از مرورگرهای مختلف	سایر فروشندگان مرورگر که از APIهای Privacy Sandbox استفاده می کنند.	سایر فروشندگان مرورگر، مانند اپل، موزیلا و مایکروسافت، شرکت کنندگان فعالی در تالارهای گفتمان عمومی هستند که در آن اصول حفظ حریم خصوصی و رویکردهای مبتنی بر مرورگر مورد بحث قرار می گیرد. ما از بحث های مشترک در انجمن هایی مانند نشست اخیر TPAC سالانه W3C و انجمن های W3C PATCG در حال انجام که در آن نشانه هایی از همگرایی را می بینیم، تشویق می شویم. به عنوان مثال، مایکروسافت اج اخیراً طرح خود را اعلام کرد که هدف آن "به حداکثر رساندن سازگاری نحوی" با PA API و ARA است و در عین حال ویژگی های اضافی را برای توسعه دهندگان ارائه می دهد.
گزینه بازگشتی برای جاسازی های ناسازگار پس از 3PCD	قلاب‌های API را برای تشخیص اینکه آیا یک iframe/embed شخص ثالث با 3PCD مطابقت دارد یا خیر، فراهم کنید.	ما در اینجا در حال بحث در مورد درخواست هستیم و از بازخورد اضافی از اکوسیستم استقبال می کنیم.
آزمایش کردن	درخواست پرچم‌های اضافی در نمونه‌های مدیریت‌شده Chrome که رفتارهای سفارشی‌شده را موقتاً خاموش می‌کند.	ما در حال بررسی این درخواست برای نمونه‌های مدیریت‌شده Chrome هستیم و اگر چنین پرچمی مفید باشد، از ورودی‌های اضافی از اکوسیستم استقبال می‌کنیم.

ثبت نام و تاییدیه

موضوع بازخورد	خلاصه	پاسخ کروم
تأیید گواهی	چگونه گوگل از صحت گواهینامه ها اطمینان می دهد؟	همه ثبت نام کنندگان موظفند هنگام استفاده از APIها، فایل گواهی را در محل خود نگه دارند. Google تأیید می‌کند که فایل در جای خود است و نحو درست است، اما Google رفتار فناوری تبلیغات را با توجه به زبان گواهی تأیید نمی‌کند.
فرآیند ثبت نام API جمع آوری خصوصی	آیا راهی برای بررسی وضعیت ثبت نام Private Aggregation API وجود دارد؟	پس از تایید ثبت نام، به تمامی ثبت نام کنندگان تایید شده از طریق ایمیل از تیم پشتیبانی ثبت نام مطلع می شود. اگر ثبت نام کننده در طول فرآیند سؤالی داشته باشد، می تواند با تیم پشتیبانی (که پس از ارسال فرم ثبت نام با آنها در ارتباط است) تماس بگیرد. تیم پشتیبانی پاسخ خواهد داد و به سؤالات پاسخ می دهد و هر گونه راهنمایی اضافی که لازم باشد ارائه می دهد.

نمایش محتوا و تبلیغات مرتبط

موضوعات

موضوع بازخورد	خلاصه	پاسخ کروم
(در فصل های گذشته نیز گزارش شده است) جدول زمانی طبقه بندی کننده و مستندات	باید مکانیزمی وجود داشته باشد تا طبقه بندی بررسی شود یا حداقل شفافیت بیشتری در مورد نحوه طبقه بندی دسته بندی ها وجود داشته باشد.	پاسخ ما نسبت به فصل های گذشته بدون تغییر است: "طبقه بندی نادرست سایت ها ممکن است سیگنال Topics را به طور کلی کمی کمتر مفید کند، اما سایت های خاصی که به اشتباه طبقه بندی شده اند، بیشتر و کمتر از سایر سایت ها آسیب نمی بینند. این به این دلیل است که اطلاعات متنی یک سایت همیشه برای آنها در دسترس خواهد بود. حراج در سایت خود، که اطلاعات قابل مقایسه با موضوع صحیح را ارائه می دهد، حتی در صورت طبقه بندی اشتباه، ما از بازخورد در مورد این موضوع در اینجا استقبال می کنیم.
Google Ad Manager	Google Ad Manager در حال حاضر در اکثر سایت ها تعبیه شده است و اطلاعات بسیار گسترده تری در مورد موضوعات کاربر نسبت به رقبایانی که در سایت های کمتری حضور دارند، خواهد داشت.	الزام مشاهده برای اطمینان از اینکه Topics API منجر به اشتراک گذاری داده های کاربر با نهادهای بیشتری نسبت به فناوری هایی که API جایگزین آن می شود (از جمله 3PC) وجود ندارد. راه حل های صنعتی دیگر مانند Prebid با 10000 سایت کار می کند و به فعالان بازار امکان می دهد تا از طریق فناوری خود با Topics API تماس بگیرند. علاوه بر این، شایان ذکر است که محدودیت حداکثر 5 موضوع برتر در هفته ممکن است اثر برابری داشته باشد، زیرا فعالان بازار در بسیاری از سایت‌ها که ممکن است بتوانند بیش از 5 موضوع را با استفاده از 3PC یاد بگیرند، به 5 محدود می‌شوند.
(در فصل های گذشته نیز گزارش شده است) سودمندی برای انواع مختلف ذینفعان	نگرانی در مورد ارزش ایجاد شده و توزیع آن ارزش برای سایت ها بسته به سطح ترافیک آنها یا میزان تخصصی بودن محتوای آنها.	ما می‌دانیم که سایت‌های تخصصی به احتمال زیاد بیشتر از حوزه‌های علاقه عمومی به موضوعات مفصل‌تری کمک می‌کنند. با این حال، همه سایت های تخصصی موضوعات ارزشمند تجاری را ارائه نمی دهند. همچنین، این پویا منعکس کننده وضعیت موجود است و کاملاً مستقل از پایان پشتیبانی از 3PC در کروم است. همچنین در محیط فعلی، برخی از سایت‌ها ارزش بیشتری نسبت به سایرین در سیستم‌های مرتبط آگهی مبتنی بر 3PC ارائه می‌کنند. علاوه بر این، موضوعات در بین سایت‌های تخصصی می‌توانند برای یکدیگر مفید باشند، زیرا تبلیغ‌کنندگان مختلف می‌توانند کمپین‌هایی را در مجموعه‌های متنوعی از موضوعات اجرا کنند و منطق مناقصه می‌تواند ارزش را در طیف وسیعی از موضوعات مشاهده کند.
نام هاست در مقابل URL های کامل	آیا طبقه بندی بر اساس نام میزبان وب سایت ها به اندازه کافی مؤثر است و آیا این امر خطر حفظ حریم خصوصی را در مقایسه با URL های کامل کاهش می دهد؟	ما استفاده از نشانی‌های اینترنتی اطلاعات یا عناوین صفحه را علاوه بر نام میزبان در نظر گرفتیم و به این نتیجه رسیدیم که مزایای بالقوه با خطرات برای حریم خصوصی و امنیت کاربر غلبه خواهد کرد. نمونه ای از خطرات حریم خصوصی کاربر شامل طبقه بندی اطلاعات حساس موجود در URL یا عنوان صفحه در موضوعات کاربر است.
موضوعات به عنوان یک سیگنال	درخواست راهنمایی در مورد نحوه ترکیب موضوعات با سیگنال های دیگر و اینکه چه سیگنال های دیگری می تواند مفید باشد.	راه‌حل‌های فناوری تبلیغات می‌توانند با ترکیب همه ابزارهای موجود، مانند یادگیری ماشینی و سیگنال‌های ایمن حریم خصوصی از APIهای حفظ حریم خصوصی، همراه با داده‌های متنی، داده‌های خلاقانه و داده‌های شخص اول، بهترین نتایج را باز کنند. راهنمایی بیشتر در این مورد در اینجا موجود است.

API مخاطب محافظت شده (FLEDGE سابق)

موضوع بازخورد	خلاصه	پاسخ کروم
تست حجم ترافیک	آزمایش‌کنندگان حجم کم پاسخ پیشنهادی را برای حراج PA API گزارش می‌کنند.	1. تراکم قیمت پیشنهادی با مشارکت اکوسیستم در PA API مرتبط است، که پیش‌بینی می‌کنیم در طول سال 2024 و پس از آن افزایش یابد. تعیین نحوه تخصیص بودجه کمپین در نهایت بر عهده تبلیغ کنندگان، آژانس ها و ارائه دهندگان فناوری آنهاست. ما انتظار داریم برخی از شرکت کنندگان در اکوسیستم ممکن است سرمایه گذاری خود را در راه حل های مختلف "بدون کوکی" از جمله PA API تا بعد از 3PCD به تاخیر بیندازند. در آن زمان ما انتظار داریم که آنها ممکن است تخصیص بودجه کمپین خود را به چنین راه حل هایی افزایش دهند. 2. حجم درخواست‌های پیشنهادی در حراج‌های PA API ممکن است تحت تأثیر (1) باشد، زیرا ناشران و ارائه‌دهندگان فناوری تبلیغاتی آن‌ها ممکن است تصمیم بگیرند اگر احساس کنند تقاضا کم است، حراج‌های PA API را آغاز نکنند. این به ناشران بستگی دارد که اولویت به‌روزرسانی صفحات و مشارکت را تعیین کنند. ما پیش‌بینی می‌کنیم که ناشران به این دلایل برای آزمایش و افزایش تدریجی ترافیک وقت بگذارند. این گزارش همچنین شامل پاسخی از Google Ad Manager درباره کنترل‌های ناشر آن برای مشارکت PA API است.
(در فصل های گذشته نیز گزارش شده است) کلاهبرداری / سوء استفاده	چگونه اکوسیستم می تواند خطرات را کاهش دهد و بازیگران یا خریداران بد را از قرار دادن خود به عنوان یک مخاطب مطلوب باز دارد؟	مکانیسم‌های گزارش‌دهی تبلیغات PA API اطلاعاتی را که امروزه برای تشخیص انسان از ترافیک ربات استفاده می‌شود، حفظ می‌کند. علاوه بر این، تکنیک های فعلی مبتنی بر دامنه شامل یا حذف دامنه ها را می توان در PA API استفاده کرد. این با جزئیات بیشتر در پاسخ ما به گزارش IAB Tech Lab درباره Privacy Sandbox توضیح داده شده است.
همان محدودیت مبدا در مالک IG و URL منطق پیشنهاد قیمت	با الزامات مبدأ یکسان، نقاط پایانی برای مالک IG مجبور خواهند شد از همان بار متعادل کننده عبور کنند، که ممکن است منجر به رد تغییر مسیرها شود.	نیاز یکسان برای بارگذاری اسکریپت یک حفاظت امنیتی مهم است. جزئیاتی در مورد راه حل پیشنهادی در اینجا وجود دارد که بازخورد اکوسیستم و سایر ملاحظات را در اینجا متعادل می کند.
حراج خصوصی چند اسلات	فضای زیادی برای اجازه دادن به حراج خصوصی چند اسلات در محدوده حریم خصوصی با استفاده از نویز و ادغام دقیق تر با شیوه های تبلیغاتی فعلی وجود دارد.	ما در حال بررسی این بازخورد و ارزیابی درخواست برای حراج چند برچسب در برابر افزایش پیچیدگی و خطرات حفظ حریم خصوصی مرتبط با این ویژگی هستیم. ما این موضوع را در طی تماس گروه انجمن انکوباتور وب PA API (WICG) در اینجا بیشتر مورد بحث قرار دادیم.
فروشندگان سطح بالا	ساختار فعلی PA API داده‌ها و درک قابل‌توجهی از ارزش نسبی نمایش‌ها را نسبت به ناشران یا فروشندگان مؤلفه به هر فروشنده سطح بالایی ارائه می‌دهد.	در حراج چند فروشنده، هر فروشنده بهترین پیشنهاد را خواهد داشت. علاوه بر این، از اکوسیستم آموخته ایم که ناشران ممکن است بخواهند تقاضای فروش مستقیم را در کنار بهترین پیشنهادهای هر فروشنده ای که با آن کار می کنند، در نظر بگیرند. نگاهی به همه این فرصت‌های بالقوه کسب درآمد برای تعیین اینکه کدام تبلیغ ارائه شود، ضروری است. این وضعیت، که در آن لازم است برخی از بازیگران مجموعه کاملی از گزینه‌ها را ببینند تا تبلیغی را برای ارائه انتخاب کنند، پیش از PA API است. PA API به دنبال حمایت از حراج های چند فروشنده و تمایل ناشران برای در نظر گرفتن بهترین پیشنهاد هر فروشنده در کنار کمپین های تبلیغاتی فروش مستقیم است، جایی که مورد دوم قابل اعمال است. این بدان معناست که باید مکانیزمی وجود داشته باشد که از بین آن فرصت‌های کسب درآمد مانند امروز انتخاب شود. ما فکر نمی‌کردیم که وظیفه مرورگر این باشد که کدام تبلیغ را انتخاب کند. بنابراین مفهوم یک فروشنده سطح بالا برای انتخاب یک تبلیغ برنده از بسیاری از احتمالات ضروری است. منطق فروشنده سطح بالا باید بتواند بهترین پیشنهادها را از هر فروشنده ای که ناشر برای کار با آن انتخاب می کند در نظر بگیرد. و منطق فروشنده ممکن است انتخاب کند که اطلاعاتی درباره کمپین های فروش مستقیم ناشر در جایی که این اطلاعات در دسترس است ارائه دهد. همه این اطلاعات را می توان در منطق انتخاب تبلیغات سطح بالا در نظر گرفت. این بدان معناست که منطق سطح بالا بهترین پیشنهادها را از حراج PA API و در صورت لزوم، هر گزینه تبلیغاتی فروش مستقیم ناشر را برای تعیین برنده می بیند. Google Ad Manager اجرای PA API خود را به عنوان یک فروشنده سطح بالا در این گزارش با موضوع " دسترسی به اطلاعات " شرح می دهد.
جداسازی تبلیغات رقابتی	درخواست جداسازی تبلیغات رقابتی، مانند جلوگیری از نمایش تبلیغات از برندهای رقیب در کنار یکدیگر.	ما از راهی برای اطمینان از جدایی رقابتی در اکوسیستم تبلیغات دیجیتال برنامه‌ریزی‌شده، پیشنهادی و چند فروشنده امروزی بی‌اطلاع هستیم. با این حال، PA API فروشندگان را قادر می‌سازد تا سیگنال‌های بی‌درنگ اضافی را بر اساس ترکیبی از renderURL و نام میزبان (نماینده دامنه ناشر) واکشی کنند که می‌تواند در حین امتیازدهی خلاقیت‌ها در طی ScoreAd() استفاده شود. این ممکن است توسط فروشندگان برای جلوگیری از نمایش تبلیغات مارک های رقیب در کنار یکدیگر استفاده شود، با این فرض که ناشر مایل به اجرای این قانون است.
اطلاعات محدود	PA API اطلاعات موجود برای ناشران مانند ارزش آگهی، نام خریدار جزء، نام تبلیغ‌کننده، URL صفحه فرود، اندازه خلاقانه، زمان پاسخ‌دهی، و نرخ پیشنهاد و همچنین از دست دادن پیشنهادها را کاهش می‌دهد.	ما در اینجا راه حل های بالقوه ای را پیشنهاد کرده ایم و از بازخورد اضافی از اکوسیستم استقبال می کنیم.
گزارش در سطح رویداد	ناشران نمی‌توانند اطلاعات کافی درباره آگهی ارائه شده پس از منسوخ شدن API گزارش‌دهی در سطح رویداد دریافت کنند.	ما از موارد مختلف استفاده از گزارش‌گیری آگاه هستیم که باید در صورت بازنشستگی گزارش‌دهی در سطح رویداد به حمایت از آنها ادامه دهیم. به همین دلیل است که ما تاریخ بازنشستگی گزارش‌دهی در سطح رویداد را زودتر از سال 2026 هدف‌گذاری کرده‌ایم. در طول زمان از هم‌اکنون تا آن زمان، از مشارکت فعال دعوت می‌کنیم زیرا با اکوسیستم در مسیرهای بادوام رو به جلو درگیر هستیم که می‌تواند شامل ایده‌های جدیدی برای به دست آوردن اطلاعات به روش حفظ حریم خصوصی
SSP های متعدد	ارزش افزوده از داشتن چندین SSP برای ناشران بسیار کم خواهد بود.	ما معتقد نیستیم که این درست است و از بازخورد اضافی از اکوسیستم برای درک دلیل این ادعا استقبال می کنیم.
فعالیت های سرپرستی	فعالیت های سرپرستی با PA API امکان پذیر نیست.	ما بازخوردهایی در مورد توانایی فروشندگان برای استفاده از PA API برای ارائه اطلاعات مخاطبان خود به خریداران در سراسر وب شنیده‌ایم (افزونه مخاطب AKA). ما معتقدیم که این امر امروز با استفاده از قابلیت تفویض اختیار PA همراه با قراردادهای تجاری امکان پذیر است. همزمان، ما فعالانه در حال بررسی این موضوع هستیم که آیا و چگونه می‌توانیم این نوع موارد استفاده را بهتر تطبیق دهیم.
انصراف خریدار	انصراف پیش‌فرض خریدار احتمالاً منجر به نتایج کمتری برای حراج قطعات می‌شود.	چه برای تعیین حراج PA تک فروشنده یا چند فروشنده، فروشنده باید به صراحت خریداران را در قسمت interestGroupBuyers در AuctionConfig لیست کند. این بر اساس بازخورد اکوسیستم است که فروشندگان با برخی از خریداران و نه دیگران توافقات قراردادی دارند، بنابراین نیاز به کنترل صریح بر اینکه کدام خریداران را در حراج قرار دهند، دارند. ما از بحث بیشتر در مورد GitHub استقبال می کنیم.
Adsize	امکان انجام پیش فیلتر بر اساس adsize و adSlotSize وجود ندارد.	ما در حال کار بر روی افزودن این قابلیت هستیم و جزئیات بیشتر در اینجا موجود است.
پشتیبانی از هدف گذاری منفی IG	یک API برای پشتیبانی از هدف گذاری منفی IG: نمایش تبلیغات تنها در صورتی که کاربر به یک IG تعلق نداشته باشد.	این مشکل GitHub یک راه جایگزین برای پیاده‌سازی هدف‌گیری منفی پیشنهاد کرد، که در آن مرورگر مستقیماً به سرور تبلیغات می‌گوید کدام قوانین هدف‌گیری منفی باید برای یک درخواست تبلیغات خاص اعمال شود. در حالی که این یک رویکرد جذاب به نظر می رسد، همه نسخه های این ایده که ما بررسی کرده ایم به این نتیجه رسیده اند که سرور را قادر می سازد تا کاربر را به طور منحصر به فرد شناسایی کند.
قانون خدمات دیجیتال	چگونه یک ناشر می‌تواند از قاب‌های حصاردار استفاده کند اما از ارائه پاسخ‌های حاوی اطلاعات مشمول قانون خدمات دیجیتال نیز جلوگیری کند؟	مانند هر فن آوری جدید، هر شرکت مسئول اطمینان از این است که استفاده از جعبه ایمنی حریم خصوصی مطابق با قانون است. Google قادر به ارائه مشاوره حقوقی به دیگران نیست. برای هر API، ما مستندات فنی گسترده‌ای منتشر کرده‌ایم که باید مبنایی را برای ارزیابی‌های قانونی لازم فراهم کند. قاب‌های حصاردار برای استفاده در PA API زودتر از سال 2026 لازم نیست، به ذینفعان زمان بیشتری می‌دهد تا اطمینان حاصل کنند که استفاده آنها از این فناوری مطابق با تمام قوانین مربوطه است.
مستندات	آیا updateAdInterestGroups() موقتی است؟	ما هیچ برنامه ای برای منسوخ کردن updateAdInterestGroup اعلام نکرده ایم. در آینده، ما ممکن است از محافظت های حریم خصوصی مشابهی که به طور عمومی در مورد مکانیسم های به روز رسانی IG صحبت کرده ایم، استفاده کنیم، به عنوان مثال استفاده از یک آدرس IP همچنین پروکسی و اضافه کردن مقداری تاخیر قبل از به روز رسانی.
پشتیبانی از متادیتا و مالکیت منطقی Buyside برای غیر DSPها	درخواست راهی برای عمل به عنوان یک پروکسی برای DSPها.	ما از این بازخورد از بخش‌های غیر DSP آگاه هستیم و در حال بررسی این درخواست هستیم. ما از بازخورد اضافی از اکوسیستم استقبال می کنیم.
گزارش نویسی	درخواست اضافه کردن ویژگی کنترل کننده سفارشی برای سطل سیگنال ها / مقدار در گزارش جمع آوری خصوصی.	ما آگاه هستیم و این درخواست ویژگی در صف ما برای کشف بیشتر است. ما از بازخورد اضافی از اکوسیستم در اینجا استقبال می کنیم.
مستندات	آیا پیوندی وجود دارد که در آن امکان مشاهده تمام سرصفحه های پاسخی که باید توسط تبلیغ کننده و دامنه مالک (تخصیص شده) تنظیم شود وجود دارد؟	ما در حال برنامه ریزی به روز رسانی اسناد برای روشن شدن این موضوع و استقبال از بازخورد اضافی از اکوسیستم هستیم.
مناقصه چند برج	درخواست توضیح گردش کار (آموزش و استنباط) از طریق یک نمودار معماری / بلوک در مورد چگونگی پیش بینی رویکرد چند برج در زمینه PA API.	از بازخورد شما سپاسگذاریم. ما چند ارائه در مورد این موضوع داریم که پیش‌بینی می‌کنیم مستندات بیشتری از آن بسازیم.
هدف گذاری منفی	قابلیت Privacy Sandbox برای محافظت از مخاطبان حساس و خردسالان در برابر تبلیغات نامناسب، به عنوان مثال قمار.	API PA محتوای تبلیغات نشان داده شده را در نظر نمی گیرد. این در کنترل توسعه دهندگان فناوری تبلیغات با استفاده از PA است. به طور کلی، ناشر و ارائه‌دهندگان فناوری تبلیغاتی آن‌ها می‌توانند با استفاده از اطلاعات متنی صفحه و همچنین مجموعه‌های قوانین ناشر، خلاقیت‌های تبلیغاتی را در حراج‌های مخاطب محافظت‌شده مسدود کنند. این آینه درک ما از رویکرد اکوسیستم به این چالش‌های امروزی است. برای خریداران، عملکرد هدف‌گیری منفی IG نیز ممکن است برای برخی موارد استفاده از انطباق مفید باشد.
طراحی API	Google در حال عقب‌نشینی است و از فن‌آوران تبلیغات می‌خواهد که از یک تابع مناقصه جهانی استفاده کنند و در نتیجه تأخیر را افزایش دهند، به جای biddingLogicURL‌های مختلف در IGهای مختلف که مجاز است.	در طول بحث‌هایمان درباره تأخیر حراج، تأکید کرده‌ایم که استفاده مجدد از یک اسکریپت در همه IGهای خریدار باعث می‌شود پیشنهاد خریدار سریع‌تر انجام شود. این با جزئیات بیشتر در اینجا همراه با توصیه های دیگر ما برای بهبود تاخیر حراج PA API ارائه شده است.
بازاریابی مبتنی بر حساب	PA API یک API تمیز برای موارد استفاده بازاریابی مبتنی بر حساب نیست.	ما از بازخورد اکوسیستم در مورد موارد استفاده خاص استقبال می کنیم که معتقدند آنها ممکن نیست و شرکت کنندگان در اکوسیستم را ترغیب می کند تا این بحث را از طریق مخزن عمومی GitHub یا تماس های هفتگی ما ادامه دهند.
تست A/B	هنگامی که PA API در GAM برای یک ناشر پیکربندی شده است ، در حال حاضر باید برای همه موجودی یا هیچ یک فعال شود. این توانایی ناشران را در اجرای یک تست A/B مناسب محدود می کند.	پاسخ ارائه شده توسط Google Ad Manager: کنترل PA API در Google Ad Manager (GAM) بر توانایی GAM در استفاده از API تأثیر می گذارد ، مشروط بر اینکه API برای استفاده در دسترس باشد. بنابراین ، ناشران می توانند با استفاده از عملکرد سیاست مجوزهای Chrome ، آزمایش های A/B را انجام دهند تا استفاده از API را در زیر مجموعه ای از ترافیک غیرفعال کنند تا به عنوان بازوی کنترل برای آزمون A/B استفاده کنند.
فراگیری ماشین	ناشران نیاز به کنترل بیشتری بر استفاده پیشنهادی GAM از یادگیری ماشین دارند.	پاسخ ارائه شده توسط Google Ad Manager: در ژانویه سال 2024 ، ما یک کنترلی را راه اندازی کردیم که به ناشران این امکان را می دهد تا بتوانند یادگیری ماشین ما را غیرفعال کنند و حراج های PA API را با فروشندگان غیر گوگل در تمام ترافیک خود فعال کنیم. جزئیات بیشتر در مورد این کنترل را می توان در مرکز کمک ما یافت.
(همچنین در سه ماهه قبلی گزارش شده است) حراج های سطح بالا	امکان استفاده از سرور آگهی ناشر گوگل بدون ارائه کنترل GAM در حراج API سطح بالا PA.	پاسخ ارائه شده توسط Google Ad Manager: به دلایلی که در گزارش Q3 2023 Google توضیح داده شده است ، برنامه های GAM برای ادغام PA API خود شامل ناشران پشتیبانی از GAM به عنوان سرور تبلیغات ناشر خود بدون کنترل حراج سطح بالا نیست.
دسترسی به اطلاعات	GAM به اطلاعات ارزشمندی از رقبا ، از جمله قیمت حراج متنی ، سیگنال های ارائه شده توسط خریداران به SSP برای حراج PA API و پارامترهای پیکربندی از SSP دسترسی دارد.	پاسخ ارائه شده توسط Google Ad Manager: ما سالهاست که تمرکز جدی روی انصاف حراج داشته ایم ، از جمله قول ما مبنی بر اینکه هیچ قیمتی از منابع تبلیغاتی غیر ضمانت نامه ای از جمله قیمت کالاهای غیر تضمین شده ، قبل از پیشنهاد در حراج ، با یک خریدار دیگر به اشتراک گذاشته می شود. که بعداً در تعهدات خود به مرجع رقابت فرانسه تأکید کردیم. برای حراج های PA API ، ما قصد داریم وعده های خود را حفظ کنیم و پیشنهاد هیچ یک از شرکت کنندگان در حراج را با هیچ یک از شرکت کنندگان در حراج دیگر قبل از اتمام حراج در حراج های چند فروش به اشتراک نگذاریم. برای روشن شدن ، ما قیمت حراج متنی را با هر حراج مؤلفه ، از جمله خودمان ، به اشتراک نمی گذاریم ، همانطور که در این بروزرسانی توضیح داده شده است . علاوه بر این ، ما از اطلاعاتی در مورد تنظیمات حراج مؤلفه ، از جمله سیگنال های ارائه شده توسط خریداران به SSP ، به عنوان بخشی از حراج خود استفاده نمی کنیم. در حقیقت ، ما از تغییراتی در API PA استقبال می کنیم که به فروشندگان مؤلفه اجازه می دهد تا تنظیمات حراج مؤلفه خود را به روشی که از فروشنده سطح بالا غرق می شود ، مشخص کنند.
حراج های مؤلفه	به عنوان حراج سطح بالا ، GAM کنترل خواهد کرد که SSP ها حراج های مؤلفه را برای هر فرصت تبلیغاتی اجرا می کنند.	پاسخ ارائه شده توسط Google Ad Manager: به عنوان یک سرور تبلیغاتی ناشر ، GAM یک API سبک برای SSP ها ارائه می دهد که یک ناشر ممکن است با آن کار کند تا تنظیمات حراج مؤلفه خود را از طریق API برچسب Google Publisher (GPT) مشخص کند. جزئیات بیشتر را می توان در اینجا یافت . اگر SSP از طریق این API پیکربندی حراج مؤلفه را فراهم کند ، آنها در لیست حراج های مؤلفه برای آن فرصت تبلیغ قرار می گیرند. GAM هیچ محدودیتی را در حراج های مؤلفه موجود اعمال نمی کند. هر SSP که مایل به اجرای حراج مؤلفه است ، می تواند این کار را انجام دهد ، مشروط بر اینکه ناشر به آنها اجازه داده باشد تا کد لازم را در صفحه ناشر اجرا کنند.
حراج های مؤلفه	GAM می تواند یک کف خاص و ناشناخته برای هر پیشنهاد برنده حراج مؤلفه اعمال کند.	پاسخ ارائه شده توسط Google Ad Manager: گام سالها تمرکز جدی بر انصاف حراج داشته است. به عنوان بخشی از حفظ حراج منصفانه و شفاف ، ما از قیمت کف پشتیبانی نمی کنیم که فقط برای بخش های خاص تقاضا اعمال می شود. این یک اصل مداوم در محصول ما است و برای حراج های API PA نیز ادامه خواهد یافت.
سرورهای تبلیغاتی شخص ثالث	سرورهای تبلیغاتی شخص ثالث به مشارکت Google در حراج سطح بالاتر دسترسی ندارند و توانایی آن را برای بهره مندی از تقاضای Google SSP در زمینه PA API محدود می کنند.	پاسخ ارائه شده توسط Google Ad Manager: در حال حاضر ، GAM از آزمایش API PA با چندین فروشنده در GAM از طریق API که در اینجا شرح داده شده است ، پشتیبانی می کند. مشارکت GAM به عنوان حراج مؤلفه در سایر حراج های سطح بالا در حال حاضر پشتیبانی نمی شود.
(همچنین در سه ماهه قبلی گزارش شده است) عملکرد حراج های API PA	از آزمایش کنندگان گزارش دهید که حراج های API PA دارای تأخیر بالایی هستند.	ما نگرانی هایی در مورد تأخیر شنیده ایم و این بخشی از این دلیل است که ما به عنوان بخشی از API PA چندین ویژگی را توسعه داده ایم که باعث می شود SSP ها هر دو محدودیت در تأخیر DSP و همچنین پیشرفت هایی را ایجاد کنند که می تواند باعث کاهش تأخیر شود . ما اخیراً راهنمای بهترین روشهای تأخیر خود را به روز کرده ایم که شامل اطلاعات بیشتر در مورد نحوه استفاده از این ویژگی ها است. ما همچنان به پیشرفت های جدید تأخیر ادامه می دهیم که برخی از آنها در اینجا قابل مشاهده است.
(همچنین در سه ماهه قبلی گزارش شده است) ارائه ویدیو	پشتیبانی از ارائه ویدیویی با استفاده از API PA و فریم های حصارکشی.	در ماه ژانویه ، ما نسخه ی نمایشی از نحوه کار کردن ویدیوی Instream را در حراج PA منتشر کردیم ، با جزئیات اضافی در مورد رویکردهای متناوب. ما همچنین می بینیم که بازیکنان اکوسیستم شروع به پیشنهاد نحوه ارائه فیلمبرداری برای شرکای ادغام شده با آنها می کنند ، مانند پیشنهادات GAM در ساخت و ساز سازگار با ویدیویی Renderurl یا روند کامل E2E . علاوه بر این ، ما در حال گوش دادن به بازخورد اکوسیستم در مورد تغییراتی هستیم که می توانیم برای افزایش فرزندخواندگی انجام دهیم ، و یکی از این موارد در GitHub به تفصیل شرح داده شده است . ما به طور فعال با اکوسیستم درگیر هستیم تا موانع دیگری را برای فرزندخواندگی شناسایی کنیم که ممکن است با آنها روبرو شویم و به موقع آنها را مورد بررسی قرار دهیم.
(همچنین در سه ماهه قبلی گزارش شده است) خط مشی انتقال داده ها	سیاست مدیریت داده برای IGS / PA API چیست؟	در طراحی API PA ، تمام داده های ذخیره شده در IGS ، یا در مورد آنچه افراد در IGS هستند ، یا (i) در دستگاه خود باقی مانده یا (ii) در مناقصه و حراج (B&A) که در یک محیط اجرای قابل اعتماد اجرا می شوند ، پردازش می شوند. (TEE). در هر دو مورد ، داده ها توسط طرفین دیگر قابل خواندن نیستند ، یا به هیچ وجه به غیر از تولید پیشنهادات در حراج استفاده می شوند. برخی از پیشرفت های حریم خصوصی که Chrome در حال کاوش در آن است ، شامل تعامل با یک سرور ناشناس بودن K Google است. این تعامل با دقت طراحی شده است تا از به اشتراک گذاری اطلاعات در مورد کاربران جلوگیری شود و در یک TEE برای اطمینان از برابری اطلاعات در سراسر اکوسیستم ADS اجرا شود. گوگل متعهد شده است كه CMA را به طراحی و اجرای پیشنهادات Sandbox حریم خصوصی به گونه ای كه با پیشگویی از تجارت خود Google ، رقابت را تحریف نمی كند و تأثیر خود را در رقابت در تبلیغات دیجیتال و ناشران و تبلیغات در نظر بگیرد. ما همچنان با CMA همکاری نزدیکی داریم تا اطمینان حاصل کنیم که کار ما با این تعهدات مطابقت دارد.
(همچنین در سه ماهه قبلی گزارش شده است) عمر IG	درخواست افزایش عمر IGS از 30 تا 90 روز.	چنین تغییری مستلزم ارزیابی دقیق است و مزایای این صنعت را در برابر تأثیر کاربران Chrome و سایر ذینفعان وزن می کند. ما در حال بررسی این درخواست هستیم و از بازخورد اضافی در اینجا استقبال می کنیم.
(همچنین در سه ماهه قبلی گزارش شده است) مدل های مدنی	علاوه بر ModelingSignals که فقط می تواند نمایش را رمزگذاری کرده و روی اطلاعات کلیک کنید ، یک زمینه جدید درخواست کنید.	ما در اینجا با یک پیشنهاد پیشخوان به این بازخورد پاسخ داده ایم. ما به طور جدی با صنعت درگیر هستیم تا نظرات آنها را در مورد پیشنهاد خود درک کنیم و در حال حاضر مزایای این صنعت را در برابر تأثیر کاربران Chrome و سایر ذینفعان در نظر می گیریم.
بیت های اضافی در ReportWin ()	بیت های اضافی را در ReportWin () از حد فعلی 12 قبل از 3pcd تهیه کنید.	ما در حال حاضر در حال بررسی رویکردها برای پشتیبانی از این مورد استفاده هستیم. مدتی طول می کشد زیرا ما به دنبال رویکردهایی هستیم که می تواند به اطمینان از داشتن یک برنامه حفظ حریم خصوصی طولانی مدت کمک کند.
طرح حراج	درخواست های یک حراج واحد که با نمره مربوطه URL ها را باز می گرداند.	به اشتراک گذاشتن چندین رندر ، و نمره مربوط به آنها ، از یک حراج واحد PA چیزی است که ما در نظر گرفتیم اما به دلیل نگرانی های مربوط به حریم خصوصی اجرا نکردیم. ما تمایل به جلوگیری از نشان دادن همان تبلیغ را چندین بار به کاربر در یک صفحه واحد و استقبال از بحث بیشتر در مورد GitHub درک می کنیم.
گزارش وین	زمینه های دلخواه را در عملکرد ReportWin () وارد کنید.	این در حال حاضر در طول دوره آزمایش اتفاق می افتد. هنگامی که Chrome پشتیبانی از 3PC را به پایان رساند ، نسخه Fordebuggingonly API برای فعال کردن اشکال زدایی Downsampled ، که در اینجا مشخص شده است ، مهاجرت می کند.
فروشندگان مؤلفه	یک مکانیسم مستقل برای شمارش برداشت های خود و سایر رویدادها داشته باشید و لازم نیست که فقط به گزارش های فناوری تبلیغاتی وابسته باشند.	این درخواست ویژگی برای کشف بیشتر در صف ما است. ما پیش بینی نمی کنیم که این موضوع را در دوره آزمایش تسهیل شده کرومی مورد بررسی قرار دهیم.
صورتحساب هزینه برای هر کلیک	صورتحساب هزینه را برای هر کلیک در PA API اجرا کنید.	ما این درخواست را در اینجا در نظر می گیریم و در حال حاضر این موضوع را به عنوان درخواست پیشنهادی در مورد نحوه اجرای آن با سطح API فعلی می بینیم.
مرورگرهای	ورودی های ورودی را به گزارش مشخصات مرورگرهای مربوط به فروشنده اضافه کنید.	ما در حال بررسی این درخواست هستیم و از بازخورد اضافی در اینجا استقبال می کنیم.
ابرداده طرف خرید و پشتیبانی از مالکیت منطقی برای DSP	طراحی فعلی API می تواند به تغییر قابل توجهی در کمپین های بازپرداخت سطح محصول منجر شود که در آن ممکن است کمپین ها نیاز به مهاجرت به سیستم عامل هایی داشته باشند که هم به عنوان DSPS و هم به عنوان ارائه دهندگان DCO خدمت می کنند.	ما در مورد این موضوع بحث می کنیم و از بازخورد اضافی در اینجا استقبال می کنیم.
ابرداده طرف خرید و پشتیبانی از مالکیت منطقی برای DSP	مثالهایی را به اشتراک بگذارید که DSP صاحب IG نیست.	ما می دانیم که افراد غیر مبارز دوست دارند از برخی از عملکردهای IGS استفاده کنند ، اما دیگران نیستند. ما به طور فعال گزینه های پرداختن به این موارد استفاده را ارزیابی می کنیم و از بازخورد اضافی در اینجا استقبال می کنیم.
کنترل زمان	ناشران باید بتوانند تعداد IG ها را قادر به شرکت در زمان و زمان بندی سطح بالا / زمان جهانی کنند.	ما می دانیم که تمایل به کنترل های افزایش یافته و دید بین فروشنده سطح بالا و مؤلفه وجود دارد و ما این درخواست را در نظر می گیریم.
اندازه چند آگهی	پشتیبانی از API PA برای موارد استفاده از اندازه چند تبلیغ.	ما در حال بررسی این درخواست هستیم و از بازخورد اضافی از اکوسیستم استقبال می کنیم.
مستندات	آیا لیستی از ویژگی های IG وجود دارد که در معرض K-Anon قرار دارند؟	ما در اینجا به این سوال پاسخ داده ایم.
اشکال زدایی	قابلیت های اشکال زدایی بهبود یافته برای PA API.	ما اهمیت ابزارهای اشکال زدایی قوی را برای توسعه دهندگان کار با PA API تشخیص می دهیم. ما متعهد هستیم که با بررسی راه های ادغام بهتر پرونده های شناخته شده با ابزارهای توسعه دهنده ، تجربه توسعه دهنده را تقویت کنیم. هدف ما فراهم کردن قابلیت دید و عیب یابی بیشتر در محیط توسعه است. ما در اینجا در مورد این موضوع بحث می کنیم و از بازخورد اضافی استقبال می کنیم.
برچسب ها	آیا همه کاربران در برچسب های درمان Mode B دارای API های ماسه ای حریم خصوصی هستند؟	تکالیف گروه آزمایش Chrome به طور تصادفی تعیین شده و مستقل از تنظیمات Chrome با تنظیم کاربر است. در حالی که این API ها ممکن است در گروه های درمانی خاص در دسترس کاربران باشند (به عنوان مثال ، درمان_1.*) ، عملکرد آنها می تواند از طریق تنظیمات کروم اصلاح یا غیرفعال شود. حالت B CONTROL_2 گروه: گنجاندن در این گروه ذاتاً API و اندازه گیری مربوط به ماسهبازی حریم خصوصی را غیرفعال می کند ، و این تنظیم نمی تواند توسط کاربر در تنظیمات Chrome نادیده گرفته شود.
استفاده از API	آیا فراخوانی برای گزارش وین () و ارائه تبلیغات به صورت موازی یا یکی پس از دیگری اتفاق می افتد؟	ReportWin () مستقیماً پس از اتمام Runadauction () نامیده می شود. در عین حال ، فرآیند ارائه آگهی ممکن است هنگامی که نتیجه حراج در یک قاب Iframe یا حصار قرار گیرد ، شروع شود. پس از اتمام اجرای هر دو Reportwin () و تبلیغات ، URL های ارائه شده برای SendReportto () به دست می آیند.
(همچنین در سه ماهه قبلی گزارش شده است) پشتیبانی تست A/B	درخواست پشتیبانی از آزمایش PA API A/B.	ما در اینجا در مورد این درخواست بحث می کنیم و از بازخورد اضافی استقبال می کنیم.
شکل دهی ترافیک	پیشنهاد Google برای مدیریت تصمیم گیری مورد نیاز از طریق سرور KV مفید نیست ، زیرا فروشندگان قادر به تعامل با باطن خود نیستند و شکل دهی ترافیک را به چالش می کشد.	همانطور که در موضوع GitHub مورد بحث قرار گرفت ، در معرض دید آیا DSP های فردی دارای IGS موجود است می تواند نگرانی های اثر انگشت کاربر را داشته باشد. ما گزینه های دیگری را در این موضوع پیشنهاد کرده ایم و برای پیشنهادات بیشتر باز است.
شکل دهی ترافیک	مکانیسم های ذخیره سازی لایه قابل توجهی از پیچیدگی را اضافه می کنند و از دانستن DSP ها از شکل واقعی ترافیکی که می توانند در آن استفاده کنند ، جلوگیری می کند.	مکانیسم ذخیره سازی به سادگی به عنوان یک پیشنهاد ارائه شد. AdTechs می تواند از پیشنهادهایی که در مورد استفاده از آنها استفاده می کند استفاده کند و ما در اینجا از بحث های اضافی استقبال می کنیم.
برچسب ها	Chrome باید برچسب را به عنوان یک پارامتر در درخواست ها به سرورهای معتبر خریدار و فروشنده به اشتراک بگذارد.	به نظر می رسد این یک درخواست معقول است زیرا به نظر می رسد به طور گسترده با هدف استفاده از داده های مسئول IG هماهنگ است. با این حال ، ما در حال بررسی درخواست ، منوط به بررسی داخلی هستیم و با پیشرفت بحث و گفتگو ، به روزرسانی های عمومی در مورد این موضوع را ارائه می دهیم.
استفاده از API	روشن کردن تعریف صریح از گروه "Control_1" در "راهنمایی اضافی CMA به اشخاص ثالث در مورد آزمایش". به طور خاص ، این نگرانی وجود دارد که ممکن است تغییر در متن به اشتباه تفسیر شود زیرا مستلزم محرومیت از همه API های ماسه ای حریم خصوصی از Control_1 است.	ما نظرات خود را در این مورد در این موضوع GitHub بیان کرده ایم. گفته می شود ، ما در موقعیتی نیستیم که برای CMA صحبت کنیم و پیشنهاد می کنیم درمورد تفسیر راهنمایی آزمایش آنها به طور مستقیم با CMA ، موضوعاتی را مطرح کنیم.
استفاده از API	آیا Chrome اجازه می دهد در حالی که به منبع دیگری هدایت می شود ، از joinadinterestgroup () در صفحه خالی تماس بگیرید؟	اگر کاربر در حال بازدید از برخی از سایت ها باشد ، صاحب سایت می تواند توانایی تماس با joinadinterestgroup را به شخص ثالث ارائه دهد. این هیئت به شخص ثالث اجازه می دهد تا بدون نیاز به اضافه کردن هر نوع تغییر مسیر از طریق یک صفحه خالی ، IGS را بسازد. ما به دلایل خاص برای ساخت IG در وسط یک تغییر مسیر به جای استفاده از مکانیسم هیئت در نظر گرفته شده ، از بازخورد استقبال می کنیم.
استفاده از API	صرافی ها باید بتوانند IG را به صفحات متعلق به ناشران که با آنها کار می کنند بنویسد و سپس می توانند مجوز پیشنهاد برای آن IG را به هر خریدار یا DSP اختصاص دهند.	ما بازخورد را دریافت کرده ایم و در حال ارزیابی این هستیم که آیا می توان چنین درخواستی را پشتیبانی کرد یا خیر. ما از بازخورد اضافی از اکوسیستم استقبال می کنیم.
استفاده از API	اگر هیچ کس برنده حراج API PA نباشد ، هیچ اعلان ضرر اشکال زدایی وجود ندارد.	کارکردهای ReportWin و Reportresult Chrome برای گزارش برنده در سطح رویداد در سیستم حراج حراج (PA) طراحی شده اند. در شرایطی که تمام پیشنهادات در حراج PA رد می شوند ، انتظار نمی رود که این توابع به عنوان مشخصی که برنده مشخص نمی شود ، فراخوانی شود. به روزرسانی اخیر برای Chrome ممکن است اختلافات را در جایی که URL ها به Fordebuggingonly منتقل شده اند توضیح دهد. ReportAductionLoss () در پانل شبکه DevTools ظاهر نمی شوند. توصیه می کنیم این قابلیت را با استفاده از ساخت کانال قناری یا dev از Chrome تأیید کنید.
استفاده از API	آیا Adcost می تواند از GenerateBid برگردانده شود (در حال حاضر به صورت تصادفی به 2 بایت گرد شده است)؟	ADCOST هزینه کلیک یا تبدیل تبلیغ کننده از GenerateBid () به ReportWin () منتقل شده است. این مقدار می تواند تهی یا دو برابر باشد. مقادیر منفی نادیده گرفته می شود و تصویب نمی شود. با گذشت مقدار به صورت تصادفی گرد می شود.
بهبود API	آیا می توان از سرورهای اعدام قابل اعتماد و رمزگذاری شده برای رسیدگی به هدف قرار دادن / گروه / انتساب و حراج ها استفاده کرد و نه مرورگر کروم؟	ما توصیه می کنیم اجزای و گزینه های مبتنی بر TEE را در API PA (به عنوان مثال سرورهای KV و خدمات B&A ) و همچنین مؤلفه های مبتنی بر TEE از گزارش دهی و جمع آوری خصوصی (به عنوان مثال سرویس جمع آوری ) بررسی کنید که به این سؤال می پردازند.
بهبود API	آیا پاسخ حراج ماسهبازی حریم خصوصی می تواند به جای پاسخ تبلیغاتی (مانند برچسب های تبلیغاتی) پاسخ پیشنهاد (مانند مناقصه هدر) باشد؟	این نوع تغییر اساساً خصوصیات حریم خصوصی API PA را تغییر می دهد ، بنابراین چیزی نیست که ما در نظر داریم.
ناشر کنترل	آیا ناشران می توانند خلاقیت های API PA را در صفحات خود مسدود کنند؟	Chrome پیشنهادی برای اسکن خلاق در زمان واقعی دارد که هنوز برای آزمایش در دسترس نیست. در حالی که این هنوز در دسترس نیست ، ما مشاهده کرده ایم که بیشتر SSP ها راه حل هایی برای فعال کردن این امر ایجاد کرده اند.
استفاده از API	محدودیت اندازه در Perbuyersignals چقدر است؟	در شکل کلاسیک خود ، Perbuyersignals محدودیت اندازه ذاتی در کروم ندارد. محدودیت های اصلی این است که داده ها json-serializable باقی مانده و باعث مصرف بیش از حد حافظه نمی شود. با این حال ، لازم به ذکر است که پیشگامان بسیار بزرگ و پیچیده ممکن است بر عملکرد تأثیر منفی بگذارد. یک روش جایگزین برای عبور از perbuyersignals از طریق DirectFromSellersignalSheaderAdslot وجود دارد. این روش perbuyersignals را در یک هدر منتقل می کند ، در معرض حد حداکثر اندازه 10 کیلوبایت برای کل پاسخ هدر. علاوه بر این ، سرورهای انفرادی ممکن است محدودیت های خود را در حداکثر اندازه هدر تحمیل کنند.
مستندات	مستندات موجود در تماس با RegisterAdbeacon از Inside GenerateBid تغییر می کند.	ما این مستندات را در 17 فوریه به روز کردیم.
استفاده از API	چگونه ReportEvent URL Beacon Right را از گزینه های مختلف ثبت شده انتخاب می کند؟	هر حراج منجر به پیکربندی جداگانه ای می شود ، که به نوبه خود منجر به یک نقشه گزارش جداگانه می شود. حراج های فردی (و فریم های حاصل از آنها) کاملاً از یکدیگر جدا هستند و داده ها را به اشتراک نمی گذارند. توضیح دهنده " گزارش تبلیغات فریم های حصارکشی " جزئیات بیشتری در مورد این موضوع ارائه می دهد.
uri	فیلتر را در برگه chrome devtools "برنامه ->" گروه های ذینفع "اضافه کنید ، اجازه می دهد تا توسط مالک IG (یا شاید با نام IG) فیلتر کنید.	ما در حال ارزیابی این درخواست هستیم و از بازخورد اضافی از اکوسیستم استقبال می کنیم.
کروم بدون سر	پشتیبانی API PA در کروم بدون سر.	برخی از مؤلفه های PA API وجود دارد که به Chrome گره خورده است ، به عنوان مثال K-Anon با سرورهای Google تماس می گیرد ، که ممکن است در کروم بی سر "قدیمی" کار نکند. ما معتقدیم که این ممکن است توسط نسخه "جدید" Chrome بدون سر منتشر شده در Chrome 112 مورد بررسی قرار گیرد.
استفاده از API	در مورد گزارش از دست دادن با ReportAductionLoss ، ما در بسیاری موارد شاهد "Toplevelwinningbid = 0" هستیم. تعبیر این چیست؟	مقدار Toplevelwinningbid از عملکرد نقص () در مؤلفه فروشنده سطح بالا سرچشمه می گیرد. این مقدار در تعیین نتیجه حراج سطح بالا نقش دارد. طبق توضیح دهنده ، یک مقدار toplevelwinningbid صفر یا هر عدد منفی نشان می دهد که AD مربوطه برای برنده شدن در حراج واجد شرایط نیست. به عنوان مثال می توان از این مکانیسم استفاده کرد تا تبلیغات هدفمند گروهی را که از یک نامزد هدفمند متناسب استفاده نمی کنند ، فیلتر کند. در حالی که یک Toplevelwinningbid با ارزش صفر ممکن است نشان دهد که یک حراج متنی حاکم شده است ، مشخصات PA API اذعان می کند که عوامل دیگر می توانند در این نتیجه نقش داشته باشند.
تست A/B حالت	شفاف سازی در حالت B و حالت انتخاب ترافیک و درخواست های امتناع.	معیارهای ورود به حالت A و حالت B یکسان هستند. هدف این است که گروه هایی که نماینده ترافیک طبیعی کروم هستند تا زمانی که از API های ماسه ای حریم خصوصی و روش برچسب زدن پشتیبانی کنند ، به این ترتیب برخی از تنظیمات مشتری سازگار نیستند. برای اهداف آزمایش ، مهم است که فقط ترافیک دارای برچسب را با سایر ترافیک های دارای برچسب مقایسه کنید. کاربران در حالت B دارای ویژگی حفاظت از ردیابی هستند و به همین ترتیب ، آنها در مورد آن ویژگی اعلان دریافت می کنند.
بهبود API	آیا می توان "LifetImems" را به عنوان یک ویژگی مستقیم در تماس با joinadinterestgroup درج کرد یا آن را به عنوان یک استدلال جداگانه مدیریت کرد؟	ما با دقت در حال بررسی بازخورد جامعه توسعه وب در مورد عملکرد "joinadinterestroup" در پیشنهاد PA API هستیم. یک نکته اصلی بحث بر روش بهینه برای مدیریت طول عمر IG متمرکز است. ما در حال ارزیابی مزایای یک آرگومان جداگانه برای پارامتر "LifetImems" هستیم ، زیرا باعث انعطاف پذیری و سازگاری برای پیشرفتهای احتمالی آینده با مشخصات می شود. ما در اینجا در مورد این موضوع بحث می کنیم و از بازخورد اضافی استقبال می کنیم.
استفاده از API	پتانسیل افزایش نرخ منفی کاذب در چارچوب API PA به دلیل برخورد با شناسه های مرورگر کم آنتروپی.	تیم Chrome به طور جدی درگیر پالایش مداوم چارچوب API PA است. ما از بحث در مورد نرخ های منفی کاذب احتمالی ناشی از برخورد شناسه مرورگر قدردانی می کنیم. ما این بازخورد را با دقت ارزیابی می کنیم و برای اطمینان از اینکه تجزیه و تحلیل های به روز شده به طور جامع منعکس کننده تمام عوامل مرتبط است ، کار خواهیم کرد. تعهد ما به راه حلی است که ضمن حفظ دقت و قابلیت اطمینان ، به نتایج حریم خصوصی مطلوب دست می یابد. ما در اینجا در مورد این موضوع بحث می کنیم و از بازخورد اضافی استقبال می کنیم.
استفاده از API	آیا یک شناسه مرورگر کم آنتروپی برای جلوگیری از ارسال مکرر درخواست های "پیوستن" برای همان شیء در یک سیستم ناشناس بودن K- لازم است؟	ما بحث در مورد استفاده از شناسه های مرورگر در اجرای سیستم های ناشناس بودن K را تأیید و قدردانی می کنیم. ما نگرانی های مطرح شده در مورد پیامدهای احتمالی حریم خصوصی چنین شناسه هایی را درک می کنیم. در حالی که اجرای اولیه ما از یک شناسه کم آنتروپی به عنوان یک مکانیسم ضد سوء استفاده استفاده می کند ، ما به طور فعال در حال بررسی تکنیک های جایگزین مانند نشانه های شمارش ناشناس هستیم که در ضمن حفظ یکپارچگی سیستم ، حریم شخصی کاربر را در اولویت قرار می دهد. ما متعهد به یافتن راه حل هایی هستیم که استفاده از داده های مسئول را با حمایت از حریم خصوصی قوی تعادل برقرار کنیم و از ادامه گفتگو با جامعه تحقیقاتی استقبال می کنیم. ما در اینجا در مورد این موضوع بحث می کنیم و از بازخورد اضافی استقبال می کنیم.
استفاده از API	آیا AMP (صفحات شتاب موبایل) از API PA پشتیبانی می کند.	AMP در حال حاضر به طور طبیعی از PA API پشتیبانی نمی کند. اگر پشتیبانی توسط AMP از اولویت بالایی برخوردار باشد ، از بازخورد اضافی از اکوسیستم استقبال می کنیم.
بهبود API	در نظر بگیرید که نوع را از چک های ناشناس بودن K حذف کنید.	ما با دقت در حال بررسی بازخورد در مورد بهینه سازی ساختارهای درخواست ناشناس بودن K- به طور بالقوه هستیم. ما پیشنهادی را برای ادغام پارامترها و انواع بالقوه متحد کردن فرآیند درک می کنیم. هدف ما اطمینان از بهره وری و قابلیت حفظ است و ما همچنان که ما همچنان به توسعه راه حل های حریم خصوصی خود می پردازیم ، همه گزینه ها را ارزیابی می کنیم. ما در اینجا در مورد این موضوع بحث می کنیم و از بازخورد اضافی استقبال می کنیم.
uri	درخواست مکانیسم برای کاربران کمتر فنی برای مشاهده و مدیریت IG های متعلق به آنها ، از جمله کنترل های بالقوه در سطح وب سایت برای انتخاب.	ما اهمیت ارائه ابزارهای کاربر پسند برای درک و مدیریت IGS را تشخیص می دهیم. ما روشهای مختلفی را با دقت در نظر گرفته ایم و دریافتیم که شناسایی IG توسط وب سایت که در آن به آنها پیوسته اند ، بهترین تعادل وضوح و محافظت از حریم خصوصی را ارائه می دهد. در حال حاضر ، مدیریت جهانی IGS در تنظیمات Chrome واقع شده است. ما به طور مداوم در حال بررسی راه های افزایش بیشتر تجربه کاربر در این زمینه هستیم. ما در اینجا در مورد این موضوع بحث می کنیم و از بازخورد اضافی استقبال می کنیم.
ایمنی API	آیا PA API در برابر نشت حریم خصوصی از طریق تعامل AD خلاق ، حتی در چارچوب قاب های حصار آسیب پذیر است؟	ما پتانسیل نشت اطلاعات را از طریق تعامل پیشرفته AD تأیید می کنیم. ما به طور فعال در حال بررسی تعامل بین فریم های حصارکشی ، API PA و بردارهای حمله بالقوه هستیم. کاهش خطرات حفظ حریم خصوصی اولویت اصلی است و ما متعهد به ایجاد راه حل های قوی هستیم که نوآوری را با محافظت از کاربر متعادل می کند. ما در اینجا در مورد این موضوع بحث می کنیم و از بازخورد اضافی استقبال می کنیم.
تاخیر	آیا پیش فرض از زمان 50ms برای منطق مناقصه خریدار یک ارزش واقع بینانه است؟	ما نگرانی های مطرح شده در مورد ناسازگاری های احتمالی بین مشخصات و زمان درخواست های شبکه برای منطق مناقصه را تأیید می کنیم. ما به طور فعال در حال بررسی مشخصات برای اطمینان از صحت آنها و بررسی تنظیمات زمان پیش فرض بهینه برای تعادل عملکرد و امکان سنجی هستیم. ما در اینجا در مورد این موضوع بحث می کنیم و از بازخورد اضافی استقبال می کنیم.
مستندات	نشت زمان بالقوه در مشخصات جایی که یک وب سایت می تواند استنباط کند که آیا یک آگهی آستانه ناشناس بودن K و پیامدهای بالقوه برای ردیابی متقابل سایت را شکست داده است.	ما مسئله مطرح شده در مورد نشت زمان بالقوه را تشخیص می دهیم. ما اختلاف در مشخصات را تأیید کرده ایم و در حال انجام اقدامات برای اطمینان از تعیین وضعیت ناشناس بودن K ADS قبل از حراج برای جلوگیری از چنین نشت هستیم. ما این نگرانی ها را جدی می گیریم و مشخصات را به روز می کنیم تا این تغییرات را منعکس کند. ما در اینجا در مورد این موضوع بحث می کنیم و از بازخورد اضافی استقبال می کنیم.
استفاده از API	راه های اجرای یک بلوک SSP در API PA.	ما نیاز به مکانیسم ها را برای مدیریت محدودیت های تبلیغاتی توسط SSP ها تشخیص می دهیم. ما کاوش در مورد راه حل هایی را که در اولویت ارزیابی در مورد دستگاه قرار دارد و از ابرداده AD موجود برای محافظت از حریم شخصی کاربر در عین حال انعطاف پذیری استفاده می کنیم ، تشویق می کنیم. ما متعهد هستیم که با توسعه دهندگان همکاری کنیم تا رویکردهای بهینه در API PA را شناسایی کنیم. ما در اینجا در مورد این موضوع بحث می کنیم و از بازخورد اضافی استقبال می کنیم.
استفاده از API	آیا کسی می تواند به مرورگر خود بگوید که وانمود کند که PA API را به گونه ای انجام دهد که سایت ها نتوانند آن را تشخیص دهند؟	ما تأیید می کنیم که ، در شکل فعلی خود ، انتخاب از API PA می تواند توسط وب سایت ها قابل تشخیص باشد. ما به طور فعال روی ویژگی هایی مانند پیشنهادات اضافی و هدف قرار دادن منفی ، همراه با قاب های حصارکشی ، برای تقویت حریم خصوصی و تلاش برای ارائه گزینه های انتخاب غیر قابل کشف کار می کنیم. ما در اینجا در مورد این موضوع بحث می کنیم و از بازخورد اضافی استقبال می کنیم.
تست A/B حالت	ترافیک مرکز داده فرض می شود که معالجه 1.1 باشد.	تیم Chrome با تیم GAM تأیید کرده است که این ترافیک اکنون از آزمایش فیلتر شده است. ما در اینجا در مورد این موضوع بحث می کنیم و از بازخورد اضافی استقبال می کنیم.
استفاده از API	کارآیی و انصاف اجرای علاقه مندان در PA API.	ما بحث مداوم در مورد کارآیی و انصاف زمینه "GrowergroupBuyers" را در حراج های API PA تشخیص می دهیم. ما تجارت بین کارآیی ، حریم خصوصی و انصاف بازار را تصدیق می کنیم. در حالی که فروشندگان نیاز به مدیریت روابط تجاری با خریداران دارند ، ما در حال بررسی راه های بهینه سازی روند تطبیق هستیم. اینها ممکن است شامل تنظیمات پویا بر اساس داده های زمان واقعی و مدل های ترکیبی باشد. ما متعهد هستیم که راه حل هایی را پیدا کنیم که در اولویت حفظ حریم خصوصی کاربر و پشتیبانی از یک اکوسیستم تبلیغاتی رقابتی باشد. ما در اینجا در مورد این موضوع بحث می کنیم و از بازخورد اضافی استقبال می کنیم.
uri	نگرانی های مربوط به حافظه بالقوه و وضوح UI مربوط به IG در Chrome.	ما نگرانی های مطرح شده در مورد نمایش IGS در Devtools را درک می کنیم. در حالی که دیدگاه فعلی منعکس کننده تمام رویدادهای IG برای ردیابی تاریخی است ، ما ارزش ارائه دید واضح تر به وضعیت فعلی IG های ذخیره شده را تأیید می کنیم. ما بهینه سازی ها و پیشرفت های احتمالی UI را برای تقویت بینش توسعه دهنده کشف خواهیم کرد. با توجه به مدیریت حافظه ، اجرای IG برای جلوگیری از نشت حافظه طراحی شده است ، اما ما به طور مداوم نظارت و بهینه سازی استفاده از منابع را کنترل می کنیم. ما در اینجا در مورد این موضوع بحث می کنیم و از بازخورد اضافی استقبال می کنیم.
مستندات	پوستر اصلی هنگام تلاش برای استفاده از اندازه های تبلیغاتی به طور مستقیم در قسمت "اندازه" از عملکرد "joinadinterestgroup" با خطایی روبرو می شود. آنها می خواهند بدانند که آیا این رفتار در نظر گرفته شده است یا خیر.	ما مقدار پیکربندی آگهی ساده سازی را در عملکرد "joinadinterestgroup" تشخیص می دهیم. ما به طور فعال در تلاش هستیم تا به این محدودیت بپردازیم و برنامه ریزی می کنیم تا این عملکرد را در به روزرسانی های آینده فعال کنیم. این پیشرفت با تعهد ما برای ارائه ابزارهای انعطاف پذیر و کارآمد برای مدیریت تبلیغات ، به توسعه دهندگان می پردازد. ما در اینجا در مورد این موضوع بحث می کنیم و از بازخورد اضافی استقبال می کنیم.
برچسب تست تسهیل شده با کروم	درخواست داشتن داده های مستقیم در مورد حالت A در مقابل B و برچسب های دقیق در SendReportto به طوری که ما می توانیم آزمایش را به طور مداوم پیگیری کنیم.	ما در اینجا در مورد این درخواست بحث می کنیم و از بازخورد اضافی استقبال می کنیم
مستندات	آیا نام دامنه فروشنده در درخواستهایی که برای اهداف اعتبار سنجی به سرور قابل اعتماد فروشنده ارائه شده است ، درج شده است؟	ما از حذف اولیه پارامتر نام میزبان از مستندات API API مخاطبان محافظت شده KV استفاده می کنیم. ما می خواهیم به توسعه دهندگان اطمینان دهیم که نام دامنه فروشنده به طور خودکار در درخواست های سرور قابل اعتماد فروشنده گنجانده شده است. این عملکرد برای فرآیندهای اعتبار سنجی تبلیغاتی قوی ضروری است. ما مستندات را برای رسیدگی به این نظارت به روز کرده ایم و به اولویت بندی وضوح و شفافیت برای جامعه توسعه دهنده ادامه خواهیم داد. ما در اینجا در مورد این موضوع بحث می کنیم و از بازخورد اضافی استقبال می کنیم.
استفاده از API	روشهای بالقوه برای شامل نام IG در AD Impression Calls خواستار اهداف گزارشگری.	ما متعهد هستیم که نیاز به مکانیسم های گزارشگری قوی را با اصل اساسی حفظ حریم خصوصی کاربر متعادل کنیم. گنجاندن نامهای IG در ردیابی AD Impression منوط به ضمانت های ناشناس بودن K است که برای جلوگیری از شناسایی افراد طراحی شده است. ما به بررسی راه حل های نوآورانه گزارش در این محدودیت های حریم خصوصی خواهیم پرداخت. ما در اینجا در مورد این موضوع بحث می کنیم و از بازخورد اضافی استقبال می کنیم.
ویژگی API	درخواست سرور قابل اعتماد خریدار برای دریافت نکات مشتری HTTP.	ما این درخواست ویژگی را در اینجا پیگیری می کنیم.
استفاده از API	آیا با توجه به اینکه این رفتار عضویت در IG را برای مرورگر دیکته می کند ، آیا پرونده هیئت باید به عنوان "دسترسی کنترل-آلم-منشور" نیاز داشته باشد؟	ما متعهد هستیم که با بهترین شیوه های امنیت وب هماهنگ شویم. نیاز به عنوان "دسترسی به کنترل-میلی لیتر" برای پرونده های نمایندگی ، سازگاری با اصول CORS را تضمین می کند و از قرار گرفتن در معرض غیر عمدی اطلاعات حساس جلوگیری می کند. ما در حال بررسی راه های بهینه سازی این فرایند در حالی که یک وضعیت امنیتی قوی را حفظ می کنیم. ما در اینجا در مورد این موضوع بحث می کنیم و از بازخورد اضافی استقبال می کنیم.
استفاده از API	سرورهای تبلیغاتی را قادر سازند تا خلاقیت ها را در چارچوب API PA شخصی سازی کنند.	ما می دانیم که سرورهای تبلیغاتی می توانند در شخصی سازی خلاق بازی کنند. ما به طور فعال در حال بررسی راه حل هایی برای توانمندسازی سرورهای تبلیغاتی در PA API هستیم ، مانند مدل "IG مشترک" که در آن می توان پیشنهادات و منطق انتخاب خلاق را با هم ترکیب کرد. هدف ما این است که تعادل بین فعال کردن قابلیت های خلاقانه تبلیغاتی قوی و محافظت از حریم شخصی کاربر را انجام دهیم. ما از همکاری و بازخورد بیشتر در مورد تکامل API برای تأمین نیازهای همه ذینفعان در اینجا استقبال می کنیم.
نگرانی های حریم خصوصی	در دسترس بودن شناسه های متناوب (به عنوان مثال ، RAMPID ، ID5) در درخواست های پیشنهادی متنی می تواند با تسهیل جمع آوری داده های بین سایت ، اهداف حریم خصوصی PA API را تضعیف کند.	ما تنش بالقوه بین شناسه های متقابل سایت و اهداف حریم خصوصی PA API را تشخیص می دهیم. در حالی که ناشران می توانند چنین شناسه هایی را به اشتراک بگذارند ، طراحی API PA اساساً قصد دارد تا انتخاب تبلیغات را از نیاز به ردیابی متقابل سایت جدا کند. ما متعهد به تقویت یک اکوسیستم تبلیغاتی محور حریم خصوصی هستیم و توسعه دهندگان را ترغیب می کنیم تا رویکرد API PA را در اولویت قرار دهند. ما در اینجا در مورد این موضوع بحث می کنیم و از بازخورد اضافی استقبال می کنیم.
ذخیره سازی	آیا راهی برای جلوگیری از استفاده مجدد از اسکریپت های مناقصه در حراج های متعدد وجود دارد؟	ما رفتار ذخیره شده مشاهده شده از اسکریپت های مناقصه را در چارچوب API PA تأیید می کنیم. در حالی که مکانیسم های ذخیره سازی استاندارد HTTP پشتیبانی می شود ، پتانسیل استفاده مجدد از اسکریپت در حراج ها به دلیل رفتار تعلیق دستگاه و طراحی مجریان مناقصه وجود دارد. The team is investigating solutions to provide buyers with greater control over script caching to manage their bidding strategies effectively. We are discussing this issue here and welcome additional feedback.
استفاده از API	Centralize reporting of bidding activity across all IGs for a DSP, while respecting user privacy.	We prioritize user privacy when designing PA API. While direct reporting of individual bidding events is not feasible due to cross-site tracking risks, we offer mechanisms like Shared Storage and Private Aggregation. These enable DSPs to gain aggregated insights on bidding activity, in a manner that upholds user privacy.
استفاده از API	The fetch from sendReportTo() in reportResult() only happens 94% of the time relative to getting a fetch registered with forDebuggingOnly.reportAdAuctionWin().	While they may not have the same timing, it is possible for both URLs to be fetched at the same time. In some instances, the component seller's worklet was disposed of and needs to be reloaded to then run the reportResult() function. However, neither the time it takes to fetch the scoring logic nor the time for the worklet to reload affects the 50ms timeout of for reportResult(). Please note that Chrome will use caching headers to define its fetching behavior in cases where the worklet needs to be reloaded. You can learn more about the phases of a PA auction here .
K-ناشناس بودن	Request for confirmation that the name of the interestGroup does not affect the k-anonymity of ad serving.	For a creative to be considered k-anonymous, the tuple of IG owner URL, bidding script URL, creative URL, and ad size must meet the specified threshold (k) over a past time period (w). The k-anonymity status is updated periodically (p).
Chrome UI	Proposal to provide the type of "internal visibility" that lots of MVC, ORM, etc frameworks offer. Eg start with simple logging of selected internal events to a new panel in the Dev Tools --> Application --> Application section	We are discussing the proposal here and welcome additional feedback.
Chrome UI	Dev Tools IG joining doesn't show priority related elements.	We have addressed this issue here .
API Improvement	It would be preferable to allow the creative ad server to track its own events. Could a list of allowed tracking domains be configurable?	We have shared a proposal here and welcome additional feedback from the ecosystem.
API Feature Request	Can PA API be extended to support non-RTB media transactions and maintain critical use cases such as ad serving and DCO?	We are discussing the issue here and welcome additional feedback.
Publisher Auction Timeout	Publishers need control over auction duration to prevent lost impressions, especially in header-bidding setups where ads are selected sequentially.	We acknowledge the importance of giving publishers granular control over ad auction timeouts. We are actively exploring how to implement a global auction timeout mechanism, potentially within the "auctionConfig" object, while carefully considering the edge cases. This feature aims to optimize impression fill-rates for publishers, and we will continue collaborating with the community to find the best solution. We are discussing the issue here and welcome additional feedback.
API Improvement	The current design of IGs in PA API leads to large metadata sizes due to lengthy renderURLs. Testers would like a way to compress these URLs for greater efficiency.	We recognize the importance of optimizing IG metadata size, particularly for efficiency-sensitive ad auctions. We think a template-based solution for compressing renderURLs offers significant potential. We will carefully evaluate the proposed template designs and ensure that any implemented solution includes robust abuse-prevention mechanisms to maintain browser stability. Collaborating with the web standards community to develop the optimal approach, with these considerations in mind, remains a priority. We are discussing the issue here and welcome additional feedback.
استفاده از API	Testers handling native ad formats want to optimize the Privacy Sandbox auction process by retrieving multiple ad results in a single call to reduce network load and improve ad rendering speed.	We recognize the performance concerns raised for native ad rendering in the Privacy Sandbox. We are committed to finding a balance between efficiency and strong user privacy protections. While returning multiple ads with full scores compromises privacy, we are actively exploring ways to optimize the auction process. We are dedicated to enhancing PA API support for native ad formats and investigating alternative mechanisms to improve efficiency within the strong privacy constraints of the Privacy Sandbox. We are discussing the issue here and welcome additional feedback.
استفاده از API	Flexibility in how ad bids are scored and sorted within the Privacy Sandbox, especially to represent priority levels or private marketplace rules.	We understand the need for fine-grained control over ad scoring and sorting within the Privacy Sandbox, particularly in complex bidding scenarios. We acknowledge the proposed solutions using tuples and mathematical functions to achieve multi-dimensional scoring without sacrificing user privacy. While these approaches may add complexity for developers, they offer the necessary expressiveness. We are committed to exploring ways to streamline these processes, potentially through helper functions or guidelines, to ensure optimal use of Privacy Sandbox features for advanced auction logic. We are discussing this issue here and welcome additional feedback.
reportEvent()	Add a new reserved event (automatic beacon perhaps) fired by the browser once a frame with an ad creative is initialized.	We are discussing this request here and welcome additional feedback.
adCost	Allowing breakdown of adCost.	Each cost value is an opportunity to send a limited amount of information out of the auction. Allowing a whole list of N of those costs would be enough to send a whole user identifier, which would enable cross-site tracking. We are discussing this here and welcome additional feedback.
resolveToConfig	Should resolveToConfig be inherited from the top level and exposed in browserSignals?	We are discussing this request here and welcome additional feedback.
ابزارهای بهتر	Is there something akin to chrome://topics-internals but for PA API?	There is nothing exactly the same. However, there is extensive developer tooling for PA API .
برچسب ها	Can Chrome use labels to identify the 20% k-anon population?	We are considering this request and welcome additional feedback from the ecosystem.
مستندات	Will Privacy Sandbox auction worklets become standard worklet types?	Due to unique privacy and security requirements, these worklets differ significantly from standard browser worklet types, so we do not anticipate that they will become standard worklet types within the HTML specification soon. We are committed to enhancing our developer resources with clear explanations about the implementation and execution environment of auction worklets, making this information more accessible for Privacy Sandbox participants. We have discussed this further here .
Bring-Your-Own-Server (BYOS) Key-Value (KV) server	Parties may be able to learn multiple IGs (from the same owner) joined by a user through KV services queries in a BYOS KV Service setup.	This will no longer be possible when KV servers run in TEEs and we can ensure they can abide by the published trust model.
userBiddingSignals	update part of the "userBiddingSignals" while maintaining others.	This is already possible without any changes required to the API.
استفاده از API	Implement frequency capping across multiple IGs within the Privacy Sandbox, potentially using the KV server or modified "prevWinsMs" data.	We acknowledge the desire for advanced frequency capping capabilities within the Privacy Sandbox. We recognize that current restrictions on data sharing across IGs can present challenges when implementing these strategies. While the KV server provides a potential mechanism with appropriate privacy safeguards, we encourage developers to explore solutions within a single IG model. We are discussing this issue here and welcome additional feedback.
استفاده از API	Component sellers (those participating in nested auctions within the Privacy Sandbox) need visibility into top-level auction timeouts to optimize their own configurations and avoid unnecessary delays.	We recognize the need for improved timeout coordination between top-level sellers and component sellers within the Privacy Sandbox. We are actively investigating the addition of new timeout mechanisms, including a potential whole-auction timeout and exploring ways to apply top-level timeouts to component auctions. Our goal is to enhance efficiency and predictability for all participants in the Privacy Sandbox auction process. We are discussing this issue here and welcome additional feedback.

Protected Audience Services

Feedback Theme	خلاصه	Chrome Response
Trusted Execution Environments (TEEs)	More expensive to run TEEs in public clouds as opposed to on-premise ad tech data centers?	Our response is similar to previous quarters: Our current TEE security model benefits from the practices of public cloud implementations. In particular, current hardware-based TEEs do not defend against all physical attacks. Our existing supported public cloud providers, AWS and GCP, designed and implemented mitigations for physical access risks, including from employees. See further details below regarding on-premise support. Ad techs have mentioned to us that running cloud services is more expensive than on-premise ad tech data centers. While we are not in a position to evaluate those statements, we welcome additional feedback on costs and continue to evaluate options for expanding our TEE support.
TEEs	Support for TEEs in non-public cloud environments	Our response is similar to previous quarters: While we are continuing to explore support for options beyond public cloud-based solutions, we have no current plans to support on-premise TEEs. At this stage, given Privacy Sandbox security requirements and the significant challenges presented by on-premise deployments, we believe that continuing to expand and improve cloud-based deployments (for example, supporting Google Cloud in addition to AWS) is the most beneficial for the زیست بوم. However, we welcome additional feedback on why such a requirement is necessary and feasible given the privacy and security constraints.
Other Cloud Providers	Support for other cloud providers	We are always open to suggestions for other cloud providers, but currently we are planning at least to support GCP and AWS when 3PCD is enforced. Refer to this explainer for more information.
B&A Services API	What is Google's direction for the B&A Services API? Will it be prioritized above or below the Chrome browser Protected Audience on device auctions?	Our response is similar to previous quarters: We remain committed to the current Protected Audience on-device bidding design. The B&A services have been proposed to explore possible solutions to support a subset of use cases where the computational power or network speed of the device may be limited.
استاندارد سازی	B&A services have not gone through a standardization process.	The B&A Services proposal is in the middle of one phase of the standardization process, and we welcome additional engagement in support of that goal. It began with a proposal (based on previous proposals), it is being publicly incubated through extensive open discussion at W3C and interested developers are able to begin experimenting with it and providing feedback. This is the usual pattern for web feature development, as described for example in our blog post here .
KV Server	Expose full URL to buyer's KV server for content / contextual / site targeting.	We are discussing this request here and welcome additional feedback from the ecosystem.
مستندات	The documentation for "Trusted/Enforced components vs. optional" on GitHub causes confusion with some ad techs who have their own set of deployment images and infrastructure.	We are looking to improve the documentation for "Trusted/Enforced components vs optional", and am interested in hearing from the ecosystem if such work needs to be prioritized.
API Improvement	The HTTP Status Code of a KV server call should also be available to the scoreAd() function as a parameter.	We are evaluating this request and welcome additional feedback from the ecosystem.
مستندات	Provide more information on how JS and WASM workloads would be handled exactly with the UDF execution.	We are looking into providing this information and welcome additional feedback here .
مستندات	Request to update repo name.	We have renamed the repository to "protected-auction-key-value-service". This is in line with the term for the collection of services this belongs to, which also has other repositories such as the Protected Audience Services discussion , and the Protected Auction Services documentation repos.
مستندات	Remove reference to Cloud debugger API in bidding_auction_services_gcp_guide.md.	We have updated the documentation and removed the reference.
استفاده از API	Latency introduced by the KV lookup is taking more than 50ms. It's taking nearly 100ms. Do you have any guidance on what's been working well for other sellers? Do you have any suggestions on how to measure the timeouts and timing?	The KV server call happens inside the context of the Script Runners, ie the special protected environment inside of the Chrome browser. It is intended to keep information in these script runners protected from any non-API access. We have provided a detailed explanation here .
استفاده از API	Is there a timeout for the KV server to respond in a particular time?	Sellers can specify the "perBuyerCumulativeTimeouts" field in the auction config. This timeout includes the time needed to fetch trusted bidding signals.
تاخیر	How is the Privacy Sandbox team working to address latency?	For strategies we are exploring to keep the latency within acceptable limits, see here .

Measuring Digital Ads

Attribution Reporting (and other APIs)

Feedback Theme	خلاصه	Chrome Response
Manual Campaign Optimization	ARA does not support manual campaign optimization.	We have discussed this scenario with the ad tech and shown ways in which ARA can be used to support manual campaign optimization. ARA has been built in a way that allows for ad tech customization and flexibility to solve a range of ad tech use cases. A few suggestions that were provided included using different flexible event-level configurations and, using event-level reports with summary reports to reduce the impact of noise and to achieve their manual and automatic optimization needs. We are open to additional ecosystem feedback regarding the customizability and flexibility of ARA configurations.
نوع تبدیل	Google is only allowing eight conversion types which is limiting.	We have implemented the majority of Flexible event-level reporting , which gives ad techs additional flexibility in terms of the number of reporting windows, number of attribution reports, and bits of trigger data that they can use. Ad techs can choose a configuration that allows measuring up to 32 different conversion types.
Aggregatable Report Event Limit	The numerical minimum of 20 conversion events per aggregable report is not workable for smaller advertisers with limited budget.	There is no minimum number of conversion events needed per aggregatable report. Additionally there are a number of design decisions that can be made to optimize aggregatable reports for smaller advertisers such as changing the key structure / dimensions tracked, testing different levels of epsilon, testing longer batching frequencies, and testing different contribution budget allocations between measurement goals. Smaller ad techs can also experiment with combining event-level reports and summary reports as a way to reduce the impact of noise.
داده های زمان واقعی	Depriving DSPs of real-time data (eg on clicks, sessions, and conversions) which DSPs use to adapt their bidding strategy and achieve better campaign effectiveness, goes against the commitment to maintain existing functionalities.	Even with ARA, clicks and sessions remain real time, and conversions are always after the fact even with 3PCs.
Missing Fields	Missing requirements in the Full Flexible event rollout: i) Currency field, and ii) orderID / TransactionID field.	We do not plan to support a Currency field or Order ID / Transaction ID field currently as part of full flexible event-level because there are already ways to do this with current event-level reporting. We are open to additional feedback regarding these fields, and will reconsider if there are additional use cases that require these. The ways to use ARA's current design to measure currency and order ID type information: 1. Based on the feedback, the currency is determined by a user's geo, which can be added as part of the source_event_id as a way to determine what currency was used. 2. Based on the feedback, the order ID field is needed to ensure conversions and values are not double counted by mistake, which can be done by using deduplication keys.
بودجه حریم خصوصی	ARA Privacy Budget limits the ability to measure across multiple dimensions	ARA has been designed in such a way as to allow ad techs to customize their own ARA configurations to cover a variety of attribution scenarios. With the current ARA design ad techs will need to think about the trade off between what dimensions are most crucial for them to measure and the impact of noise on their data. Adding noise to the data depending on the granularity of dimensions that are being measured is essential for privacy. We are open to additional ecosystem feedback regarding the ability to measure across different dimensions, but would need to understand the specific use cases that require this.
Update Specification	Although Google has said it has moved from fixed to flexible event reporting windows, this has not been reflected in Google's Technical Specifications which still currently has a minimum window of one hour.	Flexible event-level reporting currently allows ad techs to change the number of attribution reports per source event, the bits of trigger data, and the number/length of reporting windows. ARA still has a minimum reporting window of 1 hour for event-level reports which is essential to maintain privacy and mitigate against certain types of history reconstruction attacks. Since summary reports provide information in aggregate, ad techs can opt in to receive aggregatable reports immediately with no delay, if needed for their use cases.
API Design	Concern that reducing information in conversion reports and adding noise could impact the ecosystem more than Google.	Google has committed to the CMA to design and implement the Privacy Sandbox proposals in a way that does not distort competition by self-preferencing Google's own business, and to take into account impact on competition in digital advertising and on publishers and advertisers of all sizes.
Attribution Correction	ARA doesn't allow the tech provider to control and verify the correct attribution.	There are many available solutions within ARA that provide verification capabilities: 1. Ad techs can verify that ARA behavior matches their expectations: – ARA client-side code is open-sourced. – ARA server-side code is also open sourced, and Coordinators ensure that only allowed versions of Aggregation Service can decrypt and process aggregatable reports. 2. Chrome has provided ad techs with a Simulation Library to verify attribution behavior, where the ad tech can test how ARA performs attribution in a mock environment. 3. ARA supports a number of debug signals that help to verify whether or not and why expected processing may not have occurred.
(Also reported in previous quarters) سر و صدا	Feedback that the level of noise is too high and it is impacting the usefulness of the reporting.	We have spoken to ad techs with this same feedback and were able to identify ways in which ARA can be customized to better suit their use cases, even with noise. We have developer documentation that contains the majority of design decisions and customizations that we discussed with the ad techs. ARA has been designed in a way to allow ad techs to customize their own ARA configurations to cover a variety of attribution scenarios. But ad techs will need to think about the trade off between what dimensions are most crucial for them to measure and the impact of noise on their data. We are open to additional ecosystem feedback regarding the impact of noise and can provide additional guidance on ARA levers that can be used to change the impact of noise.
Cross-domain Attribution	How to track the attributions that are cross domain?	Ad techs can redirect to different reporting URLs to solve for this use case. We are open to additional ecosystem feedback regarding this design aspect of ARA.
API Improvement	Regularly change the scaling factor used when registering attribution for ARA Summary Reports.	Based on the discussion on GitHub, it seems that handling multiple scaling factors in Aggregation Service will most likely result in a higher amount of noise added to summary reports versus the current functionality. We are open to additional feedback regarding the need for scaling factors as part of aggregatable reports, but want to call out the potential trade off with increased noise. We are also evaluating whether other future ARA features may help to solve this use case as well.
استفاده از API	Opportunity to unify how attribution events get shared with all participants which is beneficial for SSP, DSP, etc.	We plan to sync with ad tech to better understand their feedback and any limitations they are running into.
Test Traffic Volume	Is the test traffic for Mode B for all Chrome stable?	Inclusion in an experiment group is unaffected by (independent of) Chrome settings.
مستندات	Support ARA for pixels.	We have published information about how to support this use case and welcome additional feedback from the ecosystem.
استفاده از API	ARA may not be attributed to the correct source for third-party sellers on ecommerce platforms if the conversion is not done by the last touch.	Companies can use filters to prevent incorrect attribution from happening (as in no conversion report will be generated). We are also working on a proposal for pre-attribution filtering to help with this use case.
پشتیبانی مرورگر	Will ARA be supported in different browsers?	We welcome other browsers to adopt the Privacy Sandbox APIs and continue to dedicate time to discussing our approach in the open at W3C. We have explicitly stated interoperability as a goal for shipping ARA and ARA's design is intended to be browser-agnostic with flexible vendor-specified values for vendors with different privacy stances. Other browsers are making their own choices on whether to provide viable alternatives to cross-site identifiers that can support the digital ecosystem of content and services. We're encouraged that Microsoft Edge has indicated it will support A RA .
استفاده از API	What is the expected source kind for ARA source registrations for registerAdBeacon/reportEvent (and navigation_start/commit automatic beacons)?	It depends if these beacons are automatic or manual: - reserved.* (ie automatic) events to be of navigation-source type. - Manually triggered events to be of event-source type.
استفاده از API	Does the maximum limit of 20 aggregatable reports per source mean for each source event? Is the limit global or daily? Is there a plan to increase the limit?	The 20 aggregatable reports per source limit is a global limit where 20 aggregatable reports can be created for each source. The limit is set by the browser and non-configurable. The purpose of this limit is to avoid abusing the protection of real attribution reports with null reports. We have discussed this further here .
استفاده از API	Support for email marketing using ARA.	Right now there is no direct support for this use case within ARA (if you don't control the email hosting site). We are discussing this here and welcome additional feedback.
اپسیلون	When will the value of epsilon for the Aggregate API be determined?	The current epsilon value can be configured by ad techs up to a predetermined threshold defined by Privacy Sandbox (which is currently 64). We recommend testing different epsilon values and identifying inflection points for your own use cases and providing feedback. We will make sure to communicate to ad techs in advance prior to any changes to the range of epsilon values.
API Improvement	Support a use case where the advertiser can insert an identifier into the trigger_data field for matching with external CRM data to allow advertisers to verify the quality of conversions.	We are discussing the request and welcome additional feedback here .
استفاده از API	How to handle redirect URLs as destination urls.	Ad techs can do either of the following: 1. Put the final destination URL in the destination field; 2. Destination field allows up to 3 urls which allows you to put multiple URLs into the field. Both options will require knowing the final destination URL. We have discussed this further here.

Aggregation Service

Feedback Theme	خلاصه	Chrome Response
Key Discovery Mechanism	Request for a key discovery mechanism	We have a proposal for key discovery and welcome feedback from the ecosystem on the proposal.
استفاده از API	Roadmap for observability on Aggregation Service	We are reviewing options to support more observability and welcome feedback from the ecosystem here .
API Improvement	Requesting to be able to requery reports.	Aggregation Service is working on a requerying proposal where ad techs can split their epsilon for each report. This can introduce more noise per query but will allow ad techs to requery and maintain privacy.
API Improvement	Would like to be able to associate multiple origins to the same AWS ID.	Aggregation Service will now allow multiple sites to be onboarded on the same cloud account (GCP or AWS). This will allow ad techs to use the same Aggregation Service enclave for processing reports from multiple sites and multiple origins from the same sites.
استفاده از API	When aggregatable batches fail, not sure if the budget is consumed or not and if they can reprocess their batch. When an aggregation service encounters a budget error for duplicate reports, the rest of the remaining reports are lost. How to minimize this loss?	In a typical scenario, if the entire job fails, the budget will not be consumed. In cases of a rare failure where budget is consumed, ad techs can request budget recovery. If the ad tech encounters frequent job failures with the budget exhausted error, they should confirm their batching strategy. Instructions on how to batch correctly and avoid duplicate reports and errors can be found here . We welcome feedback on budget recovery here .
استفاده از API	Using Private Aggregation API with the trigger described here would produce an aggregatable report for every auction. What are the scaling capabilities of Aggregation Service?	Aggregation Service itself does not put an upper limit on the number of keys or reports in a batch but a scale of 10^14 reports and 10^12 keys is currently unsupported due to the memory that would be required. Our sizing guidance indicates the ranges we have tested and recommend for optimal performance given expected load and the supported cloud vm instance types.
پردازش داده ها	If an encrypted data has personal information, what is the legal arrangement of providing encrypted data to the Aggregation Service? Can you advise whether it is guaranteed that the coordinator will not access encrypted data?	The Aggregation service does not share encrypted / user data with the Coordinator. The Aggregation service uses the coordinator for key management and accounting. Some details on the coordinator can be found here . For accounting, Aggregation service only shares the shared ID and the reporting origin with the PBS for budget consumption. Once we launch a multi-site we will replace origin with site. Note that Aggregation service runs in a TEE which is the only place where reports from clients can be decrypted. The code running in the TEE is open sourced and audited by external parties as outlined here .

Private Aggregation API

Feedback Theme	خلاصه	Chrome Response
استفاده از API	Ability of component sellers to send reports to multiple aggregation servers within a TEE.	The current Private Aggregation API status does not support this feature. We have discussed this issue further here .
مستندات	What is the epsilon value used in Google's trials?	For the Private Aggregation API, the ε value specified in an aggregation service query corresponds to the L1 contribution budget of 2^16 that is enforced on a rolling 10 minute basis. There's also a 'backstop' L1 contribution budget of 2^20 that is enforced on a rolling 24 hour basis. So essentially, the privacy parameter is ε on a rolling 10 minute basis, and is 16ε on a rolling 24 hour basis (rather than 144ε). Aggregation service currently supports a range of ε for testing (up to 64) to allow for experimentation with different aggregation strategies and provide feedback on the utility of the system with different privacy parameters for Private Aggregation and other APIs. We plan to revisit the maximum allowable epsilon value over time as we get feedback from testers and add features that allow for more efficient privacy budget usage.

Limit Covert Tracking

User Agent Reduction/User Agent Client Hints

No feedback received this quarter.

IP Protection (formerly Gnatcatcher)

Feedback Theme	خلاصه	Chrome Response
Resolution ID	Privacy Sandbox needs to be more vocal to press that resolution IDs often built on IP are not sustainable for advertisers.	Privacy Sandbox has made it clear that we aim to reduce cross-site tracking. Our public initiatives, which extend beyond cookies, are publicized both on privacysandbox.com and GitHub. We strive to reduce cross-site tracking, including that based on IP addresses. However, it is ultimately up to individual websites to decide whether to proactively enable cross-site tracking. In an era of increased scrutiny on regulatory compliance, it is prudent for individual companies to have an understanding of the practices employed by their service providers.
Chromecast	Will IP Protection impact Chromecast or other Chrome devices?	There are currently no plans for IP Protection to be applied to Chromecast devices.
IP Protection List	Will the list of third parties identified as potentially using IP addresses for web-wide cross-site tracking be published?	The list will be published once finalized, as discussed here .

Bounce Tracking Mitigation

Feedback Theme	خلاصه	Chrome Response
Single Sign On (SSO) Exemption	How will Bounce Tracking Mitigation (BTM) verify SSO use cases for exemption?	BTM will be disabled by Chrome heuristics. برای جزئیات اینجا را ببینید.
Deprecation Trial	Is BTM enabled for sites in the 3PC deprecation trial?	No, BTM honors the cookie exceptions created by the deprecation trial, as discussed here .

بودجه حریم خصوصی

As noted in the GitHub explainer and developer site, Privacy Budget is no longer being actively considered as part of the Privacy Sandbox proposals.

Strengthen cross-site privacy boundaries

Related Website Sets (formerly First-Party Sets)

Feedback Theme	خلاصه	Chrome Response
درخواست ویژگی	CHIPs and / or Storage Partitioning are automatically allowed to be accessed across the RWS, without the need for the Storage Access API, nor user interaction.	We are considering the benefits and feasibility of a feature that may perform this function. One consideration is a potential gap in cross-browser interoperability, which RWS addresses by leveraging the Storage Access API. There is no current equivalent to this requested functionality supported on other browsers. We encourage developers to submit their use cases on this issue to facilitate discussion here .
Removal of Non-compliant Sets	What is the process to remove sets that become non-compliant from the repository?	We are working on defining a process for this, and we'll share updates as soon as they're available.
Enforcement Process	There is a lack of clarity around Google's subjective role in the RWS enforcement process.	As RWS is an ongoing project and we are continuing to receive new submissions, aspects of the process and our criteria are still being solidified. We do agree that it is important for our submission guidelines to fully outline our requirements for submission, and we will add greater detail to our submission guidelines going forward to avoid further ambiguity and confusion. Our intent is for the submission process to be as technical as possible so that we can phase out human involvement and entirely rely on automated checks. PRs such as this one necessitate more human interaction because they include behaviors we did not anticipate, but they allow us to identify more areas for automation and ways we can fix our guidelines to avoid these problems going forward.
Sharing Data	Request for a feature that allows domain owners to indicate they would like a third party to also share RWS data, with user consent.	The requested functionality is already available through APIs such as FedCM, and Storage Access APIs that enable access to authenticated identity after the user accepts a permission prompt. We welcome feedback from the ecosystem on any specific use cases that they believe are not possible.
Other Storage Methods	Will information saved on local storage or session storage will also be interpreted as 3PCs?	Local storage, session storage, and other forms of non-cookie storage when used within third-party contexts have been partitioned in Chrome since version 115. See this blog post for additional details.
Associated Sets Limit	What happens to organizations who submit more than 5 domains even though this is "capped at 5 associated sites"?	These sets will be accepted via the GitHub process, but the browser (Chrome) will only apply our Storage Access API auto-granting rules to the first 5 domains; and ignore the remaining domains, as discussed here .
find_robots_txt	find_robots_txt check does not work with redirects.	A fix has been submitted to resolve this issue here .
User Gesture	Remove user gesture requirement for accessStorage().	This requirement was made based on a similar design that is in place across all major browsers for the requestStorageAccess API. We invite additional feedback and use cases in this GitHub issue to help us prioritize this request, and enable cross-browser discussions.
User Gesture	Is a user-gesture required to grant permission for third-party storage access after a Chrome or OS restart?	Yes, but we welcome additional feedback from the ecosystem on whether to change this behavior here .

Fenced Frames API

Feedback Theme	خلاصه	Chrome Response
adComponent	Lack of documentation and flexibility using AdComponents with Fenced Frames.	We are looking to share more documentation regarding this use case. Also to add, ad components are supported in Fenced Frames using getNestedConfigs() which is documented in the spec here .
(Also reported in previous quarters) Render adComponent	Request for sample codes on how to render adComponents in Fenced Frame.	We are working on sharing some sample codes here .
Third-party Ad Verification	The role of third-party ad verification in the context of Fenced Frames needs more detail, especially regarding contextual/brand safety.	Today, Fenced Frames Ad Reporting does allow for DSPs to send impression and auction event-level data to 3P ad verifiers for post-render brand safety checks and billing.
Expandable Ads	Request to support expandable ads.	If the ad needs to switch between two sizes with the same aspect ratio, and there is no functional difference between the two (just size), the embedder could resize the Fenced Frame with the second ad size and the browser accordingly scales the Fenced Frame element .
(Also reported in previous quarters) Support for Video & Native Inventory	Does Fenced Frames support video & native inventory?	Our response is similar to previous quarters: PA API supports video rendering using a mechanism that relies on iframes. However, we haven't yet designed a solution for video and native ads rendering that is compatible with Fenced Frames, and this is one of the reasons we had decided to push back Fenced Frames enforcement to 2026. That means if a partner does decide to enforce Fenced Frames now, the support for video and native would be lacking for that partner.
هیئت مشورتی	Requests the creation of an advisory board of native ad vendors to ensure Fenced Frames implementations follow industry standards.	Fenced Frames are not required for use in PA API any sooner than 2026. The additional time allows us to continue working with the industry to design and implement support for a broader range of critical use cases. We've previously stated we will evolve Fenced Frames ahead of their requirement to maintain support for video and native ads with PA API. Per our commitments, we will engage with and inform the CMA of any such changes, and we will continue engaging with feedback from the ecosystem ahead of requiring Fenced Frames. Our ecosystem engagement model at W3C and ad standards organizations like IAB Tech Lab allows for industry experts of all kinds to guide the designs before they are required.
(Also reported in previous quarters) Size Difference Across Platforms	Reports that the size of content displayed in the Fenced Frame looks different between desktop and smartphones.	This is a known Chromium issue which we are investigating. We welcome additional feedback here .
API Improvement	Did the Fenced Frames requirement get pushed back to 2025 so that native ads are now supported under Privacy Sandbox?	As we noted in our public announcement for Fenced Frames enforcement no sooner than 2026, we had learned of a broad "significant effort to accommodate" Fenced Frames. Certainly, one of which was Native, but it was not the only factor. The intent was to provide more time to ensure ecosystem readiness to support key use cases, including, but not limited to, native.

API ذخیره سازی مشترک

Feedback Theme	خلاصه	Chrome Response
کارایی	Shared Storage return times outside of the worklet appear to be dependent on activity in the worklet.	We are discussing this test result here .
Wider Adoption	Shared Storage should be an industry-wide standard available across browsers.	We welcome and acknowledge this feedback. Chrome is continuing to actively participate in W3C fora, including the WICG , to champion the proposal, seek feedback, and drive adoption.
Bidding Worklets	Is it possible to read from Shared Storage within the generateBid (which is already running in a worklet) to apply ad-decision / business logic (such as Frequency Capping) based on cross-site information and select a subset of ads?	No, it is impossible to read from shared storage within bidding worklets.

چیپس

Feedback Theme	خلاصه	Chrome Response
Partition Capacity	Clarify behavior when over partition capacity.	When capacity is reached, the oldest cookies are ejected from the least recently accessed cookie(s) to free memory until the limit is no longer surpassed. Developers see the updated Cookie header in subsequent requests.
Third-party iFrame Access	Embedded third-party iFrame content opening a new tab/window to the same third-party site should have access to the same partitioned cookies as the opener.	We are discussing this use case and welcome additional feedback from the ecosystem here .
Duplicate Cookies	If there's a partitioned cookie and an unpartitioned cookie with the same name, which key value does the browser decide to send?	When having two cookies with the same name (one partitioned, and one not), you'll get both cookies – unfortunately, there is no way to differentiate which is which. The RFC spec on this is available here , which explains that the order in which cookies are sent should not be relied upon.
درخواست ویژگی	Opt into origin-partitioned cookies.	We are considering this request and welcome additional feedback from the ecosystem here .

FedCM

No feedback received this quarter.

Fight spam and fraud

Private State Token API (and other APIs)

Feedback Theme	خلاصه	Chrome Response
نمای وب	Are Private State Tokens (PSTs) persisted across multiple Webviews on the same mobile device (profile)?	Each app that uses webview will have a different local storage, which means PST issuers cannot issue tokens in one app's webview and then later in a separate app, allow token redemptions. This is true for other forms of data stored locally on webviews as well, such as cookies. PSTs are not yet fully available in WebView. We expect to provide an update on this by the end of Q2.
New Token Type	Proposal for a new token type.	We are thankful for this proposal and continued exploration into applications and adaptations of PSTs, and look forward to learning more about this proposal in upcoming Anti-Fraud Community Group meetings in Q2 2024.
User Identification	How to prevent users being identified based on the particular PSTs a user has?	This is currently mitigated by limiting redemption attempts on a site to two issuers, regardless of whether there are tokens available from that issuer. You need to count an issuer against the limit even if there aren't tokens available as otherwise the site could iterate through all issuers until it hits a positive match.
ثبت	How long will registration be required for PSTs?	Registration will continue to be required for the foreseeable future, as explained in further detail here .
Support for other Chromium Browsers	Will PST issuer registration for other Chromium-based browsers be supported through the Chrome Issuer Registration repository ?	Chrome fetches the key commitments and distributes them to Chrome clients through a mechanism called Component Updater. As other browsers add more complete support for the API, they'll need to establish a process for getting the key commitments to the client, either through a component updater-style method or some other method. This is addressed in further detail here .