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

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

  • 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 דקות לאחר סיום המכרז.

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

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

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

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

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

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