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

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

يوضح اقتراح خدمات عروض الأسعار والمزادات طريقة للسماح إجراء عمليات الحوسبة الحاسوبية المحمية على السحابة الإلكترونية في بيئة (TEE) بدلاً من التشغيل محليًا على جهاز المستخدم. تشير رسالة الأشكال البيانية يهدف اقتراح B&A إلى دعم تدفق موحّد للنظر في السياق طلب إعلان تجديد النشاط التسويقي. يمكن أن يساعد نقل الحساب إلى الخوادم في تحسين مزاد يستخدم Protected Audience API من خلال توفير دورات الحوسبة والشبكة معدل نقل البيانات للجهاز.

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

الخدمات المناسبة التي تقدّم خدمات المبيت والإفطار

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

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

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

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

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

البنية وتدفق المزاد

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

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

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

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

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

ستنشر شركات تكنولوجيا الإعلان خدمات 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 في بيئة التنفيذ الموثوقة (TEE). عند تهيئة SellerFrontEnd الخدمة، سيقدم البائعون قائمة بعناوين النطاقات التي مع خدمات purchaseFrontEnd التي يديرها المشترون لديها شراكة مع. سيتم توحيد الطلبات لدى مختلف مشتري الواجهة الأمامية والخدمات التي قدّمها البائع، حتى يتمكن المشترون من إنشاء عروض أسعار لمرشحي الإعلانات الذين يختارونهم. بالنسبة إلى مشترٍ محدّد، سترسل 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 تم إنشاؤه أثناء عملية B&A. الإشارات التي تم إنشاؤها لـ أن يتم تضمين التقارير التفاعلية وعناوين URL المقابلة في استجابة مشفرة، أي أنه أثناء فك تشفير الرد، تنتقل الأحداث وعناوين URL يتم تخزين التعيينات على الجهاز.

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

تعمل عروض الأسعار في المتصفّح يوضّح اقتراح 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 بدلاً من استخدام البيانات الوصفية ومعرّف الموارد المنتظم (URI) لعرض الإعلان يمكن لتقنيات الإعلان يتم إجراء مزيد من التحسين من خلال عدم إرسال بيانات الإعلانات في adSelectionData. هذا الخيار سيتوفّر في CustomAudience API في الإصدارات المستقبلية.
2. تأكَّد من عدم إرسال user_bidding_signals بلغة adSelectionData. بدلاً من ذلك، يستخدم الإعلان بإمكان التكنولوجيات جلب user_bidding_signals من خادم المفتاح/القيمة.
3. السماح للمشترين بإعطاء الأولوية لـ CustomAudience.
4. السماح للمشتري بتحديد أولوية البائع.
5. يمكنك إنشاء adSelectionData في بضع حِزم ثابتة للحدّ من تسرُّب وحدات البيانات أثناء تقليل حجم حمولة البيانات.

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

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

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

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

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

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

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

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