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. پیشنهاد دهنده یک پاسخ پیشنهاد شامل پیام InterestGroupBidding را که برای شرکت در حراج گروه ذینفع لازم است، برمی گرداند. در OpenRTB این با فیلد BidResponse.ext.igbid مشخص شده است، و در پروتکل منسوخ شده Google RTB با فیلد BidResponse.interest_group_bidding مشخص شده است. اگر پیشنهاد دهنده این اطلاعات را مشخص نکند، Google مبدا پیشنهاد دهنده را در interestGroupBuyers در پیکربندی حراج لحاظ نمی کند. InterestGroupBidding همچنین می‌تواند حاوی سیگنال‌های اختیاری خاص خریدار باشد که در طول حراج درون مرورگر به عملکرد پیشنهاد دهنده پیشنهاد داده می‌شود. در OpenRTB این با فیلد BidResponse.ext.igbid.igbuyer.buyerdata مشخص شده است، و در پروتکل منسوخ شده Google RTB با فیلد BidResponse.interest_group_bidding.interest_group_buyers.per_buyer_signals مشخص شده است. برای اطلاعات بیشتر به بخش تغییرات پاسخ پیشنهادی مراجعه کنید.
  8. گوگل حراج سمت سرور را اجرا می کند و یک پاسخ پیشنهادی را به مرورگر برمی گرداند. مزایده سمت سرور پیشنهادات سنتی و سمت سرور را در نظر می گیرد. پاسخ پیشنهاد می تواند حاوی اطلاعاتی در مورد یک پیشنهاد برنده متنی (در صورت وجود) باشد.
  9. پاسخ پیشنهاد شامل پیکربندی حراج برای حراج درون مرورگر است. این می‌تواند شامل سیگنال‌های متنی از هر خریدار شرکت‌کننده (که از طریق buyerdata OpenRTB یا پروتکل منسوخ شده Google RTB per_buyer_signals قبلا ارسال شده بود)، اطلاعات برنده متنی، و تنظیمات واجد شرایط بودن پیشنهاد باشد.
  10. تگ ناشر Google برای شروع حراج گروه علاقه مند در دستگاه، API مخاطب محافظت شده runAdAuction() را فراخوانی می کند. Google فقط خریدارانی را شامل می‌شود که در طول پیکربندی حراج به‌عنوان InterestGroupBuyer در InterestGroupBidding گنجانده شده‌اند.
  11. Google سیگنال های اختیاری خریدار خاص هر پیشنهاد دهنده واجد شرایط را به پیکربندی حراج مخاطب محافظت شده ارسال می کند.
  12. اگر گروه‌های ذینفع یک پیشنهاددهنده، trustedBiddingSignalsUrl را مشخص کرده باشند، مرورگر از هر گروه درخواستی برای واکشی سیگنال‌های trustedBiddingSignalsUrl برای هر گروه می‌کند. جزئیات را در مشخصات API مخاطب محافظت شده ببینید.
  13. مرورگر برای هر گروه ذینفعی که شرکت کرده و واجد شرایط شرکت در مزایده درون مرورگر است، مناقصه‌دهنده generateBid() فراخوانی می‌کند. این مرحله قیمت پیشنهادی را محاسبه می کند و یک خلاقیت انتخاب می کند. generateBid() به سیگنال‌های خریدار اختیاری ارائه‌شده توسط مناقصه‌دهنده و سیگنال‌های مناقصه مورد اعتماد برای گروه مورد نظر دسترسی دارد.
  14. مرورگر scoreAd() فروشنده (در این مورد، گوگل) را فراخوانی می‌کند تا رتبه‌ای را به هر پیشنهاد در مزایده آگهی گروه علاقه‌مند اختصاص دهد. پیشنهادها بر اساس محافظت از ناشر، خط‌مشی‌های تبلیغاتی و سایر محدودیت‌ها رتبه‌بندی و فیلتر می‌شوند.
  15. مرورگر حراجی را با پیشنهادهای گروه ذینفع واجد شرایط اجرا می کند. پیشنهاد متنی با رتبه برتر در مزایده درون مرورگر شرکت می کند.
  16. پس از حراج، اگر برنده گروه ذینفعی وجود داشته باشد، مرورگر reportResult() و پیشنهاد دهنده reportWin() را فراخوانی می کند تا به هر یک از طرفین در مورد برنده مزایده درون مرورگر اطلاع دهد.
  17. اگر تبلیغ گروه علاقه‌مندی برنده شود، برچسب ناشر Google آگهی را در یک iframe نمایش می‌دهد.

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

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

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

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

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

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

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

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

مناقصه گران می توانند اسکن خلاقیت خودکار را برای خلاقیت هایی که از طریق 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 ارسال می‌کنید، باید بعد از 15 روز خلاقیت را دوباره ارسال کنید. اگر به اسکن خلاقانه خودکار تکیه می کنید، فرآیند اسکن به طور خودکار آنها را دوباره اسکن می کند.

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

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

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

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

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

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

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

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

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

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

  • OpenRTB:
    • BidRequest.imp.ext.ae
    • BidRequest.imp.ext.igbid
  • پروتکل Google RTB (منسوخ شده):
    • BidRequest.adslot.supported_auction_environment
    • BidRequest.adslot.interest_group_bidding_allowed

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

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

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

  • OpenRTB:
    • BidRequest.imp.ext.interest_group_auction . width
    • BidRequest.imp.ext.interest_group_auction . height
  • پروتکل Google RTB (منسوخ شده):
    • BidRequest.adslot.interest_group_auction.width
    • BidRequest.adslot.interest_group_auction.height

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

این اندازه ممکن است با موارد موجود در درخواست متنی متفاوت باشد، مانند مواردی که در فیلدهای BidRequest.imp.banner.format.w و BidRequest.imp.banner.format.h OpenRTB یا BidRequest.adslot.width و BidRequest.adslot.height پروتکل منسوخ شده Google RTB وجود دارد. فیلدهای BidRequest.adslot.height .

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

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

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

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

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

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

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

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

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

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

  • OpenRTB: BidRequest.device.ext.cdep
  • پروتکل RTB Google (منسوخ شده): BidRequest.device.cookie_deprecation_label

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

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

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

  • OpenRTB: BidResponse.ext.igbid
  • پروتکل RTB Google (منسوخ شده): BidResponse.interest_group_bidding

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

سیگنال های متنی خریدار را منتشر کنید

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

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

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

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

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

  • OpenRTB: BidResponse.ext.igbid.igbuyer.rsig
  • Google RTB (منسوخ شده): BidResponse.interest_group_bidding.interest_group_buyer.rendering_signals

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

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

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

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

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

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

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

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

  • OpenRTB: BidResponse.igbid.igbuyer.billing_id
  • پروتکل Google RTB (منسوخ شده): BidResponse.interest_group_bidding.interest_group_buyers.billing_id

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

  • OpenRTB: BidRequest.imp.ext.billing_id
  • پروتکل Google RTB (منسوخ شده): BidRequest.adslot.matching_ad_data.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() به بخش Protected Audience spec On-Device Bidding مراجعه کنید.

ارز پیشنهادی

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

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

در OpenRTB، از فیلد cur جدید در شی 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.regs.dsa.required تعیین کنند که برای ارائه شفافیت خریدار به چه فرصت‌هایی نیاز دارند. BidRequest.regs.dsa.required و BidRequest.dsa.pubrender در درخواست پیشنهاد ( BidRequest.dsa.dsa_support و BidRequest.dsa.publisher_rendering_support به ترتیب در پروتکل منسوخ شده Google RTB).

هنگامی که پیشنهاد دهنده ای که مایل به شرکت در مزایده های API مخاطبان محافظت شده است، سیگنال درخواست پیشنهاد مبنی بر اینکه شفافیت DSA باید برای تبلیغات ارائه شده از طریق API مخاطب محافظت شده نمایش داده شود، دریافت می کند، باید ارزیابی کند که آیا می تواند اطلاعات مورد نیاز را به درستی نمایش دهد و با تنظیم BidResponse.ext.igbid.igbuyer.dsaadrender ( BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render در پروتکل منسوخ شده Google RTB). در غیر این صورت، خریدار در حراج 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 مخاطب محافظت شده، شناسایی و کاهش این اختلافات است.

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

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

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

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

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

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

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

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

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

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

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

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

  • %%GOOGLE_QUERY_ID%% . در پروتکل OpenRTB این مورد با BidRequest.ext.google_query_id مشخص شده است، در حالی که پروتکل منسوخ شده Google RTB از 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 بیدرنگ پیشنهاد برای تأیید ارسال کنید.
  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 حساب این مرحله را فعال می کند.

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

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

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

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

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

موازی سازی

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

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

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

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

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

برای حراج های موازی ، تماس navigator.runAdAuction قبل از بازگشت پاسخ AD متنی اتفاق می افتد. به منظور شروع تماس های سرور قابل اعتماد خریدار ، navigator.runAdAuction نیاز دارد که پارامتر interestGroupBuyers باید به عنوان یک مقدار منتقل شود ، در حالی که پارامترهای حراج باقیمانده وعده های JavaScript را می پذیرند که پس از پاسخ تبلیغات متنی قابل حل است. از آنجا که interestGroupBuyers قبل از پاسخ AD متنی منتقل می شود ، از پاسخ AD متنی (از جمله پاسخ های پیشنهاد) نمی توان استفاده کرد تا انتخاب کند که خریداران در حراج موازی برای درخواست داده شده شرکت می کنند. در عوض ، ناشر برچسب های ناشر گوگل ، در مرورگر کاربر ، پارامتر 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 مربوطه است:

    • پروتکل Google RTB: 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 حراج موازی گنجانده شده است) که یک پیشنهاد دهنده نشان نمی دهد قصد شرکت در پاسخ پیشنهاد خود ممکن است یک تماس سرور قابل اعتماد خریدار را دریافت کند اما در حراج موازی شرکت نخواهد کرد.