الجمهور المحمي: دليل الدمج

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

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

يتألف سير عمل دمج Protected Audience من 4 خطوات رئيسية تنفّذها أنواع مختلفة من شركاء تكنولوجيا الإعلان:

  1. يُنشئ المشتري شرائح جمهور مخصّصة.
  2. تختار عملية اختيار الإعلان إعلانًا فائزًا.
    1. يبدأ تطبيق البائع عملية اختيار الإعلان.
    2. تنفّذ الخدمات الإعلانية رمز الفلترة وعروض الأسعار من جهة الشراء.
    3. تنفّذ خدمات الإعلانات رمز اتّخاذ القرار من جهة البيع.
  3. يتم عرض الإعلان الفائز في تطبيق البائع.
  4. تتوفّر تقارير مرات ظهور الإعلانات لكلّ من المشتري والبائع.

يوضّح الرسم البياني التالي هذه الخطوات:

سير عمل إدارة شرائح الجمهور المخصّصة واختيار الإعلانات في Protected Audience
سير عمل إدارة شرائح الجمهور المخصّصة واختيار الإعلانات في Protected Audience API

المصطلحات

  • المعلِن: شركة تتفاعل مع المستخدمين من خلال شراء مساحة إعلانية.
  • الناشر: هو شركة تبيع مستودعًا إعلانيًا متاحًا بجانب المحتوى الذي تقدّمه.
  • المشتري: شركة تكنولوجيا إعلانية تسهّل على المعلِنين شراء المستودع الإعلاني.
  • البائع: شركة لتكنولوجيا الإعلان تسهّل على الناشرين بيع المساحات الإعلانية.
  • الشبكة: شركة لتكنولوجيا الإعلان تعمل كمشترٍ وبائع.
  • مملوكة ومُدارة: شركة تعمل كناشر وبائع ومشتري.
  • شركاء الدمج: أي شركات تحتاج إلى التعاون معها من أجل إجراء عملية دمج ناجحة مع Protected Audience.

المتطلبات الأساسية والتفاعل مع شريك التكامل والإعداد

يوضّح هذا القسم مجموعة من الأنشطة الأولية لمساعدتك في فهم طريقة عمل Protected Audience وكيفية بدء عملية الدمج مع Protected Audience وكيفية التفاعل مع شركاء الدمج بشأن تنفيذ Protected Audience. ويمكن أن تحدث هذه الأنشطة بالتوازي.

رسم بياني يعرض دليل طرح ميزات Protected Audience.
دليل طرح ميزات Protected Audience

التعرّف على Protected Audience

الخطوة الأولى هي التعرّف على واجهات Protected Audience API وخدماتها.

  1. ابدأ بقراءة اقتراح التصميم للتعرّف على Protected Audience API وإمكاناتها.
  2. اطّلِع على دليل المطوّرين لمعرفة كيفية دمج الرموز البرمجية وطلبات البيانات من واجهة برمجة التطبيقات التي تحتاج إليها لحالات الاستخدام، والخدمات اللازمة للتكامل مع Protected Audience.
  3. إرسال ملاحظات بشأن تصميم وتنفيذ واجهات برمجة التطبيقات والخدمات والمستندات الخاصة بـ Protected Audience API
  4. اشترِك لتلقّي الإشعارات لتبقى على اطّلاع على أحدث ميزات "مبادرة حماية الخصوصية".

إعداد تطبيقات نموذجية واختبارها

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

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

التفاعل مع شركاء التكامل

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

إعداد الإصدار التجريبي (متاح في الربع الرابع)

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

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

تتيح Protected Audience API للمشترين والبائعين إمكانية إجراء مزادات الإعلانات على الجهاز فقط. يجب أن تأخذ أنت وشركاؤك في الدمج عدة اعتبارات مهمة في تصاميمك، وهي:

يتم تخزين إعلانات تجديد النشاط التسويقي وشرائح الجمهور على الجهاز

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

تتم عمليات تقديم عروض الأسعار والمزاد على الجهاز

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

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

إستراتيجية البيانات

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

إنشاء الحلّ

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

المشترون: بناء قاعدة جماهيرية

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

إذا كانت لديك حزمة SDK خاصة بك في تطبيق المعلِن، يمكنك تنفيذ هذا الرمز مباشرةً باستخدام joinCustomAudience().

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

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

نموذج أوّلي لحملة تجديد النشاط التسويقي: تصميم شريحة جمهور مخصّصة

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

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

الإعداد والنموذج الأوّلي

اعتبارات التصميم

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

عنوان URL لمنطق عروض الأسعار

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

إشارات عروض أسعار المستخدمين

يمكن للمشترين استخدام UserBiddingSignals لنقل المعلومات التي يعرفها المعلِن أو المشتري نفسه عن المستخدم إلى المزادات المستقبلية على الجهاز. يمكن أن يشمل ذلك معلومات مثل:

  • شرائح الجمهور الأخرى التي تمت إضافة المستخدِم إليها
  • إحصاءات الطرف الأول التي يملكها المعلِن عن المستخدِم

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

  • رفع عروض الأسعار أو خفضها استنادًا إلى إشارات عروض الأسعار
  • فلترة إعلانات معيّنة من المزاد

بيانات عروض الأسعار الموثوق بها

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

يتكوّن الحقل TrustedBiddingData من عنوان URL ومجموعة من المفاتيح. في ما يلي بعض الاعتبارات عند تصميم نوع بنية المفتاح التي سيتم استخدامها:

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

قائمة AdData

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

ويعود للمشترين تحديد مقدار المعلومات التي سيتم تضمينها في كل إعلان. إليك بعض النقاط التي يجب أخذها في الاعتبار:

  • يمكن تعديل قائمة AdData بطريقتَين:
    • عندما يكون للتطبيق نشاط مرئي في المقدّمة، يمكنه بدء القائمة عند إضافة مستخدم إلى شريحة جمهور مخصّصة.
    • أثناء التعديل اليومي، يتم بدء عملية الجلب في الخلفية. يرسل الجهاز طلبًا إلى daily_update_url المضمّن في طلب joinCustomAudience ويتوقّع تلقّي ردّ يتضمّن قائمة AdData معدَّلة.
  • يمكن طلب معلومات إضافية عن الإعلانات في وقت المزاد. قبل المزاد، يرسل الجهاز طلبًا إلى خدمة قيم المفاتيح الخاصة بالمشترين والتي تم توفيرها في الحقل trustedBiddingData من joinCustomAudience. خدمة القيم الرئيسية هي خدمة جديدة تشكّل جزءًا من عملية تنفيذ Protected Audience من جانب المشترين. سيتم توضيح المزيد من التفاصيل حول هذه الخدمة لاحقًا في هذا المستند.
  • يمكن أن يساعدك تضمين معرّف تصميم لإعلانك في اتّخاذ إجراءات معيّنة بشأن تصاميم محدّدة. على سبيل المثال، قد يوقف المعلنون تصاميم إعلانات معيّنة مؤقتًا، وتريد أنت استرداد معرّفات تصاميم الإعلانات هذه من خدمة المفتاح والقيمة في الوقت الفعلي، ثم مطابقتها مع الإعلانات في قائمة AdData.

يجب أن يتضمّن AdData render_url. يتم استخدام عنوان URL للعرض الخاص بإعلان تجديد النشاط التسويقي الفائز من أجل عرض الإعلان. تشمل بعض الاعتبارات ما يلي:

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

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

وقت التفعيل ووقت انتهاء الصلاحية

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

  • المستخدم غير النشط (مثل المستخدم الذي لم يتفاعل مع تطبيق المعلِن في آخر 7 أيام)
    • في كل مرة يفتح فيها المستخدم التطبيق، يمكن للمشتري طلب joinCustomAudience وتحديد activation_time ليكون طابعًا زمنيًا بعد 7 أيام.
    • تكون شريحة الجمهور مؤهَّلة لتقديم عروض الأسعار إذا مرّت 7 أيام منذ أن فتح المستخدم التطبيق آخر مرة.
  • شريحة الجمهور الموسمية (شريحة جمهور صالحة خلال فترة زمنية محدّدة في المستقبل القريب فقط)
    • يمكن للمشتري البدء في تحديد شرائح الجمهور المخصّصة مسبقًا، والتي يجب أن تكون مؤهَّلة لتقديم عروض الأسعار خلال فترة زمنية محدّدة مسبقًا في المستقبل (القريب).
    • على سبيل المثال، إذا كان أحد المعلِنين لديه حملة لنهاية الصيف في الولايات المتحدة في عام 2022، يمكن للمشتري الاتصال بـ joinCustomAudience وتحديد activation_time ليكون يوم السبت 20 آب (أغسطس) 2022. إذا كانت الحملة لا تعمل إلا لمدة أسبوع واحد، يمكن للمشتري ضبط تاريخ انتهاء الصلاحية على 27 أغسطس 2022، وبعد ذلك ستستبعد المنصة شريحة الجمهور المخصّصة أثناء اختيار الإعلان، وسيتم في النهاية جمع البيانات غير الصالحة.

المشترون والبائعون: اختيار الإعلانات

يتطلّب اختيار الإعلانات التعاون بين المشترين والبائعين. ويمكن اعتبار ذلك عملية من أربع خطوات:

  1. يحدّد البائعون استراتيجية توسّط.
  2. يُعدّ البائعون المزاد ويبدأون عملية اختيار الإعلانات.
  3. تتم دعوة المشترين للمشاركة في المزاد باستخدام الإعدادات التي يحدّدها البائع. يتم تنفيذ منطق عروض الأسعار الخاص بالمشتري لاختيار إعلان مرشّح وعرض سعر.
  4. يتم تنفيذ منطق قرار البائع لتقييم الإعلانات المرشّحة واختيار الإعلان الفائز.

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

البائعون: تحديد استراتيجية التوسّط

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

البائعون: ضبط إعدادات المزاد

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

الإعداد والنموذج الأوّلي

  • يمكن للبائع إعداد مزاد وبدءه من خلال إعداد عنصر AdSelectionConfig واستخدام واجهة برمجة التطبيقات AdSelection. ابدأ المزاد عن طريق استدعاء selectAds().
  • يُرجى الاطّلاع على دليل المطوّرين لمعرفة تفاصيل التنفيذ واستخدام واجهة برمجة التطبيقات.

اعتبارات التصميم

يتضمّن هذا القسم اعتبارات التصميم الخاصة بملء الحقول الرئيسية واستخدامها في إعدادات اختيار الإعلانات.

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

  • قبل بدء سير عمل اختيار الإعلان، أرسِل طلب إعلان لجمع المعلومات من المشترين. بعد ذلك، استخدِم هذه المعلومات لإعداد عملية اختيار الإعلانات.

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

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

  • يمكن للبائع إدخال المعلومات في العملية بعدّة طرق:

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

المشترون: تقديم عروض أسعار لشريحة إعلانية

الإعداد والنموذج الأوّلي

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

اعتبارات التصميم

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

تصميم منطق عروض الأسعار

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

بيانات عروض أسعار المساحات الإعلانية

إشارات عروض الأسعار في الوقت الفعلي مع خدمات المفتاح والقيمة

بصفتك مشتريًا، يمكنك استرداد الإشارات في الوقت الفعلي أثناء المزاد من خدمة تستخدم مفتاحًا وقيمة وتملكها. يمكنك العثور على عملية تنفيذ أولية لهذه الخدمة في مستودع Privacy Sandbox العام، أو يمكنك إنشاء خدمة خاصة بك. يتم تحديد عنوان URL لهذه الخدمة على أنّه trustedBiddingUrl في شريحة جمهور مخصّصة، وتحاول المنصة جلب البيانات وإتاحتها لوظيفة generateBid باستخدام trusted_bidding_signals parameter. عليك إنشاء بنية مفاتيح خاصة بك.

إشارات السياق والمستخدم

تتمكّن الدالة generateBid من الوصول إلى إشارات مستخدم إضافية عند إجراء المزاد على الجهاز. يتم تمرير هذه الإشارات باستخدام الحقلَين contextual_signals وper_buyer_signals. جميع هذه الحقول هي عناصر JSON يجب أن يحدّد المشترون والبائعون تنسيقها.

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

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

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

البائعون: تسجيل نقاط الإعلان الفائز واختياره

الإعداد والنموذج الأوّلي

  • يمكن للبائع إضافة منطق التسجيل إلى دالة JavaScript scoreAd() التي يتم عرضها من خلال مجموعة المَعلمات scoringLogicUrl عند إنشاء AdSelectionConfig. يمكنك إعداد خدمة وهمية باستخدام المواصفات المقدَّمة، أو تنفيذ نقطة النهاية هذه على خادم حقيقي.
  • يُرجى الاطّلاع على دليل المطوّرين لمعرفة تفاصيل التنفيذ واستخدام واجهة برمجة التطبيقات.

تصميم منطق تسجيل النقاط

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

بيانات تسجيل الأداء الخاصة بمساحة العرض

إشارات تسجيل النقاط في الوقت الفعلي باستخدام خدمات المفتاح والقيمة

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

إشارات السياق والمستخدم

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

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

البائعون: عرض إعلان

على البائعين عرض الإعلان الفائز. راجِع اقتراح التصميم للاطّلاع على تفاصيل إضافية حول كيفية عرض الإعلانات الفائزة. لا تزال هذه المنطقة قيد التصميم.

الإبلاغ عن نتائج مرات الظهور

الإعداد والنموذج الأوّلي

  • يمكن للمشترين والبائعين إضافة منطق إعداد التقارير إلى دالة reportWin() JavaScript التي يتم عرضها من المَعلمة biddingLogicUrl أو scoringLogicUrl على التوالي. يمكنك إعداد خدمة وهمية باستخدام المواصفات المقدَّمة، أو تنفيذ نقطة النهاية هذه على خادم حقيقي.
  • يُرجى الاطّلاع على دليل المطوّرين لمعرفة تفاصيل التنفيذ واستخدام واجهة برمجة التطبيقات.

اعتبارات التصميم

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

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