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

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

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

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

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

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

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

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

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