نظرة عامة على إعداد تقارير الإحالة للأجهزة الجوّالة

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

• تعديل قائمة التغييرات القادمة والمشاكل المعروفة
• تمّ تقديم إعدادات مرنة ومبسّطة على مستوى الحدث، كخطوة أولى نحو استخدام الإعدادات المرنة الكاملة على مستوى الحدث
• اعتبارًا من أيلول (سبتمبر) 2023، يجب أن تستخدم السمات registerWebSource وregisterWebTrigger registerAppSource وregisterAppTrigger سلاسل في الحقول التي تتوقّع قيمة رقمية (مثل priority وsource_event_id وdebug_key trigger_data وdeduplication_key وما إلى ذلك).
• في الربع الرابع من عام 2023، ستتم إضافة دعم Google Cloud إلى Android Attribution Reporting API لإنشاء تقارير تلخيصية باستخدام "خدمة التجميع" على Google Cloud. وسيظهر لك هنا توقيت أكثر تحديدًا. اطّلِع على دليل النشر للحصول على مزيد من المعلومات عن إعداد "خدمة التجميع" باستخدام Google Cloud.
• حدود جديدة لمعدّل الحفاظ على الخصوصية لعدد الوجهات الفريدة
• ستتوفّر وظائف معدَّلة لفلاتر بدء فترة معاينة الإعلانات في الربع الأول من عام 2024، اطّلِع على ملاحظة للمزيد من المعلومات.

نظرة عامة

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

تضم واجهة برمجة التطبيقات هذه الآليات الهيكلية التالية التي تقدم إطارًا لتحسين الخصوصية، والتي تصفها الأقسام التالية في هذه الصفحة بمزيد من التفصيل:

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

الآليات السابقة تحدّ من إمكانية ربط هوية المستخدم في تطبيقَين أو نطاقَين مختلفَين

تتيح واجهة برمجة التطبيقات Attribution Reporting API حالات الاستخدام التالية:

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

على مستوى عالٍ، تعمل Attribution Reporting API على النحو التالي، والتي تصفها الأقسام اللاحقة في هذا المستند بمزيد من التفصيل:

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

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

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

تسجيل مصدر تحديد المصدر (النقرة أو المشاهدة)

تشير Attribution Reporting API إلى النقرات على الإعلانات ومشاهدات الإعلانات باعتبارها مصادر إحالة. لتسجيل نقرة على إعلان أو مشاهدة إعلان، اتصل بالرقم registerSource(). تتوقع واجهة برمجة التطبيقات هذه المعلَمات التالية:

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

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

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

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

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

تعرض الخطوات التالية مثالاً على سير العمل:

1. تستدعي حزمة تطوير البرامج (SDK) لتكنولوجيا الإعلان واجهة برمجة التطبيقات لبدء تسجيل مصدر الإحالة، مع تحديد عنوان URL لواجهة برمجة التطبيقات لاستدعائه:

   registerSource(
       Uri.parse("https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA"),
       myClickEvent);
   

2. تُرسل واجهة برمجة التطبيقات طلبًا إلى https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA، باستخدام أحد العناوين التالية:

   <!-- For click events -->
   Attribution-Reporting-Source-Info: navigation
   
   <!-- For view events -->
   Attribution-Reporting-Source-Info: event
   

3. يردّ خادم HTTPS الخاص بتكنولوجيا الإعلان هذه برؤوس تتضمّن ما يلي:

   Attribution-Reporting-Register-Source: {
       "destination": "android-app://com.advertiser.example",
       "source_event_id": "234",
       "expiry": "60000",
       "priority": "5"
   }
   Attribution-Reporting-Redirect:
   https://adtechpartner1.example?their_ad_click_id=567
   Attribution-Reporting-Redirect:
   https://adtechpartner2.example?their_ad_click_id=890
   

4. تُرسل واجهة برمجة التطبيقات طلبًا إلى كل عنوان URL محدّد في Attribution-Reporting-Redirect. في هذا المثال، يتم تحديد عنوانَي URL لشريكَي تكنولوجيا الإعلان ، لذلك تُجري واجهة برمجة التطبيقات طلبًا واحدًا إلى https://adtechpartner1.example?their_ad_click_id=567 وطلبًا آخر إلى https://adtechpartner2.example?their_ad_click_id=890.

5. يردّ خادم HTTPS الخاص بتكنولوجيا الإعلان هذه برؤوس تتضمّن ما يلي:

   Attribution-Reporting-Register-Source: {
       "destination": "android-app://com.advertiser.example",
       "source_event_id": "789",
       "expiry": "120000",
       "priority": "2"
   }
   

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

تسجيل مصدر تحديد مصدر من WebView

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

بما أنّ تقنيات الإعلانات تستخدم رمزًا برمجيًا مشتركًا بين الويب ومكوّن WebView، يتّبع WebView عمليات إعادة التوجيه HTTP 302 وتمريره إلى النظام الأساسي لعمليات التسجيل الصالحة. لا نخطّط لإتاحة استخدام العنوان Attribution-Reporting-Redirect في هذا السيناريو، ولكن يمكنك التواصل معنا إذا كانت لديك حالة استخدام متأثرة.

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

يمكن لمنصّات تكنولوجيا الإعلان تسجيل العوامل المشغّلة، مثل الإحالات الناجحة مثل عمليات التثبيت أو أحداث ما بعد التثبيت، باستخدام طريقة registerTrigger().

تتوقع طريقة registerTrigger() المعلَمة معرف الموارد المنتظم (URI) للمشغل. تُصدر واجهة برمجة التطبيقات طلبًا لعنوان URI هذا لجلب البيانات الوصفية المرتبطة بالمشغل.

تتّبع واجهة برمجة التطبيقات عمليات إعادة التوجيه. يجب أن تتضمّن استجابة خادم تكنولوجيا الإعلان عنوان HTTP يُعرف باسم Attribution-Reporting-Register-Trigger، ويمثّل معلومات عن عامل تشغيل مسجَّل واحد أو أكثر. يجب أن يكون محتوى الرأس بترميز JSON وأن يتضمّن الحقول التالية:

• بيانات العامل المشغِّل: بيانات لتحديد حدث عامل التشغيل (3 وحدات بت للنقرات، و1 بت للمشاهدات). يجب أن يكون عددًا صحيحًا بعلامة 64 بت بتنسيق سلسلة.
• أولوية المشغِّل (اختياري): تمثّل أولوية هذا المشغِّل مقارنةً بعوامل التفعيل الأخرى لمصدر تحديد المصدر نفسه. يجب أن يكون عددًا صحيحًا signed بسعة 64 بت ويكون منسَّقًا كسلسلة. لمزيد من التفاصيل حول كيفية إعداد تقارير التأثيرات ذات الأولوية، راجِع قسم قسم الأولويات.
• مفتاح إزالة التكرار (اختياري): يُستخدَم لتحديد الحالات التي يتم فيها تسجيل عامل التفعيل نفسه عدّة مرّات من خلال منصّة تكنولوجيا الإعلان نفسها، وذلك لمصدر تحديد المصدر نفسه. يجب أن يكون عددًا صحيحًا بتوقيع 64 بت ومنسق كسلسلة.
• مفاتيح التجميع (اختيارية): وهي قائمة بالقواميس التي تحدد مفاتيح التجميع، وتقارير التقارير القابلة للتجميع، والتي يجب تجميع قيمها.
• قيم التجميع (اختيارية): قائمة بكميات القيمة التي تساهم في كل مفتاح
• الفلاتر (اختيارية): تُستخدم لفلترة المشغلات أو تشغيل البيانات بشكل انتقائي. لمزيد من التفاصيل، يُرجى الاطّلاع على القسم فلاتر العوامل المشغّلة في هذه الصفحة.

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

يمكن لتقنيات إعلانات متعددة تسجيل حدث المشغِّل نفسه إما باستخدام عمليات إعادة التوجيه في الحقل Attribution-Reporting-Redirect أو عبر طلبات متعددة لطريقة registerTrigger(). ننصحك باستخدام حقل مفتاح إزالة التكرار لتجنُّب تضمين عوامل تشغيل مكرّرة في التقارير في حال كانت تكنولوجيا الإعلان نفسها تقدّم ردودًا متعدّدة لحدث التفعيل نفسه. يمكنك الاطّلاع على المزيد من المعلومات حول كيفية استخدام مفتاح إزالة التكرار وحالات استخدامه.

يتضمّن دليل المطوِّر أمثلة توضّح كيفية قبول تسجيل المشغِّل.

تعرض الخطوات التالية مثالاً على سير العمل:

1. تستدعي حزمة تطوير البرامج (SDK) لتكنولوجيا الإعلان واجهة برمجة التطبيقات لبدء تسجيل المشغّل باستخدام عنوان URL مسجَّل مسبقًا. راجِع التسجيل للحصول على حساب "مبادرة حماية الخصوصية" لمزيد من المعلومات.

   registerTrigger(
       Uri.parse("https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA"));
   

2. ترسل واجهة برمجة التطبيقات طلبًا إلى https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA.

3. يردّ خادم HTTPS المرتبط بتكنولوجيا الإعلان هذه بعناوين تحتوي على ما يلي:

   Attribution-Reporting-Register-Trigger: {
       "event_trigger_data": [{
       "trigger_data": "1122",
       // This returns 010 for click-through conversions (CTCs) and 0 for
       // view-through conversions (VTCs) in reports
       "priority": "3",
       "deduplication_key": "3344"
       }],
   }
   Attribution-Reporting-Redirect: https://adtechpartner.example?app_install=567
   

4. تُرسل واجهة برمجة التطبيقات طلبًا إلى كل عنوان URL محدّد في Attribution-Reporting-Redirect. في هذا المثال، تم تحديد عنوان URL واحد فقط، لذلك تقدّم واجهة برمجة التطبيقات طلبًا إلى https://adtechpartner.example?app_install=567.

5. يردّ خادم HTTPS المرتبط بتكنولوجيا الإعلان هذه بعناوين تحتوي على ما يلي:

   Attribution-Reporting-Register-Trigger: {
   "event_trigger_data":[{
     "trigger_data": "5566",
     "priority": "3",
     "deduplication_key": "3344"
   }]
   }
   

   تم تسجيل اثنين من المشغلات بناءً على الطلبات الواردة في الخطوات السابقة.

إمكانات تحديد المصدر

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

تم تطبيق خوارزمية تحديد المصدر حسب الأولوية

تستخدِم Attribution Reporting API algorithn تحديد مصدر يستند إلى المصدر لمطابقة عامل تشغيل (إحالة ناجحة) مع مصدر تحديد مصدر.

توفّر مَعلمات الأولوية طُرقًا لتخصيص عملية تحديد مصدر العوامل المُشغِّلة:

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

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

فلاتر التشغيل

يتضمّن تسجيل المصدر والمشغِّل وظائف اختيارية إضافية لتنفيذ ما يلي:

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

لفلترة عوامل التشغيل بشكل انتقائي، يمكن لتكنولوجيا الإعلان تحديد بيانات الفلترة، التي تتألّف من المفاتيح والقيم، أثناء تسجيل المصدر وعامل التشغيل. إذا تم تحديد نفس المفتاح لكل من المصدر والمشغِّل، فسيتم تجاهل المشغل إذا كان التقاطع فارغًا. على سبيل المثال، يمكن أن يحدّد المصدر "product": ["1234"]، حيث يكون product هو مفتاح الفلتر و1234 هي القيمة. في حال ضبط فلتر عامل التفعيل على "product": ["1111"]، سيتم تجاهل العامل المشغِّل. إذا لم يكن هناك مفتاح فلتر تشغيل يتطابق مع product، يتم تجاهل الفلاتر.

هناك سيناريو آخر قد تحتاج فيه منصات تكنولوجيا الإعلان إلى فلترة عوامل التفعيل بشكل انتقائي، وهو فرض فترة انتهاء صلاحية أقصر. عند تسجيل المشغّل، يمكن لتكنولوجيا الإعلان تحديد (بالثواني) فترة معاينة الإعلان من وقت حدوث الإحالة الناجحة. على سبيل المثال، يمكن تعريف فترة معاينة الإعلان التي تبلغ 7 أيام على النحو التالي: "_lookback_window": 604800 // 7d

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

يمكن لمنصّات تكنولوجيا الإعلان أيضًا اختيار بيانات المشغِّل استنادًا إلى بيانات الأحداث المصدر. على سبيل المثال، يتم إنشاء source_type تلقائيًا من خلال واجهة برمجة التطبيقات على النحو التالي: navigation أو event. أثناء تسجيل المشغِّل، يمكن ضبط trigger_data كقيمة واحدة لـ "source_type": ["navigation"] وكقيمة مختلفة لـ "source_type": ["event"].

يتم استبعاد عوامل التفعيل من التقارير على مستوى الحدث في حال استيفاء أيّ من الشروط التالية:

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

تحديد المصدر بعد التثبيت

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

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

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

في المستقبل، قد نبحث في توسيع نطاق التصميم ليشمل نماذج تحديد مصدر أكثر تقدّمًا.

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

تقدّم القائمة التالية بعض الملاحظات الإضافية بشأن إحالة ما بعد التثبيت:

• إذا لم تحدث عملية التثبيت التي تم إثبات صحتها خلال عدد الأيام المحدّد من قِبل install_attribution_window، لن يتمّ تطبيق عملية تحديد المصدر بعد التثبيت.
• لا تسجّل تقنيات الإعلانات عمليات التثبيت التي تم إثبات صحتها، ولا يتم إرسالها في التقارير. ولا يتم احتسابها ضمن حدود المعدل التي تفرضها تقنية الإعلان. لا تُستخدَم عمليات التثبيت التي تم التحقّق منها إلا لتحديد مصدر الإحالة الذي يُنسب إليه عملية التثبيت.
• في المثال من الجدول السابق، يمثّل المشغّل 1 والمشغّل 2 إحالة ناجحة للتشغيل لأول مرة وإحالة ناجحة بعد التثبيت، على التوالي. ومع ذلك، يمكن لمنصات تكنولوجيا الإعلان تسجيل أي نوع من أنواع المشغّلات بعبارة أخرى، ليس بالضرورة أن يكون المشغِّل الأول مشغِّلاً مفتوحًا.
• إذا تم تسجيل المزيد من عوامل التفعيل بعد انتهاء صلاحية post_install_exclusivity_window ، سيظلّ النقر رقم 1 مؤهّلاً للإحالة، بافتراض أنّه لم يتم انتهاء صلاحيته ولم يصل إلى حدود معدّلاته.
  • قد يظلّ النقر رقم 1 غير متوفّر أو يتم تجاهله إذا تم تسجيل مصدر تحديد مصدر ذو أولوية أعلى.
• في حال إلغاء تثبيت تطبيق المعلِن ثم إعادة تثبيته، يتم احتساب عملية إعادة التثبيت كعملية تثبيت جديدة تم التحقّق منها.
• إذا كانت النقرة 1 عبارة عن حدث مشاهدة بدلاً من ذلك، ستُنسب إليها كل من عوامل تشغيل "أول فتح" وما بعد التثبيت. تحدّ واجهة برمجة التطبيقات من عملية تحديد المصدر إلى عامل بدء واحد لكل مشاهدة، باستثناء حالة تحديد المصدر بعد التثبيت حيث يُسمح بما يصل إلى عاملَي بدء لكل مشاهدة. في حالة تحديد المصدر بعد التثبيت، يمكن أن تتلقّى تكنولوجيا الإعلان نافذتَي إعداد تقارير مختلفتَين (بعد يومَين أو عند انتهاء صلاحية المصدر).

تتوفّر جميع مجموعات مسارات التفعيل المستندة إلى التطبيقات والويب.

تتيح Attribution Reporting API تحديد مصدر مسارات المشغّل التالية على جهاز Android واحد:

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

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

تعرَّف على التغييرات التي يجب إجراؤها على تكنولوجيات الإعلان والتطبيقات من أجل إتاحة مسارات تشغيل القياس على جميع التطبيقات والويب.

منح الأولوية لعوامل تشغيل متعددة لمصدر تحديد مصدر واحد

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

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

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

السماح لعدة تقنيات إعلان بتسجيل مصادر تحديد المصدر أو مشغِّلات

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

يمكن للمعلِنين الذين يريدون استخدام جهة خارجية لإجراء عملية إزالة تكرار على مستوى الشبكات المتعددة مواصلة إجراء ذلك باستخدام أسلوب مشابه لما يلي:

• إعداد خادم داخلي لتسجيل التقارير وتلقّيها من واجهة برمجة التطبيقات
• مواصلة استخدام شريك قياس أداء حالي للأجهزة الجوّالة

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

تتوفّر عمليات إعادة التوجيه لمصدر تحديد المصدر بطريقة registerSource():

1. يمكن لتقنية الإعلان التي تطلب طريقة registerSource() توفير حقل Attribution-Reporting-Redirect إضافي في الردّ يمثّل مجموعة عناوين URL لإعادة التوجيه الخاصة بتقنية إعلانات الشركاء.
2. بعد ذلك، تستدعي واجهة برمجة التطبيقات عناوين URL لإعادة التوجيه حتى تتمكّن تكنولوجيات الإعلانات التابعة للشركاء من تسجيل مصدر الإحالة.

يمكن إدراج عناوين URL متعددة لتكنولوجيا الإعلانات الخاصة بالشركاء في حقل Attribution-Reporting-Redirect، ولا يمكن لتكنولوجيا الإعلانات الخاصة بالشركاء تحديد حقل Attribution-Reporting-Redirect الخاص بها.

تتيح واجهة برمجة التطبيقات أيضًا تقنيات إعلان مختلفة لكل طلب registerSource().

العوامل التي تؤدي إلى الظهور

بالنسبة إلى تسجيل المشغِّلات، يتم توفير الجهات الخارجية بطريقة مشابهة: يمكن لتقنيات الإعلان استخدام حقل Attribution-Reporting-Redirect الإضافي أو يمكن لكل منها استدعاء طريقة registerTrigger().

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

معالجة عوامل التشغيل المكرّرة

قد تسجِّل تقنية عرض الإعلانات عامل التفعيل نفسه عدّة مرات باستخدام واجهة برمجة التطبيقات. تشمل السيناريوهات ما يلي:

• ينفّذ المستخدم الإجراء نفسه (عامل التفعيل) عدة مرات. على سبيل المثال، يتصفّح المستخدم المنتج نفسه عدة مرات في النافذة نفسها لإعداد التقارير.
• يستخدم تطبيق المعلن عدة حِزم تطوير برامج (SDK) لقياس الإحالات الناجحة، وجميعها تعيد توجيه المستخدمين إلى تكنولوجيا الإعلان نفسها. على سبيل المثال، يستعين تطبيق المعلِن بشريكَين في عملية القياس، وهما MMP #1 وMMP #2. تعيد كلتا منصّتَي إدارة الأداء إعادة التوجيه إلى تكنولوجيا الإعلان رقم 3. عند حدوث عامل تشغيل، يسجّل كلّ من منصّت إدارة الأداء التسويقي (MMP) عامل التشغيل هذا باستخدام واجهة برمجة التطبيقات Attribution Reporting API. بعد ذلك، تتلقّى تقنية الإعلان رقم 3 عمليتَي إعادة توجيه منفصلتَين، إحداهما من MMP #1 والأخرى من MMP #2، للعامل المشغِّل نفسه.

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

الطريقة المقترَحة: مفتاح إزالة التكرار

والطريقة المقترحة هي أن يمرّر تطبيق المعلِن مفتاح إزالة تكرارًا فريدًا إلى أيّ من تقنيات الإعلان أو حِزم تطوير البرامج (SDK) التي يستخدمها لقياس الإحالات الناجحة. عند حدوث إحالة ناجحة، يمرِّر التطبيق مفتاح إزالة التكرار إلى تقنيات الإعلان أو حِزم تطوير البرامج (SDK). وبعد ذلك، ستواصل هذه الأدوات أو حِزم تطوير البرامج (SDK) عرض مفتاح إزالة التكرار في عمليات إعادة التوجيه باستخدام مَعلمة في عناوين URL المحدّدة في Attribution-Reporting-Redirect.

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

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

الطريقة البديلة: توافق تكنولوجيات الإعلان على أنواع عوامل التفعيل لكلّ معلِن

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

تشتمل تقنيات الإعلان التي تبدأ طلب تسجيل المشغِّل، مثل حِزم SDK، على مَعلمة في عناوين URL المحدّدة في Attribution-Reporting-Redirect، مثل duplicate_trigger_id. ويمكن أن تتضمّن مَعلمة duplicate_trigger_id معلومات مثل اسم حزمة SDK ونوع المشغِّل لذلك المعلِن. يمكن لتقنيات الإعلان بعد ذلك إرسال مجموعة فرعية من هذه العوامل المكررة إلى التقارير على مستوى الحدث. يمكن لتقنيات الإعلان أيضًا تضمين duplicate_trigger_id هذا في مفاتيح التجميع.

مثال على تحديد المصدر على جميع الشبكات

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

للبدء، يجب أن تُكمِل كلّ من تكنولوجيا الإعلان (أ) وتكنولوجيا الإعلان (ب) وإدارة الأداء التسويقي عملية التسجيل لاستخدام واجهة برمجة التطبيقات Attribution Reporting API. راجِع التسجيل للحصول على حساب "مبادرة حماية الخصوصية" لمزيد من المعلومات.

تقدِّم القائمة التالية سلسلة افتراضية من إجراءات المستخدمين يتم إجراؤها كل يوم على حدة، وكيفية تعامل واجهة Attribution Reporting API مع هذه الإجراءات في ما يتعلّق بتقنية الإعلان (أ) وتكنولوجيا الإعلان (ب) وMMP:

اليوم 1: نقر المستخدِم على إعلان يتمّ عرضه بواسطة تكنولوجيا الإعلان (أ)

تطلب تقنية الإعلان A الاتصال بـ registerSource() باستخدام معرّف الموارد المنتظم (URI). ترسل واجهة برمجة التطبيقات طلبًا إلى عنوان URI، ويتم تسجيل النقرة في البيانات الوصفية الواردة من استجابة خادم تكنولوجيا الإعلان A.

تتضمّن تقنية الإعلان (أ) أيضًا عنوان URL لخدمة إدارة الأداء التسويقي في العنوان Attribution-Reporting-Redirect . تُرسل واجهة برمجة التطبيقات طلبًا إلى معرّف الموارد المنتظم (URI) لخدمة إدارة الأداء التسويقي (MMP)، ويتم تسجيل النقرة مع البيانات الوصفية من استجابة خادم خدمة إدارة الأداء التسويقي.

اليوم 2: ينقر المستخدِم على إعلان تعرِضه تقنية Ad Tech B.

تطلب تقنية الإعلان "ب" registerSource() باستخدام معرّف الموارد المنتظم (URI). ترسل واجهة برمجة التطبيقات طلبًا إلى عنوان URI، ويتم تسجيل النقرة مع البيانات الوصفية من استجابة خادم تكنولوجيا الإعلان "ب".

كما هو الحال مع تكنولوجيا الإعلان "أ"، ضمّنت تكنولوجيا الإعلان "ب" أيضًا معرّف الموارد المنتظم (URI) لتطبيق MMP في العنوان Attribution-Reporting-Redirect. ترسل واجهة برمجة التطبيقات طلبًا إلى معرّف الموارد المنتظم (URI) لـ MMP، ويتم تسجيل النقرة مع البيانات الوصفية من استجابة خادم MMP.

اليوم 3: يشاهد المستخدِم إعلانًا تم عرضه باستخدام تكنولوجيا الإعلان (أ)

تستجيب واجهة برمجة التطبيقات بالطريقة نفسها التي كانت تستجيب بها في اليوم الأول، باستثناء تسجيل مرة مشاهدة لتقنية الإعلان "أ" و"لوحة الإعلانات المتعددة اللاعبين".

اليوم 4: يثبّت المستخدم التطبيق الذي يستخدم منصّة إدارة الأداء (MMP) لقياس الإحالات الناجحة.

يتصل منصّة إدارة الأداء (MMP) بخدمة registerTrigger() باستخدام معرّف الموارد المنتظم (URI). ترسل واجهة برمجة التطبيقات طلبًا إلى عنوان URL، ويتم تسجيل التحويل باستخدام البيانات الوصفية الواردة من استجابة خادم MMP.

يتضمّن MMP أيضًا معرّفات الموارد المنتظمة (URI) لتقنية الإعلان "أ" وتقنية الإعلان "ب" في العنوان Attribution-Reporting-Redirect. ترسل واجهة برمجة التطبيقات طلبات إلى خوادم تكنولوجيا الإعلان "أ" و"ب"، ويتم تسجيل الإحالة الناجحة وفقًا للبيانات الوصفية الواردة من استجابات الخادم.

يوضّح المخطّط التالي العملية الموضّحة في القائمة السابقة:

تعمل الإحالة على النحو التالي:

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

تحديد المصدر على جميع الشبكات بدون عمليات إعادة التوجيه

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

تدفق عالي المستوى

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

تسجيل المصدر

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

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

تسجيل مشغِّل

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

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

تحديد المصدر

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

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

يسجِّل منصّة إدارة الأداء (MMP) مصدرًا من تقنية الإعلان (أ)، ويحدِّد إعدادات تحديد المصدر التي تتضمّن تقنية الإعلان (ب) وتقنية الإعلان (د).

تتضمّن عملية تحديد المصدر في منصّة إدارة الأداء (MMP) الآن ما يلي:

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

لا تشمل عملية تحديد المصدر في منصّة إدارة الأداء (MMP) ما يلي:

• تقنية الإعلان (ج)، لأنّ منصّة إدارة الأداء لم تُدرِجها في إعدادات تحديد المصدر.
• Ad Tech D، لأنّها لم تُعيد التوجيه أو تشارك مفاتيح التجميع.

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

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

لن تتوفّر ميزة تصحيح الأخطاء هذه إلا لتحديد المصدر على مستوى الشبكات بدون عمليات إعادة التوجيه في الحالات التالية:

• بين التطبيقات والقياس حيث تم السماح باستخدام رقم تعريف الإعلان
• قياس الإحالات الناجحة من التطبيق إلى الموقع الإلكتروني حيث يُسمح باستخدام AdId والمطابقة على مستوى كلّ من مصدر التطبيق وعامل تشغيل الويب
• القياس من الويب إلى الويب (على تطبيق المتصفّح نفسه) عند توفّر "ar_debug" في كلٍّ من المصدر والمشغِّل

اكتشاف مفتاح تحديد المصدر على جميع الشبكات بدون عمليات إعادة التوجيه

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

عندما يستفسر MMP عن "خدمة التجميع" لإنشاء تقارير ملخصة للحملات التي تتضمن مصادر مشتقة، تتطلب "خدمة التجميع" (MMP) تحديد قائمة المفاتيح المحتملة كمدخل لمهمة التجميع. وفي بعض الحالات، قد تكون قائمة مفاتيح تجميع المصادر المحتملة كبيرة جدًا أو غير معروفة. يصعب تتبع القوائم الكبيرة من المفاتيح المحتملة، ومن المحتمل أيضًا أن تكون معالجتها معقدة ومكلفة للغاية. راجِع المثالين التاليين:

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

مع إطلاق ميزة "اكتشاف المفتاح":

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

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

عمليات إعادة توجيه سلسلة العلامات النجمية

من خلال توفير عدة عناوين Attribution-Reporting-Redirect في المصدر أو استجابة خادم HTTPS للتسجيل، يمكن لتقنية الإعلان استخدام Attribution Reporting API لإجراء عدّة مصادر وتشغيل عمليات التسجيل من خلال طلب بيانات واحد من واجهة برمجة التطبيقات للتسجيل.

في استجابة الخادم، يمكن أن تتضمّن تقنية عرض الإعلانات أيضًا عنوان Location (إعادة توجيه 302) واحدًا مع عنوان URL، ما يؤدي بدوره إلى تسجيل آخر، بما في ذلك الحدّ الأقصى المسموح به.

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

لا يتم قبول عمليات إعادة التوجيه لـ registerWebSource وregisterWebTrigger التي تستخدمها المتصفّحات. يمكنك الاطّلاع على مزيد من التفاصيل في دليل تنفيذ ميزة "التتبّع على الويب والتطبيقات" على مستوى الموقع الإلكتروني والتطبيق.

عرض بيانات القياس في تقارير الإحالة

تتيح Attribution Reporting API الأنواع التالية من التقارير، الموضّحة بالتفصيل في هذه الصفحة:

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

يتكامل هذان النوعان من التقارير مع بعضهما البعض ويمكن استخدامهما في الوقت نفسه.

التقارير على مستوى الحدث

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

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

يحتوي التقرير على مستوى الحدث على بيانات مثل ما يلي:

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

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

يتم تطبيق الحدود التالية بعد مراعاة الأولويات المتعلّقة بمصادر تحديد المصدر والعوامل المشغّلة.

الحدود المفروضة على عدد تقنيات الإعلان

هناك حدود لعدد تقنيات الإعلان التي يمكنها تسجيل التقارير أو تلقّيها من واجهة برمجة التطبيقات، مع اقتراح حالي لما يلي:

• 100 تقنية للإعلان مع مصادر تحديد المصدر لكل {source app, destination app, 30 days, device}.
• 10 تقنيات للإعلان مع عوامل تشغيل محدّدة مصدرها لكل {source app, destination app, 30 days, device}.
• يمكن أن تسجِّل 20 تقنية إعلانية مصدر تحديد مصدر واحدًا أو عامل تشغيل واحدًا (من خلال Attribution-Reporting-Redirect).

الحدود المفروضة على عدد الوجهات الفريدة

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

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

ولا تُحتسب المصادر المنتهية الصلاحية ضمن حدود المعدّلات.

مصدر إعداد تقارير واحد لكل تطبيق مصدر يوميًا

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

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

1. يسجّل المصدر 1 لإعداد التقارير الخاصة بتقنية الإعلان "أ" مصدرًا في التطبيق "ب"
2. بعد 12 ساعة، حاول مصدر الإبلاغ لتقنية الإعلان "أ" تسجيل مصدر في التطبيق "ب"

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

حدود فترة الاستراحة والمعدل

للحدّ من مقدار تسرُّب هوية المستخدم بين زوج {source, destination} ، تقلّل واجهة برمجة التطبيقات مقدار إجمالي المعلومات التي يتم إرسالها خلال فترة زمنية معيّنة للمستخدم.

يقضي الاقتراح الحالي بحصر كل تقنية إعلانية بـ 100 عامل تشغيل منسَب لكل {source app, destination app, 30 days, device}.

عدد الوجهات الفريدة

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

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

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

دقة محدودة لبيانات المشغّل

توفّر واجهة برمجة التطبيقات بتًا واحدًا لعوامل تشغيل المشاهدة فقط و3 بتات لعوامل تشغيل النقر فقط. تستمرّ مصادر الإسناد في إتاحة الـ 64 بت الكامل من البيانات الوصفية.

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

إطار عمل لوظائف إخفاء هوية المستخدمين للحفاظ على الخصوصية

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

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

الاستجابة العشوائية التصنيفية هي خوارزمية تتمتع بالخصوصية التفاضلية إذا استوفت المعادلة التالية:

بالنسبة إلى القيم المنخفضة لدالة ε، يتم حماية الإخراج الصحيح من خلال آلية الردّ المبرمَج بترتيب عشوائي من k. تجدر الإشارة إلى أن معلمات التشويش الدقيقة قيد التنفيذ حاليًا، وتخضع للتغيير بناءً على الملاحظات، مع اقتراح حالي لما يلي:

• ‫p=0.24% لمصادر التنقّل
• ‫p=0.00025% لمصادر الأحداث

الحدود المفروضة على المشغّلات المتاحة (الإحالات الناجحة)

هناك حدود لعدد عوامل التفعيل لكلّ مصدر إحالة، مع اقتراح حالي على النحو التالي:

• 1 أو 2 من عوامل مصادر تحديد المصدر لمشاهدات الإعلان (يتوفّر عامل تشغيل واحد فقط في حالة تحديد المصدر بعد التثبيت)
• 3 عوامل تشغيل لمصادر تحديد مصدر الإعلانات التي يتم النقر عليها

فترات زمنية محددة لإرسال التقارير (السلوك التلقائي)

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

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

• يومان: يجمع الجهاز كل المشغِّلات التي حدثت بعد يومَين على الأكثر من تسجيل مصدر تحديد المصدر. يتم إرسال التقرير بعد يومين وساعة واحدة من تسجيل مصدر الإحالة
• 7 أيام: يجمع الجهاز كل المشغلات التي حدثت بعد أكثر من يومين ولكن ليس أكثر من 7 أيام بعد تسجيل مصدر تحديد المصدر. ويتم إرسال التقرير بعد 7 أيام وساعة واحدة من تسجيل مصدر تحديد المصدر.
• مدة مخصّصة، يتم تحديدها من خلال سمة "expiry" لمصدر تحديد المصدر يتم إرسال التقرير بعد ساعة واحدة من انقضاء مهلة الصلاحيه المحدّدة. لا يمكن أن تكون هذه القيمة أقل من يوم واحد أو أكثر من 30 يومًا.

إعدادات مرنة على مستوى الحدث

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

سيتمّ تقديم هذه المرونة الإضافية في واجهة برمجة التطبيقات لخدمة "تقارير تحديد المصدر" في مرحلتَين:

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

يمكن استخدام المرحلة 1 (مستوى الحدث المرن البسيط) لإجراء ما يلي:

• تغيير معدّل تكرار التقارير من خلال تحديد عدد فترات إعداد التقارير
• تغيير عدد الإحالات لكل تسجيل مصدر
• تقليل إجمالي مقدار الضوضاء عن طريق خفض المَعلمات أعلاه
• ضبط فترات إعداد التقارير بدلاً من استخدام الإعدادات التلقائية

يمكن استخدام المرحلة 2 (مستوى الحدث المرن الكامل) لتنفيذ كل الوظائف في المرحلة 1 وتنفيذ ما يلي:

• تغيير عدد القيم الفريدة لبيانات العامل المشغِّل في تقرير
• تقليل مقدار الضوضاء الإجمالية عن طريق تقليل عدد العناصر في الحقل لبيانات المشغّل

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

بالإضافة إلى ضبط مستويات الضوضاء ديناميكيًا استنادًا إلى الإعدادات التي تم اختيارها لتكنولوجيا الإعلان، سنضع بعض الحدود للمَعلمات لتجنّب تكاليف العمليات الحسابية العالية والإعدادات التي تتضمّن عددًا كبيرًا من حالات الإخراج (حيث سيزداد الضوضاء بشكل ملحوظ). في ما يلي مثال على مجموعة من القيود. يتم تشجيع الملاحظات على [اقتراح التصميم][50]:

• الحد الأقصى لعدد التقارير هو 20 تقريرًا على مستوى العالم لكل trigger_data
• 5 فترات زمنية محتملة كحد أقصى لإعداد التقارير لكل trigger_data
• إنّ الحدّ الأقصى لعدد القيم الفريدة للسمة هو 32 عامل تشغيل (لا ينطبق على المرحلة 1: مستوى مرن: مستوى الحدث المرن)

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

التقارير القابلة للتجميع

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

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

• تقارير لقيم المشغّلات، مثل الأرباح
• التعامل مع المزيد من أنواع المشغّلات

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

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

1. يُرسِل الجهاز تقارير مشفَّرة قابلة للتجميع إلى تكنولوجيا الإعلان. وفي بيئة الإنتاج، لا يمكن لتكنولوجيا الإعلان استخدام هذه التقارير مباشرةً.
2. وترسل تقنية الإعلان مجموعة من التقارير القابلة للتجميع إلى خدمة التجميع.
3. تقرأ خدمة التجميع مجموعة من التقارير القابلة للتجميع وفك تشفيرها وتجميعها.
4. يتمّ إرسال القيم المجمّعة النهائية مرة أخرى إلى تكنولوجيا الإعلان في تقرير تلخيصي.

تحتوي التقارير القابلة للتجميع على البيانات التالية ذات الصلة بمصادر تحديد المصدر:

• الوجهة: اسم حزمة التطبيق أو عنوان URL للويب eTLD+1 حيث حدث المشغِّل
• التاريخ: تاريخ وقوع الحدث الذي يمثّله مصدر الإحالة.
• الحمولة: قيم المشغِّلات التي يتم جمعها كأزواج مفتاح/قيمة مشفَّرة، والتي يتم استخدامها في خدمة التجميع الموثوق بها لحساب عمليات التجميع

خدمات التجميع

توفِّر الخدمات التالية وظيفة التجميع وتساعد في الحماية من الوصول غير الملائم إلى بيانات التجميع.

تُدار هذه الخدمات من قِبل جهات مختلفة، وهي موضّحة بالتفصيل في القسم التالي من هذه الصفحة:

• وخدمة التجميع هي الخدمة الوحيدة التي من المتوقّع أن تنشرها تقنيات الإعلان.
• تتم إدارة خدمتَي إدارة مفاتيح التشفير ومحاسبة التقارير القابلة للتجميع من قِبل جهات موثوقة تُعرف باسم المنسقين. ويقر هؤلاء المنسّقون أنّ الرمز البرمجي الذي يشغِّل خدمة التجميع هو الرمز البرمجي المتاح للجميع الذي توفّره Google وأنّ جميع مستخدمي خدمة التجميع لديهم نفس المفتاح وخدمات محاسبة التقارير القابلة للتجميع المطبَّقة عليهم.

خدمة تجميع البيانات

يجب أن تستخدم منصات تكنولوجيا الإعلان مسبقًا خدمة تجميع تستند إلى برامج ثنائية توفّرها Google.

تعمل خدمة التجميع هذه في بيئة تنفيذ موثوقة (TEE) تتم استضافتها في السحابة الإلكترونية. توفّر بيئة التنفيذ الموثوقة (TEE) مزايا الأمان التالية:

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

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

لمزيد من المعلومات حول التصميم وعملية سير العمل والاعتبارات الأمنية للخدمة التجميعية، يُرجى الاطّلاع على مستند الخدمة التجميعية على GitHub.

خدمة إدارة مفاتيح التشفير

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

محاسبة التقارير القابلة للتجميع

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

واجهة برمجة التطبيقات للتقارير القابلة للتجميع

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

تسجيل بيانات المصدر القابلة للتجميع

عندما تُقدّم واجهة برمجة التطبيقات طلبًا إلى معرّف الموارد المنتظم لمصدر تحديد المصدر، يمكن لتكنولوجيا الإعلان تسجيل قائمة بمفاتيح التجميع التي تحمل الاسم histogram_contributions، وذلك من خلال الردّ بحقل جديد باسم aggregation_keys في رأس HTTP Attribution-Reporting-Register-Source، مع استخدام key_name كمفتاح وkey_piece كقيمة:

• (مفتاح) اسم المفتاح: سلسلة لاسم المفتاح يُستخدم كمفتاح دمج للدمج مع مفاتيح جانب المشغل لتشكيل المفتاح النهائي.
• (القيمة) قطعة المفتاح: قيمة سلسلة بت للمفتاح.

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

الحد الأقصى لحجم المفاتيح النهائية هو 128 بت، ويتم اقتطاع المفاتيح الأطول من ذلك. وهذا يعني أنّ سلاسل الأعداد الست عشرية في ملف JSON يجب أن تقتصر على 32 رقمًا كحد أقصى.

يمكنك الاطّلاع على مزيد من المعلومات حول كيفية تنظيم مفاتيح التجميع وكيفية ضبط مفاتيح التجميع.

في المثال التالي، تستخدم تقنية عرض الإعلانات واجهة برمجة التطبيقات لجمع ما يلي:

• تجميع أعداد الإحالات الناجحة على مستوى الحملة
• قيم الشراء المجمّعة على المستوى الجغرافي

// This is where the Attribution-Reporting-Register-Source object appears when
// an ad tech registers an attribution source.

// Attribution source metadata specifying histogram contributions in aggregate report.
Attribution-Reporting-Register-Source:
…
aggregation_keys: {
  // Generates a "0x159" key piece named (low order bits of the key) for the key
  // named "campaignCounts".
  // User saw an ad from campaign 345 (out of 511).

  "campaignCounts": "0x159",
  // Generates a "0x5" key piece (low order bits of the key) for the key name "geoValue"
  // Source-side geo region = 5 (US), out of a possible ~100 regions.
  "geoValue": "0x5"
}

سجِّل عامل التشغيل القابل للتجميع.

يتضمن تسجيل المشغِّل حقلين إضافيين.

يُستخدم الحقل الأول لتسجيل قائمة بالمفاتيح المجمّعة على جانب المشغّل. ومن المفترض أن تستجيب تكنولوجيا الإعلان باستخدام الحقل aggregatable_trigger_data في عنوان HTTP Attribution-Reporting-Register-Trigger، مع تضمين الحقول التالية لكل مفتاح مجمّع في القائمة:

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

يُستخدَم الحقل الثاني لتسجيل قائمة بالقيم التي يجب أن تساهم في كل مفتاح. يجب أن تستجيب تقنية عرض الإعلانات من خلال الحقل aggregatable_values في عنوان HTTP Attribution-Reporting-Register-Trigger. يُستخدم الحقل الثاني لتسجيل قائمة بالقيم التي يجب أن تسهم في كل مفتاح، والتي يمكن أن تكون أعدادًا صحيحة في النطاق $ [1, 2^{16}] $.

يمكن لكل عامل تشغيل تقديم مساهمات متعددة في التقارير القابلة للتجميع. يرتبط إجمالي مبلغ المساهمات في أي حدث مصدر محدّد بمَعلمة $ L1 $، وهي أقصى عدد للمساهمات (القيم) على مستوى كل المفاتيح المجمّعة لمصدر محدّد. يشير $ L1 $ إلى حساسية L1 أو القاعدة للمساهمات في المخطّط البياني لكل حدث مصدر. يؤدي تجاوز هذه الحدود إلى إسقاط المساهمات المستقبلية بدون إشعار. الاقتراح الأولي هو تعيين $ L1 $ إلى $ 2^{16} $ (65536).

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

في المثال التالي، يتم تقسيم ميزانية الخصوصية بالتساوي بين campaignCounts وgeoValue من خلال تقسيم مساهمة $ L1 $ لكل منهما:

// This is where the Attribution-Reporting-Register-Trigger object appears
// when an ad tech registers a conversion trigger.

// Specify a list of dictionaries that generates aggregation keys.
Attribution-Reporting-Register-Trigger:{
    …
    "aggregatable_trigger_data":

    [
    // Each dictionary independently adds pieces to multiple source keys.
    {
    // Conversion type purchase = 2 at a 9-bit offset, i.e. 2 << 9.
    // A 9-bit offset is needed because there are 511 possible campaigns, which
    // will take up 9 bits in the resulting key.
        "key_piece": "0x400",// Conversion type purchase = 2
        // Apply this key piece to:
        "source_keys": ["campaignCounts"]
    },
    {
    // Purchase category shirts = 21 at a 7-bit offset, i.e. 21 << 7.
    // A 7-bit offset is needed because there are ~100 regions for the geo key,
    // which will take up 7 bits of space in the resulting key.
        "key_piece": "0xA80",
        // Apply this key piece to:
        "source_keys": ["geoValue", "nonMatchingIdsListedHereAreIgnored"]
    }
    ]

    // Specify an amount of an abstract value which can be integers in [1, 2^16] to
    // contribute to each key that is attached to aggregation keys in the order that
    // they're generated.
    aggregatable_values:
    {
    // Privacy budget for each key is L1 / 2 = 2^15 (32768).
    // Conversion count was 1.
    // Scale the count to use the full budget allocated: 1 * 32768 = 32768.
        "campaignCounts": 32768,

    // Purchase price was $52.
    // Purchase values for the app range from $1 to $1,024 (integers only).
    // Scaling factor applied is 32768 / 1024 = 32.
    // For $52 purchase, scale the value by 32 ($52 * 32 = $1,664).
        "geoValue": 1664
    }
}

يُنشئ المثال السابق المساهمات التالية في المخطّط البياني الشريطي:

[
  // campaignCounts:
  {
    "key": "0x559", // = 0x159 | 0x400
    "value": 32768
  },
  // geoValue:
  {
    "key": "0xA85",  // = 0x5 | 0xA80
    "value": 1664
  }
]

يمكن عكس عوامل التكبير للحصول على القيم الصحيحة، مع مراعاة الضوضاء التي يتم تطبيقها:

L1 = 65536
trueCampaignCounts = campaignCounts / (L1 / 2)
trueGeoValue = geoValue / (L1 / 2) * 1024

الخصوصية التفاضلية

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

دمج Protected Audience API وAttribution Reporting API

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

من خلال هذا الدمج على مستوى واجهات برمجة التطبيقات، يمكن لتكنولوجيات عرض الإعلانات إجراء ما يلي:

• أنشئ خريطة للمفاتيح والقيم لمعرّفات الموارد المنتظمة التي سيتم استخدامها في كلّ من: 1) إعداد تقارير التفاعل و2) تسجيل المصدر.
• أدرِج CustomAudience في تعيين المفاتيح من جهة المصدر لإعداد تقارير متراكمة ومقتضبة (باستخدام Attribution Reporting API).

عندما يرى أحد المستخدِمين إعلانًا أو ينقر عليه:

• سيتم أيضًا استخدام عنوان URL المستخدَم لتسجيل هذه التفاعلات باستخدام Protected Audience لتسجيل مشاهدة أو نقرة كمصدر مؤهَّل باستخدام Attribution Reporting API.
• قد تختار تقنية الإعلان تمرير Custom Audience (أو معلومات سياقية أخرى ذات صلة عن الإعلان، مثل موضع الإعلان أو مدة المشاهدة) باستخدام عنوان URL هذا حتى يمكن نشر هذه البيانات الوصفية في التقارير التلخيصية عندما تراجع تقنية الإعلان الأداء الإجمالي للحملة.

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

أمثلة على أولوية التسجيل وتحديد المصدر وإعداد التقارير

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

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

لنفترض أنّ المستخدِم ينفِّذ ما يلي:

1. يرى المستخدِم إعلانًا. تسجِّل تكنولوجيا الإعلان مصدر إحالة من خلال واجهة برمجة التطبيقات، مع أولوية 0 (عرض رقم 1).
2. يشاهد المستخدم إعلانًا مسجَّلاً بأولوية 0 (عرض رقم 2).
3. ينقر المستخدم على إعلان مسجَّل بأولوية 1 (انقر على رقم 1).
4. يُجري المستخدِم إحالة ناجحة (يصل إلى الصفحة المقصودة) في تطبيق معلِن. تسجِّل تقنية الإعلان trigger (العامل المشغِّل) باستخدام واجهة برمجة التطبيقات، مع أولوية 0 (الإحالة الناجحة رقم 1).
   • عند تسجيل عوامل التفعيل، تُجري واجهة برمجة التطبيقات عملية تحديد المصدر أولاً قبل إنشاء التقارير.
   • تتوفّر 3 مصادر تحديد مصدر: العرض رقم 1 والعرض رقم 2 والنقر رقم 1. تُنسِب واجهة برمجة التطبيقات هذا المشغِّل إلى النقرة رقم 1 لأنّه الأكثر أولوية والأحدث.
   • يتم تجاهل العرضَين الأول والثاني، ولم يعُدَا مؤهّلين لتحديد المصدر في المستقبل.
5. يضيف المستخدِم سلعة إلى سلّة التسوّق في تطبيق المعلِن، المسجَّلة بأولوية 1 (الإحالة الناجحة رقم 2).
   • النقرة رقم 1 هي مصدر تحديد المصدر الوحيد المؤهَّل. سمات واجهة برمجة التطبيقات تؤدي إلى تنشيط النقرة رقم 1.
6. يضيف المستخدم سلعة إلى سلة التسوّق في تطبيق المعلن، وتم التسجيل بأولوية 1 (الإحالة الناجحة رقم 3).
   • النقرة رقم 1 هي مصدر الإحالة المؤهَّل الوحيد. سمات واجهة برمجة التطبيقات تؤدي هذه العوامل إلى النقر على الخيار رقم 1.
7. يضيف المستخدم سلعة إلى سلة التسوّق في تطبيق المعلِن، وتم التسجيل بأولوية 1 (الإحالة الناجحة رقم 4).
   • النقرة رقم 1 هي مصدر تحديد المصدر الوحيد المؤهَّل. سمات واجهة برمجة التطبيقات تؤدي إلى تنشيط النقرة رقم 1.
8. يُجري المستخدِم عملية شراء في تطبيق المعلِن المسجَّل بأولوية 2 (الإحالة الناجحة رقم 5).
   • النقرة رقم 1 هي مصدر الإحالة المؤهَّل الوحيد. تحدد واجهة برمجة التطبيقات هذا المشغل للنقر فوق #1.

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

• يتم تلقائيًا إرسال أول 3 عوامل تشغيل منسوبة إلى نقرة وأول عامل تشغيل منسوب إلى مشاهدة بعد فترات إعداد التقارير السارية.
• في فترة إعداد التقارير، إذا كانت هناك مشغِّلات مسجّلة بأولوية أعلى، تكون لها الأولوية وتحلّ محل أحدث عامل تشغيل.
• في المثال السابق، تتلقّى تقنية الإعلان 3 تقارير عن الأحداث بعد فترة إعداد التقارير التي تبلغ يومَين، فيما يخص الإحالة الناجحة رقم 2 والإحالة الناجحة رقم 3 والإحالة الناجحة رقم 5.
  • يتمّ تحديد جميع عوامل التفعيل الخمسة على أنّها من النقرة رقم 1. بشكل تلقائي، سترسل واجهة برمجة التطبيقات تقارير لأول 3 عوامل تشغيل: الإحالة الناجحة رقم 1، والإحالة الناجحة رقم 2، والإحالة الناجحة رقم 3.
  • ومع ذلك، تكون أولوية الإحالة الناجحة رقم 4 (1) أعلى من أولوية الإحالة الناجحة رقم 1 (0). ويحلّ تقرير حدث الإحالة الناجحة رقم 4 محلّ تقرير حدث الإحالة الناجحة رقم 1 المطلوب إرساله.
  • إضافةً إلى ذلك، تكون أولوية الإحالة الناجحة رقم 5 (2) أعلى من أي مشغِّل آخر. يحل تقرير حدث الإحالة الناجحة رقم 5 محل تقرير الإحالة الناجحة رقم 4 الذي سيتم إرساله.

تتميّز التقارير القابلة للتجميع بالسمات التالية:

• يتم إرسال التقارير المشفَّرة القابلة للتجميع إلى تكنولوجيا الإعلان فور معالجتها، أي بعد بضع ساعات من تسجيل عوامل التشغيل.

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

• يُرجى العِلم أنّه يعود إلى تكنولوجيا عرض الإعلانات تحديد وقت تجميع التقارير القابلة للّجمّع وكيفية تجميعها ونقلها إلى خدمة التجميع.

• مقارنةً بالتقارير على مستوى الحدث، يمكن أن تنسب التقارير المشفَّرة المجمّعة عوامل تشغيل أكثر إلى مصدر.

• في المثال السابق، يتم إرسال 5 تقارير مجمّعة، بتقرير واحد لكل مشغّل مسجّل.

تقارير تصحيح الأخطاء الانتقالي

‫Attribution Reporting API هي طريقة جديدة ومعقّدة إلى حدٍ ما لقياس تحديد المصدر بدون معرّفات على مستوى التطبيقات. ولهذا السبب، نتيح استخدام آلية انتقالية للاطّلاع على مزيد من المعلومات عن تقارير الإحالة عندما يكون المعرّف الإعلاني متاحًا (لم يوقف المستخدم التخصيص باستخدام المعرّف الإعلاني وأعلن الناشر أو التطبيق المعلن عن أذونات المعرّف الإعلاني). ويضمن ذلك فهم واجهة برمجة التطبيقات بشكل كامل أثناء عملية الطرح، والمساعدة في إزالة أي أخطاء، ومقارنة الأداء بسهولة أكبر بالبدائل المستندة إلى المعرِّف الإعلاني. هناك نوعان من تقارير تصحيح الأخطاء: نجاح الإحالة والتحسين المطوَّل.

اطّلِع على دليل تقارير تصحيح الأخطاء الانتقالية للحصول على تفاصيل عن تقارير تصحيح الأخطاء باستخدام قياس التطبيق إلى الويب والويب إلى التطبيق.

تقارير تصحيح أخطاء نجاح تحديد المصدر

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

إذا تم إنشاء تقرير باستخدام مفاتيح تصحيح أخطاء المصدر والتشغيل، يتم إرسال ملف تكرار تقرير تصحيح الأخطاء بعد تأخير محدود إلى نقطة نهاية .well-known/attribution-reporting/debug/report-event-attribution. تتطابق تقارير تصحيح الأخطاء مع التقارير العادية، بما في ذلك الحقلان الرئيسيان لتصحيح الأخطاء. يسمح تضمين هذين المفتاحَين في كليهما بربط التقارير العادية بالتدفق المنفصل من تقارير تصحيح الأخطاء.

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

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

تسمح تقارير تصحيح الأخطاء المطوَّلة للمطوّرين برصد أخطاء معيّنة في مصدر تحديد المصدر أو تشغيل عمليات التسجيل. يتم إرسال تقارير تصحيح الأخطاء هذه مع تأخير محدود بعد مصدر الإحالة أو تشغيل عمليات التسجيل .نقطة نهاية well-known/attribution-reporting/debug/verbose.

يحتوي كل تقرير مطوَّل على الحقول التالية:

• النوع: السبب الذي أدّى إلى إنشاء التقرير اطّلِع على القائمة الكاملة لأنواع التقارير التفصيلية.
  • بشكل عام، هناك تقارير تفصيلية للمصادر وتقارير تفصيلية للعوامل المشغِّلة.
  • تتطلب التقارير المفصَّلة المصدر توفّر المعرِّف الإعلاني لتطبيق الناشر، وتتطلّب التقارير المطوَّلة التي تعمل على تشغيل المعرِّف الإعلاني توفُّر المعرِّف الإعلاني لتطبيق المعلِن.
  • يمكن أن تتضمّن تقارير التشغيل المطوَّل (باستثناء trigger-no-matching-source) السمة source_debug_key بشكل اختياري. لا يمكن تضمين ذلك إلا إذا كان المعرِّف الإعلاني متاحًا أيضًا لتطبيق الناشر.
• النص: نص التقرير الذي يعتمد على نوعه

يجب أن يوافق فريق تكنولوجيا الإعلان على تلقّي تقارير تصحيح الأخطاء المطوَّل باستخدام حقل جديد من قاموس debug_reporting في العنوان Attribution-Reporting-Register_Source وAttribution-Reporting-Register-Trigger.

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

كيفية استخدام تقارير تصحيح الأخطاء

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

لكلّ تقرير تحديد مصدر من خلال تصحيح الأخطاء، تحقّق ممّا إذا كنت تتلقّى تقرير تحديد مصدر عاديًا يتطابق مع مفتاحَي تصحيح الأخطاء.

يمكن أن يعود عدم تطابق البيانات لعدد من الأسباب.

تعمل على النحو المطلوب:

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

الأسباب غير المقصودة:

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

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

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

بالإضافة إلى ذلك، نودّ أن نحصل على ملاحظات من المنتدى بشأن بعض المشاكل:

1. هل هناك أيّ حالات استخدام تريد فيها أن تُرسِل واجهة برمجة التطبيقات تقارير عن التلقّي المُثبَّت؟ سيتم احتساب هذه التقارير ضمن حدود المعدّلات الخاصة بمنصّات تكنولوجيا الإعلان.
2. هل تتوقّع حدوث أيّ صعوبات في نقل InputEvent من التطبيق إلى تكنولوجيا الإعلان من أجل تسجيل المصدر؟
3. هل لديك أيّ حالات استخدام خاصة لتحديد المصدر للتطبيقات المحمَّلة مسبقًا أو التطبيقات التي تمت إعادة تثبيتها؟