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

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

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

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

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

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

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

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

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

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

שלב 1: הוספת מידע על מכסת התדירות למודעות

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

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

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

void updateAdCounterHistogram(@EventType eventType, long adSelectionId)

קלט:

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

הערה: ה-API של reportImpression לא יגדיל באופן אוטומטי את המונים עבור אירועי FrequencyCapFilters.AD_EVENT_TYPE_IMPRESSION. הלקוח אמור להתקשר אל updateAdCounterHistogram(FrequencyCapFilters.AD_EVENT_TYPE_IMPRESSION, adSelectionId);.

הקריאה 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 for Android מגדיל באופן אוטומטי את כל המונים שהוזכרו למעלה בשביל סוג האירוע FrequencyCapFilters.AD_EVENT_TYPE_WIN עבור מודעות שהוחזרו על ידי הקריאה של selectAds ל-API. הפונקציונליות הזו מקבילה מבחינה פונקציונלית לתוספת של הארגומנט prev_wins ל-browser_signals ב-generateBid בהטמעה של Protected Audience של Chrome.

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

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

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

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

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

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

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

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

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

מגבלות

הרשימה הבאה מפרטת את המגבלות הידועות של מכסת התדירות 'קהל מוגן':

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