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

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

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

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

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

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

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

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

• סינון בזמן אמת, עם עיכוב מינימלי בצד השרת כשהמכשירים מעדכנים את המונים.
• היררכיה גמישה של מפתחות, כולל מודעות ספציפיות, קמפיינים או כל קיבוץ אחר.
• תאימות לשיטות אחרות של הגבלת תדירות, ללא תלות ב-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 עם ערך id של 9999, קריאה ל-updateAdCounterHistogram(FrequencyCapFilters.AD_EVENT_TYPE_VIEW, adSelectionId: 999) תגדיל את המונים של שלושת המפתחות הראשיים הבאים:

• {'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 קורא את שדה המסננים באובייקט AdsData. רשימת המסננים מצוינה ב-frequency_cap. הערכים של המפתח, event_type ו-interval_in_seconds משמשים לאחזור תרשים היסטוגרמה של אירועים שמשמשים לסינון ול-Protected Audience.

אפשר לציין את פרטי הסינון למודעות רימרקטינג שמתקבלות מקהלים מותאמים אישית ולמודעות לפי הקשר כחלק מהאובייקט 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. אפשר להשתמש במזהה הזה כדי להפעיל את ה-API של reportImpression שתומך בדיווח ברמת האירוע. בגרסת הבטא 1, השיטה הזו תומכת בדיווח על מודעות רימרקטינג, והיא תורחב לדיווח על מודעות לפי הקשר בגרסה מאוחרת יותר. במודעות לפי הקשר, הקונה צריך לציין איפה אפשר לאחזר את הפונקציה reportWin במהלך קריאה ל-reportImpression באמצעות שדה נוסף שנקרא reportingJS במבנה המודעה, כפי שמוצג בדוגמה הקודמת.

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

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

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

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

שמירת ספירת האירועים לפי הקשר בשרת

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

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

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

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

מגבלות

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

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