این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

خدمات مناقصه و مزایده

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

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

Google اجزای B&A را ارائه خواهد کرد و آنها به عنوان منبع باز در دسترس قرار خواهند گرفت. فناوری های تبلیغاتی علاقه مند می توانند نمونه های خود را با ارائه دهندگان ابر عمومی پشتیبانی شده میزبانی کنند. می‌توانید درباره پیشنهاد B&A در GitHub بیشتر بخوانید. توجه داشته باشید که تاریخ‌های ارائه‌شده در آن سند نشان‌دهنده اجرای Chrome است و در آینده اطلاعات بیشتری درباره ادغام با Android منتشر خواهیم کرد. این سند به عنوان مقدمه ای برای B&A عمل می کند و API های جدید Android برای تعامل با B&A ارائه می کند. اطلاعات فنی بیشتری در مورد نحوه استفاده از این APIهای جدید در به روز رسانی های آینده منتشر خواهیم کرد.

جایی که خدمات B&A مناسب است

B&A یک گزینه اضافی برای اجرای یک مزایده در سرورهای مورد اعتماد متعلق به فناوری تبلیغات ارائه می دهد که یک باینری منبع باز ارائه شده توسط Google را اجرا می کنند. داده‌های کاربر همچنان در دستگاه وجود دارد و Google APIهایی را برای انتقال ایمن آن داده‌ها به TEE ارائه می‌کند. اطلاعات بیشتر در مورد استراتژی رمزگذاری ما در زیر.

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

تفاوت عمده در جایی است که منطق تولید URL پیشنهادی، امتیازدهی و گزارش دهی اجرا می شود. به جای اجرای منطق مناقصه، مزایده و گزارش بر روی دستگاه، منطق generateBid() ، scoreAd() ، reportResult() و reportWin() در TEE اجرا می شود. منطق پیشنهاد خریدار و منطق امتیازدهی فروشنده در محیط B&A خودشان، در میانه جریان حراج مخاطب محافظت شده اجرا می‌شوند:

تصویری که جریان حراج مخاطب محافظت شده و جایی که مناقصه و حراج متناسب است را نشان می دهد. — جریان حراج مخاطب حفاظت شده

رمزگذاری داده ها

با B&A، اطلاعات مخاطبان محافظت شده مانند مخاطبان سفارشی و مبالغ پیشنهادی از دستگاه، از طریق سرورهای فناوری آگهی فروشنده، به سرورهای فناوری آگهی خریدار، و دوباره به دستگاه منتقل می‌شوند. به همین دلیل، این پلتفرم داده‌هایی را که به سرویس‌های مخاطب محافظت شده ارسال می‌شوند، رمزگذاری می‌کند و تنها توسط سرویس‌هایی که تأیید شده‌اند می‌توانند رمزگشایی شوند. درباره استراتژی های رمزگذاری در GitHub بیشتر بخوانید.

جریان معماری و حراج

این پیشنهاد شامل نیاز به چندین مؤلفه جدید به تفصیل در GitHub است، از جمله جریان داده از دستگاه به B&A .

تصویری که جریان حراج مخاطبین متنی و حفاظت شده را نشان می دهد، که در ادامه توضیح داده می شود. — جریان حراج مخاطب حفاظت شده و متنی یکپارچه، با خدمات مناقصه و حراج.

در سطح بالا، جریان داده به شرح زیر توصیف می شود:

در دستگاه، فروشندگان با استفاده از getAdSelectionData API اطلاعاتی را از مخاطبان محافظت شده جمع‌آوری می‌کنند.
SDK روی دستگاه درخواستی را به سرویس آگهی فروشنده آن‌ها ارسال می‌کند. این درخواست شامل بار متنی و ProtectedAudienceInput رمزگذاری شده است.
سرویس آگهی فروشنده درخواستی را به سرویس مناقصه بیدرنگ (RTB) خریداران که در خارج از TEE اجرا می‌شود ارسال می‌کند تا تبلیغات متنی نامزد را دریافت کند و سپس یک آگهی متنی برنده را انتخاب کند.
سرویس Seller Ad درخواستی را به سرویس SellerFrontEnd که در TEE اجرا می شود ارسال می کند.
سرویس SellerFrontEnd درخواست هایی را با داده های خاص خریدار به سرویس های BuyerFrontEnd ارسال می کند.
خریداران از خدمات کلید/ارزش و خدمات پیشنهادی خود استفاده می‌کنند که برای همه مخاطبان سفارشی در نظر گرفته شده برای بازاریابی مجدد، پیشنهادهایی را برای نامزدهای تبلیغاتی که از دستگاه تهیه می‌شوند، ایجاد می‌کند.
سرویس SellerFrontEnd از سرویس Key/Value خود می خواند و به تبلیغات نامزد امتیاز می دهد. نتیجه رمزگذاری شده و به سرویس آگهی فروشنده بازگردانده می شود.
سرویس آگهی فروشنده نتیجه برنده رمزگذاری شده و در صورت تمایل یک نتیجه متنی را به SDK روی دستگاه برمی گرداند.
در دستگاه، فروشندگان آگهی برنده را با استفاده از API processAdSelectionResult بازیابی می کنند که پاسخ سرویس آگهی فروشنده را رمزگشایی می کند.

شرح مفصلی از هر مرحله و نحوه رمزگذاری داده ها در GitHub یافت می شود. کد این اجزا از طریق منبع باز در دسترس قرار خواهد گرفت. کد ارائه شده، درخواست‌های سرویس SellerFrontEnd به سرویس‌های BuyerFrontEnd را رسیدگی می‌کند.

استقرار ابر

فناوری های تبلیغاتی خدمات B&A را در یک پلت فرم ابر عمومی پشتیبانی شده مستقر خواهند کرد. این استقرارها باید توسط فناوری‌های تبلیغاتی مدیریت شوند که مسئول تعریف هدف سطح سرویس در دسترس هستند.

حراج اجرا کنید

اولین قدم برای اجرای حراج B&A جمع آوری داده ها از مخاطبان سفارشی روی دستگاه و رمزگذاری آن برای ارسال به مزایده سمت سرور است. برای انجام این کار، از getAdSelectionData API استفاده کنید:

AdSelectionData getAdSelectionData(AdTechIdentifier seller)

روش getAdSelectionData ورودی مورد نیاز برای مؤلفه‌های B&A، مانند BuyerInput و ProtectedAudienceInput را ایجاد می‌کند و داده‌ها را قبل از در دسترس قرار دادن نتیجه در اختیار تماس‌گیرنده رمزگذاری می‌کند. برای جلوگیری از نشت داده ها در بین برنامه ها، این داده ها حاوی اطلاعاتی از همه خریداران حاضر در دستگاه است. اطلاعات بیشتر در مورد این تصمیم را در بخش ملاحظات حریم خصوصی بخوانید.

این API یک شی AdSelectionData را برمی گرداند:

class AdSelectionData {
  long adSelectionId // Unique identifier for the auction.
  byte[] data // Encrypted bytes containing data sourced from
              // on device custom audiences; will
              // be used as the payload to B&A.
}

با استفاده از این AdSelectionData ، SDK روی دستگاه می‌تواند با گنجاندن داده‌ها در یک درخواست POST یا PUT، درخواستی را به سرویس آگهی فروشنده خود ارسال کند:

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
…
})

SDK روی دستگاه مسئول رمزگذاری این داده ها است. توصیه می شود از یک راه حل کارآمد فضا مانند ارسال درخواست به سرویس آگهی فروشنده به عنوان multipart/form-data استفاده کنید.

هنگامی که درخواست شروع شد، سرویس Seller Ad درخواست را به سرویس SellerFrontEnd در حال اجرا در TEE ارسال می کند. هنگام پیکربندی یک سرویس SellerFrontEnd ، فروشندگان فهرستی از آدرس‌های دامنه را ارائه می‌کنند که با سرویس‌های BuyerFrontEnd مطابقت دارد که توسط خریدارانی که فروشنده با آنها شریک است اداره می‌شوند. درخواست‌ها به سرویس‌های مختلف BuyerFrontEnd که فروشنده ارائه کرده است فدرال می‌شود، به طوری که خریداران می‌توانند برای کاندیداهای تبلیغاتی منتخب خود مناقصه ایجاد کنند. برای یک خریدار خاص، B&A فقط اطلاعاتی درباره مخاطبان سفارشی که خریدار دارند ارسال می کند تا هیچ گونه نشت متقابل داده ها بین خریداران وجود نداشته باشد. پس از ایجاد پیشنهادها، لیست تبلیغات نامزد به سرویس SellerFrontEnd باز می گردد که در آن برنده انتخاب می شود. در نهایت، سرویس SellerFrontEnd آگهی برنده رمزگذاری شده را به دستگاه برمی گرداند.

با پاسخ درخواست به سرویس آگهی فروشنده بر روی دستگاه، پلتفرم دومین API جدید را برای رمزگشایی نتیجه و ارائه AdSelectionOutcome ارائه می‌کند، همان شیئی که امروز از یک حراجی در دستگاه بازگردانده می‌شود.

PersistAdSelectionResultRequest {
  AdSelectionId id // Same ID returned from initial getAdSelectionData call.
  AdTechIdentifier seller // Used for enrollment checks.
  byte[] adSelectionionResult // The result of the network call to Seller Ad
                              // service/B&A.
}

persistAdSelectionResult(persistAdSelectionResultRequest);

گزارش

نشانی‌های وب گزارش‌دهی در سرویس‌های B&A ایجاد خواهند شد. پینگ‌های آن نشانی‌های اینترنتی برای گزارش نمایش‌ها و تعاملات برای حراجی‌ها همچنان باید در دستگاه فعال شوند. SDK روی دستگاه همچنان باید APIهای reportImpression() و reportInteraction() با استفاده از AdSelectionId ایجاد شده در جریان B&A فراخوانی کند. بیکن های تولید شده برای گزارش تعامل و URL های مربوطه در پاسخ رمزگذاری شده وجود دارند، بنابراین در طول رمزگشایی پاسخ، رویدادها و نقشه های URL در دستگاه ذخیره می شوند.

ملاحظات حفظ حریم خصوصی

پیشنهاد Browser Bidding & Auction API در GitHub توضیح می دهد که چگونه ملاحظات حریم خصوصی در نظر گرفته شده است. این پیشنهاد از نامگذاری کروم استفاده می کند، اما همان اصول در مورد اندروید نیز صدق می کند.

adSelectionData رمزگذاری شده است تا اطمینان حاصل شود که داده های در حال انتقال فقط برای PPAPI و سرورهای مورد اعتماد قابل دسترسی است. برای کاهش خطر نشت داده به دلیل تغییر اندازه adSelectionData ، ما قصد داریم همان adSelectionData برای همه تماس‌ها با getAdSelectionData API ایجاد کنیم. این بدان معناست که تمام CustomAudience روی دستگاه برای ایجاد adSelectionData استفاده می‌شوند. همچنین قصد داریم تأثیر پارامترهای ورودی GetAdSelectionData بر adSelectionData ایجاد شده را محدود کنیم.

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

ملاحظات اندازه

انتظار می‌رود SDK مشتری فناوری تبلیغات، بایت‌های رمزگذاری‌شده adSelectionData را در فراخوانی برای تبلیغات متنی که به سرور فروشنده ارسال می‌شود، بسته‌بندی کند. برای عملکرد بهینه، بهینه سازی اندازه adSelectionData بدون به خطر انداختن عملکرد مهم است. ما قصد داریم بهینه‌سازی‌هایی را همانطور که در توضیح بهینه‌سازی Payload ذکر شد برای کاهش اندازه adSelectionData معرفی کنیم. این بهینه سازی ها شامل موارد زیر خواهد بود:

افزودن ad_render_id در CustomAudience به طوری که با استفاده از adSelectionData به جای استفاده از URI و ابرداده رندر آگهی ارسال شود. فناوری های تبلیغاتی می توانند با ارسال نکردن داده های تبلیغاتی در adSelectionData این را بیشتر بهینه کنند. این گزینه در نسخه های بعدی در CustomAudience API پشتیبانی خواهد شد.
اطمینان حاصل کنید که user_bidding_signals در adSelectionData ارسال نشده اند. در عوض، فن‌آوران تبلیغات می‌توانند user_bidding_signals از سرور Key/Value خود دریافت کنند.
به خریداران اجازه دهید تا CustomAudience در اولویت قرار دهند.
به خریدار اجازه دهید اولویت فروشنده را مشخص کند.
adSelectionData در چند سطل ثابت ایجاد کنید تا نشت بیت را محدود کنید و در عین حال حجم بار را کاهش دهید.

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

ملاحظات ضد سوء استفاده

همانطور که در ملاحظات حفظ حریم خصوصی ذکر شد، adSelectionData با استفاده از تمام داده‌های خریدار در دستگاه تولید می‌شود.

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

برای مبارزه با سوء استفاده از adSelectionData ، اقدامات زیر را معرفی خواهیم کرد

به CustomAudience اجازه دهید صریحاً فروشندگان تأیید شده و اولویت فروشنده را مشخص کند
به SSP ها اجازه دهید تا به صراحت خریدار، اولویت خریدار، سهمیه هر خریدار را در بار تولید شده مشخص کنند.
مکانیزمی برای SSP ها فراهم کنید تا حداکثر تعداد خریداران در هر تماس یا حداکثر اندازه برای هر خریدار را تعریف کنند.

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

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