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

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

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

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

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

באמצעות Protected Audience, אפשר:

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

כדי להתחיל, כדאי לקרוא את המדריך למפתחים עם 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
דיווח על אינטראקציות	רבעון 2 של 2023	רבעון 3 של 2023
איך מצטרפים אל הקצאת הרשאות לניהול קהלים בהתאמה אישית	רבעון 3 של 2023	רבעון 4 של 2023
חיוב ללא עלות לאלף חשיפות	רבעון 3 של 2023	רבעון 4 של 2023
שילוב של שירותי בידינג ומכרזים	רבעון 3 של 2023	רבעון 4 של 2023
דיווח על ניפוי באגים	רבעון 3 של 2023	רבעון 4 של 2023
שילוב של דוחות שיוך (Attribution)	לא רלוונטי	רבעון 4 של 2023
תהליך בחירת הרשת (Mediation) ב-Open Bidding	רבעון 4 של 2023	רבעון 4 של 2023
ניהול מטבעות	רבעון 1 2024	רבעון 2 של 2024
שילוב K-anon	לא רלוונטי	רבעון 2 של 2024
שילוב הדוחות המצטברים	רבעון 3 של 2024	רבעון 4 של 2024

סקירה כללית

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בקרה של פלטפורמות פרסום דיגיטלי

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שפת תכנות

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

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

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

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

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

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

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

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

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

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

registerAdBeacon(beacons)

קלט:

event_key: מחרוזת שמציינת את סוג האינטראקציה שיש להירשם אליה. הוא משמש כמפתח לחיפוש נקודת הקצה של הפינגים של הפלטפורמה בזמן הדיווח על תוצאות המכרז.
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 הוא הפלט של הדוח בצד המוכר. כך הפלטפורמה בצד המוכר יכולה לשתף נתונים עם הפלטפורמה בצד הקונה למטרות דיווח.
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, אנחנו מספקים פונקציונליות ברשתות API שונות בממשקי Protected Audience and Attribution Reporting API (ARA). הפונקציונליות הזו מאפשרת לטכנולוגיות של מודעות להעריך את ביצועי השיוך שלהן בשיטות רימרקטינג שונות, כדי להבין אילו סוגי קהלים מניבים את החזר ה-ROI הגבוה ביותר.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שרת מהימן המנוהל על ידי פלטפורמת פרסום דיגיטלי

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

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

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