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

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

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

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

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

[Chrome के मूल FLEDGE ऑरिजिन ट्रायल के प्रस्ताव में, डीबग रिपोर्टिंग के बारे में ज़्यादा जानें][10].

इस्तेमाल

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

  • 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 बिड की वह वैल्यू जिसे सेलर की scoreAd स्क्रिप्ट ने सबसे ज़्यादा के बाद दूसरी सबसे ज़्यादा वैल्यू के तौर पर स्कोर किया था. ध्यान दें कि यह बिड की दूसरी सबसे ज़्यादा वैल्यू नहीं हो सकती, क्योंकि स्कोर और बिड अलग-अलग हो सकती हैं.
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

कंस्ट्रेंट

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

डिवाइस पर होने वाली गतिविधि

मोबाइल प्लैटफ़ॉर्म पर, मेमोरी और नेटवर्क के इस्तेमाल को सुरक्षित रखना सबसे ज़रूरी है. इसलिए, डीबग रिपोर्ट एक साथ भेजी जाती हैं.

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

  • fledge_event_level_debug_reporting_batching_rate
  • fledge_event_level_debug_reporting_batch_size

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

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

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

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

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

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

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