דיווח על תוצאות ניפוי באגים ב-Protected Audience API מאפשר למפתחי טכנולוגיות פרסום להצהיר על כתובות URL מרוחקות כדי לקבל בקשת GET ממכשירים במקרה של זכייה במכרז או אובדן שלו. כך אפשר להשתמש בתרחישים הבאים:
- קבלת דוחות לגבי תוצאות מכרזים שנצברו והפסידו.
- מבינים למה אתם מפסידים מכירות פומביות. לדוגמה: בדקו אם מדובר בבעיה בהטמעה של סקריפט של בידינג או של ציון, או בבעיה לוגית מהותית.
- בעיות בעדכון הלוגיקה של JavaScript
דיווח על ניפוי באגים ברמת האירוע זמין לבדיקה בתצוגה מקדימה למפתחים 9 של ארגז החול לפרטיות. דיווח על ניפוי באגים נתמך בכל המכשירים שבהם מזהה הפרסום זמין.
התוכנית לטווח הארוך היא לאפשר לפלטפורמה לדווח על תוצאות המכרז באמצעות שירות הצבירה הפרטית. כך ניתן להבטיח שלא ניתן יהיה להשתמש בדיווח לאחר מעשה כדי לצרף קהלים בהתאמה אישית של משתמשים ספציפיים לאפליקציה של בעל האפליקציה. דיווח ברמת האירוע הוא זמני, עד שתפורסם מסגרת דיווח מתאימה.
למידע נוסף על דיווח על ניפוי באגים בהצעה המקורית של גרסת המקור לניסיון של FLEDGE ב-Chrome.
Usage
הדיווח על ניפוי הבאגים מוטמע באמצעות ממשקי ה-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 לניפוי באגים תואמים למשתנים האחרים שלהם ב-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 דקות לאחר סיום המכרז.
אין ערובה קשיחה לגבי שלמות הדוחות של ניפוי הבאגים. אם המכשיר מופעל מחדש או שתהליך שירותי הפרסום קורס לפני שהקריאות לשרת נשלחות, האירועים האלה מושמטים.
לכל טכנולוגיית פרסום יש מגבלה של 75 כתובות URL רשומות לניפוי באגים לכל מכרז. כתובות URL שנרשמו אחרי שמגיעים למגבלה הזו מושמטות באופן שקט.
לבסוף, אם המשתמש השבית AdId, דוחות ניפוי באגים נשלחים. ההגדרה הזו לא מוטמעת בגרסה 9 למפתחים, אבל היא תיושם בגרסאות עתידיות.
התנהגות של שרת פרסום דיגיטלי
שרתי פרסום דיגיטלי צריכים לפעול לפי ההתנהגויות הבאות לצורך דיווח על ניפוי באגים:
- המכשיר שולח בקשות GET לשרת שציינתם באמצעות ממשקי ה-API של
forDebuggingOnly.*
. - כל בקשה מייצגת דוח אחד של ניפוי באגים ברמת האירוע: זכייה יחידה במכרז של מודעות או הפסד במכירה פומבית.
- לכל בקשה אין גוף. כל הנתונים נמצאים בפרמטרים של השאילתה.
- מטענים ייעודיים (payloads) גדולים של תגובות יכולים להשפיע לרעה על הביצועים ועל השימוש בנתונים, והמערכת מתעלמת מהם.