דף זה תורגם על ידי Cloud Translation API.

תמיכה בטירגוט לפי קהל בהתאמה אישית באמצעות Protected Audience API

עדכונים אחרונים

נוסף מידע על תזמון עדכונים של קהלים בהתאמה אישית
נוסף שילוב של דוחות שיוך (Attribution) עם קהלים מוגנים
פורסם ציר זמן של תכונות של Protected Audience.
השם של FLEDGE השתנה ל-Protected Audience API.
נוספה הצעה להענקת גישה לקהלים בהתאמה אישית.
הסרה של הדרישה ל-k-anonymity בכתובת ה-URL של העדכון היומי.

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

בעזרת 'קהל מוגן', אתם יכולים:

ניהול קהלים בהתאמה אישית על סמך פעולות קודמות של משתמשים.
התחלת מכרזים במכשיר עם תמיכה ב-Mediation מסוג 'רשת אחת' או 'מפל'.
להפעיל דיווח על חשיפות אחרי בחירת המודעות.

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

ציר הזמן

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

תכונה	זמין בתצוגה המקדימה למפתחים	זמין בגרסת בטא
דיווח ברמת האירוע	ברבעון הראשון של 2023	רבעון שלישי 2023
תהליך בחירת הרשת (Mediation) ב-Waterfall	רבעון 1 של שנת 2023	רבעון 4 של שנת 2023
סינון של מודעות להתקנת אפליקציות	רבעון 2 בשנת 2023	רבעון שלישי 2023
סינון לפי מכסת תדירות	רבעון 2 בשנת 2023	רבעון שלישי 2023
העברת מודעות לפי הקשר לתהליך העבודה לבחירת מודעות לצורך סינון	רבעון 2 של שנת 2023	רבעון שלישי 2023
דוחות אינטראקציה	רבעון 2 של שנת 2023	רבעון 3 של שנת 2023
הצטרפות להענקת גישה לקהלים בהתאמה אישית	רבעון 3 של שנת 2023	רבעון 4 של שנת 2023
חיוב שאינו לפי עלות לאלף חשיפות (CPM)	רבעון 3 של שנת 2023	רבעון 4 של שנת 2023
שילוב בין שירותי בידינג לבין שירותי מכרזים	רבעון 3 של שנת 2023	רבעון 4 של שנת 2023
דיווח על ניפוי באגים	רבעון שלישי 2023	רבעון 4 של שנת 2023
שילוב של דוחות שיוך (Attribution)	לא רלוונטי	רבעון 4 של שנת 2023
תהליך בחירת הרשת (Mediation) ב-Open Bidding	רבעון 4 של שנת 2023	רבעון 4 של שנת 2023
ניהול מטבעות	רבעון 1 של שנת 2024	רבעון 2 של שנת 2024
שילוב עם k-anonymity	לא רלוונטי	רבעון 2 '24
שילוב של נתוני דיווח מצטברים	רבעון 3 של שנת 2024	שאלה 4 '24

סקירה כללית

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

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

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

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

תרשים זרימה שמציג את תהליך העבודה בהתאמה אישית של ניהול קהלים ובחירת מודעות בארגז החול לפרטיות ב-Android.

באופן כללי, השילוב פועל באופן הבא:

ב-SportingGoodsApp רוצים להזכיר למשתמשים לרכוש את מוצרי המרצ'נדייז שהם השאירו בעגלת הקניות, אם הם לא השלימו את הרכישה תוך יומיים. ב-SportingGoodsApp נעשה שימוש ב-Custom Audience API כדי להוסיף את המשתמש לרשימת הקהלים 'מוצרים בעגלת הקניות'. הפלטפורמה מנהלת את רשימת הקהלים הזו ושומרת אותה במכשיר, ומגבילה את השיתוף עם צדדים שלישיים. SportinggoodsApp פועלת בשיתוף עם פלטפורמה פרסום דיגיטלי כדי להציג את המודעות שלה למשתמשים ברשימת החברים בקהל. פלטפורמת הפרסום הדיגיטלי מנהלת מטא-נתונים של קהלים רשימות ומספקות מודעות של מועמדים בבחירות, שזמינות למודעה תהליך העבודה של הבחירה. אפשר להגדיר את הפלטפורמה כך: אחזור תקופתי של מודעות מעודכנות שמבוססות על קהל ברקע. כך אפשר לשמור על עדכניות הרשימה של מודעות המועמדות לבחירה לפי קהל, בלי קורלציה לבקשות שנשלחות לשרתי מודעות של צד שלישי במהלך ההזדמנות להצגת מודעה (כלומר, בקשה להצגת מודעה לפי הקשר).
כשהמשתמש ישחק ב-FrisbeeGame באותו מכשיר, יכול להיות שתוצג לו מודעה עם תזכורת להשלים את הרכישה של הפריטים שהשאיר בעגלת הקניות של SportingGoodsApp. אפשר לעשות זאת באמצעות FrisbeeGame (באמצעות מודעות משולבות SDK) על הפעלת Ad Selection API כדי לבחור את המודעה הזוכה עבור המשתמש, על סמך כל רשימת קהלים שהוא עשוי להיכלל בה (ב לדוגמה, העמודה 'מוצרים בעגלת הקניות' קהל בהתאמה אישית שנוצר על ידי SportinggoodsApp). אפשר להגדיר את תהליך העבודה לבחירת מודעות כך שיכלול מודעות שאוחזרו מהשרתים של פלטפורמות טכנולוגיית הפרסום, בנוסף למודעות במכשיר שמשויכות לקהלים בהתאמה אישית וכן אותות אחרים במכשיר. אפשר גם להתאים אישית את תהליך העבודה באמצעות פלטפורמת טכנולוגיית הפרסום ו-SDK של המודעות, עם לוגיקה מותאמת אישית של בידינג וסיווג כדי להשיג את יעדי הפרסום המתאימים. הגישה הזו מאפשרת להשתמש בנתוני האינטרסים או האינטראקציות של המשתמש באפליקציה כדי לבחור מודעות, תוך הגבלת השיתוף של הנתונים האלה עם צדדים שלישיים.
ערכת ה-SDK של האפליקציה להצגת מודעות או של פלטפורמת טכנולוגיית הפרסום מרינדרת את המודעה שנבחרה.
הפלטפורמה מאפשרת דיווח על חשיפות ועל תוצאות בחירת המודעות. יכולת הדיווח הזו שמשלימים את דוחות השיוך (Attribution) API. ייתכן שפלטפורמות פרסום דיגיטלי יותאמו אישית בהתאם לצורכי הדיווח שלהם.

קבלת גישה ל-Protected Audience API דרך ממשקי API של Android

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

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

קהל בהתאמה אישית

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

אפשר להצטרף לאפליקציית מפרסם או ל-SDK המשולב או להשאיר קהל בהתאמה אישית על סמך, למשל, משתמש באפליקציה.

מטא-נתונים של קהל בהתאמה אישית

כל קהל מותאם אישית מכיל את המטא-נתונים הבאים:

בעלים: שם החבילה של האפליקציה של הבעלים. מוגדר במרומז שם החבילה של אפליקציית המתקשר/ת.
קונה: רשת המודעות של הקונה שמנהלת את המודעות לקהל המותאם אישית הזה. הקונה מייצג גם את הגורם שעשוי לגשת לקהל בהתאמה אישית ולאחזר אותו מידע רלוונטי במודעה. הקונה מצוין באמצעות הפורמט eTLD+1.
שם: שם או מזהה שרירותי של קהל בהתאמה אישית, למשל משתמש ש"נוטשי עגלת קניות". אפשר להשתמש במאפיין הזה בתור אחד מקריטריוני הטירגוט, למשל בקמפיינים הפרסומיים של המפרסם, או במחרוזת שאילתה בכתובת ה-URL לאחזור בקוד בידינג.
זמן ההפעלה וזמן התפוגה: השדות האלה מגדירים את חלון הזמן שבו הקהל המותאם אישית הזה יהיה פעיל. הפלטפורמה משתמשת במידע הזה כדי לבטל את החברות בקהל בהתאמה אישית. כדי להגביל את משך החיים של קהל מותאם אישית, זמן התפוגה לא יכול לחרוג מחלון זמן מקסימלי.
כתובת URL לעדכון יומי: כתובת ה-URL שבה הפלטפורמה משתמשת כדי לאחזר מודעות מועמדות ומטא-נתונים אחרים שמוגדרים בשדות 'אותות בידינג של משתמשים' ו'אותות בידינג מהימנים' באופן קבוע. פרטים נוספים זמינים בקטע בנושא אחזור מודעות מועמדות לקהלים מותאמים אישית.
אותות לבידינג של משתמשים: אותות ספציפיים לפלטפורמת הפרסום הדיגיטלי עבור כל בידינג במודעות רימרקטינג. דוגמאות לאותות: המיקום המשוער של המשתמש, המיקום המועדף וכו'.
נתוני בידינג מהימנים: פלטפורמות טכנולוגיות של פרסום מסתמכות על נתונים בזמן אמת כדי להחליט אילו מודעות לאחזר ולתת להן ניקוד. למשל, ייתכן שהתקציב של המודעה ייגמר וצריך להפסיק אותו באופן מיידי. טכנולוגיית פרסום יכולה להגדיר כתובת URL נקודת הקצה (endpoint) שממנה ניתן לאחזר את הנתונים בזמן אמת, ואת קבוצת המפתחות עבור שצריך לבצע את הבדיקה בזמן אמת. השרת לטפל בבקשה הזו יהיה שרת מהימן שמנוהל על ידי פלטפורמת ה-AdTech.
כתובת ה-URL של לוגיק הבידינג: כתובת ה-URL שבה הפלטפורמה משתמשת כדי לאחזר את קוד הבידינג מפלטפורמת צד הביקוש. הפלטפורמה מבצעת את השלב הזה כשמתחיל מכרז על מודעה.
מודעות: רשימה של מודעות מועמדים לקהל בהתאמה אישית. המטא-נתונים האלה כוללים מטא-נתונים ספציפיים לפלטפורמת טכנולוגיית הפרסום וכתובת URL לעיבוד המודעה. כשמתחילים מכרז לקהל בהתאמה אישית, המערכת מביאה בחשבון את רשימת המטא-נתונים של המודעות. המערכת תרענן את רשימת המודעות הזו באמצעות כתובת ה-URL לעדכון יומי נקודת קצה, כשזה אפשרי. עקב אילוצי משאבים בניידים, מגבלה על מספר המודעות שאפשר לשמור בקהל בהתאמה אישית.

הענקת גישה לקהלים בהתאמה אישית

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

הצטרפות לקהל בהתאמה אישית

יש שתי דרכים להצטרף לקהל בהתאמה אישית:

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 אוכף כתובת האתר לעדכון תתאים גם ל-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 הם הבעלים שם החבילה של האפליקציה ששולחת קריאה. אין אימות אחר של fetchUri מלבד הבדיקה של eTLD+1, ובמיוחד אין בדיקה של 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. הגודל של הנתונים בסדרה שצוינו לקהל המותאם אישית מוגבל ל-8KB. אם הגודל הוא חרגת מהקריאה ל-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);

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

שליטת משתמשים

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

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

עדכונים מתוזמנים

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

כדי לאפשר זאת, טכנולוגיות הפרסום יכולות לקרוא ל-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 הזה גם תואם ל-fetchAndJoinCustomAudience() ממשק API שמאפשר שיתוף מידע דומה.
ShouldReplacePendingUpdates: ערך בוליאני שקובע אם צריך לבטל עדכונים מתוזמנים בהמתנה ולהחליף אותם בעדכון שמפורט ב-ScheduleCustomAudienceUpdateRequest הנוכחי. אם הערך של השדה הזה מוגדר כ-false ויש עדכונים שנשלחו בעבר לאותו קונה באותה אפליקציה שעדיין בהמתנה, קריאה ל-scheduleCustomAudienceUpdate עם הערך הזה של ScheduleCustomAudienceUpdateRequest תיכשל. ברירת המחדל היא false.

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

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

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

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

אמצעי בקרה בפלטפורמת טכנולוגיית הפרסום

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

טכנולוגיות הפרסום נרשמות לארגז החול לפרטיות ומספקות דומיין מסוג eTLD+1 שתואם לכל כתובות ה-URL של קהל מותאם אישית.
טכנולוגיות הפרסום יכולות לעבוד בשיתוף עם אפליקציות או ערכות SDK כדי לספק אסימוני אימות ששימשו לאימות יצירת קהל בהתאמה אישית. כשמאשרים לשותף לבצע את התהליך הזה, אפשר להגדיר יצירת קהלים בהתאמה אישית כך שתידרש אישור מצד חברת טכנולוגיית הפרסום.
ספקי טכנולוגיות פרסום יכולים להשבית את הקריאות ל-joinCustomAudience בשמם, ולאפשר רק ל-API של fetchAndJoinCustomAudience להפעיל את כל הקהלים בהתאמה אישית של הקריאות. אפשר לעדכן את אמצעי הבקרה במהלך ההרשמה לארגז החול לפרטיות. חשוב לזכור שהאמצעי הזה מאפשר להפעיל את כל טכנולוגיות הפרסום או לא להפעיל אף אחת מהן. עקב מגבלות בפלטפורמה, אי אפשר להקצות הרשאות הענקה לפי פלטפורמת מודעות.

תגובה של מודעות ומטא-נתונים של מועמדים

המודעות המועמדות והמטא-נתונים שמוחזרים מפלטפורמה בצד הקונה צריכים לכלול את השדות הבאים:

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

תהליך עבודה לבחירת מודעות

מטרת ההצעה הזו היא לשפר את הפרטיות באמצעות Ad Selection API, שמנהל את ביצוע המכרזים בפלטפורמות של טכנולוגיות פרסום.

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

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

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

תרשים זרימה שמראה את התחלת תהליך העבודה של בחירת המודעות.

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

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

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

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

הפעלת תהליך העבודה לבחירת מודעות

כשהאפליקציה צריכה להציג מודעה, ה-SDK של הפלטפורמה לפרסום דיגיטלי עשוי להפעיל את המודעה תהליך הבחירה של המוצר, על ידי הפעלה של השיטה selectAds() אחרי שיוצרים את האובייקט האובייקט AdSelectionConfig עם הפרמטרים הצפויים:

בית עסק: מזהה של פלטפורמת המודעות בצד המוכר, אחרי הסיומת eTLD+1 פורמט
כתובת ה-URL של לוגיקה של החלטה: כשמתחיל מכרז על מודעה, הפלטפורמה משתמשת בכתובת ה-URL הזו כדי לאחזר קוד JavaScript מהפלטפורמה של הצד המוכר כדי להעניק ניקוד למודעת הזוכה.
קונים של קהלים בהתאמה אישית: רשימה של פלטפורמות בצד הקונה עם התאמה אישית ביקוש מבוסס-קהל למכרז הזה, בפורמט eTLD+1.
אותות לבחירת מודעות: מידע על המכרז (גודל המודעה, פורמט המודעה וכו').
אותות של אתר מכירה: ספק אותות ספציפיים לפלטפורמה צדדית.
כתובת URL של אותות ציונים מהימנים: כתובת URL של נקודת קצה (endpoint) של אות מהימן בצד המוכר מאיזה מידע ניתן לאחזר את המידע הספציפי של הקריאייטיב בזמן אמת.
Per buyer signals: צדדים של ביקוש שמשתתפים במכרז יכולים להשתמש בפרמטר הזה כדי לספק קלט למכרז. לדוגמה, הפרמטר הזה יכול לכלול מידע מקיף לפי הקשר שיועיל לקביעת הצעות מחיר.

קטע הקוד הבא הוא דוגמה ל-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);

לוגיקה של בידינג בצד הקונה

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

הפלטפורמה תשתמש במטא-נתונים 'כתובת ה-URL של לוגיק הבידינג' של הקהל המותאם אישית כדי לאחזר את קוד ה-JavaScript, שצריך לכלול את חתימה הפונקציה הבאה:

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

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

הפונקציה מצפה לפרמטרים הבאים:

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

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

לוגיקה של ניקוד בצד המוכר

לוגיקת הציון בדרך כלל מסופקת על ידי הפלטפורמה בצד המוכר. מטרת הקוד היא לקבוע את המודעה הזוכה על סמך הפלט של לוגיקת הבידינג. ייתכן להפעיל לוגיקה עסקית נוספת כדי לקבוע את התוצאה. אם יש כמה ספקים של לוגיקה של החלטות, המערכת לא מבטיחה את רצף הביצועים בין הספקים. הפלטפורמה תשתמש בפרמטר הקלט 'כתובת ה-URL של לוגיקה של החלטה' של ה-API ‏selectAds() כדי לאחזר את קוד ה-JavaScript, שצריך לכלול את חתימה הפונקציה הבאה:

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

הפונקציה מצפה לפרמטרים הבאים:

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

זמן ריצה של קוד בחירת המודעות

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

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

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

שפת תכנות

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

עיבוד המודעה הזוכה

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

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

דיווח על חשיפות ואירועים

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

דיווח בצד המוכר.
דיווח בצד הקונה.

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

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

Protected Audience API מספק מנגנון הרשמה לאירועים עתידיים שקשורים אליהם מכרז מנצח באמצעות רישום משׂואות רשת (beacons). בreportResult() של בית העסק של JavaScript, פלטפורמות בצד המוכר יכולות לרשום איתותים באמצעות בפונקציה registerAdBeacon() בפלטפורמה. באופן דומה, פלטפורמות בצד הקונה יכולות לקרוא באמצעות registerAdBeacon() מפונקציית ה-JavaScript reportWin().

registerAdBeacon(beacons)

קלט:

event_key: מחרוזת שמציינת לאיזה סוג אינטראקציה להירשם. הוא משמש כמפתח לחיפוש נקודת הקצה (endpoint) שהפלטפורמה שולחת אליה הודעות ping בזמן הדיווח על תוצאות המכרז.
reporting_url: כתובת ה-URL בבעלות פלטפורמת הפרסום הדיגיטלי לטיפול באירוע.

מפתחות אירועים הם מזהי מחרוזות בבעלות ה-SDK בצד המוכר האחראי לדיווח על תוצאות המכרז. כדי שתתבצע התקשרות חזרה, טכנולוגיות הפרסום רושמים משׂואות רשת (beacons) עם מפתחות שתואמים למפתחות המשמשים בצד המוכר בזמן הדיווח על האירועים. הם לא חייבים להיות אנונימיים, למרות שיש מגבילה את הכמות והאורך של המפתחות שאפשר לרשום קהל מותאם אישית. אם reportEvent() נקרא, פלטפורמות בצד המכירה שהפעילו את המכרז תמיד זכאיות לקבל את דוחות האירועים האלה. רק הפלטפורמה הזוכה בצד הקונה תהיה זכאית לקבל את הדוחות האלה.

דיווח בצד המוכר

הפלטפורמה מפעילה את פונקציית ה-JavaScript reportResult() באספקה קוד שסופק על ידי בית העסק, שהורד מכתובת ה-URL של לוגיקת ההחלטה של בית העסק פרמטר ל-API של selectAds():

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 לדיווח: הפלטפורמה מפעילה את כתובת ה-URL הזו שמוחזרת מהפונקציה.
אותות לקונה: אובייקט JSON שיועבר אל reportWin של הקונה מותאמת אישית.

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

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

דוחות בצד הקונה

הפלטפורמה מפעילה את פונקציית ה-JavaScript reportWin() בביקוש קוד שסופק על ידי צד, שהורד מהמטא-נתונים של כתובת ה-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 לדיווח: הפלטפורמה מפעילה את כתובת ה-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 (אופציונלי) משמש לשילוב עם Attribution Reporting API. הוא יכול להיות אובייקט InputEvent (לאירוע קליקים) או null (לאירוע צפייה). פרטים נוספים על הפרמטר הזה זמינים במאמר שילוב Attribution Reporting API.

אחרי שערכת ה-SDK בצד המוכר מפעילה את reportEvent, ובהתאם הדגל reporting_destinations, הפלטפורמה מנסה להתאים את event_key אל המפתחות שרשומים על ידי קונים ואתרי מכירה בreportWin reportResult פונקציות JavaScript. אם קיימת התאמה, הפלטפורמה מפרסמת את event_data אל reporting_url המשויך. סוג התוכן של הבקשה הוא טקסט פשוט, והגוף הוא event_data. מומלץ לעשות זאת בצורה הטובה ביותר מנסה להיכשל באופן שקט במקרה של שגיאה בחיבור לרשת, שגיאה בחיבור לשרת או אם לא נמצאו מפתחות תואמים.

שילוב עם Attribution Reporting API

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

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

יוצרים מפה של מפתח-ערך של מזהי URI שישמשו גם לדיווח על אינטראקציות עם מודעות וגם לרישום מקורות.
צריך לכלול את נתוני המכרזים מהמכרז של הקהל המוגן במיפוי המפתחות שלהם בצד המקור, לצורך דיווח על סיכום מרוכז (באמצעות Attribution Reporting API). מידע נוסף זמין במסמך ההצעה לתכנון של ARA.

כשמשתמש רואה מודעה או לוחץ עליה:

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

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

reportEvent() יקבל פרמטר אופציונלי חדש, InputEvent. זכייה קונים שרושמים משׂואות רשת (beacon) של מודעות יכולים לבחור אילו דוחות 'אירועים' יקבלו רשום בממשקי Attribution Reporting API כמקור רשום. הכותרת Attribution-Reporting-Eligible תתווסף לכל בקשות הדיווח על אירועים שנשלחות מ-reportEvent(). תשובות עם כותרות ARA מתאימות ינותחו באותו אופן שבו כל רישום מקור רגיל אחר של ARA התשובה תהיה. הסבר על Attribution Reporting API לרשום כתובת URL של מקור.

מאחר ש-ARA ב-Android תומך באירועי צפייה ובאירועי קליקים, המערכת משתמשת ב-InputEvents כדי להבדיל בין שני הסוגים. בדיוק כמו במקור של ARA רישום, ה-API של reportEvent() יפרש תוכן שמאומת באמצעות פלטפורמה InputEvent כאירוע קליק. אם השדה InputEvent חסר, לא חוקי או null, רישום המקור ייחשב בתור תצוגה.

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

דוגמה לדיווח על התעניינות והמרות

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

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

תהליך העבודה: לפני שהמכרז מתחיל, הקונה שולח למוכ"ז מזהה ייחודי כחלק מתגובה פרוגרמטית להצעת מחיר בבידינג בזמן אמת (RTB). אפשר להגדיר את המזהה כמשתנה כמו auctionId. המזהה מועבר בתור perBuyerSignals ב- auctionConfig והוא יהיה זמין בלוגיקת הבידינג של הקונה.

במהלך ההפעלה של reportWin, הקונה יכול לרשום איתות מודעה כדי מופעלות בזמן רינדור המודעה ובאירועי אינטראקציה ספציפיים (registerAdBeacon()). כדי לשייך אותות של מכרז לאירוע של מודעה, צריך להגדיר את auctionId כפרמטר בשאילתה של כתובת ה-URL של משׂואת רשת (beacon).
במהלך עיבוד המודעה, משׂואות רשת (beacon) שרשמתם בזמן המכרז יכולים מופעלות או משופרות באמצעות נתונים ברמת האירוע. בית העסק צריך להפעיל reportEvent() ולהעביר את הנתונים ברמת האירוע. הפלטפורמה תשלח פינג לכתובת ה-URL הרשומה של משואת המודעות של הקונה, שתואמת ל-reportEvent() שהופעל.
הקונה ירשום את המודעה ב-Attribution Reporting API עד שמגיבות לבקשות של חיישן המודעה עם הכותרת Attribution-Reporting-Register-Source. כדי לשייך אותות של מכרז עבור אירוע המרה, מגדירים את auctionId בכתובת ה-URL של מקור הרישום.

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

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

שרת מהימן בניהול של פלטפורמת טכנולוגיית פרסום

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

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

צד הקונה: אחרי שצד הקונה מפעיל את הלוגיקה של הבידינג בצד הקונה, הפלטפורמה מבצעת אחזור HTTP של נתוני בידינג מהימנים מהשרת המהימן. כתובת ה-URL מורכבת מהכתובת והמפתחות שמופיעים במטא-נתונים של אותות ה-Trusted Bidding של הקהל המותאם אישית שעובד. האחזור הזה מתבצע רק במהלך עיבוד מודעות מהקהלים המותאמים אישית שנשמרו במכשיר. בשלב הזה, צד הקונה יכול לאכוף תקציבים, לבדוק אם יש קמפיין מצב השהיה וביטול השהיה, ביצוע טירגוט וכו'.

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

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

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

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

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

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

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

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

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

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

קונים ומוכרים יכולים להשתמש בשרת מהימן נפוץ מסוג מפתח/ערך עבור בפלטפורמות שתואמות לארגז החול לפרטיות ב-Android ובאינטרנט.