خدمات عروض الأسعار والمزادات

bookmark_border تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

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

يوضّح اقتراح خدمات عروض الأسعار والمزادات (B&A) طريقة للسماح بإجراء عملية حساب "شرائح الجمهور المحمية" على خوادم السحابة الإلكترونية في بيئة تنفيذ موثوق بها (TEE)، بدلاً من تشغيلها محليًا على جهاز المستخدم. يهدف اقتراح B&A إلى توفير مسار مُوحَّد لأخذ طلب الإعلانات السياقية و الإعلانات لإعادة التسويق في الاعتبار. يمكن أن يساعد نقل العمليات الحسابية إلى الخوادم في تحسين ملف bidding الجمهور المحمي من خلال تحرير دورات الحساب وملف النطاق الترددي للشبكة على أحد الأجهزة.

ستوفّر Google مكوّنات B&A، وسيتم توفيرها كبرامج مفتوحة المصدر. يمكن لمزوّدي تقنية الإعلان المهتمين استضافة نُسخهم الخاصة باستخدام مزوّدي خدمات السحابة العامة المتوافقين. يمكنك الاطّلاع على مزيد من المعلومات حول اقتراح B&A على GitHub. تجدر الإشارة إلى أنّ التواريخ الواردة في هذا المستند تشير إلى موعد التنفيذ في Chrome، وسننشر المزيد من المعلومات عن دمج الميزة مع Android في المستقبل. يقدّم هذا المستند مقدمةً عن واجهة برمجة التطبيقات لتجربة المستخدم والتفاعل (B&A) وواجهات برمجة التطبيقات الجديدة التي سيوفّرها نظام التشغيل Android للتفاعل مع واجهة B&A. سننشر في التحديثات المستقبلية مزيدًا من المعلومات الفنية حول كيفية استخدام واجهات برمجة التطبيقات الجديدة هذه.

مكان خدمات B&A

توفّر تقنية B&A خيارًا إضافيًا لإجراء مزاد داخل الخوادم الموثوق بها المملوكة لتكنولوجيا الإعلان التي تعمل على ملف ثنائي مفتوح المصدر تقدّمه Google. ستظل بيانات المستخدمين مخزّنة على الجهاز، وستوفّر Google واجهات برمجة تطبيقات لنقل تلك data بأمان إلى وحدة TEE. يمكنك الاطّلاع على المزيد من المعلومات حول استراتيجية التشفير أدناه.

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

يكمن الاختلاف الرئيسي في مكان تنفيذ منطق إنشاء عناوين URL لعروض الأسعار والتقييم وإعداد التقارير. بدلاً من تنفيذ منطق عروض الأسعار والمزادات وإعداد التقارير على الجهاز، يتم تنفيذ منطق generateBid() وscoreAd() وreportResult() و reportWin() في وحدة TEE. يتم تنفيذ منطق عروض أسعار المشتري ومنطق تسجيل نقاط البائع في بيئة B&A الخاصة بهما، في منتصف مسار مزاد الجمهور المحمي:

تشفير البيانات

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

خطوات إنشاء مزاد

يتضمن هذا الاقتراح الحاجة إلى العديد من المكوّنات الجديدة الموضّحة بالتفصيل على GitHub، بما في ذلك تدفق البيانات من الجهاز إلى B&A.

على مستوى عالٍ، يتم وصف تدفق البيانات على النحو التالي:

1. على الجهاز، يجمع البائعون معلومات من Protected Audience باستخدام واجهة برمجة التطبيقات getAdSelectionData.
2. تُرسِل حزمة SDK على الجهاز طلبًا إلى خدمات إعلانات البائعين. يتضمّن هذا الطلب الحمولة السياقية وProtectedAudienceInput المشفَّرة.
3. تُرسِل خدمة "إعلانات البائع" طلبًا إلى خدمة عروض الأسعار في الوقت الفعلي (RTB) للمشتريِين التي تعمل خارج بيئة التشغيل المخصّصة للثقة (TEE) للحصول على إعلانات سياقية مرشّحة، ثم تُحسِّن الأداء وتختار إعلانًا سياقيًا فائِزًا.
4. تُرسِل خدمة "إعلانات البائع" طلبًا إلى SellerFrontEnd service التي تعمل في بيئة التشغيل المُعزّزة للثقة.
5. تُرسِل خدمة SellerFrontEnd طلبات تتضمّن بيانات خاصة بالمشتري إلى خدمات BuyerFrontEnd.
6. يستخدم المشترون خدمة المفتاح/القيمة وخدمة عروض الأسعار الخاصة بهما، ما يؤدي إلى إنشاء عروض أسعار للإعلانات المُحتمَلة التي يتم الحصول عليها من الجهاز لجميع شرائح الجمهور المخصّصة التي يتمّ أخذها في الاعتبار لتجديد النشاط التسويقي.
7. تقرأ خدمة SellerFrontEnd من خدمة Key/Value وتُحسِّن الإعلانات المُرشّحة. ويتم تشفير النتيجة وإعادتها إلى خدمة "إعلانات البائع".
8. تعرض خدمة "إعلانات البائع" النتيجة الفائزة المشفّرة، ونتيجة سياقية اختيارية، إلى حزمة تطوير البرامج (SDK) على الجهاز.
9. على الجهاز، يستردّ البائعون الإعلان الفائز باستخدام واجهة برمجة التطبيقات processAdSelectionResult API، التي تفكّ تشفير الاستجابة الواردة من خدمة إعلانات البائعين.

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

النشر في السحابة الإلكترونية

ستنشر تكنولوجيات الإعلان خدمات B&A على منصّة سحابة علنية متوافقة. ستتم إدارة عمليات النشر هذه من قِبل خبراء التكنولوجيا الإعلانية الذين سيكونون مسؤولين عن تحديد هدف مستوى الخدمة الخاص بمدى التوفّر.

إجراء مزاد

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

AdSelectionData getAdSelectionData(AdTechIdentifier seller)

تُنشئ طريقة getAdSelectionData الإدخال المطلوب لمكوّنات B&A، مثل BuyerInput و ProtectedAudienceInput، وتشفّر البيانات قبل إتاحة النتيجة للمتصل. لمنع تسرُّب البيانات على مستوى التطبيقات، تحتوي هذه البيانات على معلومات من جميع المشترين على الجهاز. يمكنك الاطّلاع على مزيد من المعلومات حول هذا القرار في قسم الاعتبارات المتعلّقة بالخصوصية.

تعرض واجهة برمجة التطبيقات هذه عنصر AdSelectionData:

class AdSelectionData {
  long adSelectionId // Unique identifier for the auction.
  byte[] data // Encrypted bytes containing data sourced from
              // on device custom audiences; will
              // be used as the payload to B&A.
}

باستخدام هذا AdSelectionData، يمكن لحزمة SDK على الجهاز إرسال طلب إلى خدمة إعلانات البائع من خلال تضمين البيانات في طلب POST أو PUT:

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
…
})

تتحمّل حزمة SDK على الجهاز مسؤولية ترميز هذه البيانات. ننصحك باستخدام حلّ يُوفّر مساحة، مثل إرسال الطلب إلى خدمة إعلانات البائعين على النحو التالي: multipart/form-data.

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

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

PersistAdSelectionResultRequest {
  AdSelectionId id // Same ID returned from initial getAdSelectionData call.
  AdTechIdentifier seller // Used for enrollment checks.
  byte[] adSelectionionResult // The result of the network call to Seller Ad
                              // service/B&A.
}

persistAdSelectionResult(persistAdSelectionResultRequest);

إعداد التقارير

سيتمّ إنشاء عناوين URL لإعداد التقارير في خدمات B&A. سيظلّ من الضروري بدء إرسال طلبات إلى عناوين URL هذه لتسجيل مرات الظهور والتفاعلات في المزادات على الجهاز. سيظلّ على حزمة تطوير البرامج (SDK) المثبّتة على الجهاز استدعاء واجهات برمجة التطبيقات reportImpression() وreportInteraction() باستخدام AdSelectionId الذي تم إنشاؤه أثناء عملية الربط والتحليل. العلامات التي تم إنشاؤها لتسجيل التفاعلات وعناوين URL المقابلة لها مضمّنة في الاستجابة المشفّرة، لذلك يتم تخزين الأحداث وعمليات ربط عناوين URL على الجهاز أثناء فك تشفير الاستجابة.

اعتبارات الخصوصية

يوضّح اقتراح Browser Bidding & Auction API على GitHub الاعتبارات المتعلّقة بالخصوصية التي تم أخذها في الاعتبار. يستخدم هذا الاقتراح مصطلحات Chrome، ولكن تنطبق المبادئ نفسها على Android.

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

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

اعتبارات حول الحجم

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

1. إضافة ad_render_id في CustomAudience لإرساله باستخدام adSelectionData بدلاً من استخدام عنوان URL لعرض الإعلان والبيانات الوصفية يمكن لتكنولوجيات الإعلان تحسين ذلك بشكلٍ أكبر من خلال عدم إرسال بيانات الإعلانات في adSelectionData. سيكون هذا الخيار متاحًا في CustomAudience API في الإصدارات المستقبلية.
2. تأكَّد من عدم إرسال user_bidding_signals في adSelectionData. بدلاً من ذلك، يمكن لتكنولوجيات الإعلان retrievinguser_bidding_signals من خادم "المفتاح/القيمة".
3. اسمح للمشترين بتحديد أولوية CustomAudience.
4. السماح للمشتري بتحديد أولوية البائع
5. أنشئ adSelectionData في بضعة حِزم ثابتة للحدّ من تسرُّب الوحدات أثناء تقليل حجم الحمولة.

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

اعتبارات مكافحة إساءة الاستخدام

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

ويؤدي ذلك إلى فتح المنظومة المتكاملة أمام كيانات ضارة محتملة يمكنها إضافة بيانات مشكوك فيها للمشترين قد تؤدي إلى خفض الأداء وتضخيم الأحمال لزيادة التكاليف وما إلى ذلك.

لمكافحة إساءة استخدام adSelectionData، سنطبّق الإجراءات التالية:

• السماح CustomAudience بتحديد البائعين المعتمَدين وترتيبهم بوضوح
• السماح لخدمات عرض الإعلانات على الشبكات (SSP) بتحديد المشتري وأولوية المشتري والحصة لكل مشترٍ بشكل صريح في ملف التحميل الذي تم إنشاؤه
• توفير آلية لخدمات عرض الإعلانات (SSP) لتحديد الحد الأقصى لعدد المشترين لكلّ طلب أو الحدّ الأقصى للحجم لكلّ مشترٍ

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

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