گزارش فصلی برای سه ماهه چهارم سال 2024، خلاصه بازخورد اکوسیستم دریافت شده در مورد پیشنهادات جعبه ایمنی حریم خصوصی و پاسخ Chrome.
به عنوان بخشی از تعهدات خود به CMA، Google موافقت کرده است که گزارشهای سه ماهه در مورد فرآیند تعامل با ذینفعان را برای پیشنهادات جعبه ایمنی حریم خصوصی خود به صورت عمومی ارائه کند (به پاراگرافهای 12 و 17(c)(ii) تعهدات مراجعه کنید). این گزارشهای خلاصه بازخورد Sandbox حریم خصوصی با جمعآوری بازخوردهای دریافتی توسط Chrome از منابع مختلف که در نمای کلی بازخورد فهرست شده است، ایجاد میشوند، از جمله اما نه محدود به: مشکلات GitHub، فرم بازخورد موجود در privacysandbox.com ، جلسات با سهامداران صنعت، و انجمنهای استانداردهای وب. Chrome از بازخوردهای دریافتی از اکوسیستم استقبال می کند و به طور فعال در حال بررسی راه هایی برای ادغام آموخته ها در تصمیمات طراحی است.
مضامین بازخورد بر اساس شیوع در هر API رتبهبندی میشوند. این کار با جمعآوری مقدار بازخوردی که تیم Chrome در مورد یک موضوع خاص دریافت کرده و به ترتیب نزولی از نظر سازماندهی انجام میشود. مضامین رایج بازخورد با بررسی موضوعات بحث از جلسات عمومی (W3C، PatCG، IETF)، بازخورد مستقیم، GitHub و سوالات متداول مطرح شده از طریق تیمهای داخلی Google و فرمهای عمومی شناسایی شدند.
به طور خاص، صورتجلسات جلسات بدنه استانداردهای وب بررسی شد و برای بازخورد مستقیم، سوابق Google از جلسات 1:1 ذینفعان، ایمیلهای دریافتی توسط مهندسان فردی، فهرست پستی API و فرم بازخورد عمومی در نظر گرفته شد. سپس گوگل بین تیمهای درگیر در این فعالیتهای ارتباطی مختلف هماهنگ کرد تا شیوع نسبی موضوعات در حال ظهور در رابطه با هر API را تعیین کند.
توضیحات پاسخهای Chrome به بازخورد از پرسشهای متداول منتشر شده، پاسخهای واقعی به مسائل مطرحشده توسط ذینفعان و تعیین موقعیت بهویژه برای اهداف این گزارش گزارش عمومی ایجاد شده است. با توجه به تمرکز فعلی توسعه و آزمایش، سؤالات و بازخوردها به ویژه در رابطه با موضوعات، API PA و APIها و فناوری های گزارش اسناد دریافت شد.
بازخورد دریافتی اخیراً ممکن است هنوز پاسخی در نظر گرفته شده برای Chrome نداشته باشد.
واژه نامه کلمات اختصاری
- آرا
- Attribution Reporting API
- چیپس
- کوکی هایی که دارای حالت تقسیم شده مستقل هستند
- DSP
- پلتفرم سمت تقاضا
- FedCM
- مدیریت اعتبار فدرال
- IAB
- دفتر تبلیغات تعاملی
- بیجاشدگان داخلی
- ارائه دهنده هویت
- IETF
- کارگروه مهندسی اینترنت
- IP
- آدرس پروتکل اینترنت
- openRTB
- مناقصه در زمان واقعی
- OT
- آزمایش مبدا
- PA API
- API مخاطب محافظت شده (FLEDGE سابق)
- PatCG
- گروه اجتماعی فناوری تبلیغات خصوصی
- RP
- حزب اتکا
- RWS
- مجموعههای وبسایت مرتبط (سستهای شخص اول سابق)
- SSP
- پلت فرم سمت عرضه
- UA
- رشته عامل کاربر
- UA-CH
- نکات مشتری عامل کاربر
- W3C
- کنسرسیوم وب جهانی
- WIPB
- کوری IP ارادی
بازخورد عمومی، بدون API/فناوری خاصی
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
تعهدات | بخش G از تعهدات برای زنده ماندن جعبه ایمنی حریم خصوصی ضروری است. بدون ضمانت اینکه کسب و کار تبلیغاتی خود Google منحصراً بر روی فناوریهای Sandbox عمل میکند، خطر کاهش روزافزون ابزارها و همچنین احتمال واگذاری Google از فناوری افزایش مییابد. چنین واگذاری یا کاهش سودمندی یک تهدید وجودی برای آدرسپذیری حریم خصوصی در وب باز خواهد بود. | تعهدات تضمین نمیکند که کسبوکار تبلیغاتی خود Google منحصراً بر اساس فناوریهای جعبه ایمنی حریم خصوصی کار میکند. Google در نظر دارد از یک رویکرد نمونه کارها برای آدرسپذیری استفاده کند، که شامل فناوریهای جعبه ایمنی حریم خصوصی میشود، همان روشی که اشخاص ثالث میتوانند و انجام میدهند. ما درک می کنیم که یک رویکرد نمونه کارها در سراسر اکوسیستم تبلیغات رایج است. ما معتقدیم که داشتن ابزارها و فناوری های حفظ حریم خصوصی برای توسعه دهندگان مهم است. ما به در دسترس قرار دادن Privacy Sandbox APIها و سرمایه گذاری در آنها برای بهبود بیشتر حریم خصوصی و ابزار ادامه خواهیم داد. |
حکومت داری | مدل حاکمیتی پیشنهادی شامل سازوکارهای خاصی برای پاسخگویی در فرآیندهای مشاوره رسمی یا تجدیدنظر نیست. | این درست نیست. هم (i) سیستم تصمیمگیری و نشریات مرتبط و (۲) فرآیند تجدیدنظر مکانیسمهای خاصی را برای پاسخگویی فراهم میکنند. علاوه بر این، متولی نظارت بر عملکرد آنها به تفصیل نظارت خواهد کرد. |
حکومت داری | بازخوردی مبنی بر اینکه این مدل حاوی مقرراتی برای ایجاد و نگهداری یک استاندارد بین پلتفرمی نیست. | هیچ مدل حاکمیتی نمی تواند سایر بازیگران، در این مورد مرورگرها، را مجبور به اتخاذ یک استاندارد کند. بنابراین ما مدلی پیشنهاد نکردهایم که مستلزم پذیرش استانداردهای بین پلتفرمی باشد. Google به شرکت در انجمنهای استاندارد ادامه میدهد، جایی که ارائه پیشنهادات و به اشتراک گذاشتن تجربه در اجرای پیشنهادات یک فعالیت رایج در این فرآیند است. |
حکومت داری | توصیه می شود مدت زمان مشاوره را حداقل به 2 ماه افزایش دهید. مدل حاکمیت پیشنهادی زمان کافی برای تجزیه و تحلیل اثرات تغییرات پیشنهادی را در اختیار اکوسیستم قرار نمی دهد. | دوره سه هفته ای کل دوره بازخورد برای یک تغییر مشخص نیست زیرا چرخه های بازخورد موجود (که بسیار طولانی تر هستند) ادامه خواهند داشت. فرآیند مشاوره در عوض یک پنجره بازخورد رسمی و جدید در فرآیند موجود برای تصمیمات استراتژیک ارائه می دهد. به این ترتیب، اشخاص ثالث همچنان میتوانند از طریق انجمنهای مختلف (از جمله GitHub، W3C و سازمانهای استاندارد تبلیغات مانند IAB Tech Lab) ورودی را در طول دوره توسعه ویژگی ارائه دهند. ساختار چرخههای بازخورد به این روش به اکوسیستم فرصتی میدهد تا نظرات خود را در مورد یک تغییر پیشنهادی بدون تاخیر مادی در فرآیند توسعه تجزیه و تحلیل کند و به اشتراک بگذارد. |
حکومت داری | درخواست جزئیات در مورد برنامه های حکومتداری آینده. | خلاصه ای از مدل حاکمیتی پیشنهادی در گزارش Q2/Q3 2024 CMA ارائه شده است (صفحات 3-5 اینجا ). |
درخواست استثناء | درخواست استثنا برای دسترسی به کوکیهای شخص ثالث (3PC) برای کاربرانی که رضایت دارند. | رضایت به دسترسی و ذخیره سازی دستگاه برای اهداف خاص پردازش داده به این معنی نیست که کاربر می خواهد تنظیمات 3PC خود را در Chrome لغو کند. اجازه دادن به نادیده گرفتن تنظیمات 3PC کاربر در سطح سایت، پتانسیل قابل توجهی برای سوء استفاده ایجاد می کند و برای Chrome غیرممکن است که رفتار همه سایت ها را که ممکن است منجر به درخواست استثنا شود بررسی کند. |
جعبه ایمنی حریم خصوصی | درخواست نرخهای انتخاب API Privacy Sandbox. | ما هیچ برنامه ای برای به اشتراک گذاشتن این اطلاعات با اکوسیستم نداریم. توسعهدهندگان میتوانند با APIهایی که امروز کدی را در آنجا مستقر کردهاند تماس بگیرند تا در دسترس بودن APIهای جعبه ایمنی حریم خصوصی را تخمین بزنند. |
آزمایش مبدا | آیا برنامه ای برای تمدید دوره آزمایشی مبدا وجود دارد؟ | آزمایش اولیه تا 14 آوریل 2025 تمدید شده است. |
جعبه ایمنی حریم خصوصی | درخواست توضیح مختصر و غیر فنی Privacy Sandbox که ارزش تجاری آن را برجسته میکند و خرید اجرایی را تضمین میکند. | ما اخیراً یک بخش منابع تجاری را به privacysandbox.com اضافه کرده ایم که این اطلاعات را ارائه می دهد. |
حالت B | وقتی یک مرورگر در حالت B است، کوکی فعلی (1PC، 3PC، حافظه محلی) باقی می ماند یا پاک می شود؟ | شیشه کوکی فعلی پاک نخواهد شد. 3 رایانه شخصی در زمینه شخص اول خود در دسترس خواهند بود. |
رویکرد به روز شده برای 3PC در Chrome | آیا 3 رایانه شخصی در آینده به طور کامل از Chrome حذف می شود؟ | ما یک رویکرد به روز شده را پیشنهاد می کنیم که انتخاب کاربر را افزایش می دهد. همانطور که در اینجا ذکر شد، به جای منسوخ کردن 3PC، تجربه جدیدی را در Chrome معرفی می کنیم که به افراد امکان می دهد انتخاب آگاهانه ای داشته باشند که در سراسر مرور وب آنها اعمال می شود و آنها می توانند هر زمان که بخواهند این انتخاب را تنظیم کنند. ما در حال بحث در مورد این مسیر جدید با تنظیمکنندهها هستیم و قبل از اجرای این مسیر با صنعت درگیر خواهیم شد. |
تست کروم | درخواست برای ادامه در دسترس بودن برچسبهای آزمایشی با تسهیل Chrome. | تیم Privacy Sandbox میداند که شرکتها مایلند به استفاده از برچسبهای لغو کوکیها ادامه دهند. روند گسترش در دسترس بودن برچسب ها شبیه به گسترش آزمایش مبدا است. بهعنوان بخشی از این فرآیند، آزمایش ممکن است فقط برای سه نقطه عطف Chrome در یک زمان تمدید شود . به عنوان مثال، جدیدترین Intent to Extend Experiment ( I2EE ) Chrome برای برچسبهای منسوخ شدن کوکیها برای Chrome M130-M132، شامل تمدید شد. این امکان پشتیبانی از برچسب ها را تا زمان انتشار پایدار M133 در اوایل فوریه فراهم می کند. افزونههای اضافی نیز از طریق همین فرآیند اجرا میشوند، بنابراین توصیه میکنیم برای بهروزرسانیها، گروه ایمیل blink-dev را دنبال کنید. |
ثبت نام و تاییدیه
هیچ بازخوردی در این سه ماهه دریافت نشد.
نمایش محتوا و تبلیغات مرتبط
موضوعات
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
مشخصات | آیا مدل طبقهبندیکننده بین Android (بر اساس نام برنامه) و کروم (بر اساس نام میزبان) مشترک است؟ | نه، آنها مدل های جداگانه ای هستند زیرا طبقه بندی های متفاوتی دارند. |
دانه بندی موضوعات تاکسونومی | موضوعات آنقدر عمومی هستند که وقتی با اطلاعات شخص اول استفاده می شوند، مفید نیستند. | تاکسونومی Topics به دنبال ایجاد تعادل بین مطلوبیت و حریم خصوصی است. در حالی که مکانیسمهای احتمالی را برای مشخصتر کردن موضوعات ارزیابی کردهایم، در نهایت به دلیل ملاحظات امنیتی و حفظ حریم خصوصی و سایر نگرانیها، تصمیم گرفتیم این کار را انجام ندهیم. فناوریهای تبلیغاتی میتوانند با ترکیب همه ابزارهای موجود، مانند یادگیری ماشینی و سیگنالهای ایمن حریم خصوصی از APIهای حفظ حریم خصوصی، همراه با دادههای متنی، دادههای خلاقانه و دادههای شخص اول، بهترین نتایج را باز کنند. راهنمایی بیشتر در این مورد در اینجا موجود است. |
استفاده از API | Topics API پوشش کمی دارد. | دلایل معمول برای پوشش کم عبارتند از: - کنترل های کاربر/انصراف - کنترل های ناشر/انصراف - واجد شرایط بودن سایت (سایتهای زیر برای مطابقت با موضوعات تأیید نشدهاند: سایتهای ناامن، WebView، Chrome در iOS، و حالت ناشناس) - محدودیتهای کاربر (کاربران Chrome زیر 18 سال یا افرادی که از حالت ناشناس استفاده میکنند، قابل مشاهده و اختصاص موضوعات نیستند) - شرط مشاهده فروشنده (تماس گیرنده باید قبلاً کاربر را در سایت مرتبط با موضوع واجد شرایط دیده باشد) - تازگی اجرا (به مدت 4 هفته اجازه می دهد تا برای مشاهده تماس گیرنده در مقیاس افزایش یابد) |
استفاده از API | به نظر میرسد درخواست اطلاعات در مورد استفاده از Topics API بهعنوان برگه Networking نشان میدهد که تماسی ارسال و ضبط شده است، اما chrome://topics-internals/ مشاهدهگر را ثبتشده نشان نمیدهد. | هنگام استفاده از مکانیسم هدر HTTP برای تعامل با Topics API، موضوعات در هدر درخواست Sec-Browsing-Topics ارسال میشوند، اما تنها در صورتی مشاهده میشوند که سرور با هدر پاسخ Observe-Browsing-Topics: ?1 پاسخ دهد. این در اینجا با جزئیات بیشتر بیان شده است. |
مشارکت کروم | برای دسکتاپ، آیا کروم با سایر مرورگرهای مبتنی بر Chromium همان مشاهدات و زمینه رتبهبندی را به اشتراک میگذارد؟ برای موبایل، آیا Android Chrome با سایر مرورگرهای Android مبتنی بر Chromium / In-App Chromium همان مشاهدات و زمینه های رتبه بندی را به اشتراک می گذارد؟ | Chrome دادههای موضوعات را با سایر مرورگرهای دستگاه به اشتراک نمیگذارد. |
مشخصات | Topics API چگونه تصمیم می گیرد که مشاهده صفحه توسط یک کاربر به عنوان "ورودی سابقه موضوع" در نظر گرفته شود؟ | برای واجد شرایط بودن برای محاسبه موضوعات هفتگی، بازدید از صفحه باید دارای تماس "مشاهده" باشد (می تواند از هر تماس گیرنده باشد). بدون تماس "مشاهده"، بازدید برای تاریخچه موضوع در نظر گرفته نمی شود. |
امنیت | چگونه API موضوعات مانع از دریافت موضوعات مشاهده شده توسط تماسگیرندگان دیگر میشود؟ | در اینجا توضیح داده ایم. |
طبقه بندی | چگونه طبقه بندی ساختار درختی در Topics API در مشاهده در هر دوره استفاده می شود؟ | هنگام محاسبه 5 موضوع برتر، فقط موضوعات اصلی ارائه شده توسط طبقه بندی کننده را در نظر می گیرد و رتبه بندی ها با (i) دفعات بازدید از صفحه و (ii) امتیاز اولویت بندی تعیین می شود (به مشخصات مراجعه کنید). هنگام محاسبه تعداد تماس گیرندگان مشاهده شده هر یک از 5 موضوع برتر، شامل تماس گیرندگانی می شود که موضوع اصلی یا هر یک از موضوعات بعدی را مشاهده کرده اند. |
مشخصات | درخواست اطلاعات بیشتر در مورد نویز تصادفی 5% در پاسخ. | همیشه 5 موضوع برتر برای هر دوره وجود دارد. اگر تاریخچه مرور 5 موضوع را ارائه نکرده باشد، آنگاه موضوعات به صورت تصادفی انتخاب می شوند تا زمانی که 5 موضوع وجود داشته باشد. تماسگیرندگان یکی از این موضوعات بهصورت تصادفی را دریافت نخواهند کرد، مگر اینکه کاربر را در سایتی با موضوع در چند هفته گذشته مشاهده کرده باشند (که API روشن است). هنگامی که API فراخوانی می شود، هش برای هر کاربر، هر سایت، در هر دوره محاسبه می شود. اگر آن هش کمتر از احتمال بازگرداندن یک موضوع نویزدار باشد، موضوع تصادفی برای هر کاربر، هر سایت، هر دوره برای بازگشت انتخاب میشود. با این حال، موضوع نویز شده تنها در صورتی برگردانده میشود (به عنوان مثال، فیلتر نشده است) در صورتی که تماسگیرنده موضوع بدون نویز مربوطه را برای آن کاربر/سایت/عصر مشاهده کرده باشد ( به توضیح مراجعه کنید). این فیلتر کردن تضمین می کند که موضوعات نویز شده بدون در نظر گرفتن قابلیت مشاهده، 5٪ از زمان برای تماس گیرنده معین بازگردانده می شوند. |
مشخصات | موضوعات تکراری cross week چگونه کار می کنند؟ آیا API به طور مستقل در بین هفته ها انتخاب می شود و سپس ادغام می شود؟ | موضوعات هر هفته (دوران) به طور مستقل محاسبه می شود. موضوع خاص انتخاب شده برای بازگرداندن از هر دوره به سایتی که تماس گیرنده در آن است بستگی دارد. ما این موضوع را در نظر نمی گیریم که ممکن است موضوع در دوره های مختلف برای یک تماس گیرنده خاص تکرار شود (و بنابراین باید موضوع دیگری را انتخاب کنیم) اما از بازخورد اضافی در مورد این موضوع در اینجا استقبال می کنیم. |
API مخاطبان محافظت شده
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
تست A/B | راهحل ذخیرهسازی مشترک که در اینجا توضیح داده شده است تأخیر را اضافه میکند و نرخ خرابی بالایی دارد (یعنی بخش قابلتوجهی از ترافیک بدون شناسه جمعیت به پایان میرسد). یک شناسه آنتروپی کم (به عنوان مثال، 3 بیت) می تواند برای آزمایش موثر A/B بدون تأثیر قابل توجهی بر حریم خصوصی کافی باشد. | ما بر این باوریم که راهحل ذخیرهسازی مشترک یک رویکرد قابل اجرا باقی میماند، اما در حال بررسی این درخواست هستیم و در صورتی که این ویژگی اولویت بالایی داشته باشد، از بازخورد اضافی اکوسیستم استقبال میکنیم . |
گزارش | درخواست برای بیتهای اضافی در reportWin() ، به ویژه از آنجایی که درک این است که گزارش کلیک و نمایش جدید در PA API از ۶ تا ۸ بیت استفاده میکند و به طور موثر بیتهای باقیمانده موجود برای گزارشهای دیگر PA API را کاهش میدهد. | ما دیگر به دلیل نگرانی های مربوط به حفظ حریم خصوصی، افزایش بیت های modelingSignals را بیش از 12 بیت فعلی در نظر نمی گیریم. ما از اکوسیستم دعوت می کنیم تا در مورد پیشنهاد آموزش مدل خصوصی ما بازخورد ارائه کند، که هدف آن پشتیبانی از نیازهای آموزشی ML در یک محیط امن بدون محدودیت اعمال شده توسط Privacy Sandbox در بیت ها است. |
گروه های علاقه مند | درخواست چرخه عمر 90 روزه برای گروه های علاقه (IG) به عنوان 30 روز کافی نیست. | همانطور که در پست وبلاگ خود ذکر کردیم، ما قصد داریم طول عمر IG را تا 90 روز افزایش دهیم و توضیحی در اینجا ایجاد کرده ایم. ما در حال حاضر روی پیادهسازی کار میکنیم و در صورت وجود، جدول زمانی راهاندازی را به اشتراک خواهیم گذاشت. |
گروه های علاقه مند | درخواست به روز رسانی پویا برای نمایندگی IG. | ما از این درخواست چندین ذینفع آگاه هستیم و در حال بررسی راه حل هستیم. ما بهروزرسانیهای GitHub را در حین توسعه به اشتراک خواهیم گذاشت و از بازخورد اضافی از اکوسیستم استقبال میکنیم. |
روی دستگاه | برای ادامه سرمایهگذاری در راهحلهای PA API روی دستگاه، ارزش بیشتری برای اکوسیستم نشان دهید. | تیم Privacy Sandbox به توسعه APIهای مبتنی بر فناوری افزایش حریم خصوصی (PET) از جمله PA API ادامه میدهد تا گزینههای حفظ حریم خصوصی بیشتری را در مرورگر به توسعهدهندگان ارائه دهد. این فناوریها عموماً در مرورگرهای کروم اکنون در مقیاس بزرگ در دسترس هستند (و نه فقط 1٪ همانطور که برخی از توسعه دهندگان اشتباه فهمیدهاند). چه کاربران 3PC را فعال کنند یا نه، توسعه دهندگان ممکن است راه حل های مبتنی بر PET را در محصولات خود بگنجانند، همانطور که بسیاری از شرکت ها تصمیم می گیرند راه حل های مبتنی بر PET را خارج از مرورگر اتخاذ کنند. برای بسیاری از توسعهدهندگان، آنها از سرمایهگذاری در راهحلهای PA API روی دستگاه با گسترش سیگنال مخاطبان شخص اول قطعی خود برای دسترسی بهتر به سایتها سود میبرند. ما میدانیم که برخی از توسعهدهندگان تنها در صورتی استفاده از APIهای Privacy Sandbox یا سایر راهحلهای مبتنی بر PET را انتخاب میکنند که تعداد بیشتری از 3PC غیرفعال باشند، و این توسعهدهندگان منتظر اطلاعاتی هستند که به آنها امکان میدهد حدس بزنند که چه تعداد مرورگر 3PC را حفظ میکنند. ما میدانیم که آن توسعهدهندگان برای تصمیمگیری درباره محصول، منتظر خواهند ماند تا اطلاعات مورد نظر خود را پیدا کنند. |
گروه های علاقه مند | به SSP ها اجازه دهید تا در ایجاد IG و نقش های مرتبط با آن ها نقش داشته باشند. SSP ها این را بخش مهمی از ارزش افزوده خود می دانند و مایلند توانایی کمک به ناشران را در فروش IG از طریق SSP های خود داشته باشند. | ما درخواست حمایت از هیئتهای IG پیشرفتهتر را از چند ذینفع دریافت کردهایم، و میبینیم که ارزش افزوده SSPها به این فرآیند کمک میکند. ما در حال تحقیق برای یافتن بهترین راه حلی هستیم که به احزاب مختلف اجازه می دهد در فرآیند افزایش مخاطب شرکت کنند. ما بهروزرسانیهای GitHub را در حین توسعه به اشتراک خواهیم گذاشت و از بازخورد اضافی از اکوسیستم استقبال میکنیم. |
گزارش | اختلاف در تعداد گزارشهای "مناقصه غیر صفر" بین forDebuggingOnly و Private Aggregation API. | ما انتظار داریم که به دو دلیل اختلاف وجود داشته باشد: اولاً، حالت اشکالزدایی API Aggregation Private تنها زمانی در دسترس است که 3 رایانه شخصی روی دستگاه مجاز باشد، در حالی که forDebuggingOnly API همیشه بدون نمونه در دسترس است (این رفتار آخر در نهایت همانطور که در اینجا توضیح داده شده است تغییر میکند). دوم، Private Aggregation API دارای محدودیت مشارکت است در حالی که forDebuggingOnly ندارد. با این حال، این بازخورد نشان میدهد که ممکن است چیز دیگری باعث اختلاف غیرمنتظره شود و ما در حال کار با یک ذینفع شخص ثالث برای حل این مشکل هستیم. |
کلیکی بودن | همانطور که در پیشنهاد به روز شده برای سیگنال کلیکی ذکر شد، بازدیدها و کلیکها با بازگرداندن یک سرصفحه پاسخ HTTP جدید به درخواستهایی که توسط ویژگی "attributionsrc" واجد شرایط هستند، ثبت میشوند، و این سرصفحه پاسخ شامل فهرستی از مبدا است که میتواند برای نشان دادن اینکه کدام طرفهای دیگر میتوانند این بازدیدها و کلیکها را در مبداهای فنی خود لحاظ کنند، ثبت میشوند؟ | در توضیح کلیکی بودن مشخص شده است که یک فناوری تبلیغاتی که یک بازدید یا رویداد کلیک را به نمای انبوه و تعداد کلیک ها کمک می کند (یک "منبع ارائه کننده") ممکن است شامل یک پارامتر اختیاری با سرصفحه پاسخ باشد که به آنها اجازه می دهد "یک یا چند مبدا مالک IG را که این رویداد ممکن است در نمای محاسبه شده گنجانده شود، در نمای محاسبه شده گنجانده شود generateBid() مزایده ها" ("منشاهای واجد شرایط").گفته می شود، این بازدیدها و کلیک ها به طور خودکار در تعداد نمایش ها و کلیک ها لحاظ نمی شوند. در عوض، هر فناوری تبلیغاتی باید در IGهای خود مجموعه ای از "منشاء ارائه" را مشخص کند که رویدادهای نمایش و کلیک از آن باید گنجانده شود، و فقط داده های این مبداهای ارائه دهنده به تعداد بازدیدها و کلیک های ارائه شده به فراخوان های generateBid() آن فناوری تبلیغات کمک می کند.این مکانیسم نیاز به توافق دو طرف دارد و مانع از تأثیرگذاری بازیکنان مخرب بر تعداد بازدیدها و کلیکها برای سایر adtechها میشود. این همچنین به این معنی است که یک فناوری تبلیغاتی «ارائهکننده» که «منشاهای واجد شرایط» را بهطور خودسرانه تنظیم میکند، تأثیری بر نمای آن منابع واجد شرایط و تعداد کلیکها نخواهد داشت، مگر اینکه آن مبداهای واجد شرایط صریحاً و عمداً مبدا ارائهدهنده را در IG خود لحاظ کنند. |
آموزش مدل خصوصی | مواردی وجود دارد که DP-SGD (حریم خصوصی دیفرانسیل - نزول گرادیان تصادفی) روند تمرین را به طور قابل توجهی کندتر می کند زیرا پراکندگی گرادیان های محاسبه شده در حین پشتیبان را از بین می برد. آیا تکنیک هایی برای هدایت این موضوع در نظر گرفته می شود یا افکاری در مورد این نگرانی وجود دارد؟ | ما از برخی تکنیک ها برای حفظ پراکندگی در DP-SGD آگاه هستیم (به عنوان مثال، این یکی )، و در حال بررسی حمایت از این نوع تکنیک ها در زیرساخت آموزش مدل خصوصی هستیم. ما بهروزرسانیها را در حین توسعه به اشتراک خواهیم گذاشت و از بازخورد اضافی در اینجا استقبال میکنیم. |
هدف گذاری منفی | درخواست برای بهروزرسانی در مورد عرضه عملکرد فیلتر منفی IG که در اینجا توضیح داده شده است. | همانطور که در پاسخ ما در اینجا ذکر شد، ما قصد داریم از IGهای منفی در پیشنهادات PA API پشتیبانی کنیم. زمانی که در دسترس باشد جدول زمانی راه اندازی را به اشتراک می گذاریم و از بازخورد اضافی در اینجا استقبال می کنیم. |
مناقصه | آیا امکان ترکیب چندین IG در هنگام مناقصه وجود دارد؟ | این در حال حاضر با PA API امکان پذیر نیست. PA API مبتنی بر طراحی است که IG به اطلاعاتی که یک سایت در مورد کاربر میداند مربوط میشود، که هسته اصلی بحث با اکوسیستم در کل بوده است. این رویکرد به فنآوران تبلیغات اجازه میدهد راهحلهای مختلفی ایجاد کنند که به تبلیغکنندگان کمک میکند تا مخاطبان ۱P خود را در سراسر وب گسترش دهند. ما می دانیم که پیشنهاد مایکروسافت Ads Selection API طراحی متفاوتی را پیشنهاد می کند که در آن مخاطبان بر اساس اطلاعات در سراسر سایت ها هستند. در حالی که ما به نظارت بر رویکرد آنها ادامه خواهیم داد، میخواهیم قبل از بررسی تغییرات مشابه در Chrome، بحثهای بیشتری را از اکوسیستم، از جمله جامعه حریم خصوصی ببینیم. |
تبلیغات بومی | نگرانیهایی در مورد اینکه آیا PA API میتواند به اندازه کافی قالبهای متنوع و الزامات رندر تبلیغات بومی را پشتیبانی کند یا خیر و اینکه آیا API PA انعطافپذیری خلاقانه و بهینهسازی مورد نیاز برای تبلیغات بومی مؤثر را میدهد یا خیر. | ما فعالانه در حال تحقیق برای ارائه پشتیبانی بیشتر برای تبلیغات بومی هستیم و از بازخورد اضافی از اکوسیستم استقبال می کنیم. |
گزارش | درخواست برای بهبود استحکام اسکریپتهای گزارشدهی که برای منابع با اسکریپتهای مناقصه رقابت میکنند و ممکن است زمانی که قاب حراج در حال اجرا از بین برود، از بین بروند. | امیدواریم به زودی پاسخی به GitHub ارسال کنیم، اما تصور نمیکنیم که این نگرانیها بهطور قابلتوجهی بر گزارشهای معتبر در عمل تأثیر بگذارد. |
جایگزینی ماکرو | پیکربندی مزایده جایگزینهای ماکرو را تصویب کرد که با برخی از پیکربندیهای 3P کار نمیکنند. | علت اصلی این بود که همه ترافیک های دارای برچسب حالت A/B این ویژگی را روشن نکرده بودند. اخیراً تصمیم گرفتهایم این (و سایر ویژگیها در شرایط مشابه) را در تمام ترافیکهای دارای برچسب حالت A/B روشن کنیم. ما پیشبینی میکنیم که این تغییر را در سه ماهه اول 2025 انجام دهیم. ما از بازخورد اضافی در اینجا استقبال می کنیم. |
مستندات | درخواست توضیح، زیرا به نظر میرسد در مستندات مربوط به واحد اندازهگیری مقدار تازگی در شی browserSignals در generateBid() وجود دارد. | ما در اینجا با جزئیات بیشتر به این موضوع پاسخ داده ایم و اسناد خود را بر این اساس به روز کرده ایم. پاسخ صحیح این است که واحد اندازه گیری میلی ثانیه است. |
گزارش | درخواست گزارش 3P؛ در حالی که DSP ها و SSP ها اعلان های نمایش را از کروم دریافت می کنند، ارائه دهندگان فنی لایه میانی به طور پیش فرض این کار را نمی کنند. | ما در حال حاضر در حال بحث درباره این درخواست ویژگی در اینجا هستیم و از بازخورد اضافی استقبال می کنیم. |
گروه های علاقه مند | درخواست راهنمایی در مورد نحوه حذف پویا InterestGroupBuyers هنگام استفاده از گردش کار حراج IG موازی. | ما در اینجا راهنمایی در این مورد ارائه کرده ایم. |
تبلیغات بومی | مزایدههای مستقل PA API برای بارگذاری صفحه معین، از فیلتر تبلیغات همان صفحه جلوگیری میکند. | پشتیبانی بیشتر از تبلیغات بومی، از جمله ویجتهای توصیهای که بهعنوان «بومی» شناخته میشوند و دارای تبلیغات متعدد در یک واحد هستند، یک حوزه تحقیقاتی فعال است و ما اذعان میکنیم که طراحی کنونی ممکن است از فیلتر کردن تبلیغات در همان صفحه پشتیبانی نکند، و سایر محافظتها مانند قابهای حصاردار نیز ممکن است از این امر جلوگیری کنند. |
تبلیغات بومی | ویژگیهای موجود PA API مانند اسکن خلاق، گزارشگیری، و غیره، که بر سیگنالهای مبتنی بر URL متکی هستند، ممکن است برای مدیریت اشیاء JSON مورد استفاده در خلاقیتهای تبلیغاتی بومی نیاز داشته باشند. | پشتیبانی بیشتر از Native Ads یک حوزه تحقیقاتی فعال است و ما در حال ارزیابی امکان انطباق API PA برای کمک به ارائه تبلیغات بومی هستیم. |
تأیید آگهی | ایمنی نام تجاری 3P در PA API به دلیل محدودیتهای تاخیر و حافظه پنهان perBuyerSignals تحت تأثیر قرار میگیرد که برای محتوای پویا مشکلساز است. | ما نیاز SSPها و DSPها را برای تعیین یک TTL بهینه برای حافظه پنهان میدانیم که اهداف شکلدهی ترافیک و حداکثر TTLهای ایمنی نام تجاری را متعادل میکند تا اطمینان حاصل شود که دادههای ذخیرهشده در حافظه پنهان برای ایمنی برند مرتبط باقی میمانند. ما در حال بررسی این موضوع هستیم و بهروزرسانیها را در حین توسعه به اشتراک میگذاریم. |
تأیید آگهی | جایگزینی کلان FullpageURL توسط SSPها برای انجام اندازهگیری ایمنی نام تجاری پس از مناقصه مورد نیاز است. | deprecatedReplaceInURN پیشنهاد فعلی برای SSP ها برای ارائه این سیگنال است. |
تأیید آگهی | عدم استانداردسازی در قالبهای کلان مورد استفاده توسط SSPها برای تأیید پس از مناقصه ممکن است به طور بالقوه باعث ناهماهنگی و خطا در پردازش و تجزیه و تحلیل دادهها شود. | SSPها و تأییدکنندگان آگهی باید مستقیماً برای تعریف دستورالعملها و مشخصات واضح برای استفاده کلان همکاری کنند تا استانداردسازی قالبهای ماکرو در سراسر SSPها تضمین شود و از خطاها در پردازش و تجزیه و تحلیل دادهها جلوگیری شود. این فعالیتی است که سازمان های استاندارد تبلیغات مانند IAB Tech Lab برای آن مناسب هستند. |
تأیید آگهی | تبلیغکنندگان و تأییدکنندگان آگهی به مکانیزمی نیاز دارند تا بررسیهای قبل از مناقصه و پس از مناقصه را برای یک زمینه ناشر برای اشکالزدایی و عیبیابی پیوند دهد. | یکی از گزینههای تأیید پس از پیشنهاد، از طریق سیگنالهای مبتنی بر مزایده و کمپین است که در گزارشهای سطح رویداد گنجانده شده است. این ممکن است پیوستن ها با گزارش های تصمیم گیری قبل از پیشنهاد را فعال کند. ما در حال بررسی الگوهای احتمالی برای دستیابی به این هستیم و بهروزرسانیها را در حین توسعه به اشتراک خواهیم گذاشت. |
تأیید آگهی | درخواست برای کاوش راهحلهای سرور با ارزش کلیدی مورد اعتماد (TKV) (متعلق به DSP و متعلق به تأییدکننده آگهی) برای پیشفرض و رسیدگی به محدودیتهای قابهای حصاردار برای پس از مناقصه. | ما در حال ارزیابی این درخواست هستیم و از بازخورد اضافی از اکوسیستم در اینجا استقبال می کنیم تا راه حلی پیدا کنیم که بتواند از ایمنی نام تجاری قبل از مناقصه پشتیبانی کند و الزامات هماهنگی بین طرفین را تسهیل کند. |
تبلیغات بومی | درخواست ممیزی رندر پس از مناقصه سمت فروش برای تبلیغات بومی. | پشتیبانی بیشتر از تبلیغات بومی یک حوزه تحقیقاتی فعال است و ما در حال بررسی تطبیق ویژگیهای موجود مانند این برای کمک به ارائه تبلیغات بومی هستیم. |
حراج محافظت شده (خدمات B&A)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
تأخیر | کاهش کافی برای تأخیر وجود ندارد. در حالی که خدمات B&A ممکن است این مشکل را در درازمدت کاهش دهد، Google به در دسترس بودن گسترده آن قبل از تغییرات در 3PC در Chrome متعهد نیست. | ما در چند فصل گذشته چندین بهبود در تأخیر روی دستگاه ایجاد کردهایم. ما همچنین در صورت لزوم در حال ساخت و مقیاس بندی خدمات B&A هستیم. ما اخیراً راهنمای بهترین شیوههای تأخیر خود را بهروزرسانی کردهایم که حاوی اطلاعات بیشتری در مورد نحوه استفاده از این ویژگیها است. ما همچنین به توسعه بهبودهای تأخیر جدید ادامه می دهیم که برخی از آنها را می توان در اینجا مشاهده کرد. |
(در فصل های گذشته نیز گزارش شده است) امنیت حراج | درخواست برای توضیح بیشتر در مورد روشهای جلوگیری/کاهش تلاشها برای دستکاری در مزایده روی دستگاه (به عنوان مثال از جمله اینکه آیا Google این را یک خطر مهم میداند). | پاسخ ما نسبت به فصل های گذشته بدون تغییر است: "مکانیسمهای گزارشدهی تبلیغات PA API، اطلاعاتی را که امروزه برای تشخیص انسانها از ترافیک رباتها استفاده میشود، حفظ میکند. علاوه بر این، تکنیکهای مبتنی بر دامنه فعلی شامل یا حذف دامنهها را میتوان در PA API استفاده کرد. این در پاسخ ما به گزارش IAB Tech Lab درباره Privacy Sandbox با جزئیات بیشتر توضیح داده شده است." |
راه حل های در محل | نگرانی در مورد اینکه چگونه بزرگترین تامین کنندگان ممکن است به دلیل عدم پشتیبانی از ابر خصوصی و نقشه راه طولانی و مبهم برای حمایت از آن، Privacy Sandbox یا B&A را اتخاذ نکنند. | ما متعهد به گسترش زیرساختهایی هستیم که سرویسهای جعبه ایمنی حریم خصوصی روی آنها اجرا میشوند. ما اخیراً پشتیبانی از ابر Azure را اعلام کردهایم و به تحقیقات خود در مورد راهحلهای احتمالی برای ارائه حفاظتهای حریم خصوصی و امنیتی مشابه برای ابرهای خصوصی ادامه میدهیم. از زمان ارتباط ما در ماه اکتبر، با ادامه تحقیق در مورد رویکردهای بالقوه برای ایمن کردن حریم خصوصی کاربران Chrome در یک محیط اجرای مورد اعتماد (TEE) پیشرفت کرده ایم. ما اکنون خود را در جایی در تحقیقات خود می یابیم که می خواهیم رویکردهای مختلف را با ذینفعان اکوسیستم تأیید کنیم و قصد داریم در Q1 جمع آوری ورودی ها را آغاز کنیم. بازخورد اکوسیستم و همکاری به اصلاح هر راه حل ممکن کمک خواهد کرد. |
تست کردن | آیا امکان ایجاد TEE برای آزمایش راه حل های گزارش PA API (Real Time Reporting و Private Aggregation) وجود دارد؟ | برای آزمایش سرویس تجمیع، فنآوران تبلیغات میتوانند از دادههای تست و ابزارهای تست محلی برای تولید گزارشهای خلاصه برای آزمایش عملکردی استفاده کنند. لطفاً به Local Testing Codelab در اینجا مراجعه کنید. برای آزمایش Aggregation در TEE، متخصصان تبلیغات باید فرآیند ثبت نام را همانطور که در پیش نیازهای Codelab در بالا ذکر شد، تکمیل کنند. ما از بازخورد اضافی در مورد این درخواست در اینجا استقبال می کنیم. |
معامله K/V یکپارچه سازی | درخواست توانایی استخراج اطلاعات مبتنی بر معامله از KV برای موارد استفاده تجاری. | ما در حال ارزیابی این درخواست ویژگی هستیم و به روز رسانی در GitHub ارائه خواهیم کرد. |
بدون برد اندازه گیری معامله | درخواست سیگنال یا توانایی درک اینکه چه زمانی یک SSP برنده نشد و چرا. | ما در حال ارزیابی این درخواست هستیم و به روز رسانی در GitHub ارائه خواهیم کرد. |
درخواست ویژگی | درخواست برای Privacy Sandbox برای ارائه ساختار فرهنگ لغت برای کمک به تطبیق گروهی از تبلیغات با مجموعه مربوطه از شناسه های معامله. | ما در حال ارزیابی این درخواست، همراه با روشهای دیگر برای کاهش اندازه IG با توجه به ذخیره شناسه معامله هستیم. ما یک به روز رسانی در GitHub ارائه خواهیم کرد. |
عملکرد | راهحلهایی برای اندازهگیری فرصتهای مزایده تبلیغاتی از دست رفته، احتمالاً به دلیل اندازه اسکریپت مناقصه. | ما در حال ارزیابی این درخواست هستیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
مشخصات | در حال حاضر B&A فقط فیلد prevWins را به جای آخرین فیلد prevWinMs که جایگزین prevWins در مشخصات شده است می خواند. | درست است که B&A مدت زمان را بر حسب میلی ثانیه در prevWins به generatebid() منتقل نمی کند. Chrome مدت زمان را بر حسب ثانیه ارسال میکند تا از سربار کمتری در بار بارگیری مطمئن شود، راه حل اینجا این است که B&A تبدیل را از ثانیه به میلیثانیه انجام دهد. B&A هم prevWins و هم prevWinsMs را در مرورگر Signals فراهم میکند تا با حراجهای روی دستگاه سازگار شود.توجه داشته باشید، حتی برای حراج های روی دستگاه برای وب، prevWins و prevWinsMs با یک مقدار و prevWinsMs = prevWins * 1000 مطابقت دارند. ما یک اصلاح را در اولویت قرار می دهیم. |
مستندات | مستندات در مورد نحوه آزمایش Seller Front End (SFE) روشن نیست، داشتن راهنمایی آزمایشی اضافی بلافاصله پس از تکمیل استقرار و همچنین نحوه استفاده از Bazel برای ساختها مفید خواهد بود. | این آزمایشگاه کد به عنوان یک راهنما منتشر شده است تا اکوسیستم گسترده تر را برای آزمایش SFE های خود آسان تر کند. |
استقرار | آیا برنامه ای برای ارائه باینری های از پیش ساخته شده برای B&A وجود دارد؟ | ما در حال بررسی ارائه باینری های از پیش ساخته شده برای B&A هستیم، اما جدول زمانی مشخصی برای این کار نداریم. تا آن زمان، متخصصان تبلیغات می توانند باینری ها را به تنهایی بسازند و با استفاده از هش های ارائه شده اعتبار سنجی کنند. |
استقرار | آیا همه انواع ارکستراسیون (سرور، مشتری، مختلط) باید پشتیبانی شوند یا یکی وجود دارد که باید نسبت به سایرین اولویت داشته باشد؟ | ما هیچ توصیه خاصی در مورد حالت هایی که فناوری تبلیغات اجرا می کند نداریم. انتخاب به عوامل مختلفی بستگی دارد، اما، در نهایت، به آنچه به نفع مشتریان شما است، بستگی دارد. |
تست کردن | به دنبال توضیح در مورد تست های ناموفق در طول ساخت B&A. | این می تواند نتیجه یک آزمایش پوسته پوسته باشد. ما به فناوری تبلیغات توصیه کردهایم که از پرچم --no-tests برای تمام دستورات ساخت build_and_test_all_in_docker استفاده کند تا از اجرای آزمایشها صرفنظر کند. |
سیاههها | به دنبال توضیح اینکه چرا log in log explorer در GCP به نمونه VM که SFE را در حالت آزمایشی اجرا می کند برچسب گذاری می شوند اما در حالت prod، گزارش ها به نمونه VM برچسب گذاری نمی شوند. | تعمیم آن دشوار است زیرا به آنچه دقیقاً دیده شده بستگی دارد اما به طور کلی: - گزارشهای non_prod احتمالاً گزارشهای stderr هستند که توسط ارائهدهنده ابر (در این مورد GCP) هدایت شدهاند و GCP تگ را اضافه کرده است. - گزارش های تولید شده توسط VM عموماً با نمونه VM برچسب گذاری می شوند، در حالی که گزارش های تولید شده توسط باینری توسط GCP برچسب گذاری نمی شوند. - گزارش های مربوط به prod توسط Open Telemetry در TEE صادر می شوند که دارای برچسب های مختلف هستند. در اینجا جزئیاتی از موارد موجود در non_prod و prod آمده است. |
B&A | خطای 403 در مورد از دست دادن اسرار زمانی که ثبت OTEL غیرفعال است. | اکنون از بهروزرسانی 4.1 این مشکل برطرف شده است و اسناد بر این اساس ویرایش شده است. |
B&A | فایل outputs.tf از دست رفته برای پیکربندی GCP terraform منجر به خطا می شود. | این در حال حاضر ثابت شده است. |
تست کردن | خطا هنگام واکشی کلید خصوصی در حالت تست. | در این موارد لطفاً مطمئن شوید که سرورها با TEST_MODE=true در حال اجرا هستند. توضیح دهنده را اینجا ببینید. |
نقشه راه | آیا برنامههایی برای getInterestGroupAdAuctionData وجود دارد که بیش از یک مبدا فروشنده را بپذیرد و نقشه مبدا فروشنده را به متن رمزی بارگذاری B&A بازگرداند؟ | بله، افزودن پشتیبانی برای اجازه دادن به navigator.getInterestGroupAdAuctionData() برای پذیرش چندین فروشنده برنامه ریزی شده است. |
مشخصات KV | آیا URL KV (trustedScoringSignalsURL) می تواند به صورت بالقوه به عنوان یک وعده ارائه شود؟ | توضیحات ارائه شده در اینجا را ببینید. |
B & A | درخواست ایجاد یک هدر پلتفرم جدید برای نشان دادن به طرف B&A به طرف فروشنده چه قابلیت هایی را برای مشتری (مرورگر) برای ایجاد حراج خصوصی نیاز دارد. | ما در حال حاضر در مورد این درخواست ویژگی در اینجا بحث می کنیم و از بازخورد اضافی استقبال می کنیم. |
شکل دهی ترافیک | پیشنهاد برای کاهش هزینه های افزایشی از میزبانی سرورهای B&A به ویژه برای DSP. | ما در حال حاضر در مورد این پیشنهاد در اینجا بحث می کنیم و از بازخورد اضافی استقبال می کنیم. |
-خود را بیاورید- با دودویی | به روزرسانی توضیح دهنده را در نظر بگیرید تا صریحاً به این موضوع بپردازید که از همه باینری ها پشتیبانی می شود. | این اکنون به روز شده است ، توضیح دهنده را در اینجا مشاهده کنید. |
KV تماس می گیرد | آیا generateBid() منتظر تمام تماس های فروشگاهی با ارزش کلیدی (kV) برای پایان دادن به آن است یا به طور مستقل اجرا می شود؟ چگونه دسته بندی KV بر زمان آن تأثیر می گذارد؟ | توضیحات ارائه شده در اینجا را ببینید. |
عملکرد | درخواست مستندات اضافی در مورد استفاده مجدد از اسکریپت های مناقصه و توصیه تنظیم هدرهای کنترل حافظه نهان بر روی اسکریپت ها. | مستندات در اینجا اضافه شده است. |
عملکرد | به منظور کاهش تأخیر در حراج در دستگاه ، درخواست بارگیری منابع (به عنوان مثال ، اسکریپت های مناقصه) را به صورت ناهمزمان در نظر بگیرید. | ما در حال حاضر در مورد این درخواست ویژگی در اینجا بحث می کنیم و از بازخورد اضافی استقبال می کنیم. |
ورود به سیستم رضایت | شفاف سازی مورد نیاز برای خطایی که هنگام تلاش برای استفاده از ورود رضایت نامه با تنظیم Consented_Debug_token مشاهده می شود. | در این موارد بررسی کنید که Consented_debug_token در مدیر مخفی وجود دارد ، Enable_otel_Based_Logging را روی تنظیم TRUE و TELEMETRY_CONFIG تنظیم کنید : Prod . توضیح دهنده را در اینجا مشاهده کنید که به منبع در اینجا اشاره دارد. |
سیاههها | آیا رویدادهای Fordebuggingonly از طریق B&A در دسترس هستند؟ | Fordebuggingonly برای B&A از آوریل 2024 برای حراج های فروشنده مجرد در دسترس بوده است. برنامه ما این است که خیلی زود آن را برای حراج های چندرسانه ای فعال کنیم. |
سیاهههای مربوط به کار | درخواست برای ورود به سیستم کار با Chromedriver. | ما در حال ارزیابی این درخواست هستیم و از بازخورد اضافی در اینجا استقبال می کنیم. |
اندازه گیری تبلیغات دیجیتال
گزارش انتساب (و سایر API ها)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
گزارش های اشکال زدایی | چگونه گزارش های اشکال زدایی ARA پس از رویکرد به روز شده به 3pcs در Chrome ، در اختیار فناوری های تبلیغاتی قرار می گیرد؟ آیا فناوری های تبلیغاتی هنوز هم باید به گزارش های اشکال زدایی ARA برای کاربرانی که 3PC را حفظ می کنند دسترسی داشته باشند و API های Sandbox را فعال کنند؟ | Techs AD در رابطه با کاربران با هر دو 3PCS و ARA به راه حل های اشکال زدایی مبتنی بر کوکی و CookieLess دسترسی خواهند داشت. هنگامی که کوکی ها خاموش هستند ، آنها فقط به راه حل اشکال زدایی کل دسترسی خواهند داشت. جزئیات بیشتر در مورد راه حل های اشکال زدایی در اینجا و اینجا موجود است. |
تشخیص ویژگی | درخواست راهنمایی در مورد نحوه انجام ویژگی های تشخیص برای ARA در سمت سرور. | در حال حاضر پشتیبانی از ویژگی ARA را می توان بر اساس استفاده از نسخه Chrome که در رشته عامل کاربر مشاهده می شود ، شناسایی کرد. ما از بازخورد اکوسیستم اضافی در این باره استقبال می کنیم. |
درخواست ویژگی | درخواست Source_Registration_Time که در ARA جمع شده are_info استفاده می شود ، به عنوان مثال به یک ساعت یا یک دقیقه (بر خلاف یک روز) و همچنین قابل تنظیم است تا منطقه زمانی را در نظر بگیرید (در حال حاضر فقط UTC). | گرد کردن قسمت Source_Registration_Time به نزدیکترین روز ، مکانیسم حفظ حریم خصوصی است که برای کاهش توانایی یک فناوری تبلیغاتی استفاده می شود تا بتواند یک کاربر خاص را به یک منبع خاص پیوند دهد. در حال حاضر Source_Registration_Time مبتنی بر UTC است و یک فناوری تبلیغاتی می تواند گزارش های تبلیغاتی خود را تنظیم کند تا این امر را به حساب آورد. ما از بازخورد اکوسیستم اضافی در مورد این درخواست در اینجا استقبال می کنیم. |
مشخصات | درخواست برای روشن شدن مشخصات "trigger_data" و "اولویت" به ویژه هنگامی که از آنها با مقدار آرایه استفاده می شود. | این زمینه ها مقادیر آرایه را نمی پذیرند. براکت های مربع در توضیح دهنده یک آرایه را نشان نمی دهند ، بلکه نشان می دهد که متن یک ارزش نمونه نیست ، بلکه یک مکان نگهدارنده با توضیحات است. همانطور که متن موجود در براکت های مربع نشان می دهد: - trigger_data یک INT-64 است - اولویت یک INT-64 امضا شده است هیچ یک از زمینه ها مقادیر آرایه را نمی پذیرند. همچنین ارزش استفاده از ابزار اعتبار سنجی هدر را برای ARA برای آزمایش با مقادیر مختلف و در صورت گیج کردن مستندات در نظر گرفته شده است. |
پشتیبانی از تبلیغات صفحات موبایل (AMP) | آیا ARA از تبلیغات آمپ پشتیبانی می کند؟ | پیشنهاد ما در مورد چگونگی پشتیبانی از AMP در اینجا موجود است و از بازخورد اضافی استقبال می کنیم. |
مشخصات | کدام URL به عنوان "سایت منبع" برای تبلیغات تعبیه شده چند لایه برای ARA در نظر گرفته می شود؟ | URL از سایت سطح بالا. |
(همچنین در سه ماهه قبلی گزارش شده است) درخواست ویژگی | درخواست حداقل مقدار Event_Report_Window از 3600 ثانیه (1 ساعت) به 1800 ثانیه (30 دقیقه) کاهش یابد. | تعیین حداقل پنجره گزارش ، نیاز به تعادل ملاحظات ابزار و حفظ حریم خصوصی دارد. حداقل پنجره گزارش 1 ساعت برای گزارش های سطح رویداد برای حفظ حریم خصوصی و کاهش در برابر انواع خاصی از حملات بازسازی تاریخ ضروری است. ما در اینجا از بازخورد اضافی در مورد این درخواست استقبال می کنیم. |
سر و صدا | به دنبال درک عمیق تر از نحوه اجرای سر و صدا در گزارش های سطح رویداد ARA برای اطمینان از تفسیر دقیق و استفاده از داده ها. | جزئیات بیشتر در اینجا و اینجا موجود است. |
گزارش | گزارش های جمع شده به اشتراک گذاشته شده_ینفو دیگر حاوی source_registration_time به طور پیش فرض نیست. | این به دلیل تغییرات API است و در اینجا با جزئیات بیشتر بیان شده است. |
گزارش | filtering_id از برگه "گزارش های قابل جمع" از Chrome: // Attribution-Internals/UI غایب است. | filtering_id در حال حاضر در جزئیات برگه "Trigger Registrations" هنگام کلیک بر روی یک ردیف قابل مشاهده است ، که به شما امکان می دهد اعتبار آن را تأیید کنید. ما ابزار نمایش آن را در برگه "گزارش های قابل جمع" می شناسیم و به این موضوع پرداخته ایم. |
منبع | درخواست توضیح در مورد نحوه عملکرد منبع انتساب. | توضیحی در اینجا موجود است. |
برنامه به انتساب وب | درخواست راهنمایی برای پیاده سازی هایی که در آن عدم اطمینان وجود دارد که آیا منابع OS یا وب خواهند بود. | راهنمایی در اینجا موجود است. |
سرویس تجمع
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
درخواست ویژگی | درخواست یک زمان بندی قابل تنظیم برای AGS و/یا دید بیشتر در مورد وضعیت کار برای اجرای طولانی مدت. | ما در حال بررسی ویژگی هایی برای پشتیبانی از نظارت بر مشاغل طولانی مدت هستیم. ما از بازخورد اکوسیستم اضافی در این باره استقبال می کنیم. |
Terraform | Terraform سعی در تغییر خط مشی IAM حتی اگر Service_Account_Token_Creator_List تنظیم نشده باشد. | توسعه دهندگان می توانند مجوزهای اضافه شده خود را در پرونده محلی/adtech_setup/main.tf اضافه کنند. |
درخواست مستندات | درخواست مستندات یا CodeLab در مورد نحوه نظارت بر سلامت خدمات جمع آوری. | شرح هشدارهای موجود که می تواند برای نظارت بر خدمات و سلامت شغلی مورد استفاده قرار گیرد ، می توانید در پرونده های مربوط به اپراتور Terraform ( Alarms.TF و Monitor.TF ) در مخزن هماهنگ کننده خدمات و ---lribribaries مشاهده کنید. ما اسناد و راهنمایی های اضافی را در مورد نحوه نظارت بر مشاغل خدمات جمع آوری منتشر خواهیم کرد. |
مقیاس بندی | چگونه می توان مسائل مقیاس گذاری را کنترل کرد؟ | ما یک نسخه به روز شده از این راهنمایی را منتشر کردیم که مقیاس بالاتر سرویس جمع آوری را مستند می کند. در حال حاضر هیچ سیگنال مستقیمی وجود ندارد که نشانگر عدم موفقیت باشد زیرا دستگاه نمی تواند از مقیاس کار پشتیبانی کند. سیگنال های غیرمستقیم عبارتند از: 90 ٪ مصرف حافظه قبل از خرابی ، شغلی که به طور مکرر از بین می رود. ما از بازخورد اکوسیستم اضافی در مورد نیاز به چنین سیگنالی استقبال می کنیم. |
مشخصات | زمان اجرا معمولی از گروههای گزارش AGS چقدر است؟ | لطفاً به راهنمایی در اینجا مراجعه کنید. |
API تجمع خصوصی
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
درخواست ویژگی | درخواست برای کمک به مقادیر شناور (از جمله موارد منفی) به مشارکت در مورد حساسیت با حساسیت 2^16 | ما در حال حاضر در مورد این پیشنهاد در اینجا بحث می کنیم و از بازخورد اضافی استقبال می کنیم. |
ردیابی پنهانی را محدود کنید
کاهش نماینده کاربر/نکات مشتری عامل کاربر
هیچ بازخوردی در این سه ماه دریافت نکرد.
محافظت از IP (قبلاً Gnatcatcher)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
موقعیت جغرافیایی | درخواست پرونده جغرافیایی محافظت از IP. | نقشه برداری فایل IP به مکان های خشن برای محافظت از IP در اینجا موجود است. لطفاً توجه داشته باشید که این پرونده به صورت دوره ای به روز می شود. |
کاهش ردیابی گزاف گویی
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
لیست مجاز | موقعیت به روز شده دیگر به لیست مجاز یا مکانیسم های مشابهی که مستقل از فرآیند تصمیم گیری Google باشد ، نمی پردازد. | Google قصد ندارد لیست های مجاز مربوط به کاهش ردیابی Bounce (BTM) را داشته باشد. محافظت ها به طور یکنواخت در همه حوزه ها اعمال می شود. |
انطباق | ICO باید در زمینه انطباق مربوط به حریم خصوصی اقتدار داشته باشد. | وضعیت انطباق هیچ ارتباطی با کاربرد BTM ندارد و Google هیچ تصمیمی در مورد انطباق در اجرای BTM اتخاذ نمی کند. |
رقابت | به نظر می رسد که ممکن است Google اجازه داده شود رقبا PET را با استفاده از BTM (یا اقدامات دیگر) سلب کند و سپس از اختیار آن استفاده کند که آیا اجازه می دهد آنها را به بازار برگردانند. فرایند تجدید نظر فعلی ممکن است به طور موقت رقبای PET را از استفاده از BTM یا اقدامات مشابه سلب کند. | پیشنهاد فعلی BTM با هدف ردیابی گزاف گویی به عنوان یک تکنیک انجام شده است. در حالی که Google قصد دارد از شکستن موارد استفاده خاصی که ممکن است تکنیک های مشابهی را درگیر کند ، جلوگیری کند ، هیچ برنامه ای برای Google برای ارائه معافیت های فردی از BTM وجود ندارد. بنابراین سؤال از Google اعمال اختیار بر حضور رقبا ایجاد نمی شود. |
مرزهای حفظ حریم خصوصی سایت را تقویت کنید
مجموعه های وب سایت مرتبط (مجموعه های شخص اول)
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
(همچنین در سه ماهه قبلی گزارش شده است) محدوده دامنه مجموعه وب سایت (RWS) | حد فعلی پنج حوزه همراه به اندازه کافی بالا برای دستیابی به موارد استفاده از اندازه گیری در سایت نیست. | پاسخ ما شبیه به محله های قبلی است: در حال حاضر ، ما انتظار نداریم حد عددی را افزایش دهیم. این حد بر اساس ملاحظات حریم خصوصی کاربر ، بازخورد ذینفعان اکوسیستم در W3C و در نظر گرفتن پیاده سازی های قابل مقایسه برقرار شد در مرورگرهای دیگر. برای کسب اطلاعات بیشتر ، لطفاً به پست های وبلاگ ما مراجعه کنید ( 1 ، 2 ). توصیه می کنیم موارد استفاده را که نیاز به دسترسی به کوکی های متقابل در سایت فراتر از حد عددی دارند ، بررسی کنید و از راهنمایی های ما برای استفاده از هویت ، تعبیه های معتبر و موارد استفاده تبلیغاتی استفاده کنید. ما در اینجا از بازخورد اضافی در مورد این موضوع استقبال می کنیم. |
قاب های حصارکشی API
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
تبلیغات بومی | ارائه تبلیغات بومی در فریم های حصارکشی چالش هایی را ایجاد می کند زیرا ارث بندی یک ظاهر طراحی ناشر به دلیل محدودیت در ارتباط بین Iframe و صفحه ناشر محدود است. | پشتیبانی بیشتر از تبلیغات بومی ، از جمله پشتیبانی از اجرای قاب های حصارکشی ، یک منطقه فعال از تحقیقات است. ما در اینجا از بازخورد اضافی در مورد این موضوع استقبال می کنیم. |
API ذخیره سازی مشترک
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
استفاده از API | هنگامی که سایر API های Sandbox Privace کاربردی هستند ، API ذخیره سازی مشترک در برخی از دستگاه ها در دسترس نیست. | این رفتار برای زیر مجموعه کوچکی از کاربران (تقریباً 1 ٪) که بخشی از آزمایش نگهدارنده ذخیره سازی مشترک هستند ، پیش بینی می شود. این مجموعه آزمایشی برای ارزیابی عملکرد و پذیرش API ها در سناریوهای متنوع استفاده می شود. |
استفاده از API | آیا می نویسد برای ذخیره سازی مشترک تحت عنوان ناشر یا منشأ اسکریپت مناقصه رخ می دهد؟ آزمایش اولیه هیچ نوشتن را نشان نداد که منشأ ناشر با منشأ فیلمنامه متفاوت باشد. | این مسئله برطرف شده است و فقط در صورت وجود اشکال احتمالی Devtools باز است. جزئیات بیشتر در اینجا موجود است. ذخیره سازی مشترک در زمینه مناقصه تماس generateBid به منشأ خریدار می نویسد. نوشتن به منشأ ناشر گره خورده نیست ، حتی اگر صفحه ناشر در دامنه دیگری ساکن باشد. |
استفاده از API | حفاظت های موجود برای بازیگر بد قادر به خواندن گزارش های ذخیره سازی مشترک چیست؟ | ذخیره سازی مشترک با فراخوانی Origin تقسیم می شود ، بنابراین یک بازیگر بد یا AD Tech نمی تواند داده های ذخیره سازی مشترک را از یک فناوری تبلیغی دیگر بخواند. گزارش های جمع آوری خصوصی مستقیماً از طریق TLS به همان منشاء ارسال می شوند تا آنها را رهگیری کنند. |
چیپس
موضوع بازخورد | خلاصه | پاسخ کروم |
---|---|---|
کوکی های تقسیم شده | برخورداری از کوکی ها در درگاه های مختلف محلی در Chrome و Firefox وجود دارد ، به خصوص هنگام استفاده از ویژگی تقسیم شده. | Firefox LocalHost را با درگاه های مختلف به عنوان کلیدهای پارتیشن مجزا رفتار می کند. در حالی که این رفتار با اصول امنیتی هماهنگ است. این از مشخصات و رویکرد Chrome منحرف می شود. ما انتظار داریم که این موضوع را با سایر مرورگرها در بحث مشخصات HTML در مورد این موضوع بحث کنیم و در صورت ایجاد این امر منجر به تغییر در کلید پارتیشن تراشه ها ، به اکوسیستم اطلاع خواهیم داد. ما در اینجا از بازخورد اضافی در مورد این موضوع استقبال می کنیم. |
کوکی های تقسیم شده | پیش نویس داده های روشن به طور نادرست اجازه می دهد تا فراتر از پارتیشن سایت انتشار ، پاکسازی با بحث های قبلی که در اینجا ذکر شده است ، پاکسازی شود. | این یک اشکال در سند مشخصات استاندارد است ، که ما قصد داریم به زودی آن را برطرف کنیم. رفتار صحیح در این بخش از توضیحات مشخص شده است و با رفتار هماهنگ با سایر مرورگرهای موجود در مخزن توضیحات بخش ذخیره سازی هماهنگ است. اجرای Chrome قبلاً به درستی عمل می کند. |
فدستان
هیچ بازخوردی در این سه ماه دریافت نکرد.
با هرزنامه و کلاهبرداری مبارزه کنید
API Token State Private (و سایر API)
هیچ بازخوردی در این سه ماه دریافت نکرد.