إعداد تقارير الإحالة: القياس على جميع التطبيقات والويب

أجدد التحديثات

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

كما هو موضّح في اقتراح تصميم Attribution Reporting API، تتيح واجهة برمجة التطبيقات تحديد مصدر الإحالة لمسارات المشغّلات التالية على جهاز واحد يعمل بنظام التشغيل Android. نعرّف الويب هنا على أنّه إما (1) متصفّح مستقل يعمل على Android (مثل Chrome) أو (2) WebView يعمل داخل تطبيق Android.

  • App-to-app: يرى المستخدم إعلانًا في تطبيق، ثم يُجري إحالة ناجحة في هذا التطبيق أو في تطبيق آخر مثبَّت.
  • App-to-web: يرى المستخدم إعلانًا في تطبيق، ثم يُجري إحالة ناجحة على الويب.
  • Web-to-app: يرى المستخدِم إعلانًا على الويب، ثم يُجري إحالة ناجحة في تطبيق.
  • Web-to-web: يرى المستخدِم إعلانًا على الويب، ثمّ يُجري إحالة ناجحة على الويب.

تؤدي مسارات المشغّلات السابقة إلى المتطلبات التالية:

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

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

الوصول إلى واجهات برمجة التطبيقات Attribution Reporting API

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

بعد الانتهاء من عملية التسجيل، ستتجاهل واجهة برمجة التطبيقات عملية التسجيل إذا تم تلقّي طلب تسجيل غير مسجّل.

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

التغييرات المتعلّقة بتكنولوجيات الإعلان

يتناول هذا القسم التغييرات التي ستطرأ على تكنولوجيات الإعلان التي تستخدم Attribution Reporting API.

التغييرات على التسجيل وتحديد المصدر

عند تسجيل مصدر تحديد المصدر، تحدّد تكنولوجيات الإعلان حقل الوجهة وهو اسم حزمة التطبيق الذي يقع فيه حدث التشغيل. لتفعيل ميزة القياس بين التطبيقات والويب، نخطّط لتوفير حقل واحد لوجهة التطبيق (اسم حزمة التطبيق) وحقل واحد لوجهة الويب (eTLD+1).

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

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

تلقّي تقارير التطبيقات والمواقع الإلكترونية

يمكن لواجهة برمجة التطبيقات Attribution Reporting API على Android إرسال تقارير عن الإحالات الناجحة على التطبيقات والمواقع الإلكترونية. إذا كانت تكنولوجيات الإعلان لا تريد مطابقة بيانات المشغّلات وقيم مفاتيح التجميع على مستوى مساحات العرض على الويب والتطبيقات، يمكنها التمييز بين إحالة ناجحة على الويب وإحالة ناجحة على التطبيق باتّباع الخطوات التالية:

تأثيرات القياس من موقع إلكتروني إلى آخر

تختار التطبيقات وقت إرسال بيانات التسجيل إلى Attribution Reporting API. هناك عدة اعتبارات يجب أخذها في الحسبان:

  • هل تتوفّر واجهة برمجة التطبيقات Attribution Reporting API على هذا الجهاز؟ سنعرض إشارة جديدة للتطبيقات توضّح ما إذا كانت واجهة برمجة التطبيقات Attribution Reporting API متاحة على هذا الجهاز. يمكنك الاطّلاع على قسم تغييرات التطبيق لمعرفة المزيد من التفاصيل حول كيفية إرسال التطبيقات لبيانات التسجيل إلى Attribution Reporting API.
  • ما هي نسبة مصادر تحديد المصدر وعوامل التشغيل التي يجب تمريرها إلى واجهة برمجة التطبيقات؟ سيكون هذا القرار من مسؤولية كل تطبيق أو تكنولوجيا الإعلان إذا كان التطبيق يسمح بالاختيار. إذا كان التطبيق يتضمّن حلّ قياس خاصًا به، قد يكون من الأفضل استخدامه بدلاً من ذلك. في النهاية، يتيح تمرير جميع عمليات تسجيل المصدر والمشغّل إلى واجهة برمجة التطبيقات Attribution Reporting API على Android، عند توفّرها، تحديد المصدر الأكثر دقة على مستوى التطبيق والموقع الإلكتروني.

يوضّح المثال التالي كيف يمكن لتطبيقات المتصفّح أن تعمل مع واجهة برمجة التطبيقات Attribution Reporting لتوفير قياس دقيق عندما ينقر المستخدم على إعلان في كلّ من تطبيق متصفّح وتطبيق غير متصفّح:

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

تسجيل مصدر الإحالة ومشغّلها من WebView

في حال كان التطبيق يستخدم WebView لعرض محتوى الويب بدلاً من إعلان على Android، يمكن للتطبيق تقديم طلب للانضمام إلى القائمة المسموح بها registerWebSource() وتقديم المصدر ذي المستوى الأعلى للموقع الإلكتروني الذي سيتم ربطه بمصدر تحديد المصدر بدلاً من اسم حزمة التطبيق.

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

على عكس المتصفّحات، لا يتيح WebView التسجيل باستخدام نظام التشغيل إلا ضمن العنوان Attribution-Reporting-Eligible في حال توفُّر واجهة برمجة التطبيقات Attribution Reporting من Android. في حال عدم توفّر واجهة برمجة التطبيقات Attribution Reporting API على Android، لن يضبط WebView عنوان Attribution-Reporting-Eligible ولن يتم إجراء أي عمليات تسجيل.

لتسجيل مصدر / مشغّل تحديد المصدر باستخدام نظام التشغيل، اتّبِع الخطوات التالية:

  • على تكنولوجيات الإعلان الاستجابة لعمليات تسجيل المصادر باستخدام العنوان Attribution-Reporting-Register-OS-Source، ما يؤدي إلى بدء طلب ثانٍ من واجهة برمجة التطبيقات من WebView إلى registerSource() أو registerWebSource().
  • يمكن أيضًا أن تستجيب تكنولوجيات الإعلان لعمليات تسجيل المشغّلات باستخدام العنوان Attribution-Reporting-Register-OS-Trigger، ما يؤدي إلى بدء طلب ثانٍ من واجهة برمجة التطبيقات من WebView إلى registerWebTrigger() أو registerTrigger().

يُرجى العِلم أنّه إذا لم تتضمّن الاستجابة العناوين السابقة، أو إذا كانت تتضمّن أيضًا العناوين Attribution-Reporting-Register-Source / Attribution-Reporting-Register-Trigger على الرغم من عدم توفّر الويب، ستفشل عملية التسجيل بالكامل.

للحصول على تفاصيل حول ما إذا كان WebView سيستخدم registerSource() / registerWebSource() وregisterTrigger() / registerWebTrigger() (بالإضافة إلى كيفية تغيير هذا السلوك)، يُرجى الرجوع إلى مصدر تحديد المصدر وتسجيل مشغّل تحديد المصدر من WebView.

تقارير تصحيح الأخطاء المؤقتة

تتيح Attribution Reporting API ميزة اختيارية تُعرف باسم تقارير تصحيح الأخطاء المؤقتة، ما يسمح لمزوّدي تكنولوجيا الإعلان بالحصول على مزيد من المعلومات حول تقارير تحديد المصدر عند توفّر معرّف إعلاني. يتوفّر نوعان من تقارير تصحيح الأخطاء: attribution-success وverbose. تتوفّر هذه التقارير للإحالة على جميع التطبيقات والمواقع الإلكترونية، ويحتوي كلا نوعَي التقارير على المعلومات نفسها، ويكمن الاختلاف الوحيد في الأذونات التي تحدّد وقت إرسال تقارير تصحيح الأخطاء.

بالنسبة إلى تحديد المصدر من الويب إلى الويب الذي يحدث داخل تطبيق واحد (على سبيل المثال، داخل تطبيق المتصفّح نفسه)، لا تتوفّر تقارير تحديد المصدر الناجح والتقارير التفصيلية إلا عندما تتوفّر ملفات تعريف الارتباط التابعة لجهات خارجية، ولا تستند إلى توفّر المعرّف الإعلاني.

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

في مثال لاحق على الانتقال من التطبيق إلى الويب، يحدث المصدر في تطبيق ناشر، ولكن يحدث المشغّل على موقع إلكتروني خاص بالمعلِن داخل تطبيق متصفّح.

لتفعيل تقرير تصحيح الأخطاء الخاص بنجاح تحديد المصدر في ميزة "التطبيق إلى الويب"، يجب استيفاء الشروط التالية:

  • يجب ألا يكون المستخدم قد أوقف ميزة التخصيص باستخدام المعرِّف الإعلاني
  • يجب أن يكون تطبيق الناشر قد أعلن عن أذونات المعرّف الإعلاني
  • يجب أن تمرِّر تكنولوجيا الإعلان قيمة AdID في عملية تسجيل المشغّل (من سياق الويب).

لتفعيل تقارير تصحيح الأخطاء التفصيلية لميزة "التطبيق على الويب"، اتّبِع الخطوات التالية:

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

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

التغييرات على التطبيقات

سنوفّر إمكانية تحديد المصدر على مستوى التطبيقات والمواقع الإلكترونية من خلال السماح للتطبيقات بنقل تسجيل مصادر تحديد المصدر على الويب ومشغّلات الويب إلى Attribution Reporting API على Android باستخدام مجموعة جديدة من طلبات البيانات من واجهة برمجة التطبيقات الخاصة بسياق الويب.

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

يمكنك الاطّلاع على اقتراح "مبادرة حماية الخصوصية على الويب" للحصول على مثال حول كيفية دمج المتصفّحات مع Attribution Reporting API على Android من أجل تفعيل قياس الأداء على مستوى التطبيقات والويب. في الاقتراح، سيضيف المتصفّح عناوين الطلبات التالية:

  • Attribution-Reporting-Eligible تبث ما إذا كان الدعم على مستوى نظام التشغيل لتحديد المصدر متاحًا. في هذه الحالة، يشير العنوان إلى ما إذا كانت واجهة برمجة التطبيقات Attribution Reporting على Android متاحة.
  • إذا كان ذلك متاحًا، يمكن لتكنولوجيات الإعلان الردّ بشكل اختياري باستخدام Attribution-Reporting-Register-OS-Source، ما يؤدي إلى بدء طلب ثانوي من واجهة برمجة التطبيقات من تطبيق المتصفّح إلى registerWebSource().
  • يمكن لتكنولوجيات الإعلان أيضًا الاستجابة لعمليات تسجيل المشغّلات باستخدام العنوان Attribution-Reporting-Register-OS-Trigger، ما يؤدي إلى بدء طلب ثانٍ من واجهة برمجة التطبيقات من تطبيق المتصفّح إلى registerWebTrigger().

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

عند تسجيل مصدر تحديد المصدر، يمكن للتطبيقات استدعاء registerWebSource()، الذي يتوقّع المَعلمات التالية:

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

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

عندما ترسل واجهة برمجة التطبيقات طلبًا إلى معرّف الموارد المنتظم (URI) لمصدر تحديد المصدر، يجب أن تردّ تكنولوجيا الإعلان ببيانات مصدر تحديد المصدر الوصفية في عنوان HTTP، Attribution-Reporting-Register-Source. يستخدم هذا العنوان الحقول نفسها المستخدَمة في تسجيل مصدر تحديد المصدر من تطبيق إلى تطبيق، مع إجراء بعض التغييرات:

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

    من المتوقّع أن تتحقّق التطبيقات من صحة عناوين URL على الويب قبل استدعاء واجهة برمجة التطبيقات الخاصة بسياق الويب. بالنسبة إلى النقرات، يجب أن تتأكّد التطبيقات من أنّ الوجهة المحدّدة تتطابق مع الوجهة التي ينتقل إليها المستخدم.
  • تتجاهل واجهة برمجة التطبيقات أي عناوين URI لإعادة التوجيه يتم تقديمها في Attribution-Reporting-Redirects. يجب أن تتبع التطبيقات عمليات إعادة التوجيه من تلقاء نفسها وأن تستدعي registerWebSource() لكل عملية إعادة توجيه، حتى تتمكّن من تطبيق سياسات الأذونات الخاصة بها حسب الحاجة.

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

تسجيل حدث مشغِّل (إحالة ناجحة)

عند تسجيل المشغِّل، يمكن للتطبيقات استدعاء registerWebTrigger()، الذي يتوقّع المعلمات التالية:

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

تسجيل مصدر الإحالة وعامل التشغيل من WebView

سيستخدم WebView تلقائيًا registerSource() وregisterWebTrigger(). يربط ذلك المصادر بالتطبيق ويؤدي إلى تشغيلها باستخدام المصدر ذي المستوى الأعلى لـ WebView عند حدوث عملية التشغيل.

إذا كان التطبيق يتطلّب سلوكًا مختلفًا (مثل التطبيقات التي تستضيف محتوى الويب في WebView)، عليه استخدام طريقة setAttributionRegistrationBehavior في فئة androidx.webkit.WebViewSettingsCompat. ستحدّد هذه الطريقة ما إذا كان على WebView استدعاء registerWebSource() أو registerSource() وregisterWebTrigger() أو registerTrigger().

في ما يلي الخيارات المتاحة لـ setAttributionRegistrationBehavior:

القيمة الوصف مثال على حالة الاستخدام
APP_SOURCE_AND_WEB_TRIGGER (الإعداد التلقائي) تسمح للتطبيقات بتسجيل مصادر التطبيقات (المصادر المرتبطة باسم حزمة التطبيق) وعوامل تشغيل الويب (عوامل التشغيل المرتبطة بـ eTLD+1) من WebView. التطبيقات التي تستخدم WebView لعرض الإعلانات بدلاً من إتاحة تصفُّح الويب
WEB_SOURCE_AND_WEB_TRIGGER يسمح للتطبيقات بتسجيل مصادر الويب ومشغّلات الويب من WebView.
ملاحظة: على التطبيقات التي تستخدم هذا الخيار تقديم طلب للانضمام إلى قائمة السماح من أجل استخدام registerWebSource().		 تطبيقات المتصفّحات المستندة إلى WebView، حيث يمكن أن تحدث مرات ظهور الإعلانات والإحالات الناجحة على المواقع الإلكترونية في WebView.
APP_SOURCE_AND_APP_TRIGGER تتيح هذه الإذن للتطبيقات تسجيل مصادر التطبيقات ومشغّلات التطبيقات من WebView. التطبيقات المستندة إلى WebView والتي يجب أن تكون مرات ظهور الإعلانات والإحالات الناجحة مرتبطة دائمًا بالتطبيق بدلاً من eTLD+1 الخاص بـ WebView
غير مفعّلة يؤدي هذا الخيار إلى إيقاف تسجيل المصدر والمشغّل من WebView.
يُرجى العِلم أنّه قد يظلّ يتم إجراء طلب الشبكة الأوّلي إلى معرّفات الموارد الموحّدة الخاصة بمصدر تحديد المصدر أو المشغّل، ولكن سيتم تجاهل أي ردّ ولن يتم تخزين أي بيانات على الجهاز.

اعتبارات الخصوصية والأمان

يناقش هذا القسم اعتبارات الخصوصية والأمان للتطبيقات التي تستخدم واجهة برمجة التطبيقات Attribution Reporting API.

التأثير في آليات الحفاظ على الخصوصية المطبَّقة على التقارير

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

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

بناء الثقة في سياق الويب

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

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

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

يمكن لأي تطبيق استدعاء registerWebTrigger() لأنّ اعتبارات الخصوصية والأمان في جهة المشغّل لا تنطبق بدون تواطؤ من جهة المصدر.

عناصر تحكم المستخدم

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

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

اعتبارات مستقبلية وأسئلة مفتوحة

لا يزال العمل جارٍ على إتاحة إمكانية التشغيل التفاعلي بين التطبيق والويب لواجهة برمجة التطبيقات Attribution Reporting API. نريد الحصول على ملاحظات من المنتدى حول بعض الأفكار:

  1. على جهاز متوافق مع "مبادرة حماية الخصوصية" على Android، كيف ستستخدم حلول قياس المتصفّح مع Attribution Reporting API على Android؟ هل تفضّل نقل كل شيء إلى Android؟
  2. هل هناك أي مخاوف بشأن احتمال تلقّي إشارتَي ping لكل مصدر إحالة وزناد، إحداهما من المتصفّح أو التطبيق والأخرى من Attribution Reporting API؟
  3. كيف يمكننا تسهيل عملية تصحيح الأخطاء في واجهات برمجة التطبيقات المختلفة؟
  4. لا يتضمّن الاقتراح التحقّق من أنّ وجهات التطبيق والويب مرتبطة ببعضها. في المستقبل، قد نتمكّن من التحقّق من صحة هذه الوجهات من خلال التحقّق من عمليات الربط باستخدام روابط مواد العرض الرقمية. هل سيؤدي ذلك إلى حظر أي من حالات الاستخدام؟ هل من المنطقي استخدام روابط تنقل إلى مواد عرض رقمية لإجراء عملية التحقّق هذه؟
  5. عند تسجيل مصدر تحديد المصدر، يجب تحديد وجهة. في حالة الانتقال من الويب إلى التطبيق، قد تحتاج إلى تحديد رابط تطبيق. ما هي التنسيقات التي تستخدمها لتحديد رابط التطبيق هذا؟
  6. عند تسجيل مصدر تحديد المصدر من التطبيق إلى الموقع الإلكتروني، يجب تسجيل حدث المصدر من التطبيق باستخدام واجهة برمجة التطبيقات Android Attribution Reporting API. على سبيل المثال، إذا نقر المستخدم على إعلان وتم فتح النقرة في متصفّح أو علامة تبويب مخصّصة في المتصفّح، يجب تسجيل هذه النقرة (الحدث المصدر) من التطبيق وليس في سياق المتصفّح. يُرجى التواصل معنا إذا كانت لديك أي مخاوف بشأن ذلك، أو إذا كانت هناك حالات استخدام أخرى لا تندرج ضمن الفئات الموضّحة في المشكلة التي تصف مسارات العمل المتوافقة.