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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

استقرار ابری

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

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

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

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 موجود در دستگاه مسئول رمزگذاری این داده‌ها است. توصیه می‌شود از یک راه‌حل کارآمد در فضا مانند ارسال درخواست به سرویس Seller Ad به صورت multipart/form-data استفاده شود.

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

با بازگشت پاسخ درخواست به سرویس Seller Ad روی دستگاه، پلتفرم یک 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);

گزارش‌دهی

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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