تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

دليل التنفيذ على مستوى المواقع الإلكترونية والتطبيقات في Attribution Reporting API

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

سيعلمك هذا الدليل كيفية إعداد الإحالة على مستوى التطبيقات والمواقع الإلكترونية.

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

تسجيل المصادر وعوامل التشغيل باستخدام نظام التشغيل Android

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

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

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

تسجيل مصدر تطبيق ومشغّل الويب

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

مثال

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

تسجيل مصدر التطبيق:

تُسجِّل حزمة تطوير البرامج (SDK) الخاصة بتكنولوجيا الإعلان في تطبيق Daily News Android النقرة باستخدام registerSource()
تُرسِل Attribution Reporting API على نظام التشغيل Android طلبًا إلى خادم تكنولوجيا الإعلان. تم تقديم عنوان URL إلى "registerSource()".
يستجيب خادم تكنولوجيا الإعلان باستخدام Attribution-Reporting-Register-Source لإكمال تسجيل المصدر

تسجيل مشغِّل الويب:

تسجِّل تكنولوجيا الإعلان عاملاً مشغِّلاً وتتحقّق من توفُّر نظام التشغيل في Attribution Reporting API
تعرض ARA على الويب معلومات حول النظام الأساسي المتوافق
يطلب عنوان OS-Trigger لواجهة برمجة تطبيقات ARA على الويب استدعاء واجهة برمجة التطبيقات OS ARA. دالة registerWebTrigger()
يتم الاتصال بـ "registerWebTrigger()" بشكل خفيف، ويتولّى مطوّر البرامج. لا يحتاج إلى الاتصال بـ registerWebTrigger() من خلال نظام التشغيل مباشرةً
تتولى ARA لنظام التشغيل إدارة الطلبات وإرسال طلب إلى عنوان URL لخادم تكنولوجيا الإعلان الذي يوفّره الرأس Attribution-Reporting-Register-OS-Trigger
ستكمل تقنية الإعلان عملية التسجيل من خلال واجهة برمجة التطبيقات OS API
سيُنفِّذ ARA نظام التشغيل الإحالة وفقًا للمنطق نفسه المطبق على إحالة التطبيق <> وإرسال التقارير نفسها

سير العمل

تتضمن الخطوات التالية مزيدًا من التفاصيل حول كيفية إكمال المهمة:

تسجِّل تقنية الإعلان من التطبيق مصدرًا باستخدام إحالة Android Reporting API مع التعديلات التالية:
- لتسجيل مصدر تطبيق من المتوقّع أن يُجري إحالة ناجحة على موقع إلكتروني، يجب يجب أن يشتمل عنوان الاستجابة Attribution-Reporting-Register-Source على عنوان ويب. الوجهة (eTLD+1) بدلاً من وجهة التطبيق.
```
Attribution-Reporting-Register-Source: {
    "web_destination": "https://advertiser.example",
    ...
}
```
ملاحظة: بالنسبة إلى الحملات التي قد تؤدي إلى إحالات ناجحة في موقعَين إلكترونيَّين أو وجهة تطبيق، اطّلِع على القسم الذي يتناول الوجهات المزدوجة
.
- قد يستخدِم بعض المعلِنين العديد من مقدّمي خدمات القياس (على سبيل المثال أداة قياس تابعة لجهة خارجية أو أداة إحصاءات) باستخدام سلاسل إعادة التوجيه 302. في بعض الحالات، ستتّبع Attribution Reporting API مسار إعادة التوجيه المحدد في العنوان Attribution-Reporting-Redirect في الخلفية وفي الوقت نفسه الذي يتم فيه تنفيذ مسار إعادة التوجيه 302 في المقدّمة للروابط طلبات التنقل. وستنتقل هذه الطلبات إلى عنوان URL نفسه وقد ينتج عنها في مزود خدمة القياس التابع لجهة خارجية، العدّ المزدوج لعمليات التسجيل. إلى منع الاحتساب المزدوج لعمليات التسجيل، يمكن لتقنيات الإعلان تعديل سلوك إعادة التوجيه إرسال تسجيل Attribution Reporting API إلى نطاق بديل حتى الآن عنوان URL محدد.
- لتفعيل هذا السلوك، يجب أن تضمّ تقنيات الإعلان عنوان HTTP جديدًا عندما الاستجابة لطلب التسجيل:
  - العنوان هو Attribution-Reporting-Redirect-Config.
  - يجب أن تكون قيمة العنوانredirect-302-to-well-known.
```
"Attribution-Reporting-Redirect-Config": "redirect-302-to-well-known"
```
  ملاحظة: جميع عمليات إعادة التوجيه اللاحقة التي تلي هذا العنوان ستتم إلحاق .well-known ببداية مسار عنوان URL لإعادة التوجيه.
- باقي عملية تسجيل المصدر هي نفسها إجراء القياس التسجيل المصدر من تطبيق إلى تطبيق
ملاحظة: في حال استخدام webview أنت أو تطبيق النشر لعرض إعلان مدمج مع المحتوى في تطبيق Android، ارجع إلى القسم الذي يتناول WebView
تسجِّل تقنية الإعلان على موقع المعلن الإلكتروني المشغل عن طريق طرح في ما يلي كيفية تفويض التسجيل في واجهة برمجة التطبيقات Android Attribution Reporting API:
- بعد أن يُكمل المستخدم إحالة ناجحة على موقع إلكتروني، ستُجري تقنية الإعلان طلب تسجيل المشغّل في Chrome
  1. يمكن استخدام طلب بكسل أو fetch() لتقديم طلب تسجيل تشغيل
  2. يعرض Chrome عنوان طلب "Attribution-Reporting-Support" بتكنولوجيا الإعلان في حالة تمكين واجهة برمجة التطبيقات على كل من متصفح Chrome جهاز Android، سيعرض الرأس os, web
```
"Attribution-Reporting-Support": "os, web"
```
- بعد ذلك، يجب أن تطلب تقنية الإعلان من Chrome تفويض نظام التشغيل باستخدام Attribution-Reporting-Register-OS-Trigger الذي:
  1. طلب من Chrome تفويض التسجيل إلى نظام التشغيل
  2. يفوّض Chrome التسجيل إلى نظام التشغيل من خلال استدعاء وظيفة واجهة برمجة تطبيقات نظام التشغيل registerWebTrigger()
    - يتم الاتصال بـ registerWebTrigger() بشكل غير مرئي، تقنية الإعلان لا يحتاج إلى الاتصال بـ registerWebTrigger() مباشرةً
  3. تبدأ واجهة برمجة التطبيقات لنظام التشغيل طلب البيانات من واجهة برمجة التطبيقات الثانوية إلى معرّف الموارد المنتظم (URI) لتكنولوجيا الإعلان الذي تم تمريره من المتصفِّح
```
"Attribution-Reporting-Register-OS-Trigger": "https://adtech.example/register-trigger",
"https://other-adtech.example/register-trigger"
```
- في بعض الحالات، لا يكون العنوان Attribution-Reporting-Support متاحًا لا يمكن إرسالها. وعند حدوث ذلك، يظل بإمكان تقنية الإعلان تحديد للتعامل مع تسجيل المشغل من خلال تضمين عنوان Attribution-Reporting-Info المفتاح هو النظام الأساسي المفضل القيمتان المسموح بإدراجهما هما os وweb. سيستخدم المتصفّح النظام الأساسي المفضّل عند توفره وستعود إلى استخدام نظام الويب عندما يكون نظام التشغيل غير متاح.
ملاحظة: يتوفر كل من Attribution-Reporting-Register-Trigger الذي يحتوي على معلومات تسجيل الويب عنوان Attribution-Reporting-Register-OS-Trigger يتضمّن تسجيل نظام التشغيل عند تحديد منصة مفضّلة لضمان عرض تسجيل المنصة. يجب أن تكون عمليات تسجيل كل من نظام التشغيل والويب لأنّه في حال عدم توفّر المنصة المفضّلة، مطلوبة للطريقة الاحتياطية.
```
Attribution-Reporting-Info: preferred-platform=os
```
- لإكمال تسجيل المشغِّل، يجب أن تستجيب نقطة نهاية تكنولوجيا الإعلان لطلب واجهة برمجة التطبيقات Android Attribution Reporting API باستخدام عنوان الاستجابة
```
Attribution-Reporting-Register-Trigger {
    "event_trigger_data": [{"trigger_data":"1"}],
    "aggregatable_trigger_data": [
        {"key_piece":"0x400","source_keys":["campaignCounts"]},
        {"key_piece":"0xA80","source_keys":["geoValue"]}
    ],
    ...
}
```
- يبقى باقي تسجيل المشغّل كما هو.

تسجيل مصدر ويب ومشغّل تطبيق

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

مثال

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

تسجيل مصادر الويب:

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

تسجيل مشغِّل التطبيق:

تسجِّل حزمة تطوير البرامج (SDK) لتكنولوجيا الإعلان في تطبيق Android Clothing Store المشغِّل باستخدام نظام التشغيل ARA
تُرسِل Attribution Reporting API على نظام التشغيل Android طلبًا إلى خادم تكنولوجيا الإعلان. تم تقديم عنوان URL إلى "registerTrigger()".
يستجيب خادم تكنولوجيا الإعلان باستخدام Attribution-Reporting-Register-Trigger لإكمال عملية تسجيل المشغِّل
سيُنفِّذ ARA نظام التشغيل الإحالة وفقًا للمنطق نفسه المطبق على إحالة التطبيق <> وإرسال التقارير نفسها

سير العمل

تتضمن الخطوات التالية مزيدًا من التفاصيل حول كيفية إكمال المهمة:

تسجِّل تقنية الإعلان على الموقع الإلكتروني للناشر المصدر من خلال إرشاد في ما يلي كيفية تفويض التسجيل في واجهة برمجة التطبيقات Android Attribution Reporting API:
- بالنسبة إلى حالة الاستخدام من الويب إلى التطبيق، عند تسجيل مصدر، يتم تحديد المصدر يجب تحديد المعلمة source مباشرةً، إما باستخدام السمة علامة attributionsrc أو باستخدام تسجيل JavaScript
- يستخدم المثال التالي العلامة attributionsrc لتحديد مَعلمة source:
```
<img src="https://adtech.example/conversionpixel"
attributionsrc="https://adtech.example/register-source?purchase=12">
```
يعرض Chrome عنوان طلب Attribution-Reporting-Support إلى تكنولوجيا الإعلان إذا كانت واجهة برمجة التطبيقات مُفعّلة على كل من متصفح Chrome وجهاز Android، سيرجع العنوان os, web.
```
"Attribution-Reporting-Support": "os, web"
```
ملاحظة: يجب تفعيل Attribution Reporting API. على نظام التشغيل Android لقياس الأداء بنجاح على مستوى التطبيق والويب.
يجب أن تطلب تقنية الإعلان من Chrome التفويض إلى واجهة برمجة التطبيقات على مستوى نظام التشغيل باستخدام Attribution-Reporting-Register-OS-Source الذي:
1. طلب من Chrome تفويض التسجيل إلى نظام التشغيل
2. يفوّض Chrome التسجيل إلى نظام التشغيل من خلال استدعاء وظيفة واجهة برمجة تطبيقات نظام التشغيل registerWebSource()
3. تتم المكالمة إلى registerWebSource() بشكل خفيف، كما أن تقنية الإعلان لا لست بحاجة إلى الاتصال بـ registerWebSource() مباشرةً
4. تبدأ واجهة برمجة التطبيقات لنظام التشغيل طلب البيانات من واجهة برمجة التطبيقات الثانوية إلى معرّف الموارد المنتظم (URI) لتكنولوجيا الإعلان الذي تم تمريره من المتصفّح
```
"Attribution-Reporting-Register-OS-Source": "https://adtech.example/register-source"
```
- في بعض الحالات، لا يكون العنوان Attribution-Reporting-Support متاحًا. عند حدوث ذلك، يبقى بإمكان تكنولوجيا الإعلان إعداد منصّة مفضّلة للتعامل معها تسجيل المصدر من خلال تضمين العنوان Attribution-Reporting-Info. المفتاح هو النظام الأساسي المفضَّل والقيم المسموح بها هي os وweb. تشير رسالة الأشكال البيانية النظام الأساسي المفضّل عند توفّره وسيعود إلى منصة الويب عندما يكون نظام التشغيل غير متاح.
ملاحظة: يتوفر كل من Attribution-Reporting-Register-Source الذي يحتوي على معلومات تسجيل الويب عنوان Attribution-Reporting-Register-OS-Source يتضمّن تسجيل نظام التشغيل عند تحديد منصة مفضّلة لضمان عرض تسجيل المنصة. يجب أن تكون عمليات تسجيل كل من نظام التشغيل والويب لأنّه في حال عدم توفّر المنصة المفضّلة، مطلوبة للطريقة الاحتياطية.
```
Attribution-Reporting-Info: preferred-platform=os
```
- لإكمال تسجيل المصدر، يجب أن تستجيب نقطة نهاية تكنولوجيا الإعلان. إلى طلب Android Attribution Reporting API مع عنوان الاستجابة Attribution-Reporting-Register-Source يجب أن يحدد الرد أيضًا وجهة التطبيق في حقل الوجهة.
```
Attribution-Reporting-Register-Source {
    "source_event_id":"123001",
    "destination":"android-app://com.example.advertiser",
    ...
}
```
- لإتاحة عمليات إعادة التوجيه لتسجيلات المصدر، يتّبع Chrome وعمليات إعادة التوجيه واستدعاء واجهات برمجة تطبيقات سياق الويب لكل قفزة من عمليات إعادة التوجيه.
- يظلّ باقي تسجيل المصدر كما هو.
تسجِّل تقنية الإعلان في تطبيق المعلِن عاملاً مشغِّلاً في نظام Android Attribution Reporting API:
- بالنسبة إلى المشغِّلات التي تحدث داخل التطبيقات، تُسجِّل التطبيقات ما يلي: Android Attribution Reporting API كالمعتاد

الحملات التي تتضمّن وجهات محتمَلة على كلٍّ من التطبيقات والمواقع الإلكترونية

إعداد وجهات مزدوجة
- قد يتم إعداد بعض الحملات لإجراء إحالة ناجحة في تطبيق المعلِن أو في صفحة ويب المعلن اعتمادًا على عوامل مختلفة مثل ما إذا كان المستخدم تم تثبيت التطبيق عليه.
- وفي هذه الحالات، ننصح بتفويض تسجيل المصدر إلى نظام التشغيل حيثما كان متاحًا حتى يمكن تحديد مصدر المصدر بشكل صحيح بصرف النظر عن لمكان حدوث المشغل. عند تسجيل المصدر في نظام التشغيل، فإن كلاً من يمكن تحديد التطبيق ووجهة الويب في المعلمات المعنية.
- يجب أن تكون وجهة التطبيق في الحقل destination.
- يجب أن تكون وجهة الويب في الحقل web_destination.
- يجب أن يلاحظ مطوّرو Chrome أنّ الحقل destination لنظام التشغيل يجب أن تكون Attribution Reporting API حزمة تطبيق وليس عنوان URL.
```
Attribution-Reporting-Register-Source {
    "source_event_id":"123001",
    "destination":"android-app://com.example.advertiser",
    "web_destination": "https://example.advertiser"
    ...
}
```
- سيوضح القسم التالي حول التقارير التقريبية كيفية استخدام الوجهات المزدوجة التشويش في تقاريرك.
استخدام التقارير التقريبية لتقليل التشويش في التقارير على مستوى الحدث للثنائي مصادر الوجهة:
- في حال تحديد كل من نظام التشغيل (التطبيق) ووجهة الويب في المصدر التسجيل، فستحدِّد التقارير على مستوى الحدث ما إذا كان المُشغِّل قد في وجهة ويب أو وجهة تطبيق تلقائيًا ومع ذلك، للحفاظ على حدود الخصوصية، ستتم إضافة تشويش إضافي إلى هذه التقارير.
- يمكن لتقنيات الإعلان استخدام الحقل "coarse_event_report_destinations" ضمن عنوان "Attribution-Reporting-Register-Source" لتفعيل إعداد التقارير التقريبية وتقليل الضوضاء. إذا كان مصدر المعلومات coarse_event_report_destinations المحدد الذي يفوز بالإحالة، فإن التقرير الناتج يتضمن كلاً من ووجهات الويب دون تمييز بشأن مكان وجود المشغل الفعلي حدثت ولكن مع تشويش أقل من التقارير التي تعرض التطبيق أو وجهة الويب المحدد.
- ولم تتغيّر التقارير المجمَّعة.

بالنسبة إلى التطبيقات التي تستخدم علامات تبويب Chrome المخصَّصة

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

تسجيل مصدر تطبيق ومشغّل علامة تبويب مخصّصة:
- اتّبِع التعليمات من أجل تسجيل مصدر تطبيق ومشغّل على الويب.
تسجيل مصدر علامة تبويب مخصَّصة ومشغّل التطبيق:
- اتّبِع التعليمات لتسجيل مصدر ويب ومشغّل تطبيق.
تسجيل مصدر CCT ومشغّل CCT
- يتم التعامل مع ذلك بالطريقة نفسها التي يتم التعامل بها مع أي إحالة ويب من موقع إلى موقع في Chrome.

بالنسبة إلى التطبيقات التي تستخدم WebView

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

لا يتوفّر سوى الإحالة على مستوى نظام التشغيل في WebView. تشير رسالة الأشكال البيانية سيعرض عنوان Attribution-Reporting-Support نظام التشغيل فقط، وفقط في حال تتوفّر Android Attribution Reporting API.

ملاحظة: لتنفيذ عملية تحديد المصدر في Chrome و WebView، يُرجى اتّباع الخطوات التالية: تفويض عمليات التسجيل المصدر والتشغيل في Chrome إلى نظام التشغيل إذ لا يتوافق مع WebView سوى تحديد المصدر بالاستناد إلى نظام التشغيل.
عند التفويض إلى نظام التشغيل، قد يستخدم WebView registerSource أو registerWebSource وregisterTrigger أو registerWebTrigger. ما الطرق التي يستخدمها WebView ويتم تحديدها بواسطة التطبيق الذي يعرض WebView على أساس WebView لكل WebView.
- الفرق بين registerSource وregisterWebSource هو المصدر كناشر. باستخدام registerSource، يتم تسجيل التطبيق كناشر ومن الأمثلة على حالات استخدام registerSource تطبيق ناشر يعرض إعلانًا معروضًا باستخدام WebView مع registerWebSource، يتم تسجيل الموقع الإلكتروني المستضاف في WebView على أنّه الناشر: أحد الأمثلة على حالات استخدام registerWebSource هو تطبيق يستضيف WebView، كما أن موقع الويب الذي يتم عرضه بواسطة WebView هو عرض الإعلانات. يختلف أداء كلّ من registerTrigger وregisterWebTrigger. تشير رسالة الأشكال البيانية رسم بياني في البند رقم 3 يفصّل سيناريوهات مختلفة للحالات التي يواجه فيها مطوِّر تطبيقات أو حِزم SDK يريد ضبط واجهة برمجة التطبيقات لتستخدم registerSource أو registerWebSource، وregisterTrigger أو registerWebTrigger.

سيستخدم WebView تلقائيًا registerSource وregisterWebTrigger في الحالات التالية: عن Android Attribution Reporting API يؤدي هذا إلى ربط المصادر بـ التطبيق والمشغلات ذات المصدر الأعلى لعنوان URL في WebView عندما حدوث المشغل.

إذا كان أحد التطبيقات يتطلب سلوكًا مختلفًا، سيحتاج التطبيق إلى استخدام طريقة جديدة. setAttributionRegistrationBehavior على androidx.webkit.WebViewSettingsCompat الصف. ستحدِّد هذه الطريقة ما إذا كان يجب أن يستدعي مكوّن WebView registerWebSource(). أو registerWebTrigger() بدلاً من registerSource() أو registerTrigger().
- يجب ضبط هذا السلوك لكل مكوّن WebView يتم تشغيله.
- إذا كانت حزمة تطوير البرامج (SDK) لتكنولوجيا الإعلان تبدأ في WebView، ستحتاج حزمة SDK إلى ضبط هذا السلوك الافتراضي.
- بالنسبة إلى التطبيقات التي تريد استخدام "registerWebSource()" لربط المصدر عمليات التسجيل باستخدام موقع الويب في WebView بدلاً من التطبيق، يجب الانضمام إلى القائمة المسموح بها في WebApp أكمِل هذا النموذج للانضمام إلى القائمة المسموح بها. تشير رسالة الأشكال البيانية أنّ الغرض من القائمة المسموح بها هو التخفيف من اعتبارات الخصوصية حول ترسيخ الثقة لسياق الويب:
الخيارات المتعلّقة بـ setAttributionRegistrationBehavior

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

عمليات التسجيل المصدر والمشغِّلة من WebView
- يجب أن تستجيب تقنيات الإعلان لتسجيلات المصدر باستخدام عنوان Attribution-Reporting-Register-OS-Source بناءً على السلوك المحدّد بالنسبة إلى WebView، سيؤدي هذا إما إلى استدعاء registerSource() أو registerWebSource() مع نظام التشغيل وبدء طلب بيانات ثانوي من واجهة برمجة التطبيقات من إحالة Android Reporting API لمعرّف الموارد المنتظم (URI) لتكنولوجيا الإعلان.
  - لإكمال تسجيل المصدر، يجب أن تكون نقطة نهاية تكنولوجيا الإعلان الردّ على طلب Android Attribution Reporting API من خلال عنوان الاستجابة:
```
Attribution-Reporting-Register-OS-Source {
    "source_event_id":"123001",
    "destination":"android-app://com.example.advertiser",
    ...
}
```
- يظلّ باقي تسجيل المصدر كما هو.
يجب أن تستجيب تقنيات الإعلان لإطلاق عمليات التسجيل باستخدام عنوان Attribution-Reporting-Register-OS-Trigger بناءً على السلوك المحدّد بالنسبة إلى WebView، سيؤدي هذا إما إلى استدعاء registerTrigger() أو registerWebTrigger() مع نظام التشغيل وبدء طلب بيانات ثانوي من واجهة برمجة التطبيقات من Rb إلى معرّف الموارد المنتظم (URI) لتكنولوجيا الإعلان.
- لإكمال تسجيل المشغِّل، يجب أن تبدأ نقطة نهاية تكنولوجيا الإعلان الردّ على طلب Android Attribution Reporting API .
```
Attribution-Reporting-Register-OS-Trigger {
    "event_trigger_data": [{"trigger_data":"1"}],
    "aggregatable_trigger_data": [
        {"key_piece":"0x400","source_keys":["campaignCounts"]},
        {"key_piece":"0xA80","source_keys":["geoValue"]}
    ],
    ...
}
```
- تبقى بقية عملية تسجيل المشغّل كما هي.

تصحيح الأخطاء

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

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