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

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

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

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

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

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

שימוש

הדיווח על תוצאות ניפוי הבאגים מוטמע באמצעות ממשקי ה-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).

שם המשתנה תיאור
winningBid הערך של הצעת המחיר שזכתה במכרז.
madeWinningBid ערך בוליאני שמייצג אם הקונה של ההתאמה האישית הזו הגיש את הצעת המחיר הזוכה, על ידי הקהל המותאם אישית הזה או קהל בהתאמה אישית עם אותו קונה.
highestScoringOtherBid הערך של הצעת המחיר שקיבלו את הדירוג השני הגבוה ביותר של סקריפט המודעה של דירוג המפיץ. לתשומת ליבכם: לא בטוח שזו תהיה הצעת המחיר השנייה בגובהה מפני שהציונים והצעות המחיר יכולים להיות בלתי תלויים.
madeHighestScoringOtherBid ערך בוליאני שמייצג אם הקונה של הקהל המותאם אישית הזה הגיש את הצעת המחיר ${highestScoringOtherBid}, על ידי התאמה אישית זו קהל או קהל אחר בהתאמה אישית עם אותו קונה.
rejectReason מחרוזת אופציונלית שהוגדרה על ידי בית העסק, שמסבירה למה הוא דחה להצעת מחיר. הוא יכול להיות כל אחד מהערכים הבאים:

  • not-available
  • invalid-bid
  • bid-below-auction-floor
  • pending-approval-by-exchange
  • disapproved-by-exchange
  • blocked-by-publisher
  • language-exclusions
  • category-exclusions

מגבלות

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