إعداد تقارير الإحالة: نظرة عامة كاملة على النظام

نظرة عامة شاملة على الخدمات المرتبطة لإعداد تقارير تحديد المصدر، موجَّهة إلى صناع القرار الفني

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

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

المستخدمون المعنيّون بهذه المقالة

يجب قراءة هذه المقالة في الحالات التالية:

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

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

نظرة عامة

تتألّف Attribution Reporting API من عدة خدمات تتطلّب إعدادات محدّدة وعمليات ضبط من جهة العميل وعمليات نشر الخادم. لتحديد ما تحتاجه، أولاً:

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

هناك دائمًا مكونان (وفي بعض الأحيان ثلاثة) يعملان معًا لدعم إعداد التقارير:

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

إذا كنت قد جمعت تقارير تجميعية، ستحتاج إلى مكوّن ثالث:

• إنشاء تقرير الملخّص: تجميع التقارير المجمّعة واستخدام خدمة التجميع لمعالجة التقارير لإنشاء تقرير ملخص.

قرارات التصميم

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

يمكن أن يكون تقرير الإخراج:

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

تحدِّد التقارير التي اخترتها البيانات التي ستحتاج إلى جمعها.

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

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

الاتصال من الموقع الإلكتروني إلى المتصفح

ملاحظة: أثناء اختبار واجهة برمجة التطبيقات هذه، يجب أن يؤكّد الرمز البرمجي توفُّر واجهة برمجة التطبيقات وأن يتم ضبط سياسة الأذونات المناسبة.

تربط مصادر تحديد المصدر على الموقع الإلكتروني للناشر بعوامل التشغيل على الموقع الإلكتروني للمعلِن.

مسار حدث الإحالة

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

1. في الموقع الإلكتروني للناشر، يتم ضبط عنصر إعلان (علامة <a> أو <img>) باستخدام سمة خاصة attributionsrc. وتكون قيمته عنوان URL، على سبيل المثال https://adtech.example/register-source/ad_id=....

   في ما يلي مثال على رابط سيسجِّل مصدرًا بعد النقر عليه:

   <a href="https://shoes.example/landing" 
     attributionsrc="http://adtech.example/register-source?..."
     target="_blank">
   Click me</a>
   

   في ما يلي مثال على صورة تؤدي إلى تسجيل مصدر عند عرضها:

   <img href="https://advertiser.example/landing" 
     attributionsrc="https://adtech.example/register-source?..."/>
   

   بدلاً من عناصر HTML، يمكن استخدام استدعاءات JavaScript.

   إليك مثال على JavaScript باستخدام window.open(). يُرجى العِلم أنّه تم ترميز عنوان URL لتجنُّب المشاكل المتعلّقة بالرموز الخاصة.

   const encodedUrl = encodeURIComponent(
     'https://adtech.example/attribution_source?ad_id=...');
   window.open(
     "https://shoes.example/landing",
     "_blank",
     attributionsrc=${encodedUrl});
   

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

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

   

3. وبعد ذلك، يزور المستخدِم الموقع الإلكتروني للمعلن.

4. في كل صفحة ذات صلة على الموقع الإلكتروني للمعلِن، مثل صفحة تأكيد الشراء أو صفحة منتج، يتم إرسال طلب إلى https://adtech.example/conversion?param1=...&param2=... باستخدام وحدة بكسل الإحالة الناجحة (العنصر <img>) أو استدعاء JavaScript.

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

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

7. يجدول المتصفح تقريرًا لإرساله إلى attributionsrc. يتضمّن هذا التقرير ما يلي:

   1. بيانات إعدادات تحديد المصدر المخصّصة التي أرفقها مزوّد تقنية الإعلان أو المعلِن بالحدث المصدر في الخطوة 3
   2. مجموعة بيانات الإحالات الناجحة المخصّصة في الخطوة 6.

   

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

عوامل تشغيل تحديد المصدر (الموقع الإلكتروني للمعلِن)

مشغِّل الإحالة هو الحدث الذي يطلب من المتصفِّح تسجيل الإحالات الناجحة.

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

ويضمن ذلك أن تكون النتائج المجمّعة مفصّلة ودقيقة لهذه الأحداث.

مطابقة المصادر مع عوامل التشغيل

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

على سبيل المثال، عندما يتلقّى المتصفّح عامل تشغيل إحالة من adtech.example على shoes.example/shoes123، يبحث المتصفّح عن مصدر في مساحة التخزين المحلية يتطابق مع كلٍّ من adtech.example وshoes.example.

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

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

جمع البيانات

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

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

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

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

إنشاء تقرير الملخص

لإنشاء تقارير تلخيصية، عليك استخدام خدمة التجميع (التي تديرها تكنولوجيا الإعلان) لمعالجة التقارير المجمَّعة. تضيف خدمة التجميع تشويشًا لحماية خصوصية المستخدم وترجع تقرير الملخص النهائي.

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

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

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

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

يجب أن تحتوي الدفعات على العديد من التقارير لضمان ارتفاع نسبة الإشارة إلى التشويش.

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

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

خدمة التجميع

تكون خدمة التجميع مسؤولة عن معالجة التقارير القابلة للتجميع لإنشاء تقرير ملخّص. يتم تشفير التقارير المجمّعة ولا يمكن قراءتها إلا من خلال خدمة التجميع التي تعمل على بيئة تنفيذ موثوقة (TEE).

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

يمكن للممارسين إنشاء تقارير مجمّعة للنصوص الواضحة لاختبار خدمة التجميع محليًا. أو يمكنك الاختبار باستخدام التقارير المشفّرة على AWS باستخدام Nitro Enclaves.

ما هي الخطوات التالية؟

نريد المشاركة في محادثات معك للتأكد من أننا ننشئ واجهة برمجة تطبيقات تناسب الجميع.

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

على غرار واجهات برمجة التطبيقات الأخرى الخاصة بـ "مبادرة حماية الخصوصية"، يتم توثيق واجهة برمجة التطبيقات هذه ومناقشتها بشكل علني.

تجربة باستخدام واجهة برمجة التطبيقات

يمكنك التجربة والمشاركة في المحادثات حول Attribution Reporting API.