تعديلات على اقتراحات إعداد تقارير الإحالة في كانون الثاني (يناير) 2022

خضع اقتراح "تقارير تحديد المصدر" لعدد من التغييرات بهدف ملاحظات المنتدى، من تغييرات آلية واجهة برمجة التطبيقات إلى الوظائف الجديدة.

سجلّ التغييرات

لمن هذه المشاركة؟

هذه المشاركة مخصّصة لك:

  • إذا كنت تفهم واجهة برمجة التطبيقات بالفعل، على سبيل المثال، إذا كنت تراقب أو يشاركون في المناقشات حول مستودع WICG ويريدون فهم مجموعة التغييرات التي تم إجراؤها على الاقتراح في كانون الثاني (يناير) 2022.
  • إذا كنت تستخدم Attribution Reporting API في عرض توضيحي أو في تجربة في مرحلة الإنتاج.

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

نقل البيانات إلى الآن

بعد تنفيذ هذه التغييرات في Chrome: إذا كنت تستخدم تقارير على مستوى الحدث من Attribution Reporting API في عرض توضيحي أو في تجربة في مرحلة الإنتاج (مرحلة التجربة والتقييم)، ستحتاج إلى تعديل الرمز الخاص بواجهة برمجة التطبيقات لمواصلة العمل. يمكنك أيضًا استخدام الميزات الجديدة.

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

تغييرات الأسماء

التقارير الموجزة والتقارير القابلة للتجميع

سيُشار الآن إلى ما قد تكون رأيت وصفًا له على أنّه تقارير مجمّعة. على أنّها تقارير موجزة.

التقارير الموجزة هي الإخراج النهائي لتجميع تقارير متعددة قابلة للتجميع، كان يطلق عليه سابقًا المساهمات أو المساهمات في المدرج التكراري.

تغييرات آلية واجهة برمجة التطبيقات

تسجيل المصدر المستند إلى العناوين (التقارير على مستوى الحدث)

ما هي التغييرات التي يتم إجراؤها، ولماذا؟

وعندما يشاهد المستخدم إعلانًا أو ينقر عليه، يسجِّل المتصفح هذا الحدث، على جهاز المستخدم محليًا، إلى جانب المَعلمات الخاصة بإعداد تقارير تحديد المصدر (مثل attributionsourceeventid وattributiondestination وattributionexpiry ومعلَمات أخرى). تشير رسالة الأشكال البيانية تُحدد قيم هذه المعلمات بواسطة adtech.

تتغير طريقة تعيين هذه المعلمات.

في الاقتراح السابق، كان يجب تضمين المعلمات من جهة العميل: إما في علامات الارتساء كسمات HTML أو كوسيطات لطلب مستند إلى JavaScript. يجب أن تكون المَعلمات معروفة عند النقر أو المشاهدة الوقت.

أمّا في الاقتراح الجديد، فيتم تحديد قيمة هذه المَعلمات على خادم adtech بدلاً من ذلك.

مخطّط بياني لتسجيل المصدر المستند إلى العناوين

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

كيف يتم تسجيل المصدر؟

  1. بالنسبة إلى إعلان معيّن، تحتاج تكنولوجيا الإعلان الآن إلى تحديد سمة معيّنة من جهة العميل attributionsrc قيمة هذه السمة هي عنوان URL الذي سيرسل إليه المتصفح request; سيتضمّن هذا الطلب عنوان HTTP جديدًا Attribution-Reporting-Source-Info يتم navigationأو event,ما إذا كان المصدر قد كان نقرة أو مشاهدة على التوالي.
  2. عند استلام هذا الطلب، من المفترض أن يستجيب خادم تتبُّع النقرات/العرض باستخدام HTTP Attribution-Reporting-Register-Source، الذي يحتوي على الإحالة المطلوبة المعلَمات.

  3. المصدر الذي يعرض هذا العنوان هو الآن أصل إعداد التقارير (الذي كان يُعرف سابقًا باسم attributionreportto).

    عنوان استجابة HTTP Attribution-Reporting-Register-Source:

    {
  "source_event_id": "267630968326743374",
  "destination": "https://toasters.example",
  "expiry": "604800000"
}

مزيد من المعلومات في الشرح الفني

تسجيل مصادر تحديد المصدر

الانضمام إلى المناقشة العامة

المشكلة رقم 261

مشغِّل تحديد المصدر المستند إلى العنوان (التقارير على مستوى الحدث)

ما هي التغييرات التي يتم إجراؤها، ولماذا؟

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

بالإضافة إلى ذلك، في الاقتراح الجديد، يجب توفير السمة attributionsrc في صفحة الإحالات الناجحة.

يستند الأساس المنطقي إلى مسألة الأذونات: في الاقتراح السابق، كان الموقع من جانب المشغل — عادةً، أحد مواقع المعلنين، وكان لديه تحكّم عام في الميزة من خلال عنوان Permissions-Policy، إلا أنّه على عنصر تحكُّم دقيق على مستوى العنصر في ما إذا كان يمكنه إرسال طلب إلى طرف ما التي ستؤدي في النهاية إلى تشغيل الإحالة. attributionsrc يغير هذا: هذه العلامة الإلزامية إلى المعلن القدرة على مراقبة العناصر التي يمكن أن تؤدي إلى ظهور الإحالة.

لاحظ أنه في الجانب المصدر، عادةً موقع الناشر، هو عنصر تحكم على مستوى الصفحة عبر تتوفر السمة Permissions-Policy، بالإضافة إلى عنصر تحكّم على مستوى العنصر من خلال attributionsrc.

كيف يعمل عامل تشغيل الإحالة؟

عند تلقّي طلب بشأن وحدات بكسل وقرار تصنيفه كإحالة ناجحة، يتم اعتبار تقنية الإعلان يجب أن تستجيب باستخدام HTTP جديد
الرأس Attribution-Reporting-Register-Event-Trigger.

تحدّد قيمة العنوان هذه كيفية التعامل مع حدث عامل التفعيل، باعتباره كائن JSON. تمامًا المعلومات التي تم تحديدها كمعلمات طلب بحث في الاقتراح السابق.

عنوان استجابة HTTP Attribution-Reporting-Register-Event-Trigger:

    [{
        trigger_data: (unsigned 3-bit integer),
        trigger_priority: (signed 64-bit integer),
        deduplication_key: (signed 64-bit integer)
    }]

إعادة التوجيه (اختياري)

ويمكن لخادم تكنولوجيا الإعلان اختياريًا إرسال الاستجابة التي تحتوي على Attribution-Reporting-Register-Event-Trigger كاستجابة لإعادة التوجيه. وبفضل ذلك، يمكن للجهات الخارجية مراقبة حدث الإحالة الناجحة وتوجيه المتصفّح إلى نسبه.

إعادة التوجيه اختيارية؛ لا تحتاج إلى ذلك عندما تحتوي كل من تقنية الإعلان والجهة الخارجية على وحدات بكسل في الصفحة.

يمكنك الاطّلاع على مزيد من التفاصيل في إعداد تقارير الجهات الخارجية.

مزيد من المعلومات في الشرح الفني

تشغيل ميزة تحديد المصدر

الانضمام إلى المناقشة العامة

المشكلة رقم 91

بلا وظيفة (تقارير قابلة للتجميع)

ما هي التغييرات التي يتم إجراؤها، ولماذا؟

في الاقتراح السابق للتقارير القابلة للتجميع، كان الوصول إلى JavaScript مطلوبًا لاستدعاء worklet - آلية تستند إلى JavaScript - يعمل على إنشاء هذه التقارير.

في الاقتراح الجديد، لا تكون هناك حاجة إلى أي عمل. بدلاً من ذلك، ستعرِّف تقنية الإعلان بشكل صريح - عبر HTTP هي القواعد التي يجب أن يستخدمها المتصفّح لإنشاء تقارير قابلة للتجميع.

يقدم الاقتراح الجديد عدة مزايا:

  • تنفيذ المتصفح: يختلف التصميم الجديد إلى حد كبير، على عكس تصميم الوظيفة المصغّرة، أبسط لأنه لا يتطلب بيئة تنفيذ جديدة في المتصفحات.
  • تجربة المطوِّر: يعتمد التصميم الجديد على العناوين التي يشيع استخدامها المعروفة على نطاق واسع من قبل المطورين - على عكس الأدوات الصغيرة. كما تتوافق بشكل وثيق مع سطح واجهة برمجة التطبيقات تسجيل المصدر، ما يسهّل التعرُّف على واجهة برمجة التطبيقات واستخدامها.
  • الاستخدام: يتيح التصميم الجديد للمزيد من أنظمة القياس الحالية استخدام تقنية التجميع. التقارير. يعتمد العديد من حلول القياس على بروتوكول HTTP فقط، حيث تعتمد على طلبات الصور — بكسل الطلبات التي لا تتطلب الوصول إلى JavaScript. ولكن نظرًا لأن نهج العمل يتطلب الوصول إلى JavaScript، ربما كان من الصعب الانتقال إليه من بعض أنظمة القياس الحالية.
  • المتانة: يساعد التصميم الجديد في الحدّ من فقدان البيانات لأنه من السهل دمجه. باستخدام دلالات keepalive، مثلاً إذا تم تسجيل نقرة أو مشاهدة عند مغادرة المستخدم صفحة.

كيف تعمل الآلية الخالية من العمل؟

وتستند هذه الآلية التعريفية إلى عناوين HTTP، تمامًا مثل تسجيل المصدر على مستوى الحدث. وعنوان عامل تشغيل الإحالة. تعرَّف على مزيد من التفاصيل حول هذا الموضوع في الأقسام التالية.

الانضمام إلى المناقشة العامة

المشكلة رقم 194

تسجيل المصدر المستند إلى العناوين (التقارير القابلة للتجميع)

تم اقتراح آلية جديدة لتسجيل مصدر للتقرير القابل للتجميع. هذه الآلية هو تمامًا مثل تسجيل المصدر على مستوى الحدث.

يختلف اسم العنوان فقط: Attribution-Reporting-Register-Aggregatable-Source.

مزيد من المعلومات في الشرح الفني

تسجيل مصدر مقياس الأداء

مشغِّل تحديد المصدر المستند إلى العنوان (التقارير القابلة للتجميع)

تم اقتراح آلية جديدة لتسجيل مصدر للتقرير القابل للتجميع. هذه الآلية هو هي نفسها مشغّل الإحالة على مستوى الحدث.

يختلف اسم العنوان فقط: Attribution-Reporting-Register-Aggregatable-Trigger-Data.

مزيد من المعلومات في الشرح الفني

تسجيل مشغِّل تحديد المصدر

الميزات الجديدة

إعداد تقارير الجهات الخارجية (التقارير على مستوى الحدث والتقارير القابلة للتجميع)

ما هي التغييرات التي يتم إجراؤها، ولماذا؟

يساعد جانبان للاقتراح الجديد في دعم حالات استخدام تقارير الجهات الخارجية بشكل أفضل:

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

كيف تعمل ميزة إعداد التقارير التابعة لجهات خارجية؟

في الاقتراح الجديد، يعتمد تسجيل المصدر القائم على الاستجابة والمشغّل على عناوين HTTP: ويمكن لتقنية الإعلان الاستفادة من عمليات إعادة توجيه HTTP لهذه الطلبات.

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

يمكن لكل طرف الوصول إلى تقاريره المنفصلة وإعدادها باستخدام بيانات منفصلة.

تسجيل عدة عوامل تشغيل بدون عمليات إعادة توجيه

ومن الممكن أيضًا تسجيل عوامل تشغيل متعددة لتحديد المصدر بدون استخدام عمليات إعادة التوجيه، وذلك من خلال إضافة عناصر بكسل متعددة على جانب الإحالة الناجحة (عنصر واحد لكل مشغّل).

الانضمام إلى المناقشة العامة

المشكلة رقم 91 المشكلة رقم 261

قياس نشاط العرض (التقارير على مستوى الحدث والتقارير القابلة للتجميع)

ما هي التغييرات التي يتم إجراؤها، ولماذا؟

وفي الاقتراح الجديد، يعمل كلٌّ من قياس نشاط العرض وقياس نسبة النقر إلى الظهور بطريقة موحّدة:

  • registerattributionsrc، وهي السمة الخاصة بالملف الشخصي التي وجّهت المتصفّح إلى تسجيل المشاهدات جنبًا إلى جنب مع النقرات، لم يعد جزءًا من الاقتراح.
  • وقد تم الآن توحيد آليات الخصوصية على مستوى النقرات والعرض. في هذه الحالة، يُرجى الاطّلاع على التفاصيل في قسم الضوضاء. والشفافية.

تم اقتراح هذا التغيير ليتوافق مع آلية التسجيل المستندة إلى رأس الصفحة الجديدة. يبسّط أيضًا تجربة المطوّرين عندما يريدون إتاحة كل من الإحالات الناجحة الناتجة عن النقر. القياس.

كيف يعمل قياس نشاط العرض؟

يعتمد كلّ من قياس نشاط العرض وقياس النقر إلى الظهور على التسجيل المستند إلى رأس الصفحة.

مزيد من المعلومات في الشرح الفني

التقارير على مستوى الحدث (لكلّ من النقرات والمشاهدات)

الانضمام إلى المناقشة العامة

المشكلة رقم 261

تصحيح الأخطاء / تحليل الأداء (التقارير على مستوى الحدث والتقارير القابلة للتجميع)

ما هي التغييرات التي يتم إجراؤها، ولماذا؟

وتمت إضافة آلية لتصحيح الأخطاء إلى الاقتراح لمساعدة المطوّرين في رصد الأخطاء. مقارنة أداء تقارير تحديد المصدر بحلول القياس الحالية المستندة إلى ملفات تعريف الارتباط.

مخطّط بياني لنظام تصحيح الأخطاء الجديد المستنِد إلى ملفات تعريف الارتباط

كيف يتم تصحيح الأخطاء؟

سيقبل كل من تسجيل المصدر وعامل التشغيل معلمة جديدة debug_key، وهي عبارة عن 64 بت غير موقَّعة عدد صحيح (أي عدد كبير).

في حال إنشاء تقرير باستخدام المصدر وتشغيل مفاتيح تصحيح الأخطاء وإذا كان ملف تعريف الارتباط Samesite=None ar_debug=1 متوفّر في حاوية ملفات تعريف الارتباط الخاصة بالمصدر لإعداد التقارير عند المصدر ووقت تسجيل المشغِّل، وهو تصحيح سيتم إرسال تقرير بتنسيق JSON إلى نقطة نهاية .well-known/attribution-reporting/debug:

{
  "source_debug_key": 1234567890987,
  "trigger_debug_key": 4567654345028
}

وستتضمّن التقارير على مستوى الحدث والتجميع أيضًا هاتين المَعلمتَين الجديدتَين، بحيث يمكن المرتبطة بتقرير تصحيح الأخطاء الصحيح.

مزيد من المعلومات في الشرح الفني

اختياري: تقارير تصحيح الأخطاء الموسّعة

الانضمام إلى المناقشة العامة

المشكلة رقم 174

إمكانات الفلترة (التقارير على مستوى الحدث والتقارير القابلة للتجميع)

ما هي التغييرات التي يتم إجراؤها، ولماذا؟

ونظرًا لدعم حالات الاستخدام المهمة في المنظومة المتكاملة للإعلانات اليوم، هناك عدد من حالات الاستخدام متاحة الآن في التقارير على مستوى الحدث والتقارير القابلة للتجميع:

  • فلترة الإحالات الناجحة: يمكنك فلترة إحالة ناجحة استنادًا إلى معلومات من جهة المصدر. بالنسبة على سبيل المثال، يمكنك اختيار بيانات مشغِّل مختلفة (بيانات الإحالات الناجحة) للنقرات على الإعلانات ومرات المشاهدة.
  • عدم تطابق تحديد المصدر: فلترة الإحالات الناجحة التي تم تحديد مصدرها بشكل خاطئ هذا هو لنوع معيّن من فلترة الإحالات الناجحة على سبيل المثال، يمكنك فلترة الإحالات الناجحة التي تتم مطابقتها مع نقرة أو عرض غير صحيحة على الإعلان بسبب نطاق الوجهة etld+1 في واجهة برمجة التطبيقات.

كيف تعمل إمكانات الفلترة؟ (للتقارير على مستوى الحدث)

يمكن حقل source_data اختياري في كائن JSON من جهة المصدر تحديد العناصر التي سيتم ويستخدمه المتصفّح لاحقًا في وقت الإحالة الناجحة لتطبيق منطق الفلترة.

  {
    source_event_id: "267630968326743374",
    destination: "https://toasters.example",
    expiry: "604800000"
    source_data: {
      conversion_subdomain: ["electronics.megastore"
                              "electronics2.megastore"],
      product: "198764",
      // Note that "source_type" will be automatically generated as one of {"navigation", "event"}
    }
  }

سيقبل الآن التسجيل المشغِّل عنوانًا اختياريًا للسمة Attribution-Reporting-Filters.

عنوان استجابة HTTP Attribution-Reporting-Filters:

{
  "conversion_subdomain": "electronics.megastore",
  "directory": "/store/electronics"
}

بدلاً من ذلك، يمكن تمديد عنوان Attribution-Reporting-Register-Event-Trigger باستخدام filters لإجراء فلترة انتقائية لضبط trigger_data استنادًا إلى source_data.

إذا تطابقت المفاتيح في الفلاتر على مفاتيح JSON مع المفاتيح في source_data، سيكون عامل التفعيل هو
. يتم تجاهله تمامًا إذا كان التقاطع فارغًا.

مزيد من المعلومات في الشرح الفني

فلاتر تحديد المصدر الاختيارية

الانضمام إلى المناقشة العامة

المشكلة رقم 194
المشكلة رقم 201

تغييرات حماية الخصوصية

التشويش والشفافية (التقارير على مستوى الحدث والتقارير القابلة للتجميع)

ما هي التغييرات التي يتم إجراؤها، ولماذا؟

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

لهذه التقنية الجديدة بعض الفوائد:

  • إنّها توحد آلية خصوصية النقرات والمشاهدات.
  • ومن الأبسط السبب في ذلك من استخدام آلية يتم من خلالها فصل بيانات المشغِّل (بيانات الإحالات الناجحة) عن التشويش الناتج عن رابط مصدر المشغِّل.
  • فهي تعمل على إعداد إطار عمل للخصوصية يمكن أن يضمن، باستخدام إعدادات التشويش الصحيحة، عدم تمكّن أي طرف من الاعتماد على واجهة برمجة التطبيقات ليعرف بشكل مؤكد أنّ مستخدمًا فرديًا أجرى إحالة ناجحة (أو لا أجرى) إحالة ناجحة لإعلان معيّن.

تحل هذه الآلية الجديدة محل الآلية السابقة حيث يتم تشغيل البيانات بنسبة 5% من الوقت (بيانات الإحالات الناجحة) تم استبداله بقيمة عشوائية.

بالإضافة إلى ذلك، تمت إضافة قيمة احتمالية الاستجابة العشوائية إلى نص التقرير (حقل واحد (randomized_trigger_rate)). يحدّد هذا الحقل احتمالية (0 إلى 1) أنّ المصدر لاستجابة عشوائية.

وهذا له فائدتان رئيسيتان:

  • يجعل سلوك المتصفّح الأساسي شفافية للجهات التي ستتلقّى التقارير (المعروفة عادةً باسم أدوات الإعلان)
  • وهو مفيد لمستقبل يتم فيه دعم واجهة برمجة التطبيقات عبر المتصفحات: قد تقرر متصفحات مختلفة تطبيق مستويات مختلفة من التشويش استنادًا إلى وأهداف الخصوصية، والأطراف التي ستعالج البلاغات بحاجة إلى الاطلاع على ذلك.

ما هي آلية عمل وظائف إخفاء هوية المستخدمين؟

بالنسبة إلى الاقتراح الجديد، عند تسجيل المصدر (أي تسجيل نقرة على إعلان أو مشاهدة له)، يجب يقرر المتصفح عشوائيًا ما إذا كان سينسب الإحالات الناجحة ويرسل تقارير عنها نقرة أو مشاهدة على إعلان، أو ما إذا كانت ستؤدي إلى نتائج زائفة بدلاً من ذلك.

يمكن أن تكون النتائج المزيفة كما يلي:

  • لا يوجد تقرير على الإطلاق - بغض النظر عما إذا كان المستخدم أجرى إحالة ناجحة أم لا
  • إبلاغ واحد أو أكثر من التقارير الزائفة: بغض النظر عمّا إذا كان المستخدم أجرى إحالة ناجحة.

ففي التقارير الزائفة، تكون بيانات العامل المفعِّل (بيانات الإحالات الناجحة) عشوائية، وهي قيمة عشوائية من 3 بت للنقرات (أي رقم بين 0 و7) وقيمة عشوائية بعدد 1 بت لمرات المشاهدة (0 أو 1).

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

هناك ثلاث فترات لإعداد تقارير النقرات (يومان أو 7 أيام أو 30 يومًا بعد النقرة). كل نموذج مزيّف يتم تعيينه عشوائيًا لإحدى فترات إعداد التقارير.

وبشكلٍ منفصل، وكما ذكر الاقتراح السابق، يتم ترتيب التقارير داخل فترة بشكلٍ عشوائي.

مزيد من المعلومات في الشرح الفني

أمثلة على الإحالات الناجحة الزائفة المزعجة

الانضمام إلى المناقشة العامة

المشكلة رقم 84
المشكلة رقم 273

قيود إعداد التقارير (التقارير على مستوى الحدث والتقارير القابلة للتجميع)

حدود مصادر إعداد التقارير

ما هي التغييرات التي يتم إجراؤها، ولماذا؟

إنّ الاقتراح الجديد يحدّ بشكل صريح من عدد الأطراف التي يمكنها قياس الأحداث بين موقعَين إلكترونيَين.

  • الحدّ الأقصى لعدد مصادر إعداد التقارير الفريدة (المعروفة عادةً باسم أدوات تكنولوجيا الإعلان) التي يمكن تسجيلها نقترح تحديد المصادر لكل {publisher, advertiser} إلى 100 لكل 30 يومًا. هذا النمط ستتم زيادة العدّاد لكل نقرة على إعلان أو مشاهدة (حدث مصدر)، حتى تلك التي لا المنسوبة.
  • الحدّ الأقصى لعدد مصادر إعداد التقارير الفريدة (عادةً تكنولوجيات الإعلان) التي يمكنها إرسال التقارير لكلّ نقترح تحديد {publisher, advertiser} بحد أقصى 10 كل 30 يومًا. سيكون هذا العدّاد كل إحالة ناجحة منسوبة

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

إعداد التقارير عن فترة توقّف الخدمة / الحدود القصوى لمعدّل الزيارات

ما هي التغييرات التي يتم إجراؤها، ولماذا؟

فترة توقُّف الإبلاغ هي آلية للخصوصية تعمل على الحد من إجمالي المعلومات التي يتم إرسالها. من خلال واجهة برمجة التطبيقات هذه في فترة زمنية معيّنة للمستخدم

في الاقتراح الجديد، 100 تقرير لكلّ {source site, destination, reporting asset} (عادةً {publisher, advertiser, adtech}) على مدار 30 يومًا.

وبعد هذا الحدّ، سيتوقف المتصفّح عن جدولة التقارير التي تطابق هذا {source site, الوجهة، مصدر إعداد التقارير} (عادةً {publisher, advertiser, adtech}) حتى نهاية 30 يومًا انخفاض عدد التقارير إلى أقل من 100 في {source site, Destination, reporting asset}.

مزيد من المعلومات في الشرح الفني

فترة توقّف إعداد التقارير / حدود المعدّل

تحديد الوجهة (التقارير على مستوى الحدث فقط)

ما هي التغييرات التي يتم إجراؤها، ولماذا؟

يتم تعديل "تحديد عدد الوجهات" لتضمين مصدر إعداد التقارير (عادةً ما يكون تكنولوجيا الإعلان) في النطاق: 100 فريد. وجهات في انتظار المراجعة (عادةً ما تكون مواقع المعلنين أو المواقع التي من المتوقع أن تحدث فيها الإحالات الناجحة مكان) مسموح بها لكل {publisher, adtech}.

تهدف هذه السياسة إلى حماية الخصوصية للحدّ من إعادة إنشاء سجلّ التصفُّح.

مزيد من المعلومات في الشرح الفني

الحدّ من عدد الوجهات الفريدة التي تغطيها المصادر في انتظار المراجعة

جميع الموارد

صورة العنوان مأخوذة من قناة Diana Polekhina على Unسباش.