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

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

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

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

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

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

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

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

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

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

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

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

حدث	العلامة	الإعداد الحالي	بعد دمج 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);

تفعيل تسجيل مصدر تحديد المصدر في مزاد Protected Audience API

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

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

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

ملاحظة: تتوفّر واجهة Fenced Frame Ads Reporting API في كلّ من إطار iframe وإطار محاط بحدود.

للحصول على معلومات أكثر تفصيلاً، اطّلِع على قسم Support for Attribution Reporting (دعم إعداد تقارير تحديد المصدر) في الفيديو التوضيحي حول واجهة برمجة التطبيقات Ad 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. يجب أيضًا تسجيل تكنولوجيا الإعلان في سلسلة إعادة التوجيه.

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

تحذير: يتم إرسال هذه الطلبات فقط على المتصفّحات المتوافقة مع Attribution Reporting API، وقد يتم فقدان الطلبات في البيئات غير المتوافقة.

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

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

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

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

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