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

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

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

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

الأماكن التي تتلاءم فيها خدمات B&A

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

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

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

مسار مزاد "الجمهور المحمي"

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

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

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

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

تدفق موحّد لمزاد الجمهور المحمي المستندة إلى السياق، مع خدمات عروض الأسعار والمزادات

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

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

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

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

ستنشر تكنولوجيا الإعلان خدمات 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، سيقدم البائعون قائمة بعناوين النطاقات التي تتوافق مع خدمات buyFrontEnd التي يديرها المشترون الذين عقدوا شراكة معهم. سيتم توحيد الطلبات مع خدمات BuyFrontEnd المختلفة التي قدّمها البائع حتى يتمكن المشترين من إنشاء عروض أسعار لمرشحي الإعلانات المحددين. بالنسبة إلى مشترٍ معيّن، لن ترسل 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 على الجهاز أثناء فك تشفير الاستجابة.

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

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

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