تعديلات على اقتراحات إعداد تقارير الإحالة في كانون الثاني (يناير) 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. عند تلقّي هذا الطلب، يجب أن يستجيب خادم تتبّع النقرات/المشاهدات باستخدام عنوان HTTP، Attribution-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)
    }]

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

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

إنّ إعادة التوجيه اختيارية، وهي غير مطلوبة عندما تتوفّر وحدة بكسل في الصفحة لكل من تكنولوجيا الإعلان والجهة الخارجية.

يمكنك الاطّلاع على مزيد من التفاصيل في تقارير الطرف الثالث.

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

بدء تحديد المصدر

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

المشكلة رقم 91

ما مِن وظيفة مصغَّرة (تقارير قابلة للتجميع)

ما الذي يتم تغييره ولماذا؟

في الاقتراح السابق للتقارير القابلة للتجميع، كان يجب الوصول إلى JavaScript لاستدعاء وظيفة مصغَّرة، وهي آلية مستندة إلى 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) أن يخضع المصدر لاستجابة عشوائية.

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

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

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

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

يمكن أن يكون الناتج الزائف على النحو التالي:

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

وفي التقارير الزائفة، تكون بيانات العامل المشغِّل (بيانات الإحالات الناجحة) عشوائية، أي قيمة عشوائية من 3 بت للنقرات (أي رقم بين 0 و7) وقيمة 1 بت عشوائية لمرات العرض (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 على منصة Unسبلاش.