सुरक्षित ऑडियंस के लिए डीबग रिपोर्टिंग

सुरक्षित ऑडियंस डीबग रिपोर्टिंग की मदद से विज्ञापन तकनीक बनाने वाले डेवलपर, रिमोट यूआरएल के बारे में एलान कर सकते हैं, ताकि नीलामी जीतने या हारने पर, डिवाइस से जीईटी अनुरोध पा सकें. ऐसा करने पर, इस्तेमाल के ये उदाहरण उपलब्ध हो सकते हैं:

  • नीलामी के जीतने वाले और हारने के नतीजों की रिपोर्ट पाएं.
  • जानें कि नीलामियां क्यों नहीं होती हैं. उदाहरण के लिए: समझें कि क्या यह समस्या बिडिंग या स्कोरिंग स्क्रिप्ट को लागू करने या लॉजिक से जुड़ी कोई मुख्य समस्या है.
  • JavaScript लॉजिक के अपडेट होने पर आने वाली समस्याओं का पता लगाएं

इवेंट-लेवल डीबग रिपोर्टिंग, प्राइवसी सैंडबॉक्स के डेवलपर झलक 9 में जांच के लिए उपलब्ध है. डीबग रिपोर्टिंग उन सभी डिवाइसों पर काम करती है, जहां AdId उपलब्ध है.

लंबे समय का प्लान यह है कि प्लैटफ़ॉर्म, प्राइवेट एग्रीगेशन सेवा की मदद से नीलामी के नतीजों की रिपोर्ट कर सके. इससे यह पक्का होता है कि तथ्यों के आधार पर रिपोर्टिंग का इस्तेमाल, पब्लिशर के ऐप्लिकेशन में अलग-अलग उपयोगकर्ताओं की कस्टम ऑडियंस से जुड़ने के लिए नहीं किया जा सकता. रिपोर्टिंग के लिए ज़रूरी फ़्रेमवर्क रिलीज़ होने तक, इवेंट-लेवल की रिपोर्टिंग कुछ समय के लिए होती है.

Chrome के मूल FLEDGE ऑरिजिन ट्रायल ट्रायल प्रपोज़ल में डीबग रिपोर्टिंग के बारे में ज़्यादा जानें.

इस्तेमाल का तरीका

डीबग रिपोर्टिंग, नीचे दिए गए JavaScript API का इस्तेमाल करके लागू की जाती है. ये दोनों ही, यूआरएल स्ट्रिंग तर्क का इस्तेमाल करते हैं:

  • 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} टेंप्लेट को असल वैल्यू से बदल दिया जाता है.

विक्रेता वैकल्पिक रूप से अपने scoreAds फ़ंक्शन से rejectReason लौटा सकते हैं:

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 भेजा जाता है.

यूआरएल वैरिएबल

डीबग यूआरएल में जोड़े जा सकने वाले वैरिएबल, 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

कंस्ट्रेंट

  • यूआरएल होस्ट, आपके रजिस्टर किए गए प्राइवसी सैंडबॉक्स के डोमेन से मैच होना चाहिए.
  • यूआरएल में 4,096 से ज़्यादा वर्ण नहीं होने चाहिए. इनमें डोमेन, https:// प्रीफ़िक्स, और बदले गए नीलामी का डेटा शामिल है.
  • आगे की रिलीज़ में, डीबग पिंग सिर्फ़ वाई-फ़ाई से कनेक्ट होने पर ही भेजे जाते हैं.

डिवाइस पर व्यवहार

मोबाइल के मामले में, मेमोरी और नेटवर्क के इस्तेमाल को सुरक्षित रखना सबसे अहम है. इसलिए, डीबग रिपोर्ट बैच में होती हैं.

नीचे दी गई सिस्टम प्रॉपर्टी बैच रेट और साइज़ को कंट्रोल करती हैं, जिन्हें डेवलपमेंट के लिए कम वैल्यू के साथ बदला जा सकता है:

  • fledge_event_level_debug_reporting_batching_rate
  • fledge_event_level_debug_reporting_batch_size

नीलामी पूरी होने के बाद, डीबग रिपोर्ट को प्रोसेस होने में 15 से 60 मिनट लग सकते हैं.

डीबग रिपोर्ट के पूरा होने की कोई गारंटी नहीं है. अगर सर्वर पर कॉल भेजने से पहले ही डिवाइस रीबूट होता है या adservices प्रोसेस क्रैश हो जाती है, तो ये इवेंट छोड़ दिए जाते हैं.

हर विज्ञापन टेक्नोलॉजी के लिए, हर नीलामी में ज़्यादा से ज़्यादा 75 रजिस्टर किए गए डीबग यूआरएल हो सकते हैं. उस सीमा पर पहुंचने के बाद, रजिस्टर किए गए यूआरएल को बिना किसी सूचना के हटा दिया जाता है.

आखिर में, अगर उपयोगकर्ता ने AdId को बंद कर दिया है, तो डीबग रिपोर्ट भेजी जाती हैं. इसे डेवलपर प्रीव्यू 9 में लागू नहीं किया गया है, लेकिन आने वाले वर्शन में इसे लागू किया जाएगा.

विज्ञापन टेक्नोलॉजी सर्वर का व्यवहार

डीबग रिपोर्टिंग के लिए, विज्ञापन टेक्नोलॉजी सर्वर में ये काम होने चाहिए:

  • डिवाइस, आपके बताए गए सर्वर पर forDebuggingOnly.* एपीआई के साथ जीईटी अनुरोध भेजता है.
  • हर अनुरोध, इवेंट-लेवल की एक डीबग रिपोर्ट दिखाता है: विज्ञापन नीलामी में सिर्फ़ एक जीत या नीलामी में हार.
  • हर अनुरोध का कोई मुख्य हिस्सा नहीं होता. सारा डेटा, क्वेरी पैरामीटर में है.
  • बड़े रिस्पॉन्स पेलोड, परफ़ॉर्मेंस और डेटा खर्च पर बुरा असर डाल सकते हैं. इन्हें नज़रअंदाज़ किया जाता है.