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

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

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

  • تمّ تقديم ميزة الإعداد البسيط والمرنة على مستوى الحدث، كخطوة أولى نحو استخدام ميزة الإعداد المرن على مستوى الحدث الكاملة.

  • اعتبارًا من أيلول (سبتمبر) 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(). تتوقع واجهة برمجة التطبيقات هذه المَعلمات التالية:

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

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

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

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

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

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

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

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

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

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

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

  • مفاتيح التجميع (اختيارية): представлява قائمة بالقواميس التي تحدّد مفاتيح التجميع والتقارير القابلة للتجميع التي يجب تجميع قيمها.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

اليوم الأول: ينقر المستخدِم على إعلان تعرِضه تقنية الإعلان (أ).

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

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

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

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

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

اليوم 3: يشاهد المستخدِم إعلانًا تعرِضه تقنية Ad Tech A

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

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

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

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

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

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

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

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

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

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

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

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

تسجيل المصدر

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

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

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

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

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

تحديد المصدر

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • الوجهة: اسم حزمة تطبيق المعلِن أو نطاق المستوى الأعلى للترميز الجغرافي (eTLD+1) الذي حدث فيه عامل التفعيل
  • رقم تعريف مصدر الإحالة الناجحة: رقم تعريف مصدر الإحالة الناجحة نفسه الذي تم استخدامه في تسجيل مصدر إحالة ناجحة
  • نوع العامل المشغِّل: 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 لخدمة Ad Tech A. لن يتمكّن مصدر إعداد التقارير 2 لشركة AdTech A من تسجيل مصدر على الجهاز نفسه في التطبيق B بنجاح إلى اليوم التالي.

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

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

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

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

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

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

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

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

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

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

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

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

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

الاستجابة العشوائية بترتيب k هي خوارزمية ��

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

عندما تُقدّم واجهة برمجة التطبيقات طلبًا إلى معرّف الموارد المنتظم لمصدر الإحالة، يمكن لتكنولوجيا الإعلان تسجيل قائمة بمفاتيح التجميع التي تحمل الاسم 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).

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

في المثال التالي، يتم تقسيم ميزانية الخصوصية بالتساوي بين 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 $، مثل اختيار التشويش باستخدام التوزيع التالي:

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

دمج Protected Audience API وAttribution Reporting API

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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