מכסת תדירות של 'קהל מוגן'

הגבלת תדירות היא שיטה פרסומית שמגבילה את מספר המודעות מקטגוריה מסוימת שמוצגות למשתמש בפרק זמן נתון. הגדרת מכסת תדירות משפרת את חוויית משתמשי הקצה כי היא מאפשרת להציג חשיפות של מודעות בצורה רעננה ומעניינת, ועוזרת למפרסמים לנהל את הוצאות הפרסום.

בהצעה הזו מוסבר איך אפשר להשתמש ב-Protected Audience ב-Android כדי להטמיע פונקציונליות של הגבלת תדירות בצורה מדויקת ושומרת פרטיות.

ב-Protected Audience API, מכסת התדירות מיושמת באמצעות שילוב של שני מאפיינים: אחסון במכשיר של מוני אירועים ספציפיים למודעות, והיכולת לסנן מודעות לפי קבוצה מוגדרת מראש של אסטרטגיות סינון. מכסת תדירות מאפשרת למפרסמים לציין סף של מונה מעל סכום של ערכי היסטוגרמה במהלך תקופת זמן נתונה.

המונים הם ייחודיים לכל שילוב של פרופיל מכשיר, טכנולוגיית פרסום ומפתח מונה. כל מודעה צריכה להכיל קבוצה של מפתחות מונה לשימוש במקרה של צפייה במודעה או חשיפה שלה. לכל מפתח, Protected Audience מאחסן קבוצה של מוני נתונים, וכל מונה נתונים סופר את כל האירועים שקשורים למודעות שמתרחשים בפרק זמן מסוים. הערכים של מוניטורים במכשיר גדלים כשמתרחשת חשיפה או צפייה, והנתונים של המוניטורים נשמרים במכשיר. משך השמירה המדויק יוגדר בהמשך.

ללוגיקה של סינון המודעות בתהליך בחירת המודעות של Protected Audience יש גישה לדלפקים, למודעות רימרקטינג ולמודעות קונטקסטואליות, ולכן אפשר להשתמש בהגבלת תדירות ההצגה של Protected Audience עם כל סוגי בקשות המודעות האלה.

הערה: סינון מודעות זמין רק ב-Privacy Sandbox ב-Android. ההטמעה של Protected Audience ב-Chrome לא כוללת מנגנון לסינון מודעות שאינן מודעות Protected Audience ומטרגטות לפי הקשר. ההצעה הזו מתייחסת לתמיכה בצד הקונה בלבד. אם יהיה ביקוש, נוסיף תמיכה בצד המוכר בהמשך.

התכונה 'הגבלת תדירות הצגת מודעות בקהלים מוגנים' תומכת במגוון רחב של דרישות, כולל:

• סינון בזמן אמת, עם עיכוב מינימלי בצד השרת כשמתבצע עדכון של מוניטורים במכשיר.
• היררכיה גמישה של מפתחות, כולל מודעות בודדות, קמפיינים או כל קבוצה אחרת.
• התאמה לשיטות אחרות של הגבלת תדירות, ללא תלות ב-AdID.
• פועל באפליקציות שונות בפרופיל משתמש נתון במכשיר.
• דלפקים מדויקים ומלאים.
• תמיכה בהגדרות מותאמות אישית של אירועים שקשורים למודעות, כמו צפיות או חשיפות.
• פונקציה אחת גם לרימרקטינג וגם למודעות קונטקסטואליות.

כדי להגדיר מכסת תדירות, פועלים לפי השלבים הבאים:

שלב 1: מוסיפים מידע על הגבלת תדירות להצגת מודעות

מודעות קונטקסטואליות ומודעות רימרקטינג מציינות את מוני ההיסטוגרמה הרלוונטיים לעדכון במקרה של צפייה או חשיפה, באמצעות השדה ad_counter_keys שמכיל רשימה של מספרים שלמים שרירותיים. השדה לא נכלל בשדה metadata שלא מנותח על ידי Protected Audience.

בדוגמה הבאה מוצג פורמט הנתונים של השדה 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]
      }]
  }]
}

שלב 2: רישום צפייה או חשיפה

טכנולוגיות פרסום יכולות להפעיל את השיטה updateAdCounterHistogram כדי לרשום מקרים של אירועים שמשמשים להגבלת תדירות. אפשר להפעיל שיטה שוב ושוב על אותו אירוע עבור מפתחות שצוינו ב-eventType של המודעה הזוכה.

void updateAdCounterHistogram(@EventType eventType, long adSelectionId)

קלט:

• ‫eventType: מזהה אם אירוע נספר כצפייה, כחשיפה, כקליק או כזכייה בתהליך בחירת המודעות.
• ‫adSelectionId: ערכי המזהה באובייקט AdSelectionOutcome שמוחזרים על ידי קריאות selectAds.

הקריאה updateAdCounterHistogram מעדכנת את ההיסטוגרמה של קבוצת המפתחות שהוגדרו כחלק ממודעות הרימרקטינג שאוחזרו על ידי CustomAudience או ממודעות קונטקסטואליות שנכללות בפרמטר AdSelectionConfig עבור selectAds.

אם מניחים שהמודעה בשלב 1 היא המודעה המנצחת בAdSelection עם ערך של 9999, קריאה ל-updateAdCounterHistogram(FrequencyCapFilters.AD_EVENT_TYPE_VIEW, adSelectionId: 999) מגדילה את הערכים של שלושת המפתחות הראשיים הבאים:id

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

השם של ספק טכנולוגיית הפרסום נלקח משדה הקונה, ממודעות קונטקסטואליות או מקהלים מותאמים אישית, בהתאם למקור המודעות המנצחות.

ב-Protected Audience ל-Android, כל המונים שצוינו קודם עבור סוג האירוע FrequencyCapFilters.AD_EVENT_TYPE_WIN גדלים אוטומטית עבור מודעות שמוחזרות על ידי קריאת API‏ selectAds. מבחינה פונקציונלית, זה שווה להוספה של הארגומנט prev_wins ל-browser_signals ב-generateBid בהטמעה של Protected Audience ב-Chrome.

שלב 3: הטמעה של סינון מכסות תדירות באמצעות מסננים

כדי להשיג ביצועים אופטימליים, פונקציית הסינון של מכסת התדירות מופעלת תוך AdServices. מערכת Protected Audience קוראת את השדה filters באובייקט AdsData כדי להבין אם צריך לסנן הודעה. רשימת המסננים מפורטת ב-frequency_cap. הערכים של המפתחות event_type ו-interval_in_seconds משמשים לאחזור היסטוגרמה של אירועים שמשמשים לסינון ולקהלים מוגנים.

אפשר לציין סינון של מידע לגבי מודעות רימרקטינג שמסופקות על ידי קהל מותאם אישית ומודעות קונטקסטואליות כחלק מאובייקט AdSelectionConfig.

למודעות קונטקסטואליות עם מסננים של מכסת תדירות, המודעות מועברות באמצעות השדה ads באובייקט AdSelectionConfig. המערכת מסננת את המודעות ומחזירה את המודעה עם הצעת המחיר הגבוהה ביותר כתוצאה של הקריאה selectAds.

במודעות רימרקטינג עם מסננים של מכסת תדירות, המודעות מסוננות לפני הפעלת פונקציית ה-JavaScript של 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"
}

שלב 4: דיווח על מודעות מנצחות

אחרי שתהליך בחירת המודעה מסתיים, מוחזר AdSelectionOutcome אובייקט שמכיל את renderUri ואת adSelectionId, מזהה מספרי של הקריאה selectAds. אפשר להשתמש במזהה הזה כדי להפעיל את reportImpression API שתומך בדיווח ברמת האירוע. בגרסת הבטא הראשונה, השיטה הזו תומכת בדיווח על מודעות רימרקטינג, ובגרסה מאוחרת יותר היא תורחב כך שתתמוך בדיווח על מודעות קונטקסטואליות. במודעות קונטקסטואליות, הקונה נדרש לציין איפה אפשר לאחזר את הפונקציה reportWin במהלך קריאה reportImpression באמצעות שדה נוסף שנקרא reportingJS במבנה המודעה, כמו שמוצג בדוגמה הקודמת.

שיטות מומלצות לבחירת מועמדים להצגת מודעות

ב-Protected Audience, האכיפה של מכסת התדירות מתבצעת במכשיר ולא בשרת. למרות שדיווח על הצעות מחיר זוכות מתבצע באמצעות ארגז החול לפרטיות, המפתחים לא יודעים למה מודעה מסוימת לא מוצגת. יכול להיות שהמודעות לא יוצגו בגלל הפסד בהצעת מחיר או בגלל מכסת תדירות. מערכות הבידינג לא יכולות לראות את כל הסיבות לכך שמודעות מסוימות לא זוכות בבידינג, ולכן נדרשת עבודה נוספת כדי לוודא שהמודעות האופטימליות מוצגות. השיטות המומלצות האלה יעזרו לכם לוודא שהצגת המודעות מתבצעת בצורה אופטימלית באמצעות Protected Audience.

שליחת מספיק מודעות רימרקטינג

אי אפשר לבצע אופטימיזציה של מודעות רימרקטינג ברמת המשתמש. אם משתמש נחשף למספר משמעותי של מודעות מקהל מותאם אישית והגבלות המודעות נמוכות, יכול להיות שכל המודעות יסוננו. מודעות רימרקטינג מתעדכנות באופן תקופתי, ולכן צריך להגדיר הגבלת תדירות על מספיק מלאי שטחי פרסום כדי לוודא שמודעות הרימרקטינג ימשיכו להיות מוצגות. צריך לאזן בין זה לבין ההגבלות על גודל המודעות שאפשר לציין במהלך הקריאה joinCustomAudience ובמהלך העדכון היומי של קהל בהתאמה אישית. הקונים צריכים לקחת בחשבון שאולי תהיה עלייה בחביון במהלך שלב הבידינג. כדי למזער את ההשפעה של הבעיות האלה, סינון של מכסת תדירות מתבצע לפני הקריאה אל generateBid.

שמירה של מוני הקשר בשרת

באמצעות הערכה בצד השרת, מפתחים יכולים לקבל הערכות גסות לגבי המועד שבו מכסת התדירות עשויה להיות פעילה. ההערכות האלה יכולות להצביע על כך שסביר להניח שמודעה הגיעה לסף של מכסת התדירות, ולכן צריך לשלוח אותה עם עוד מודעות פוטנציאליות או להסיר אותה לגמרי.

שליחת כמה מועמדים למודעות בתשובה ההקשרית

כדאי לשלוח כמה מועמדים למודעות עם תגובה הקשרית לפני מכרז של קהל מוגן. כך אפשר לוודא שאם כמה מודעות מסוננות, עדיין מוצגות מודעות אחרות. אפשר לתעדף מועמדים להצגת מודעות כדי שמודעות מסוימות יוצגו כגיבוי.

הביצוע מוגבל בזמן, ולכן צריך לבחור את המודעות המועמדות לפי הסיכוי שלהן לזכות במכרז ולא להיפסל.

מגבלות

אלה המגבלות הידועות של מכסת תדירות בקהלים מוגנים:

1. הגבלת תדירות הצגת המודעות ב-Protected Audience פועלת ברמת פרופיל המשתמש במכשיר, ללא מוניטורים משותפים במכשירים אחרים ובפרופילים אחרים. אם צריך, אפשר להוסיף באופן ידני את מספר המודעות שמוצגות במכשירים אחרים.
2. המונים של המכשיר מאוחסנים במכשיר ומתבצעת אליהם גישה במכשיר. צריך לנהל בנפרד את המונים בצד השרת.
3. מכיוון שסינון מודעות שקשור להגבלת תדירות מתבצע במכשיר, לפלטפורמות טכנולוגיות פרסום אין שליטה ישירה בפעולות האלה. כדי לעקוף את סף הגבלת התדירות במכשיר, פלטפורמות טכנולוגיות פרסום יכולות לשלוח כמה מודעות מועמדות עם מסננים שונים.
4. אין תמיכה בהתאמות של הצעות מחיר שמבוססות על תדירות מתועדת. הפונקציות generateBid לא יכולות להציג את מוני התדירות.