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

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

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

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

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

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

توجه : فیلتر کردن تبلیغات فقط در Privacy Sandbox در اندروید موجود است. پیاده‌سازی Protected Audience در کروم، مکانیزمی برای فیلتر کردن تبلیغات Non-Protected Audience که به صورت زمینه‌ای هدف‌گذاری شده‌اند، پیاده‌سازی نمی‌کند. این پیشنهاد فقط پشتیبانی سمت خریدار را پوشش می‌دهد. در صورت وجود تقاضا، پشتیبانی سمت فروش را در آینده اضافه خواهیم کرد.

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

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

برای تنظیم محدودیت فرکانس، این مراحل را دنبال کنید:

مرحله ۱: اطلاعات محدودیت تکرار را به تبلیغات اضافه کنید

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

مثال زیر فرمت داده برای فیلد adsData در AdSelectionConfig را نشان می‌دهد. برای بازاریابی مجدد، فرمت لیست تبلیغات برای یک مخاطب سفارشی مشخص با محتوای فیلد ads که در مثال زیر نشان داده شده است، سازگار است:

'adsData': [
  {
    "buyer": "ads.example.com",
    "ads": [
      {
        'render_url': 'exampleUrl',
        'metadata': {...},   /* metadata are opaque to Protected Audience are
                                required to be in valid JSON format */
        'ad_counter_keys': [1234, 5678]
      }]
  }]
}

مرحله ۲: ثبت یک بازدید یا برداشت

تکنسین‌های تبلیغات می‌توانند متد updateAdCounterHistogram را برای ثبت رخدادهای مورد استفاده برای محدود کردن فرکانس فراخوانی کنند. یک متد می‌تواند به طور مکرر روی یک رویداد مشابه برای کلیدهای مشخص شده در eventType تبلیغ برنده فراخوانی شود.

void updateAdCounterHistogram(@EventType eventType, long adSelectionId)

ورودی‌ها:

• eventType : مشخص می‌کند که آیا یک رویداد به عنوان یک بازدید، یک نمایش، یک کلیک یا یک برد در فرآیند انتخاب تبلیغ محاسبه می‌شود یا خیر.
• adSelectionId : مقادیر شناسه در شیء AdSelectionOutcome که توسط فراخوانی‌های selectAds بازگردانده می‌شوند.

فراخوانی updateAdCounterHistogram هیستوگرام را برای مجموعه‌ای از کلیدها که به عنوان بخشی از تبلیغات بازاریابی مجدد دریافت شده توسط CustomAudience یا تبلیغات زمینه‌ای موجود در پارامتر AdSelectionConfig برای selectAds تعریف شده‌اند، به‌روزرسانی می‌کند.

اگر فرض کنید که تبلیغ مرحله ۱ برنده AdSelection با مقدار id 9999 است، فراخوانی تابع updateAdCounterHistogram(FrequencyCapFilters.AD_EVENT_TYPE_VIEW, adSelectionId: 999) شمارنده‌های سه کلید اصلی زیر را افزایش می‌دهد:

• {'ads.example.com', 1234, VIEW}
• {'ads.example.com', 5678, VIEW}

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

افزونه Protected Audience برای اندروید به طور خودکار تمام شمارنده‌های ذکر شده قبلی برای نوع رویداد FrequencyCapFilters.AD_EVENT_TYPE_WIN را برای تبلیغاتی که توسط فراخوانی selectAds API برگردانده می‌شوند، افزایش می‌دهد. این از نظر عملکردی معادل اضافه کردن آرگومان prev_wins به browser_signals در generateBid در پیاده‌سازی Protected Audience کروم است.

مرحله ۳: پیاده‌سازی فیلترینگ سقف فرکانس با فیلترها

برای عملکرد بهینه، تابع فیلترینگ فرکانس در AdServices اجرا می‌شود. Protected Audience با خواندن فیلد فیلترها در شیء AdsData متوجه می‌شود که آیا پیامی باید فیلتر شود یا خیر. لیستی از فیلترها در frequency_cap مشخص شده است. مقادیر key، event_type و interval_in_seconds برای بازیابی هیستوگرام رویدادهایی که برای فیلترینگ و Protected Audience استفاده می‌شوند، استفاده می‌شوند.

اطلاعات فیلترینگ را می‌توان برای تبلیغات ریمارکتینگ ارائه شده توسط مخاطبان سفارشی و برای تبلیغات متنی به عنوان بخشی از شیء AdSelectionConfig مشخص کرد.

برای تبلیغات متنی با فیلترهای محدودیت فرکانس، تبلیغات با استفاده از فیلد ads در شیء AdSelectionConfig ارسال می‌شوند. تبلیغات فیلتر می‌شوند و تبلیغی که بالاترین پیشنهاد قیمت را دارد به عنوان نتیجه فراخوانی selectAds بازگردانده می‌شود.

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

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

{
  'render_url': 'url',
  'metadata': {...},   /* metadata are opaque to Protected Audience and assumed
                        to be in valid JSON format */

  'ad_counter_keys': [1234, 5678],

  "filters": {
    "frequency_cap": {
      "view": [
        {
          "ad_counter_key": 1234
          "max_count": 10,
          "interval_in_seconds": 86400
        },
        {
          "ad_counter_key": 5678
          "max_count": 10,
          "interval_in_seconds": 86400
        },
      ],
      "win": [
        {
          "ad_counter_key": 1234
          "max_count": 5,
          "interval_in_seconds": 604800
        },
        {
          "ad_counter_key": 5678
          "max_count": 5,
          "interval_in_seconds": 345600
        },
      ]
    },

  // This field is only required in contextual ads and is used in
  // reportImpression calls to fetch the reportWin function.
  'reportingJS': "https://ads.example.com?reportWin.js"
}

مرحله ۴: گزارش تبلیغات برنده

پس از تکمیل فرآیند انتخاب تبلیغ، یک شیء AdSelectionOutcome حاوی renderUri و adSelectionId ، یک شناسه عددی برای فراخوانی selectAds ، را برمی‌گرداند. این شناسه می‌تواند برای فراخوانی API reportImpression که از گزارش‌دهی در سطح رویداد پشتیبانی می‌کند، استفاده شود. در بتا ۱، این روش از گزارش‌دهی برای تبلیغات بازاریابی مجدد پشتیبانی می‌کند و در نسخه بعدی برای پشتیبانی از گزارش‌دهی برای تبلیغات متنی نیز گسترش خواهد یافت. برای تبلیغات متنی، خریدار موظف است با استفاده از یک فیلد اضافی به نام reportingJS در ساختار تبلیغ، همانطور که در مثال قبلی نشان داده شده است، مشخص کند که تابع reportWin در طول فراخوانی reportImpression از کجا قابل بازیابی است.

بهترین شیوه‌ها برای انتخاب نامزدهای تبلیغاتی

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

به اندازه کافی تبلیغات ریمارکتینگ ارسال کنید

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

شمارنده‌های متنی را روی سرور نگه دارید

با تخمین سمت سرور، یک توسعه‌دهنده می‌تواند تخمین‌های تقریبی از زمان فعال بودن محدودیت فرکانس داشته باشد. این تخمین‌ها می‌توانند نشان دهند که یک تبلیغ احتمالاً به آستانه محدودیت فرکانس رسیده است و بنابراین باید با نامزدهای تبلیغاتی بیشتری ارسال شود یا کاملاً حذف شود.

چندین کاندید تبلیغ را در پاسخ متنی ارسال کنید

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

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

محدودیت‌ها

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

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