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

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

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

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

موقع خدمات B&A

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

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

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

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

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

بنية المزاد وسير عمله

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

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

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

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

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

ستنشر تكنولوجيات الإعلان خدمات 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.

بعد بدء الطلب، تحوّل خدمة Seller Ad الطلب إلى خدمة SellerFrontEnd التي تعمل في بيئة تنفيذ موثوقة (TEE). عند إعداد خدمة 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. سيظل من الضروري إرسال طلبات ping إلى عناوين 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 بتحديد البائعين المعتمَدين وأولوية البائع بشكل صريح
• السماح لمنصّات العرض من جهة الخادم بتحديد المشتري وأولوية المشتري والحصة المخصّصة لكل مشترٍ بشكل صريح في الحمولة التي يتم إنشاؤها
• توفير آلية تتيح لمنصّات العرض من جهة الخادم تحديد الحدّ الأقصى لعدد المشترين لكل طلب أو الحدّ الأقصى للحجم لكل مشترٍ

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

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