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

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

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

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

عندما تقدِّم واجهة برمجة التطبيقات طلبًا إلى معرّف الموارد المنتظم (URI) لمصدر مقياس الأداء، من المفترض أن تردّ تقنية الإعلان على البيانات الوصفية لمصدر الإحالة في عنوان 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، يتّبع WebView عمليات إعادة التوجيه HTTP 302 ويمرر عمليات التسجيل الصالحة إلى النظام الأساسي. لا نخطط لتوفير عنوان Attribution-Reporting-Redirect لهذا السيناريو، ولكن تواصَل معنا في حال كانت لديك حالة استخدام متأثرة بهذا التغيير.

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

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

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

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

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

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

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

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

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

في ما يلي بعض الملاحظات الإضافية بشأن تحديد مصدر ما بعد التثبيت:

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

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

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

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

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

اليوم الأول: ينقر المستخدم على أحد الإعلانات المعروضة من خلال تكنولوجيا الإعلان (أ)

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

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

اليوم الثاني: نقر المستخدم على أحد الإعلانات المعروضة من خلال "تكنولوجيا الإعلان (ب)"

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

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

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

تستجيب واجهة برمجة التطبيقات بالطريقة نفسها التي كانت تستجيب بها في اليوم الأول، باستثناء أنّه تم تسجيل مرة المشاهدة في Ad Tech A وMMP.

اليوم 4: يثبّت المستخدم التطبيق الذي يستخدم MMP لقياس الإحالات الناجحة

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

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

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

مثال على كيفية استجابة Attribution Reporting API لسلسلة من إجراءات المستخدمين.

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

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

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

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

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

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

تسجيل المصدر

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

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

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

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

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

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

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

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

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

يشمل تحديد مصدر MMP الآن ما يلي:

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

ولا يشمل تحديد مصدر MMP ما يلي:

  • تكنولوجيا الإعلان ج، نظرًا لأن MMP لم يدرجها في إعدادات الإحالة.
  • تكنولوجيا الإعلان د، لأنّها لم تكن تعيد توجيه مفاتيح تجميع البيانات ولا تشاركها.

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

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

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

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

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

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

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

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

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

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

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

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

تتيح 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 لتقنية الإعلان أ، بواسطة واجهة برمجة التطبيقات. لن يتمكن أصل إعداد التقارير 2 لتكنولوجيا الإعلان "أ" من تسجيل مصدر بنجاح على الجهاز نفسه على التطبيق "ب" حتى اليوم التالي.

حدود فترة التوقف ومعدّل الاشتراك

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

والاقتراح الحالي هو حصر كل تكنولوجيا إعلانات بـ 100 عامل تشغيل من المصدر لكل {source app, destination app, 30 days, device}.

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

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

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

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

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

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

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

إطار عمل تشويش الخصوصية التفاضلية

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

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

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

\[ p = \frac{k}{k + e^ε - 1} \]

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

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

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

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

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

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

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

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

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

ضبط مرن على مستوى الحدث

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

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

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

يمكن استخدام المرحلة 1 (مستوى الحدث المرن البسيط) للأغراض التالية:

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

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

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

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

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

  • الحد الأقصى هو 20 تقريرًا للإجمالي، على مستوى العالم، ولكل فئة user_data.
  • 5 فترات محتملة لإعداد التقارير كحد أقصى لكل المعلّمة_data
  • الحد الأقصى لعدد القيم الفريدة للسمة هو 32 حرفًا (لا ينطبق ذلك على المرحلة 1: مستوى الحدث المرن في المستوى البسيط)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تتتبّع هذه الخدمة عدد مرّات وصول خدمة تجميع تكنولوجيا الإعلان إلى مشغِّل معيّن يمكن أن يحتوي على مفاتيح تجميع متعدّدة، كما تحدّ من إمكانية الوصول إلى العدد المناسب من عمليات فك التشفير. للحصول على التفاصيل، يُرجى الرجوع إلى خدمة التجميع الخاصة باقتراح تصميم Attribution Reporting 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 $ إلى $ 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

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

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

\[ Laplace(\frac{L1}{ε}) \]

دمج Protected Audience API وAttribution Reporting API

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

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

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

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

  • سيتم أيضًا استخدام عنوان URL المستخدَم في الإبلاغ عن هذه التفاعلات باستخدام Protected Audience لتسجيل ملف شخصي أو نقرة كمصدر مؤهَّل في Attribution Reporting API.
  • قد تختار تقنية الإعلان تمرير بيانات الجمهور المخصّص (أو غيرها من المعلومات السياقية ذات الصلة حول الإعلان، مثل موضع الإعلان أو مدة المشاهدة) باستخدام عنوان 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. بشكل تلقائي، ترسل واجهة برمجة التطبيقات تقارير حول أول 3 عوامل: الإحالة الناجحة 1 والإحالة الناجحة رقم 2 والإحالة الناجحة رقم 3.
    • مع ذلك، إنّ أولوية الإحالة الناجحة رقم 4 (1) أعلى من أولوية الإحالة الناجحة رقم 1 (0). فتقرير الأحداث المتعلّق بالإحالة الناجحة رقم 4 يحلّ محلّ تقرير أحداث الإحالة الناجحة رقم 1 الذي سيتمّ إرساله.
    • بالإضافة إلى ذلك، تكون أولوية الإحالة الناجحة رقم 5 (2) أعلى من أي عامل تشغيل آخر. يحل تقرير الحدث للإحالة الناجحة رقم 5 محل تقرير الإحالة الناجحة رقم 4 الذي سيتم إرساله.

تتسم التقارير القابلة للتجميع بالخصائص التالية:

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

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

  • الأمر متروك لتكنولوجيا الإعلان فيما يتعلق بموعد وكيفية تجميع التقارير القابلة للتجميع وإرسالها إلى خدمة التجميع.

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

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

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

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

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

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

تقبل عمليات تسجيل المصدر وعوامل التشغيل حقل 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. هل لديك أي حالات استخدام خاصة لتحديد المصدر للتطبيقات المحمَّلة مسبقًا أو التطبيقات التي تمت إعادة تثبيتها؟