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

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

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

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

خریداران مجاز علاقه‌مند به آزمایش باید برای جزئیات بیشتر به بخش «آشنایی با محصول» مراجعه کنند.

بتا: رفتاری که در اینجا شرح داده شده است ممکن است در آینده با یادگیری از آزمایش و جمع‌آوری بازخورد از ناشران و خریداران مجاز تغییر کند.

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

توجه: وقتی API مخاطب محافظت‌شده (که قبلاً با نام FLEDGE شناخته می‌شد) در کروم به‌طور عمومی در دسترس قرار گیرد، Ad Manager به‌تدریج میزان ترافیک موجود در آزمایش خود را افزایش خواهد داد. ما همزمان با افزایش تدریجی درصد ترافیک، تأثیر آن بر درآمد ناشر را رصد خواهیم کرد و در صورت وجود تأثیر منفی قابل توجه، آن را افزایش نخواهیم داد. ما انتظار داریم تا پایان سال ۲۰۲۳، تا ۱۰٪ از ترافیک کروم برای آزمایش API مخاطب محافظت‌شده فعال شود.

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

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

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

جزئیات جریان سرو

قبل از نمایش تبلیغات

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

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

الزامات renderUrls :

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

API پیشنهاد قیمت در لحظه

پیشنهاددهندگان می‌توانند از API پیشنهاددهی بلادرنگ برای آپلود آگهی‌های تبلیغاتی جهت پیشنهاددهی گروه‌های ذی‌نفع استفاده کنند.

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

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

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

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

• تمام ریشه‌های renderUrl مربوط به گروه هدف را به حساب خریدار مجاز اضافه کنید.

• هدرهای HTTP سفارشی زیر را به پاسخ HTTP مربوط به طراح اضافه کنید:

  Authorized-Buyers-Creative-ID	رشته شناسه خلاق مخصوص خریدار. حداکثر طول شناسه خلاق ۱۲۸ بایت است.
  Authorized-Buyers-Click-Through-URLs	رشته مجموعه URL های مقصد اعلام شده برای خلاقیت کدگذاری شده طبق 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>

انقضای خلاقانه

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

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

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

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

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

buyer_reporting_id به عنوان یک بُعد جدید در ابزار گزارش‌دهی خریدار مجاز، با عنوان شناسه گزارش‌دهی خریدار (Buyer Reporting ID) ظاهر خواهد شد.

حراج سمت سرور

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

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

• لینک اولیه OpenRTB
• لینک اولیه پروتکل RTB گوگل (منسوخ شده)

حمایت از حراج گروه‌های ذی‌نفع را نشان دهید

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

• اوپن‌آرتی‌بی:
  • BidRequest.imp.ext.ae
  • BidRequest.imp.ext.igbid
• پروتکل RTB گوگل (منسوخ شده):
  • BidRequest.adslot.supported_auction_environment
  • BidRequest.adslot.interest_group_bidding_allowed

شما می‌توانید از این فیلد برای تمایز قائل شدن بین فرصت‌های نمایش که از حراج گروه‌های ذینفع درون مرورگری Protected Audience پشتیبانی می‌کنند و آن‌هایی که فقط از حراج تبادل سنتی سمت سرور پشتیبانی می‌کنند، استفاده کنید. شمارش AuctionEnvironment می‌تواند مقادیر زیر را داشته باشد:

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

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

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

• اوپن‌آرتی‌بی:
  • BidRequest.imp.ext.interest_group_auction . width
  • BidRequest.imp.ext.interest_group_auction . height
• پروتکل 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، متفاوت باشد.

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

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

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

• OpenRTB: BidRequest.imp.ext.interest_group_auction.render_interest_group_ads
• پروتکل RTB گوگل (منسوخ شده): 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 را حمل کنند. وجود چنین شناسه‌هایی در درخواست‌های پیشنهاد تابع سیاست‌های حفظ حریم خصوصی موجود است. توصیه می‌کنیم در طول آزمایش برای اهداف هدف‌گذاری و پیشنهاد قیمت، به شناسه‌های مبتنی بر کوکی تکیه نکنید تا در زمانی که کوکی‌های شخص ثالث دیگر در دسترس نیستند، برای خرید کارآمدتر آماده شوید.

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

تست حذف کوکی‌های شخص ثالث با پشتیبانی کروم

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

هشدار: این ویژگی به پشتیبانی مرورگر deprecatedRenderURLReplacements بستگی دارد.

شما می‌توانید سیگنال‌های رندر خریدار را که به صورت یک رشته URL-safe سریالی شده‌اند، در پاسخ پیشنهاد متنی قرار دهید، که گوگل با ساخت ماکروی ${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

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

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

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

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

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

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

• OpenRTB: BidResponse.igbid.igbuyer.maxbid (بیان شده بر حسب واحدهای ارزی CPM)
• پروتکل RTB گوگل (منسوخ شده): 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() به بخش پیشنهاد قیمت روی دستگاه با مشخصات مخاطب محافظت‌شده مراجعه کنید.

ارز پیشنهادی

پیشنهادهای حراج درون مرورگری بر اساس واحد 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، اجرای سیاست‌های خلاقانه و کنترل‌های ناشر برای پیشنهادهای گروه‌های ذی‌نفع درون مرورگر محدودتر باشد.

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

طبق ماده ۲۶ قانون خدمات دیجیتال، ناشران ممکن است از خریداران بخواهند که اطلاعات شفافیت درون تبلیغی را ارائه دهند. وقتی کنترل «از خریداران بخواهید فقط تبلیغاتی با اطلاعات شفافیت DSA را در سایت یا برنامه من در منطقه اقتصادی اروپا نشان دهند» توسط یک ناشر فعال شود، خریداران گروه‌های ذینفع می‌توانند با توجه به مقادیر BidRequest.regs.dsa.required و BidRequest.dsa.pubrender در درخواست پیشنهاد (به ترتیب BidRequest.dsa.dsa_support و BidRequest.dsa.publisher_rendering_support در پروتکل منسوخ‌شده Google RTB) تعیین کنند که برای کدام فرصت‌ها ملزم به ارائه شفافیت خریدار خواهند بود.

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

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

فیلتر کردن پیشنهاد قیمت

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

بعد از حراج درون مرورگری

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

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

• auctionSignals
• sellerSignals

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

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

ماکروها

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

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

${GDPR}	اگر GDPR اعمال نشود به ۰ و اگر GDPR اعمال شود به ۱ افزایش می‌یابد. به مستندات مراجعه کنید.
${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 را با origin گروه مورد نظر خریدار جایگزین کنید، که باید با interest_group_buyers.origin در پاسخ پیشنهاد قیمت مطابقت داشته باشد. می‌توانید یک _OPTIONAL_SUFFIX برای ارائه حداکثر سه مقدار سیگنال رندر مختلف اضافه کنید.

شمارش تعداد نمایش‌ها

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• %%GOOGLE_QUERY_ID%% : این ماکرو با شناسه‌ی جستجوی گوگل که در درخواست پیشنهاد متنی با قابلیت Protected Audience ارسال شده بود، جایگزین می‌شود. در پروتکل 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 کروم وابسته است.

TURTLEDOVE در سطح محصول

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

سوار شدن

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

مراحل

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

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

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

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

چک لیست ادغام

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

مراحل آزمایش

مرحله ۱: تست دستی

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

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

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

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

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

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

   1. تبلیغ برنده‌ی مورد انتظار نمایش داده می‌شود.
   2. نتیجه حراج به سمت سرور ارسال می‌شود—به این معنی که پیشنهاد دهنده برنده، یک پینگ برگشتی از reportWin() دریافت می‌کند.
   3. کنسول صفحه ناشر آزمایشی، برای هر پیشنهاد، یک پیام اشکال‌زدایی با اطلاعات زیر ثبت می‌کند:
      • renderUrl : آدرس رندر پیشنهاد.
      • interestGroupOwner : مالک گروه ذینفع پیشنهاد.
      • accepted : This field is true if the bid was accepted and false if the bid was rejected by scoreAd() .
      • externalBidStatus : A status code if the bid was rejected within scoreAd() . Values are creative status codes .

Stage 2: (Optional) Non-rendering experiment

After Google and the partner have manually verified that the partner can participate in the Protected Audience auction, Google enables the partner for the next stage of testing.

Google allocates a small amount of live traffic to run Protected Audience auctions. Then, Google and the partner no longer need to manually trigger a Protected Audience auction. The result of the Protected Audience auction isn't rendered. This allows us to test the integration at scale.

Reach out to your account manager or file a ticket through the Authorized Buyer Help Center when you're ready. Google will enable the account for this stage.

Stage 3: Rendering Experiment

Once Google and the partner have verified Protected Audience auctions at scale without rendering, Google can enable the partner to render the Protected Audience winning ad. Google has a small amount of traffic where Protected Audience auctions are eligible to run, and winning interest group ads are rendered. Participating bidders' in-browser bids compete with the traditional bids.

Reach out to your account manager or file a ticket through the Authorized Buyer Help Center when you're ready. Google will enable the account for this stage.

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

The following features are extensions of the core protocol.

Parallelization

Parallelization is an optimization that decreases end-to-end auction latency by initiating the contextual ad request in parallel with the requests to the buyer trusted servers specified in trustedBiddingSignalsUrl .

Parallelization reduces latency but affects interest group buyer eligibility and support for coordinated experiments . Parallelization applies to all bidders who participate in the on-device interest group auction. Bidders don't need to take action to participate in parallel auctions but should familiarize themselves with how parallelization may affect their eligibility in on-device auctions. Experiment group IDs for coordinated experiments are not yet supported within parallel auctions.

Serving flow summary

Here's a summary of the parallel auction flow:

On-device interest group buyer eligibility

For parallel auctions, navigator.runAdAuction 's call happens before the contextual ad response is returned. In order to initiate buyer trusted server calls, navigator.runAdAuction requires that the interestGroupBuyers parameter must be passed as a value, while the remaining auction parameters accept Javascript Promises that can be resolved after the contextual ad response. Since interestGroupBuyers is passed before the contextual ad response, the contextual ad response (including bid responses) cannot be used to choose which buyers participate in the parallelized auction for the given request. Instead Google's publisher tag caches, in the user's browser, the interestGroupBuyers parameter from previous navigator.runAdAuction executions on the same domain.

Parallelization has several important considerations:

1. Auction signals that aren't needed for buyer trusted server requests, such as perBuyerSignals , can continue to be specified in RTB bid responses in the same way as for non-parallelized auctions. Once the Promises for these signals are resolved, the remaining steps of the on-device auction will complete in the same manner as for the non-parallel auction flow.

2. Since parallelization relies on caching the list of interest group buyers, Google does not always run a parallel auction, as the parallelization cache may be empty or expired. If the cache is empty or expired, Google runs a standard non-parallel Protected Audience API auction and uses buyer intent to participate in the non-parallel auction to build the interest group buyer cache.

3. If at least one buyer for any bidder is cached for the current publisher domain, then Google will run a parallel auction, which will be indicated on the bid request:

   • Google RTB Protocol: BidRequest.adslot.interest_group_auction.parallelized
   • OpenRTB: BidRequest.imp.ext.interest_group_auction.parallelized

4. Each registered interest group buyer origin for a given bidder that was included in the parallel auction will have a corresponding ParallelAuctionBuyer entry:

   • Google RTB Protocol: BidRequest.adslot.interest_group_auction.parallel_auction_buyer
   • OpenRTB: BidRequest.imp.ext.interest_group_auction.pbuyer

5. If a parallel auction is run, but a specific buyer origin is not present in the cache, then that given buyer cannot be added to the current on-device auction. This is indicated by a request with parallelized=True that lacks a ParallelAuctionBuyer entry for a given interest group buyer origin. However, bidders that indicate interest by including valid and eligible InterestGroupBuyer (s) on their bid response will have the corresponding interest group buyer origins added to the cache, and those origins will be eligible for future parallelized requests from the same browser and domain. Intent to participate in interest group auctions can be indicated in the following fields:

   • Google RTB Protocol: BidResponse.adslot.interest_group_bidding.interest_group_buyers
   • OpenRTB: BidResponse.ext.igbid.igbuyer

6. Cached buyer origins (which are included in the parallel auction's interestGroupBuyers parameter) for which a bidder doesn't indicate intent to participate on their bid response may receive a buyer trusted server call but won't participate in the parallel auction.