درباره ویژگی های حراج API مخاطب محافظت شده بیشتر بیاموزید.
همانطور که ویژگی های Protected Audience API را به در دسترس بودن عمومی منتقل می کنیم، ممکن است در مورد در دسترس بودن خدمات و ویژگی های Protected Audience API تعجب کنید. در اینجا فهرستی از ویژگی‌های API مخاطب محافظت شده با محدوده و زمان پشتیبانی از آنها را می‌بینید.
جدول زمانی در دسترس بودن ویژگی
| ویژگی | برای تست موجود است | وضعیت |
|---|---|---|
| گزارش برنده حراج در سطح رویداد | در حال حاضر | حداقل تا سال 2026 پشتیبانی می شود. این ویژگی در نظر گرفته شده است تا انتقال به گزارش‌های API مخاطبان محافظت شده از گزارش کوکی شخص ثالث را آسان‌تر کند. بنابراین، پس از اینکه فناوری‌های تبلیغاتی زمان لازم برای به‌روزرسانی مکانیسم‌های گزارش‌دهی خود را داشتند، از این گزارش پشتیبانی نمی‌شود. |
| تجمع مبتنی بر ماشه | در حال حاضر | برای آزمایش در Chrome Canary/Dev M113+ و Beta/Stable M115+ موجود است. |
| استفاده از محیط اجرای معتمد (TEE) برای سرویس کلید/ارزش | در حال حاضر | زودتر از سه ماهه سوم 2025 لازم نیست. |
| قاب های نرده دار | در حال حاضر | زودتر از 2026 لازم نیست. |
| API مخاطب محافظت شده + ادغام گزارش Attribution بهبود یافته است | 2023 Q2 | برای آزمایش در Chrome Stable M112+ موجود است. |
| K-ناشناس بودن | در حال حاضر | مقاله k-anonymity را ببینید |
| خدمات مناقصه و مزایده | برای آزمایش در H2 2023 هدف گذاری شده است. | در حال توسعه. |
ویژگی های اضافی
| ویژگی | برای تست موجود است | وضعیت |
|---|---|---|
| سیگنال‌های پیشنهاد کاربر در سطح رویداد برای مدل‌سازی ( مساله Github ) | 2023 | در سه ماهه دوم 2023 در کروم موجود است. |
| گزارش تاخیر به ازای هر خریدار | 2023 | در سه ماهه اول 2023 در کروم موجود است. |
| مهلت زمانی دیوار برای هر خریدار | 2023 | در سه ماهه اول 2023 در کروم موجود است. |
| شناسه گزارش خریدار برای خرابی‌های سفارشی | 2023 | در سه ماهه سوم 2023 در کروم موجود است. |
| پشتیبانی مقصد فروشنده مستقیم | 2023 | در سه ماهه اول 2023 در کروم موجود است. |
| هزینه تبلیغات محدود با دقت برای صورت‌حساب هزینه هر کلیک | 2023 | در سه ماهه دوم 2023 در کروم موجود است. |
| ارز برای بالاترین پیشنهاد و بالاترین پیشنهاد امتیازدهی دیگر | 2023 | در سه ماهه سوم 2023 در کروم موجود است. |
| پشتیبانی ماکرو برای ردیاب های تبلیغاتی شخص ثالث (3PAT) | 2023 | در سه ماهه سوم 2023 در کروم موجود است. |
| پشتیبانی از هدف گذاری گروهی با علاقه منفی | بعداً در سال 2023 | در کروم در Q4 2023 مورد انتظار است. |
| انتشار ایمن سیگنال های حراج بدون WebBundle مسئله Github | بعداً در سال 2023 | در کروم در Q4 2023 مورد انتظار است |
| حذف گروه بهره انبوه مسئله Github | بعداً در سال 2023 | در کروم در Q4 2023 مورد انتظار است |
| سقف گروه بهره را از 1 هزار به 2 هزار افزایش دهید مسئله Github | بعداً در سال 2023 | در کروم در Q4 2023 مورد انتظار است |
| پشتیبانی از Bidding و Auction Beta 1 توضیح دهنده | Origin Trial، بعداً در سال 2023 | در کروم (از طریق Origin Trial) در Q4 2023 مورد انتظار است |
| API مانیتورینگ زمان واقعی توضیح دهنده | اواخر سه ماهه دوم یا اوایل سه ماهه سوم 2024 | در کروم در اواخر سه ماهه دوم یا اوایل سه ماهه سوم 2024 انتظار می رود همچنین در حال بررسی بهبودهایی هستیم که در توضیح دهنده در کار آینده به اشتراک گذاشته شده است. ما قصد داریم تا سه ماهه اول سال 2025 جهت را تأیید کنیم و انتظار داریم تا سه ماهه اول 2026 راه حل تجدید نظر شده ای را ارائه دهیم، مشروط به زمان بندی راه اندازی فناوری های اساسی. |
گزارش برنده حراج در سطح رویداد
ما در ابتدا اشاره کردیم که گزارش برنده حراج در سطح رویداد یک راه حل موقت خواهد بود و از API جمع آوری خصوصی برای تولید گزارش های خلاصه استفاده می شود. پس از گوش دادن به بازخورد و بررسی پیچیدگی نسبی راه‌حل‌های مبتنی بر تجمیع، به‌ویژه برای صدور صورت‌حساب، تصمیم گرفتیم پشتیبانی از گزارش نتایج برنده حراج در سطح رویداد را با توابع reportResult() و reportWin() که قابلیت فراخوانی sendReportTo() را دارند حذف نکنیم. sendReportTo() .
گزارش برنده حراج در سطح رویداد حداقل تا سال 2026 پشتیبانی می‌شود و قبل از انتقال API به هر راه‌حل جایگزین، اطلاعیه‌ای پیشرفته ارائه می‌کنیم.
گزارش ضرر حراج همچنان از طریق Private Aggregation API پشتیبانی می شود.
گزارش انبوه مبتنی بر محرک
در طول حراج مخاطب محافظت‌شده، می‌توانید یک گزارش جمع‌آوری‌شده را هنگامی که توسط یک رویداد راه‌اندازی می‌شود، با استفاده از روش contributeToHistogramOnEvent() API Aggregation خصوصی ارسال کنید. رویداد آغازگر می تواند از خود حراج باشد، مانند برد یا باخت حراج. پس از آن، چنین گزارش‌های انبوهی به یک سرویس جمع‌آوری مستقر ارسال می‌شوند، که به شما امکان می‌دهد یک گزارش خلاصه نهایی که شامل نتایج ضرر حراج است، ایجاد کنید. این رویداد همچنین می‌تواند از یک قاب حصاردار خارج از حراج با استفاده از APIهای گزارش‌دهی تبلیغات قاب حصاردار (Fenced Frame Ads Reporting API window.fenced.reportEvent() باشد.
برای کسب اطلاعات بیشتر به بخش contributeToHistogramOnEvent() صفحه Private Aggregation مراجعه کنید.
استفاده از محیط اجرای مورد اعتماد برای سرویس کلید/ارزش
سرویس کلید/ارزش API مخاطب محافظت شده به حراج اجازه می‌دهد سیگنال‌های بی‌درنگ را زمانی که پیشنهاد توسط خریدار تولید می‌شود و آگهی توسط فروشنده امتیاز می‌گیرد، بازیابی کند. سرویس Key/Value در نهایت باید در یک محیط اجرای قابل اعتماد (TEE) اجرا شود تا اطمینان حاصل شود که داده‌های کاربر خصوصی نگه داشته می‌شوند.
اجرای سرویس کلید/مقدار در TEE مورد نیاز نیست. ما حداقل 12 ماه قبل از اجباری شدن استفاده از TEE اطلاع رسانی خواهیم کرد. تا آن زمان، می‌توانید به استفاده از سرور خود برای سیگنال‌های کلید/مقدار بی‌درنگ ادامه دهید. توجه داشته باشید که اجرای سرویس Key/Value در یک TEE با توابع تعریف شده توسط کاربر (UDF) تا پایان سه ماهه اول سال 2023 با API مخاطب محافظت شده روی دستگاه برای آزمایش در دسترس خواهد بود.
قاب های نرده دار
فریم های حصاردار یک عنصر جدید HTML هستند که ارتباط بین محتوا و جاسازی را محدود می کند و برای ارائه محتوا بر اساس داده های بین سایتی استفاده می شود. Protected Audience API محتوا را به یک قاب حصاردار تبدیل می کند.
پس از همکاری نزدیک با سهامداران مختلف و بررسی تلاش‌های قابل توجه برای سازگاری با این تغییر، Chrome قاب‌های حصاردار را حداقل تا سال 2026 برای حفظ فراگیر بودن اکوسیستم اجباری نمی‌کند و Chrome اطلاعیه‌های پیشرفته قابل توجهی را ارائه خواهد کرد. تا آن زمان، اگر از قاب‌های حصاردار استفاده نمی‌شود، باید از یک iframe برای رندر کردن URN مات استفاده کنید. همچنین، لازم به ذکر است که فروشندگان همچنان می توانند از قاب های حصاردار استفاده کنند.
| پیشنهاد | وضعیت |
|---|---|
| Web API برای urn به پیکربندی تغییر می کند توضیح دهنده | در سه ماهه اول 2023 در کروم موجود است. |
| ماکروهای خلاقانه در قاب های حصاردار برای گزارش تبلیغات (FFAR) مشکل GitHub | در سه ماهه سوم 2023 در کروم موجود است. |
| یک بار چراغ های خودکار ارسال کنید مشکل GitHub | در سه ماهه سوم 2023 در کروم موجود است. |
| پیکربندی قاب های حصاردار قابل سریال مشکل GitHub | در سه ماهه سوم 2023 در کروم موجود است. |
| گزینه قالب اضافی برای ماکروهای اندازه تبلیغ مخاطب محافظت شده مشکل GitHub | در کروم در Q4 2023 موجود است. |
| ارسال خودکار چراغ ها به همه URL های ثبت شده مشکل GitHub | مشکل GitHub | در کروم در Q4 2023 موجود است. |
| خروج از گروه‌های مورد علاقه آگهی از Urn iFrames و Ad Component Frames را فعال کنید مشکل GitHub | در سه ماهه اول 2024 در کروم موجود است |
| Reserved.top_navigation_start/commit را معرفی کنید مشکل GitHub ، مشکل GitHub | در سه ماهه اول 2024 در کروم موجود است |
| تنظیمات کوکی را در ReportEvent تا 3PCD غیرفعال نکنید مشکل GitHub | در سه ماهه اول 2024 در کروم موجود است |
| پشتیبانی از چراغ های خودکار را در زیرفریم های متقاطع اضافه کنید مشکل GitHub | در سه ماهه اول 2024 در کروم موجود است |
به زیرفریم های Cross-Origin اجازه دهید که Beacon های reportEvent() ارسال کنندمشکل GitHub | در سه ماهه دوم 2024 در کروم موجود است |
API مخاطب محافظت شده و ادغام Attribution Reporting بهبود یافته است
اخیراً، چالش‌هایی در مورد ادغام API گزارش انتساب و API مخاطب محافظت شده، به ویژه در مواردی که قاب‌های حصاردار درگیر هستند، اشاره شده است .
برای گزارش‌دهی در سطح رویداد با API مخاطبان محافظت‌شده، مجموعه‌ای از پیشرفت‌های اولیه پیشنهادی برای آسان‌تر کردن این یکپارچه‌سازی داریم که می‌توانید در توضیح بیشتر درباره آن بیاموزید. ادغام برای هر دو قاب حصاردار و iFrames در دسترس خواهد بود. گزارش‌دهی در سطح رویداد برای آزمایش در Chrome Stable M112+ در دسترس خواهد بود.
برای کسانی که به گزارش انتساب با API مخاطبان محافظت شده نیاز دارند، ما در حال کار بر روی راه حل های انعطاف پذیرتری هستیم تا سیگنال های پیشنهادی بیشتری را با گزارش های انباشته دریافت کنیم، و پس از آماده شدن پیشنهاد، آن را منتشر خواهیم کرد.
خدمات مناقصه و مزایده
ما نگرانی‌هایی در مورد تأخیر API مخاطب محافظت‌شده شنیده‌ایم و فعالانه در حال کار روی بهبود تأخیر در دستگاه هستیم. هم Chrome و هم Android قصد دارند خدمات مناقصه و مزایده را به عنوان راه دیگری برای اجرای منطق مناقصه و امتیازدهی در کنار مزایده‌های داخل دستگاه ارائه کنند. خدمات مناقصه و مزایده یک راه حل سرویس API مخاطبان محافظت شده برای اجرای حراج ها خارج از دستگاه است که ما معتقدیم عملکرد سریع تری را ممکن می کند.
ما به حمایت از مزایده های روی دستگاه ادامه خواهیم داد و استفاده از خدمات مناقصه و مزایده الزامی نیست مگر اینکه با موارد استفاده شما مطابقت داشته باشد.
جزئیات بیشتر را می توانید در پست وبلاگ پیدا کنید.
بعدش چی؟
ما می‌خواهیم با شما گفتگو کنیم تا اطمینان حاصل کنیم که یک API درست می‌کنیم که برای همه کار کند.
در مورد API بحث کنید
مانند سایر APIهای Privacy Sandbox، این API مستند شده و به صورت عمومی مورد بحث قرار گرفته است.
با API آزمایش کنید
می‌توانید آزمایش کنید و در گفتگو درباره API مخاطبان محافظت شده شرکت کنید .
،درباره ویژگی های حراج API مخاطب محافظت شده بیشتر بیاموزید.
همانطور که ویژگی های Protected Audience API را به در دسترس بودن عمومی منتقل می کنیم، ممکن است در مورد در دسترس بودن خدمات و ویژگی های Protected Audience API تعجب کنید. در اینجا فهرستی از ویژگی‌های API مخاطب محافظت شده با محدوده و زمان پشتیبانی از آنها را می‌بینید.
جدول زمانی در دسترس بودن ویژگی
| ویژگی | برای تست موجود است | وضعیت |
|---|---|---|
| گزارش برنده حراج در سطح رویداد | در حال حاضر | حداقل تا سال 2026 پشتیبانی می شود. این ویژگی در نظر گرفته شده است تا انتقال به گزارش‌های API مخاطبان محافظت شده از گزارش کوکی شخص ثالث را آسان‌تر کند. بنابراین، پس از اینکه فناوری‌های تبلیغاتی زمان لازم برای به‌روزرسانی مکانیسم‌های گزارش‌دهی خود را داشتند، از این گزارش پشتیبانی نمی‌شود. |
| تجمع مبتنی بر ماشه | در حال حاضر | برای آزمایش در Chrome Canary/Dev M113+ و Beta/Stable M115+ موجود است. |
| استفاده از محیط اجرای معتمد (TEE) برای سرویس کلید/ارزش | در حال حاضر | زودتر از سه ماهه سوم 2025 لازم نیست. |
| قاب های نرده دار | در حال حاضر | زودتر از 2026 لازم نیست. |
| API مخاطب محافظت شده + ادغام گزارش Attribution بهبود یافته است | 2023 Q2 | برای آزمایش در Chrome Stable M112+ موجود است. |
| K-ناشناس بودن | در حال حاضر | مقاله k-anonymity را ببینید |
| خدمات مناقصه و مزایده | برای آزمایش در H2 2023 هدف گذاری شده است. | در حال توسعه. |
ویژگی های اضافی
| ویژگی | برای تست موجود است | وضعیت |
|---|---|---|
| سیگنال‌های پیشنهاد کاربر در سطح رویداد برای مدل‌سازی ( مساله Github ) | 2023 | در سه ماهه دوم 2023 در کروم موجود است. |
| گزارش تاخیر به ازای هر خریدار | 2023 | در سه ماهه اول 2023 در کروم موجود است. |
| مهلت زمانی دیوار برای هر خریدار | 2023 | در سه ماهه اول 2023 در کروم موجود است. |
| شناسه گزارش خریدار برای خرابی‌های سفارشی | 2023 | در سه ماهه سوم 2023 در کروم موجود است. |
| پشتیبانی مقصد فروشنده مستقیم | 2023 | در سه ماهه اول 2023 در کروم موجود است. |
| هزینه تبلیغات محدود با دقت برای صورت‌حساب هزینه هر کلیک | 2023 | در سه ماهه دوم 2023 در کروم موجود است. |
| ارز برای بالاترین پیشنهاد و بالاترین پیشنهاد امتیازدهی دیگر | 2023 | در سه ماهه سوم 2023 در کروم موجود است. |
| پشتیبانی ماکرو برای ردیاب های تبلیغاتی شخص ثالث (3PAT) | 2023 | در سه ماهه سوم 2023 در کروم موجود است. |
| پشتیبانی از هدف گذاری گروهی با علاقه منفی | بعداً در سال 2023 | در کروم در Q4 2023 مورد انتظار است. |
| انتشار ایمن سیگنال های حراج بدون WebBundle مسئله Github | بعداً در سال 2023 | در کروم در Q4 2023 مورد انتظار است |
| حذف گروه بهره انبوه مسئله Github | بعداً در سال 2023 | در کروم در Q4 2023 مورد انتظار است |
| سقف گروه بهره را از 1 هزار به 2 هزار افزایش دهید مسئله Github | بعداً در سال 2023 | در کروم در Q4 2023 مورد انتظار است |
| پشتیبانی از Bidding و Auction Beta 1 توضیح دهنده | Origin Trial، بعداً در سال 2023 | در کروم (از طریق Origin Trial) در Q4 2023 مورد انتظار است |
| API مانیتورینگ زمان واقعی توضیح دهنده | اواخر سه ماهه دوم یا اوایل سه ماهه سوم 2024 | در کروم در اواخر سه ماهه دوم یا اوایل سه ماهه سوم 2024 انتظار می رود همچنین در حال بررسی بهبودهایی هستیم که در توضیح دهنده در کار آینده به اشتراک گذاشته شده است. ما قصد داریم تا سه ماهه اول سال 2025 جهت را تأیید کنیم و انتظار داریم تا سه ماهه اول 2026 راه حل تجدید نظر شده ای را ارائه دهیم، مشروط به زمان بندی راه اندازی فناوری های اساسی. |
گزارش برنده حراج در سطح رویداد
ما در ابتدا اشاره کردیم که گزارش برنده حراج در سطح رویداد یک راه حل موقت خواهد بود و از API جمع آوری خصوصی برای تولید گزارش های خلاصه استفاده می شود. پس از گوش دادن به بازخورد و بررسی پیچیدگی نسبی راه‌حل‌های مبتنی بر تجمیع، به‌ویژه برای صدور صورت‌حساب، تصمیم گرفتیم پشتیبانی از گزارش نتایج برنده حراج در سطح رویداد را با توابع reportResult() و reportWin() که قابلیت فراخوانی sendReportTo() را دارند حذف نکنیم. sendReportTo() .
گزارش برنده حراج در سطح رویداد حداقل تا سال 2026 پشتیبانی می‌شود و قبل از انتقال API به هر راه‌حل جایگزین، اطلاعیه‌ای پیشرفته ارائه می‌کنیم.
گزارش ضرر حراج همچنان از طریق Private Aggregation API پشتیبانی می شود.
گزارش انبوه مبتنی بر محرک
در طول حراج مخاطب محافظت‌شده، می‌توانید یک گزارش جمع‌آوری‌شده را هنگامی که توسط یک رویداد راه‌اندازی می‌شود، با استفاده از روش contributeToHistogramOnEvent() API Aggregation خصوصی ارسال کنید. رویداد آغازگر می تواند از خود حراج باشد، مانند برد یا باخت حراج. پس از آن، چنین گزارش‌های انبوهی به یک سرویس جمع‌آوری مستقر ارسال می‌شوند، که به شما امکان می‌دهد یک گزارش خلاصه نهایی که شامل نتایج ضرر حراج است، ایجاد کنید. این رویداد همچنین می‌تواند از یک قاب حصاردار خارج از حراج با استفاده از APIهای گزارش‌دهی تبلیغات قاب حصاردار (Fenced Frame Ads Reporting API window.fenced.reportEvent() باشد.
برای کسب اطلاعات بیشتر به بخش contributeToHistogramOnEvent() صفحه Private Aggregation مراجعه کنید.
استفاده از محیط اجرای مورد اعتماد برای سرویس کلید/ارزش
سرویس کلید/ارزش API مخاطب محافظت شده به حراج اجازه می‌دهد سیگنال‌های بی‌درنگ را زمانی که پیشنهاد توسط خریدار تولید می‌شود و آگهی توسط فروشنده امتیاز می‌گیرد، بازیابی کند. سرویس Key/Value در نهایت باید در یک محیط اجرای قابل اعتماد (TEE) اجرا شود تا اطمینان حاصل شود که داده‌های کاربر خصوصی نگه داشته می‌شوند.
اجرای سرویس کلید/مقدار در TEE مورد نیاز نیست. ما حداقل 12 ماه قبل از اجباری شدن استفاده از TEE اطلاع رسانی خواهیم کرد. تا آن زمان، می‌توانید به استفاده از سرور خود برای سیگنال‌های کلید/مقدار بی‌درنگ ادامه دهید. توجه داشته باشید که اجرای سرویس Key/Value در یک TEE با توابع تعریف شده توسط کاربر (UDF) تا پایان سه ماهه اول سال 2023 با API مخاطب محافظت شده روی دستگاه برای آزمایش در دسترس خواهد بود.
قاب های نرده دار
فریم های حصاردار یک عنصر جدید HTML هستند که ارتباط بین محتوا و جاسازی را محدود می کند و برای ارائه محتوا بر اساس داده های بین سایتی استفاده می شود. Protected Audience API محتوا را به یک قاب حصاردار تبدیل می کند.
پس از همکاری نزدیک با سهامداران مختلف و بررسی تلاش‌های قابل توجه برای سازگاری با این تغییر، Chrome قاب‌های حصاردار را حداقل تا سال 2026 برای حفظ فراگیر بودن اکوسیستم اجباری نمی‌کند و Chrome اطلاعیه‌های پیشرفته قابل توجهی را ارائه خواهد کرد. تا آن زمان، اگر از قاب‌های حصاردار استفاده نمی‌شود، باید از یک iframe برای رندر کردن URN مات استفاده کنید. همچنین، لازم به ذکر است که فروشندگان همچنان می توانند از قاب های حصاردار استفاده کنند.
| پیشنهاد | وضعیت |
|---|---|
| Web API برای urn به پیکربندی تغییر می کند توضیح دهنده | در سه ماهه اول 2023 در کروم موجود است. |
| ماکروهای خلاقانه در قاب های حصاردار برای گزارش تبلیغات (FFAR) مشکل GitHub | در سه ماهه سوم 2023 در کروم موجود است. |
| یک بار چراغ های خودکار ارسال کنید مشکل GitHub | در سه ماهه سوم 2023 در کروم موجود است. |
| پیکربندی قاب های حصاردار قابل سریال مشکل GitHub | در سه ماهه سوم 2023 در کروم موجود است. |
| گزینه قالب اضافی برای ماکروهای اندازه تبلیغ مخاطب محافظت شده مشکل GitHub | در کروم در Q4 2023 موجود است. |
| ارسال خودکار چراغ ها به همه URL های ثبت شده مشکل GitHub | مشکل GitHub | در کروم در Q4 2023 موجود است. |
| خروج از گروه‌های مورد علاقه آگهی از Urn iFrames و Ad Component Frames را فعال کنید مشکل GitHub | در سه ماهه اول 2024 در کروم موجود است |
| Reserved.top_navigation_start/commit را معرفی کنید مشکل GitHub ، مشکل GitHub | در سه ماهه اول 2024 در کروم موجود است |
| تنظیمات کوکی را در ReportEvent تا 3PCD غیرفعال نکنید مشکل GitHub | در سه ماهه اول 2024 در کروم موجود است |
| پشتیبانی از چراغ های خودکار را در زیرفریم های متقاطع اضافه کنید مشکل GitHub | در سه ماهه اول 2024 در کروم موجود است |
به زیرفریم های Cross-Origin اجازه دهید که Beacon های reportEvent() ارسال کنندمشکل GitHub | در سه ماهه دوم 2024 در کروم موجود است |
API مخاطب محافظت شده و ادغام Attribution Reporting بهبود یافته است
اخیراً، چالش‌هایی در مورد ادغام API گزارش انتساب و API مخاطب محافظت شده، به ویژه در مواردی که قاب‌های حصاردار درگیر هستند، اشاره شده است .
برای گزارش‌دهی در سطح رویداد با API مخاطبان محافظت‌شده، مجموعه‌ای از پیشرفت‌های اولیه پیشنهادی برای آسان‌تر کردن این یکپارچه‌سازی داریم که می‌توانید در توضیح بیشتر درباره آن بیاموزید. ادغام برای هر دو قاب حصاردار و iFrames در دسترس خواهد بود. گزارش‌دهی در سطح رویداد برای آزمایش در Chrome Stable M112+ در دسترس خواهد بود.
برای کسانی که به گزارش انتساب با API مخاطبان محافظت شده نیاز دارند، ما در حال کار بر روی راه حل های انعطاف پذیرتری هستیم تا سیگنال های پیشنهادی بیشتری را با گزارش های انباشته دریافت کنیم، و پس از آماده شدن پیشنهاد، آن را منتشر خواهیم کرد.
خدمات مناقصه و مزایده
ما نگرانی‌هایی در مورد تأخیر API مخاطب محافظت‌شده شنیده‌ایم و فعالانه در حال کار روی بهبود تأخیر در دستگاه هستیم. هم Chrome و هم Android قصد دارند خدمات مناقصه و مزایده را به عنوان راه دیگری برای اجرای منطق مناقصه و امتیازدهی در کنار مزایده‌های داخل دستگاه ارائه کنند. خدمات مناقصه و مزایده یک راه حل سرویس API مخاطبان محافظت شده برای اجرای حراج ها خارج از دستگاه است که ما معتقدیم عملکرد سریع تری را ممکن می کند.
ما به حمایت از مزایده های روی دستگاه ادامه خواهیم داد و استفاده از خدمات مناقصه و مزایده الزامی نیست مگر اینکه با موارد استفاده شما مطابقت داشته باشد.
جزئیات بیشتر را می توانید در پست وبلاگ پیدا کنید.
بعدش چی؟
ما می‌خواهیم با شما گفتگو کنیم تا اطمینان حاصل کنیم که یک API درست می‌کنیم که برای همه کار کند.
در مورد API بحث کنید
مانند سایر APIهای Privacy Sandbox، این API مستند شده و به صورت عمومی مورد بحث قرار گرفته است.
با API آزمایش کنید
می‌توانید آزمایش کنید و در گفتگو درباره API مخاطبان محافظت شده شرکت کنید .
،درباره ویژگی های حراج API مخاطب محافظت شده بیشتر بیاموزید.
همانطور که ویژگی های Protected Audience API را به در دسترس بودن عمومی منتقل می کنیم، ممکن است در مورد در دسترس بودن خدمات و ویژگی های Protected Audience API تعجب کنید. در اینجا فهرستی از ویژگی‌های API مخاطب محافظت شده با محدوده و زمان پشتیبانی از آنها را می‌بینید.
جدول زمانی در دسترس بودن ویژگی
| ویژگی | برای تست موجود است | وضعیت |
|---|---|---|
| گزارش برنده حراج در سطح رویداد | در حال حاضر | حداقل تا سال 2026 پشتیبانی می شود. این ویژگی در نظر گرفته شده است تا انتقال به گزارش‌های API مخاطبان محافظت شده از گزارش کوکی شخص ثالث را آسان‌تر کند. بنابراین، پس از اینکه فناوری‌های تبلیغاتی زمان لازم برای به‌روزرسانی مکانیسم‌های گزارش‌دهی خود را داشتند، از این گزارش پشتیبانی نمی‌شود. |
| تجمع مبتنی بر ماشه | در حال حاضر | برای آزمایش در Chrome Canary/Dev M113+ و Beta/Stable M115+ موجود است. |
| استفاده از محیط اجرای معتمد (TEE) برای سرویس کلید/ارزش | در حال حاضر | زودتر از سه ماهه سوم 2025 لازم نیست. |
| قاب های نرده دار | در حال حاضر | زودتر از 2026 لازم نیست. |
| API مخاطب محافظت شده + ادغام گزارش Attribution بهبود یافته است | 2023 Q2 | برای آزمایش در Chrome Stable M112+ موجود است. |
| K-ناشناس بودن | در حال حاضر | مقاله k-anonymity را ببینید |
| خدمات مناقصه و مزایده | برای آزمایش در H2 2023 هدف گذاری شده است. | در حال توسعه. |
ویژگی های اضافی
| ویژگی | برای تست موجود است | وضعیت |
|---|---|---|
| سیگنال‌های پیشنهاد کاربر در سطح رویداد برای مدل‌سازی ( مساله Github ) | 2023 | در سه ماهه دوم 2023 در کروم موجود است. |
| گزارش تاخیر به ازای هر خریدار | 2023 | در سه ماهه اول 2023 در کروم موجود است. |
| مهلت زمانی دیوار برای هر خریدار | 2023 | در سه ماهه اول 2023 در کروم موجود است. |
| شناسه گزارش خریدار برای خرابی‌های سفارشی | 2023 | در سه ماهه سوم 2023 در کروم موجود است. |
| پشتیبانی مقصد فروشنده مستقیم | 2023 | در سه ماهه اول 2023 در کروم موجود است. |
| هزینه تبلیغات محدود با دقت برای صورت‌حساب هزینه هر کلیک | 2023 | در سه ماهه دوم 2023 در کروم موجود است. |
| ارز برای بالاترین پیشنهاد و بالاترین پیشنهاد امتیازدهی دیگر | 2023 | در سه ماهه سوم 2023 در کروم موجود است. |
| پشتیبانی ماکرو برای ردیاب های تبلیغاتی شخص ثالث (3PAT) | 2023 | در سه ماهه سوم 2023 در کروم موجود است. |
| پشتیبانی از هدف گذاری گروهی با علاقه منفی | بعداً در سال 2023 | در کروم در Q4 2023 مورد انتظار است. |
| انتشار ایمن سیگنال های حراج بدون WebBundle مسئله Github | بعداً در سال 2023 | در کروم در Q4 2023 مورد انتظار است |
| حذف گروه بهره انبوه مسئله Github | بعداً در سال 2023 | در کروم در Q4 2023 مورد انتظار است |
| سقف گروه بهره را از 1 هزار به 2 هزار افزایش دهید مسئله Github | بعداً در سال 2023 | در کروم در Q4 2023 مورد انتظار است |
| پشتیبانی از Bidding و Auction Beta 1 توضیح دهنده | Origin Trial، بعداً در سال 2023 | در کروم (از طریق Origin Trial) در Q4 2023 مورد انتظار است |
| API مانیتورینگ زمان واقعی توضیح دهنده | اواخر سه ماهه دوم یا اوایل سه ماهه سوم 2024 | در کروم در اواخر سه ماهه دوم یا اوایل سه ماهه سوم 2024 انتظار می رود همچنین در حال بررسی بهبودهایی هستیم که در توضیح دهنده در کار آینده به اشتراک گذاشته شده است. ما قصد داریم تا سه ماهه اول سال 2025 جهت را تأیید کنیم و انتظار داریم تا سه ماهه اول 2026 راه حل تجدید نظر شده ای را ارائه دهیم، مشروط به زمان بندی راه اندازی فناوری های اساسی. |
گزارش برنده حراج در سطح رویداد
ما در ابتدا اشاره کردیم که گزارش برنده حراج در سطح رویداد یک راه حل موقت خواهد بود و از API جمع آوری خصوصی برای تولید گزارش های خلاصه استفاده می شود. پس از گوش دادن به بازخورد و بررسی پیچیدگی نسبی راه‌حل‌های مبتنی بر تجمیع، به‌ویژه برای صدور صورت‌حساب، تصمیم گرفتیم پشتیبانی از گزارش نتایج برنده حراج در سطح رویداد را با توابع reportResult() و reportWin() که قابلیت فراخوانی sendReportTo() را دارند حذف نکنیم. sendReportTo() .
گزارش برنده حراج در سطح رویداد حداقل تا سال 2026 پشتیبانی می‌شود و قبل از انتقال API به هر راه‌حل جایگزین، اطلاعیه‌ای پیشرفته ارائه می‌کنیم.
گزارش ضرر حراج همچنان از طریق Private Aggregation API پشتیبانی می شود.
گزارش انبوه مبتنی بر محرک
در طول حراج مخاطب محافظت‌شده، می‌توانید یک گزارش جمع‌آوری‌شده را هنگامی که توسط یک رویداد راه‌اندازی می‌شود، با استفاده از روش contributeToHistogramOnEvent() API Aggregation خصوصی ارسال کنید. رویداد آغازگر می تواند از خود حراج باشد، مانند برد یا باخت حراج. پس از آن، چنین گزارش‌های انبوهی به یک سرویس جمع‌آوری مستقر ارسال می‌شوند، که به شما امکان می‌دهد یک گزارش خلاصه نهایی که شامل نتایج ضرر حراج است، ایجاد کنید. این رویداد همچنین می‌تواند از یک قاب حصاردار خارج از حراج با استفاده از APIهای گزارش‌دهی تبلیغات قاب حصاردار (Fenced Frame Ads Reporting API window.fenced.reportEvent() باشد.
برای کسب اطلاعات بیشتر به بخش contributeToHistogramOnEvent() صفحه Private Aggregation مراجعه کنید.
استفاده از محیط اجرای مورد اعتماد برای سرویس کلید/ارزش
سرویس کلید/ارزش API مخاطب محافظت شده به حراج اجازه می‌دهد سیگنال‌های بی‌درنگ را زمانی که پیشنهاد توسط خریدار تولید می‌شود و آگهی توسط فروشنده امتیاز می‌گیرد، بازیابی کند. سرویس Key/Value در نهایت باید در یک محیط اجرای قابل اعتماد (TEE) اجرا شود تا اطمینان حاصل شود که داده‌های کاربر خصوصی نگه داشته می‌شوند.
اجرای سرویس کلید/مقدار در TEE مورد نیاز نیست. ما حداقل 12 ماه قبل از اجباری شدن استفاده از TEE اطلاع رسانی خواهیم کرد. تا آن زمان، می‌توانید به استفاده از سرور خود برای سیگنال‌های کلید/مقدار بی‌درنگ ادامه دهید. توجه داشته باشید که اجرای سرویس Key/Value در یک TEE با توابع تعریف شده توسط کاربر (UDF) تا پایان سه ماهه اول سال 2023 با API مخاطب محافظت شده روی دستگاه برای آزمایش در دسترس خواهد بود.
قاب های نرده دار
فریم های حصاردار یک عنصر جدید HTML هستند که ارتباط بین محتوا و جاسازی را محدود می کند و برای ارائه محتوا بر اساس داده های بین سایتی استفاده می شود. Protected Audience API محتوا را به یک قاب حصاردار تبدیل می کند.
پس از همکاری نزدیک با سهامداران مختلف و بررسی تلاش‌های قابل توجه برای سازگاری با این تغییر، Chrome قاب‌های حصاردار را حداقل تا سال 2026 برای حفظ فراگیر بودن اکوسیستم اجباری نمی‌کند و Chrome اطلاعیه‌های پیشرفته قابل توجهی را ارائه خواهد کرد. تا آن زمان، اگر از قاب‌های حصاردار استفاده نمی‌شود، باید از یک iframe برای رندر کردن URN مات استفاده کنید. همچنین، لازم به ذکر است که فروشندگان همچنان می توانند از قاب های حصاردار استفاده کنند.
| پیشنهاد | وضعیت |
|---|---|
| Web API برای urn به پیکربندی تغییر می کند توضیح دهنده | در سه ماهه اول 2023 در کروم موجود است. |
| ماکروهای خلاقانه در قاب های حصاردار برای گزارش تبلیغات (FFAR) مشکل GitHub | در سه ماهه سوم 2023 در کروم موجود است. |
| یک بار چراغ های خودکار ارسال کنید مشکل GitHub | در سه ماهه سوم 2023 در کروم موجود است. |
| پیکربندی قاب های حصاردار قابل سریال مشکل GitHub | در سه ماهه سوم 2023 در کروم موجود است. |
| گزینه قالب اضافی برای ماکروهای اندازه تبلیغ مخاطب محافظت شده مشکل GitHub | در کروم در Q4 2023 موجود است. |
| ارسال خودکار چراغ ها به همه URL های ثبت شده مشکل GitHub | مشکل GitHub | در کروم در Q4 2023 موجود است. |
| خروج از گروه‌های مورد علاقه آگهی از Urn iFrames و Ad Component Frames را فعال کنید مشکل GitHub | در سه ماهه اول 2024 در کروم موجود است |
| Reserved.top_navigation_start/commit را معرفی کنید مشکل GitHub ، مشکل GitHub | در سه ماهه اول 2024 در کروم موجود است |
| تنظیمات کوکی را در ReportEvent تا 3PCD غیرفعال نکنید مشکل GitHub | در سه ماهه اول 2024 در کروم موجود است |
| پشتیبانی از چراغ های خودکار را در زیرفریم های متقاطع اضافه کنید مشکل GitHub | در سه ماهه اول 2024 در کروم موجود است |
به زیرفریم های Cross-Origin اجازه دهید که Beacon های reportEvent() ارسال کنندمشکل GitHub | در سه ماهه دوم 2024 در کروم موجود است |
API مخاطب محافظت شده و ادغام Attribution Reporting بهبود یافته است
اخیراً، چالش‌هایی در مورد ادغام API گزارش انتساب و API مخاطب محافظت شده، به ویژه در مواردی که قاب‌های حصاردار درگیر هستند، اشاره شده است .
برای گزارش‌دهی در سطح رویداد با API مخاطبان محافظت‌شده، مجموعه‌ای از پیشرفت‌های اولیه پیشنهادی برای آسان‌تر کردن این یکپارچه‌سازی داریم که می‌توانید در توضیح بیشتر درباره آن بیاموزید. ادغام برای هر دو قاب حصاردار و iFrames در دسترس خواهد بود. گزارش‌دهی در سطح رویداد برای آزمایش در Chrome Stable M112+ در دسترس خواهد بود.
برای کسانی که به گزارش انتساب با API مخاطبان محافظت شده نیاز دارند، ما در حال کار بر روی راه حل های انعطاف پذیرتری هستیم تا سیگنال های پیشنهادی بیشتری را با گزارش های انباشته دریافت کنیم، و پس از آماده شدن پیشنهاد، آن را منتشر خواهیم کرد.
خدمات مناقصه و مزایده
ما نگرانی‌هایی در مورد تأخیر API مخاطب محافظت‌شده شنیده‌ایم و فعالانه روی بهبود تأخیر در دستگاه کار می‌کنیم. هم Chrome و هم Android قصد دارند خدمات مناقصه و مزایده را به عنوان راه دیگری برای اجرای منطق مناقصه و امتیازدهی در کنار مزایده‌های داخل دستگاه ارائه کنند. خدمات مناقصه و مزایده یک راه حل سرویس API مخاطبان محافظت شده برای اجرای حراج ها خارج از دستگاه است که ما معتقدیم عملکرد سریع تری را ممکن می کند.
ما به حمایت از مزایده های روی دستگاه ادامه خواهیم داد و استفاده از خدمات مناقصه و مزایده الزامی نیست مگر اینکه با موارد استفاده شما مطابقت داشته باشد.
جزئیات بیشتر را می توانید در پست وبلاگ پیدا کنید.
بعدش چی؟
ما می‌خواهیم با شما گفتگو کنیم تا اطمینان حاصل کنیم که یک API درست می‌کنیم که برای همه کار کند.
در مورد API بحث کنید
مانند سایر APIهای Privacy Sandbox، این API مستند شده و به صورت عمومی مورد بحث قرار گرفته است.
با API آزمایش کنید
می‌توانید آزمایش کنید و در گفتگو درباره API مخاطبان محافظت شده شرکت کنید .