پرسش‌های متداول مربوط به Sandbox و اندازه‌گیری حریم خصوصی

پاسخ به پرسش‌های متداول مرتبط با مرتبط بودن و اندازه‌گیری Privacy Sandbox.

چگونه موضوعات با مخاطبان تعریف شده فروشنده (SDA) مقایسه می شود؟

موضوعات و SDA انواع مکملی از اطلاعات را ارائه می دهند و هر دو در کنترل ناشر هستند. ما معتقد نیستیم که آنها در رقابت با یکدیگر هستند. در عوض، هر دو در کنار هم یا در زمینه های مختلف برای به حداکثر رساندن فرصت های خرید کار می کنند. خریداران هنگام ارزیابی برنامه‌ریزی‌ها، سیگنال‌های زیادی را در نظر می‌گیرند و از آنها استفاده می‌کنند، و ما انتظار داریم که Topics یکی از این ملاحظات باشد. فروشندگان از لحاظ تاریخی بخش‌های مخاطب را در حراج‌های بازار آزاد لحاظ نمی‌کنند، احتمالاً موضوعات مکانی مورد استفاده قرار خواهند گرفت. در عوض، فروشندگان مخاطبان خود را برای خرید برنامه‌ریزی شده در معاملاتی که با تبلیغ‌کنندگان، آژانس‌ها یا DSP‌ها انجام می‌شود، در دسترس قرار داده‌اند. در این موارد، فروشنده و خریدار به طور هدفمند در SDA معامله می کنند. اگر از موضوعات در این موارد استفاده می شود، می تواند برای یک یا چند مورد از موارد زیر باشد:

• فروشنده تعریف مخاطب خود را با موضوعات افزایش می دهد
• خریدار از موضوعات به عنوان سیگنالی برای قیمت پیشنهاد استفاده می کند
• خریدار از Topics برای تأیید صحت SDA استفاده می کند

آیا مخاطب محافظت شده گوگل را در کنترل ایجاد مخاطب قرار می دهد؟

خیر. سایت‌ها می‌توانند به ایجاد مخاطبین خود در داخل و خارج از Privacy Sandbox ادامه دهند. وقتی سایت‌ها در داخل جعبه ایمنی حریم خصوصی مخاطب ایجاد می‌کنند، مالک سایت یا پروکسی انتخابی تعیین می‌کند که چه کسی می‌تواند مخاطبان را بسازد، چه مخاطبانی هستند، چگونه آن مخاطبان به‌روزرسانی می‌شوند، چگونه به آن مخاطبان پیشنهاد داده می‌شوند و آیا کاربران را از مخاطب حذف کند یا خیر.

آیا مخاطب محافظت شده از گروه های علاقه ایجاد شده توسط ناشر پشتیبانی می کند؟

آره. ما می دانیم که ناشران از ترس نشت داده ها از قرار دادن مخاطبان خود در مزایده های مبتنی بر OpenRTB امروز محتاط هستند. ناشران می‌توانند امروز در مخاطبین محافظت‌شده مخاطبانی بسازند که نمای متقاطع آن کاربر ناشر را به پیشنهاد دهنده ارائه ندهند. ما مشتاقیم که به بررسی روش‌هایی ادامه دهیم که ناشران بتوانند از محیط کاهش نشت داده مخاطبین محافظت شده استفاده کنند.

قوانین کیفیت تبلیغات چگونه در حراجی های مخاطب محافظت شده اجرا می شود؟

روش‌های مختلفی وجود دارد که قوانین کیفیت تبلیغات در حراج‌های مخاطب محافظت‌شده اعمال می‌شود. هر یک از اینها شبیه به نحوه اعمال قوانین کیفیت تبلیغات توسط SSPها امروزی است. یکی از راه‌ها این است که اجازه دهید یک حراج با یک خلاقیت ناشناخته، خلاق را در صف اسکن قرار دهد. ما این بازخورد را شنیده‌ایم که SSP‌ها می‌خواهند پشتیبانی بهتری برای این مورد استفاده کنند و در حال طراحی مکانیزمی هستیم که می‌تواند فید از renderUrls ایجاد کند که SSP بتواند خارج از باند آن را بررسی کند و سپس اطلاعات را در سرور ارزش کلیدی خود ذخیره کند. راه دیگر این است که نیاز به پیش ثبت نام تبلیغات داشته باشید. مانند مورد قبلی، هنگامی که خلاقیت اسکن شد، نتایج را می توان به سرور ارزش کلید متصل کرد. بعداً وقتی خریدار با آن خلاقیت پیشنهاد داد (همانطور که یک شناسه خلاقانه نشان می‌دهد که احتمالاً همان قالب OpenRTB را دارد)، منطق امتیازدهی فروشنده می‌تواند در سرور ارزش کلیدی جستجو کند و تصمیم بگیرد که چگونه امتیاز بگیرد.

آیا مخاطب محافظت شده از تبلیغات ویدیویی پشتیبانی می کند؟

آره. نشانی‌های وب VAST را می‌توان به مخاطب محافظت‌شده ارسال کرد و از آن خارج کرد. همانطور که URL VAST منتشر می شود، فناوری سمت فروش می تواند نحوه بسته بندی URL VAST خریدار را قبل از ارسال به پخش کننده هماهنگ کند. پیش از نیاز به حرکت به فریم‌های حصاردار (نه زودتر از سال 2026) و تقویت بیشتر حفاظت از حریم خصوصی کاربر، انتظار داریم اکوسیستم در بحث‌های طراحی شرکت کند که مطمئناً شامل ویدیو می‌شود.

آیا مخاطب محافظت شده از تبلیغات بومی پشتیبانی می کند؟

آره. نشانی‌های اینترنتی JSON را می‌توان به مخاطب محافظت‌شده ارسال کرد و از آن خارج کرد. همانطور که یک URL JSON منتشر می شود، فناوری سمت فروش می تواند نحوه اضافه کردن رویدادهای مورد نظر را قبل از ارسال JSON نهایی به کد رندر هماهنگ کند. پیش از نیاز به انتقال به فریم‌های حصاردار (نه زودتر از سال 2026) برای تقویت بیشتر حفاظت از حریم خصوصی کاربر، ما انتظار داریم اکوسیستم در بحث‌های طراحی که احتمالاً شامل بومی می‌شود، شرکت کند.

آیا رندر تبلیغات مخاطب محافظت شده مانع از نوآوری می شود؟

خیر. رندر تبلیغات همیشه به فناوری های مرورگر متکی بوده است. این تغییر نمی کند. شاید این نگرانی مختص برنامه هایی باشد که در آینده نیاز به استفاده از قاب های حصاردار در ارتباط با مخاطبان محافظت شده دارند. بخشی از دلیل اینکه این طرح‌ها «در آینده» هستند این است که ما می‌خواهیم فناوری Fenced Frames از نوآوری و تمایز اکوسیستم در هنگام ارائه تبلیغات پشتیبانی کند. برای توسعه‌دهندگان و شرکت‌های علاقه‌مند زمان وجود دارد تا در جهت فریم‌های حصاردار که شامل نحوه پشتیبانی از رویکردهای تبلیغات بومی است، فکر کنند.

آیا مخاطب محافظت شده به روش‌های پیچیده‌ای که امروزه در مزایده‌های سنتی وجود دارد، سرعت و ارزش‌گذاری پیشنهاد می‌دهد؟

مخاطبان محافظت شده یک گزینه بی‌درنگ برای خریداران برای درک سرعت و بودجه کمپین ارائه می‌کند. از نقطه نظر موجودی، این امکان برای فروشنده وجود دارد که سیگنال های حراج را در مورد زمینه صفحه و هر چیز دیگری به خریدار ارائه دهد. اگر فروشنده ای تصمیم به ارسال یک درخواست پیشنهادی متنی داشته باشد، خریدار می تواند از طریق آن مکانیسم نیز در مورد موجودی اطلاعات بیاموزد، سپس سیگنال های متنی (از طریق perBuyerSignals ) برای خود فراهم کند که می تواند در تولید پیشنهاد مخاطب محافظت شده خود استفاده شود. پذیرندگان اولیه در حال حاضر سیستم های یادگیری ماشین را به مخاطبان محافظت شده متصل می کنند. ما می‌دانیم که تنظیم این سیستم‌ها برای مناقصه در محیط‌های مخاطب محافظت شده زمان می‌برد، اما توجه به این نکته ضروری است که تنظیم امکان‌پذیر است و در حال حاضر در حال انجام است.

آیا استاندارد OpenRTB در مخاطبین محافظت شده کار می کند؟

آره. این کار در آزمایشگاه فناوری IAB از طریق یک گروه پرمخاطب از DSPها و SSPها در حال پیشرفت است. به نظر می رسد مسیر پیش رو استفاده از بخش هایی از پروتکل OpenRTB به عنوان یک استاندارد ارتباطی در مزایده های مخاطب محافظت شده باشد، و ما از پذیرندگان اولیه که قبلاً به این شکل ساخته شده اند آگاه هستیم.

آیا مخاطب محافظت شده شرکت ها را ملزم به حفظ دو معماری مجزا برای ارائه تبلیغات می کند؟

خیر. مخاطب محافظت شده نیازی به حفظ دو معماری مجزا ندارد. انتخاب های معماری شما با خودتان است. همانطور که تبلیغات آنلاین در طول سال ها پیشرفت کرده است، پیچیدگی سیستم های تقویت کننده آن نیز افزایش یافته است. خصوصی کردن اینترنت برای کاربران، پیچیدگی بیشتری را به همراه دارد و نیاز به کار دارد. شرکت‌های فناوری تبلیغات می‌توانند دو معماری مجزا را حفظ کنند یا مخاطبان محافظت شده را در یک معماری ترکیبی با حراج‌های سنتی بسازند.

یک بار دیگر شرکت‌های فناوری تبلیغاتی از مخاطبان محافظت شده حمایت کنند، با حراج‌های سنتی چه اتفاقی می‌افتد؟

ما انتظار داریم که حراج‌های متنی به دلایل بی‌شماری، از جمله معاملات، کمپین‌های هدف‌دار مخاطبان شخص اول و بسیاری از سناریوهای متنی دیگر، مرتبط باقی بماند. آنها همچنین زمانی ارزشمند می مانند که هیچ گروه علاقه مندی وجود نداشته باشد یا پیشنهادات در مخاطبین محافظت شده به سطح بالایی نرسند یا قوانین کیفیت آگهی را رعایت نکنند.

آیا حراج مخاطب محافظت شده با تلاش‌های بهینه‌سازی مسیر تامین اکوسیستم (SPO) برای کاهش کل واسطه‌ها بین یک تبلیغ‌کننده و یک ناشر و/یا تکرار یک فرصت تبلیغاتی مغایرت دارد؟

خیر. اگر خریدار یکپارچه سازی مستقیم با ناشر ایجاد کند، یک آگهی برنده در مخاطبین محافظت شده حداکثر از دو نهاد فروشنده (به عنوان مثال، یک پلتفرم سمت تأمین (SSP) و یک سرور آگهی ناشر) عبور می کند.

تکرار درخواست مشابه با استفاده از چند واسطه، انتخاب ناشر است. مخاطب محافظت شده نباید این موضوع را به یک شکل تحت تاثیر قرار دهد.

حراج های مخاطب محافظت شده خارج از سیستم بلادرنگ سرور به سرور امروزی رخ می دهد تا اطلاعات کاربران بین سایتی درز نکند. برخی ممکن است بگویند این یک درخواست تبلیغاتی تکراری است. رسیدن به حریم خصوصی قابل اثبات فنی نیازمند برخی معاوضه است. با این حال، ممکن است در درازمدت اکوسیستم تصمیم بگیرد که از مخاطبان محافظت شده بدون حراج های سنتی سمت سرور استفاده کند. این انتخاب می تواند حتی به مسیرهای عرضه بهینه تر منجر شود.

آیا مخاطب محافظت شده ارزش زیرساخت های شکل دهی ترافیک موجود را کاهش می دهد؟

همانطور که فهمیدیم، چیزی که با توجه به پرس و جو در ثانیه در حال تغییر است این است که بسیاری از SSP ها از شناسه های متقابل سایت به عنوان ویژگی برای تعیین ارسال یا عدم ارسال درخواست DSP استفاده می کنند. بنابراین کاهش شناسه های متقابل سایت بر تکنیک های شکل دهی ترافیک موجود تأثیر می گذارد. چه ناشر بخواهد حراج مخاطب محافظت شده را اجرا کند یا نه، این درست است.

ما شکل‌دهی ترافیک را با بسیاری از SSPها بررسی کردیم و راه‌حل‌هایی از جمله ذخیره‌سازی پنهان و فیلتر مبتنی بر زمینه پیدا کردیم. با گذشت زمان از توسعه دهندگان انتظار داریم که از مزیت Private Aggregation برای کمک به درک بیشتر ترجیحات پیشنهادی DSP و فیلتر کردن بر اساس آن استفاده کنند.

در نهایت، برخی از زیرساخت‌های قدیمی که حول شناسه‌های متقابل ساخته شده‌اند دیگر مفید نخواهند بود.

آیا درخواست های جدید ناشی از حراج مخاطب محافظت شده ظرفیت SSP را کاهش می دهد؟

ما از برخی SSP ها شنیده ایم که ظرفیت از نقطه نظر یکپارچه سازی یک مسئله یا بخش مهمی از یک پیشنهاد ارزش SSP نیست. برای SSPهایی که نگران تماس‌های جدید در فرآیند حراج هستند، ما از شرکت‌هایی آگاه هستیم که از قبل به SSPها با نگرانی‌های مربوط به ظرفیت کمک می‌کنند و به دنبال گسترش این خدمات برای حمایت از مخاطبین محافظت‌شده هستند. اگر مایلید که شما را با یکی از آن شرکت ها ارتباط دهیم ، به ما اطلاع دهید .

وقتی منابع رقیب در مرورگر وجود دارد، اولویت در مخاطبین محافظت شده چگونه بررسی می شود؟

مخاطب محافظت شده عموماً از الگوی استاندارد کنترل ساختمان پیروی می کند که به فروشندگان اجازه می دهد تصمیم بگیرند که پیشنهاد دهندگان چه مقدار زمان و منابع می توانند مصرف کنند و ابزارهایی بسازند که به خریداران اجازه می دهد تصمیم بگیرند که چگونه از منابع در دسترس خود به بهترین شکل استفاده کنند. این کنترل ها و ابزارها امروزه در دسترس هستند، اما سود کامل آنها پس از پذیرش توسط خریداران و فروشندگان محقق خواهد شد. علاوه بر این، Chrome به کار بر روی انواع بهبودهای زیرساختی برای سرعت حراج (به عنوان مثال، crrev.com/1190815 ، crrev.com/1199839 ، crrev.com/1201837 ، crrev.com/1198339 ، crrev.com/1197323 ) ادامه می‌دهد. .

مخاطب محافظت شده چگونه نگرانی‌های مربوط به تأخیر را برطرف می‌کند؟

در گذشته، قبل از «مخاطب محافظت‌شده »، مناقصه‌های بلادرنگ که روی سرورها اتفاق می‌افتاد، فروشندگان را مجبور می‌کرد که بازه‌های زمانی دقیقی را برای پاسخ‌های خریداران تعیین کنند تا تأخیر را کنترل کنند. ما انواع کنترل‌های زمان‌بندی بسیار مشابه تعیین‌شده توسط فروشنده (به مستندات مربوط به perBuyerCumulativeTimeouts ، perBuyerTimeouts ، sellerTimeout مراجعه کنید) به مخاطبین محافظت‌شده اضافه کردیم تا همین هدف را برای کنترل تأخیر انجام دهیم. این کنترل‌ها همچنین شرکت‌کنندگان در حراج را تشویق می‌کنند تا منطق خود را بهینه کنند تا مطمئن شوند از منابع به بهترین شکل برای پشتیبانی از اکوسیستم فناوری تبلیغات و تجربه کاربر با کیفیت بالا استفاده می‌شود.

Chrome همچنین به کار بر روی انواع بهبودهای زیرساختی برای سرعت حراج (به عنوان مثال crrev.com/1190815 , crrev.com/1199839 , crrev.com/1201837 , crrev.com/1198339 , crrev.com/1197323 ) ادامه می دهد. ما از هر دو بخش این تلاش تأخیر بازخورد می‌خواهیم : ابزارهای اضافی که خریداران و فروشندگان مفید می‌دانند، و گزارش‌هایی از تنگناهای مشاهده‌شده که مهندسان Chrome باید بررسی کنند.

آیا ساختن برای مخاطبان محافظت شده روی دستگاه، زمانی که خدمات مناقصه و حراج (B&A) وجود دارد، تلاشی بیهوده است؟

خیر. روی دستگاه برای موارد استفاده از فناوری تبلیغاتی کافی است. خدمات مناقصه و مزایده یک راه حل اختیاری در مقیاس افقی است زمانی که فناوری های تبلیغاتی می خواهند بیش از آنچه مرورگر اجازه می دهد در منابع محاسبه قیمت سرمایه گذاری کنند. توسعه روی دستگاه سرمایه‌گذاری خوبی است، زیرا بیشتر کارها قابل استفاده مجدد خواهند بود حتی اگر توسعه‌دهندگان بعداً تصمیم بگیرند در محیط‌های خدمات مزایده و مزایده شرکت کنند. اکثر لوله ها و زیرساخت های ساخته شده به طور مشابه به کار خود ادامه می دهند.

آیا الزامات محیط‌های اجرایی معتمد مبتنی بر ابر (TEE) برای مخاطبان محافظت‌شده، کسب‌وکارها را به استفاده از Google Cloud سوق می‌دهد؟

Privacy Sandbox APIها را برای ارائه حریم خصوصی و امنیت قوی طراحی کرده است و ما هیچ تصمیمی برای طراحی به نفع Google Cloud نگرفته ایم. پشتیبانی ما از ارائه دهندگان ابری با AWS آغاز شد، زیرا تأیید می کنیم که چه تعداد از ارائه دهندگان فناوری تبلیغات آمازون را انتخاب می کنند. علاوه بر AWS و Google Cloud، انتظار داریم در آینده از سایر ارائه دهندگان ابر پشتیبانی کنیم و آماده ارائه پیشنهادات برای سایر ارائه دهندگان ابری هستیم. اگر تأخیر یک نگرانی باشد، ابرها به مشتریان گزینه های مکان ارائه می دهند که فاصله را با سایر ارائه دهندگان ابر کوتاه می کند.

آیا جعبه ایمنی حریم خصوصی به محیط‌های اجرایی مورد اعتماد (TEEs) اجازه می‌دهد در مراکز داده ابری غیرعمومی اجرا شوند؟

محیط‌های اجرایی مورد اعتماد قابل حسابرسی (TEE) بخشی از مدل حریم خصوصی و امنیتی ما هستند. ما با TEE های ارائه شده توسط ارائه دهندگان ابر عمومی به دلیل اقدامات امنیتی دقیق شروع کردیم. برای روشن بودن، تنها APIهایی که در کوتاه مدت نیاز به استفاده از محیط‌های اجرای معتمد دارند ، API گزارش اسناد و API جمع‌آوری خصوصی هستند و هیچکدام شامل فراخوانی TEE در زمان واقعی در تنظیمات حراج نمی‌شوند. ما به بررسی پشتیبانی از گزینه‌های فراتر از راه‌حل‌های مبتنی بر ابر عمومی ادامه می‌دهیم.

آیا اجرای Trusted Execution Environments در ابرهای عمومی در مقایسه با مراکز داده فناوری تبلیغات داخلی گرانتر نخواهد بود؟

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

ارائه دهندگان ابر عمومی باید خود را از نظر امنیت در سطح بسیار بالایی نگه دارند. به عنوان مثال، AWS یک ارائه دهنده ابر معتبر با شیوه های امنیتی ثابت است. به طور خاص، AWS Nitro دارای یک مدل امنیتی مستند برای اطمینان از اینکه Nitro Enclaves از دسترسی اپراتورها به داده هایی که در Enclave پردازش می شوند جلوگیری می کند و منابع محافظت شده (مانند کلیدهای رمزگشایی) فقط برای کدهای مجاز در حال اجرا در Enclave در دسترس هستند. دسترسی فیزیکی نیز وجود دارد که باید در نظر گرفته شود. AWS برای خطرات دسترسی فیزیکی، از جمله کارمندان آمازون، اقدامات کاهشی طراحی و اجرا کرده است. TEE های مبتنی بر سخت افزار موجود ممکن است در برابر همه حملات فیزیکی که ابرهای عمومی برای انجام آن طراحی شده اند، دفاع نکنند. علاوه بر این، آمازون اخیراً گروه NCC، یک شرکت تحقیقاتی مستقل را برای بررسی طرح‌های Nitro خود، با تمرکز بر ادعاهای امنیتی مرتبط با دسترسی توسط کارکنان داخلی، استخدام کرد. گزارش عمومی نشان می دهد که طرح های AWS ادعاهای آنها را برآورده می کند.

اجرای این شیوه ها، پشتیبانی و بهبود در طول زمان هزینه دارد. با ابرهای عمومی توزیع شده در سطح جهانی و به طور گسترده در دسترس، این هزینه ها بر روی پایگاه گسترده ای از مشتریان توزیع می شود.

آیا جعبه ایمنی حریم خصوصی صورت‌حساب را تغییر می‌دهد؟

خیر. شرکت‌های فناوری تبلیغات و سایر تماس‌گیرندگان API می‌توانند همچنان ببینند که آیا چیزی در یک صفحه ارائه می‌شود و با چه قیمتی.

آیا محدودیت فرکانس در Privacy Sandbox امکان پذیر است؟

مخاطب محافظت شده از محدودیت فرکانس متقابل سایت در همان گروه علاقه از طریق شی prevWinsMs پشتیبانی می کند. generateBid() خریدار در حراج مخاطب محافظت شده می تواند منطقی ایجاد کند که می تواند استراتژی پیشنهاد قیمت را بر اساس نتایج تبلیغات قبلی برای همان مرورگر ایجاد کند.

چند راه حل وجود دارد که می توان برای محدود کردن فرکانس در خارج از مخاطبین محافظت شده استفاده کرد، اما آنها به طور کامل به تکنیک های متقابل سایتی که فناوری های تبلیغاتی با کوکی های شخص ثالث دارند، نگاشت نمی شوند.

• کوکی‌های شخص اول: فناوری‌های تبلیغاتی می‌توانند از داده‌های شخص اول خود برای محدودیت فرکانس در سایت خود استفاده کنند
• چیپ ها : فناوری های تبلیغاتی می توانند محدودیت های فرکانس را در سطح هر سایت با استفاده از یک کوکی پارتیشن بندی شده مدیریت کنند.
• Shared Storage SelectURL() : پس از برنده شدن یک فناوری تبلیغاتی در حراج و قبل از ارائه خلاقیت، آنها می توانند با Storage مشترک تماس بگیرند تا به داده های بین سایتی دسترسی داشته باشند و از طریق گیت خروجی URL انتخاب، خلاقیت مناسب را بر اساس فرکانس انتخاب کنند.

یک راه حل محدود کردن فرکانس مخاطب بدون محافظت از حریم خصوصی که ابزار مفید فناوری تبلیغات را ارائه می دهد به دلایل زیر چالش برانگیز است:

• در حال حاضر بر اساس بازخورد فناوری تبلیغات مشخص نیست که آیا سیگنال فرکانس می تواند نویز را تحمل کند یا خیر.
• ما بازخوردهای فناوری تبلیغاتی ثابتی شنیده‌ایم که سیگنال فرکانس متقاطع باید در طول زمان حراج در دسترس باشد، که نیاز به سیگنال‌های متقاطع بدون نویز برای استفاده در هر حراج تبلیغاتی دارد. این می‌تواند حجم زیادی از اطلاعات مربوط به فعالیت کاربر در سراسر سایت‌ها را نشان دهد و اهداف حریم خصوصی Privacy Sandbox را تضعیف کند.
• ما نسبت به معرفی تأخیر حساس هستیم و راه حلی روی دستگاه که ممکن است این سیگنال را ارائه دهد، می تواند باعث تأخیر شود و محیط حراج را مختل کند.
• راه حل احتمالاً نیاز به یک API جدید است که باید از طریق فرآیند پیشنهاد W3C بگذرد.

به این ترتیب، ایجاد یک راه حل محدودیت فرکانس خارج از مخاطب محافظت شده در نقشه راه فوری ما نیست، اما ما آماده بازخورد در مورد راه های بالقوه برای حل این مورد استفاده هستیم.

در مورد موارد استفاده که تحت پوشش Sandbox حریم خصوصی نیستند، چطور؟

Privacy Sandbox API بلوک‌های ساختمانی کلیدی برای تبلیغات حفظ حریم خصوصی را فراهم می‌کند، جایی که توسعه‌دهندگان انعطاف‌پذیری برای تعیین نحوه چیدمان آنها را دارند. رویکرد بلوک‌های ساختمانی به کسب‌وکارها این امکان را می‌دهد تا راه‌حل‌هایی را نوآوری و توسعه دهند که ارزشی را برای مشتریان خود به ارمغان می‌آورد. هدف Privacy Sandbox این نیست که یک راه حل نهایی برای همه موارد استفاده باشد. ما معتقدیم که این یک نتیجه بد خواهد بود. در عوض، توسعه‌دهندگان و کسب‌وکارها به اجرای ایده‌های خود از طریق انواع فناوری‌ها، از جمله APIهای Privacy Sandbox که در راه‌حل(های) خود ادغام می‌کنند، ادامه خواهند داد.