با استفاده از Protected Audience API از هدف گیری مخاطبان سفارشی پشتیبانی کنید

به‌روزرسانی‌های اخیر

• اطلاعات مربوط به زمان‌بندی به‌روزرسانی‌های سفارشی مخاطبان اضافه شد
• ادغام گزارش انتساب با مخاطبان محافظت‌شده اضافه شد
• یک جدول زمانی از ویژگی‌های مخاطب محافظت‌شده منتشر کرد.
• FLEDGE به Protected Audience API تغییر نام داده است.
• پیشنهاد برای واگذاری سفارشی مخاطبان اضافه شد.
• الزام ناشناس بودن k برای به‌روزرسانی روزانه URL حذف شد.

مخاطب محافظت‌شده در مرحله بتا است و برای توسعه در دسترس است.

با مخاطب محافظت‌شده، می‌توانید:

• مخاطبان سفارشی را بر اساس اقدامات قبلی کاربر مدیریت کنید.
• حراج‌های روی دستگاه را با پشتیبانی از میانجیگری تک فروشنده یا آبشاری آغاز کنید.
• پس از انتخاب تبلیغ، گزارش نمایش (impression report) را اجرا کنید.

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

گاهشمار

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

نمای کلی

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

امروزه، این موارد استفاده معمولاً با به اشتراک گذاشتن اطلاعات زمینه‌ای در مورد نحوه نمایش تبلیغ (مانند نام برنامه) و اطلاعات خصوصی مانند فهرست مخاطبان با پلتفرم‌های فناوری تبلیغات پیاده‌سازی می‌شوند. با استفاده از این اطلاعات، تبلیغ‌کنندگان می‌توانند تبلیغات مرتبط را در سرورهای خود انتخاب کنند.

رابط برنامه‌نویسی کاربردی (API) مخاطب محافظت‌شده در اندروید (که قبلاً با نام FLEDGE شناخته می‌شد) شامل رابط‌های برنامه‌نویسی کاربردی (API) زیر برای پلتفرم‌های فناوری تبلیغات و تبلیغ‌کنندگان است تا از موارد استفاده رایج مبتنی بر تعامل پشتیبانی کنند، به گونه‌ای که اشتراک‌گذاری شناسه‌ها در برنامه‌ها و اطلاعات تعامل برنامه کاربر با اشخاص ثالث را محدود کند:

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

در سطح بالا، ادغام به شرح زیر عمل می‌کند:

1. SportingGoodsApp می‌خواهد به کاربران خود یادآوری کند که اگر خرید خود را ظرف ۲ روز تکمیل نکرده‌اند، اقلام کالایی باقی‌مانده در سبد خرید خود را خریداری کنند. SportingGoodsApp از API مخاطب سفارشی برای اضافه کردن کاربر به لیست مخاطبان "محصولات در سبد خرید" استفاده می‌کند. این پلتفرم این لیست مخاطبان را در دستگاه مدیریت و ذخیره می‌کند و اشتراک‌گذاری با اشخاص ثالث را محدود می‌کند. SportingGoodsApp با یک پلتفرم فناوری تبلیغات همکاری می‌کند تا تبلیغات خود را به کاربران در لیست مخاطبان خود نشان دهد. پلتفرم فناوری تبلیغات، ابرداده‌های لیست مخاطبان را مدیریت می‌کند و تبلیغات کاندید را ارائه می‌دهد که برای بررسی در اختیار گردش کار انتخاب تبلیغات قرار می‌گیرد. این پلتفرم را می‌توان طوری پیکربندی کرد که به صورت دوره‌ای تبلیغات به‌روز شده مبتنی بر مخاطب را در پس‌زمینه دریافت کند . این امر به تازه نگه داشتن لیست تبلیغات کاندید مبتنی بر مخاطب و عدم ارتباط آن با درخواست‌های ارسال شده به سرورهای تبلیغاتی شخص ثالث در طول فرصت تبلیغ (یعنی درخواست تبلیغات زمینه‌ای) کمک می‌کند.

2. وقتی کاربر FrisbeeGame را در همان دستگاه بازی می‌کند، ممکن است تبلیغی را ببیند که به او یادآوری می‌کند خرید اقلام باقی‌مانده در سبد خرید SportingGoodsApp را تکمیل کند. این امر می‌تواند توسط FrisbeeGame (با یک SDK تبلیغات یکپارچه) با فراخوانی API انتخاب تبلیغ برای انتخاب یک تبلیغ برنده برای کاربر بر اساس هر لیست مخاطبی که ممکن است بخشی از آن باشد (در این مثال، مخاطب سفارشی "محصولات در سبد خرید" که توسط SportingGoodsApp ایجاد شده است) محقق شود. گردش کار انتخاب تبلیغ را می‌توان طوری تنظیم کرد که تبلیغات بازیابی شده از سرورهای پلتفرم‌های فناوری تبلیغات را علاوه بر تبلیغات روی دستگاه مرتبط با مخاطبان سفارشی و همچنین سایر سیگنال‌های روی دستگاه در نظر بگیرد. گردش کار همچنین می‌تواند توسط پلتفرم فناوری تبلیغات و SDK تبلیغات با منطق پیشنهاد قیمت و امتیازدهی سفارشی برای دستیابی به اهداف تبلیغاتی مناسب سفارشی شود. این رویکرد به داده‌های مربوط به علایق کاربر یا تعاملات برنامه اجازه می‌دهد تا در انتخاب تبلیغات تأثیرگذار باشند، در حالی که اشتراک‌گذاری این داده‌ها با اشخاص ثالث را محدود می‌کند.

3. SDK اپلیکیشن نمایش تبلیغات یا پلتفرم فناوری تبلیغات، تبلیغ انتخاب‌شده را رندر می‌کند.

4. این پلتفرم ، گزارش‌دهی نمایش‌ها و نتایج انتخاب تبلیغات را تسهیل می‌کند. این قابلیت گزارش‌دهی مکمل API گزارش‌دهی نسبت‌دهی است. پلتفرم‌های فناوری تبلیغات می‌توانند بر اساس نیازهای گزارش‌دهی خود، سفارشی‌سازی کنند.

دسترسی به مخاطبان محافظت‌شده در APIهای اندروید

پلتفرم‌های فناوری تبلیغات برای دسترسی به API مخاطبان محافظت‌شده باید ثبت‌نام کنند. برای اطلاعات بیشتر به بخش ثبت‌نام برای حساب کاربری Privacy Sandbox مراجعه کنید.

مدیریت مخاطبان سفارشی

مخاطبان سفارشی

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

یک برنامه تبلیغ‌کننده یا SDK یکپارچه ممکن است بر اساس، مثلاً میزان مشارکت کاربر در یک برنامه، به یک مخاطب سفارشی بپیوندد یا آن را ترک کند .

فراداده‌های سفارشی مخاطبان

هر مخاطب سفارشی شامل فراداده‌های زیر است:

• مالک: نام بسته برنامه مالک. این به طور ضمنی روی نام بسته برنامه فراخواننده تنظیم شده است.
• خریدار: شبکه تبلیغاتی خریدار که تبلیغات را برای این مخاطب سفارشی مدیریت می‌کند. خریدار همچنین نماینده طرفی است که ممکن است به مخاطب سفارشی دسترسی داشته باشد و اطلاعات مربوط به تبلیغات را دریافت کند. خریدار با فرمت eTLD+1 مشخص می‌شود.
• نام: یک نام یا شناسه دلخواه برای مخاطبان سفارشی، مانند کاربری که «سبد خرید را رها می‌کند» دارد. این ویژگی می‌تواند به عنوان مثال، یکی از معیارهای هدف‌گیری در کمپین‌های تبلیغاتی تبلیغ‌کننده یا یک رشته پرس‌وجو در URL برای دریافت کد پیشنهاد قیمت استفاده شود.
• زمان فعال‌سازی و زمان انقضا: این فیلدها بازه زمانی را تعریف می‌کنند که این مخاطب سفارشی در آن فعال خواهد شد. پلتفرم از این اطلاعات برای لغو عضویت از یک مخاطب سفارشی استفاده می‌کند. زمان انقضا نمی‌تواند از حداکثر مدت زمانی که برای محدود کردن طول عمر یک مخاطب سفارشی تعیین شده است، تجاوز کند.
• URL به‌روزرسانی روزانه: URL ای که پلتفرم برای دریافت مکرر تبلیغات کاندیدا و سایر فراداده‌های تعریف شده در فیلدهای «سیگنال‌های پیشنهاد قیمت کاربر» و «سیگنال‌های پیشنهاد قیمت معتبر» استفاده می‌کند. برای جزئیات بیشتر، به بخش نحوه دریافت تبلیغات کاندیدا برای مخاطبان سفارشی مراجعه کنید.
• سیگنال‌های پیشنهاد قیمت کاربر: سیگنال‌های مخصوص پلتفرم فناوری تبلیغات برای هرگونه پیشنهاد قیمت تبلیغات ریمارکتینگ. نمونه‌هایی از سیگنال‌ها عبارتند از: موقعیت مکانی تقریبی یا محل ترجیحی کاربر.
• داده‌های مناقصه‌ی قابل اعتماد: پلتفرم‌های فناوری تبلیغات برای اطلاع‌رسانی در مورد بازیابی و امتیازدهی تبلیغات به داده‌های بلادرنگ متکی هستند. به عنوان مثال، ممکن است بودجه‌ی یک تبلیغ تمام شود و لازم باشد نمایش آن فوراً متوقف شود. یک تکنسین تبلیغات می‌تواند یک نقطه‌ی پایانی URL را تعریف کند که از آنجا می‌توان این داده‌های بلادرنگ را دریافت کرد و مجموعه‌ای از کلیدهایی را که باید جستجوی بلادرنگ برای آنها انجام شود، تعیین کند. سروری که این درخواست را مدیریت می‌کند، یک سرور قابل اعتماد خواهد بود که توسط پلتفرم فناوری تبلیغات مدیریت می‌شود.
• URL منطق پیشنهاد قیمت: URL ای که پلتفرم برای دریافت کد پیشنهاد قیمت از پلتفرم سمت تقاضا استفاده می‌کند. پلتفرم این مرحله را هنگام شروع حراج آگهی انجام می‌دهد.
• تبلیغات: فهرستی از تبلیغات کاندید برای مخاطبان سفارشی. این شامل فراداده‌های تبلیغاتی مخصوص پلتفرم فناوری تبلیغات و یک URL برای نمایش تبلیغ می‌شود. هنگامی که یک مزایده برای مخاطبان سفارشی آغاز می‌شود، این فهرست از فراداده‌های تبلیغاتی در نظر گرفته می‌شود. این فهرست از تبلیغات در صورت امکان با استفاده از نقطه پایانی به‌روزرسانی روزانه URL به‌روزرسانی می‌شود. با توجه به محدودیت‌های منابع در دستگاه‌های تلفن همراه، محدودیتی در تعداد تبلیغاتی که می‌توان در یک مخاطب سفارشی ذخیره کرد، وجود دارد.

واگذاری سفارشی مخاطبان

رویکرد تثبیت‌شده برای تعریف و پیکربندی مخاطبان سفارشی معمولاً به فناوری‌ها و ادغام‌های سمت سرور متکی است که توسط تکنسین‌های تبلیغات با همکاری مشتریان و شرکای آژانس‌ها و تبلیغ‌کنندگان هدایت می‌شود. API مخاطب محافظت‌شده، تعریف و پیکربندی مخاطب سفارشی را در عین محافظت از حریم خصوصی کاربر امکان‌پذیر می‌کند. برای پیوستن به یک مخاطب سفارشی، تکنسین‌های تبلیغات خریدار که در برنامه‌ها حضور SDK ندارند، باید با تکنسین‌های تبلیغاتی که حضور روی دستگاه دارند، مانند شرکای اندازه‌گیری موبایل (MMPs) و پلتفرم‌های سمت عرضه (SSPs) همکاری کنند. API مخاطب محافظت‌شده با ارائه راه‌حل‌های انعطاف‌پذیر برای مدیریت مخاطبان سفارشی، از طریق فعال کردن تماس‌گیرندگان روی دستگاه برای فراخوانی ایجاد مخاطب سفارشی از طرف خریداران، از این SDKها پشتیبانی می‌کند. این فرآیند، واگذاری مخاطب سفارشی نامیده می‌شود. واگذاری مخاطب سفارشی را با دنبال کردن این مراحل پیکربندی کنید:

به مخاطبان سفارشی بپیوندید

پیوستن به مخاطبان سفارشی می‌تواند به دو صورت انجام شود:

joinCustomAudience()

یک برنامه یا SDK می‌تواند با فراخوانی تابع joinCustomAudience() پس از نمونه‌سازی شیء CustomAudience با پارامترهای مورد انتظار، درخواست پیوستن به یک مخاطب سفارشی را بدهد. در اینجا یک مثال از قطعه کد توضیحی آورده شده است:

CustomAudience audience = new CustomAudience(
    Buyer = "example-dsp.com",
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    DailyUpdateURL = Uri.parse("https://..."),
    UserBiddingSignals = new JSONObject("{...}"),
    TrustedBiddingURL = Uri.parse("https://..."),
    TrustedBiddingKeys = {'key1","key2", ...,"key n"},
    BiddingLogicURL =  Uri.parse("https://..."),
    Ads = [new AdData(renderUrl = Uri.parse("https://..."),
           metadata = new JSONObject("{...}"), ...];

// Invoke ad services API to join a custom audience.
joinCustomAudience(audience);

fetchAndJoinCustomAudience()

یک برنامه یا SDK می‌تواند از طرف یک تکنسین تبلیغات که حضور روی دستگاه ندارد، با فراخوانی تابع fetchAndJoinCustomAudience() با پارامترهای مورد انتظار، مانند مثال زیر، درخواست پیوستن به یک مخاطب سفارشی را بدهد:

FetchAndJoinCustomAudienceRequest fetchRequest = new FetchAndJoinCustomAudienceRequest(
    // Example: Optional verification token passed inside the fetch URL
    FetchURI = Uri.parse("https://example-dsp.com/...?mytoken=arbitrary1234"),
    // All the following parameters are optional
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    UserBiddingSignals = new JSONObject("{...}")
);

fetchAndJoinCustomAudience(fetchRequest);

نقطه پایانی URL که متعلق به خریدار است، با یک شیء CustomAudience JSON در بدنه پاسخ پاسخ می‌دهد. فیلدهای خریدار و مالک مخاطب سفارشی نادیده گرفته می‌شوند (و توسط API به صورت خودکار پر می‌شوند). API همچنین تضمین می‌کند که URL به‌روزرسانی روزانه با eTLD+1 خریدار نیز مطابقت داشته باشد.

{
 "name": "running-shoes",
 "activation_time": 1680603133000,
 "expiration_time": 1680803133000,
 "user_bidding_signals" : {"signal1": "value"},
 "trusted_bidding_data": {
    "trusted_bidding_uri": "https://example-dsp.com/.."
    "trusted_bidding_keys": ["k1", "k2"],
 },
 "bidding_logic_uri": "https://example-dsp.com/...",
 "daily_update_uri": "https://example-dsp.com/...",
 "ads": [
   {
     "render_uri": "https://example-dsp.com/...",
     "metadata": {},
     "ad_filters": {
       "frequency_cap": {
         "win": [
           {
             "ad_counter_key": 1,
             "max_count": 2,
             "interval_in_seconds": 60
           },
         ],
         "view": [
           {
             "ad_counter_key": 2,
             "max_count": 10,
             "interval_in_seconds": 3600
           },
         ]
       },
       "app_install": {
         "package_names": [
           "package.name.one",
           "package.name.two", ...
         ]
       }
     }
   },
   ...
 ]
}

API fetchAndJoinCustomAudience() هویت خریدار را از eTLD+1 مربوط به fetchUri تعیین می‌کند. هویت خریدار CustomAudience برای انجام همان بررسی‌های ثبت‌نام و مجوز برنامه که توسط joinCustomAudience() انجام می‌شود، استفاده می‌شود و نمی‌تواند توسط پاسخ fetch تغییر یابد. مالک CustomAudience نام بسته برنامه فراخوانی شده است. هیچ اعتبارسنجی دیگری برای fetchUri به غیر از بررسی eTLD+1 وجود ندارد، و به طور خاص، هیچ بررسی k-anon وجود ندارد. API fetchAndJoinCustomAudience() یک درخواست HTTP GET به fetchUri ارسال می‌کند و انتظار دارد یک شیء JSON که نشان‌دهنده مخاطب سفارشی است، دریافت کند. همان محدودیت‌های اجباری، اختیاری و مقادیر پیش‌فرض برای فیلدهای شیء مخاطب سفارشی برای پاسخ اعمال می‌شود. برای کسب اطلاعات بیشتر در مورد الزامات و محدودیت‌های فعلی، به راهنمای توسعه‌دهندگان ما مراجعه کنید.

هرگونه پاسخ خطای HTTP از خریدار باعث عدم موفقیت fetchAndJoinCustomAudience می‌شود. به طور خاص، یک پاسخ وضعیت HTTP با کد ۴۲۹ (درخواست‌های بسیار زیاد) درخواست‌های برنامه فعلی را برای مدت زمان مشخصی مسدود می‌کند. در صورت ناقص بودن پاسخ خریدار، فراخوانی API نیز با شکست مواجه می‌شود. شکست‌ها به فراخوانی‌کننده API که مسئول تلاش مجدد به دلیل خرابی‌های موقت (مانند عدم پاسخگویی سرور) یا مدیریت خرابی‌های مداوم (مانند خرابی‌های اعتبارسنجی داده‌ها یا سایر خطاهای غیرگذرا در ارتباط با سرور) است، گزارش می‌شوند.

شیء CustomAudienceFetchRequest به فراخوانی‌کننده API اجازه می‌دهد تا با استفاده از ویژگی‌های اختیاری نشان داده شده در مثال، برخی اطلاعات را برای مخاطب سفارشی تعریف کند. در صورت تنظیم در درخواست، این مقادیر نمی‌توانند توسط پاسخ خریدار دریافت شده توسط پلتفرم بازنویسی شوند؛ API مخاطب محافظت‌شده فیلدهای موجود در پاسخ را نادیده می‌گیرد. اگر آنها در درخواست تنظیم نشده باشند، باید در پاسخ تنظیم شوند، زیرا این فیلدها برای ایجاد یک مخاطب سفارشی مورد نیاز هستند. یک نمایش JSON از محتوای مخاطب CustomAudience که تا حدی توسط فراخوانی‌کننده API تعریف شده است، در درخواست GET برای fetchUri در یک هدر ویژه X-CUSTOM-AUDIENCE-DATA گنجانده شده است. اندازه فرم سریالی داده‌های مشخص شده برای مخاطب سفارشی به 8 کیلوبایت محدود می‌شود. اگر اندازه از این مقدار تجاوز کند، فراخوانی API fetchAndJoinCustomAudience با شکست مواجه می‌شود.

فقدان بررسی k-anon به شما امکان می‌دهد fetchUri برای تأیید خریدار و فعال کردن اشتراک‌گذاری اطلاعات بین خریدار و SDK استفاده کنید. برای تسهیل تأیید مخاطبان سفارشی، خریدار می‌تواند یک توکن تأیید ارائه دهد. SDK روی دستگاه باید این توکن را در fetchUri بگنجاند تا نقطه پایانی میزبان خریدار بتواند محتوای مخاطبان سفارشی را دریافت کند و از توکن تأیید برای تأیید اینکه عملیات fetchAndJoinCustomAudience() مربوط به خریدار است و از یک شریک قابل اعتماد روی دستگاه سرچشمه گرفته است، استفاده کند. برای به اشتراک گذاشتن اطلاعات، خریدار می‌تواند با تماس‌گیرنده روی دستگاه توافق کند که برخی از اطلاعاتی که قرار است برای ایجاد مخاطبان سفارشی استفاده شود، به عنوان پارامترهای پرس‌وجو به fetchUri اضافه شود. این به خریدار اجازه می‌دهد تا تماس‌ها را بررسی کند و تشخیص دهد که آیا یک توکن اعتبارسنجی توسط یک فناوری تبلیغاتی مخرب برای ایجاد چندین مخاطب سفارشی مختلف استفاده شده است یا خیر.

نکته‌ای در مورد تعریف و ذخیره‌سازی توکن تأیید

• توکن تأیید به هیچ وجه توسط API مخاطب محافظت‌شده استفاده نمی‌شود و اختیاری است.

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

مخاطب سفارشی بگذارید

مالک یک مخاطب سفارشی می‌تواند با فراخوانی تابع leaveCustomAudience() ‎، همانطور که در این قطعه کد توضیحی نشان داده شده است، تصمیم به ترک مخاطب بگیرد:

// Invoke ad services API to leave a custom audience.
leaveCustomAudience(buyer, name);

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

کنترل کاربر

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

طراحی این قابلیت در حال انجام است و جزئیات آن در به‌روزرسانی‌های بعدی ارائه خواهد شد.

به‌روزرسانی‌های زمان‌بندی‌شده

راه‌حل‌هایی که قبلاً توضیح داده شدند، مستلزم آن هستند که برنامه یا SDK فناوری تبلیغات، APIها را در حالی که برنامه در پیش‌زمینه است، فراخوانی کند و ویژگی‌های کامل مخاطبان سفارشی را، چه مستقیماً و چه با استفاده از واگذاری اختیار، ارائه دهد. با این حال، همیشه برای تبلیغ‌کنندگان و ارائه‌دهندگان فناوری تبلیغات امکان‌پذیر نیست که هنگام استفاده از برنامه، مخاطبانی را که کاربر به آنها تعلق دارد، به صورت بلادرنگ تعریف کنند.

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

/**
* API To schedule delayed update events for Custom Audience
*
* @param request Criteria that determine when and where to trigger a call to a
* DSP endpoint to update one or more Custom Audiences
*/

public void scheduleCustomAudienceUpdate(
    @NonNull ScheduleCustomAudienceUpdateRequest request,
    @NonNull @CallBackExecutor Executor executor,
    @NonNull AdServicesOutcomeReceiver<Object, Exception> receiver)

درخواست به‌روزرسانی مخاطب سفارشی زمان‌بندی‌شده

public final class ScheduleCustomAudienceUpdateRequest {
  // Required Field
  @NonNull public Uri getUpdateUri() {
    return mUpdateUri;
  }

  // Required Field
  @NonNull public Duration getMinDelay() {
    return mMinDelay;
  }

  //  Required Field
  @NonNull public List<PartialCustomAudience> getPartialCustomAudienceList() {
    return mPartialCustomAudiences;
  }

  //  Optional Field (default false)
  public boolean shouldReplacePendingUpdates () {
    return mShouldReplacePendingUpdates;
  }
}

ScheduleCustomAudienceUpdateRequest شامل اطلاعات لازم برای ثبت یک کار با تأخیر برای اجرا در پلتفرم است. پس از تأخیر مشخص شده، یک کار پس‌زمینه به صورت دوره‌ای اجرا می‌شود و درخواست(ها) را ارسال می‌کند. ScheduleCustomAudienceUpdateRequest می‌تواند شامل اطلاعات زیر باشد:

• UpdateUri : نقطه پایانی URI که برای دریافت به‌روزرسانی، یک فراخوانی GET به آن ارسال می‌شود. هویت خریدار ذاتاً از eTLD+1 استنباط می‌شود و نیازی به ارائه صریح آن نیست و نمی‌تواند توسط پاسخ به‌روزرسانی تغییر کند. درخواست GET در پاسخ، انتظار یک شیء JSON حاوی لیستی از اشیاء customAudience را دارد.
• DelayTime : زمان نشان دهنده تأخیر از زمان فراخوانی API مربوط به scheduleCustomAudienceUpdate() برای زمان‌بندی به‌روزرسانی.

• PartialCustomAudience : این API همچنین به SDK روی دستگاه اجازه می‌دهد تا فهرستی از مخاطبان سفارشیِ تا حدی ساخته‌شده را ارسال کند. این امر به SDKهای درون‌برنامه‌ای اجازه می‌دهد تا نقش دوگانه‌ای را ایفا کنند، از کنترل کامل تا جزئی بر مدیریت مخاطبان سفارشی بر اساس همکاری آنها با DSPها.

  • این امر همچنین این API را با API مربوط به fetchAndJoinCustomAudience() که امکان اشتراک‌گذاری اطلاعات مشابه را فراهم می‌کند، سازگار نگه می‌دارد.

• ShouldReplacePendingUpdates : مقدار بولی که تعیین می‌کند آیا به‌روزرسانی‌های زمان‌بندی‌شده‌ی در انتظار باید لغو و با به‌روزرسانی‌ای که جزئیات آن در ScheduleCustomAudienceUpdateRequest فعلی آمده است، جایگزین شوند یا خیر. اگر این مقدار روی false تنظیم شود و به‌روزرسانی‌های درخواست‌شده‌ی قبلی هنوز برای همان خریدار در همان برنامه در انتظار باشند، فراخوانی scheduleCustomAudienceUpdate با این ScheduleCustomAudienceUpdateRequest با شکست مواجه خواهد شد. مقدار پیش‌فرض روی false است.

مجوزها و کنترل برنامه

این پیشنهاد قصد دارد به برنامه‌ها امکان کنترل بر مخاطبان سفارشی خود را بدهد:

• یک اپلیکیشن می‌تواند ارتباط خود را با مخاطبان سفارشی مدیریت کند.
• یک برنامه می‌تواند به پلتفرم‌های فناوری تبلیغات شخص ثالث مجوزهایی برای مدیریت مخاطبان سفارشی از طرف خود اعطا کند.

طراحی این قابلیت در حال انجام است و جزئیات آن در به‌روزرسانی‌های بعدی ارائه خواهد شد.

کنترل پلتفرم فناوری تبلیغات

این پیشنهاد، راه‌هایی را برای کنترل مخاطبان سفارشی توسط شرکت‌های تبلیغاتی تشریح می‌کند:

• تکنسین‌های تبلیغات در Privacy Sandbox ثبت‌نام می‌کنند و یک دامنه eTLD+1 ارائه می‌دهند که با تمام URLها برای مخاطبان سفارشی مطابقت دارد.
• تکنسین‌های تبلیغات می‌توانند با برنامه‌ها یا SDKها همکاری کنند تا توکن‌های تأییدی را که برای تأیید ایجاد مخاطب سفارشی استفاده می‌شوند، ارائه دهند. هنگامی که این فرآیند به یک شریک واگذار می‌شود، ایجاد مخاطب سفارشی می‌تواند طوری پیکربندی شود که نیاز به تأیید توسط تکنسین تبلیغات داشته باشد.
• یک تکنسین تبلیغات می‌تواند فراخوانی‌های joinCustomAudience را از طرف خود غیرفعال کند و فقط به API مربوط به fetchAndJoinCustomAudience اجازه دهد تا همه مخاطبان سفارشی تماس را فعال کند. این کنترل می‌تواند در طول ثبت‌نام در Privacy Sandbox به‌روزرسانی شود. توجه داشته باشید که این کنترل یا به همه تکنسین‌های تبلیغات اجازه می‌دهد یا به هیچ کدام. به دلیل محدودیت‌های پلتفرم، مجوزهای تفویض اختیار نمی‌توانند بر اساس هر تکنسین تبلیغات باشند.

تبلیغات کاندیداها و پاسخ فراداده

تبلیغات و فراداده‌های کاندیدا که از یک پلتفرم خرید-محور برگردانده می‌شوند، باید شامل فیلدهای زیر باشند:

• فراداده: فراداده‌های تبلیغاتی مختص فناوری تبلیغاتی و سمت خریدار. به عنوان مثال، این ممکن است شامل اطلاعاتی در مورد کمپین تبلیغاتی و معیارهای هدف‌گذاری مانند مکان و زبان باشد.
• رندر URL: نقطه پایانی برای رندر کردن تبلیغ خلاقانه.
• فیلتر: اطلاعات اختیاری لازم برای API مخاطب محافظت‌شده جهت فیلتر کردن تبلیغات بر اساس داده‌های روی دستگاه. برای جزئیات بیشتر، بخش منطق فیلترینگ جانبی خرید را مطالعه کنید.

گردش کار انتخاب تبلیغ

این پیشنهاد با معرفی رابط برنامه‌نویسی کاربردی انتخاب تبلیغات (Ad Selection API) که اجرای مزایده را برای پلتفرم‌های فناوری تبلیغات هماهنگ می‌کند، قصد دارد حریم خصوصی را بهبود بخشد.

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

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

این رویکرد، داده‌های تعاملات برنامه کاربر را قادر می‌سازد تا در انتخاب تبلیغات مؤثر باشند، در حالی که اشتراک‌گذاری این داده‌ها با اشخاص ثالث را محدود می‌کند.

این گردش کار انتخاب تبلیغ، اجرای کد جاوا اسکریپت ارائه شده توسط فناوری تبلیغات را بر اساس توالی زیر بر روی دستگاه هماهنگ می‌کند:

1. اجرای منطق مناقصه سمت خرید
2. فیلتر و پردازش تبلیغات سمت خریدار
3. اجرای منطق تصمیم‌گیری سمت فروش

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

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

شروع گردش کار انتخاب تبلیغ

وقتی یک برنامه نیاز به نمایش تبلیغ دارد، SDK پلتفرم فناوری تبلیغات می‌تواند پس از نمونه‌سازی شیء AdSelectionConfig با پارامترهای مورد انتظار، گردش کار انتخاب تبلیغ را با فراخوانی متد selectAds() آغاز کند:

• فروشنده : شناسه پلتفرم تبلیغاتی سمت فروش، مطابق با فرمت eTLD+1
• آدرس اینترنتی منطق تصمیم‌گیری : وقتی یک مزایده‌ی آگهی آغاز می‌شود، پلتفرم از این آدرس اینترنتی برای دریافت کد جاوا اسکریپت از پلتفرم فروش استفاده می‌کند تا یک آگهی برنده را امتیازدهی کند.
• خریداران مخاطب سفارشی : فهرستی از پلتفرم‌های خرید با تقاضای مبتنی بر مخاطب سفارشی برای این حراج، مطابق با فرمت eTLD+1.
• سیگنال‌های انتخاب تبلیغ : اطلاعات مربوط به حراج (اندازه تبلیغ، قالب تبلیغ و غیره).
• سیگنال‌های فروشنده : سیگنال‌های خاص پلتفرم سمت عرضه.
• آدرس اینترنتی سیگنال‌های امتیازدهی معتبر : نقطه پایانی آدرس اینترنتی سیگنال معتبر سمت فروش که اطلاعات خلاقانه و خاص بلادرنگ را می‌توان از آن دریافت کرد.
• سیگنال‌های مربوط به هر خریدار : طرف‌های تقاضای شرکت‌کننده ممکن است از این پارامتر برای ارائه ورودی‌های حراج استفاده کنند. به عنوان مثال، این پارامتر ممکن است شامل اطلاعات زمینه‌ای جامعی باشد که برای تعیین پیشنهادات مفید است.

قطعه کد توضیحی زیر، SDK یک پلتفرم فناوری تبلیغات را نشان می‌دهد که گردش کار انتخاب تبلیغ را با تعریف اولیه AdSelectionConfig و سپس فراخوانی selectAds برای دریافت تبلیغ برنده، آغاز می‌کند:

AdSelectionConfig myAdSelectionConfig = new AdSelectionConfig {
    Seller = "example-ssp1.com",
    DecisionLogicURL = Uri.parse("https://..."),
    CustomAudienceBuyerList = Arrays.asList("example-dsp1.com","bexample-dsp2.com"),
    AdSelectionSignals = "{"min_price": 10,"auction_attempts": 3}"
    SellerSignals = "{"seller_type": "news", "content_category": "sports","mature_ads_accepted" :"false"}"
    PerBuyerSignals = " {"buyer1Name": {"key1" : "value1"},
                         "buyer2Name": {"key1" : "value1", "key2" : "value2" }"
};

// Invoke ad services API to initiate ad selection workflow.
Ad winningAd = selectAds(myAdSelectionConfig);

منطق پیشنهاد قیمت سمت خرید

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

این پلتفرم از فراداده‌ی «URL منطق پیشنهاد قیمت» مخاطب سفارشی برای دریافت کد جاوا اسکریپت استفاده می‌کند که باید شامل امضای تابع زیر باشد:

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ...};
}

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

این تابع پارامترهای زیر را دریافت می‌کند:

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

هزینه تبلیغات

علاوه بر پیشنهاد قیمت، پلتفرم‌های خرید-محور این امکان را دارند که هزینه هر کلیک را به عنوان بخشی از generateBid() برگردانند. برای مثال:

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ..., 'adCost': ...,};
}

اگر این تبلیغ برنده شود، adCost به صورت تصادفی برای حفظ حریم خصوصی به ۸ بیت گرد می‌شود. سپس مقدار گرد شده adCost در طول گزارش نمایش به پارامتر contextual_signals در reportWin ارسال می‌شود.

منطق فیلترینگ سمت خرید

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

منطق فیلترینگ سمت خرید می‌تواند به عنوان بخشی از منطق پیشنهاد قیمت با برگرداندن مقدار پیشنهاد 0 برای یک تبلیغ مشخص پیاده‌سازی شود.

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

منطق امتیازدهی سمت فروش

منطق امتیازدهی معمولاً توسط پلتفرم سمت فروش ارائه می‌شود. هدف از این کد، تعیین یک تبلیغ برنده بر اساس خروجی‌های منطق پیشنهاد قیمت است. ممکن است منطق تجاری اضافی برای تعیین نتیجه اعمال شود. اگر چندین ارائه‌دهنده منطق تصمیم‌گیری وجود داشته باشد، سیستم توالی اجرا بین ارائه‌دهندگان را تضمین نمی‌کند. پلتفرم از پارامتر ورودی "URL منطق تصمیم‌گیری" از API selectAds() برای دریافت کد جاوا اسکریپت استفاده می‌کند که باید شامل امضای تابع زیر باشد:

scoreAd(ad, bid, auction_config, trusted_scoring_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return score_for_this_ad;
}

این تابع پارامترهای زیر را دریافت می‌کند:

• Ad : تبلیغی که ارزیابی می‌شود؛ خروجی از تابع generateBid() .
• Bid : خروجی مقدار پیشنهادی از تابع generateBid() .
• پیکربندی حراج : پارامتر ورودی به متد selectAds() .
• سیگنال‌های امتیازدهی معتبر : پلتفرم‌های فناوری تبلیغات برای فیلتر کردن و امتیازدهی تبلیغات به داده‌های بلادرنگ متکی هستند. به عنوان مثال، یک ناشر برنامه ممکن است نمایش تبلیغات یک کمپین تبلیغاتی را در برنامه مسدود کند. این داده‌ها از پارامتر URL سیگنال‌های امتیازدهی معتبر در پیکربندی حراج گرفته می‌شوند. سروری که این درخواست را ارائه می‌دهد باید یک سرور قابل اعتماد تحت مدیریت فناوری تبلیغات باشد.
• سیگنال زمینه‌ای : این ممکن است شامل اطلاعات دقیق زمانی یا موقعیت مکانی باشد.
• سیگنال کاربر : این ممکن است شامل اطلاعاتی مانند فروشگاه برنامه‌ای باشد که نصب برنامه را آغاز کرده است.
• سیگنال مخاطب سفارشی : اگر تبلیغی که امتیازدهی می‌شود از یک مخاطب سفارشی روی دستگاه باشد، این شامل اطلاعاتی مانند خواننده و نام مخاطب سفارشی خواهد بود.

زمان اجرای کد انتخاب تبلیغ

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

• اجرای کد باید در مدت زمان از پیش تعیین‌شده‌ای به پایان برسد. این محدودیت به طور یکسان برای همه شبکه‌های تبلیغاتی خریدار اعمال خواهد شد. جزئیات این محدودیت در به‌روزرسانی بعدی به اشتراک گذاشته خواهد شد.
• کد باید مستقل باشد و هیچ وابستگی خارجی نداشته باشد.

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

زبان برنامه‌نویسی

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

رندرینگ تبلیغاتی برنده

تبلیغی که بالاترین امتیاز را داشته باشد، برنده مزایده در نظر گرفته می‌شود. در این پیشنهاد اولیه، تبلیغ برنده برای رندر شدن به SDK منتقل می‌شود.

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

گزارش برداشت‌ها و رویدادها

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

1. گزارش‌دهی سمت فروش.
2. گزارش سمت خرید.

This gives buy-side and sell-side platforms a way to send important on-device information back to the servers to enable capabilities like real time budgeting, bidding model updates, and accurate billing workflows. This impression reporting support is complementary to the Attribution Reporting API .

There are two steps required to support event reporting: Sell-side and buy-side JavaScript needs to register what event it should receive event reports for, and the sell-side is responsible for reporting event-level information.

Protected Audience provides a mechanism to subscribe to future events related to a winning auction by registering beacons. In a seller's reportResult() JavaScript function, sell-side platforms can register beacons using the platform's registerAdBeacon() function. Similarly, buy-side platforms can call the registerAdBeacon() method from their reportWin() JavaScript function.

registerAdBeacon(beacons)

ورودی:

• event_key : A string denoting which interaction type to register for. This is used as a key to look up the endpoint the platform pings while reporting the results of the auction.
• reporting_url : The URL owned by the ad tech platform for handling the event.

Event keys are string identifiers that are owned by the sell-side SDK responsible for reporting the results of the auction. For a callback to be made, ad techs register beacons with keys that match the keys used by the sell-side when reporting the events. These don't need to be k-anonymous, though there are limits to the quantity and length of keys that can be registered for a given custom audience. If reportEvent() is called, sell-side platforms that ran the auction are always eligible to receive these event reports. Only the winning buy-side platform is eligible to receive these reports.

Sell-side reporting

The platform invokes the reportResult() JavaScript function in the supply side-provided code downloaded from the seller's Decision logic URL parameter for the selectAds() API:

reportResult(render_url, bid, auction_config, contextual_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_url": reporting_url,
                  "signals_for_buyer": signals_for_buyer}};
}

Output: A JSON object containing

• Status: 0 for success, any other value for failure.
• Reporting URL: The platform invokes this URL returned from the function.
• Signals for Buyer: A JSON object to be passed to the buyer's reportWin function.

The supply side may encode relevant signals in the reporting URL to help them gain further insights into the auction and winning ad. For example, it may include signals such as these:

• Ad render URL
• Winning bid amount
• نام برنامه
• Query identifiers
• Signals for buyer: To support data sharing between supply side and demand side, the platform passes this return value as an input parameter to demand side reporting code.

Buy-side reporting

The platform invokes the reportWin() JavaScript function in the demand side-provided code downloaded from the Bidding logic URL metadata of the custom audience associated with the auction.

reportWin(render_url, bid, auction_signals, per_buyer_signals,
        signals_for_buyer, contextual_signals, custom_audience_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_uri": reporting_uri}};
}

ورودی:

• auction_signals and per_buyer_signals are fetched from AuctionConfig . Any information that the buy-side platform needs to pass into the reporting URL may come from this datum.
• signals_for_buyer is the output of the sell-side reportResult. This provides the sell-side platform with an opportunity to share data with the buy-side platform for reporting purposes.
• contextual_signals contains information such as app name and custom_audience_signals contains the custom audience information. Other information may be added in the future.

خروجی:

• Status: 0 for success, any other value for failure.
• Reporting URL: The platform invokes this URL returned from the function.

Reporting Events

Reporting events is only possible after impression reporting for the auction has completed. The sell-side SDK is responsible for reporting any events. The platform exposes an API that takes a ReportEventRequest that specifies the recently run auction, the event key that is reported, the data associated with that key, whether the report should be sent to the buyer or the seller (or both), and an optional input event for ad events. The client defines the event key and collection of data to report.

ReportEventRequest request = new ReportEventRequest(
  AdSelectionId = ad_selection_id,
  event_key = "view"
  event_data = "{ "viewTimeInSeconds" :1 }",
  reporting_destinations =
    FLAG_REPORTING_DESTINATION_SELLER |
      FLAG_REPORTING_DESTINATION_BUYER,
  input_event = clickInputEvent // or null for view
  )

reportEvent(request)

ورودی:

• ad_selection_id needs to be an AdSelectionId of a recently run auction retrieved from the AdSelectionOutcome .
• event_key is a sell-side defined string describing the interaction event.
• event_data is a string representing the data associated with the event_key
• reporting_destinations is a bit mask set using flags provided by the platform. It can be one of FLAG_REPORTING_DESTINATION_SELLER or FLAG_REPORTING_DESTINATION_BUYER , or both.
• input_event (optional) is used for integration with Attribution Reporting API. It is either an InputEvent object (for a click event) or null (for a view event). See Attribution Reporting API Integration for more details on this parameter.

After the sell-side SDK invokes reportEvent and, depending on the reporting_destinations flag, the platform attempts to match the event_key to the keys registered by buyers and sellers in their reportWin and reportResult JavaScript functions. If there is a match, the platform POSTs the event_data to the associated reporting_url . The content type of the request is plain text with the body being the event_data . This request is made as best effort and fails silently in the event of a network error, server error response, or if no matching keys were found.

Attribution Reporting API integration

To support buyers who participate in a Protected Audience auction, we are providing cross-API functionality across the Protected Audience and Attribution Reporting APIs (ARA). This functionality enables ad techs to evaluate their attribution performance across various remarketing tactics, so that they can understand which types of audiences deliver the highest ROI.

Through this cross-API integration, adtechs can:

• Create a key-value map of URIs to be used for both 1) ad interaction reporting and 2) source registration.
• Include auction data from the Protected Audience auction in their source-side key mapping for aggregate summary reporting (using the Attribution Reporting API) See the ARA design proposal for more information.

When a user sees or clicks on an ad:

• The URL used to report those events interactions using Protected Audience will provide the necessary data to the buyer to be used to register a view or click as an eligible source with the Attribution Reporting API.
• The ad tech may choose to pass CustomAudience (or other relevant contextual information about the ad such as ad placement or view duration) using that URL so this metadata can propagate down to summary reports when the ad tech is reviewing aggregate campaign performance.

Enabling source registration

reportEvent() will accept a new optional parameter InputEvent . Winning buyers who register ad beacons can choose which reportEvent reports get registered with Attribution Reporting APIs as a registered source. The request header Attribution-Reporting-Eligible will be added to all event reporting requests sent from reportEvent() . Any responses with appropriate ARA headers will be parsed in the same way any other regular ARA source registration response would be. See Attribution Reporting API explainer for how to register a source URL .

Because ARA on Android supports view and click events, InputEvents are used to distinguish between the two types. Just as in ARA source registration, the reportEvent() API will interpret a platform-verified InputEvent as a click event. If the InputEvent is missing, null, or invalid, the source registration will be considered a view.

Note the post-auction eventData may contain sensitive information, so the platform drops the eventData in redirected source registration requests.

Engagement and conversion reporting example

In this example, we'll look at it from the buyer perspective who is interested in associating the data from the auction, rendered ad, and conversion app together.

In this workflow, the buyer coordinates with the seller to send a unique ID into the auction. During the auction, the buyer sends this unique ID with the auction data. During render and conversion time, the data from the rendered ad is also sent out with the same unique ID. Later, the unique ID can be used to associate these reports together.

Workflow: Before the auction starts, the buyer sends a unique ID to the seller as part of their programmatic real-time bidding ("RTB") bid response . The ID can be set as a variable like auctionId . The ID is passed in as perBuyerSignals in the auctionConfig and it becomes available in buyer's bidding logic.

1. During the execution of reportWin , the buyer can register an ad beacon to be triggered during ad render time and for specific interaction events ( registerAdBeacon() ). To associate auction signals for an ad event, set the auctionId as a query param of the beacon URL.
2. During ad render time, the beacons you registered during auction time can be triggered or enhanced with event-level data. The seller must trigger reportEvent() and pass in the event-level data. The platform will ping the buyer's registered ad beacon URL that correlates with the reportEvent() that was triggered.
3. The buyer will register the ad with the Attribution Reporting API by responding to the ad beacon requests with the Attribution-Reporting-Register-Source header. To associate auction signals for a conversion event, set the auctionId in the Register source URL.

At the end of this process, the buyer will have an auction report, interaction report, and conversion report, that can be correlated using the unique ID that can be used to associate with each other.

Similar workflow applies to a seller if it needs access to attribution data, and the seller can also use a unique ID to send with registerAdBeacon() . The reportEvent() call contains a destination property that can be used to send the report to both the buyer and the seller.

Ad tech platform managed trusted server

Ad selection logic today requires real-time information such as budget depletion status to determine if ad candidates should be selected for auction. Both buy-side and sell-side platforms will be able to get this information from servers they operate. In order to minimize leak of any sensitive information using these servers the proposal calls for the following restrictions:

• The behaviors of these servers, described later in this section, wouldn't leak user information.
• The servers wouldn't create pseudonymous profiles based on the data it sees, that is, it will need to be 'trusted'.

Buy side : Once buy side initiates the buy side bidding logic, the platform performs an HTTP fetch of trusted bidding data from the trusted server. The URL is composed by appending the URL and keys present in the Trusted Bidding Signals metadata of the custom audience being processed. This fetch is done only when processing ads from the on device custom audiences. At this stage, buy side can enforce budgets, check for campaign pause / unpause state, perform targeting, etc.

This is a sample URL to fetch trusted bidding data, based on trusted bidding signal metadata from the custom audience:

https://www.kv-server.example/getvalues?keys=key1,key2

The response from the server should be a JSON object whose keys are key1, key2, etc., and whose values will be made available to the buyer's bidding functions.

Sell side : Similar to this buy side flow, sell side may want to fetch information about creatives considered in the auction. For example, a publisher may want to enforce that certain creatives are not shown in their app based on brand safety concerns. This information can be fetched and made available to the sell side auction logic. Similar to the buy side trusted server lookup, sell side trusted server lookup also happens using an HTTP fetch. The URL is composed by appending the Trusted Scoring Signals URL with render URLs of the creatives for which the data needs to be fetched.

Following is a sample URL to fetch information about creatives considered in the auction, based on creative render URLs:

https://www.kv-server.example/getvalues?renderUrls=render_url1,render_url2

Response from the server should be a JSON object whose keys are render URLs sent in the request.

These servers would operate in a trusted way to offer several security and privacy benefits:

• The server's return value for each key can be trusted to be based only on that key.
• The server does not perform event-level logging.
• The server has no other side effects based on these requests.

As a temporary mechanism, the buyer and seller can fetch these bidding signals from any server, including one they operate themselves. However, in the release version, the request will only be sent to a trusted key-value-type server.

Buyers and sellers could use a common trusted key-value-type server for platforms compatible with Privacy Sandbox on Android and for the Web.