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

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

• تم تعديل قائمة التغييرات القادمة والمشاكل المعروفة

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

نظرة عامة

من الشائع اليوم أن تستخدم حلول قياس الأداء وتحديد المصدر على الأجهزة الجوّالة معرّفات من جهات خارجية مختلفة، مثل المعرِّف الإعلاني. تمّ تصميم 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) لمصدر تحديد المصدر: ترسل المنصة طلبًا إلى معرّف الموارد المنتظم هذا من أجل استرداد البيانات الوصفية المرتبطة بمصدر تحديد المصدر.
• حدث الإدخال: إما عنصر InputEvent (لحدث نقرة) أو null (لحدث مشاهدة).

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

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

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

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

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

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

   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 بتات للنقرات، وبت واحد للمشاهدات). يجب أن يكون عددًا صحيحًا 64 بتًا بتنسيق سلسلة.

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

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

• مفاتيح التجميع (اختيارية): قائمة من القواميس التي تحدّد مفاتيح التجميع وتحدّد التقارير القابلة للتجميع التي يجب تجميع قيمتها.

• قيم التجميع (اختيارية): قائمة بمبالغ القيم التي تساهم في كل مفتاح.

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

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

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

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

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

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

   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 خوارزمية تحديد المصدر حسب الأولوية لمطابقة حدث مشغِّل (إحالة ناجحة) مع مصدر تحديد المصدر.

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

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

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

فلاتر المشغّلات

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

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

لتصفية المشغّلات بشكل انتقائي، يمكن أن تحدّد تكنولوجيا الإعلان بيانات الفلتر التي تتألف من مفاتيح وقيم أثناء تسجيل المصدر والمشغّل. إذا تم تحديد المفتاح نفسه لكل من المصدر والمشغّل، سيتم تجاهل المشغّل إذا كان التقاطع فارغًا. على سبيل المثال، يمكن أن يحدّد المصدر "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 تحديد مصدر مسارات المشغّلات التالية على جهاز Android واحد:

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

نسمح لمتصفّحات الويب بتوفير ميزات جديدة متاحة على الويب، مثل الوظائف المشابهة لواجهة برمجة التطبيقات 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) متعددة لقياس الإحالات الناجحة، وكلها تعيد التوجيه إلى تقنية الإعلان نفسها. على سبيل المثال، يستخدم تطبيق المعلِن شريكَي قياس، هما شريك القياس رقم 1 وشريك القياس رقم 2. تعيد كلتا منصّتَي التسويق قياس الأداء التوجيه إلى تكنولوجيا الإعلان رقم 3. عندما يتم تشغيل عامل، تسجّل كلتا منصّتَي قياس الأداء والتسويق هذا العامل في Attribution Reporting API. بعد ذلك، تتلقّى تكنولوجيا الإعلان رقم 3 عمليتَي إعادة توجيه منفصلتَين، إحداهما من منصّة قياس التسويق رقم 1 والأخرى من منصّة قياس التسويق رقم 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 في مفاتيح التجميع.

مثال على الإحالة على جميع الشبكات

في المثال الموضّح في هذا القسم، يستخدم المعلِن منصتَين لتقنية عرض الإعلانات (تقنية عرض الإعلانات A وتقنية عرض الإعلانات B) وشريكًا واحدًا للقياس (MMP).

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

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

اليوم الأول: ينقر المستخدم على إعلان يعرضه "تكنولوجيا الإعلان أ"

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

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

اليوم الثاني: ينقر المستخدم على إعلان يعرضه "تكنولوجيا الإعلان ب"

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

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

اليوم 3: يرى المستخدِم إعلانًا تعرضه "تكنولوجيا الإعلان أ"

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

اليوم الرابع: يثبّت المستخدم التطبيق الذي يستخدِم منصة التسويق لقياس الإحالات الناجحة

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

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

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

تعمل تحديد المصدر على النحو التالي:

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

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

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

خطوات التنفيذ العالية المستوى

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

تسجيل المصدر

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

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

تسجيل المشغّل

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

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

تحديد المصدر

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

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

تسجّل منصّة MMP مصدرًا من "تكنولوجيا الإعلان أ"، وتحدّد إعدادات تحديد المصدر تتضمّن "تكنولوجيا الإعلان ب" و"تكنولوجيا الإعلان د".

يتضمّن تحديد مصدر الإحالة في منصة MMP الآن ما يلي:

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

لا يشمل تحديد المصدر في منصة التسويق ما يلي:

• تقنية الإعلان C، لأنّ منصّة قياس الأداء والتسويق لم تدرجها في إعدادات تحديد المصدر.
• مزوّد تقنية الإعلان D، لأنّه لم يعِد التوجيه ولم يشارك مفاتيح التجميع.

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

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

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

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

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

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

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

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

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

• لم تعُد "خدمة تجميع البيانات" تتطلّب تعدادًا كاملاً لمفاتيح التجميع المحتملة.
• بدلاً من الاضطرار إلى تحديد القائمة الكاملة للمفاتيح المحتملة، يمكن لـ 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 تكنولوجيا إعلانية تتضمّن مصادر تحديد المصدر لكل {تطبيق مصدر، تطبيق وجهة، 30 يومًا، جهاز}.
• 10 تكنولوجيات إعلانية تتضمّن مشغّلات مرتبطة بمصدرها لكل {تطبيق مصدر، تطبيق وجهة، 30 يومًا، جهاز}.
• يمكن لـ 20 تكنولوجيا إعلان تسجيل مصدر أو مشغّل تحديد مصدر واحد (من خلال Attribution-Reporting-Redirect)

الحدود القصوى لعدد الوجهات الفريدة

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

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

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

مصدر تقارير واحد لكل تطبيق مصدر في اليوم

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

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

1. تسجّل تقنية الإعلان (أ) مصدرًا على التطبيق (ب)
2. بعد 12 ساعة، يحاول مصدر إعداد التقارير 2 التابع لتكنولوجيا الإعلان (أ) تسجيل مصدر على التطبيق (ب)

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

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

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

ويتمثّل الاقتراح الحالي في حصر كل تكنولوجيا إعلانية في 100 مشغّل محدّد المصدر لكل {تطبيق المصدر، تطبيق الوجهة، 30 يومًا، الجهاز}.

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

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

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

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

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

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

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

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

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

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

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

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

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

الحدود القصوى المسموح بها للمشغّلات المتاحة (الإحالات الناجحة)

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

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

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

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

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

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

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

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

سيتم توفير هذه المرونة الإضافية في Attribution Reporting API على مرحلتَين:

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

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

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

يمكن استخدام المرحلة 2 (مستوى الحدث المرن الكامل) لتنفيذ جميع الإمكانات في المرحلة 1، بالإضافة إلى ما يلي:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

واجهة برمجة التطبيقات Aggregatable Reports API

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

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

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

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

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

تقتصر المفاتيح النهائية على 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 لمساهمات المدرّج التكراري لكل حدث مصدر. ويؤدي تجاوز هذه الحدود إلى تجاهل المساهمات المستقبلية بدون إشعار. ويتمثل الاقتراح الأوّلي في ضبط قيمة $ 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 لمنصات تكنولوجيا الإعلان تقييم أداء تحديد المصدر في مختلف استراتيجيات تجديد النشاط التسويقي من أجل معرفة أنواع شرائح الجمهور التي تحقّق أعلى عائد استثمار.

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

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

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

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

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

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

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

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

لنفترض أنّ المستخدم قام بما يلي:

1. يظهر الإعلان للمستخدم. تسجّل تكنولوجيا الإعلان مصدر تحديد المصدر مع واجهة برمجة التطبيقات، مع تحديد الأولوية 0 (المشاهدة رقم 1).
2. يشاهد المستخدم إعلانًا مسجّلاً بالأولوية 0 (المشاهدة رقم 2).
3. ينقر المستخدِم على إعلان مسجَّل بالأولوية 1 (النقرة رقم 1).
4. يُجري المستخدم إحالة ناجحة (يصل إلى الصفحة المقصودة) في تطبيق أحد المعلِنين. تسجّل تكنولوجيا الإعلان حدثًا مشغّلاً باستخدام واجهة برمجة التطبيقات، مع تحديد الأولوية على أنّها 0 (الإحالة الناجحة رقم 1).
   • عند تسجيل المشغّلات، تنفّذ واجهة برمجة التطبيقات عملية تحديد المصدر أولاً قبل إنشاء التقارير.
   • تتوفّر 3 مصادر لتحديد المصدر: المشاهدة رقم 1 والمشاهدة رقم 2 والنقرة رقم 1. تنسب واجهة برمجة التطبيقات هذا المشغّل إلى النقرة رقم 1 لأنّها الأعلى أولوية والأحدث.
   • يتم تجاهل المشاهدة رقم 1 والمشاهدة رقم 2 ولم يعودا مؤهّلتَين لتحديد المصدر في المستقبل.
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. تُرسِل واجهة برمجة التطبيقات تلقائيًا تقاريرًا عن المشغّلات الثلاثة الأولى: الإحالة الناجحة رقم 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. هل لديك أي حالات استخدام خاصة لتحديد المصدر للتطبيقات المحمَّلة مسبقًا أو التطبيقات التي تمت إعادة تثبيتها؟