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