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

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

كما هو موضّح في اقتراح تصميم Attribution Reporting API، تتيح واجهة برمجة التطبيقات تحديد مصدر مسارات التفعيل التالية على جهاز واحد يعمل بنظام 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 API لتقديم قياس دقيق عندما ينقر المستخدِم على إعلان في كلّ من تطبيق متصفّح وتطبيق غير متصفّح:

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

تسجيل مصدر تحديد المصدر وعامل التفعيل من WebView

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

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

على عكس المتصفّحات، لا يتيح WebView التسجيل باستخدام نظام التشغيل ضمن عنوان Attribution-Reporting-Eligible إلا إذا كانت واجهة برمجة التطبيقات Attribution Reporting API لنظام التشغيل Android متوفرة. إذا لم تكن واجهة برمجة التطبيقات Attribution Reporting API لنظام التشغيل Android متاحة، لن تضبط WebViewAttribution-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 متاحًا على جانب التطبيق ويمكن لتكنولوجيا الإعلان ضبط رقم تعريف AdID نفسه (الصحيح) على جانب الويب.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    من المتوقّع أن تتحقّق التطبيقات من وجهات الويب قبل طلب بيانات واجهة برمجة التطبيقات web context API. بالنسبة إلى النقرات، يجب أن تتحقّق التطبيقات من أنّ الوجهة المحدّدة تطابق الوجهة التي ينتقل إليها المستخدم.
  • تتجاهل واجهة برمجة التطبيقات أيّ معرّفات موارد منتظمة لإعادة التوجيه مقدّمة في 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.
يُرجى العِلم أنّه قد يستمر طلب البيانات الأولي من الشبكة إلى عناوين URL لمصدر تحديد المصدر أو مشغِّل الإجراء، ولكن يتم تجاهل أي استجابة ولن يتم تخزين أي بيانات على الجهاز.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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