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

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

مَن هو الجمهور المعنيّ بهذا المنشور؟

ننصحك بالاطّلاع على هذه المشاركة:

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

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

عملية نقل البيانات القادمة

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

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

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

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

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

التقارير التلخيصية هي النتيجة النهائية لتجميع تقارير قابلة للتجميع متعددة، ويُشار إليها سابقًا باسم "المساهمات" أو "مساهمات الرسم البياني الشريطي".

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

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

ما هي التغييرات التي سيتم إجراؤها؟

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

يتم تغيير طريقة ضبط هذه المَعلمات.

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

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

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

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

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

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

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

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

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

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

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

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

المشكلة رقم 261

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

ما هي التغييرات التي سيتم إجراؤها؟

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

بالإضافة إلى ذلك، في الاقتراح الجديد، يجب استخدام سمة 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.

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

  • تنفيذ المهام في المتصفّح: على عكس تصميم "مهام Google"، يكون التصميم الجديد أكثر بساطة لأنّه لا يتطلّب بيئة تنفيذ جديدة في المتصفّحات.
  • تجربة المطوّر: يعتمد التصميم الجديد على الرؤوس التي يستخدمها المطوّرون بشكل شائع ويعرفونها على نطاق واسع، على عكس وحدات العمل. وتتطابق أيضًا بشكل وثيق مع واجهة برمجة التطبيقات لأجل تسجيل المصدر، ما يسهّل تعلم واجهة برمجة التطبيقات واستخدامها.
  • التوافق: يتيح التصميم الجديد لعدد أكبر من أنظمة القياس الحالية استخدام تقارير قابلة للتجميع. تعتمد العديد من حلول القياس على بروتوكول 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 cookie في ملف تعريف ملفات تعريف الارتباط لمصدر إعداد التقارير في وقت تسجيل المصدر والعامل المشغِّل، سيتم إرسال تقرير تصحيح أخطاء (بتنسيق 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) وقيمة عشوائية من بت واحد للمشاهدات (0 أو 1).

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

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

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

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

أمثلة على الإحالات الناجحة المزيفة غير الصالحة

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

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

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

حدود مصادر الإبلاغ

ما هي التغييرات التي سيتم إجراؤها؟

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

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

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

حدود معدّل الإبلاغ / فترة الاستراحة

ما هي التغييرات التي سيتم إجراؤها؟

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

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

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

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

فترة الانتظار قبل الإبلاغ عن المخالفات / حدود معدّل الإبلاغ

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

ما هي التغييرات التي سيتم إجراؤها؟

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

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

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

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

جميع الموارد

صورة العنوان من Diana Polekhina على Unsplash.