تقارير الإحالة

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

آخر التعديلات

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

نظرة عامة

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

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

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

تتيح Attribution Reporting API حالات الاستخدام التالية:

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

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

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

الوصول إلى Attribution Reporting API

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

أسباب طلب المساعدة

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

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

التعامل مع المشغلات المكررة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

اليوم 2: ينقر المستخدم على إعلان من خلال تكنولوجيا الإعلان (ب)

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

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

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

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

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

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

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

يوضح الشكل 1 العملية الموضحة في القائمة السابقة:

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

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

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

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

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

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

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

تسجيل المصدر

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

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

بدء التسجيل

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

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

الإحالات

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

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

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

تشمل إحالة MMP الآن ما يلي:

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

لا تشمل إحالة MMP ما يلي:

  • تكنولوجيا الإعلان (ج)، بما أن MMP لم يدرجها في إعدادات الإحالة.
  • Ad Tech D، لأنها لم تعيد توجيه أو مشاركة مفاتيح التجميع.

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

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

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

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

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

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

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

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

مع مقدمة عن ميزة الاستكشاف الأساسي:

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

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

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

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

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

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

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

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

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

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

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

حدود فترة التوقف ومعدّل الضريبة

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

يتمثل الاقتراح الحالي في قصر كل تكنولوجيا إعلانات على 100 عامل تشغيل منسوبًا إلى كل {source app, destination app, 30 days, device}.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الحدود المسموح بها للعوامل المشغِّلة المتاحة (السلوك التلقائي)

هناك حدود تلقائية لعدد المشغلات (الإحالات الناجحة) لكل مصدر تحديد مصدر:

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

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

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

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

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

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

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

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

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

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

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

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

  • تنويع عدد القيم الفريدة للسمة التي تؤدي إلى البيانات المشغِّلة في أحد التقارير
  • تقليل مقدار التشويش الكلي عن طريق تقليل عدد القيم الفريدة للسمة في البيانات المشغِّلة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

لمزيد من المعلومات حول التصميم وسير العمل واعتبارات الأمان الخاصة بخدمة التجميع، راجع [مستند خدمة التجميع][59]{: .external} على GitHub.

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

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

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

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

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

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

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

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

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

يتم تحديد مفتاح مجموعة المدرج التكراري النهائي بالكامل في وقت التشغيل عن طريق تنفيذ عملية 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

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

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

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

دمج Protected Audience API وAttribution Reporting API

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

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

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

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

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

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

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

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

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

ضع في اعتبارك الحالة التي يقوم فيها المستخدم بما يلي:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

بالنسبة إلى إصدارات DP 10 والإصدارات الأحدث، ستحتوي طلبات تقرير تصحيح أخطاء الإحالة الناجحة على عنوان إصدار على النحو التالي: Version: 202310

تتطابق تقارير تصحيح الأخطاء مع التقارير العادية، بما في ذلك كلا حقلَي مفتاح تصحيح الأخطاء. يسمح تضمين هذين المفتاحين في كليهما بربط التقارير العادية بالتدفق المنفصل لتقارير تصحيح الأخطاء.

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

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

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

بالنسبة إلى إصدارات DP 10 والإصدارات الأحدث، ستحتوي طلبات تقرير تصحيح أخطاء الإحالة الناجحة على عنوان إصدار على النحو التالي: Version: 202310

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

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

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

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

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

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

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

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

يعمل على النحو المنشود:

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

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

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

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

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

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

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