تفعيل قياس الإحالات الناجحة

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

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

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

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

السيناريوهات الشائعة لقياس الإحالات الناجحة

في هذا القسم، سنفحص سيناريوهَين شائعَين لقياس الإحالات الناجحة.

السيناريو 1: يجب أن يتلقّى كلّ من مزوّد تقنية الإعلان الذي يعرض خدمات القياس ومقدّم خدمة القياس التابع لطرف ثالث تقارير من Attribution Reporting API.

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

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

يمكن أن يظهر الإعداد النموذجي للحملة على النحو التالي:

  1. يزوِّد خادم إعلانات المعلِن (3PAS) ترميز تصميم الإعلان بنظام وسيط عرض الطلب، الذي يتضمّن وحدات بكسل تتبُّع النقرات ومرات الظهور لمزوِّد خدمة القياس التابع لطرف ثالث. يجب أن يتأكّد خادم الإعلانات من تضمين attributionsrc في ترميز تصميم الإعلان.

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

السيناريو 2: يحتاج مقدِّم خدمات القياس التابع لجهة خارجية فقط إلى تلقّي التقارير من Attribution Reporting API.

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

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

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

تفاصيل التنفيذ

يوضِّح الجدول التالي خطوات تنفيذ Attribution Reporting API على مستوى عالٍ:

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

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

بالنسبة إلى إعلانات الفيديو التي تستخدم تنسيق نموذج عرض إعلانات الفيديو (VAST)، يضيف الناشر وحزمة تطوير البرامج (SDK) للفيديو السمة.

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

إذا تعذّر استخدام عمليات إعادة التوجيه 302، يمكن استخدام السمة attributionsrc لإدراج خوادم متعدّدة لتكنولوجيا الإعلان.

بوجه عام، ما دامت السمة attributionsrc قد تمت إضافتها إلى تصميم الإعلان، من المفترض أن تتلقّى عمليات إعادة التوجيه التابعة لجهة خارجية طلبات البيانات من Attribution Reporting API.
الخطوة 3: إعداد الردود لطلبات Attribution Reporting API أيّ جهة تريد تلقّي التقارير من Attribution Reporting API مزوِّد خدمة القياس ومقدّم خدمة القياس التابع لطرف ثالث اللذان يستعين بهما المعلِن

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

الخطوة 1: تفعيل مصدر تحديد المصدر لتصميمات الإعلانات الحالية ورمز القياس

في الخطوة الأولى، يتم تفعيل مصادر تحديد المصدر.

آلية عمل سمة attributionsrc

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

بالنسبة إلى أحداث النقر التي تستخدم عمليات إعادة التوجيه، يجب إضافة السمة attributionsrc إلى شريط التنقّل. ولا تحتاج أي عمليات إعادة توجيه 302 بعد عملية التنقّل إلى إضافة السمة attributionsrc، وتكون مؤهَّلة لاستخدام ARA طالما أنّ عملية التنقّل الأولية تمت إضافة السمة attributionsrc.

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

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

مثال على سمة attributionsrc فارغة:

إعداداتك الحالية مع دمج ARA
<a href="[CLICKTHROUGH_URL]">...</a> <a href="[CLICKTHROUGH_URL]" attributionsrc>...</a>

عندما تكون السمة attributionsrc فارغة، سيتم إرسال طلبات Attribution Reporting API إلى عنوان URL الذي حدّدته السمة href لعلامة الارتساء.

مثال على سمة Attributionsrc غير فارغة:

إعداداتك الحالية مع دمج ARA
<a href="[CLICKTHROUGH_URL]">...</a> <a href="[CLICKTHROUGH_URL]" attributionsrc="[ATTRIBUTION_SRC_URL]">...</a>

عندما لا يكون attributionsrc فارغًا، سيتم إرسال طلبات Attribution Reporting API إلى عنوان URL الذي تحدّده العلامة attributionsrc. وكذلك يكون عنوان URL للنقرة مؤهَّلاً أيضًا لتسجيل المصادر.

أضِف attributionsrc لأحداث النقر ومرّات الظهور.

  • أحداث النقر:
    • عادةً ما يكون الكيان المسؤول عن إضافة attributionsrc هو تقنية الإعلانات المعروضة.
    • يجب إضافة سمة attributionsrc لعلامات الارتساء التي تتضمّن أحداث نقر.
    • يجب أن تستخدم النقرات التي تستخدم window.open الوسيطة windowFeatures لاستدعاء window.open لتحديد مصدر الإحالة.
  • أحداث مرات الظهور:
    • الكيان المسؤول عن إضافة attributionsrc هو عادةً فريق تكنولوجيا الإعلانات المعروضة ومزوّدي خدمات القياس.
    • يجب أن تتضمّن أحداث مرات الظهور التي تم تنشيطها من علامة <img> أو علامة <script> سمة attributionsrc.
    • يجب أن تتضمن أحداث مرات الظهور التي تستخدم Fetch API عنصر attributionReporting في وسيطة options التي تم تمريرها إلى طلب بيانات من واجهة برمجة التطبيقات للجلب.

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

حدث العلامة إعداداتك الحالية بعد دمج ARA
(يُرجى النقر.) HTML <a href="[CLICKTHROUGH_URL]">...</a> <a href="[CLICKTHROUGH_URL]" attributionsrc>...</a>
JavaScript window.open('[CLICKTHROUGH_URL]', '_blank'); window.open('[CLICKTHROUGH_URL]', '_blank', 'attributionsrc');
الظهور علامة HTML <img> <img src="[IMPRESSION_URL]" /> <img src="[IMPRESSION_URL]" attributionsrc />
علامة HTML <script> <script src="[IMPRESSION_URL]"></script> <script src="[IMPRESSION_URL]" attributionsrc></script>
JavaScript const options = {...}
window.fetch("[IMPRESSION_URL]", options); 		const options = {
  attributionReporting: {
    eventSourceEligible: true,
    triggerEligible: false,
  },
  // ...
}

window.fetch("[IMPRESSION_URL]", options);

تفعيل تسجيل مصدر تحديد المصدر في مزاد جمهور محمي

لقياس الإحالات الناجحة في مزادات ذات جمهور محمي، بدلاً من استخدام attributionsrc، يمكنك استخدام registerAdBeacon/registerAdMacro وsetReportEventDataForAutomaticBeacons/reportEvent لتفعيل تسجيل مصادر تحديد المصدر.

لإعداد تقارير إشارات الجمهور المحمي، تتوفّر الدالة registerAdBeacon داخل حِزم إعداد التقارير، في حين تتوفّر registerAdMacro ضمن الوظيفة المصغّرة لإعداد تقارير اكتساب المشتري. وبعد ذلك، يمكن إضافة بيانات الأحداث داخل إطار الإعلان إلى أجهزة المرشد ووحدات الماكرو المسجَّلة باستخدام الدالتَين reportEvent وsetReportEventDataForAutomaticBeacons في واجهة برمجة التطبيقات Fenced Frame Ads Reporting API. ويسمح هذا الإجراء بربط إشارات الوظائف المصغّرة لإعداد تقارير Protected Audience وحمولة حدث إطار تصميم الإعلان معًا.

يُضاف عنوان HTTP Attribution-Reporting-Eligible إلى الطلب عند تشغيل الإشارات ووحدات الماكرو عند تشغيل طلب reportEvent من إطار، أو عند تفعيل الإشارات التلقائية من خلال المتصفح. يمكنك استخدام استجابة المرشد لتسجيل مصدر تحديد مصدر. قد تتم إعادة توجيه طلبات الإشارة للسماح بالقياس التابع لطرف ثالث.

لمزيد من التفاصيل، اطّلِع على قسم دعم إعداد تقارير تحديد المصدر في الشرح التوضيحي لواجهة برمجة التطبيقات Fenced Frame Ad Reporting API.

تفعيل إعداد تقارير الإحالة لأشكال نموذج عرض إعلانات فيديو (VAST)

VAST هو شكل شائع لعرض المساحة المتوفّرة لإعلانات الفيديو وقياسها، ويجب اعتبار العديد من الأحداث المحدّدة في هذا المعيار أحداث مصدر محتملة مؤهَّلة للتسجيل في Attribution Reporting API. يتناول ملحق نموذج عرض إعلانات الفيديو (VAST) لدعم إعداد تقارير الإحالة هذا الأمر بالتفصيل، ولكن باختصار، جميع أحداث <Tracking> و<Impression> و<*ClickThrough> و<*ClickTracking> هي أحداث محتملة لمصدر تحديد المصدر. يجب أن توفر جميع عمليات تنفيذ نموذج عرض إعلانات الفيديو (VAST) تغطية أهلية التسجيل لهذه الأحداث.

يحدّد ملحق نموذج عرض إعلانات الفيديو (VAST) سمات جديدة لهذه العناصر للسماح بإعداد عنوان URL ثانوي مخصّص لتسجيل تحديد المصدر. عندما يحتوي حدث على attributiontype="DOUBLE_PING" وattributionsrc="[URL]"، يجب أن يستخدم رمز تنشيط هذا الحدث [URL] كقيمة للسمة attributionsrc عند تفعيل Attribution Reporting API. يحتوي ملحق VAST على أمثلة لكل سيناريو.

ولضمان أقصى قدر من التغطية، يجب أن تجعل عمليات تنفيذ نموذج عرض إعلانات فيديو (VAST) جميع الأحداث المُدرجة مؤهَّلة للتسجيل تلقائيًا عند تنشيط إشعارات الأحداث. على سبيل المثال، عند تنشيط عنوان URL لحدث <Impression>، يجب استخدام السمة attributionsrc (الفارغة) على العنصر <img> المستخدَم لإرسال الطلب (أو ما يعادله في طلب الجلب)، وذلك للسماح دائمًا للجهة المستلِمة بتسجيل هذا الحدث باستخدام Attribution Reporting API.

الخطوة 2: تفعيل إعداد تقارير تحديد المصدر لمصادر تابعة لجهة خارجية

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

التعامل مع مصادر الجهات الخارجية في سلسلة إعادة توجيه حالية

في نسبة النقر إلى الظهور المعتادة على الإعلان، قد تتوفّر العديد من خدمات تتبُّع النقرات كسلسلة من عمليات إعادة التوجيه 302 التي يتم إجراؤها كجزء من عملية التنقّل إلى الصفحة المقصودة النهائية. يكون كل طلب في سلسلة إعادة التوجيه مؤهَّلاً للتسجيل باستخدام Attribution Reporting API إذا تمت إضافة تعليقات توضيحية إلى النقرة المستهدفة الأصلية باستخدام السمة attributionsrc أو إذا كان مسجّلاً باستخدام registerAdBeacon/registerAdMacro في Protected Audience API. يجب أيضًا تسجيل تقنية الإعلان في سلسلة إعادة التوجيه.

تجدر الإشارة إلى أنّ نص الطلب الأولي لا يتم إرساله في عمليات إعادة التوجيه. بالنسبة إلى مزادات "الجمهور المحمي"، إذا كان يجب تمرير eventData إلى reportEvent وsetReportEventDataForAutomaticBeacons كجزء من عملية إعادة التوجيه، يجب تمريره صراحةً كجزء من عنوان URL لإعادة التوجيه.

في المثال التالي، سنستخدم تقنية إعلان للعرض (serving-adtech.example) ومزوّد خدمة قياس تابع لطرف ثالث (3p-measurement.example) ككيانَين مختلفَين يسعان إلى إنشاء تقارير تحديد مصدر وتلقّيها. في هذا المثال، يمكن أن تكون تقنية عرض الإعلانات على نظام وسيط عرض الطلب (DSP) التي تعرض تصميم الإعلان على الموقع الإلكتروني للناشر، ولديه منتج إعداد التقارير الخاص به. يمكن أن يكون مقدّم خدمة القياس التابع لطرف ثالث كيانًا يستخدمه المعلِن لإعداد تقارير الإحالات الناجحة.

يشير هذا المصطلح إلى رسم تخطيطي يصف كيفية تسجيل الطرف الأول للمصدر ثم تسجيل الطرف الثالث

في وقت تسجيل المصدر، يتم تنفيذ الخطوات التالية:

  1. يضبط serving-adtech.example السمة attributionsrc في تصميم الإعلان. يزور المستخدم صفحة الناشر، ويرسل المتصفّح طلبًا إلى serving-adtech.example..
  2. يستجيب serving-adtech.example باستخدام العنوان Attribution-Reporting-Register-Source والرأس Location.
    1. يستخدم serving-adtech.example عنوان Attribution-Reporting-Register-Source للرد بالبيانات الوصفية حول المصدر المراد تسجيله.
    2. يستخدم serving-adtech.example عنوان Location لتضمين إعادة توجيه إلى 3p-measurement.example. يُرجى العلم أنّه من المحتمل أن يكون العنوان Location مستخدَمًا حاليًا في مسارات تتبُّع النقرات الحالية لإتاحة عمليات إعادة توجيه 302 إلى جهة خارجية.
  3. يتلقّى المتصفّح الاستجابة من serving-adtech.example ويحلّل عنوان Attribution-Reporting-Register-Source. يخزِّن المتصفّح الحدث المصدر، باستخدام serving-adtech.example كمصدر لإعداد التقارير.
  4. ولأنّ هذا الطلب عبارة عن إعادة توجيه، يقدّم المتصفّح أيضًا طلبًا جديدًا إلى 3p-measurement.example.
  5. يستجيب 3p-measurement.example باستجابة تحتوي على عنوان Attribution-Reporting-Register-Source.
  6. يتلقّى المتصفّح هذا الردّ من 3p-measurement.example ويقرأ Attribution-Reporting-Register-Source. يخزِّن المتصفّح الحدث المصدر، باستخدام 3p-measurement.example كمصدر لإعداد التقارير.

استخدام attributionsrc للمصادر التابعة لجهات خارجية والتي ليست في سلسلة إعادة توجيه

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

إعداداتك الحالية مع تعديل ARA
<a href="[CLICKTHROUGH_URL]">...</a> <a href="[CLICKTHROUGH_URL]" attributionsrc="[REPORTING_URL_1] [REPORTING_URL_2]"></a>

في هذا المثال، سيتم إرسال الطلبات المؤهَّلة لاستخدام Attribution Reporting API إلى كلٍّ من REPORTING_URL_1 وREPORTING_URL_2. إنّ طلب التنقّل المرسَل إلى عنوان URL للنقرة يكون مؤهّلاً أيضًا لتسجيل مصادر تحديد المصدر.

الخطوة 3: إعداد الردود لطلبات Attribution Reporting API

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

تسجيل مشغلات متعددة

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

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