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

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

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

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

Protected Audience נמצא בשלב בטא וזמין לבדיקה במכשירים ציבוריים!

עם Protected Audience אפשר:

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

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

ציר הזמן

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

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

סקירה כללית

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

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

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

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

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

ככלל, השילוב פועל כך:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הערה לגבי ההגדרה והאחסון של אסימון האימות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מפתחות אירועים הם מזהים של מחרוזות שנמצאים בבעלות ה-SDK בצד המכירה שאחראי לדיווח על תוצאות המכרז. כדי שתתבצע התקשרות חזרה, טכנולוגיות הפרסום רושמים משׂואות רשת (beacons) עם מפתחות שתואמים למפתחות המשמשים בצד המוכר בזמן הדיווח על האירועים. הם לא חייבים להיות אנונימיים לפי k, אבל יש מגבלות על הכמות והאורך של המפתחות שאפשר לרשום לקהל מותאם אישית נתון. אם השם 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 הוא הפלט של דוח התוצאה בצד המוכר. כך אפשר לקבל לפלטפורמה בצד המוכר, עם הזדמנות לשתף נתונים עם הצד הקונה למטרות דיווח.
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) API. הוא אובייקט InputEvent (לאירוע מסוג קליק) או שהוא ערך null (לאירוע של צפייה). מידע נוסף זמין במאמר שילוב של Attribution Reporting API פרטים על הפרמטר הזה.

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

שילוב של Attribution Reporting API

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

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

יצירת מפה של מזהי URI שמשמשים את שניהם 1) דיווח על אינטראקציות עם מודעות ו-2) רישום מקור.
לכלול נתוני מכרז מהמכרז של Protected Audience בצד המקור מיפוי מרכזי לדיווח סיכום מצטבר (באמצעות 'דיווח ייחוס' API) מידע נוסף זמין בהצעה לעיצוב של ARA.

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

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

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

הפרמטר reportEvent() יקבל פרמטר אופציונלי חדש, InputEvent. קונים שזכו במכרז ורשמים משואות פרסום יכולים לבחור אילו דוחות reportEvent ירשמו ב-Attribution Reporting API כמקור רשום. הבקשה הכותרת 'כשיר לדיווח על שיוך (Attribution)' תתווסף לכל הדיווחים על אירועים בקשות שנשלחו מאת 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 מורכב מצירוף של כתובת ה-URL והמפתחות שקיימים בשיטת הבידינג המהימנה המטא-נתונים של האותות של הקהל בהתאמה אישית עבר עיבוד. האחזור הזה מתבצע רק כשמעבדים מודעות מהמכשיר בהתאמה אישית קהלים. בשלב הזה, צד הקונה יכול לאכוף תקציבים, לבדוק אם יש קמפיין מצב השהיה וביטול השהיה, ביצוע טירגוט וכו'.

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

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

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

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

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

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

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

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

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

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

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