דיווח על ניפוי באגים עבור Protected Audience

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

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

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

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

מידע נוסף זמין במאמר [דיווח על ניפוי באגים בהצעה המקורית של Chrome לגרסת המקור לניסיון של FLEDGE][10].

שימוש

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

• forDebuggingOnly.reportAdAuctionWin(String url)
• forDebuggingOnly.reportAdAuctionLoss(String url)

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

let someDebuggableVariable = 123;
const url = "https://example.com/reportLoss?winningBid=${winningBid}&someDebuggableVariable=" + someDebuggableVariable;
forDebuggingOnly.reportAdAuctionLoss(url);

התבנית ${winningBid} מוחלפת בערך האמיתי אחרי שהמכרז מסתיים.

המוכרים יכולים להחזיר rejectReason מפונקציית scoreAds שלהם:

function scoreAd(ad, bid, auction_config, seller_signals,
                 trusted_scoring_signals, contextual_signal,
                 custom_audience_signal) {
  let score = ...
  return {
    'status': 0,
    'score': score,
    'rejectReason': 'blocked-by-publisher'
  }
}

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

משתני כתובת URL

המשתנים שאפשר להוסיף לכתובת ה-URL לניפוי באגים תואמים למקבילים שלהם ב-Chrome (אבל ${topLevelWinningBid} ו-${topLevelMadeWinningBid} לא זמינים כי אין מושג של מכרזים של רכיבים ב-Android).

מגבלות

• מארח כתובת ה-URL צריך להתאים לדומיין של ארגז החול לפרטיות שאליו נרשמתם.
• כתובת ה-URL לא יכולה להכיל יותר מ-4,096 תווים, כולל הדומיין, התחילית https:// ונתוני המכרז החלופיים.
• בגרסאות עתידיות, פעולות ניפוי הבאגים יישלחו רק כשיש חיבור לרשת Wi-Fi.

התנהגות במכשיר

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

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

• fledge_event_level_debug_reporting_batching_rate
• fledge_event_level_debug_reporting_batch_size

זמן האחזור הצפוי של דוח ניפוי באגים הוא בין 15 ל-60 דקות אחרי סיום המכרז.

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

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

לבסוף, אם המשתמש השבית את AdId, יישלח דוח ניפוי באגים. ההטמעה הזו לא בוצעה ב-Developer Preview 9, אבל היא תבוצע בגרסאות עתידיות.

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

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

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