راهنمای ادغام و آزمایش مخاطبان محافظت شده (که قبلاً به عنوان FLEDGE شناخته می شد) برای SSP

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

SSP ها می توانند API مخاطبان محافظت شده را با Display & Video 360 و Google Ads آزمایش کنند:

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

راهنمای زیر جزئیات یکپارچه سازی بین SSP و Display & Video 360 و Google Ads را شرح می دهد. SSP هایی که علاقه مند به هماهنگی یک آزمون هستند باید با نماینده مشارکت Display & Video 360 خود در تماس باشند.

ثبت نام

SSP ها باید خود را برای استفاده از API مخاطب محافظت شده ثبت کنند .

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

نمودار زیر جریان عمومی را نشان می دهد که نقاط تعامل اصلی بین Chrome، SSP، Display & Video 360 و Google Ads را مشخص می کند.

نمودار دنباله ای که درخواست های بین کروم، SSP و DSP را نشان می دهد

گزینه های یکپارچه سازی

گزینه 1: مستقیم / تک فروشنده

جریان درخواست دقیق برای حراج های تک فروشنده

مراحل:

  1. تگ تبلیغات SSP درخواست تبلیغ را به سرور SSP ارسال می کند که نشان می دهد مرورگر از API مخاطب محافظت شده پشتیبانی می کند.
  2. سرور SSP درخواست پیشنهاد پیشنهادی متنی OpenRTB را به DSP ارسال می کند که نشان می دهد مرورگر از API مخاطب محافظت شده پشتیبانی می کند.
  3. DSP با یک پاسخ پیشنهادی OpenRTB حاوی سیگنال‌هایی برای حراج روی دستگاه پاسخ می‌دهد.
  4. سرور SSP پاسخ آگهی را با پیکربندی حراج به تگ تبلیغات SSP ارسال می کند.
  5. تگ تبلیغات SSP حراج روی دستگاه را با فراخوانی runAdAuction() آغاز می‌کند و سیگنال‌های پاسخ پیشنهادی openRTB DSP را از طریق perBuyerSignals ارسال می‌کند.
  6. Chrome برای واکشی سیگنال‌های مناقصه در زمان واقعی ، سرور پیشنهادی DSP مورداعتماد Key/Value را فراخوانی می‌کند.
  7. کروم برای هر گروه ذینفع شرکت‌کننده، تابع DSP JavaScript generateBid() فرا می‌خواند.
  8. Chrome برای دریافت سیگنال‌های امتیازدهی هم‌زمان، سرور امتیازدهی کلید/مقدار مورد اعتماد SSP را فراخوانی می‌کند.
  9. کروم تابع SSP JavaScript scoreAd() برای هر گروه ذینفع شرکت‌کننده فراخوانی می‌کند.
  10. کروم تابع reportWin() DSP JavaScript را فراخوانی می کند تا برنده را به DSP گزارش دهد.
  11. کروم تابع reportResult() SSP جاوا اسکریپت را برای گزارش برنده به SSP فراخوانی می کند.

حداقل تغییرات در سمت SSP

  • برچسب تبلیغات SSP باید به روز شود

    • تشخیص دهید که آیا مرورگر از API مخاطبان محافظت شده پشتیبانی می کند یا خیر
    • ارسال آن اطلاعات به عنوان بخشی از درخواست تبلیغات به سرور SSP [1]
    • با فراخوانی runAdAuction() که سیگنال‌هایی را از پاسخ پیشنهادی OpenRTB [5] DSP ارسال می‌کند، حراج روی دستگاه را آغاز کنید (به قسمت داده خریدار در مورد درخواست پیشنهاد و ساختار پاسخ در زیر مراجعه کنید).
  • سرور SSP نیاز دارد

    • اطلاعات مربوط به پشتیبانی از API مخاطبان محافظت شده به DSP را از طریق فیلد موجود در درخواست پیشنهادی OpenRTB [2] منتشر کنید (به بخش ساختار درخواست پیشنهاد و پاسخ در زیر مراجعه کنید).
    • سیگنال‌های خریدار DSP را در پاسخ پیشنهادی OpenRTB به برچسب آگهی SSP منتشر کنید (به بخش ساختار درخواست پیشنهاد / پاسخ پیشنهادی در زیر مراجعه کنید) [4]
  • [Optional] SSP برای واکشی سیگنال‌های امتیازدهی بی‌درنگ برای پشتیبانی از بررسی‌های کیفیت آگهی، اجرای تنظیمات ناشر، باید سرور SSP مورد اعتماد را پیاده‌سازی کند [8]

  • SSP نیاز به پیاده سازی جاوا اسکریپت با توابع "scoreAd(...)" و "reportResult(...)" [9] ، [11]

گزینه 2: چند فروشنده

جریان درخواست دقیق برای حراج های چند فروشنده

مراحل:

  1. آداپتور SSP درخواست تبلیغ را به سرور SSP ارسال می کند که نشان می دهد مرورگر از API مخاطب محافظت شده پشتیبانی می کند.
  2. سرور SSP درخواست پیشنهاد پیشنهادی متنی OpenRTB را به DSP ارسال می کند که نشان می دهد مرورگر از API مخاطب محافظت شده پشتیبانی می کند.
  3. سرور DSP با پاسخ پیشنهادی openRTB حاوی سیگنال هایی برای حراج روی دستگاه پاسخ می دهد.
  4. سرور SSP پاسخ آگهی را با پیکربندی حراج به تگ تبلیغات SSP ارسال می کند.
  5. آداپتور SSP Prebid پیکربندی حراج مؤلفه را به برچسب سرور آگهی ناشر ارائه می دهد.
  6. برچسب سرور آگهی ناشر درخواست تبلیغ را به سرور سرور آگهی ناشر ارسال می کند.
  7. تگ Publisher Ad Server با فراخوانی runAdAuction(...) API حراج روی دستگاه را آغاز می کند.
  8. Chrome برای واکشی سیگنال‌های مناقصه در زمان واقعی ، سرور پیشنهادی DSP مورداعتماد Key/Value را فراخوانی می‌کند.
  9. کروم تابع جاوا اسکریپت DSP generateBid() geneBid را برای هر گروه مشارکت کننده فراخوانی می کند.
  10. Chrome برای دریافت سیگنال‌های امتیازدهی هم‌زمان، سرور امتیازدهی کلید/مقدار مورد اعتماد SSP را فراخوانی می‌کند.
  11. کروم تابع SSP JavaScript scoreAd() برای هر گروه ذینفع شرکت‌کننده فراخوانی می‌کند.
  12. کروم تابع reportWin() DSP JavaScript را فراخوانی می کند تا برنده را به DSP گزارش دهد.
  13. کروم تابع reportResult() SSP جاوا اسکریپت را برای گزارش برنده به SSP فراخوانی می کند.

حداقل تغییرات در سمت SSP

  • آداپتور SSP باید به روز شود

  • سرور SSP نیاز دارد

    • اطلاعات مربوط به پشتیبانی مخاطب محافظت شده را به DSP از طریق فیلد موجود در درخواست پیشنهادی OpenRTB [2] منتشر کنید (به بخش ساختار درخواست پیشنهاد و پاسخ در زیر مراجعه کنید).
    • سیگنال‌های خریدار DSP را در پاسخ پیشنهادی OpenRTB به برچسب آگهی SSP منتشر کنید (به بخش ساختار درخواست پیشنهاد / پاسخ پیشنهادی در زیر مراجعه کنید) [4]
  • [Optional] SSP برای واکشی سیگنال‌های امتیازدهی بی‌درنگ برای پشتیبانی از بررسی‌های کیفیت آگهی، اجرای تنظیمات ناشر، باید سرور SSP مورد اعتماد را پیاده‌سازی کند [10]

  • SSP باید جاوا اسکریپت را با توابع scoreAd() و reportResult() نمایش دهد [11] ، [14] .

خدمات مناقصه و مزایده

ما از نزدیک در حال ارزیابی proposal خدمات مناقصه و مزایده (B&A) هستیم.

وقتی Display & Video 360 برای آزمایش API مخاطب محافظت شده با B&A آماده شد، با جزئیات بیشتر تماس خواهیم گرفت.

پروتکل OpenRTB

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

برای تمایز بین فرصت‌های نمایشی که از حراج روی دستگاه API محافظت‌شده مخاطبان پشتیبانی می‌کنند از مزایده‌هایی که فقط از حراج استاندارد تبادل سمت سرور پشتیبانی می‌کنند، یک فیلد enum جدید به نام ae برای «محیط حراج» باید به‌عنوان پسوندی به شی Imp در OpenRTB اضافه شود. درخواست پیشنهاد برای تعیین اینکه کدام محیط حراج توسط اسلات نمایش داده شده پشتیبانی می شود. ae enum می تواند مقادیر زیر را داشته باشد:

  • 0 : حراج های استاندارد سمت سرور
  • 1 : درخواست‌هایی با پشتیبانی از مخاطبین محافظت‌شده API، که در آن یک حراج متنی روی سرورهای صرافی اجرا می‌شود و گروه ذینفع پیشنهاد می‌دهد و حراج نهایی در مرورگر اجرا می‌شود.
{
  "id": 
  "imp": [{
    "id": "1"
    "video": {...}
    "ext": {
      "ae": 1
    }]
}

پاسخ پیشنهاد

علاوه بر پیشنهادهای متنی، از پاسخ پیشنهادی نیز برای ارسال اطلاعات مربوط به Display & Video 360 و مشارکت Google Ads در حراج‌های گروه علاقه‌مندی API مخاطب محافظت شده استفاده می‌شود. پاسخ پیشنهاد برای حمایت از مزایده های گروه ذینفع به شرح زیر به روز می شود:

{
  "seatbid": [{
    "bid": [{
       // Traditional contextual bids
    }]
  }],

  "ext": {
    // InterestGroupBidding object which holds information for running an
    // in-browser interest group auction.
    "igbid": [{
      // ID of the Imp object of the impression to which
      // these interest group bidding signals apply to.
      "impid": "1",

      // InterestGroupBuyer object which holds DSP information for the in-browser
      // auction.
      "igbuyer": [{
        // Origin of Display & Video 360 and Google Ads to participate in the
        // interest group auction. For more info regarding the origin see:
        // https://developer.mozilla.org/en-US/docs/Glossary/Origin
        "origin": "https://td.doubleclick.net",

        // Buyer-specific signals to use in auctionConfig as perBuyerSignals.
        // Used by the buyer's interest group bidding function. Can be left empty
        "buyerdata": ...,

        // Buyer experiment group id to support coordinated experiments with
        // buyers' trusted servers. This experiment id should be added to the
        // `perBuyerExperimentGroupIds` map in auctionConfig.
        "buyer_experiment_group_id": 12345
      }]
    }]
  }
}

سناریوهای زیر پشتیبانی می شوند.

  • سناریو 1: Display & Video 360 و Google Ads فقط می خواهند در یک حراج متنی شرکت کنند. در این سناریو فیلد igbid وجود ندارد.

  • سناریو 2: Display & Video 360 و Google Ads فقط می‌خواهند در حراج گروه علاقه‌مند شرکت کنند. در این سناریو Display & Video 360 و Google Ads فیلد seatbid را در پاسخ پیشنهاد حذف می‌کنند و فقط اطلاعات igbid را برمی‌گردانند. به عبارت دیگر وجود فیلد igbid بیانگر این واقعیت است که Display & Video 360 و Google Ads می خواهند گروه های ذینفع خود در مزایده روی دستگاه شرکت کنند.

  • سناریو 3: Display & Video 360 و Google Ads می‌خواهند در حراج‌های متنی و گروهی علاقه‌مند شرکت کنند. در این سناریو Display & Video 360 و Google Ads هر دو قسمت seatbid را در پاسخ پیشنهاد قیمت و اطلاعات igbid را برمی‌گردانند.

فراداده با آگهی Bid

Protected Audience API اجازه می دهد passing arbitrary metadata در مورد آگهی از تابع generateBid() ارسال شود.

Display & Video 360 در حال برنامه ریزی برای تکیه بر specification زیر برای فراداده تبلیغات است: API مخاطب محافظت شده و OpenRTB.

یعنی Display & Video 360 فیلدهای زیر را به عنوان بخشی از شیء تبلیغ برمی گرداند:

ویژگی PA تایپ کنید توضیحات OpenRTB
ad.seat رشته؛ مورد نیاز است شناسه صندلی خریدار (به عنوان مثال، تبلیغ کننده، آژانس) که این پیشنهاد از طرف او انجام شده است.
ad.domain رشته[] دامنه تبلیغ کننده برای بررسی لیست بلوک (به عنوان مثال، "ford.com"). این می تواند آرایه ای از برای مورد خلاقیت های چرخشی باشد. صرافی ها می توانند الزام کنند که فقط یک دامنه مجاز است.
ad.cid رشته شناسه کمپین برای کمک به بررسی کیفیت تبلیغات.
ad.crid رشته شناسه خلاق برای کمک به بررسی کیفیت آگهی.
ad.language رشته زبان خلاق با استفاده از ISO-639-1-alpha-2. در صورتی که خلاقیت محتوای زبانی نداشته باشد (مثلاً یک بنر فقط با یک آرم شرکت) ممکن است از کد غیر استاندارد "xx" نیز استفاده شود. فقط یکی از زبان یا langb باید وجود داشته باشد.
ad.w عدد صحیح عرض خلاقیت در پیکسل های مستقل دستگاه (DIPS).
ad.h عدد صحیح ارتفاع خلاقیت در پیکسل های مستقل از دستگاه (DIPS).

مثال

{
  "seat": "123"
  "adomain": ["example.com"]
  "cid": "12345"
  "crid": "12345"
  "language": "en"
  "w": 300
  "h": 250
}

گزارش رویداد

Protected Audience API یک API گزارش در سطح رویداد را ارائه می دهد که در این پست GitHub شرح داده شده است: Fenced Frame Ads Reporting . حتی اگر در نام می‌گوید Fenced Frame Ads Reporting API هم در قاب‌های حصاردار و هم iframe در دسترس است (جزئیات را here ببینید).

SSP می تواند با فراخوانی registerAdBeacon() API یک URL با مرورگر در تابع reportResult خود ثبت کند.

Display & Video 360 API reportEvent() با مقصد 'component-seller' از داخل خلاقیت فراخوانی می‌کند تا نمایش‌ها و رویدادها را گزارش کند. این منجر به ارسال یک چراغ به URL ثبت شده می شود.

توجه داشته باشید که Display & Video 360 API reportEvent() برای نمایش‌ها و کلیک‌ها با داده‌های پست خالی فراخوانی می‌کند.

مثال

registerAdBeacon({
 'impression': 'https://ssp.example/impression?ssp_event_id=abc',
});
registerAdBeacon({
 'click': 'https://ssp.example/click?ssp_event_id=abc',
});

Display & Video 360 در Chrome-facilitated testing برای منسوخ شدن کوکی های شخص ثالث شرکت می کند. برای اینکه بتوانیم آزمایش را انجام دهیم، از شرکا می‌خواهیم که برچسب‌های Chrome را در درخواست پیشنهاد قیمت OpenRTB طبق specification زیر به ما منتقل کنند:

شیء: Device.ext

صفت تایپ کنید توضیحات
cdep رشته برچسب دریافتی از Chrome یا شریک بالادستی.