API مخاطب محافظت شده (FLEDGE سابق)

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

Chrome در حال اجرای نسخه آزمایشی اولیه برای API مخاطب محافظت شده است. خریداران مجاز واجد شرایط شرکت در آزمایش API مخاطب محافظت شده در موجودی ناشر Ad Manager هستند. مناقصه گران می توانند با آزمایش API مخاطب محافظت شده به موارد زیر دست یابند:

  • تکرار کنید و در مورد کارآمدی جریان های API مخاطب محافظت شده بیاموزید.
  • بازخوردی در مورد بهبودهای بالقوه API در انجمن‌های عمومی ایجاد کنید - به عنوان مثال، GitHub .
  • برای حمایت از تبلیغات شخصی شده از طریق API بدون تکیه بر کوکی های شخص ثالث آماده شوید.

خریداران مجاز که علاقه مند به آزمایش هستند، برای جزئیات بیشتر باید بخش Onboarding را بررسی کنند.

خلاصه جریان خدمت

در اینجا خلاصه‌ای از جریان ارائه تبلیغات مخاطب محافظت‌شده برای شرکای مجاز خریداران آمده است:

Flow diagram

  1. یک پیشنهاد دهنده با تبلیغ کنندگان خود برای حفظ گروه های علاقه برای هر تبلیغ کننده کار می کند. اغلب اوقات، تبلیغ‌کنندگان برچسب پیشنهاد دهنده را به صفحه تبلیغ‌کننده اضافه می‌کنند تا مرورگری را به گروه‌های علاقه‌مند اضافه کنند.
  2. یک کاربر نهایی از صفحه یک تبلیغ کننده بازدید می کند. صفحه ممکن است حاوی برچسب پیشنهاد دهنده باشد.
  3. تگ پیشنهاد دهنده، API مخاطب محافظت شده joinAdInterestGroup() را فراخوانی می کند. این تماس از مرورگر می‌خواهد تا کاربر را به یک گروه علاقه‌مند اضافه کند.
  4. کاربر نهایی از یک صفحه وب ناشر بازدید می کند. مرورگر کاربر برچسب آگهی ناشر گوگل را درخواست می کند.
  5. تگ آگهی ناشر Google یک درخواست آگهی متنی را به سرور Google ارسال می کند.
  6. Google درخواست‌های پیشنهادی متنی را به مناقصه‌گران شرکت‌کننده ارسال می‌کند. برای اطلاعات بیشتر به بخش تغییرات درخواست پیشنهاد مراجعه کنید.
  7. پیشنهاد دهنده یک BidResponse با فیلد interest_group_bidding برمی گرداند. اگر پیشنهاد دهنده interest_group_bidding را مشخص نکند، Google مبدا پیشنهاد دهنده را در interestGroupBuyers در پیکربندی حراج لحاظ نمی کند. پاسخ پیشنهاد همچنین می تواند حاوی interest_group_bidding.per_buyer_signals باشد. per_buyer_signals در طول حراج درون مرورگر به تابع مناقصه‌دهنده منتقل می‌شوند. برای اطلاعات بیشتر به بخش تغییرات پاسخ پیشنهادی مراجعه کنید.
  8. گوگل حراج سمت سرور را اجرا می کند و یک پاسخ پیشنهادی را به مرورگر برمی گرداند. مزایده سمت سرور پیشنهادات سنتی و سمت سرور را در نظر می گیرد. پاسخ پیشنهاد می تواند حاوی اطلاعاتی در مورد یک پیشنهاد برنده متنی (در صورت وجود) باشد.
  9. پاسخ پیشنهادی حاوی یک پیکربندی حراج برای حراج درون مرورگر است. این می‌تواند شامل سیگنال‌های متنی از هر خریدار شرکت‌کننده (که از طریق interest_group_bidding.per_buyer_signals ارسال شده است)، اطلاعات برنده متنی، و تنظیمات واجد شرایط بودن پیشنهاد باشد.
  10. تگ ناشر Google برای شروع حراج گروه ذینفع روی دستگاه، از runAdAuction() API مخاطب محافظت شده فراخوانی می کند. Google فقط خریدارانی را شامل می‌شود که قبلا interest_group_bidding به‌عنوان interestGroupBuyers در پیکربندی حراج برگردانده‌اند.
  11. Google هر یک از per_buyer_signals دهندگان واجد شرایط را به پیکربندی حراج مخاطب محافظت شده ارسال می کند.
  12. اگر گروه‌های ذینفع یک پیشنهاددهنده، trustedBiddingSignalsUrl را مشخص کرده باشند، مرورگر از هر گروه درخواستی برای واکشی سیگنال‌های trustedBiddingSignalsUrl برای هر گروه می‌کند. جزئیات را در مشخصات API مخاطب محافظت شده ببینید.
  13. مرورگر برای هر گروه ذینفعی که در مزایده درون مرورگر شرکت کرده و واجد شرایط شرکت در مزایده درون مرورگر است generateBid() فراخوانی می‌کند. این مرحله قیمت پیشنهادی را محاسبه می کند و یک خلاقیت انتخاب می کند. generateBid() به سیگنال‌های per_buyer_signals ارائه‌شده توسط مناقصه‌دهنده و سیگنال‌های پیشنهادی مورد اعتماد برای گروه ذینفع دسترسی دارد.
  14. مرورگر scoreAd() فروشنده (در این مورد، گوگل) را فراخوانی می‌کند تا رتبه‌ای را به هر پیشنهاد در مزایده آگهی گروه علاقه‌مند اختصاص دهد. پیشنهادها بر اساس محافظت از ناشر، خط‌مشی‌های تبلیغاتی و سایر محدودیت‌ها رتبه‌بندی و فیلتر می‌شوند.
  15. مرورگر حراجی را با پیشنهادهای گروه ذینفع واجد شرایط اجرا می کند. پیشنهاد متنی با رتبه برتر در مزایده درون مرورگر شرکت می کند.
  16. پس از حراج، اگر برنده گروه ذینفعی وجود داشته باشد، مرورگر reportResult() و پیشنهاد دهنده reportWin() را فراخوانی می کند تا به هر یک از طرفین در مورد برنده مزایده درون مرورگر اطلاع دهد.
  17. اگر تبلیغ گروه علاقه‌مندی برنده شود، برچسب ناشر Google آگهی را در یک iframe نمایش می‌دهد.

جزئیات جریان ارائه خدمات

قبل از ارائه آگهی

بررسی خلاقانه

قبل از اینکه خلاقیت‌ها از حراج‌های «مخاطب محافظت‌شده در مرورگر» ارائه شوند، باید توسط Google بررسی و تأیید شوند. می‌توانید خلاقیت‌ها را از طریق API Bidding Real-time یا از طریق اسکن خودکار خلاقیت برای بررسی ارسال کنید. حراج‌های آگهی‌های گروه‌های علاقه‌مندی درون مرورگر، Creatives for Protected Audience باید دارای renderUrls برای بررسی باشند.

شرایط مورد نیاز برای renderUrls :

  • renderUrl ارسال شده از طریق API باید با renderUrl مورد استفاده در حراج آگهی گروه علاقه مطابقت داشته باشد.
  • هر renderUrl ممکن است فقط یک تبلیغ کننده یا کمپین تبلیغاتی را نشان دهد. یک renderUrl داده شده نمی تواند برای ارائه تبلیغات از طرف چند تبلیغ کننده استفاده شود. هر renderUrl باید به یک خلاقیت نگاشت شود.
  • renderUrl باید تا 7 روز پس از آخرین پیشنهاد آگهی توسط سیستم‌های بازبینی خلاق آفلاین Google در دسترس و قابل دریافت باشد.
Bidding API در زمان واقعی

مناقصه گران می توانند از API بیدرنگ مناقصه برای آپلود خلاقیت ها برای مناقصه گروه علاقه استفاده کنند.

اسکن خلاقانه خودکار

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

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

در اینجا نحوه روشن کردن اسکن خلاقانه خودکار آمده است:

  • همه مبدا renderUrl خلاقیت گروه علاقه را به حساب خریدار مجاز اضافه کنید.

  • هدرهای HTTP سفارشی زیر را به پاسخ HTTP خلاقیت اضافه کنید:

    Authorized-Buyers-Creative-ID

    رشته

    شناسه خلاقیت خاص خریدار. حداکثر طول شناسه خلاق 128 بایت است.

    Authorized-Buyers-Click-Through-URLs

    رشته

    مجموعه نشانی‌های اینترنتی مقصد اعلام‌شده برای خلاقیت کدگذاری شده براساس RFC2396 .

مثال:

HTTP/1.1 200 OK
Date: Mon, 8 Jan 2022 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Mon, 8 Jan 2022 12:01:53 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed
Authorized-Buyers-Creative-ID:123456
Authorized-Buyers-Click-Through-URLs:https://www.advertiser.com/clickUrl1,https://www.advertiser.com/clickUrl12

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>
انقضای خلاقیت

خلاقیت ها به مدت 15 روز تایید می شوند. اگر خلاقیت‌ها را با API بیدرنگ Bidding ارسال می‌کنید، باید بعد از ۱۵ روز دوباره آن را ارسال کنید. اگر به اسکن خلاقانه خودکار تکیه می کنید، فرآیند اسکن به طور خودکار آنها را دوباره اسکن می کند.

شناسه گزارش خریدار

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

در زیر نمونه ای از نحوه افزودن buyerAndSellerReportingId به پیکربندی گروه علاقه مندی آورده شده است:

const myGroup = {
  ...
  'ads': [
    {
      ...
      'buyerAndSellerReportingId':
        '{"google_signals": {"buyer_reporting_id": "12345"}}',
      ...
    }
  ]
}
joinAdInterestGroup(myGroup);

buyer_reporting_id به‌عنوان یک بعد جدید در ابزار گزارش‌دهی مجاز خریدار، به‌عنوان بعد شناسه گزارش خریدار ظاهر می‌شود.

مزایده سمت سرور

درخواست پیشنهاد تغییر می کند

در زیر نسخه های اولیه پروتکل های پشتیبانی شده برای استفاده در آزمایش آمده است:

پشتیبانی حراج گروه ذینفع را نشان دهید

درخواست های پیشنهادی دارای یک فیلد جدید، auction_environment هستند.

  • پروتکل RTB Google: BidRequest.adslot.auction_environment
  • OpenRTB: BidRequest.imp.ext.auction_environment

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

  • SERVER_SIDE_AUCTION (OpenRTB JSON: 0 ): مزایده های سنتی سمت سرور
  • ON_DEVICE_INTEREST_GROUP_AUCTION (OpenRTB JSON: 1 ): درخواست هایی با پشتیبانی مخاطب محافظت شده، که در آن یک حراج متنی بر روی سرورهای صرافی و پیشنهاد گروه ذینفع اجرا می شود و حراج نهایی در مرورگر اجرا می شود.
اندازه جایگاه آگهی مخاطب محافظت شده را نشان دهید

درخواست مناقصه شامل فیلدهای زیر است تا اندازه جایگاه آگهی مخاطب محافظت شده را به شما ارائه دهد:

  • پروتکل گوگل RTB:
    • BidRequest.adslot.interest_group_auction.width
    • BidRequest.adslot.interest_group_auction.height
  • OpenRTB:
    • BidRequest.imp.ext.interest_group_auction . width
    • BidRequest.imp.ext.interest_group_auction . height

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

این اندازه ممکن است با اندازه‌های درخواست متنی متفاوت باشد ( Adslot.width و Adslot.height ، یا در OpenRTB: BidRequest.imp.banner.format ).

درخواست متنی ممکن است چندین اندازه داشته باشد. انتظار می‌رود آگهی برنده حراج روی دستگاه تنها یک اندازه ثابت را پر کند.

قابلیت نمایش تبلیغات مخاطب محافظت شده را نشان دهید

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

  • پروتکل RTB Google: BidRequest.adslot.interest_group_auction.render_interest_group_ads
  • OpenRTB: BidRequest.imp.ext.interest_group_auction.render_interest_group_ads
اتکا به شناسه های کاربر را به حداقل برسانید

درخواست‌های پیشنهادی متنی در محدوده آزمایش API مخاطب محافظت‌شده می‌توانند همچنان شناسه‌های سنتی مبتنی بر کوکی را در صورت در دسترس بودن از مرورگر، مانند google_user_id ( BidRequest.user.id در OpenRTB) و hosted_match_data ( BidRequest.user.buyerid در OpenRTB) داشته باشند. زمینه ها وجود چنین شناسه‌هایی در درخواست‌های مناقصه همچنان مشمول هرگونه سیاست حفظ حریم خصوصی موجود خواهد بود. توصیه می‌کنیم در طول آزمایش برای هدف‌یابی و اهداف مناقصه به شناسه‌های مبتنی بر کوکی اعتماد نکنید تا زمانی که کوکی‌های شخص ثالث دیگر در دسترس نیستند، بهتر برای خرید کارآمد آماده شوید.

Google همچنین ممکن است آزمایش‌هایی در مقیاس کوچک اجرا کند که در آن شناسه‌های مبتنی بر کوکی از درخواست‌های پیشنهادی در محدوده آزمایش API مخاطب محافظت‌شده حذف می‌شوند. این برای ارزیابی تأثیر احتمالی از بین رفتن کوکی شخص ثالث است.

برای آماده شدن برای منسوخ شدن کوکی های شخص ثالث (3PCD) در سال 2024، Chrome اکنون آزمایش تسهیل شده توسط Chrome را ارائه می دهد.

سایت‌ها و فروشندگان می‌توانند از آزمایش تسهیل‌شده توسط Chrome برای آزمایش سیستم‌های خود تحت 3PCD استفاده کنند. در آزمایش، مرورگرهای Chrome به یک گروه آزمایشی 3PCD، یا حالت A یا حالت B اختصاص داده می‌شوند. به هر مرورگر یک برچسب ثابت مربوط به یک گروه آزمایشی خاص 3PCD اختصاص داده شده است که می‌توانید از طریق Chrome API درون مرورگر به آن دسترسی داشته باشید.

Google برچسب اصلاح نشده را از Chrome API در درخواست پیشنهاد قیمت RTB ارسال می کند. به دلیل ترافیک کوچک یک برچسب، Google همیشه برچسب را در زمینه‌های محدود به حریم خصوصی قرار نمی‌دهد.

در اینجا فیلدهایی هستند که می توانید برچسب را مشاهده کنید:

  • پروتکل RTB Google: BidRequest.device.cookie_deprecation_label
  • OpenRTB: BidRequest.device.ext.cdep

پاسخ پیشنهاد تغییر می کند

شرکت در حراج گروه ذینفع را مشخص کنید

شما مسئول هستید که با برگرداندن شی InterestGroupBidding در پاسخ پیشنهادی متنی، به صراحت قصد خود را برای شرکت در حراج درون مرورگر نشان دهید:

  • پروتکل RTB Google: BidResponse.interest_group_bidding
  • OpenRTB: BidResponse.ext.igbid

شما باید یک پاسخ پیشنهادی متنی ارائه دهید. پاسخ لازم نیست که شامل یک پیشنهاد متنی باشد. شیء InterestGroupBidding باید حاوی origin مالک گروه ذینفع باشد که باید با یکی از مبداهای پیکربندی شده توسط پیشنهاد دهنده برای حساب خود مطابقت داشته باشد. هنگامی که تگ ناشر Google، runAdAuction() فراخوانی می‌کند، origin به تنظیمات مربوط به حراج به interestGroupBuyers اضافه می‌شود.

انتشار سیگنال های متنی خریدار (perBuyerSignals)

می‌توانید سیگنال‌های خریدار را در پاسخ پیشنهادی متنی بگنجانید، که Google به‌عنوان یک شی JSON به تابع پیشنهاد قیمت روی دستگاه آن‌ها از طریق آرگومان perBuyerSignals منتشر می‌کند. بسته به پروتکل، می‌توان آن را با فیلدهای زیر در پاسخ پیشنهاد گنجاند:

  • Google RTB: BidResponse.interest_group_bidding.per_buyer_signals
  • OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata
سیگنال های رندر متنی خریدار را منتشر کنید

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

می‌توانید سیگنال‌های رندر خریدار را که به‌عنوان یک رشته ایمن برای URL در پاسخ پیشنهادی متنی به‌صورت سریالی درج شده‌اند، قرار دهید، که Google با ساخت ماکرو ${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]} را در URL رندر گروه علاقه برنده جایگزین می‌کند.

بسته به پروتکل، سیگنال های رندر را می توان در پاسخ پیشنهادی با فیلدهای زیر مشخص کرد:

  • Google RTB: BidResponse.interest_group_bidding.interest_group_buyer.rendering_signals
  • OpenRTB: BidResponse.ext.igbid.igbuyer.rsig

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

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

حداکثر قیمت پیشنهادی در مرورگر را مشخص کنید

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

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

در پاسخ پیشنهادی، می توانید حداکثر ارزش پیشنهادی مورد انتظار را در فیلدهای زیر مشخص کنید:

  • پروتکل RTB Google: BidResponse.interest_group_bidding.interest_group_buyers.max_bid_cpm_micros (بیان شده در microCPM)
  • OpenRTB: BidResponse.igbid.igbuyer.maxbid (بیان شده در واحدهای ارز CPM)
نمایش‌ها را به چندین حساب نسبت دهید

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

  • پروتکل Google RTB: BidResponse.interest_group_bidding.interest_group_buyers.billing_id
  • OpenRTB: BidResponse.igbid.igbuyer.billing_id

شناسه صورتحساب انتخاب شده باید یک شناسه صورتحساب واجد شرایط از درخواست پیشنهاد باشد:

  • پروتکل Google RTB: BidRequest.adslot.matching_ad_data.billing_id
  • OpenRTB: BidRequest.imp.ext.billing_id

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

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

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

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

در طول حراج درون مرورگر

پیشنهادات درون مرورگر ایجاد کنید

برای تولید پیشنهادات درون مرورگر از generateBid() استفاده کنید.

گوگل پارامترهای زیر را ارائه می دهد:

  • auctionSignals : خالی است
  • perBuyerSignals : یک شی جاوا اسکریپت از سیگنال های مشابه ارائه شده توسط پیشنهاد دهنده در پاسخ متنی

پارامترهای زیر برگردانده می شوند:

  • ad : گوگل این فیلد را نادیده می گیرد.
  • bid : پیشنهاد عددی که وارد مزایده می شود. باید در واحدهای CPM باشد (نه میکرو).
  • render : URL ارائه شده برای نمایش خلاقیت در صورت برنده شدن پیشنهاد در حراج. گوگل باید این URL را بررسی و تایید کند، در غیر این صورت از حراج فیلتر خواهد شد.
  • allowComponentAuction : باید true باشد. گوگل در حال حاضر از تست حراج های چند فروشنده پشتیبانی می کند.

در اینجا یک مثال است:

function generateBid(...) {
  ...
  return {'ad': 'example',
          'bid': ad.metadata.bid,
          'render': ad.renderUrl,
          'allowComponentAuction': true};
}

برای توضیح تابع generateBid() به بخش مناقصه روی دستگاه مشخصات مخاطب محافظت شده مراجعه کنید.

ارز پیشنهادی

پیشنهادات حراج درون مرورگر بر حسب واحد CPM ارز پیشنهادی انتخاب شده قرار می گیرد.

ارز پیشنهادی باید هم در پاسخ پیشنهادی متنی و هم در ارزش بازگشتی generateBid نشان داده شود و باید یک کد آلفا ISO 4217 معتبر مانند "USD"، "EUR" یا "JPY" باشد.

در OpenRTB، از فیلد cur new در شی InterestGroupBuyer در پسوند پاسخ پیشنهادی گوگل استفاده کنید.

در اینجا یک مثال است:

ext {
  igbid {
    impid: "1"
    igbuyer {
      origin: "https://examplebuyerorigin.com"
      cur: "EUR"
    }
  }
}

در پروتکل Google RTB، از فیلد currency جدید در پیام InterestGroupBuyer در پاسخ پیشنهاد استفاده کنید.

در اینجا یک مثال است:

interest_group_bidding {
  adslot_id: 1
  interest_group_buyer {
    origin: "https://examplebuyerorigin.com"
    currency: "EUR"
  }
}

توابع مناقصه گران generateBid مناقصه باید پیشنهادات را به همان واحد پولی که در پاسخ پیشنهادی متنی نشان داده شده است، برگردانند. ویژگی bidCurrency جدید را در مقدار بازگشتی generateBid پر کنید:

function generateBid(...) {
  ...
  return {'ad': ad,
          'bid': bid,
          'bidCurrency': 'EUR',
          ...};
}

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

بررسی کیفیت تبلیغات

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

پشتیبانی قانون خدمات دیجیتال

با توجه به ماده 26 قانون خدمات دیجیتال، ناشران ممکن است از خریداران بخواهند که افشای شفافیت در آگهی را ارائه کنند. وقتی کنترل «از خریداران بخواهد فقط تبلیغات با اطلاعات شفافیت DSA را در سایت یا برنامه من در منطقه اقتصادی اروپا نشان دهند» توسط ناشر فعال می‌شود، خریداران گروه ذینفع می‌توانند با توجه به فیلدهای زیر تعیین کنند که چه فرصت‌هایی برای شفاف‌سازی خریدار لازم است. درخواست‌های پیشنهادی دریافت کرد: BidRequest.dsa.dsa_support و BidRequest.dsa.publisher_rendering_support برای پروتکل Google Authorized Buyers و BidRequest.regs.dsa.required و BidRequest.dsa.pubrender برای پروتکل OpenRTB.

هنگامی که پیشنهاد دهنده ای که مایل به شرکت در مزایده های API مخاطبان محافظت شده است، سیگنال درخواست پیشنهاد مبنی بر اینکه شفافیت DSA باید برای تبلیغات ارائه شده از طریق API مخاطب محافظت شده نمایش داده شود، دریافت می کند، باید ارزیابی کند که آیا می تواند اطلاعات مورد نیاز را به درستی نمایش دهد و با تنظیم BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render برای پروتکل Google Authorized Buyers یا BidResponse.ext.igbid.igbuyer.dsaadrender برای پروتکل OpenRTB. در غیر این صورت، خریدار در حراج API مخاطبان محافظت شده شرکت نخواهد کرد.

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

فیلتر پیشنهاد

Google کنترل‌های ناشر و خط‌مشی‌های آگهی را در طول حراج روی دستگاه اعمال می‌کند.

پس از حراج درون مرورگر

گزارش نتیجه حراج به خریدار: reportWin()

گوگل آرگومان های زیر را پر نمی کند:

  • auctionSignals
  • sellerSignals

از reportWin() برای گزارش نتیجه حراج به خریدار استفاده کنید.

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

ماکروها

renderUrl که به خلاقیت Protected Audience API ارجاع می‌دهد می‌تواند شامل یک یا چند مکان‌نما به نام ماکرو باشد. پس از پایان حراج گروه ذینفع، اما قبل از رندر، ماکروها با مقادیر مربوطه جایگزین می شوند. renderUrl مورد استفاده در حراج روی دستگاه می تواند شامل ماکروهای زیر باشد:

${GDPR} اگر GDPR اعمال نشود به 0 یا اگر GDPR اعمال شود به 1 گسترش می یابد. مستندات را ببینید.
${GDPR_CONSENT_XXXX} به رشته شفافیت و رضایت (TC) مرتبط با درخواست گسترش می‌یابد. اگر رشته شفافیت و رضایت (TC) خالی یا نامعتبر باشد، این ماکرو بزرگ نمی شود.

از این ماکرو برای ارسال رشته TC به یک فروشنده ثبت شده در IAB GVL در URL استفاده کنید. XXXX با شناسه IAB GVL فروشنده ثبت شده در IAB GVL جایگزین کنید. اگر رشته TC خالی یا نامعتبر باشد، این ماکرو بزرگ نمی شود.

اگر فروشنده ثبت شده در IAB GVL مرتبط با شناسه IAB GVL که درج کرده‌اید رضایت کاربر را نداشته باشد، خلاقیت‌های دارای ماکرو ${GDPR_CONSENT_XXXX} ممکن است مسدود شوند.

ماکرو ${GDPR_CONSENT_XXXX} باید فقط یک بار در renderUrl رخ دهد.
${ADDL_CONSENT} به رشته رضایت اضافی (AC) مرتبط با درخواست گسترش می یابد.
${AD_WIDTH}, ${AD_HEIGHT) این ماکروها عرض و ارتفاع اسلات آگهی را درج می کنند.
${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}

کلان حاوی سیگنال‌های خریدار در زمان ارائه مشخص شده در پاسخ پیشنهاد.

جای جای buyer.origin.example را با مبدأ خریدار گروه ذینفع جایگزین کنید، که باید مطابق با interest_group_buyers.origin در پاسخ پیشنهاد باشد. می‌توانید یک _OPTIONAL_SUFFIX را برای ارائه حداکثر سه مقدار سیگنال رندر مختلف اضافه کنید.

شمارش برداشت

در طول آزمایش API مخاطب محافظت‌شده با شرکای RTB، وقتی مرورگر تابع reportResult() خود را فراخوانی می‌کند، Google نمایش‌ها را می‌شمارد و متعاقباً URL گزارش Google را در تماسی با sendReportTo() واکشی می‌کند.

از آنجایی که ممکن است رویدادی که Google برای شمارش نمایش‌ها در حراج‌های درون مرورگر «مخاطب محافظت‌شده» استفاده می‌کند با رویدادی که برای شمارش نمایش‌ها توسط شرکای خریدار RTB استفاده می‌شود متفاوت باشد، ممکن است تعداد نمایش‌ها متفاوت باشد.

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

انتساب برداشت های قابل پرداخت

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

سقف بودجه روزانه

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

این حساب پس از رسیدن به سقف مخاطب محافظت شده می‌تواند به شرکت در مزایده‌های متنی سمت سرور ادامه دهد. به عنوان مثال، یک حساب پیشنهاد دهنده که به سقف مخاطب محافظت شده می رسد ممکن است یک درخواست پیشنهاد با auction_environment = SERVER_SIDE_AUCTION (OpenRTB: 0 ) دریافت کند، حتی اگر درخواست پیشنهاد برای یک حراج مخاطب محافظت شده واجد شرایط باشد.

بازخورد در زمان واقعی و حداقل پیشنهاد برای برنده شدن

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

  • نوع بازخورد شیء بازخورد INTEREST_GROUP_BUYER_FEEDBACK خواهد بود.
  • منشاء خریدار گروه ذینفع.
  • حداقل پیشنهاد برای برنده شدن برای خریدار گروه ذینفع به منظور برنده شدن در حراج کلی.
  • حداقل پیشنهاد برای برنده شدن برای خریدار گروه ذینفع به منظور شکست دادن بالاترین پیشنهاد از بخش سمت سرور در حراج کلی.
  • کد وضعیت خریدار گروه ذینفع. کدهای وضعیت احتمالی در Interest-group-buyer-status-codes.txt تعریف شده است.

برای نام فیلدهای خاص، به مستندات پروتکل برای افزونه های RTB و OpenRTB خریداران مجاز مراجعه کنید.

اطلاعیه بازخورد پیشنهاد

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

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

  • BidRequest.ext.google_query_id %%GOOGLE_QUERY_ID%% BidRequest.google_query_id
  • %%INTEREST_GROUP_OWNER%% : مبدأ مالک گروه ذینفع.
  • %%BID_CPM%% : قیمت پیشنهادی در CPM که توسط خریدار در تابع generateBid() مشخص شده است.
  • %%RENDER_URL%% : نشانی اینترنتی رندر خلاقیت.
  • %%STATUS%% : یک کد وضعیت در صورتی که پیشنهاد در scoreAd() رد شود. مقادیر کدهای وضعیت خلاقانه هستند.

در اینجا یک نمونه URL ثابت است که پیشنهاد دهنده ممکن است به مدیر حساب خود ارائه دهد:

https://dsp.example/debug?google_query_id=%%GOOGLE_QUERY_ID%%&ig_owner=%%INTEREST_GROUP_OWNER%%&render_url=%%RENDER_URL%%&bid=%%BID_CPM%%&status=%%STATUS%%

اعلان بازخورد پیشنهادی یک ویژگی موقت است که به API موقت ForDebuggingOnly Chrome وابسته است.

TURTLEDOVE در سطح محصول

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

سوار شدن

در اینجا نحوه تست Protected Audience API آورده شده است:

مراحل

  1. فرم درخواست را برای پیوستن به آزمایش API مخاطب محافظت شده پر کنید.
  2. پس از ارسال فرم درخواست، با مدیر حساب خود تماس بگیرید یا با استفاده از مرکز راهنمای خریدار مجاز، یک بلیت ارسال کنید.
  3. پس از پیکربندی حساب، هم Google و هم شریک می‌توانند ادغام را از طریق مراحل مراحل تست تأیید کنند.

نقد خلاق

به منظور مناقصه با تبلیغات سطح محصول ( تبلیغات متشکل از چندین قطعه ) در حراج‌های Protected Audience API، این شرایط را دنبال کنید:

  • پارامتر &pltd=True query را در renderUrl برای کانتینر تبلیغ مؤلفه (که renderUrl سطح بالا نیز نامیده می شود) اضافه کنید تا در طول بررسی خلاق، renderUrls سطح بالا را تشخیص دهید.
  • وقتی کانتینر تبلیغ مؤلفه برای بازبینی خلاقانه توسط Google واکشی می‌شود، یک نماینده خلاق ارائه دهید. برای اینکه بفهمید چه زمانی باید یک رندر تبلیغ نماینده بازگردانده شود، می‌توانید به پارامتر validation=True تنظیم‌شده توسط سیستم بازبینی خلاق Google مراجعه کنید.

چک لیست ادغام

  • یک نقطه پایانی درخواست پیشنهاد راه‌اندازی کنید که فیلدهای مربوط به API مخاطبین محافظت‌شده را در پاسخ پیشنهادی متنی پر می‌کند - برای مثال، interest_group_bidding .
  • برای پیوستن مرورگر کاربر به گروه علاقه مندی، برچسب گذاری را در صفحات تبلیغ کننده پیاده کنید.
  • generateBid() و reportWin() را پیاده سازی کنید.
  • منشاء مالک گروه مورد علاقه را انتخاب کنید و آنها را به حساب خریدار مجاز اضافه کنید.
    • مبدا مالک گروه علاقه باید با مبداهایی مطابقت داشته باشد که توابع generateBid() در آن میزبانی می شوند.
    • برای تکمیل این مرحله با مدیر حساب تماس بگیرید یا با استفاده از مرکز راهنمای خریدار مجاز، یک بلیت ثبت کنید.
  • پیش هدف گذاری را برای موجودی مربوط به آزمایش API مخاطب محافظت شده تنظیم کنید.
  • خلاقیت‌ها را از طریق Creatives API برای بررسی و تأیید ارسال کنید.
  • (اختیاری) نقاط پایانی سیگنال های پیشنهاد قیمت قابل اعتماد را تنظیم کنید.
  • (اختیاری) یک صفحه آگهی‌دهنده آزمایشی راه‌اندازی کنید که به مهندسان Google امکان می‌دهد مرورگر خود را به گروه‌های علاقه متعلق به مبدأ خریدار گروه مورد علاقه‌تان اضافه کنند. این به ما امکان می دهد حراج های مخاطب محافظت شده را به صورت دستی راه اندازی کنیم.
  • (اختیاری) بازخورد بلادرنگ را در حساب خود فعال کنید تا برای خریداران گروه علاقه مندی که درخواست کرده اند در حراج مخاطب محافظت شده شرکت کنند، بازخورد دریافت کنید.
  • (اختیاری) با مدیر حساب خود تماس بگیرید تا یک URL ثابت را پیکربندی کنید تا یک اعلان سرور به سرور دریافت کنید که بازخورد پیشنهاد مخاطب محافظت شده را برای وضعیت پیشنهاد از حراج مخاطب محافظت شده روی دستگاه برای کمک به اشکال زدایی مشکلات غیرمنتظره ارائه می دهد. برای جزئیات به اطلاعیه بازخورد پیشنهاد مراجعه کنید.

مراحل تست

مرحله 1: آزمون دستی

در اینجا نحوه راه‌اندازی دستی حراج مخاطب محافظت‌شده، اطمینان از نمایش آگهی و ثبت نمایش آمده است:

  1. از Chrome 101 یا جدیدتر استفاده کنید.
  2. Privacy Sandbox API و Fenced Frame را با استفاده از chrome://flags/#privacy-sandbox-ads-apis و chrome://flags/#enable-fenced-frames فعال کنید. در تست جعبه ایمنی حریم خصوصی بیشتر ببینید.
  3. با استفاده از API بیدرنگ Bidding یک خلاقیت را برای تأیید ارسال کنید.
  4. از صفحه آگهی دهنده ارائه شده توسط مناقصه‌گذار برای افزودن مرورگر به گروه ذینفع متعلق به مناقصه‌گذار استفاده کنید.

  5. از صفحه ناشر آزمایشی ارائه شده توسط Google زیر برای راه اندازی حراج مخاطب محافظت شده استفاده کنید:

    https://fledge-testing.uc.r.appspot.com/?nid=allow_all

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

  6. موارد زیر را تأیید کنید:

    1. آگهی برنده مورد انتظار ارائه می شود.
    2. نتیجه حراج در سمت سرور ارسال می شود - به این معنی که پیشنهاد دهنده برنده یک پینگ از reportWin() دریافت می کند.
    3. کنسول صفحه ناشر آزمایشی یک پیام اشکال زدایی را برای هر پیشنهاد با اطلاعات زیر ثبت می کند:
      • renderUrl : URL رندر پیشنهاد.
      • interestGroupOwner : مالک گروه ذینفع پیشنهاد.
      • accepted : اگر پیشنهاد پذیرفته شود این قسمت true است و اگر پیشنهاد توسط scoreAd() رد شده باشد false .
      • externalBidStatus : یک کد وضعیت در صورتی که پیشنهاد در داخل scoreAd() رد شود. مقادیر کدهای وضعیت خلاقانه هستند.

مرحله 2: (اختیاری) آزمایش بدون رندر

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

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

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

مرحله 3: آزمایش رندر

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

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

ویژگی های اضافی

ویژگی های زیر پسوند پروتکل هسته است.

موازی سازی

موازی سازی یک بهینه سازی است که با شروع درخواست AD متنی به موازات درخواست های مربوط به سرورهای قابل اعتماد که در trustedBiddingSignalsUrl مشخص شده است ، تأخیر حراج پایان به پایان را کاهش می دهد.

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

خدمت خلاصه جریان

در اینجا خلاصه ای از جریان حراج موازی: Flow diagram

واجد شرایط بودن خریدار گروه بهره در دستگاه

برای حراج های موازی ، تماس navigator.runAdAuction قبل از بازگشت پاسخ AD متنی اتفاق می افتد. به منظور شروع تماس های سرور قابل اعتماد خریدار ، navigator.runAdAuction نیاز دارد که پارامتر interestGroupBuyers باید به عنوان یک مقدار منتقل شود ، در حالی که پارامترهای حراج باقیمانده وعده های JavaScript را می پذیرند که پس از پاسخ تبلیغات متنی قابل حل است. از آنجا که interestGroupBuyers قبل از پاسخ AD متنی منتقل می شود ، از پاسخ AD متنی (از جمله پاسخ های پیشنهاد) نمی توان استفاده کرد تا انتخاب کند که خریداران در حراج موازی برای درخواست داده شده شرکت می کنند. در عوض ، ناشر برچسب ناشر Google ، در مرورگر کاربر ، پارامتر interestGroupBuyers از navigator.runAdAuction قبلی. اعدام های Runadauction در همان دامنه.

موازی سازی چندین ملاحظات مهم دارد:

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

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

  3. اگر حداقل یک خریدار برای هر پیشنهاد دهنده برای دامنه ناشر فعلی ذخیره شود ، Google حراج موازی را اجرا می کند ، که در درخواست پیشنهاد نشان داده می شود:

    • پروتکل RTB Google: BidRequest.adslot.interest_group_auction.parallelized
    • OpenRTB: BidRequest.imp.ext.interest_group_auction.parallelized

  4. هر منشأ خریدار گروه علاقه ثبت شده برای یک پیشنهاد دهنده معین که در حراج موازی گنجانده شده است ، دارای یک ورودی ParallelAuctionBuyer مربوطه است:

    • پروتکل RTB Google: BidRequest.adslot.interest_group_auction.parallel_auction_buyer
    • OpenRTB: BidRequest.imp.ext.interest_group_auction.pbuyer

  5. اگر یک حراج موازی اجرا شود ، اما منشأ خریدار خاص در حافظه نهان وجود ندارد ، پس با توجه به خریدار نمی توان به حراج فعلی در دستگاه اضافه کرد. این با درخواستی با parallelized=True نشان داده شده است که فاقد ورود ParallelAuctionBuyer برای منشأ خریدار گروه علاقه خاصی است. با این حال ، داوطلبانی که علاقه خود را با استفاده از InterestGroupBuyer معتبر و واجد شرایط در پاسخ به پیشنهاد خود نشان می دهند ، مبدا خریدار گروه علاقه مربوطه را به حافظه نهان اضافه می کنند ، و این ریشه ها واجد شرایط درخواست های موازی آینده از همان مرورگر و دامنه هستند. قصد شرکت در حراج های گروهی علاقه را می توان در زمینه های زیر نشان داد:

    • پروتکل RTB Google: BidResponse.adslot.interest_group_bidding.interest_group_buyers
    • OpenRTB: BidResponse.ext.igbid.igbuyer

  6. منشأ خریدار ذخیره شده (که در پارامتر interestGroupBuyers حراج موازی گنجانده شده است) که یک پیشنهاد دهنده نشان نمی دهد قصد شرکت در پاسخ پیشنهاد خود ممکن است یک تماس سرور قابل اعتماد خریدار را دریافت کند اما در حراج موازی شرکت نخواهد کرد.