با استفاده از Protected Audience API از هدف گیری مخاطبان سفارشی پشتیبانی کنید

بازخورد ارائه دهید

به روز رسانی های اخیر

• اطلاعاتی درباره زمان‌بندی به‌روزرسانی‌های سفارشی مخاطبان اضافه شد
• افزودن یکپارچه سازی Attribution Reporting با مخاطبان محافظت شده
• جدول زمانی ویژگی‌های مخاطب محافظت شده را منتشر کرد.
• FLEDGE به API مخاطب محافظت شده تغییر نام داده است.
• پیشنهاد برای تفویض اختیار مخاطبان سفارشی اضافه شد.
• الزام ناشناس بودن k برای URL به‌روزرسانی روزانه حذف شد.

مخاطب محافظت شده در نسخه بتا است و برای آزمایش در دستگاه های عمومی در دسترس است!

با مخاطبین محافظت شده، می توانید:

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

برای شروع، راهنمای برنامه‌نویس مخاطب محافظت شده را بخوانید. با ادامه توسعه مخاطبین محافظت شده، از بازخورد شما قدردانی می شود.

جدول زمانی

ما ویژگی های جدید را در ماه های آینده منتشر خواهیم کرد. تاریخ انتشار دقیق بسته به ویژگی متفاوت خواهد بود و این جدول با در دسترس قرار گرفتن با پیوندهایی به اسناد به روز می شود.

نمای کلی

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

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

API مخاطب محافظت شده در Android (که قبلاً به عنوان FLEDGE شناخته می شد) شامل API های زیر برای پلتفرم های فناوری تبلیغات و تبلیغ کنندگان است تا از موارد استفاده متداول مبتنی بر تعامل پشتیبانی کند به گونه ای که اشتراک گذاری هر دو شناسه در بین برنامه ها و اطلاعات تعامل برنامه کاربر با ثالث را محدود می کند. احزاب:

1. API مخاطبان سفارشی : این بر انتزاع "مخاطبان سفارشی" متمرکز است که نشان دهنده مخاطبان تعیین شده توسط تبلیغ کننده با اهداف مشترک است. اطلاعات مخاطب در دستگاه ذخیره می‌شود و می‌تواند با تبلیغات نامزد مربوطه برای مخاطبان و فراداده‌های دلخواه، مانند سیگنال‌های پیشنهادی مرتبط شود. از این اطلاعات می توان برای اطلاع رسانی پیشنهادات آگهی دهنده، فیلتر کردن آگهی و رندر استفاده کرد.
2. Ad Selection API : این چارچوبی را فراهم می کند که جریان های کاری پلتفرم های فناوری تبلیغات را تنظیم می کند که از سیگنال های روی دستگاه برای تعیین یک تبلیغ "برنده" با در نظر گرفتن تبلیغات نامزد ذخیره شده در محل و انجام پردازش اضافی بر روی تبلیغات نامزدی که یک پلت فرم فناوری تبلیغات به آن بازمی گرداند، استفاده می کند. دستگاه

در سطح بالا، ادغام به شرح زیر عمل می کند:

1. SportingGoodsApp می‌خواهد به کاربران خود یادآوری کند که اگر در عرض 2 روز خرید را انجام ندادند، کالاهای موجود در سبد خرید خود را خریداری کنند. SportingGoodsApp از Custom Audience API برای اضافه کردن کاربر به لیست مخاطبان "محصولات در سبد خرید" استفاده می کند. پلتفرم این فهرست مخاطبان را در دستگاه مدیریت و ذخیره می‌کند و اشتراک‌گذاری با اشخاص ثالث را محدود می‌کند. SportingGoodsApp با یک پلت فرم فناوری تبلیغات شریک می شود تا تبلیغات خود را به کاربران در لیست مخاطبان خود نشان دهد. پلتفرم فناوری تبلیغات، ابرداده‌ها را برای فهرست‌های مخاطبان مدیریت می‌کند و تبلیغات نامزد را ارائه می‌کند، که برای بررسی در اختیار گردش کار انتخاب آگهی قرار می‌گیرد. این پلت فرم را می توان به گونه ای پیکربندی کرد که به صورت دوره ای آگهی های به روز شده مبتنی بر مخاطب را در پس زمینه دریافت کند . این کمک می کند تا لیست تبلیغات نامزد مبتنی بر مخاطبان تازه و نامرتبط با درخواست های ارسال شده به سرورهای تبلیغاتی شخص ثالث در طول فرصت تبلیغات (یعنی درخواست آگهی متنی) باقی بماند.

2. هنگامی که کاربر FrisbeeGame را در همان دستگاه بازی می‌کند، ممکن است تبلیغی را ببیند که به او یادآوری می‌کند تا خرید اقلام باقی‌مانده در سبد خرید SportingGoodsApp را تکمیل کند. این را می توان با استفاده از FrisbeeGame (با یک SDK تبلیغات یکپارچه) با فراخوانی Ad Selection API برای انتخاب یک تبلیغ برنده برای کاربر بر اساس فهرست مخاطبانی که ممکن است بخشی از آن باشند (در این مثال، مخاطبان سفارشی "محصولات در سبد خرید" به دست آورد. ایجاد شده توسط SportingGoodsApp). گردش کار انتخاب آگهی را می توان به گونه ای تنظیم کرد که تبلیغات بازیابی شده از سرورهای پلتفرم های فناوری تبلیغات، علاوه بر تبلیغات روی دستگاه مرتبط با مخاطبان سفارشی و همچنین سایر سیگنال های روی دستگاه را در نظر بگیرد. گردش کار همچنین می‌تواند توسط پلتفرم فناوری تبلیغات و SDK تبلیغات با پیشنهاد سفارشی و منطق امتیازدهی برای دستیابی به اهداف تبلیغاتی مناسب سفارشی شود. این رویکرد علاقه کاربر یا داده‌های تعامل برنامه را قادر می‌سازد تا از انتخاب تبلیغات مطلع شود، در حالی که اشتراک‌گذاری این داده‌ها با اشخاص ثالث را محدود می‌کند.

3. برنامه ارائه آگهی یا SDK پلت فرم فناوری تبلیغات، آگهی انتخابی را ارائه می دهد.

4. این پلت فرم گزارش برداشت ها و نتایج انتخاب آگهی را تسهیل می کند. این قابلیت گزارش‌دهی مکمل API Attribution Reporting است. پلتفرم‌های فناوری تبلیغات ممکن است بر اساس نیازهای گزارش‌دهی خود سفارشی‌سازی کنند.

در APIهای Android به مخاطبین محافظت شده دسترسی پیدا کنید

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

مدیریت مخاطبان سفارشی

مخاطب سفارشی

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

یک برنامه تبلیغ‌کننده یا SDK یکپارچه ممکن است به یک مخاطب سفارشی بپیوندد یا بر اساس مشارکت کاربر در یک برنامه، به عنوان مثال، آن را ترک کند .

فراداده مخاطب سفارشی

هر مخاطب سفارشی حاوی متادیتای زیر است:

• مالک: نام بسته برنامه مالک. این به طور ضمنی روی نام بسته برنامه تماس گیرنده تنظیم شده است.
• خریدار: شبکه تبلیغاتی خریدار که تبلیغات را برای این مخاطبان سفارشی مدیریت می کند. خریدار همچنین نماینده طرفی است که ممکن است به مخاطبان سفارشی دسترسی داشته باشد و اطلاعات مربوط به آگهی را دریافت کند. خریدار طبق فرمت eTLD+1 مشخص شده است.
• نام: یک نام یا شناسه دلخواه برای مخاطبان سفارشی، مانند کاربری که دارای «رهاکننده سبد خرید» است. این ویژگی می‌تواند به‌عنوان مثال، به‌عنوان یکی از معیارهای هدف‌یابی در کمپین‌های تبلیغاتی تبلیغ‌کننده، یا یک رشته جستجو در URL برای واکشی کد مناقصه استفاده شود.
• زمان فعال سازی و زمان انقضا: این فیلدها پنجره زمانی را مشخص می کنند که این مخاطبان سفارشی موثر خواهند بود. این پلتفرم از این اطلاعات برای حذف عضویت از مخاطبان سفارشی استفاده می کند. زمان انقضا برای محدود کردن عمر مخاطب سفارشی نمی تواند از حداکثر پنجره مدت تجاوز کند.
• URL به روز رسانی روزانه: نشانی اینترنتی که پلتفرم برای واکشی تبلیغات نامزد و سایر ابرداده‌های تعریف شده در فیلدهای «سیگنال‌های مناقصه کاربر» و «سیگنال‌های مناقصه قابل اعتماد» به صورت مکرر استفاده می‌کند. برای جزئیات بیشتر، به بخش نحوه واکشی تبلیغات نامزد برای مخاطبان سفارشی مراجعه کنید.
• سیگنال‌های مناقصه کاربر: سیگنال‌های ویژه پلتفرم فناوری تبلیغات برای هرگونه پیشنهاد تبلیغات بازاریابی مجدد. نمونه هایی از سیگنال ها عبارتند از: مکان درشت کاربر، منطقه ترجیحی، و غیره.
• داده‌های پیشنهادی مورد اعتماد: پلتفرم‌های فناوری تبلیغات برای اطلاع‌رسانی به بازیابی آگهی و امتیازدهی به داده‌های هم‌زمان متکی هستند. برای مثال، ممکن است بودجه یک آگهی تمام شود و باید فوراً پخش آن متوقف شود. یک Ad-tech می‌تواند یک نقطه پایانی URL را از جایی که این داده‌های بی‌درنگ واکشی می‌شود و مجموعه کلیدهایی که باید جستجوی بی‌درنگ برای آن‌ها انجام شود، تعریف کند. سروری که این درخواست را مدیریت می کند یک سرور قابل اعتماد خواهد بود که توسط پلت فرم فناوری تبلیغات مدیریت می شود.
• URL منطقی مناقصه: نشانی اینترنتی که پلتفرم از آن برای دریافت کد مناقصه از پلتفرم سمت تقاضا استفاده می کند. پلتفرم این مرحله را زمانی انجام می دهد که یک مزایده تبلیغاتی شروع شود .
• تبلیغات: لیستی از تبلیغات نامزد برای مخاطبان سفارشی. این شامل ابرداده های تبلیغاتی خاص پلتفرم فناوری تبلیغات و یک URL برای ارائه آگهی است. هنگامی که یک حراج برای مخاطبان سفارشی آغاز می شود، این لیست از ابرداده های آگهی در نظر گرفته می شود. در صورت امکان، این لیست از تبلیغات با استفاده از نقطه پایانی URL به روز رسانی روزانه به روز می شود. به دلیل محدودیت منابع در دستگاه های تلفن همراه، محدودیتی در تعداد تبلیغاتی که می توان در یک مخاطب سفارشی ذخیره کرد وجود دارد.

هیئت مخاطبان سفارشی

تعریف و پیکربندی مخاطب سفارشی سنتی معمولاً به فناوری‌ها و ادغام‌های سمت سرور متکی است که توسط فناوری‌های تبلیغاتی در مشارکت با مشتریان و شرکای آژانس و تبلیغ‌کننده هدایت می‌شوند. Protected Audience API تعریف و پیکربندی مخاطب سفارشی را در عین محافظت از حریم خصوصی کاربر فعال می کند. برای پیوستن به مخاطبان سفارشی، فناوری‌های تبلیغاتی خریدار که در برنامه‌ها حضور SDK ندارند، باید با فناوری‌های تبلیغاتی که در دستگاه حضور دارند، مانند شرکای اندازه‌گیری تلفن همراه (MMP) و پلت‌فرم‌های طرف عرضه (SSP) همکاری کنند. هدف برنامه Protected Audience API پشتیبانی از این SDKها با ارائه راه‌حل‌های انعطاف‌پذیر برای مدیریت مخاطبان سفارشی است که از طریق تماس‌گیرندگان دستگاه امکان ایجاد مخاطب سفارشی از طرف خریداران را فراهم می‌کند. به این فرآیند تفویض اختیار مخاطب سفارشی می گویند. با دنبال کردن این مراحل، تفویض مخاطبان سفارشی را پیکربندی کنید:

به یک مخاطب سفارشی بپیوندید

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

joinCustomAudience()

یک برنامه یا SDK می‌تواند با فراخوانی joinCustomAudience() پس از نمونه‌سازی شی CustomAudience با پارامترهای مورد انتظار، درخواست ملحق شدن به یک مخاطب سفارشی کند. در اینجا یک نمونه قطعه کد گویا آمده است:

CustomAudience audience = new CustomAudience(
    Buyer = "example-dsp.com",
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    DailyUpdateURL = Uri.parse("https://..."),
    UserBiddingSignals = new JSONObject("{...}"),
    TrustedBiddingURL = Uri.parse("https://..."),
    TrustedBiddingKeys = {'key1","key2", ...,"key n"},
    BiddingLogicURL =  Uri.parse("https://..."),
    Ads = [new AdData(renderUrl = Uri.parse("https://..."),
           metadata = new JSONObject("{...}"), ...];

// Invoke ad services API to join a custom audience.
joinCustomAudience(audience);

fetchAndJoinCustomAudience()

یک برنامه یا SDK می‌تواند با فراخوانی fetchAndJoinCustomAudience() با پارامترهای مورد انتظار، مانند مثال زیر، از طرف یک فناوری تبلیغاتی که در دستگاه حضور ندارد، درخواست ملحق شدن به یک مخاطب سفارشی کند:

FetchAndJoinCustomAudienceRequest fetchRequest = new FetchAndJoinCustomAudienceRequest(
    // Example: Optional verification token passed inside the fetch URL
    FetchURI = Uri.parse("https://example-dsp.com/...?mytoken=arbitrary1234"),
    // All the following parameters are optional
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    UserBiddingSignals = new JSONObject("{...}")
);

fetchAndJoinCustomAudience(fetchRequest);

نقطه پایانی URL، متعلق به خریدار، با یک شی JSON CustomAudience در بدنه پاسخ پاسخ می دهد. فیلدهای خریدار و مالک مخاطبان سفارشی نادیده گرفته می شوند (و توسط API به صورت خودکار پر می شوند). API همچنین اجبار می‌کند که URL به‌روزرسانی روزانه با eTLD+1 خریدار نیز مطابقت داشته باشد.

{
 "name": "running-shoes",
 "activation_time": 1680603133000,
 "expiration_time": 1680803133000,
 "user_bidding_signals" : {"signal1": "value"},
 "trusted_bidding_data": {
    "trusted_bidding_uri": "https://example-dsp.com/.."
    "trusted_bidding_keys": ["k1", "k2"],
 },
 "bidding_logic_uri": "https://example-dsp.com/...",
 "daily_update_uri": "https://example-dsp.com/...",
 "ads": [
   {
     "render_uri": "https://example-dsp.com/...",
     "metadata": {},
     "ad_filters": {
       "frequency_cap": {
         "win": [
           {
             "ad_counter_key": 1,
             "max_count": 2,
             "interval_in_seconds": 60
           },
         ],
         "view": [
           {
             "ad_counter_key": 2,
             "max_count": 10,
             "interval_in_seconds": 3600
           },
         ]
       },
       "app_install": {
         "package_names": [
           "package.name.one",
           "package.name.two", ...
         ]
       }
     }
   },
   ...
 ]
}

API fetchAndJoinCustomAudience() هویت خریدار را از eTLD+1 fetchUri تعیین می کند. هویت خریدار CustomAudience برای انجام همان بررسی‌های ثبت‌نام و مجوز برنامه که توسط joinCustomAudience() انجام می‌شود استفاده می‌شود و با پاسخ واکشی قابل تغییر نیست. مالک CustomAudience نام بسته برنامه تماس است. هیچ اعتبارسنجی دیگری به جز چک eTLD+1 برای fetchUri وجود ندارد و به طور خاص، هیچ بررسی k-anon وجود ندارد. API fetchAndJoinCustomAudience() یک درخواست HTTP GET برای fetchUri صادر می کند و انتظار دارد یک شی JSON نماینده مخاطب سفارشی باشد. همان محدودیت‌های اجباری، اختیاری و مقادیر پیش‌فرض برای فیلدهای شی مخاطب سفارشی به پاسخ اعمال می‌شود. در راهنمای برنامه نویس ما با الزامات و محدودیت های فعلی آشنا شوید.

هرگونه پاسخ خطای HTTP از طرف خریدار باعث می شود fetchAndJoinCustomAudience با شکست مواجه شود. به ویژه یک پاسخ وضعیت HTTP 429 (درخواست‌های خیلی زیاد) درخواست‌های برنامه فعلی را برای یک دوره مشخص مسدود می‌کند. اگر پاسخ خریدار بد شکل باشد، تماس API نیز با شکست مواجه می‌شود. خرابی‌ها به تماس‌گیرنده API گزارش می‌شوند که مسئول تلاش مجدد به دلیل خرابی‌های موقتی (مانند پاسخ ندادن سرور) یا مدیریت خرابی‌های مداوم (مانند خرابی‌های اعتبارسنجی داده یا سایر خطاهای غیر گذرا در ارتباط با سرور) هستند.

شی CustomAudienceFetchRequest به تماس گیرنده API اجازه می دهد تا با استفاده از ویژگی های اختیاری نشان داده شده در مثال بالا، برخی از اطلاعات را برای مخاطبان سفارشی تعریف کند. اگر در درخواست تنظیم شده باشد، این مقادیر نمی توانند توسط پاسخ خریدار دریافت شده توسط پلت فرم بازنویسی شوند. Protected Audience API فیلدهای موجود در پاسخ را نادیده می گیرد. اگر در درخواست تنظیم نشده باشند، باید در پاسخ تنظیم شوند، زیرا این فیلدها برای ایجاد یک مخاطب سفارشی مورد نیاز هستند. یک نمایش JSON از محتوای CustomAudience که تا حدی توسط فراخوان API تعریف شده است، در درخواست GET برای fetchUri در یک هدر ویژه X-CUSTOM-AUDIENCE-DATA گنجانده شده است. اندازه فرم سریال داده های مشخص شده برای مخاطبان سفارشی به 8 کیلوبایت محدود شده است. اگر اندازه بیش از اندازه باشد، تماس API fetchAndJoinCustomAudience ناموفق است.

عدم وجود چک k-anon به شما امکان می دهد از fetchUri برای تأیید خریدار استفاده کنید و امکان اشتراک گذاری اطلاعات بین خریدار و SDK را فعال کنید. برای تسهیل راستی‌آزمایی مخاطبان سفارشی، این امکان برای خریدار وجود دارد که یک رمز تأیید ارائه کند. SDK روی دستگاه باید این نشانه را در fetchUri داشته باشد تا نقطه پایانی میزبانی شده توسط خریدار بتواند محتویات مخاطبان سفارشی را واکشی کند و از رمز تأیید برای تأیید اینکه عملیات fetchAndJoinCustomAudience() با خریدار مطابقت دارد و از یک سایت قابل اعتماد منشا گرفته است استفاده کند. شریک دستگاه برای اشتراک‌گذاری اطلاعات، خریدار می‌تواند با تماس‌گیرنده روی دستگاه موافقت کند که برخی از اطلاعات مورد استفاده برای ایجاد مخاطب سفارشی به‌عنوان پارامترهای جستجو به fetchUri اضافه شود. این به خریدار اجازه می‌دهد تا تماس‌ها را بررسی کند و تشخیص دهد که آیا یک نشانه اعتبارسنجی توسط یک فناوری تبلیغات مخرب برای ایجاد چندین مخاطب سفارشی مختلف استفاده شده است یا خیر.

یادداشتی در مورد تعریف رمز تأیید و ذخیره سازی

• کد تأیید برای هیچ هدفی توسط Protected Audience API استفاده نمی شود و اختیاری است.

  • رمز تأیید ممکن است توسط خریدار برای تأیید اینکه مخاطبان ایجاد شده از طرف آنها انجام می شوند استفاده شود.
  • پیشنهاد Protected Audience API نه قالبی برای رمز تأیید و نه نحوه انتقال رمز تأیید توسط خریدار به تماس‌گیرنده مشخص می‌کند. به عنوان مثال، رمز تأیید می‌تواند از قبل در SDK یا باطن مالک بارگذاری شود، یا می‌توان آن را در زمان واقعی توسط SDK مالک از سرور خریدار بازیابی کرد.

یک مخاطب سفارشی بگذارید

صاحب یک مخاطب سفارشی می‌تواند با فراخوانی leaveCustomAudience() را ترک کند، همانطور که در قطعه کد تصویری زیر نشان داده شده است:

// Invoke ad services API to leave a custom audience.
leaveCustomAudience(buyer, name);

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

کنترل کاربر

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

طراحی این قابلیت در حال انجام است و جزئیات آن در آپدیت بعدی درج خواهد شد.

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

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

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

/**
* API To schedule delayed update events for Custom Audience
*
* @param request Criteria that determine when and where to trigger a call to a
* DSP endpoint to update one or more Custom Audiences
*/

public void scheduleCustomAudienceUpdate(
    @NonNull ScheduleCustomAudienceUpdateRequest request,
    @NonNull @CallBackExecutor Executor executor,
    @NonNull AdServicesOutcomeReceiver<Object, Exception> receiver)

ScheduleCustomAudienceUpdateRequest

public final class ScheduleCustomAudienceUpdateRequest {
  // Required Field
  @NonNull public Uri getUpdateUri() {
    return mUpdateUri;
  }

  // Required Field
  @NonNull public Duration getMinDelay() {
    return mMinDelay;
  }

  //  Required Field
  @NonNull public List<PartialCustomAudience> getPartialCustomAudienceList() {
    return mPartialCustomAudiences;
  }

  //  Optional Field (default false)
  public boolean shouldReplacePendingUpdates () {
    return mShouldReplacePendingUpdates;
  }
}

ScheduleCustomAudienceUpdateRequest حاوی اطلاعات لازم برای ثبت یک کار تاخیری برای اجرا با پلتفرم است. پس از تأخیر مشخص شده، یک کار پس زمینه به صورت دوره ای اجرا می شود و درخواست (ها) را ارسال می کند. ScheduleCustomAudienceUpdateRequest می تواند حاوی اطلاعات زیر باشد:

• UpdateUri : نقطه پایانی URI که یک تماس GET برای دریافت به‌روزرسانی ارسال می‌شود. هویت خریدار ذاتاً از eTLD+1 استنباط می‌شود و نیازی به ارائه صریح نیست و با پاسخ به‌روزرسانی نمی‌توان آن را تغییر داد. درخواست GET انتظار دارد یک شی JSON حاوی لیستی از اشیاء customAudience در ازای آن باشد.
• DelayTime : زمان نشان دهنده تأخیر از زمان برقراری فراخوانی API scheduleCustomAudienceUpdate() برای برنامه ریزی به روز رسانی است.

• PartialCustomAudience : API همچنین به SDK روی دستگاه اجازه می دهد تا لیستی از مخاطبان سفارشی ساخته شده را ارسال کند. این به SDK های درون برنامه ای اجازه می دهد تا نقش دوگانه را ایفا کنند، از کنترل کامل تا جزئی بر مدیریت مخاطبان سفارشی بر اساس مشارکت آنها با DSP.

  • این همچنین این API را با API fetchAndJoinCustomAudience() که امکان به اشتراک گذاری اطلاعات مشابه را فراهم می کند، سازگار نگه می دارد.

• ShouldReplacePendingUpdates : Boolean که تعیین می کند آیا هر به روز رسانی برنامه ریزی شده معلق باید لغو شود و با به روز رسانی که در ScheduleCustomAudienceUpdateRequest فعلی توضیح داده شده است جایگزین شود. اگر این مقدار روی false تنظیم شود و به‌روزرسانی‌های درخواستی قبلی همچنان برای همان خریدار در همان برنامه در حال تعلیق باشد، تماس با scheduleCustomAudienceUpdate با این ScheduleCustomAudienceUpdateRequest ناموفق خواهد بود. پیش فرض ها به false .

مجوزها و کنترل برنامه

این پیشنهاد قصد دارد کنترل برنامه ها را بر روی مخاطبان سفارشی خود ارائه دهد:

• یک برنامه می تواند ارتباط خود را با مخاطبان سفارشی مدیریت کند.
• یک برنامه می‌تواند به پلتفرم‌های فناوری تبلیغات شخص ثالث اجازه دهد تا مخاطبان سفارشی را از طرف خود مدیریت کند.

طراحی این قابلیت در حال انجام است و جزئیات آن در آپدیت بعدی درج خواهد شد.

کنترل پلت فرم فناوری تبلیغات

این پیشنهاد راه‌هایی را برای فناوری‌های تبلیغاتی برای کنترل مخاطبان سفارشی خود بیان می‌کند:

• متخصصان تبلیغات در جعبه ایمنی حریم خصوصی ثبت‌نام می‌کنند و یک دامنه eTLD+1 ارائه می‌کنند که با همه URL‌های یک مخاطب سفارشی مطابقت دارد.
• فناوری‌های تبلیغاتی می‌توانند با برنامه‌ها یا SDK همکاری کنند تا نشانه‌های تأییدی را ارائه کنند که برای تأیید ایجاد مخاطب سفارشی استفاده می‌شود. وقتی این فرآیند به یک شریک واگذار می‌شود، ایجاد مخاطب سفارشی می‌تواند به گونه‌ای پیکربندی شود که نیاز به تأیید توسط فناوری تبلیغات داشته باشد.
• یک فناوری تبلیغاتی می‌تواند از طرف خود تماس‌های joinCustomAudience را غیرفعال کند و فقط به fetchAndJoinCustomAudience API اجازه دهد تا همه مخاطبان سفارشی تماس را فعال کند. کنترل را می توان در حین ثبت نام در جعبه ایمنی حریم خصوصی به روز کرد. توجه داشته باشید که کنترل به همه فناوری های تبلیغاتی اجازه می دهد یا هیچ کدام. به دلیل محدودیت‌های پلتفرم، مجوزهای تفویض اختیار نمی‌تواند بر اساس فناوری تبلیغاتی باشد.

تبلیغات نامزد و پاسخ ابرداده

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

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

گردش کار انتخاب آگهی

هدف این پیشنهاد بهبود حریم خصوصی با معرفی Ad Selection API است که اجرای حراج برای پلتفرم‌های فناوری تبلیغات را تنظیم می‌کند.

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

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

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

این گردش کار انتخاب آگهی، اجرای کد جاوا اسکریپت ارائه شده توسط فناوری تبلیغات را بر روی دستگاه بر اساس دنباله زیر هماهنگ می کند:

1. اجرای منطق مناقصه سمت خرید
2. فیلتر و پردازش آگهی سمت خرید
3. اجرای منطق تصمیم گیری سمت فروش

برای انتخاب‌های تبلیغاتی که شامل مخاطبان سفارشی می‌شود، پلتفرم کد جاوا اسکریپت ارائه‌شده جانبی خرید را بر اساس نقطه پایانی URL عمومی تعریف‌شده توسط فراداده «Bidding Logic URL» مخاطبان سفارشی دریافت می‌کند. نقطه پایانی URL برای کد تصمیم گیری سمت فروش نیز به عنوان ورودی برای شروع گردش کار انتخاب آگهی ارسال می شود.

طراحی تبلیغات انتخابی که شامل مخاطبان سفارشی نمی شود در حال طراحی فعال است.

گردش کار انتخاب آگهی را آغاز کنید

هنگامی که یک برنامه نیاز به نمایش آگهی دارد، SDK پلت فرم فناوری تبلیغات ممکن است با فراخوانی متد selectAds() گردش کار انتخاب آگهی را پس از نمونه سازی شی AdSelectionConfig با پارامترهای مورد انتظار آغاز کند:

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

قطعه کد تصویری زیر یک SDK پلت فرم فناوری تبلیغات را نشان می دهد که گردش کار انتخاب آگهی را با تعریف AdSelectionConfig و سپس فراخوانی selectAds برای دریافت آگهی برنده آغاز می کند:

AdSelectionConfig myAdSelectionConfig = new AdSelectionConfig {
    Seller = "example-ssp1.com",
    DecisionLogicURL = Uri.parse("https://..."),
    CustomAudienceBuyerList = Arrays.asList("example-dsp1.com","bexample-dsp2.com"),
    AdSelectionSignals = "{"min_price": 10,"auction_attempts": 3}"
    SellerSignals = "{"seller_type": "news", "content_category": "sports","mature_ads_accepted" :"false"}"
    PerBuyerSignals = " {"buyer1Name": {"key1" : "value1"},
                         "buyer2Name": {"key1" : "value1", "key2" : "value2" }"
};

// Invoke ad services API to initiate ad selection workflow.
Ad winningAd = selectAds(myAdSelectionConfig);

منطق مناقصه سمت خرید

منطق مناقصه معمولاً توسط پلتفرم های سمت خرید ارائه می شود. هدف این کد تعیین قیمت پیشنهادی برای تبلیغات نامزد است. ممکن است منطق تجاری اضافی را برای تعیین نتیجه اعمال کند.

این پلتفرم از فراداده مخاطبان سفارشی "Bidding logic URL" برای واکشی کد جاوا اسکریپت که باید شامل امضای تابع زیر باشد استفاده خواهد کرد:

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ...};
}

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

تابع انتظار پارامترهای زیر را دارد:

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

هزینه تبلیغات

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

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ..., 'adCost': ...,};
}

اگر این تبلیغ برنده باشد، adCost به صورت تصادفی به 8 بیت برای حفظ حریم خصوصی گرد می شود. سپس مقدار گرد شده adCost به پارامتر contextual_signals در reportWin در حین گزارش‌گیری ارسال می‌شود.

منطق فیلتر طرف خرید

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

منطق فیلتر سمت خرید را می توان به عنوان بخشی از منطق مناقصه با بازگرداندن ارزش پیشنهادی 0 برای یک تبلیغ معین پیاده سازی کرد.

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

منطق امتیازدهی سمت فروش

منطق امتیازدهی معمولاً توسط پلت فرم سمت فروش ارائه می شود. هدف کد تعیین یک تبلیغ برنده بر اساس خروجی های منطقی مناقصه است. ممکن است منطق تجاری اضافی را برای تعیین نتیجه اعمال کند. اگر چندین ارائه دهنده منطق تصمیم وجود داشته باشد، سیستم توالی اجرا را در بین ارائه دهندگان تضمین نمی کند. پلتفرم از پارامتر ورودی "Decision Logic URL" API selectAds() برای واکشی کد جاوا اسکریپت که باید شامل امضای تابع زیر باشد استفاده خواهد کرد:

scoreAd(ad, bid, auction_config, trusted_scoring_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return score_for_this_ad;
}

تابع انتظار پارامترهای زیر را دارد:

• آگهی : آگهی در حال ارزیابی خروجی از تابع generateBid()
• Bid : مقدار پیشنهاد خروجی از تابع generateBid() .
• Auction config : پارامتر ورودی به متد selectAds() .
• سیگنال‌های امتیازدهی مورد اعتماد : پلت‌فرم‌های فناوری تبلیغات برای اطلاع‌رسانی فیلترینگ و امتیازدهی تبلیغات به داده‌های بی‌درنگ متکی هستند. به عنوان مثال، یک ناشر برنامه ممکن است یک کمپین تبلیغاتی را از نمایش تبلیغات در برنامه مسدود کند. این داده ها از پارامتر نشانی وب سیگنال های امتیازدهی مطمئن پیکربندی حراج واکشی شده است. سروری که این درخواست را ارائه می‌کند باید یک سرور مورد اعتماد با فناوری تبلیغاتی باشد.
• سیگنال متنی : ممکن است شامل اطلاعات مُهر زمانی درشت یا تقریبی باشد.
• سیگنال کاربر : ممکن است شامل اطلاعاتی مانند فروشگاه برنامه باشد که نصب برنامه را آغاز کرده است.
• سیگنال مخاطب سفارشی : اگر تبلیغی که امتیاز می‌گیرد از یک مخاطب سفارشی روی دستگاه باشد، حاوی اطلاعاتی مانند خواننده و نام مخاطب سفارشی است.

زمان اجرای کد انتخاب آگهی

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

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

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

زبان برنامه نویسی

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

رندر آگهی برنده

آگهی با بالاترین امتیاز برنده مزایده محسوب می شود. در این پیشنهاد اولیه، تبلیغ برنده برای رندر به SDK منتقل می شود.

این طرح توسعه راه حلی است تا اطمینان حاصل شود که اطلاعات مربوط به عضویت مخاطب سفارشی کاربر، یا سابقه تعامل برنامه، توسط برنامه یا SDK از طریق اطلاعات مربوط به آگهی برنده (مشابه پیشنهاد قاب‌های حصاردار Chrome) قابل تعیین نیست.

برداشت و گزارش رویداد

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

1. گزارش سمت فروش
2. گزارش سمت خرید

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

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

مخاطب محافظت شده مکانیزمی را برای اشتراک در رویدادهای آتی مرتبط با یک حراج برنده با ثبت بیکن ها فراهم می کند. در عملکرد reportResult() javaScript یک فروشنده ، سیستم عامل های طرف فروش می توانند چراغ ها را با استفاده از عملکرد ثبت نام Platform's registerAdBeacon() ثبت کنند. به طور مشابه ، سیستم عامل های سمت خرید می توانند از عملکرد registerAdBeacon() از عملکرد reportWin() JavaScript خود تماس بگیرند.

registerAdBeacon(beacons)

ورودی:

• event_key : رشته ای که نشان می دهد کدام نوع تعامل برای ثبت نام است. این به عنوان یک کلید برای جستجوی نقطه انتهایی پلتفرم در ضمن گزارش نتایج حراج استفاده می شود.
• reporting_url : URL متعلق به پلت فرم AD Tech برای رسیدگی به این رویداد.

کلیدهای رویداد شناسه های رشته ای هستند که متعلق به SDK طرف فروش هستند که مسئول گزارش نتایج حراج هستند. برای ایجاد پاسخ به تماس ، Techs Ad Beacons را با کلیدهایی که با کلیدهای استفاده شده توسط طرف فروش هنگام گزارش وقایع مطابقت دارند ، ثبت می کنند. اینها نیازی به ناشناس بودن ندارند ، اگرچه محدودیت هایی برای کمیت و طول کلیدها وجود دارد که می توانند برای مخاطبان سفارشی خاص ثبت شوند. در صورت فراخوانی reportEvent() ، سیستم عامل های سمت فروش که حراج را اجرا می کنند ، همیشه واجد شرایط دریافت این گزارش های رویداد هستند. فقط پلت فرم برنده خرید واجد شرایط دریافت این گزارش ها است.

گزارش سمت فروش

این پلتفرم عملکرد reportResult() javaScript را در کد جانبی ارائه شده بارگیری شده از پارامتر URL منطق تصمیم فروشنده برای selectAds() API فراخوانی می کند: API:

reportResult(render_url, bid, auction_config, contextual_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_url": reporting_url,
                  "signals_for_buyer": signals_for_buyer}};
}

خروجی: یک شی json حاوی

• وضعیت: 0 برای موفقیت ، هر مقدار دیگر برای شکست.
• URL Reporting: این پلتفرم از این URL برگشته شده از عملکرد فراخوانی می کند.
• سیگنال های خریدار: یک شیء JSON که باید به عملکرد reportWin خریدار منتقل شود.

طرف عرضه ممکن است سیگنال های مربوطه را در URL گزارش دهی رمزگذاری کند تا به آنها کمک کند تا بینش بیشتری در مورد حراج و آگهی برنده کسب کنند. به عنوان مثال ، ممکن است سیگنال های زیر را شامل شود:

• آدرس تبلیغاتی تبلیغاتی
• مبلغ پیشنهاد برنده
• نام برنامه
• شناسه های پرس و جو
• سیگنال های خریدار: برای پشتیبانی از به اشتراک گذاری داده ها بین سمت عرضه و طرف تقاضا ، این پلتفرم به عنوان یک پارامتر ورودی برای تقاضای کد گزارش ، این مقدار بازده را منتقل می کند.

گزارش سمت خرید

این پلتفرم از عملکرد reportWin() JavaScript در کد جانبی تقاضا که از ابرداده URL منطق مناقصه بارگیری شده از مخاطبان سفارشی مرتبط با حراج استفاده می شود ، فراخوانی می کند.

reportWin(render_url, bid, auction_signals, per_buyer_signals,
        signals_for_buyer, contextual_signals, custom_audience_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_uri": reporting_uri}};
}

ورودی:

• auction_signals و per_buyer_signals از AuctionConfig خارج می شوند. هرگونه اطلاعاتی که باید پلت فرم خرید برای ورود به URL گزارش دهی از این داده باشد.
• signals_for_buyer خروجی Reportresult طرف فروش است. این امر فرصتی را برای به اشتراک گذاشتن داده ها با بستر خرید برای اهداف گزارش فراهم می کند.
• contextual_signals شامل اطلاعاتی مانند نام برنامه و custom_audience_signals شامل اطلاعات مخاطبان سفارشی است. اطلاعات دیگر ممکن است در آینده اضافه شود.

خروجی:

• وضعیت: 0 برای موفقیت ، هر مقدار دیگر برای شکست.
• URL Reporting: این پلتفرم از این URL برگشته شده از عملکرد فراخوانی می کند.

گزارش وقایع

گزارش های گزارش فقط پس از اتمام گزارش برای حراج امکان پذیر است. SDK سمت فروش وظیفه گزارش هرگونه رویداد را بر عهده دارد. این پلتفرم API را در معرض ReportEventRequest قرار می دهد که حراج اخیراً اجرا شده ، کلید رویداد را که گزارش شده است ، داده های مرتبط با آن کلید ، چه گزارش باید به خریدار یا فروشنده (یا هر دو) ارسال شود ، و اختیاری است. رویداد ورودی برای رویدادهای تبلیغاتی. مشتری کلید رویداد و جمع آوری داده ها را برای گزارش تعریف می کند.

ReportEventRequest request = new ReportEventRequest(
  AdSelectionId = ad_selection_id,
  event_key = "view"
  event_data = "{ "viewTimeInSeconds" :1 }",
  reporting_destinations =
    FLAG_REPORTING_DESTINATION_SELLER |
      FLAG_REPORTING_DESTINATION_BUYER,
  input_event = clickInputEvent // or null for view
  )

reportEvent(request)

ورودی:

• ad_selection_id باید یک AdSelectionId از حراج اخیراً اجرا شده از AdSelectionOutcome باشد.
• event_key یک رشته تعریف شده از طرف فروش است که رویداد تعامل را توصیف می کند.
• event_data رشته ای است که داده های مرتبط با event_key را نشان می دهد
• reporting_destinations یک مجموعه ماسک کمی با استفاده از پرچم های ارائه شده توسط سیستم عامل است. این می تواند یکی از FLAG_REPORTING_DESTINATION_SELLER یا FLAG_REPORTING_DESTINATION_BUYER یا هر دو باشد.
• input_event (اختیاری) برای ادغام با API گزارش انتساب استفاده می شود. این یا یک شیء InputEvent (برای یک رویداد کلیک) یا NULL (برای یک رویداد مشاهده) است. برای اطلاعات بیشتر در مورد این پارامتر ، به ادغام API گزارش Attribution مراجعه کنید.

پس از فروش SDK از reportEvent و بسته به پرچم reporting_destinations ، این پلتفرم تلاش می کند تا با event_key ثبت شده توسط خریداران و فروشندگان در کارکردهای reportWin و reportResult JavaScript مطابقت داشته باشد. اگر یک مسابقه وجود داشته باشد ، پلتفرم event_data به reporting_url مرتبط_ورل ارسال می کند. نوع محتوای درخواست متن ساده است که بدن آن event_data است. این درخواست به عنوان بهترین تلاش انجام می شود و در صورت بروز خطای شبکه ، پاسخ به خطای سرور یا در صورت یافتن کلیدهای تطبیق ، سکوت می شود.

انتساب گزارش API یکپارچه سازی

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

از طریق این ادغام متقابل API ، AdTechs می تواند:

• یک نقشه با ارزش کلیدی URIS ایجاد کنید تا برای هر دو) 1) گزارش تعامل AD و 2) ثبت نام منبع استفاده شود.
• داده های حراج را از حراج مخاطبان محافظت شده در نقشه برداری کلید سمت منبع خود برای گزارش خلاصه کل (با استفاده از API گزارش انتساب) برای اطلاعات بیشتر به پیشنهاد طراحی ARA مراجعه کنید.

وقتی کاربر روی یک تبلیغ می بیند یا کلیک می کند:

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

ثبت نام منبع

reportEvent() یک InputEvent اختیاری جدید را می پذیرد. خریداران برنده که چراغهای تبلیغاتی را ثبت می کنند می توانند انتخاب کنند که گزارش های گزارش گزارش شده در API های گزارش انتساب به عنوان یک منبع ثبت شده ثبت می شوند. درخواست Aptribution-Report-Reportile به کلیه درخواست های گزارش رویداد ارسال شده از reportEvent() اضافه می شود. هرگونه پاسخ با هدرهای مناسب ARA به همان روشی که پاسخ ثبت نام منبع ARA معمولی دیگر تجزیه می شود ، تجزیه می شود. برای نحوه ثبت URL منبع ، به API توضیح دهنده گزارش انتساب مراجعه کنید.

از آنجا که ARA در Android از مشاهده و رویدادهای کلیک پشتیبانی می کند ، InputEvents برای تمایز بین این دو نوع استفاده می شود. دقیقاً مانند ثبت نام منبع ARA ، API reportEvent() یک InputEvent با تأیید شده از پلتفرم را به عنوان یک رویداد کلیک تفسیر می کند. اگر InputEvent از دست رفته ، تهی یا نامعتبر باشد ، ثبت نام منبع یک دیدگاه در نظر گرفته می شود.

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

نامزدی و گزارش تبدیل به عنوان مثال

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

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

گردش کار: قبل از شروع حراج ، خریدار شناسه منحصر به فرد را به عنوان بخشی از پاسخ پیشنهادات برنامه نویسی زمان واقعی ("RTB") به فروشنده ارسال می کند. شناسه را می توان به عنوان متغیر مانند auctionId تنظیم کرد. این شناسه به عنوان perBuyerSignals در auctionConfig منتقل می شود و در منطق مناقصه خریدار در دسترس قرار می گیرد.

1. در حین اجرای reportWin ، خریدار می تواند یک چراغ تبلیغاتی را ثبت کند که در طول زمان ارائه تبلیغات و برای وقایع خاص تعامل ایجاد شود ( registerAdBeacon() ). برای مرتبط کردن سیگنال های حراج برای یک رویداد تبلیغاتی ، auctionId به عنوان یک پرس و جو از URL Beacon تنظیم کنید.
2. در طول زمان ارائه آگهی ، چراغهایی که در طول زمان حراج ثبت کرده اید می تواند با داده های سطح رویداد شروع یا تقویت شود. فروشنده باید reportEvent() تحریک کند و در داده های سطح رویداد عبور کند. این پلتفرم URL AD Beacon Ad ثبت شده خریدار را که با reportEvent() ایجاد شده ارتباط دارد ، پینگ می کند.
3. خریدار با پاسخ دادن به درخواست های Beacon Ad با عنوان Attribution-Reporting-Register-Source تبلیغات را در API گزارش انتساب ثبت می کند. برای مرتبط کردن سیگنال های حراج برای یک رویداد تبدیل ، auctionId در URL منبع ثبت نام تنظیم کنید.

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

گردش کار مشابه در صورت نیاز به دسترسی به داده های انتساب در مورد فروشنده اعمال می شود و فروشنده همچنین می تواند از یک شناسه منحصر به فرد برای ارسال با registerAdBeacon() استفاده کند. تماس reportEvent() شامل یک ویژگی مقصد است که می تواند برای ارسال گزارش به خریدار و فروشنده استفاده شود.

پلت فرم فناوری تبلیغاتی سرور قابل اعتماد را مدیریت کرد

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

• رفتارهای این سرورها ، که بعداً در این بخش شرح داده شده است ، اطلاعات کاربر را نشت نمی کند.
• سرورها بر اساس داده هایی که می بینند ، پروفایل های مستعار ایجاد نمی کنند ، یعنی باید به آنها اعتماد شود.

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

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

https://www.kv-server.example/getvalues?keys=key1,key2

پاسخ سرور باید یک شیء JSON باشد که کلیدهای آن Key1 ، Key2 و غیره است و مقادیر آن در دسترس توابع مناقصه خریدار قرار می گیرد.

Sell ​​Side : مشابه با جریان سمت خرید در بالا ، Sell Side ممکن است بخواهد اطلاعات مربوط به خلاقین را که در حراج در نظر گرفته شده است ، بدست آورد. به عنوان مثال ، یک ناشر ممکن است بخواهد که بر اساس نگرانی های ایمنی برند در برنامه خود در برنامه خود نشان داده نشده باشد. این اطلاعات را می توان دریافت کرد و در دسترس منطق حراج سمت فروش قرار داد. شبیه به جستجوی سرور قابل اعتماد سمت خرید ، فروش سرور قابل اعتماد نیز از طریق HTTP Fetch اتفاق می افتد. URL با افزودن URL سیگنال های امتیاز دهی قابل اعتماد با URL های ارائه شده از خلاقیت هایی که داده ها نیاز به آن دارند ، تشکیل شده است.

در زیر یک URL نمونه برای واکشی اطلاعات مربوط به خلاقین در حراج ، بر اساس URL های ارائه خلاق:

https://www.kv-server.example/getvalues?renderUrls=render_url1,render_url2

پاسخ سرور باید یک شیء JSON باشد که کلیدهای آن URL های ارسال شده در درخواست ارسال شده است.

این سرورها به روشی قابل اعتماد برای ارائه چندین مزایای امنیتی و حریم خصوصی فعالیت می کنند:

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

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

خریداران و فروشندگان می توانند از یک سرور با ارزش کلیدی متداول برای سیستم عامل های سازگار با ماسهبازی حریم خصوصی در Android و وب استفاده کنند.