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

ملاحظة: يعكس هذا المستند اقتراحات التصميم الحالية لـ "مبادرة حماية الخصوصية" على Android وهو يخضع لمزيد من التغيير. ونحن نشجّعك على استخدام ملاحظاتك وتعليقاتك للمساعدة في هذه الجهود.

تقديم ملاحظات

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

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

كما هو موضّح في اقتراح تصميم 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 لتسجيل الخادم.

تغييرات لتكنولوجيا الإعلانات

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

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

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

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

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

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

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

آثار القياس من الويب إلى الويب

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

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

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

مثال على التسجيل المصدر وعوامل التسجيل عبر متصفّح وتطبيق

• في اليوم الأول، ينقر المستخدم على إعلان في تطبيق المتصفّح.
  • يمكن لتطبيق المتصفّح اختيار استخدام حل القياس الخاص به أو تمرير تسجيل نقرة الإعلان على الويب إلى 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، لا يتم ضبط عنوان Attribution-Reporting-Eligible في WebView، وبالتالي لا يتم إجراء أي عمليات تسجيل.

لتسجيل مصدر / مشغّل تحديد مصدر باستخدام نظام التشغيل:

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

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

بالنسبة إلى الإحالات الناجحة من تطبيق إلى ويب ومن الويب إلى التطبيق ومن الويب إلى الويب إلى المواقع الإلكترونية على مستوى التطبيقات، تتوفّر تقارير نجاح الإحالة والتقارير المطوَّلة في حال توفّر 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-Trigger، الذي يؤدي إلى بدء طلب ثانوي من واجهة برمجة التطبيقات من تطبيق المتصفّح إلى registerWebTrigger().

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

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

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

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

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

ملاحظة: ينطبق setAttributionRegistrationBehavior على كل تنفيذ من تنفيذ WebView لكل تطبيق. وإذا كان تطبيقك يتيح استخدام العديد من مكوّنات WebView، يمكنك ضبط سلوكيات مختلفة لكل منها. لا يمنع setAttributionRegistrationBehavior أو يغيِّر ميزة المصدر أو التسجيل من التطبيق نفسه أو من أي تطبيق آخر.

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

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

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

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

بناء الثقة لاستخدام سياق الويب

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

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

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

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

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

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

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

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

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

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