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

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

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

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

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

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

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

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

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

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

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 به‌عنوان یک بعد جدید در ابزار گزارش‌دهی مجاز خریدار، به‌عنوان بعد شناسه گزارش خریدار ظاهر می‌شود.

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

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

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

• پیوند اولیه پروتکل RTB Google
• پیوند اولیه OpenRTB

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

درخواست های پیشنهادی دارای یک فیلد جدید، 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

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

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

به عنوان کاهشی که در طول آزمایش 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 مخاطب محافظت شده مراجعه کنید.

ماکروها

توجه: ماکروها برای آزمایش 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)	این ماکروها عرض و ارتفاع اسلات آگهی را درج می کنند.

شمارش برداشت

در طول آزمایش 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 با ماکروهای انتخابی جایگزین می‌شود. ماکروهای زیر پشتیبانی می شوند:

• %%GOOGLE_QUERY_ID%% BidRequest.ext.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 وابسته است.

روی رویدادها کلیک کنید

پیشنهاد دهندگان می‌توانند رویدادهای کلیک روی تبلیغات مخاطب محافظت‌شده را با استفاده از Fenced Frame Reporting API به Google گزارش دهند. پیشنهاد دهندگان باید از نوع رویداد click استفاده کنند تا گوگل را از کلیک ها مطلع کنند. در اینجا یک مثال است:

window.fence.reportEvent({
    'eventType': 'click',
    // Google does not require bidders to send data to Google in 'eventData'.
    // However, 'eventData' must be a non-null value, such as an empty string.
    'eventData': '',
    'destinations': ['direct-seller']
});

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

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