إعداد تقارير تصحيح الأخطاء للجمهور المحمي

تتيح ميزة إعداد تقارير تصحيح الأخطاء في Protected Audience لمطوّري تكنولوجيا الإعلان إدخال عناوين URL بعيدة لتلقّي طلب GET من الأجهزة عند الفوز بمزاد أو خسارته. يتيح ذلك حالات الاستخدام التالية:

  • تلقّي تقارير عن نتائج المزادات التي تم الفوز بها أو خسارتها
  • فهم أسباب عدم الفوز بالمزادات على سبيل المثال، يمكنك معرفة ما إذا كانت هناك مشكلة في تنفيذ نص برمجي خاص بتقديم عروض الأسعار أو تسجيل النقاط أو مشكلة في المنطق الأساسي.
  • رصد المشاكل عند تعديل منطق JavaScript

تتوفّر ميزة "إعداد تقارير تصحيح الأخطاء على مستوى الحدث" للاختبار في الإصدار التجريبي التاسع من "مبادرة حماية الخصوصية". تتوفّر ميزة "إعداد تقارير تصحيح الأخطاء" على جميع الأجهزة التي يتوفّر فيها معرّف الإعلانات.

تتمثّل الخطة طويلة الأمد في إتاحة إمكانية إبلاغ المنصة بنتائج المزاد باستخدام خدمة "تجميع البيانات الخاص". يضمن ذلك عدم إمكانية استخدام ميزة إعداد التقارير بأثر رجعي لربط شرائح الجمهور المخصّصة للمستخدمين الفرديين بتطبيق الناشر. إنّ ميزة إعداد التقارير على مستوى الحدث هي ميزة مؤقتة إلى أن يتم إطلاق إطار عمل مناسب لإعداد التقارير.

مزيد من المعلومات عن [اقتراح تقارير تصحيح الأخطاء في مرحلة التقييم والتجربة الأصلية لـ FLEDGE في Chrome][10]

الاستخدام

يتم تنفيذ تقارير تصحيح الأخطاء باستخدام واجهات برمجة التطبيقات التالية المستندة إلى 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 تمثّل هذه السمة قيمة عرض السعر الذي حصل على ثاني أعلى نتيجة في البرنامج النصي 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

القيود

  • يجب أن يتطابق مضيف عنوان URL مع نطاق Privacy Sandbox المسجّل.
  • يجب ألا يتجاوز عنوان URL 4096 حرفًا، بما في ذلك النطاق والبادئة https:// وبيانات المزاد البديلة.
  • في الإصدارات المستقبلية، لن يتم إرسال طلبات اختبار تصحيح الأخطاء إلا عند الاتصال بشبكة Wi-Fi.

السلوك على الجهاز فقط

في بيئة الأجهزة الجوّالة، تُعد حماية الذاكرة واستخدام الشبكة من الأولويات الأساسية. وبالتالي، يتم إعداد تقارير تصحيح الأخطاء على شكل دفعات.

تتحكّم خصائص النظام التالية في معدّل الدفعات وحجمها، ويمكن تعديلها إلى قيم أقل لأغراض التطوير:

  • fledge_event_level_debug_reporting_batching_rate
  • fledge_event_level_debug_reporting_batch_size

تتراوح مدة الاستجابة المتوقّعة لتقرير تصحيح الأخطاء بين 15 و60 دقيقة بعد اكتمال المزاد.

لا تتوفّر ضمانات قاطعة بشأن اكتمال تقارير تصحيح الأخطاء. إذا تمت إعادة تشغيل الجهاز أو تعطّلت عملية adservices قبل إرسال الطلبات إلى الخادم، سيتم تجاهل هذه الأحداث.

يبلغ الحدّ الأقصى لعدد عناوين URL المسجّلة لتصحيح الأخطاء لكلّ مزاد 75 عنوانًا لكلّ تكنولوجيا إعلانية. يتم تجاهل عناوين URL المسجّلة بعد بلوغ هذا الحدّ الأقصى بدون إشعار.

أخيرًا، إذا أوقف المستخدم AdId، سيتم إرسال تقارير تصحيح الأخطاء. لم يتم تنفيذ ذلك في الإصدار 9 من "معاينة المطوّرين"، ولكن سيتم تنفيذه في الإصدارات المستقبلية.

سلوك خادم تقنية الإعلان

يجب أن تتضمّن خوادم تكنولوجيا الإعلان السلوكيات التالية لإعداد تقارير تصحيح الأخطاء:

  • يرسل الجهاز طلبات استرداد بيانات باستخدام GET إلى الخادم الذي تحدّده باستخدام واجهات برمجة التطبيقات forDebuggingOnly.*.
  • يمثّل كل طلب تقريرًا واحدًا لتصحيح الأخطاء على مستوى الحدث: فوز واحد في مزاد الإعلانات أو خسارة واحدة في المزاد.
  • لا يتضمّن كل طلب نصًا أساسيًا. تكون جميع البيانات في مَعلمات طلب البحث.
  • يمكن أن تؤثّر حمولات الاستجابة الكبيرة سلبًا في الأداء واستخدام البيانات، ويتم تجاهلها.