تقرير ربع سنوي للربع الأول من عام 2024 يلخّص الملاحظات التي وردت من المنظومة المتكاملة بشأن اقتراحات "مبادرة حماية الخصوصية" وردّ Chrome عليها.
كجزء من التزاماتها بموجب "قانون معالجة المعاملات"، وافقت Google على تقديم تقارير ربع سنوية علانية عن عملية تفاعل الجهات المعنية باقتراحات "مبادرة حماية الخصوصية" (يُرجى الرجوع إلى الفقرتين 12 و17(ج)(2) من الالتزامات). يتم إنشاء تقارير الملخّصات هذه حول الملاحظات والآراء بشأن "مبادرة حماية الخصوصية" من خلال تجميع الملاحظات والآراء التي تلقّاها Chrome من المصادر المختلفة كما هو موضّح في نظرة عامة على الملاحظات والآراء، بما في ذلك على سبيل المثال لا الحصر: GitHub المشاكل، ونموذج الملاحظات والآراء المتاح على privacysandbox.com، والاجتماعات مع الجهات المعنية في المجال، ومنتديات معايير الويب. يرحّب فريق Chrome بالملاحظات التي يتم تلقّيها من المنظومة المتكاملة ويستكشف بنشاط طرق دمج الدروس المستفادة في قرارات التصميم.
يتم ترتيب مواضيع الملاحظات حسب معدّل تكرارها لكل واجهة برمجة تطبيقات. ويتم ذلك من خلال جمع ملاحظات فريق Chrome حول موضوع معيّن وتنظيمها بترتيب تنازلي حسب الكمية. تم تحديد مواضيع الملاحظات المشترَكة من خلال مراجعة مواضيع المناقشة من الاجتماعات العامة (W3C وPatCG وIETF) والملاحظات المباشرة وGitHub والأسئلة الشائعة التي تظهر من خلال الفِرق الداخلية في Google والنماذج العامة.
وعلى وجه التحديد، تمت مراجعة محاضر اجتماعات الهيئات المسؤولة عن معايير الويب، وبالنسبة إلى الملاحظات المباشرة، تمّت مراجعة سجلّات Google لاجتماعات الجهات المعنيّة وجهًا لوجه، والرسائل الإلكترونية التي تلقّاها المهندسون الفرديون، وقائمة البريد الإلكتروني لواجهات برمجة التطبيقات، ونموذج الملاحظات العلني. بعد ذلك، نسّقت Google بين الفِرق المشاركة في أنشطة التواصل المختلفة هذه لتحديد مدى رواج المواضيع التي تظهر في ما يتعلّق بكل واجهة برمجة تطبيقات.
تم تطوير تفسيرات ردود Chrome على الملاحظات من خلال عناوين الأسئلة الشائعة والمنشورة، والردود الفعلية التي تم تقديمها على المشاكل التي طرحها أصحاب المصالح، وتحديد وجهة نظر خاصة لأغراض هذا التمرين الخاص بإعداد التقارير العلنية. استنادًا إلى التركيز الحالي على التطوير والاختبار، تلقّينا أسئلة وملاحظات خاصةً بشأن واجهات برمجة التطبيقات Topics API وProtected Audience API وAttribution Reporting API.
قد لا يتم النظر في الملاحظات التي يتم تلقّيها بعد انتهاء فترة إعداد التقارير الحالية.
مسرد الاختصارات
- ARA
- Attribution Reporting API
- ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة (CHIPS)
- ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة
- معالِج الإشارات الرقمية (DSP)
- وسيط عرض الطلب
- FedCM
- إدارة بيانات الاعتماد الموحّدة
- عدد اللقطات في الثانية
- مجموعات نطاقات الطرف الأول
- مكتب الإعلانات التفاعلية (IAB)
- Interactive Advertising Bureau
- IDP
- موفِّر الهوية
- مجموعة مهندسي شبكة الإنترنت (IETF)
- مجموعة مهندسي شبكة الإنترنت
- عنوان IP
- عنوان بروتوكول الإنترنت
- openRTB
- عرض الأسعار في الوقت الفعلي
- الوقت بدل الضائع
- فترة التجربة في Origin
- PAT API
- Protected Audience API (المعروفة سابقًا باسم FLEDGE)
- PatCG
- مجموعة منتدى تكنولوجيا الإعلانات الخاصة
- RP
- جهة الاعتماد
- RWS
- مجموعات المواقع الإلكترونية المرتبطة (المعروفة سابقًا باسم "مجموعات نطاقات الطرف الأول")
- SSP
- وسيط عرض إعلانات المورّدين
- بيئة تنفيذ موثوقة (TEE)
- بيئة التنفيذ الموثوقة
- UA
- سلسلة وكيل المستخدم
- UA-CH
- تعديلات برنامج وكيل المستخدم
- W3C
- اتحاد شبكة الويب العالمية
- WIPB
- إخفاء عناوين IP عن قصد
ملاحظات عامة، ما مِن واجهة برمجة تطبيقات أو تقنية محدّدة
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| ميزة الإدارة | الاهتمام بفترة تعليقات عامة بشأن أي تعديلات على سياسة إدارة "مبادرة حماية الخصوصية" | نحن منفتحون على ملاحظات الجهات المعنية المعقولة بشأن أي تطورات مهمة بشأن "مبادرة حماية الخصوصية"، بما في ذلك الحوكمة المستقبلية لـ "مبادرة حماية الخصوصية". |
| الاختبار | مراحل اختبار إضافية لميزة "البحث على شبكة البحث 360" بالإضافة إلى الاختبار الحالي الذي يجريه% 1 من المستخدمين باستخدام Chrome | لا ننوي توفير ميزة الاختبار المُيسّر من خلال Chrome لأكثر من % 1 من زيارات Chrome الحالية التي تم تفعيلها منذ أوائل كانون الثاني (يناير). |
| Web to App | يجب عدم استخدام ميزة "الدفع بدون تلامس" على الأجهزة الجوّالة قبل تحقيق التشغيل التفاعلي الكامل بين الويب والتطبيق. | نوافق على أنّه من المستحسن إتاحة إمكانية التشغيل التفاعلي بين التطبيقات والويب، وقد أطلقنا قياس تحديد المصدر على مستوى التطبيقات والويب، ونستكشف حلول استهداف الويب إلى التطبيق. ومع ذلك، لا ننوي تأخير طرح ميزة "الإعلانات الديناميكية على شبكة البحث" على الويب المتوافق مع الأجهزة الجوّالة. ليس لدينا هدف بتغطية بنسبة% 100 في نهاية فترة 3PCD. بدلاً من ذلك، نتوقّع أن يكون التوافق على Android لقياس الأداء على مستوى التطبيقات والويب مرتفعًا بشكل معقول عند 3PCD وأن يزداد بمرور الوقت عندما يُجري المستخدمون تحديثات لهواتفهم. |
| دور المتصفّح | يبدو أنّ Chrome يتولّى دور خادم إعلانات أو منصّة عرض إعلانات. | لا يتولّى Chrome دور خادم إعلانات أو منصّة عرض إعلانات. من خلال PA API، يقدّم Chrome حاوية لخوادم الإعلانات وأنظمة عرض الإعلانات وأنظمة إدارة الطلبات وتكنولوجيا الإعلان الأخرى لتوفير منطق عروض الأسعار وعمليات التقييم الخاصة بها. |
| إرشادات حول حالات الاستخدام | إرشادات أكثر وضوحًا حول حالات الاستخدام التي ستتيحها واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" | في بداية مشروع "مبادرة حماية الخصوصية"، كانت وثائق المطوّرين تركّز في المقام الأول على إشراك المطوّرين في عمليات المناقشة وتقديم الملاحظات بشأن جميع الاقتراحات. وهذا يعني أنّ المحتوى كان منظَّمًا بشكل عام حول فهم الدوافع والمفاهيم التي تستند إليها المشاريع، متبوعًا بتفاصيل التطوير المبكر وتفاصيل الاختبار لكلّ اقتراح. وقد كان ذلك فعّالاً في بناء تعاون حقيقي في المنظومة المتكاملة لتطوير الاقتراحات، ولكن مع تقدّم واجهات برمجة التطبيقات إلى مدى التوفّر العام، أصبح هناك جمهور جديد من المطوّرين الذين يستخدمون هذه الواجهات بشكل أساسي بدلاً من المساهمة في تطويرها الأساسي. لقد عدّلنا مؤخرًا تنقّل موقع "مبادرة حماية الخصوصية" للمطوّرين ليصبح يركّز على حالات الاستخدام، باستخدام تصنيفات مشابهة لتلك التي استخدمتها مجموعة عمل "مبادرة حماية الخصوصية" في تقريرها الأخير الصادر عن IAB Tech Lab. سنواصل استخدام هذا الأسلوب المستنِد إلى حالات الاستخدام في إعداد المستندات. |
| بيئة التطوير المحلية | كيف يمكننا مواصلة تطوير الواجهة الأمامية واختبارها محليًا على http://localhost عندما يكون ملف تعريف الارتباط هو SameSite=Secure ويكون الجزء الخلفي من الواجهة معروضًا من خلال شبكة توصيل المحتوى (CDN)؟ | نحن نناقش هذه المشكلة هنا ونرحّب بملاحظات إضافية من المنظومة المتكاملة. |
| الحدّ من تأثير 3PCD | هل هناك طريقة آلية لمعرفة ما إذا تم حظر ملفات تعريف الارتباط التابعة لجهات خارجية أو عندما تكون الأساليب الاستقرائية نشطة؟ | في Chrome، يسمح كلّ من ميزة رصد الميزات و document.hasStorageAccess التي يتمّ استدعاؤها في إطار iframe للمطوّر بمعرفة ما إذا كان المنشأ في إطار iframe يمكنه الوصول إلى ملفات تعريف الارتباط التابعة لجهات خارجية. |
| اختبار الفيديو | لا يمكن حاليًا اختبار إعلانات الفيديو في "مبادرة حماية الخصوصية". | نشر فريق Chrome مناقشة وتوضيحًا لعدة طرق محتملة يمكن من خلالها إنشاء فيديو باستخدام PA API اليوم (راجِع 242 و 254 في مستودع العروض التوضيحية على GitHub). يُرجى العِلم أنّ هذه النماذج ليست مخصّصة لتكون نموذجًا للرمز البرمجي الذي ستعتمده تقنيات الإعلان بشكل كامل، بل هي نموذج لإثبات المفهوم وعرض التقنيات التي يمكن أن توفّر إمكانية عرض الفيديوهات باستخدام VAST مع PA API. أثناء هذه المناقشة، تبيّن أيضًا أنّه على الرغم من أنّ عرض الفيديوهات ممكن حاليًا، هناك تغييرات يمكن أن يجريها Chrome لتبسيط عملية التنفيذ باستخدام PA API. على سبيل المثال، إنّ التعديلات على استبدال وحدات الماكرو (المُناقشة هنا) التي كنّا نخطّط لحلّها استنادًا إلى الملاحظات حول حالات استخدام أدوات التحقّق من الإعلانات التابعة لجهات خارجية للحفاظ على أمان العلامة التجارية، ستعالج أيضًا الملاحظات في حالة استخدام الفيديو، حيث يبحث المشتري عن وحدات الماكرو الخاصة بالبائعين لاستخدامها في العرض. وقد تركّز معظم المناقشات حتى الآن على عرض إعلانات الفيديو باستخدام تنسيق VAST. يمكن أن يستخدِم عرض الإعلانات المدمجة مع المحتوى الأساليب نفسها، وهو أسهل من عدّة طرق. يبدو أنّ الإعلانات المدمجة تحظى حاليًا باهتمام أقل من الفيديو، ولكن هذا يرجع إلى الأولوية التي تمنحها صناعة تكنولوجيا الإعلانات لأنواع الإعلانات الأخرى، وليس بسبب أي عائق فني يحول دون تنفيذها. |
| قياس الأداء غير الإعلاني | قد تؤثّر سياسة 3PCD في حلول قياس الجمهور غير المرتبطة بالإعلانات. | لا تشترط واجهات برمجة تطبيقات القياس أن تكون حالة الاستخدام مرتبطة بالإعلانات. في حين أنّ ARA أكثر صلة برحلة إعلانية نموذجية، فإنّ التجميع الخاص يخدم أغراضًا عامة. يمكن استخدام هاتين المكوّنَين الأساسيَين للتعامل مع مجموعة كبيرة من أنشطة القياس. |
| صنّاع المحتوى | تم تصميم "مبادرة حماية الخصوصية" لتشجيع صنّاع المحتوى على إنشاء المزيد من المحتوى على YouTube ونشر قدر أقل منه على مواقعهم الإلكترونية. | تركّز "مبادرة حماية الخصوصية" على الحفاظ على خصوصية نشاط المستخدمين على الإنترنت المفتوح والمجاني. ندرك أنّ الناشرين يعتمدون على الإعلانات لإنشاء المحتوى وإتاحته على نطاق واسع قدر الإمكان. يساعد المعلِنون المستخدِمين في اكتشاف منتجات أو عروض جديدة قد تهمّهم. تتيح ميزات "مبادرة حماية الخصوصية" للمواقع الإلكترونية من جميع الأنواع، بما في ذلك المواقع الإلكترونية التي تعمل مع صنّاع المحتوى، عرض إعلانات مفيدة للمستخدمين استنادًا إلى نشاطهم مع جهات مختلفة، بدون الكشف عن هوية المستخدم لهذه الجهات. |
| مخططات زمنية أكثر وضوحًا | جداول زمنية أكثر وضوحًا وتفصيلاً لتكنولوجيات "مبادرة حماية الخصوصية" | تتضمّن مستندات Privacy Sandbox API صفحتَي حالة واجهة برمجة التطبيقات ومدى توفّرها. تعرض هذه الصفحات الميزات القادمة والمخططات الزمنية لها (مثل PA API و ARA). يمكنك الاطّلاع على عرض مركزي لهذه الحالات هنا. |
| تعلُم الآلة | لا يمكن لتكنولوجيات الإعلان تدريب نماذج تعلُّم الآلة بشكلٍ سليم إلى أن تتجاوز نسبة 3PCD 1%. | إنّ توسيع نطاق 3PCD ليشمل المزيد من المتصفّحات لاختبارها لن يضمن زيادة استخدام واجهات برمجة التطبيقات، وهو ما تبحث عنه تقنيات الإعلان على الأرجح من أجل مواصلة تدريب نماذج تعلُّم الآلة. إذا لم يكن استخدام المنظومة المتكاملة على نطاق أوسع هو ما تسعى إليه تكنولوجيات الإعلان من أجل تدريب نماذج تعلُّم الآلة بشكل أكبر، لن يكون هناك سبب لتوسيع نطاق 3PCD لأنّ تكنولوجيا الإعلان التي تريد تدريب النماذج على المزيد من الزيارات يمكنها إجراء ذلك اليوم بدون زيادة 3PCD. ويمكن إجراء ذلك بدون أن يبدو أنّ Chrome يتقدّم في 3PCD قبل انتهاء حالة "التوقف المؤقت". |
| حالة استخدام غير متوافقة | لا يتم حاليًا النظر في حالات استخدام منصّات إدارة الأداء الذاتي. | هناك العديد من منصّات إدارة الأداء (DSP) ذات الخدمة الذاتية التي تقدّم بانتظام ملاحظات علنية حول واجهات برمجة التطبيقات. والعديد من منصّات DSP هذه التي تقدّم ملاحظات علنية بشكل منتظم صنّفت نفسها أيضًا كمختبِرين. بالإضافة إلى ذلك، يشارك Chrome بشكل نشط في مواضيع منصّات إدارة الأداء المستندة إلى الخدمة الذاتية النموذجية، مثل الفيديو وخوادم الإعلانات التابعة لجهات خارجية. وقد تناولت طلبات البيانات الأخيرة من واجهة برمجة التطبيقات في "إعلانات شبكة البحث" هذه المواضيع. |
| مرحلة التجربة والتقييم | طلب الحصول على وقت إضافي للمواقع الإلكترونية التي تريد زيادة وتيرة التحسين وتوسيع نطاق الاختبار لميزة "الإعلانات على شبكة البحث المتجاوبة" | يعمل Chrome حاليًا على تطوير ميزة OT للطرف الأول، ما سيسمح للمواقع الإلكترونية بالموافقة على إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية بشكل تدريجي. بالنسبة إلى مصادر المستوى الأعلى التي تسجّل في هذه الفترة التجريبية وتنشر الرموز المميّزة، سيتم حظر ملفات تعريف الارتباط التابعة لجهة خارجية كما لو كانت ميزة "الحماية من التتبّع" مفعّلة على جهاز المستخدم. سيوفّر هذا الإطار الزمني فرصة قيّمة للمواقع الإلكترونية لإجراء اختبار أوسع النطاق لبدائل 3PC على المدى الطويل، وذلك قبل الإيقاف النهائي لـ 3PC الذي من المقرر أن يتم بعد التشاور مع هيئة CMA. ما زلنا نعمل على وضع اللمسات الأخيرة على المخطط الزمني لطرح هذا الإطار الزمني. |
| تقرير IAB Tech Lab | ملاحظات حول "مبادرة حماية الخصوصية" تم تلقّيها من تقرير IAB Tech Lab | يمكنك الاطّلاع على ردّنا على تقرير "المختبَر التقني لمكتب الإعلانات التفاعلية" بالتفصيل هنا. لقد أقررنا أيضًا في الردّ على هذا الطلب أنّ "التقرير يطرح أسئلة حول الوثائق المجزّأة والمتطلبات التجارية وعمليات التدقيق التي تجريها جهات خارجية واعتماد الصناعة وقابلية التوسّع والشفافية والإدارة المستقبلية، وسنشارك هذه الأسئلة مع المنظومة المتكاملة ونعدّل الأسئلة الشائعة المتاحة للجميع وفقًا لذلك". لقد عالجنا المستندات المجزّأة سابقًا. نتناول المتطلّبات التجارية ضمن "ضمانات البيانات" هنا، وشاركت بعض منتجات "إعلانات Google" نهجها. يمكنك الاطّلاع على عمليات التدقيق التي تجريها الجهات الخارجية ضمن "ضمان نزاهة الخوارزميات" هنا. في ما يتعلق بالاعتماد، نتوقّع أن تواصل هذه الهيئات اعتماد المنتجات، بما في ذلك استخدامها للتقنيات، بدلاً من الاعتماد على التقنيات نفسها. في ما يتعلق بقابلية التوسّع، ما زلنا نقبل البيانات الواردة من المطوّرين التي توضّح المشاكل. في ما يتعلّق بالشفافية وإدارة البيانات، نواصل تطويرها بشكل علني على GitHub وفي المنتديات مثل W3C، بينما نتواصل مع CMA بموجب "الالتزامات". |
| تسجيل الدخول بحساب Google | سيؤدي تسجيل الدخول باستخدام حساب Google إلى احتمال استخدام Google لبيانات تسجيل الدخول التي تتضمّن معلومات تحديد الهوية على مستوى الخدمات المختلفة بما يخالف "الالتزامات". | لا تسمح ميزة "تسجيل الدخول باستخدام حساب Google" لشركة Google باستخدام البيانات بما يخالف "الالتزامات". |
| التوافق | ما هي الخطط المتعلّقة بتوافق واجهات برمجة التطبيقات في "مبادرة حماية الخصوصية" مع الإصدارات السابقة والإصدارات اللاحقة؟ | بعد أن يطرح Chrome ميزة للجمهور العام، نهدف إلى مواصلة توفيرها. من المؤكد أنّه ليس من الممكن دائمًا الحفاظ على التوافق مع الإصدارات القديمة، وفي هذه الحالات، لدينا عملية واضحة لإيقاف الميزات الحالية نهائيًا وإزالتها، كما هو موضّح هنا. نتوقع مواصلة إضافة المزيد من الميزات إلى واجهات برمجة تطبيقات Privacy Sandbox API بمرور الوقت، استجابةً للملاحظات الواردة من المنظومة المتكاملة حول حالات الاستخدام التي يمكن أن تستفيد من تحسين الدعم. في هذه الحالات، نميل إلى تضمين نوع من تقنية رصد الميزات، حتى تتمكّن تقنية عرض الإعلانات المهتمة بتجربة ميزة جديدة من أن تطلب من المتصفّح مباشرةً ما إذا كانت الميزة متوافقة. وهذا أفضل من مطالبة المطوّرين بالبحث عن رقم إصدار معيّن من Chrome، لأنّ بعض الميزات قد لا يتم طرحها لجميع مستخدمي Chrome في الوقت نفسه. على سبيل المثال، يمكن العثور على عملنا بشأن رصد الميزات لواجهة برمجة التطبيقات PA API هنا. |
| تنفيذ الخادم | بدلاً من الربط بتنفيذه الخاص، يجب أن يحدِّد Chrome السلوكيات التي يجب أن يستوفيها التنفيذ المُرضِي لخادم "الإشارات الموثوق بها" وخادم التجميع وأي مكوّنات أخرى مطلوبة غير المتصفّح. سيتيح ذلك الابتكار ضمن حدود الخصوصية المقبولة. | نحن نقدّر ونرحّب برغبة الجهات الخارجية في الابتكار. نهدف إلى توفير مرونة لتكنولوجيات الإعلان من أجل تنفيذ وظائفها في جميع واجهات برمجة التطبيقات والخدمات. على سبيل المثال، نسمح لتكنولوجيات الإعلان باستخدام معلومات النشاط التجاري السرية في تصميم منطق عروض الأسعار للمزادات. بالإضافة إلى ذلك، نتفاعل باستمرار مع الملاحظات والآراء الواردة من تكنولوجيات الإعلان، وندمجها في تصميماتنا عند الاقتضاء. للسماح للآخرين بتشغيل رموزهم الخاصة في "بيئات التنفيذ الموثوق به"، ستحتاج "مبادرة حماية الخصوصية" إلى مراجعة الرمز (وأي تغييرات) للتأكّد من أنّه يستوفي ضمانات الخصوصية. سيتطلب ذلك جهدًا كبيرًا من فريق "مبادرة حماية الخصوصية". لذلك، نريد معرفة المزايا التي يسعى صاحب المصلحة إلى تحقيقها والتي لا نقدّمها له اليوم. |
| الإعدادات الإرشادية | ما هي الخطط طويلة المدى للأساليب الاستقرائية؟ | بما يتوافق مع ما أشار إليه مطوّرو المتصفّحات الأخرى، ننوي في نهاية المطاف إيقاف هذه الأساليب الاستقرائية نهائيًا مع ازدياد استخدام الحلول البديلة على نطاق واسع، وذلك بعد إجراء مزيد من تحليلات الجدوى. لقد شاركنا هذه المعلومات هنا. |
| حجم الاختبار | حجم الزيارات المختلفة عند مقارنة سمات مختلفة | تتضمّن تجربة نسبة% 1 معايير استبعاد تؤدي إلى اختلافات في الأهلية للمشاركة في التجربة بين مجموعات مختلفة من عملاء Chrome. على سبيل المثال، تستبعد التجربة مستخدمي Chrome Enterprise، لذا من المتوقّع أن يكون جزء الزيارات التي تحمل تصنيفات التجربة أعلى في عطلات نهاية الأسبوع. من المتوقّع أن تظهر نسب مئوية مختلفة للزيارات في شرائح بيانات مختلفة (مثل الموقع الجغرافي والتاريخ والنظام الأساسي)، وهذا يتوافق مع ما نراه في بيانات Chrome. |
| إعادة تفعيل 3 أجهزة كمبيوتر يدويًا | هل ستتمكّن المواقع الإلكترونية من معرفة عدد المستخدمين (بالنسبة المئوية) الذين أعادوا تفعيل ملفات تعريف الارتباط يدويًا بعد فرض سياسة "الموافقة المسبقة للمعالجة المحدودة للبيانات"؟ | سيتمكّن المستخدمون من إعادة تفعيل إمكانية وصول الجهة الخارجية الثالثة على مستوى الموقع الإلكتروني من خلال ميزة "تجاوز المستخدم" في حال حدوث خلل. يمكن أيضًا إعادة تفعيل ملفات تعريف الارتباط التابعة لجهة خارجية من خلال إجراءات أخرى، مثل واجهة برمجة التطبيقات Storage Access API. هناك إجراءات فنية، مثل hasStorageAccess()، تسمح للمواقع الإلكترونية برصد ما إذا كانت ملفات تعريف الارتباط التابعة لجهات خارجية مفعَّلة أو غير مفعَّلة. ومع ذلك، لن يسهّل Chrome للمواقع الإلكترونية معرفة أسباب إعادة التفعيل. |
| ميزة "الحماية من التتبُّع" | ما هي مدة توفُّر واجهة مستخدم ميزة "الحماية من التتبّع" في Chrome؟ | من المتوقّع أن تظل واجهة مستخدم ميزة "الحماية من التتبّع" في شريط العناوين متوفّرة بعد إيقاف ميزة "المعالجة المحدودة للطرف الثالث" نهائيًا. |
| (تم الإبلاغ عن ذلك أيضًا في الربعَين السابقَين) التوافق مع جميع المتصفّحات |
مورّدو متصفّحات آخرون يتّبعون واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" | يشارك مورّدو المتصفّحات الآخرون، مثل Apple وMozilla وMicrosoft، بشكل نشط في المنتديات العامة التي يتم فيها مناقشة مبادئ الخصوصية والنهج المستنِد إلى المتصفّح. يسرّنا أنّنا نرى علامات على التقارب في المناقشات التعاونية التي تُجرى في المنتديات، مثل اجتماع TPAC السنوي الأخير في W3C ومنتديات PATCG الجارية في W3C. على سبيل المثال، أعلنت Microsoft Edge مؤخرًا عن خطتها التي "تهدف إلى زيادة التوافق النحوي إلى أقصى حد" مع PA API وARA مع تقديم ميزات إضافية للمطوّرين أيضًا. |
| خيار احتياطي للإدراج غير المتوافق بعد 3PCD | يجب توفير عناصر ربط واجهة برمجة التطبيقات لرصد ما إذا كان إطار iframe أو المحتوى المضمّن التابعَين لجهة خارجية متوافقَين مع سياسة 3PCD أم لا. | نحن نناقش الطلب هنا ونرحّب بملاحظات إضافية من المنظومة المتكاملة. |
| الاختبار | طلب علامات إضافية في النُسخ المُدارة من Chrome التي تُوقف مؤقتًا السلوكيات المخصّصة | نحن ننظر في هذا الطلب بشأن النُسخ المُدارة من Chrome ونرحّب بملاحظات إضافية من المنظومة المتكاملة إذا كانت هذه الإبلاغات مفيدة. |
التسجيل والإقرار
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| إثبات صحة الإقرار | كيف تضمن Google صحة بيانات الاعتماد؟ | على جميع المسجّلين الاحتفاظ بملف الإقرار أثناء استخدام واجهات برمجة التطبيقات. تتحقّق Google من توفّر الملف وصحة البنية، ولكنّها لا تتحقّق من سلوك تكنولوجيا الإعلان في ما يتعلّق بلغة شهادة الاعتماد. |
| عملية التسجيل في Private Aggregation API | هل هناك طريقة للتحقّق من حالة تسجيل Private Aggregation API؟ | يُرسِل فريق دعم التسجيل إشعارًا عبر البريد الإلكتروني إلى جميع المُدرَجين الذين تمت الموافقة عليهم بعد التحقّق من التسجيل. إذا كان لدى المُسجِّل أي أسئلة أثناء العملية، يمكنه التواصل مع فريق الدعم (الذي يتم ربطه به عند إرسال نموذج التسجيل). سيردّ فريق الدعم على أسئلتك ويقدّم لك أي إرشادات إضافية مطلوبة. |
عرض محتوى وإعلانات ذات صلة
المواضيع
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| (تم الإبلاغ عنها أيضًا في الربع سنوية السابقة) المخطط الزمني والمستندات المتعلّقة بالمعرّف |
يجب أن يكون هناك شكل من أشكال الآلية لمراجعة التصنيف أو على الأقل شفافية إضافية حول كيفية تحديد وضع التصنيف للفئات. | لم يتغيّر ردّنا عن الربع السابق: "قد تؤدي التصنيفات الخاطئة للمواقع الإلكترونية إلى جعل إشارة Topics أقل فائدة قليلاً كإشارة بشكل عام، ولكنّ المواقع الإلكترونية المحدّدة التي تم تصنيفها بشكل خاطئ لا تتأثّر بهذا الإجراء أكثر أو أقل من أي مواقع إلكترونية أخرى. ويعود السبب في ذلك إلى أنّ المعلومات السياقية للموقع الإلكتروني ستكون متاحة دائمًا للمزادات على موقعه الإلكتروني، ما سيقدّم معلومات مشابهة للموضوع الصحيح، حتى في حال التصنيف الخاطئ. نرحب بملاحظاتك حول هذا الموضوع هنا." |
| مدير إعلانات Google | تمّ تضمين "مدير إعلانات Google" في معظم المواقع الإلكترونية، وسيكون لديه معلومات أوسع بكثير عن مواضيع المستخدِمين مقارنةً بالمنافسين الذين يظهرون على عدد أقل من المواقع الإلكترونية. | يُشترط إجراء المراقبة لضمان عدم مشاركة بيانات المستخدمين مع كيانات أكثر من التكنولوجيات التي تحلّ محلّ واجهة برمجة التطبيقات (بما في ذلك ملفات تعريف الارتباط التابعة لجهات خارجية). تعمل حلول أخرى في المجال، مثل Prebid، مع آلاف المواقع الإلكترونية وتتيح للمشاركين في السوق طلب Topics API من خلال التكنولوجيا الخاصة بهم. بالإضافة إلى ذلك، تجدر الإشارة إلى أنّ الحد الأقصى الذي يصل إلى 5 مواضيع رئيسية في الأسبوع قد يكون له تأثير متكافئ، لأنّ المشاركين في السوق الذين يظهرون على العديد من المواقع الإلكترونية والذين قد يتمكّنون من التعرّف على أكثر من 5 مواضيع باستخدام 3PCs سيتم حصرهم في 5 مواضيع. |
| (تم الإبلاغ عنها أيضًا في الربعَين السابقَين) الفائدة لأنواع مختلفة من الجهات المعنيّة |
المخاوف بشأن القيمة التي يتم إنشاؤها وتوزيعها على المواقع الإلكترونية استنادًا إلى مستوى الزيارات أو مدى تخصص المحتوى | ندرك أنّه من المرجّح أن تساهم المواقع الإلكترونية المتخصّصة في مواضيع أكثر دقة من النطاقات ذات الاهتمامات العامة. ومع ذلك، لا تساهم بعض المواقع الإلكترونية المتخصّصة في مواضيع ذات قيمة تجارية. وتعكس هذه الديناميكية أيضًا الوضع الحالي وهي مستقلة تمامًا عن إيقاف تقنية 3PC في Chrome. في البيئة الحالية أيضًا، توفّر بعض المواقع الإلكترونية قيمة أكبر من غيرها في أنظمة مدى صلة الإعلانات المستندة إلى ملفّات تعريف الارتباط التابعة لجهات خارجية. بالإضافة إلى ذلك، يمكن أن تكون المواضيع بين المواقع الإلكترونية المتخصّصة مفيدة للطرفين، لأنّ المعلِنين المتعدّدين يمكنهم عرض حملات على مجموعات متنوعة من المواضيع، ويمكن أن يلاحظ منطق عروض الأسعار قيمة على مستوى مجموعة كبيرة من المواضيع. |
| أسماء المضيفين في مقابل عناوين URL الكاملة | هل التصنيف استنادًا إلى أسماء مضيفي المواقع الإلكترونية فعّال بما يكفي، وهل يقلل ذلك من خطر الخصوصية مقارنةً بعناوين URL الكاملة؟ | لقد فكّرنا في استخدام عناوين URL للمعلومات أو عناوين الصفحات بالإضافة إلى أسماء المضيفين، وتبيّن لنا أنّ الفوائد المحتملة ستفوقها المخاطر التي تواجه خصوصية المستخدم وأمانه. ومن الأمثلة على مخاطر خصوصية المستخدمين تصنيف المعلومات الحسّاسة المضمّنة في عنوان URL أو عنوان الصفحة ضمن مواضيع المستخدم. |
| المواضيع كإشارة | طلب إرشادات حول كيفية دمج المواضيع مع إشارات أخرى، والإشارات الأخرى التي قد تكون مفيدة | يمكن أن تحقّق حلول تكنولوجيا الإعلان أفضل النتائج من خلال الجمع بين جميع الأدوات المتاحة، مثل تعلُّم الآلة والإشارات المصمّمة بالتوافق مع معايير الخصوصية من واجهات برمجة التطبيقات التي تحافظ على الخصوصية، بالإضافة إلى البيانات السياقية وبيانات المواد الإبداعية وبيانات الطرف الأول. يمكنك الاطّلاع على مزيد من الإرشادات حول هذا الموضوع هنا. |
Protected Audience API (المعروفة سابقًا باسم FLEDGE)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| حجم عدد الزيارات الاختبارية | يُبلغ المختبِرون عن انخفاض عدد عروض الأسعار التي يتمّ الردّ عليها في مزاد PA API. | 1. ترتبط كثافة عروض الأسعار بمشاركة المنظومة المتكاملة في PA API، والتي نتوقّع أن تستمر في الزيادة على مدار عام 2024 وما بعده. في نهاية المطاف، يعود الأمر إلى المعلِنين ووكالات المعلِنين ومقدّمي التكنولوجيا لتحديد كيفية تخصيص ميزانيات الحملات. نتوقع أن يؤخّر بعض المشاركين في المنظومة المتكاملة استثمارهم في الحلول المختلفة "التي لا تستخدِم ملفات تعريف الارتباط"، بما في ذلك PA API، إلى ما بعد تاريخ إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا. وفي ذلك الوقت، نتوقّع أن تزيد الشركة الميزانية المخصّصة لحملاتها لتشمل هذه الحلول. 2. قد يتأثّر حجم طلبات عروض الأسعار في مزادات PA API بـ (1) لأنّ الناشرين ومزوّدي تقنية الإعلان قد يقرّرون عدم بدء مزادات PA API إذا شعروا أنّ الطلب منخفض. على الناشرين تحديد أولوية تعديل صفحاتهم والمشاركة. ونتوقع أن يستغرق الناشرون بعض الوقت لاختبار الميزة وزيادة عدد الزيارات تدريجيًا لهذه الأسباب. يتضمّن هذا التقرير أيضًا ردًا من "مدير إعلانات Google" بشأن عناصر التحكّم الخاصة بالناشر في المشاركة في PA API. |
| (تم الإبلاغ عنها أيضًا في الربع السابق) الاحتيال / إساءة الاستخدام |
كيف يمكن للمنظومة المتكاملة الحدّ من المخاطر ومنع الجهات الفاعلة أو المشترين السيئين من تقديم أنفسهم كشريحة جمهور مرغوب فيها؟ | تحتفظ آليات إعداد التقارير لإعلانات PA API بالمعلومات المستخدَمة حاليًا لتمييز زيارات المستخدمين عن زيارات برامج التتبُّع. بالإضافة إلى ذلك، يمكن استخدام الأساليب الحالية المستندة إلى النطاقات لتضمين النطاقات أو استبعادها في PA API. يمكنك الاطّلاع على مزيد من التفاصيل في ردّنا على تقرير "المختبَر التقني لمكتب الإعلانات التفاعلية" (IAB Tech Lab) بشأن "مبادرة حماية الخصوصية". |
| قيود على المصدر نفسه لعنوان URL الخاص بمالك حساب Instagram وعنوان URL الخاص بمنطق عروض الأسعار | مع متطلبات المصدر نفسه، ستضطر نقاط النهاية الخاصة بمالك حساب Instagram إلى المرور عبر موازن الحمولة نفسه، ما قد يؤدي إلى رفض عمليات إعادة التوجيه. | يُعدّ شرط المصدر نفسه لتحميل النصوص البرمجية إجراءً أمنيًا مهمًا. يمكنك الاطّلاع على بعض التفاصيل حول الحل المقترَح هنا الذي يوازن بين ملاحظات المنظومة المتكاملة والاعتبارات الأخرى هنا. |
| المزاد الخاص المتعدّد الفتحات | هناك مجال كبير للسماح بالمزادات الخاصة المتعدّدة الفتحات ضمن حدود الخصوصية من خلال استخدام التشويش والدمج بشكلٍ أكثر صرامة مع الممارسات الحالية للإعلانات. | نحن نأخذ هذه الملاحظات في الاعتبار ونُقيّم طلب مزادات العلامات المتعددة في ضوء التعقيد المتزايد ومخاطر الخصوصية المرتبطة بهذه الميزة. لقد ناقشنا هذه المشكلة بشكل أكبر خلال مكالمة مع مجموعة Web Incubator Community Group (WICG) لواجهة برمجة التطبيقات في PA هنا. |
| البائعون من المستوى الأعلى | توفّر البنية الحالية لواجهة برمجة التطبيقات PA API لأيّ بائع من المستوى الأعلى بيانات وفهمًا أكبر بكثير للقيمة النسبية للمرات الظهور مقارنةً بالناشرين أو بائعي المكوّنات. | في مزاد يضمّ بائعين متعدّدين، سيقدّم كلّ بائع أفضل عرض سعر. بالإضافة إلى ذلك، تبيّن لنا من خلال المنظومة المتكاملة أنّه قد يريد الناشرون مراعاة الطلب المباع مباشرةً بجانب أفضل عروض أسعار لكل بائع يعملون معه. من الضروري النظر في كلّ هذه الفرص المحتملة لتحقيق الربح لتحديد الإعلان الذي سيتم عرضه. ويعود هذا الموقف، الذي يكون فيه من الضروري أن يرى أحد الجهات الفاعلة المجموعة الكاملة من الخيارات لاختيار إعلان لعرضه، إلى ما قبل PA API. تسعى PA API إلى إتاحة المزاد العلني المتعدد البائعين ورغبة الناشرين في أخذ أفضل عرض سعر لكل بائع في الاعتبار إلى جانب الحملات الإعلانية المُباعة مباشرةً، حيثما ينطبق ذلك. وهذا يعني أنّه يجب توفير آلية للاختيار من بين فرص تحقيق الربح هذه، كما هو الحال حاليًا. لم نعتقد أنّه يجب أن يكون دور المتصفّح هو اختيار الإعلان الذي سيتم عرضه. وبالتالي، فإنّ مفهوم البائع من المستوى الأعلى ضروري لاختيار إعلان فائز من بين العديد من الاحتمالات. يجب أن يكون منطق البائع من المستوى الأعلى قادرًا على أخذ أفضل عروض الأسعار من كل بائع يختاره الناشر للعمل معه. وقد يختار منطق هذا البائع تقديم معلومات عن الحملات التي يبيعها الناشر مباشرةً في حال توفّر هذه المعلومات. ويمكن أن يتمّ أخذ كلّ هذه المعلومات في الاعتبار في منطق اختيار الإعلانات على مستوى أعلى. وهذا يعني أنّ منطق المستوى الأعلى يعرض أفضل عروض الأسعار من مزاد PA API وأي خيارات إعلانات يتم بيعها مباشرةً من الناشر، حيثما ينطبق ذلك، لتحديد العرض الفائز. يوضّح "مدير إعلانات Google" تفاصيل تنفيذه لواجهة برمجة التطبيقات PA API بصفتها بائعًا من المستوى الأعلى في هذا التقرير ضمن موضوع الوصول إلى المعلومات. |
| فصل الإعلانات المنافسة | طلب فصل الإعلانات التنافسية، مثل منع ظهور إعلانات العلامات التجارية المتنافسة بجانب بعضها | لا نعرف طريقة لضمان الفصل التنافسي في المنظومة المتكاملة للإعلانات الرقمية الآلية التي تشمل عروض أسعار ومتعدّدة البائعين في الوقت الحالي. ومع ذلك، تتيح PA API للبائعين جلب إشارات إضافية في الوقت الفعلي استنادًا إلى مجموعة من renderURL وhostname (التي تمثّل نطاق الناشر) التي يمكن استخدامها أثناء scoreAd() عند تقييم المواد الإبداعية. وقد يستخدم البائعون هذه الميزة لمنع ظهور إعلانات العلامات التجارية المنافسة بجانب بعضها، على افتراض أنّ الناشر يريد فرض هذه القاعدة. |
| معلومات محدودة | تعمل واجهة برمجة التطبيقات PA API على تقليل المعلومات المتاحة للناشرين، مثل قيمة الإعلان واسم مشتري المكوّن واسم المعلِن وعنوان URL للصفحة المقصودة وحجم تصميم الإعلان ووقت الاستجابة ومعدّل عرض السعر بالإضافة إلى عروض الأسعار الخاسرة. | لقد اقترحنا بعض الحلول المحتملة هنا ونرحّب بملاحظات إضافية من المنظومة المتكاملة. |
| إعداد التقارير على مستوى الحدث | يتعذّر على الناشرين الحصول على معلومات كافية عن الإعلان الذي تم عرضه بعد إيقاف واجهة برمجة التطبيقات PA API لإعداد التقارير على مستوى الحدث. | نحن على دراية بحالات الاستخدام المختلفة لإعداد التقارير التي يجب أن نواصل دعمها عند إيقاف ميزة إعداد التقارير على مستوى الحدث. لهذا السبب، حدّدنا تاريخ إيقاف ميزة إعداد التقارير على مستوى الحدث في موعد لا يقلّ عن 2026. خلال الفترة التي تفصلنا عن هذا التاريخ، ندعوك إلى المشاركة الفاعلة أثناء تفاعلنا مع المنظومة المتكاملة في مسارات مستدامة يمكن أن تتضمّن أفكارًا جديدة للحصول على المعلومات بطريقة تحافظ على الخصوصية. |
| منصّات عرض إعلانات متعددة | ستكون القيمة المضافة من استخدام منصّات عرض إعلانات متعددة منخفضة جدًا للناشرين. | لا نعتقد أنّ هذا صحيح، ونرحّب بملاحظات إضافية من المنظومة المتكاملة لفهم الأساس المنطقي لهذا الافتراض. |
| أنشطة التنظيم | لا يمكن تنفيذ أنشطة التنظيم باستخدام PA API. | لقد تلقّينا ملاحظات بشأن إمكانية استخدام البائعين لواجهة برمجة التطبيقات PA API لتوفير معلومات جمهورهم للمشترين على الويب (المعروفة أيضًا باسم "إضافة الجمهور"). نعتقد أنّ هذا ممكن اليوم باستخدام وظيفة التفويض في "مساعد التسويق" إلى جانب اتفاقيات النشاط التجاري. في الوقت نفسه، ننظر بنشاط في إمكانية استيعاب هذه الأنواع من حالات الاستخدام بشكل أفضل وكيفية ذلك. |
| إيقاف الميزة من قِبل المشتري | من المرجّح أن يؤدي إيقاف المشترين التلقائي إلى نتائج أقل في مزادات المكوّنات. | سواء كان يتم تحديد مزاد إعلانات قابلة للتقديم والعرض لبائع واحد أو لبائعين متعدّدين، على البائع إدراج المشترين صراحةً في حقل interestGroupBuyers ضمن AuctionConfig. يستند ذلك إلى الملاحظات الواردة من منظومة التطبيقات المتكاملة بأنّ البائعين لديهم اتفاقيات تعاقدية مع بعض المشترين وليس آخرين، لذا سيحتاجون إلى التحكّم الواضح في المشترين الذين سيتم تضمينهم في المزاد. نرحب بمواصلة المناقشة على GitHub. |
| حجم الإعلان | تعذّر إجراء الفلترة المُسبَقة استنادًا إلى adsize وadSlotSize. | نحن نعمل على إضافة هذه الميزة، ويمكنك الاطّلاع على مزيد من التفاصيل هنا. |
| إتاحة الاستهداف السلبي على Instagram | واجهة برمجة تطبيقات تتيح استهداف IG السلبي: عرض الإعلانات فقط إذا لم يكن المستخدِم تابعًا لمجموعة IG | اقترحت هذه المشكلة على GitHub طريقة بديلة لتنفيذ الاستهداف السلبي، حيث يُعلم المتصفّح خادم الإعلانات مباشرةً بقواعد الاستهداف السلبي التي يجب أن تكون سارية لطلب إعلان معيّن. على الرغم من أنّ هذا النهج يبدو جذابًا، تبيّن لنا أنّ جميع إصدارات هذه الفكرة التي فحصناها تتيح للخادم تحديد هوية المستخدم بشكل فريد. |
| قانون الخدمات الرقمية | كيف يمكن للناشر استخدام "اللقطات المُغلقة" مع منع عرض الردود التي تحتوي على معلومات خاضعة لقانون الخدمات الرقمية؟ | كما هو الحال مع أي تقنية جديدة، تتحمّل كل شركة مسؤولية التأكّد من امتثال استخدامها لـ "مبادرة حماية الخصوصية" للقانون، ولا يمكن لشركة Google تقديم مشورة قانونية للآخرين. لقد نشرنا مستندات فنية مفصّلة لكل واجهة برمجة تطبيقات، ومن المفترض أن توفّر هذه المستندات الأساس لإجراء التقييمات القانونية اللازمة. لن تكون الإطارات المُحدودة مطلوبة لاستخدامها في PA API قبل عام 2026، ما يمنح الجهات المعنية وقتًا إضافيًا للتأكّد من أنّ استخدامهم لهذه التكنولوجيا متوافق مع جميع التشريعات ذات الصلة. |
| الوثائق | هل updateAdInterestGroups() مؤقتة؟ | لم نعلن عن أيّ خطط لإيقاف updateAdInterestGroup نهائيًا. في المستقبل، قد نطبّق إجراءات حماية خصوصية مشابهة لتلك التي تحدثنا عنها علنًا في ما يتعلّق بآليات التحديث الأخرى في Instagram، مثل استخدام عنوان IP كوكيل وإضافة بعض التأخير قبل إجراء التحديث. |
| إتاحة ملكية البيانات الوصفية والمنطق على الجهة المشترية للأنظمة غير المستندة إلى عروض الأسعار | طلب طريقة للعب دور خادم وكيل لأنظمة إدارة الأداء | نحن على دراية بهذه الملاحظات الواردة من شرائح الجمهور التي لا تستخدم منصّات إدارة الأداء (DSP)، وننظر في هذا الطلب. نرحب بملاحظات إضافية من المنظومة المتكاملة. |
| إعداد التقارير | طلب إضافة ميزة معالِج مخصّص لحزمة / قيمة الإشارات في تقارير التجميع الخاص | نحن على دراية بهذا الطلب، وهو في انتظار المراجعة. نرحب بملاحظات إضافية من المنظومة المتكاملة هنا. |
| الوثائق | هل هناك رابط يمكن من خلاله الاطّلاع على جميع رؤوس الردود التي يجب أن يضبطها المعلِن ونطاق المالك (المفوَّض)؟ | نحن بصدد إجراء تعديلات على المستندات لتوضيح ذلك، ونرحّب بملاحظات إضافية من المنظومة المتكاملة. |
| عروض الأسعار في عدّة أبراج | طلب شرح لسير العمل (التدريب والاستنتاج) من خلال مخطّط معماري / مخطّط بياني للكتلة حول كيفية تصور نهج متعدد الأبراج في سياق PA API | نشكرك على إرسال الملاحظات. لدينا بعض العروض التقديمية حول الموضوع نتوقّع من خلالها إنشاء مستندات إضافية. |
| الاستهداف السلبي | قدرة "مبادرة حماية الخصوصية" على حماية شرائح الجمهور الحساسة والقصر من الإعلانات غير المناسبة، مثل المقامرة | لا تأخذ واجهة برمجة التطبيقات PA API محتوى الإعلانات المعروضة في الاعتبار. يمكن لمطوّري تقنية الإعلانات الذين يستخدمون ميزة "الجمهور المحمي" التحكّم في ذلك. بشكل عام، يمكن للناشر ومزوّدي تقنية الإعلانات حظر تصميمات الإعلانات ضمن مزادات "الجمهور المحمي" باستخدام المعلومات السياقية من الصفحة بالإضافة إلى مجموعات قواعد الناشر. ويعكس ذلك فهمنا لنهج المنظومة المتكاملة في مواجهة هذه التحديات اليوم. بالنسبة إلى المشترين، قد تكون وظيفة الاستهداف السلبي على Instagram مفيدة أيضًا لبعض حالات الاستخدام المتعلّقة بالامتثال. |
| تصميم واجهة برمجة التطبيقات | ترفض Google ذلك وتريد من تكنولوجيات الإعلان استخدام وظيفة عروض أسعار Universal، ما يؤدي إلى زيادة وقت الاستجابة، بدلاً من استخدام عناوين URL مختلفة لـ biddingLogic في حسابات IG المختلفة، وهو أمر مسموح به. | خلال مناقشاتنا حول وقت استجابة المزاد، وضّحنا أنّ إعادة استخدام النص البرمجي نفسه في جميع حسابات المشترين على "إعلانات Google" سيؤدي إلى تنفيذ عروض أسعار هذا المشتري بشكل أسرع. يمكنك الاطّلاع على مزيد من التفاصيل هنا، بالإضافة إلى اقتراحاتنا الأخرى لتحسين وقت استجابة مزاد PA API. |
| التسويق المستنِد إلى الحساب | لا تُعدّ PA API واجهة برمجة تطبيقات مناسبة لحالات استخدام التسويق المستنِد إلى الحساب. | نرحب بملاحظات من المنظومة المتكاملة بشأن أيّ حالات استخدام محدّدة يعتقد المشاركون أنّها غير ممكنة، ونشجّع المشاركين في المنظومة المتكاملة على مواصلة هذه المناقشة من خلال مستودع GitHub العلني أو المكالمات الأسبوعية. |
| اختبار أ/ب | عند ضبط PA API في "مدير إعلانات Google" للناشر، يجب حاليًا تفعيلها لجميع المستودعات الإعلانية أو عدم تفعيلها لأي منها. ويحدّ ذلك من قدرة الناشرين على إجراء اختبار A/B مجدٍ. | الردّ المقدَّم من "مدير إعلانات Google": تؤثّر عناصر التحكّم في PA API ضمن "مدير إعلانات Google" في قدرة "مدير إعلانات Google" على استخدام واجهة برمجة التطبيقات، شرط أن تكون واجهة برمجة التطبيقات متاحة للاستخدام. وبالتالي، يمكن للناشرين إجراء اختبارات أ/ب باستخدام وظائف سياسة الأذونات في Chrome لإيقاف استخدام واجهة برمجة التطبيقات في مجموعة فرعية من الزيارات لاستخدامها كمجموعة تحكّم في اختبار أ/ب. |
| تعلُم الآلة | يحتاج الناشرون إلى مزيد من التحكّم في الاستخدام المقترَح لخدمة "إدارة الأداء من Google" لتعلُّم الآلة. | الردّ المقدَّم من "مدير إعلانات Google": في كانون الثاني (يناير) 2024، أطلقنا عنصر تحكّم يمنح الناشرين إمكانية إيقاف أداة التحكّم في معدّل نقل البيانات المستندة إلى تعلُّم الآلة وتفعيل مزادات PA API مع البائعين غير التابعين لشركة Google على جميع زياراتهم. يمكنك الاطّلاع على مزيد من التفاصيل حول عنصر التحكّم هذا في مركز المساعدة. |
| (تم الإبلاغ عنها أيضًا في الربع سنوية السابقة) المزادات على مستوى القمة |
إمكانية استخدام خادم إعلانات الناشر من Google بدون منح "مدير إعلانات Google" أيضًا إمكانية التحكّم في مزاد واجهة برمجة التطبيقات PA API ذات المستوى الأعلى | الردّ المقدَّم من "مدير إعلانات Google": للأسباب الموضّحة في تقرير الربع الثالث من عام 2023 الصادر عن Google، لا تتضمّن خطط "مدير إعلانات Google" لدمج PA API مساعدة الناشرين الذين يستخدمون "مدير إعلانات Google" بخادم إعلانات الناشر بدون التحكّم في مزاد المستوى الأعلى. |
| إمكانية الوصول إلى المعلومات | يمكن لخدمة "إدارة الأداء من Google" الوصول إلى معلومات قيّمة من المنافسين، بما في ذلك أسعار المزاد السياقي والإشارات التي يقدّمها المشترون إلى منصّات عرض الإعلانات لمزاد PA API ومَعلمات الضبط من منصّات عرض الإعلانات. | الردّ المقدَّم من "إدارة إعلانات Google": لقد حافظنا على تركيز قوي على نزاهة المزاد لعدّة سنوات، بما في ذلك التزامنا بعدم مشاركة أي سعر من أيّ من مصادر الإعلانات غير المضمونة للناشر، بما في ذلك أسعار العناصر غير المضمونة، مع مشتري آخر قبل تقديم عروض أسعاره في المزاد، وهو ما أكدتّه لاحقًا في التزاماتنا تجاه هيئة المنافسة الفرنسية. بالنسبة إلى مزادات PA API، ننوي الوفاء بوعودنا وعدم مشاركة عرض سعر أيّ مشارك في المزاد مع أيّ مشارك آخر في المزاد قبل إكمال المزاد في المزادات التي تضمّ بائعين متعدّدين. للتوضيح، لن نشارك سعر المزاد السياقي مع أي مزاد مكوّن، بما في ذلك المزاد الخاص بنا، كما أوضحنا في هذا التعديل. بالإضافة إلى ذلك، لا نستخدم معلومات عن إعدادات مزادات المكوّنات، بما في ذلك الإشارات التي يقدّمها المشترون إلى منصّات عرض الإعلانات (SSP)، كجزء من مزادنا الخاص. في الواقع، نرحب بالتغييرات التي تطرأ على واجهة برمجة التطبيقات PA API والتي تسمح لبائعي المكوّنات بتحديد إعدادات مزادات المكوّنات بطريقة غير ظاهرة للبائع من المستوى الأعلى. |
| مزادات المكوّنات | وباعتباره المزاد على مستوى القمة، ستتحكّم "إدارة إعلانات Google" في منصّات عرض الإعلانات التي تجرِي مزادات المكوّنات لكلّ فرصة إعلانية. | الردّ المقدَّم من "مدير إعلانات Google": بصفته خادم إعلانات للناشرين، يوفّر "مدير إعلانات Google" واجهة برمجة تطبيقات خفيفة لخدمات عرض الإعلانات التي قد يعمل معها الناشر لتحديد إعدادات مزاد المكوّنات من خلال واجهة برمجة تطبيقات علامة الناشر من Google (GPT). يمكنك الاطّلاع على مزيد من التفاصيل هنا. إذا كانت خدمة SSP توفّر إعدادات مزاد مكوّنات من خلال واجهة برمجة التطبيقات هذه، سيتم تضمينها في قائمة مزادات المكوّنات لهذه الفرصة الإعلانية. لا تفرض "إدارة الأداء من Google" أي قيود على مزادات المكوّنات المضمّنة. سيتمكّن أيّ نظام عرض إعلانات يريد إجراء مزاد مكوّنات من إجراء ذلك، شرط أن يسمح له الناشر بتنفيذ الرمز البرمجي اللازم على صفحة الناشر. |
| مزادات المكوّنات | يمكن أن تطبّق "إدارة الأداء من Google" حدًا أدنى محدّدًا وغير مُعلَن عنه على كلّ عرض سعر فائِز في مزاد المكوّنات. | الردّ المقدَّم من "مدير إعلانات Google": حافظ "مدير إعلانات Google" على تركيز قوي على نزاهة المزاد لعدّة سنوات. في إطار الحفاظ على مزاد عادل وشفاف، لا نسمح بتطبيق الحد الأدنى للأسعار على شرائح معيّنة من الطلب فقط. هذا مبدأ ثابت في منتجنا وسيظل كذلك في مزادات PA API. |
| خوادم الإعلانات التابعة لجهات خارجية | لن تتمكّن خوادم الإعلانات التابعة لجهات خارجية من الوصول إلى مشاركة Google في المزاد الأعلى مستوى، ما يحدّ من قدرتها على الاستفادة من طلب Google SSP في سياق PA API. | الردّ المقدَّم من "مدير إعلانات Google": يتيح "مدير إعلانات Google" حاليًا اختبار PA API مع بائعين متعدّدين على "مدير إعلانات Google" من خلال واجهة برمجة التطبيقات الموضّحة هنا. لا تتوفّر حاليًا إمكانية مشاركة "مدير إعلانات Google" كمزاد مكوّن في مزادات أخرى من المستوى الأعلى. |
| (تمّ الإبلاغ عنها أيضًا في الربعَين السابقَين) أداء مزادات PA API |
تلقّينا تقارير من المختبِرين تفيد بأنّ مزادات PA API تستغرق وقت استجابة طويلاً. | لقد تلقّينا مخاوف بشأن وقت الاستجابة، وهذا هو أحد الأسباب التي دفعتنا إلى تطوير عدد من الميزات كجزء من PA API، ما سيتيح لخدمات عرض الإعلانات ضبط حدود على وقت استجابة وحدة معالجة الإدخال/الإخراج (DSP) وإجراء تحسينات يمكن أن تقلّل من وقت الاستجابة. لقد عدّلنا مؤخرًا دليل أفضل الممارسات المتعلّقة بوقت الاستجابة الذي يتضمّن مزيدًا من المعلومات حول كيفية الاستفادة من هذه الميزات. ونحن نواصل أيضًا تطوير تحسينات جديدة في وقت الاستجابة، ويمكن الاطّلاع على بعض منها هنا. |
| (تم الإبلاغ عنها أيضًا في الربع السابق) عرض الفيديو |
إتاحة عرض الفيديو باستخدام واجهة برمجة التطبيقات PA API وميزة "الإطارات المحدودَة" | في كانون الثاني (يناير)، نشرنا عرضًا توضيحيًا لكيفية عمل الإعلانات أثناء عرض الفيديو في مزاد الإعلانات الصورية، مع تفاصيل إضافية حول الأساليب البديلة. نلاحظ أيضًا أنّ الجهات المشاركة في المنظومة المتكاملة بدأت تقترح آلية عمل عرض الفيديو للشركاء الذين يدمجون هذه المنظومة، مثل الاقتراحات التي قدّمتها "إدارة الأداء من Google" بشأن إنشاء عناوين URL متوافقة مع عرض الفيديو أو العملية الكاملة من البداية إلى النهاية. بالإضافة إلى ذلك، نأخذ بعين الاعتبار الملاحظات التي تردّها المنظومة المتكاملة بشأن التغييرات التي يمكننا إجراؤها لزيادة معدّل الاستخدام، ويمكنك الاطّلاع على تفاصيل أحد هذه التغييرات في GitHub. نواصل العمل بنشاط مع المنظومة المتكاملة لتحديد أي عقبات أخرى قد تواجهنا في عملية الاستخدام ومعالجتها في الوقت المناسب. |
| (تم الإبلاغ عنها أيضًا في الأرباع السابقة) سياسة معالجة البيانات |
ما هي سياسة معالجة البيانات في IGs / PA API؟ | في تصميم واجهة برمجة التطبيقات PA API، تبقى جميع البيانات المخزّنة في مجموعات IG أو حول المستخدمين في مجموعات IG معيّنة (1) على الجهاز أو (2) تتم معالجتها في خدمات عروض الأسعار والمزادات (B&A) التي تعمل داخل بيئة تنفيذ موثوق بها (TEE). في كلتا الحالتَين، لا يمكن لأي أطراف أخرى قراءة البيانات أو استخدامها بأي طريقة أخرى غير إنشاء عروض أسعار في المزاد. تتطلّب بعض تحسينات الخصوصية التي يستكشفها Chrome التفاعل مع خادم خصوصية k الذي تديره Google. يتم تصميم هذا التفاعل بعناية لتجنّب مشاركة معلومات عن المستخدِمين، ولتنفيذه في بيئة آمنة للتشغيل (TEE) لضمان تكافؤ المعلومات في المنظومة المتكاملة للإعلانات. وقد التزمت Google أمام هيئة CMA بتصميم اقتراحات "مبادرة حماية الخصوصية" وتنفيذها بطريقة لا تشوه المنافسة من خلال منح الأولوية لنشاط Google التجاري، كما التزمت بمراعاة التأثير في المنافسة في الإعلانات الرقمية وعلى الناشرين والمعلنين. وسنواصل العمل عن كثب مع هيئة CMA لضمان امتثال عملنا لهذه الالتزامات. |
| (تم الإبلاغ عنها أيضًا في الربع سنوية السابقة) مدة عرض الإعلان على Instagram |
طلب تمديد مدة عرض إعلانات IG من 30 إلى 90 يومًا | يتطلّب هذا التغيير تقييمًا دقيقًا، مع موازنة المزايا التي تعود على المجال مقابل التأثير في مستخدمي Chrome والأطراف المعنية الأخرى. نحن ننظر في هذا الطلب ونرحّب بملاحظاتك الإضافية هنا. |
| (تم الإبلاغ عنها أيضًا في الأرباع السابقة) modelingSignals |
اطلب حقلًا جديدًا بالإضافة إلى نموذج الإشارات الذي يمكنه ترميز معلومات العرض والنقرات فقط. | لقد رددنا على هذه الملاحظات باقتراح مضاد هنا. نحن نتواصل بشكل نشط مع الجهات المعنية في المجال لمعرفة آرائهم بشأن اقتراحنا، ونوازن حاليًا بين المزايا التي تعود على المجال والتأثير على مستخدمي Chrome والجهات المعنية الأخرى. |
| أجزاء إضافية في reportWin() | قدِّم بتات إضافية في reportWin() من الحدّ الأقصى الحالي البالغ 12 بت قبل 3PCD. | نحن نستكشف حاليًا طرقًا لإتاحة هذه الحالة. يستغرق ذلك بعض الوقت لأنّنا نبحث أيضًا عن طرق يمكن أن تساعد في ضمان وضع خطة خصوصية طويلة المدى. |
| تصميم المزاد | طلبات لمزاد واحد يعرض عناوين URL للعرض مع النتيجة المقابلة لها | لقد فكّرنا في مشاركة عدّة عناوين URL لعرض الإعلانات ونتائجها المتعلّقة بها من مزاد واحد لإعلانات الصور المتحركة، ولكنّنا لم نفّذ ذلك بسبب مخاوف تتعلّق بالخصوصية. نحن نتفهّم الرغبة في تجنُّب عرض الإعلان نفسه عدة مرات للمستخدم على صفحة واحدة، ونرحّب بمزيد من المناقشة على GitHub. |
| reportWin | تسجيل حقول عشوائية في دالة reportWin() | ويتم إجراء ذلك حاليًا خلال فترة الاختبار. بعد أن يوقف Chrome نهائيًا استخدام ملفات 3PC، سيتم نقل إصدار forDebuggingOnly من واجهة برمجة التطبيقات لتفعيل تصحيح أخطاء العينة المنخفضة الدقة، كما هو موضّح هنا. |
| بائعو المكوّنات | أن تتضمّن آلية مستقلة لاحتساب مرّات الظهور والأحداث الأخرى، وألا تعتمد فقط على تقارير تكنولوجيات الإعلان | تم إدراج طلبك هذا في قائمة الانتظار لمزيد من المراجعة. لا نتوقّع معالجة هذه المشكلة خلال فترة الاختبار الذي يسهّله Chrome. |
| الفوترة حسب تكلفة النقرة | تنفيذ الفوترة حسب تكلفة النقرة في PA API | نحن ننظر في هذا الطلب هنا، ونعتبره حاليًا طلبًا للحصول على اقتراحات حول كيفية تنفيذه باستخدام واجهة برمجة التطبيقات الحالية. |
| browserSignals | أضِف incomingBidInSellerCurrency إلى مواصفات الإبلاغ عن browserSignals للبائع. | نحن ننظر في هذا الطلب ونرحّب بملاحظاتك الإضافية هنا. |
| إتاحة الملكية للبيانات الوصفية والمنطق على جانب الشراء في منصّات غير منصّات إدارة الأداء التسويقي | يمكن أن يؤدّي التصميم الحالي لواجهة برمجة التطبيقات إلى تغيير كبير في حملات إعادة الاستهداف على مستوى المنتج، حيث قد تحتاج الحملات إلى نقل البيانات إلى منصات تؤدي دور منصّات إدارة الأداء ومورّدي ميزة "تصميم الإعلان أثناء التشغيل". | نحن نناقش هذه المشكلة ونرحّب بملاحظاتك الإضافية هنا. |
| إتاحة البيانات الوصفية وملكية المنطق من جهة الشراء للأنظمة غير المستندة إلى عروض الأسعار | شارِك أمثلة على الحالات التي لا يكون فيها نظام إدارة الأداء هو مالك IG. | ندرك أنّ المعلِنين الذين لا يقدّمون عروض أسعار يريدون استخدام بعض وظائف عروض الأسعار على شبكة البحث، ولكن ليس وظائف أخرى. نحن نقيّم بشكل نشط خيارات معالجة حالات الاستخدام هذه ونرحّب بملاحظات إضافية هنا. |
| عناصر التحكّم في المُهلة | يجب أن يتمكّن الناشرون من تحديد عدد حسابات Instagram المؤهّلة للمشاركة والمهلة على مستوى التطبيق أو على مستوى البرنامج. | نحن ندرك أنّ هناك حاجة إلى عناصر تحكّم محسّنة في المهلة وإمكانية الاطّلاع على معلومات البائعين من المستوى الأعلى والبائعين المورّدين، ونحن ننظر في هذا الطلب. |
| أحجام إعلانات متعددة | إتاحة PA API لحالات استخدام "أحجام الإعلانات المتعدّدة" | نحن ننظر في هذا الطلب ونرحّب بملاحظات إضافية من المنظومة المتكاملة. |
| الوثائق | هل هناك قائمة بسمات IG التي تخضع لعملية k-anon؟ | لقد أجبنا عن هذا السؤال هنا. |
| تصحيح الأخطاء | إمكانات محسّنة لتصحيح الأخطاء في PA API | ندرك أهمية أدوات تصحيح الأخطاء الفعّالة للمطوّرين الذين يعملون مع PA API. نحن ملتزمون بتحسين تجربة المطوّرين من خلال استكشاف طرق دمج عمليات جلب الملفات المعروفة بتنسيق .well-known بشكل أفضل مع أدوات المطوّرين. نهدف إلى توفير المزيد من الإمكانيات لرصد المشاكل وحلّها في بيئة التطوير. نناقش هذه المشكلة بشكل أكبر هنا ونرحّب بملاحظات إضافية. |
| التصنيفات | هل تم تفعيل واجهات برمجة تطبيقات Privacy Sandbox API لدى جميع المستخدمين في تصنيفات المعالجة للوضع "ب"؟ | يتم تحديد عمليات إسناد مجموعات تجارب Chrome عشوائيًا وبشكل مستقل عن إعدادات Chrome التي يضبطها المستخدم. على الرغم من أنّ واجهات برمجة التطبيقات هذه قد تكون متاحة للمستخدمين ضمن مجموعات علاج معيّنة (مثل treatment_1.*)، يمكن تعديل وظائفها أو إيقافها من خلال إعدادات Chrome. مجموعة "الوضع ب"، المجموعة control_2: يؤدي تضمين هذه المجموعة إلى إيقاف واجهات برمجة التطبيقات لقياس الأداء ومدى الصلة بالموضوع في إطار Privacy Sandbox بشكلٍ تلقائي، ولا يمكن للمستخدم إلغاء هذا الإعداد ضمن إعدادات Chrome. |
| استخدام واجهة برمجة التطبيقات | هل يتمّ تنفيذ طلب reportWin() وعرض الإعلان بشكل متزامن أو بعد الآخر؟ | يتمّ استدعاء reportWin() مباشرةً بعد اكتمال runAdAuction(). وفي الوقت نفسه، قد تبدأ عملية عرض الإعلان عند وضع نتيجة المزاد داخل إطار iframe أو إطار محدود. بعد انتهاء تنفيذ reportWin() وبدء عرض الإعلان، سيتم جلب عناوين URL المقدَّمة إلى sendReportTo(). |
| (تم الإبلاغ عنها أيضًا في الربعَين السابقَين) دعم اختبار أ/ب |
طلب الحصول على دعم لاختبار أ/ب باستخدام PA API | نحن نناقش هذا الطلب هنا ونرحّب بملاحظاتك الإضافية. |
| تشكيل الزيارات | الاقتراح الذي قدّمته Google لإدارة عملية اتخاذ القرار المطلوبة من خلال خادم KV غير مفيد، لأنّ البائعين لا يمكنهم التفاعل مع الخلفية، ما يجعل من الصعب تشكيل الزيارات. | كما هو موضّح في مشكلة GitHub، قد يؤدي الكشف عمّا إذا كانت منصّات DSP الفردية تتضمّن ملفّات تعريف الارتباط بالعملاء إلى حدوث مشاكل في وضع بصمة المستخدم. لقد اقترحنا بدائل أخرى في المشكلة ونقبل المزيد من الاقتراحات. |
| تشكيل الزيارات | تضيف آليات التخزين المؤقت طبقة كبيرة من التعقيد وتمنع منصّات إدارة الأداء من معرفة الشكل الحقيقي للزيارات التي ستقدّم عروض أسعار لها. | تم اقتراح آلية التخزين المؤقت ببساطة. يمكن لتقنيات الإعلان اختيار استخدام الاقتراحات التي تخدم حالات استخدامها، ونرحّب بمناقشة إضافية هنا. |
| التصنيفات | من المفترض أن يشارك Chrome التصنيف كمَعلمة في الطلبات المرسَلة إلى الخوادم الموثوق بها الخاصة بالمشتري والبائع. | يبدو أنّ هذا الطلب معقول لأنّه يبدو متوافقًا بشكل عام مع هدف استخدام بيانات Instagram بشكل مسؤول. مع ذلك، نحن ننظر في الطلب، وهو يخضع لمراجعة داخلية، وسنقدّم معلومات عامة حول هذه المسألة مع تقدّم المناقشات. |
| استخدام واجهة برمجة التطبيقات | توضيح التعريف الواضح لمجموعة "control_1" في مستند "إرشادات إضافية بشأن موافقة المستخدِم النهائي (CMA) للجهات الخارجية بشأن الاختبار" على وجه التحديد، هناك قلق من أنّه قد يتم إساءة تفسير تغيير في الصياغة على أنّه يتطلب استبعاد جميع واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" من مجموعة التحكّم 1. | لقد أعربنا عن آراءنا حول هذا الموضوع في سلسلة المحادثات هذه على GitHub. ومع ذلك، ليس بإمكاننا التحدث نيابةً عن هيئة CMA، وننصح بطرح أي مشاكل بشأن تفسير إرشادات الاختبار مباشرةً مع هيئة CMA. |
| استخدام واجهة برمجة التطبيقات | هل سيسمح Chrome باستدعاء joinAdInterestGroup() على صفحة فارغة أثناء إعادة التوجيه إلى مورد آخر؟ | إذا كان أحد المستخدِمين يزور موقعًا إلكترونيًا معيّنًا، يمكن لمالك الموقع الإلكتروني تفويض إمكانية استدعاء joinAdInterestGroup لجهة خارجية. يتيح هذا التفويض لجهة خارجية إنشاء عناوين IP مؤقتة بدون الحاجة إلى إضافة أي نوع من عمليات إعادة التوجيه من خلال صفحة فارغة. نرحب بملاحظاتك بشأن الأسباب المحدّدة لإنشاء عناوين IP مؤقتة في منتصف عملية إعادة توجيه بدلاً من استخدام آلية التفويض المقصودة. |
| استخدام واجهة برمجة التطبيقات | يجب أن تكون التبادلات قادرة على كتابة ملفّات IG للصفحات التي يملكها الناشرون الذين يعملون معهم، وأن يتمكّنوا بعد ذلك من تفويض الإذن لتقديم عروض أسعار على ملفّ IG هذا لأيّ مشتري أو منصّة إدارة إعلانات معيّنة. | لقد تلقّينا الملاحظات ونحن نُقيّم ما إذا كان بإمكاننا دعم هذا الطلب. نرحب بملاحظات إضافية من المنظومة المتكاملة. |
| استخدام واجهة برمجة التطبيقات | لا يتم إرسال إشعار بفقدان بيانات تصحيح الأخطاء إذا لم يفوز أحد بمزاد PA API. | تم تصميم وظيفتَي reportWin وreportResult في Chrome لإعداد تقارير عن مرات الفوز على مستوى الحدث ضمن نظام مزاد الخصوصية (PA). في الحالات التي يتم فيها رفض جميع عروض الأسعار أثناء مزاد الإعلانات المتجاوبة، لا يُتوقّع أن يتمّ استدعاء هذه الدوالّ لأنّه لم يتمّ تحديد أيّ فائز. قد يوضّح تحديث Chrome الأخير التناقضات التي لا تظهر فيها عناوين URL التي تمّ تمريرها إلى forDebuggingOnly.reportAdAuctionLoss() في لوحة "الشبكة" في "أدوات المطوّر". ننصحك بالتحقّق من هذه الوظيفة باستخدام إصدار Chrome من قناة Canary أو قناة المطوّرين. |
| استخدام واجهة برمجة التطبيقات | هل يمكن أن تكون قيمة adCost التي يتم عرضها من generateBid سالبة (يتم تقريبها بشكل عشوائي إلى 2 بايت)؟ | AdCost هي تكلفة النقرة أو تكلفة الإحالة الناجحة للمعلِن التي تم تمريرها من generateBid() إلى reportWin(). يمكن أن تكون هذه القيمة فارغة أو عددًا مزدوجًا. وسيتم تجاهل القيم السلبية ولن يتم تمريرها. سيتم تقريب القيمة بشكل عشوائي عند تمريرها. |
| تحسين واجهة برمجة التطبيقات | هل يمكن استخدام خوادم التنفيذ الموثوق بها والمشفَّرة لمعالجة الاستهداف / المجموعات النموذجية / تحديد المصدر والمزادات بدلاً من متصفّح Chrome؟ | ننصحك باستكشاف المكوّنات والخيارات المستندة إلى TEE في PA API (مثل خوادم KV وخدمات B&A) بالإضافة إلى المكوّنات المستندة إلى TEE لإعداد تقارير تحديد المصدر والتجميع الخاص (مثل خدمة التجميع) التي تتناول هذا السؤال. |
| تحسين واجهة برمجة التطبيقات | هل يمكن أن يكون استجابة مزاد "مبادرة حماية الخصوصية" استجابة عرض سعر (مثل عروض أسعار الإعلانات على مستوى الصفحة) بدلاً من استجابة إعلان (مثل علامات الإعلانات)؟ | يغيّر هذا النوع من التغييرات بشكل أساسي خصائص الخصوصية لواجهة برمجة التطبيقات PA API، لذلك لا نفكر في إجراءه. |
| عناصر التحكّم للناشرين | هل يمكن للناشرين حظر تصميمات الإعلانات التي تستخدم واجهة برمجة التطبيقات PA API على صفحاتهم؟ | يقدّم Chrome اقتراحًا لفحص تصميمات الإعلانات في الوقت الفعلي غير المتاح للاختبار بعد. على الرغم من أنّ هذه الميزة غير متاحة بعد، لاحظنا أنّ معظم منصّات عرض الإعلانات (SSP) قد أنشأت حلولاً لتفعيلها. |
| استخدام واجهة برمجة التطبيقات | ما هو الحدّ الأقصى للحجم المسموح به لكلّ عنصر من عناصر perBuyerSignals؟ | في شكله الكلاسيكي، لا تفرض ميزة perBuyerSignals أيّ قيود أساسية على الحجم في Chrome. تتمثل القيود الأساسية في أنّ البيانات تظل قابلة للتسلسل بتنسيق JSON ولا تتسبب في استهلاك الذاكرة بشكل مفرط. ومع ذلك، تجدر الإشارة إلى أنّ الإشارات لكلّ مشتري الكبيرة جدًا والمعقدة قد تؤثر سلبًا في الأداء. تتوفّر طريقة بديلة لتمرير perBuyerSignals من خلال directFromSellerSignalsHeaderAdSlot. تنقل هذه الطريقة رسائل perBuyerSignals ضمن عنوان، مع مراعاة الحد الأقصى للحجم الذي يبلغ 10 كيلوبايت للاستجابة الكاملة للعنوان. بالإضافة إلى ذلك، قد تفرض الخوادم الفردية قيودها الخاصة على الحد الأقصى لحجم الرأس. |
| الوثائق | يجب تغيير المستندات المتعلّقة باستدعاء registerAdBeacon من داخل generateBid. | عدّلنا هذه المستندات في 17 شباط (فبراير). |
| استخدام واجهة برمجة التطبيقات | كيف يختار reportEvent عنوان URL الصحيح للإشارة من بين خيارات مسجّلة متعددة؟ | يؤدّي كل مزاد إلى إعدادات منفصلة، ما يؤدّي بدوره إلى إنشاء خريطة إعداد تقارير منفصلة. تكون المزادات الفردية (والإطارات الناتجة عنها) منفصلة تمامًا عن بعضها البعض، ولا تشارك البيانات. يقدّم الشرح عن "إعداد تقارير الإعلانات في الإطارات المُفصَّلة" مزيدًا من التفاصيل حول هذا الموضوع. |
| واجهة مستخدِم Chrome | إضافة فلتر في أدوات مطوّري البرامج في Chrome، في علامة التبويب "التطبيق -> مجموعات الاهتمامات"، للسماح بالفلترة حسب مالك مجموعة الاهتمامات (أو ربما أيضًا حسب اسم مجموعة الاهتمامات) | نحن بصدد تقييم هذا الطلب ونرحّب بملاحظات إضافية من المنظومة المتكاملة. |
| Chrome بلا واجهة مستخدم رسومية | إتاحة واجهة برمجة التطبيقات PA API في Chrome بلا واجهة مستخدم رسومية | هناك بعض مكوّنات PA API المرتبطة بمتصفّح Chrome، مثل طلبات k-anon إلى خوادم Google، والتي قد لا تعمل في الإصدار "القديم" من Headless Chrome. نعتقد أنّه يمكن معالجة هذه المشكلة من خلال الإصدار "الجديد" من Headless Chrome الذي تم إصداره في Chrome 112. |
| استخدام واجهة برمجة التطبيقات | في ما يتعلّق بإعداد تقارير الخسارة باستخدام reportAdAuctionLoss، نرى "topLevelWinningBid=0" في العديد من الحالات. ما هو تفسير ذلك؟ | تأتي قيمة topLevelWinningBid من الدالة scoreAd() ضمن مكوّن البائع من المستوى الأعلى. تلعب هذه القيمة دورًا في تحديد نتيجة المزاد على مستوى القمة. وفقًا للشرح، تشير قيمة topLevelWinningBid التي تساوي صفرًا أو أي رقم سلبي إلى أنّ الإعلان المقابل غير مؤهَّل للفوز بالمزاد. يمكن استخدام هذه الآلية، على سبيل المثال، لفلترة الإعلانات المستهدَفة حسب مجموعات الاهتمامات التي لا تتجاوز مرشّحًا مستهدَفًا حسب السياق. على الرغم من أنّ القيمة صفر في topLevelWinningBid قد تشير إلى أنّ مزادًا سياقيًا قد انتصر، فإنّ مواصفات PA API تعترف بأنّ عوامل أخرى يمكن أن تساهم في هذه النتيجة. |
| اختبار A/B في الوضع | توضيح بشأن طلبات اختيار ورفض الزيارات في الوضع "ب" والوضع "أ" | معايير الإدراج في الوضع "أ" والوضع "ب" متطابقة. والهدف من ذلك هو الحصول على مجموعات تمثّل عدد الزيارات العادية على Chrome طالما أنّها متوافقة مع واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" وطريقة وضع التصنيفات، لأنّ بعض إعدادات العملاء غير متوافقة. لأغراض التجربة، من المهم مقارنة الزيارات المصنّفة فقط بالزيارات المصنّفة الأخرى. يكون لدى المستخدمين في "الوضع ب" ميزة "الحماية من التتبّع" مفعّلة، وبالتالي يتلقّون إشعارًا بشأن هذه الميزة. |
| تحسين واجهة برمجة التطبيقات | هل يمكن تضمين lifetimeMs كخاصية مباشرة ضمن طلب joinAdInterestGroup أو إدارتها كوسيطة منفصلة؟ | نحن نأخذ في الاعتبار بعناية الملاحظات الواردة من منتدى تطوير الويب بشأن وظيفة joinAdInterestGroup ضمن اقتراح PA API. تركّز إحدى نقاط المناقشة الرئيسية على الطريقة المثلى لإدارة مدّة عرض الإعلانات على Instagram. نحن نُقيّم مزايا استخدام مَعلمة منفصلة للمَعلمة lifetimeMs، لأنّها تعزّز المرونة والتكيّف مع التحسينات المستقبلية المحتملة للمواصفات. نحن نناقش هذه المشكلة هنا ونرحّب بملاحظات إضافية. |
| استخدام واجهة برمجة التطبيقات | احتمالية زيادة معدّلات النتائج السلبية الخاطئة في إطار عمل PA API بسبب حدوث تداخل مع معرّفات المتصفّحات ذات التشويش المنخفض | يشارك فريق Chrome بنشاط في عملية التحسين المستمرة لإطار عمل PA API. نشكرك على المناقشة حول معدّلات النتائج السلبية الخاطئة المحتمَلة الناتجة عن تعارض معرّفات المتصفّحات. نحن نقيّم هذه الملاحظات بعناية وسنعمل على التأكّد من أنّ التحليلات المعدّلة تعكس بشكل شامل جميع العوامل ذات الصلة. ونلتزم بتقديم حلّ يحقّق النتائج المطلوبة في ما يتعلّق بالخصوصية مع الحفاظ على الدقة والموثوقية. نحن نناقش هذه المشكلة هنا ونرحّب بملاحظاتك الإضافية. |
| استخدام واجهة برمجة التطبيقات | هل يجب استخدام معرّف متصفّح منخفض التشويش لمنع العملاء من إرسال طلبات "الانضمام" بشكل متكرّر للعنصر نفسه في نظام "المجانية الكاملة للبيانات"؟ | نحن ندرك ونقدّر المناقشة الجارية بشأن استخدام معرّفات المتصفّح في تنفيذ أنظمة "المجهولة الهوية بعامل k". نحن نتفهّم المخاوف التي تمّ التعبير عنها بشأن الآثار المحتملة على الخصوصية لهذه المعرّفات. على الرغم من أنّ عملية التنفيذ الأولية استخدمت معرّفًا منخفضًا من حيث التشويش كآلية لمكافحة إساءة الاستخدام، فإنّنا نستكشف بنشاط أساليب بديلة، مثل "الرموز المميّزة لعمليات الاحتساب المجهولة الهوية"، التي تعطي الأولوية لخصوصية المستخدم مع الحفاظ على سلامة النظام. نحن ملتزمون بإيجاد حلول توازن بين استخدام البيانات بمسؤولية وإجراءات حماية الخصوصية القوية، ونرحّب بالحوار المستمر مع منتدى الأبحاث. نناقش هذه المشكلة هنا ونرحّب بملاحظاتك الإضافية. |
| استخدام واجهة برمجة التطبيقات | هل تتوافق صفحات AMP (Accelerated Mobile Pages) مع واجهة برمجة التطبيقات PA API؟ | لا يتيح معيار AMP حاليًا استخدام واجهة برمجة التطبيقات PA API. نرحب بملاحظات إضافية من المنظومة المتكاملة إذا كان توفير الدعم من خلال AMP يُعدّ من الأولويات العالية. |
| تحسين واجهة برمجة التطبيقات | ننصحك بإزالة النوع من عمليات التحقّق من إخفاء الهوية وفقًا لعدد k. | نحن نأخذ في الاعتبار بعناية الملاحظات والآراء بشأن تحسين هياكل طلبات إخفاء الهوية وفقًا لعدد k. نحن نتفهّم اقتراح دمج المَعلمات وتوحيد الأنواع إن أمكن لتبسيط العملية. هدفنا هو ضمان الكفاءة وسهولة الصيانة، ونحن نُقيّم جميع الخيارات بينما نواصل تطوير حلول الخصوصية. نحن نناقش هذه المشكلة هنا ونرحّب بملاحظات إضافية. |
| واجهة مستخدِم Chrome | طلب توفير آلية للمستخدمين الأقل خبرة في مجال التكنولوجيا لعرض وإدارة المجموعات التي ينتمون إليها بسهولة، بما في ذلك عناصر التحكّم المحتملة على مستوى الموقع الإلكتروني لإيقاف هذه المجموعات | ندرك أهمية توفير أدوات سهلة الاستخدام لفهم مجموعات IG وإدارتها. لقد فكّرنا جيدًا في طرق مختلفة وتبيّن لنا أنّ تحديد حسابات IG من خلال الموقع الإلكتروني الذي تم الانضمام إليه يقدّم أفضل توازن بين الوضوح وحماية الخصوصية. يمكن حاليًا العثور على الإدارة الشاملة لتطبيقات IG في إعدادات Chrome. نحن نستكشف باستمرار طرقًا لتحسين تجربة المستخدم في هذا المجال. نحن نناقش هذه المشكلة هنا ونرحّب بملاحظاتك الإضافية. |
| أمان واجهات برمجة التطبيقات | هل تتعرّض PA API لتسريبات الخصوصية من خلال التفاعلات مع تصميمات الإعلانات، حتى في سياق استخدام "الإطارات المحدودَة"؟ | ندرك إمكانية تسرُّب المعلومات من خلال التفاعلات المعقدة مع الإعلانات. نحن نحقّق بنشاط في التفاعل بين "اللقطات المُغلقة" و"واجهة برمجة التطبيقات لإعلانات الأداء" ووسائل الهجوم المحتملة. إنّ الحدّ من مخاطر الخصوصية هو من أهم أولوياتنا، ونحن ملتزمون بتطوير حلول فعّالة توازن بين الابتكار وحماية المستخدمين. نحن نناقش هذه المشكلة هنا ونرحّب بملاحظاتك الإضافية. |
| استغرق الرد وقتًا طويلاً | هل المدة التلقائية التي تبلغ 50 ملي ثانية لمهلة منطق عروض أسعار المشترين هي قيمة واقعية؟ | ندرك المخاوف التي تمّ التعبير عنها بشأن التناقضات المحتمَلة بين المواصفات وتوقيت طلبات الشبكة لعرض منطق عروض الأسعار. نحن نراجع المواصفات بنشاط لضمان دقتها ونبحث في إعدادات المهلة التلقائية المثلى لتحقيق التوازن بين الأداء وإمكانية التنفيذ. نحن نناقش هذه المشكلة هنا ونرحّب بملاحظات إضافية. |
| الوثائق | تسرُّب محتمل للتوقيت في المواصفات التي يمكن لموقع إلكتروني من خلالها استنتاج ما إذا كان الإعلان قد تعذّر عليه استيفاء الحدّ الأدنى لمتطلبات إخفاء الهوية وفقًا لعدد k، والآثار المحتملة للتتبّع على مستوى المواقع الإلكترونية | ندرك المشكلة التي تمّ الإبلاغ عنها بشأن تسرُّب محتمل للوقت. لقد تأكّدنا من وجود تناقض في المواصفات ونتّخذ خطوات لضمان تحديد حالة "المعادلة الاحتمالية k" للإعلانات قبل المزاد لمنع حدوث مثل هذه التسريبات. نحن نأخذ هذه المخاوف على محمل الجدّ وسنعدّل المواصفات لتعكس هذه التغييرات. نحن نناقش هذه المشكلة هنا ونرحّب بملاحظات إضافية. |
| استخدام واجهة برمجة التطبيقات | طرق تنفيذ قائمة محظورة لخدمات SSP ضمن PA API | ندرك الحاجة إلى آليات لإدارة القيود المفروضة على الإعلانات من خلال منصّات عرض الإعلانات. ننصحك باستكشاف الحلول التي تمنح الأولوية للتقييم على الجهاز فقط وتستفيد من البيانات الوصفية الحالية للإعلانات لحماية خصوصية المستخدمين مع توفير المرونة. نحن ملتزمون بالعمل مع المطوّرين لتحديد الأساليب المثلى ضمن PA API. نحن نناقش هذه المشكلة هنا ونرحّب بملاحظاتك الإضافية. |
| استخدام واجهة برمجة التطبيقات | هل يمكن لأحد أن يطلب من المتصفّح أن يتظاهر باستخدام واجهة برمجة التطبيقات PA API بطريقة لا يمكن للمواقع الإلكترونية رصدها؟ | ندرك أنّه بإمكان المواقع الإلكترونية رصد إيقاف واجهة برمجة التطبيقات PA API بصورتها الحالية. نحن نعمل جاهدين على ميزات مثل عروض الأسعار الإضافية والاستهداف السلبي، إلى جانب عرض الإطارات المحدود، لتحسين الخصوصية والعمل على توفير خيارات إيقاف لا يمكن رصدها. نحن نناقش هذه المشكلة هنا ونرحّب بملاحظاتك الإضافية. |
| اختبار A/B في الوضع | عدد زيارات مركز البيانات التي يُزعَم أنّها معالجة 1.1 | أكّد فريق Chrome لفريق "إحصاءات Google للإعلانات" أنّه يتم الآن فلترة هذه الزيارات من التجربة. نحن نناقش هذه المشكلة هنا ونرحّب بملاحظاتك الإضافية. |
| استخدام واجهة برمجة التطبيقات | كفاءة ونزاهة تنفيذ interestGroupBuyers في PA API | ندرك المناقشة الجارية حول كفاءة حقل "interestGroupBuyers" وعدالته في مزادات PA API. ندرك التوازن بين الكفاءة والخصوصية والعدالة في السوق. على الرغم من أنّ البائعين يحتاجون إلى إدارة العلاقات التجارية مع المشترين، نحن نستكشف طرقًا لتحسين عملية المطابقة. وقد تشمل هذه التعديلات الديناميكية استنادًا إلى البيانات في الوقت الفعلي والنماذج المختلطة. ما زلنا ملتزمين بإيجاد حلول تعطي الأولوية لخصوصية المستخدمين وتوفّر منظومة متكاملة للإعلانات تنافسية. نحن نناقش هذه المشكلة هنا ونرحّب بملاحظات إضافية. |
| واجهة مستخدِم Chrome | مشاكل محتملة في الذاكرة ووضوح واجهة المستخدم في تطبيق Instagram على Chrome | نحن نتفهّم المخاوف التي تمّ التعبير عنها بشأن عرض رسائل IG في "أدوات المطوّرين". على الرغم من أنّ العرض الحالي يعرض جميع أحداث IG للتتبُّع السابق، ندرك أهمية توفير رؤية أوضح للحالة الحالية لأحداث IG المخزّنة. سنستكشف التحسينات المحتملة على واجهة المستخدم لتحسين إحصاءات المطوّرين. في ما يتعلق بإدارة الذاكرة، تم تصميم عملية تنفيذ IG لمنع تسرب الذاكرة، ولكننا نرصد استخدام الموارد باستمرار ونحسّنه. نحن نناقش هذه المشكلة هنا ونرحّب بملاحظات إضافية. |
| الوثائق | يواجه المعلِن الأصلي خطأً عند محاولة استخدام أحجام إعلانات مُسمّاة مباشرةً في حقل sizeGroup للدالة joinAdInterestGroup. يريدون معرفة ما إذا كان هذا السلوك مقصودًا. | ندرك قيمة تبسيط إعداد الإعلانات ضمن الدالة joinAdInterestGroup. نحن نعمل جاهدين على معالجة هذا القيد ونخطّط لتفعيل هذه الوظيفة في التحديثات المستقبلية. يتوافق هذا التحسين مع التزامنا بتزويد المطوّرين بأدوات مرنة وفعّالة لإدارة الإعلانات. نحن نناقش هذه المشكلة هنا ونرحّب بملاحظاتك الإضافية. |
| تصنيف الاختبار المُبسَّط في Chrome | يُرجى طلب الحصول على بيانات مباشرة عن الوضع "أ" مقارنةً بالوضع "ب" والعلامات الدقيقة في sendReportTo حتى نتمكّن من تتبُّع التجربة بشكلٍ متّسق. | نحن نناقش هذا الطلب هنا ونرحّب بملاحظاتك الإضافية. |
| الوثائق | هل يتم تضمين اسم نطاق البائع في الطلبات المقدَّمة إلى خادم موثوق به للبائع لأغراض التحقّق من الصحة؟ | ندرك أنّه تم حذف مَعلمة hostname في البداية من مستندات Protected Audience KV Server API. نريد أن نطمئن المطوّرين بأنّه يتم تلقائيًا تضمين اسم نطاق البائع في الطلبات المرسَلة إلى خادم البائع الموثوق به. هذه الوظيفة ضرورية لعمليات التحقّق القوية من الإعلانات. لقد عدّلنا المستندات لحلّ هذه المشكلة، وسنواصل منح الأولوية للوضوح والشفافية في منتدى المطوّرين. نحن نناقش هذه المشكلة هنا ونرحّب بملاحظاتك الإضافية. |
| استخدام واجهة برمجة التطبيقات | الطرق المحتملة لتضمين اسم IG ضمن طلبات تتبُّع مرّات ظهور الإعلانات لأغراض إعداد التقارير | نحن ملتزمون بموازنة الحاجة إلى آليات إعداد تقارير فعّالة مع المبدأ الأساسي لخصوصية المستخدم. يخضع تضمين أسماء مستخدمي Instagram في تتبُّع مرّات ظهور الإعلانات لتدابير وقائية مصمّمة لمنع تحديد هوية الأفراد. سنواصل استكشاف حلول مبتكرة لإعداد التقارير ضمن هذه القيود المتعلقة بالخصوصية. نحن نناقش هذه المشكلة هنا ونرحّب بملاحظاتك الإضافية. |
| ميزة واجهة برمجة التطبيقات | اطلب من الخادم الموثوق به للمشتري تلقّي عناوين HTTP الخاصة بـ "ملاحظات العميل". | يمكنك تتبُّع طلب هذه الميزة هنا. |
| استخدام واجهة برمجة التطبيقات | ما إذا كان يجب أن يتطلّب ملف التفويض تحميل العنوان Access-Control-Allow-Origin، نظرًا لأنّه يحدّد سلوك الاشتراك في Instagram للمتصفح؟ | نحن ملتزمون بالالتزام بأفضل ممارسات أمان الويب. يضمن شرط استخدام عنوان Access-Control-Allow-Origin لملفات التفويض التوافق مع مبادئ CORS ويمنع الكشف غير المقصود عن المعلومات الحساسة. نحن نستكشف طرقًا لتحسين هذه العملية مع الحفاظ على مستوى أمان عالٍ. نحن نناقش هذه المشكلة هنا ونرحّب بملاحظاتك الإضافية. |
| استخدام واجهة برمجة التطبيقات | فعِّل خوادم الإعلانات لتخصيص تصميمات الإعلانات ضمن إطار عمل PA API. | ندرك الدور الذي يمكن أن تلعبه خوادم الإعلانات في تخصيص المواد الإبداعية. نحن نستكشف بنشاط حلولاً لمنح خوادم الإعلانات مزيدًا من الإمكانيات ضمن PA API، مثل نموذج "IG المشترك" الذي يمكن من خلاله دمج منطق عروض الأسعار ومنطق اختيار تصميم الإعلان. هدفنا هو تحقيق التوازن بين تفعيل إمكانات قوية لتصميم الإعلانات وحماية خصوصية المستخدمين. ونرحّب بمزيد من التعاون والملاحظات حول تطوير واجهة برمجة التطبيقات لتلبية احتياجات جميع الجهات المعنيّة هنا. |
| مشاكل الخصوصية | توفُّر معرّفات بديلة (مثل RampID وID5) في طلبات عروض الأسعار السياقية قد تؤدي إلى تقويض أهداف الخصوصية في PA API من خلال تسهيل جمع البيانات على مستوى المواقع الإلكترونية. | ندرك التعارض المحتمل بين المعرّفات على مستوى المواقع الإلكترونية وأهداف الخصوصية في PA API. على الرغم من أنّه يمكن للناشرين اختيار مشاركة هذه المعرّفات، يهدف تصميم PA API بشكل أساسي إلى فصل اختيار الإعلان عن الحاجة إلى التتبّع على مستوى المواقع الإلكترونية. نحن ملتزمون بتعزيز منظومة إعلانية متكاملة تركّز على الخصوصية، ونشجّع المطوّرين على إعطاء الأولوية لنهج PA API. نحن نناقش هذه المشكلة هنا ونرحّب بملاحظات إضافية. |
| التخزين المؤقت | هل هناك طريقة لمنع إعادة استخدام نصوص عروض الأسعار في مزادات متعددة؟ | ندرك سلوك التخزين المؤقت الذي لوحظ في نصوص عروض الأسعار ضمن إطار عمل PA API. على الرغم من توفّر آليات التخزين المؤقت العادية لبروتوكول HTTP، إلا أنّ إمكانية إعادة استخدام النصوص البرمجية في جميع المزادات واردة بسبب سلوك تعليق الجهاز وتصميم منفّذِي عروض الأسعار. يبحث الفريق عن حلول لمنح المشترين قدرة أكبر على التحكّم في التخزين المؤقت للنصوص البرمجية لإدارة استراتيجيات عروض أسعارهم بفعالية. نحن نناقش هذه المشكلة هنا ونرحّب بملاحظات إضافية. |
| استخدام واجهة برمجة التطبيقات | تركيز إعداد تقارير نشاط عروض الأسعار على مستوى جميع منصّات عرض الإعلانات (IG) لنظام إدارة الأداء (DSP)، مع الحفاظ على خصوصية المستخدِم | نمنح الأولوية لخصوصية المستخدم عند تصميم واجهة برمجة التطبيقات PA API. على الرغم من أنّه لا يمكن إعداد تقارير مباشرة عن أحداث عروض الأسعار الفردية بسبب مخاطر التتبّع على مستوى المواقع الإلكترونية، نقدّم آليات مثل "مساحة التخزين المشتركة" و"التجميع الخاص". تتيح هذه الميزة لمنصّات إدارة الأداء (DSP) الحصول على إحصاءات مجمّعة عن نشاط عروض الأسعار، بطريقة تحافظ على خصوصية المستخدِم. |
| استخدام واجهة برمجة التطبيقات | لا يحدث الجلب من sendReportTo() في reportResult() إلا بنسبة% 94 من الوقت مقارنةً بالحصول على عملية جلب مسجّلة باستخدام forDebuggingOnly.reportAdAuctionWin(). | على الرغم من أنّهما قد لا يتطابقان في التوقيت، من الممكن جلب عنوانَي URL في الوقت نفسه. في بعض الحالات، تمّ التخلص من وحدة عمل بائع المكوّن ويجب إعادة تحميلها لتنفيذ الدالة reportResult() بعد ذلك. ومع ذلك، لا يؤثّر الوقت المستغرَق في جلب منطق التقييم ولا وقت إعادة تحميل وحدة العمل في مهلة 50 ملي ثانية لـ reportResult(). يُرجى العِلم أنّ Chrome سيستخدم رؤوس التخزين المؤقت لتحديد سلوك الجلب في الحالات التي يجب فيها إعادة تحميل وحدة العمل. يمكنك الاطّلاع على مزيد من المعلومات عن مراحل مزاد الإعلانات الصورية هنا. |
| إخفاء الهوية وفقًا لعدد "ك" | طلب تأكيد أنّ اسم مجموعة الاهتمامات لا يؤثر في مستوى إخفاء الهوية من خلال k لعرض الإعلانات | لكي يُعتبَر تصميم الإعلان مجهول الهوية بدرجة k، يجب أن تستوفي مجموعة عناوين URL الخاصة بمالك حساب IG وعنوان URL لنص عروض الأسعار وعنوان URL لتصميم الإعلان وحجم الإعلان الحدّ الأدنى المحدّد (k) على مدار فترة زمنية سابقة (w). يتم تعديل حالة "المعلومات المجهولة الهوية بدرجة k" بشكل دوري (p). |
| واجهة مستخدِم Chrome | اقتراح لتقديم نوع "مستوى الرؤية الداخلي" الذي تقدّمه الكثير من إطارات عمل MVC وORM وما إلى ذلك على سبيل المثال، ابدأ بتسجيل بسيط للأحداث الداخلية المحدّدة في لوحة جديدة في قسم "أدوات المطوّرين" --> التطبيق --> التطبيق. | نحن نناقش الاقتراح هنا ونرحّب بملاحظاتك الإضافية. |
| واجهة مستخدِم Chrome | لا يعرض الانضمام إلى أدوات المطوّرين في IG العناصر ذات الصلة بالأولوية. | لقد عالجنا هذه المشكلة هنا. |
| تحسين واجهة برمجة التطبيقات | من الأفضل السماح لخادم إعلانات تصميم الإعلان بتتبُّع أحداثه الخاصة. هل يمكن ضبط قائمة بنطاقات التتبّع المسموح بها؟ | لقد شاركنا اقتراحًا هنا ونرحّب بملاحظات إضافية من المنظومة المتكاملة. |
| طلب ميزة واجهة برمجة التطبيقات | هل يمكن توسيع نطاق PA API لتتوافق مع معاملات الوسائط غير المستندة إلى عروض الأسعار في الوقت الفعلي والحفاظ على حالات الاستخدام المهمة، مثل عرض الإعلانات وDCO؟ | نحن نناقش المشكلة هنا ونرحّب بملاحظاتك الإضافية. |
| مهلة مزاد الناشر | يحتاج الناشرون إلى التحكّم في مدة المزاد لمنع فقدان مرّات الظهور، لا سيما في عمليات إعداد عروض الأسعار في العنوان التي يتم فيها اختيار الإعلانات بشكل تسلسلي. | ندرك أهمية منح الناشرين إمكانية التحكّم بشكل دقيق في مهلات المزاد الإعلاني. نحن نستكشف بنشاط كيفية تنفيذ آلية وقت الاستراحة الشاملة للمزاد، والتي قد تكون ضمن العنصر auctionConfig، مع مراعاة الحالات القصوى بعناية. تهدف هذه الميزة إلى تحسين معدّلات ملء مرات الظهور للناشرين، وسنواصل التعاون مع المنتدى للعثور على أفضل حلّ. نحن نناقش المشكلة هنا ونرحّب بملاحظاتك الإضافية. |
| تحسين واجهة برمجة التطبيقات | يؤدي التصميم الحالي لعناصر IG في PA API إلى أحجام كبيرة للبيانات الوصفية بسبب طول renderURLs. يريد المختبِرون طريقة لضغط عناوين URL هذه لزيادة الكفاءة. | ندرك أهمية تحسين حجم البيانات الوصفية في Instagram، لا سيما في مزادات الإعلانات الحسّاسة للكفاءة. نعتقد أنّ الحلّ المستنِد إلى النماذج لضغط renderURLs يقدّم إمكانات كبيرة. سنقيّم بعناية تصاميم النماذج المقترَحة ونضمن أنّ أي حلّ يتم تنفيذه يتضمّن آليات فعّالة لمنع إساءة الاستخدام والحفاظ على ثبات المتصفّح. تظلّ التعاون مع منتدى معايير الويب لتطوير النهج الأمثل، مع مراعاة هذه الاعتبارات، من الأولويات. نحن نناقش المشكلة هنا ونرحّب بملاحظاتك الإضافية. |
| استخدام واجهة برمجة التطبيقات | يريد المختبِرون الذين يتعاملون مع أشكال الإعلانات المدمجة تحسين عملية مزاد "مبادرة حماية الخصوصية" من خلال استرداد نتائج إعلانات متعدّدة في طلب واحد لتقليل عبء الشبكة وتحسين سرعة عرض الإعلانات. | ندرك المخاوف بشأن الأداء التي تمّ التعبير عنها في ما يتعلّق بعرض الإعلانات المدمجة في "مبادرة حماية الخصوصية". نحن ملتزمون بتحقيق التوازن بين الكفاءة وتوفير إجراءات قوية لحماية خصوصية المستخدمين. مع أنّ عرض إعلانات متعددة بنتائج كاملة يشكّل تهديدًا للخصوصية، فإنّنا نستكشف بنشاط طرقًا لتحسين عملية المزاد. نحن ملتزمون بتحسين إتاحة PA API لتنسيقات الإعلانات المدمجة والبحث عن آليات بديلة لتحسين الكفاءة ضمن قيود الخصوصية القوية في "مبادرة حماية الخصوصية". نحن نناقش المشكلة هنا ونرحّب بملاحظاتك الإضافية. |
| استخدام واجهة برمجة التطبيقات | مرونة في كيفية احتساب عروض الأسعار للإعلانات وترتيبها ضمن "مبادرة حماية الخصوصية"، خاصةً لتمثيل مستويات الأولوية أو قواعد السوق الخاصة | نحن ندرك الحاجة إلى التحكّم الدقيق في تقييم الإعلانات وترتيبها ضمن "مبادرة حماية الخصوصية"، لا سيما في سيناريوهات عروض الأسعار المعقّدة. ندرك أنّ الحلول المقترَحة تستخدِم مجموعات ثنائية ووظائف رياضية لتحقيق تقييمات متعددة الأبعاد بدون المساس بخصوصية المستخدم. على الرغم من أنّ هذه الأساليب قد تزيد من تعقيد عمل المطوّرين، إلا أنّها توفّر التعبير اللازم. نحن ملتزمون باستكشاف طرق لتبسيط هذه العمليات، ربما من خلال وظائف أو إرشادات مساعدة، لضمان الاستخدام الأمثل لميزات "مبادرة حماية الخصوصية" لمنطق المزاد المتقدّم. نحن نناقش هذه المشكلة هنا ونرحّب بملاحظاتك الإضافية. |
| reportEvent() | أضِف حدثًا محجوزًا جديدًا (ربما إشارة تلقائية) يُطلقه المتصفّح بعد بدء إطار يتضمّن تصميم إعلان. | نحن نناقش هذا الطلب هنا ونرحّب بملاحظاتك الإضافية. |
| adCost | السماح بتقسيم adCost | كل قيمة تكلفة هي فرصة لإرسال قدر محدود من المعلومات خارج المزاد. إنّ السماح بقائمة كاملة من "ن" من هذه التكاليف سيكون كافيًا لإرسال معرّف مستخدم كامل، ما سيتيح التتبّع على مستوى المواقع الإلكترونية. نناقش هذه المشكلة هنا ونرحّب بملاحظاتك الإضافية. |
| resolveToConfig | هل يجب اكتساب resolveToConfig من المستوى الأعلى وعرضها في browserSignals؟ | نحن نناقش هذا الطلب هنا ونرحّب بملاحظاتك الإضافية. |
| أدوات أفضل | هل هناك رابط مشابه لـ chrome://topics-internals ولكن لواجهة برمجة التطبيقات PA API؟ | لا تتطابق الرسالتان تمامًا. ومع ذلك، تتوفّر أدوات مطوّرين مكثّفة لـ PA API. |
| التصنيفات | هل يمكن لمتصفّح Chrome استخدام التصنيفات لتحديد مجموعة 20% من k-anon؟ | نحن ننظر في هذا الطلب ونرحّب بملاحظات إضافية من المنظومة المتكاملة. |
| الوثائق | هل ستصبح وحدات عمل المزادات في "مبادرة حماية الخصوصية" أنواعًا عادية من وحدات العمل؟ | بسبب متطلبات الخصوصية والأمان الفريدة، تختلف هذه الوحدات عن أنواع وحدات العمل العادية في المتصفّح، لذا لا نتوقّع أن تصبح أنواع وحدات عمل عادية ضمن مواصفات HTML قريبًا. نحن ملتزمون بتحسين موارد المطوّرين من خلال تقديم تفسيرات واضحة حول بيئة تنفيذ وحدات عمل المزادات وتنفيذها، ما يسهّل وصول المشاركين في إطار عمل "الخصوصية أولاً" إلى هذه المعلومات. لقد ناقشنا هذا الأمر بالتفصيل هنا. |
| خادم "استخدم الخادم الذي تملكّه" (BYOS) لنظام "المفتاح/القيمة" (KV) | قد يتمكّن الطرفان من الاطّلاع على مجموعات IG متعددة (من المالك نفسه) انضم إليها مستخدم من خلال طلبات بحث خدمات KV في عملية إعداد خدمة KV في BYOS. | لن يعود هذا ممكنًا عندما يتم تشغيل خوادم KV في وحدات TEE ويمكننا التأكّد من أنّها يمكنها الالتزام بنموذج الثقة المنشور. |
| userBiddingSignals | تعديل جزء من "إشارات عروض أسعار المستخدِمين" مع الاحتفاظ بأخرى | وهذا ممكن حاليًا بدون الحاجة إلى إجراء أي تغييرات على واجهة برمجة التطبيقات. |
| استخدام واجهة برمجة التطبيقات | تنفيذ الحدّ الأقصى لعدد مرّات الظهور على مستوى حسابات IG متعددة ضمن "مبادرة حماية الخصوصية"، وذلك باستخدام خادم KV أو بيانات "prevWinsMs" المعدّلة. | ندرك الرغبة في الحصول على إمكانات متقدّمة لضبط معدّل الظهور ضمن "مبادرة حماية الخصوصية". ندرك أنّ القيود الحالية المفروضة على مشاركة البيانات في جميع المؤسسات الحكومية قد تشكل تحديات عند تنفيذ هذه الاستراتيجيات. على الرغم من أنّ خادم KV يقدّم آلية محتملة تتضمّن إجراءات حماية الخصوصية المناسبة، نشجّع المطوّرين على استكشاف الحلول ضمن نموذج IG واحد. نحن نناقش هذه المشكلة هنا ونرحّب بملاحظاتك الإضافية. |
| استخدام واجهة برمجة التطبيقات | يحتاج بائعو المكوّنات (الذين يشاركون في مزادات متداخلة ضمن "مبادرة حماية الخصوصية") إلى الاطّلاع على مهلات المزاد على مستوى أعلى لتحسين إعداداتهم الخاصة وتجنُّب التأخيرات غير الضرورية. | ندرك الحاجة إلى تحسين التنسيق في ما يتعلّق بالمهلة بين البائعين من المستوى الأعلى وبائعي المكوّنات في "مبادرة حماية الخصوصية". نحن نبحث بنشاط عن إضافة آليات وقت انتظار جديدة، بما في ذلك وقت انتظار محتمل للمزاد بأكمله واستكشاف طرق لتطبيق أوقات الانتظار ذات المستوى الأعلى على مزادات المكوّنات. هدفنا هو تحسين الكفاءة والقدرة على التنبؤ لجميع المشاركين في عملية مزاد "مبادرة حماية الخصوصية". نحن نناقش هذه المشكلة هنا ونرحّب بملاحظات إضافية. |
خدمات Protected Audience
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| بيئات التنفيذ الموثوق بها (TEE) | هل تشغيل وحدات TEE في السحب الإلكترونية المتاحة للجميع أكثر تكلفة مقارنةً بمراكز بيانات تكنولوجيا الإعلان داخل الشركة؟ | ردّنا مشابه للردّ في الربع السابق: يستفيد نموذج أمان TEE الحالي من ممارسات عمليات تنفيذ السحابة العامة. على وجه الخصوص، لا تحمي وحدات TEE الحالية المستندة إلى الأجهزة من جميع الهجمات المادية. لقد صمّم موفّرا السحابة العامة المعتمَدان الحاليان، وهما AWS وGoogle Cloud، إجراءات وقائية للحدّ من مخاطر الوصول المادي، بما في ذلك من الموظفين. اطّلِع على التفاصيل التالية بشأن الدعم على الموقع. أفادتنا تكنولوجيات الإعلان أنّ تشغيل خدمات السحابة الإلكترونية أكثر تكلفة من مراكز بيانات تكنولوجيا الإعلان داخل الشركة. على الرغم من أنّنا لسنا في وضع يسمح لنا بتقييم هذه التصاريح، نرحب بملاحظات إضافية حول التكاليف ونواصل تقييم خيارات توسيع نطاق توفّر TEE. |
| TEEs | إتاحة وحدات TEE في بيئات السحابة الإلكترونية غير العامة | لا يختلف ردّنا عن ردّنا في الربع السابق: في حين أنّنا نواصل استكشاف خيارات إضافية غير الحلول المستندة إلى السحابة الإلكترونية العامة، ليس لدينا حاليًا أي خطط لإتاحة وحدات TEE على الأجهزة. في هذه المرحلة، ونظرًا لمتطلبات أمان "مبادرة حماية الخصوصية" والتحديات الكبيرة التي تواجه عمليات النشر على الأجهزة الداخلية، نعتقد أنّ مواصلة توسيع نطاق عمليات النشر المستندة إلى السحابة الإلكترونية وتحسينها (على سبيل المثال، إتاحة Google Cloud بالإضافة إلى AWS) هو الخيار الأكثر فائدة للمنظومة المتكاملة. مع ذلك، نرحب بملاحظات إضافية حول سبب ضرورة هذا الشرط وقابليته للتنفيذ في ظل القيود المفروضة على الخصوصية والأمان. |
| مقدّمو خدمات السحابة الإلكترونية الآخرون | دعم مقدّمي خدمات السحابة الإلكترونية الآخرين | نحن دائمًا منفتحون على اقتراحات بشأن مقدّمي خدمات السحابة الإلكترونية الآخرين، ولكننا نخطّط على الأقل لاستخدام Google Cloud وAWS عند فرض سياسة "المعالجة المحدودة للبيانات الشخصية". يُرجى الاطّلاع على هذا الشرح للحصول على مزيد من المعلومات. |
| واجهة برمجة تطبيقات B&A Services API | ما هي اتجاهات Google بشأن B&A Services API؟ هل سيتم منح الأولوية لهذا الإعداد أعلى أو أسفل "شرائح الجمهور المحمية" في متصفّح Chrome في مزادات الأجهزة؟ | لا يختلف ردّنا عن ردّنا في الربع السابق: نبقى ملتزمين بتصميم عروض الأسعار الحالية على الجهاز فقط لميزة "شريحة الجمهور المحمية". تم اقتراح خدمات B&A لاستكشاف الحلول المحتملة لتلبية مجموعة فرعية من حالات الاستخدام التي قد تكون فيها الطاقة الحسابية أو سرعة الشبكة للجهاز محدودة. |
| توحيد المقاييس | لم تخضع خدمات B&A لعملية توحيد. | يُعدّ اقتراح "خدمات الإعلان والتحليلات" في منتصف مرحلة من مراحل عملية وضع المعايير، ونرحّب بمزيد من التفاعل لدعم هذا الهدف. بدأ الأمر باقتراح (استنادًا إلى اقتراحات سابقة)، ويتم تطويره بشكل علني من خلال مناقشة مفتوحة ومكثفة في W3C، ويمكن للمطوّرين المهتمين البدء في تجربته وتقديم الملاحظات والآراء. هذا هو النمط المعتاد لتطوير ميزات الويب، كما هو موضّح مثلاً في مشاركة المدوّنة هنا. |
| خادم KV | عرِض عنوان URL الكامل لخادم KV الخاص بالمشتري لاستهداف المحتوى / السياق / الموقع الإلكتروني. | نحن نناقش هذا الطلب هنا ونرحّب بملاحظات إضافية من المنظومة المتكاملة. |
| الوثائق | تؤدي مستندات "المكونات الموثوق بها/المُطبَّقة في مقابل المكونات الاختيارية" على GitHub إلى حدوث التباس لدى بعض تكنولوجيات الإعلان التي لديها مجموعة خاصة بها من صور النشر والبنية الأساسية. | نحن نسعى إلى تحسين مستندات "المكوّنات الموثوق بها/المُطبَّقة في مقابل المكوّنات الاختيارية"، ونريد معرفة رأي المنظومة المتكاملة في ما إذا كان يجب إعطاء الأولوية لهذا العمل. |
| تحسين واجهة برمجة التطبيقات | يجب أن يكون رمز حالة HTTP لطلب خادم KV متاحًا أيضًا لدالة scoreAd() كمَعلمة. | نحن بصدد تقييم هذا الطلب ونرحّب بملاحظات إضافية من المنظومة المتكاملة. |
| الوثائق | تقديم مزيد من المعلومات حول كيفية معالجة أعباء JS وWASM بالضبط من خلال تنفيذ دالة UDF | نحن ننظر في توفير هذه المعلومات ونرحّب بملاحظات إضافية هنا. |
| الوثائق | طلب تعديل اسم المستودع | لقد أعادنا تسمية المستودع إلى "protected-auction-key-value-service". يتوافق ذلك مع مصطلح مجموعة الخدمات التي ينتمي إليها هذا المستودع، والتي تتضمّن أيضًا مستودعات أخرى مثل مستودع مناقشة "خدمات الجمهور المحمي" ومستودع مستندات "خدمات المزادات المحمية". |
| الوثائق | أزِل الإشارة إلى Cloud debugger API في bidding_auction_services_gcp_guide.md. | لقد عدّلنا المستندات وأزلنا المرجع. |
| استخدام واجهة برمجة التطبيقات | يستغرق وقت الاستجابة الناتج عن البحث في قاعدة بيانات KV أكثر من 50 ملي ثانية. يستغرق ذلك 100 ملي ثانية تقريبًا. هل لديك أي إرشادات حول الإجراءات التي حقّقت نجاحًا مع بائعين آخرين؟ هل لديك أي اقتراحات حول كيفية قياس مهلات الانتظار والتوقيت؟ |
يتمّ طلب خادم KV في سياق "برامج تشغيل النصوص البرمجية"، أي البيئة المحمية الخاصة داخل متصفّح Chrome. ويهدف ذلك إلى الحفاظ على أمان المعلومات في مشغّلات النصوص البرمجية هذه من أي وصول غير مصرَّح به من خلال واجهة برمجة التطبيقات. وقد قدّمنا شرحًا مفصّلاً هنا. |
| استخدام واجهة برمجة التطبيقات | هل هناك مهلة زمنية لخادم KV للردّ في وقت معيّن؟ | يمكن للبائعين تحديد الحقل perBuyerCumulativeTimeouts في إعدادات المزاد. ويشمل هذا المهلة الوقت اللازم لجلب إشارات عروض الأسعار الموثوق بها. |
| استغرق الرد وقتًا طويلاً | كيف يعمل فريق "مبادرة حماية الخصوصية" على معالجة وقت الاستجابة؟ | للاطّلاع على الاستراتيجيات التي نستكشفها للحفاظ على وقت الاستجابة ضمن الحدود المقبولة، يُرجى الاطّلاع على هذا الرابط. |
قياس الإعلانات الرقمية
تقارير تحديد المصدر (وواجهات برمجة التطبيقات الأخرى)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| تحسين الحملة يدويًا | لا تتيح ميزة ARA تحسين الحملات يدويًا. | لقد ناقشنا هذا السيناريو مع فريق تكنولوجيا الإعلان وعرضنا الطرق التي يمكن من خلالها استخدام ARA لدعم تحسين الحملات يدويًا. تم إنشاء ARA بطريقة تسمح بتخصيص تكنولوجيا الإعلان ومرونتها لحلّ مجموعة من حالات استخدام تكنولوجيا الإعلان. تشمل بعض الاقتراحات التي تم تقديمها استخدام إعدادات مختلفة ومرنة على مستوى الحدث، واستخدام التقارير على مستوى الحدث مع التقارير التلخيصية للحدّ من تأثير الضوضاء وتحقيق احتياجات التحسين اليدوي والتلقائي. نحن منفتحون على تلقّي ملاحظات إضافية حول المنظومة المتكاملة بشأن إمكانية تخصيص إعدادات ARA ومرونتها. |
| نوع الإحالة الناجحة | تسمح Google بثمانية أنواع إحالات ناجحة فقط، ما يحدّ من الخيارات المتاحة. | لقد نفّذنا معظم التقارير المرنة على مستوى الحدث، ما يمنح تكنولوجيات الإعلان مرونة إضافية من حيث عدد فترات إعداد التقارير وعدد تقارير تحديد المصدر وبعض بيانات العوامل المشغّلة التي يمكن استخدامها. يمكن لتكنولوجيات الإعلان اختيار إعدادات تسمح بقياس ما يصل إلى 32 نوعًا مختلفًا من الإحالات الناجحة. |
| الحدّ الأقصى لأحداث التقارير القابلة للتجميع | إنّ الحدّ الأدنى الرقمي الذي يبلغ 20 حدث إحالة ناجحة لكلّ تقرير قابل للتجميع غير عملي للمعلِنين الأصغر حجمًا الذين لديهم ميزانية محدودة. | لا يوجد حدّ أدنى لعدد أحداث الإحالات الناجحة المطلوب لكل تقرير قابل للتجميع. بالإضافة إلى ذلك، هناك عدد من قرارات التصميم التي يمكن اتخاذها لتحسين التقارير القابلة للتجميع للمعلِنين الأصغر حجمًا، مثل تغيير بنية المفاتيح / السمات التي يتم تتبُّعها واختبار مستويات مختلفة من epsilon واختبار معدلات تكرار تجميع البيانات الأطول واختبار عمليات تخصيص ميزانية المساهمة المختلفة بين أهداف القياس. ويمكن أيضًا لتكنولوجيات الإعلان الأصغر حجمًا تجربة دمج التقارير على مستوى الحدث والتقارير التلخيصية كطريقة للحدّ من تأثير الضوضاء. |
| البيانات في الوقت الفعلي | إنّ حرمان منصّات إدارة الأداء من البيانات في الوقت الفعلي (مثل النقرات والجلسات والإحالات الناجحة) التي تستخدمها منصّات إدارة الأداء لتعديل استراتيجية عروض أسعارها وتحقيق فعالية أفضل للحملات، يتعارض مع الالتزام بالاحتفاظ بالوظائف الحالية. | حتى مع استخدام ARA، تظلّ النقرات والجلسات في الوقت الفعلي، وتكون الإحالات الناجحة دائمًا بعد حدوثها حتى مع استخدام 3PC. |
| الحقول المفقودة | متطلبات غير مستوفاة في عملية طرح الحدث "القابل للتعديل بالكامل": 1) حقل "العملة" و2) حقل orderID / TransactionID | لا نخطّط حاليًا لإتاحة حقل "العملة" أو حقل "معرّف الطلب" أو حقل "معرّف المعاملة" كجزء من مستوى الحدث المرن الكامل لأنّ هناك طرقًا متوفّرة حاليًا لإجراء ذلك من خلال إعداد التقارير الحالية على مستوى الحدث. نحن منفتحون على تلقّي ملاحظات إضافية بشأن هذه الحقول، وسنعيد النظر فيها إذا كانت هناك حالات استخدام إضافية تتطلّب ذلك. طرق استخدام تصميم ARA الحالي لقياس معلومات نوع العملة ورقم تعريف الطلب: 1. استنادًا إلى الملاحظات والآراء، يتم تحديد العملة حسب الموقع الجغرافي للمستخدم، والذي يمكن إضافته كجزء من source_event_id لتحديد العملة المستخدَمة. 2. استنادًا إلى الملاحظات والآراء، يجب استخدام حقل "معرّف الطلب" لضمان عدم احتساب الإحالات الناجحة والقيم مرتين عن طريق الخطأ، ويمكن إجراء ذلك باستخدام مفاتيح إزالة التكرار. |
| ميزانية الخصوصية | ميزانية الخصوصية في ARA تحدّ من إمكانية القياس على مستوى سمات متعددة | تم تصميم ARA بطريقة تسمح لتقنيات الإعلان بتخصيص إعدادات ARA الخاصة بها لتغطية مجموعة متنوعة من سيناريوهات تحديد المصدر. في ظل التصميم الحالي لواجهة برمجة التطبيقات ARA، ستحتاج تكنولوجيات الإعلان إلى التفكير في المفاضلة بين السمات الأكثر أهمية بالنسبة إليها لقياسها وتأثير الضوضاء في بياناتها. إنّ إضافة تشويش إلى البيانات استنادًا إلى دقة السمات التي يتم قياسها أمر أساسي للخصوصية. نحن منفتحون على تلقّي ملاحظات إضافية حول المنظومة المتكاملة بشأن إمكانية القياس على مستوى سمات مختلفة، ولكننا نحتاج إلى فهم حالات الاستخدام المحدّدة التي تتطلّب ذلك. |
| تعديل المواصفات | على الرغم من أنّ Google أعلنت أنّها انتقلت من الفترات الثابتة إلى الفترات المرنة لإعداد تقارير الأحداث، لم يظهر ذلك في المواصفات الفنية لشركة Google التي لا تزال تفرض حاليًا حدًا أدنى للفترات يبلغ ساعة واحدة. | تسمح ميزة إعداد التقارير المرنة على مستوى الحدث حاليًا لتكنولوجيات الإعلان بتغيير عدد تقارير تحديد المصدر لكل حدث مصدر، وعدد أجزاء بيانات العوامل المشغّلة، وعدد فترات إعداد التقارير أو طولها. لا تزال تقنية ARA تفرض حدًا أدنى لمدة إعداد التقارير يبلغ ساعة واحدة للتقارير على مستوى الحدث، وهو أمر ضروري للحفاظ على الخصوصية والحدّ من أنواع معيّنة من هجمات إعادة إنشاء السجلّ. بما أنّ التقارير الملخّصة تقدّم معلومات مجمّعة، يمكن لتقنيات الإعلان تفعيل تلقّي تقارير قابلة للتجميع على الفور بدون أي تأخير، إذا لزم الأمر لحالات الاستخدام الخاصة بها. |
| تصميم واجهة برمجة التطبيقات | القلق من أنّ تقليل المعلومات في تقارير الإحالات الناجحة وإضافة مصادر تشويش قد يؤثّر في المنظومة المتكاملة أكثر من Google | التزمت Google أمام هيئة CMA بتصميم اقتراحات "مبادرة حماية الخصوصية" وتنفيذها بطريقة لا تشوه المنافسة من خلال منح الأولوية لنشاط Google التجاري، كما التزمت بمراعاة التأثير في المنافسة في مجال الإعلانات الرقمية وعلى الناشرين والمعلنين بمختلف أحجامهم. |
| تصحيح تحديد المصدر | لا تسمح مبادرة ARA لمزوّد التكنولوجيا بالتحكّم في عملية تحديد المصدر الصحيح والتحقّق منها. | هناك العديد من الحلول المتاحة ضمن ARA التي توفّر إمكانات التحقّق: 1. يمكن لتكنولوجيات الإعلان التحقّق من أنّ سلوك ARA يتطابق مع توقعاتهم: – الرمز البرمجي من جهة العميل في ARA مفتوح المصدر. – الرمز البرمجي من جهة الخادم في ARA مفتوح المصدر أيضًا، ويضمن المنسقون أنّ الإصدارات المسموح بها فقط من "خدمة التجميع" يمكنها فك تشفير التقارير القابلة للتجميع ومعالجتها. 2. قدّم Chrome لتكنولوجيات الإعلان مكتبة محاكاة للتحقّق من سلوك تحديد المصدر، حيث يمكن لتكنولوجيا الإعلان اختبار كيفية تنفيذ ARA لتحديد المصدر في بيئة محاكاة. 3. تتوافق ARA مع عدد من إشارات تصحيح الأخطاء التي تساعد في التحقّق مما إذا كانت المعالجة المتوقّعة قد حدثت أم لا وسبب عدم حدوثها. |
| (تم الإبلاغ عنها أيضًا في الربع السابق) الضوضاء |
ملاحظات بأنّ مستوى التشويش مرتفع جدًا ويؤثر في مدى فائدة التقارير | لقد تواصلنا مع خبراء تقنية الإعلان وشاركنا معهم هذه الملاحظات نفسها، وتمكّنا من تحديد طرق يمكن من خلالها تخصيص ARA بما يناسب حالات الاستخدام بشكل أفضل، حتى في حال حدوث تشويش. لدينا مستندات مخصّصة للمطوّرين تتضمّن معظم قرارات التصميم والتخصيصات التي ناقشناها مع خبراء التكنولوجيا الإعلانية. تم تصميم ARA بطريقة تسمح لخبراء التكنولوجيا الإعلانية بتخصيص إعدادات ARA الخاصة بهم لتغطية مجموعة متنوعة من سيناريوهات تحديد المصدر. ولكن على تكنولوجيات الإعلان التفكير في المفاضلة بين السمات الأكثر أهمية بالنسبة إليهم لقياسها وتأثير الضوضاء في بياناتهم. نحن منفتحون على تلقي ملاحظات إضافية حول المنظومة المتكاملة بشأن تأثير الضوضاء، ويمكننا تقديم إرشادات إضافية حول أدوات ARA التي يمكن استخدامها لتغيير تأثير الضوضاء. |
| تحديد المصدر من عدّة نطاقات | كيف يمكن تتبُّع الإحالات الناجحة على مستوى النطاقات المختلفة؟ | يمكن أن تعيد تقنيات الإعلان التوجيه إلى عناوين URL مختلفة لإعداد التقارير لحلّ هذه الحالة. نحن منفتحون على تلقّي ملاحظات إضافية حول منظومة Android الكاملة بشأن هذا الجانب من تصميم ARA. |
| تحسين واجهة برمجة التطبيقات | غيِّر بانتظام عامل التكبير المستخدَم عند تسجيل عملية تحديد المصدر لتقارير "ARA Summary". | استنادًا إلى المناقشة على GitHub، يبدو أنّ التعامل مع عوامل توسيع نطاق متعددة في "خدمة التجميع" سيؤدي على الأرجح إلى زيادة عدد القيم العشوائية التي تتم إضافتها إلى التقارير التلخيصية مقارنةً بالوظائف الحالية. نحن منفتحون على أي ملاحظات إضافية بشأن الحاجة إلى عوامل التوسيع كجزء من التقارير القابلة للتجميع، ولكن نريد الإشارة إلى التأثير المحتمل الناتج عن زيادة القيم العشوائية. نحن نُقيّم أيضًا ما إذا كانت ميزات ARA المستقبلية الأخرى قد تساعد في حلّ حالة الاستخدام هذه أيضًا. |
| استخدام واجهة برمجة التطبيقات | فرصة لتوحيد طريقة مشاركة أحداث تحديد المصدر مع جميع المشاركين، ما يُعدّ مفيدًا لوحدة إدارة السلسلة الإعلانية ووحدة إدارة الطلبات وما إلى ذلك | نخطّط لمزامنة الإعدادات مع تكنولوجيا الإعلان لفهم ملاحظاتهم بشكل أفضل وأيّ قيود يواجهونها. |
| حجم عدد الزيارات الاختبارية | هل الزيارات الاختبارية للوضع "ب" في جميع متصفّحات Chrome ثابتة؟ | لا تتأثّر المشاركة في مجموعة تجريبية بإعدادات Chrome (أو تكون مستقلة عنها). |
| الوثائق | إتاحة ميزة ARA لهواتف Pixel | لقد نشرنا معلومات حول كيفية إتاحة هذا الاستخدام ونرحّب بملاحظات إضافية من المنظومة المتكاملة. |
| استخدام واجهة برمجة التطبيقات | قد لا يتمّ تحديد المصدر الصحيح لميزة ARA للبائعين التابعين لجهات خارجية على منصات التجارة الإلكترونية إذا لم يتمّ إتمام الإحالة الناجحة من خلال نقطة الاتصال الأخيرة. | يمكن للشركات استخدام الفلاتر لمنع حدوث عملية تحديد مصدر غير صحيحة (لأنّه لن يتمّ إنشاء أيّ تقرير إحالة ناجحة). نحن نعمل أيضًا على اقتراح لفلترة ما قبل تحديد المصدر للمساعدة في هذا النموذج. |
| توافق المتصفّح | هل ستكون ميزة ARA متاحة في متصفّحات مختلفة؟ | نرحب بالمتصفّحات الأخرى التي تتبنّى واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" ونواصل تخصيص الوقت لمناقشة نهجنا بشكل علني في W3C. لقد أوضحنا صراحةً أنّ إمكانية التشغيل التفاعلي هي أحد أهداف طرح ARA، ومن المفترض أن يكون تصميم ARA مستقلاً عن المتصفّح مع قيم مرنة يحدّدها المورّدون الذين يتّبعون مواقف مختلفة بشأن الخصوصية. تختار المتصفّحات الأخرى ما إذا كانت ستقدّم بدائل قابلة للتطبيق للمعرّفات على مستوى المواقع الإلكترونية التي يمكن أن تدعم المنظومة المتكاملة الرقمية للمحتوى والخدمات. يسرّنا أنّ Microsoft Edge أشار إلى أنّه سيتيح استخدام ميزة ARA. |
| استخدام واجهة برمجة التطبيقات | ما هو نوع المصدر المتوقّع لعمليات تسجيل مصادر ARA لـ registerAdBeacon/reportEvent (وnavigation_start/commit automatic beacons)؟ | يعتمد ذلك على ما إذا كانت هذه الإشارات تلقائية أو يدوية:
- محجوز.* (أيّ تلقائية) من نوع مصدر التنقّل. - أن تكون الأحداث التي يتم بدءها يدويًا من النوع event-source |
| استخدام واجهة برمجة التطبيقات | هل الحدّ الأقصى المسموح به وهو 20 تقريرًا قابلاً للتجميع لكلّ مصدر يعني لكلّ حدث مصدر؟ هل الحدّ عالمي أم يومي؟ هل هناك خطة لزيادة الحدّ الأقصى؟ | الحدّ الأقصى لعدد التقارير القابلة للتجميع لكلّ مصدر هو حدّ شامل يمكن من خلاله إنشاء 20 تقريرًا قابلاً للتجميع لكلّ مصدر. ويحدّد المتصفّح هذا الحدّ ولا يمكن ضبطه. ويهدف هذا الحدّ إلى تجنُّب إساءة استخدام حماية تقارير الإحالة الناجحة الحقيقية من خلال تقارير فارغة. لقد ناقشنا هذا الأمر بالتفصيل هنا. |
| استخدام واجهة برمجة التطبيقات | إتاحة التسويق عبر البريد الإلكتروني باستخدام ARA | في الوقت الحالي، لا تتوفّر مساعدة مباشرة لحالة الاستخدام هذه ضمن ARA (إذا لم تكن تتحكّم في موقع استضافة البريد الإلكتروني). نناقش هذه المشكلة هنا ونرحّب بملاحظاتك الإضافية. |
| Epsilon | متى سيتم تحديد قيمة epsilon لواجهة برمجة التطبيقات Aggregate API؟ | يمكن لتقنيات الإعلان ضبط قيمة epsilon الحالية حتى الحدّ الأدنى المحدّد مسبقًا الذي تحدّده "مبادرة حماية الخصوصية" (وهو 64 حاليًا). ننصحك باختبار قيم مختلفة لدالة epsilon وتحديد نقاط الانحناء لحالات الاستخدام الخاصة بك وتقديم الملاحظات. سنحرص على التواصل مع التكنولوجيات الإعلانية مسبقًا قبل إجراء أي تغييرات على نطاق قيم epsilon. |
| تحسين واجهة برمجة التطبيقات | أن تتيح حالة استخدام يمكن فيها للمعلِن إدراج معرّف في حقل trigger_data لمطابقته مع بيانات إدارة علاقات العملاء الخارجية للسماح للمعلِنين بالتحقّق من جودة الإحالات الناجحة | نحن بصدد مناقشة الطلب ونرحّب بملاحظاتك الإضافية هنا. |
| استخدام واجهة برمجة التطبيقات | كيفية التعامل مع عناوين URL لإعادة التوجيه كعناوين URL مقصودة | يمكن لتكنولوجيات الإعلان تنفيذ أيّ من الإجراءات التالية: 1- ضَع عنوان URL النهائي للوجهة في حقل الوجهة. 2- يسمح حقل الوجهة بما يصل إلى 3 عناوين URL، ما يتيح لك وضع عناوين URL متعددة في الحقل. سيتطلب كلا الخيارَين معرفة عنوان URL النهائي للوجهة. لقد ناقشنا هذا الأمر بالتفصيل هنا. |
خدمة تجميع البيانات
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| آلية اكتشاف المفاتيح | طلب آلية اكتشاف المفاتيح | لدينا اقتراح لاكتشاف المفاتيح ونرحّب بملاحظات من المنظومة المتكاملة حول هذا الاقتراح. |
| استخدام واجهة برمجة التطبيقات | خارطة الطريق لرصد "خدمة تجميع البيانات" | نحن نراجع الخيارات لتوفير المزيد من إمكانية المراقبة ونرحّب بملاحظات من المنظومة المتكاملة هنا. |
| تحسين واجهة برمجة التطبيقات | طلب التمكّن من إعادة طلب التقارير | تعمل خدمة التجميع على اقتراح طلب جديد يمكن من خلاله لتكنولوجيات الإعلان تقسيم قيمة epsilon لكل تقرير. ويمكن أن يؤدي ذلك إلى زيادة التشويش لكل طلب بحث، ولكنه سيسمح لتقنيات الإعلان بإعادة طلب البيانات والحفاظ على الخصوصية. |
| تحسين واجهة برمجة التطبيقات | أريد أن أتمكّن من ربط مصادر متعددة بمعرّف AWS نفسه. | ستسمح "خدمة التجميع" الآن بإعداد مواقع إلكترونية متعددة في حساب السحابة الإلكترونية نفسه (Google Cloud أو AWS). سيسمح ذلك لتكنولوجيات الإعلان باستخدام مجمع "خدمة التجميع" نفسه لمعالجة التقارير من مواقع إلكترونية متعددة ومصادر متعددة من المواقع الإلكترونية نفسها. |
| استخدام واجهة برمجة التطبيقات | عند تعذُّر معالجة الدفعات القابلة للتجميع، لا يمكن التأكّد مما إذا تمّ استخدام الميزانية أم لا وما إذا كان بإمكانهم إعادة معالجة دفعتهم. عندما تواجه خدمة التجميع خطأ في الميزانية للتقارير المكرّرة، يتم فقدان بقية التقارير المتبقية. كيف يمكن تقليل هذا الخسارة؟ | في السيناريو المعتاد، إذا تعذّر إكمال المهمة بأكملها، لن يتمّ استخدام الميزانية. في حالات حدوث خطأ نادر يؤدي إلى إنفاق الميزانية، يمكن لتكنولوجيات عرض الإعلانات طلب استرداد الميزانية. إذا واجهت تكنولوجيا عرض الإعلانات أخطاء متكرّرة في المهام تؤدي إلى ظهور خطأ "استنفاد الميزانية"، عليها التأكّد من استراتيجية تجميع البيانات. يمكنك الاطّلاع هنا على تعليمات حول كيفية تجميع التقارير بشكلٍ صحيح وتجنُّب تكرار التقارير والأخطاء. يمكنك إرسال ملاحظاتك حول استرداد الميزانية هنا. |
| استخدام واجهة برمجة التطبيقات | سيؤدي استخدام Private Aggregation API مع عامل التفعيل الموضّح هنا إلى إنشاء تقرير قابل للتجميع لكل مزاد. ما هي إمكانات التوسّع في "خدمة التجميع"؟ | لا تضع "خدمة التجميع" حدًا أقصى لعدد المفاتيح أو التقارير في حزمة، ولكن لا يمكن حاليًا استخدام مقياس يضمّ 10^14 تقريرًا و10^12 مفتاحًا بسبب الذاكرة المطلوبة. تشير إرشادات تحديد الحجم إلى النطاقات التي اختبرناها وننصحك بها لتحقيق الأداء الأمثل استنادًا إلى الحمل المتوقّع وأنواع مثيلات الأجهزة الافتراضية المتوافقة مع السحابة الإلكترونية. |
| معالجة البيانات | إذا كانت البيانات المشفَّرة تتضمّن معلومات شخصية، ما هي الترتيبات القانونية لتقديم البيانات المشفَّرة إلى "خدمة التجميع"؟ هل يمكنك إبلاغنا بما إذا كان من المؤكد أنّ المنسق لن يصل إلى البيانات المشفّرة؟ |
لا تشارك خدمة التجميع بيانات المستخدمين أو البيانات المشفّرة مع "المنسق". تستخدِم خدمة "تجميع البيانات" المُنسق لإدارة المفاتيح والاحتساب. يمكنك الاطّلاع على بعض التفاصيل حول المنسّق هنا. بالنسبة إلى المحاسبة، لا تشارك خدمة التجميع سوى رقم التعريف المشترَك ومصدر إعداد التقارير مع PBS لاستهلاك الميزانية. بعد إطلاق ميزة المواقع الإلكترونية المتعددة، سنستبدل المصدر بالموقع الإلكتروني. يُرجى العلم أنّ خدمة التجميع تعمل في بيئة آمنة للبرامج (TEE)، وهي المكان الوحيد الذي يمكن فيه فك تشفير التقارير الواردة من العملاء. إنّ الرمز البرمجي الذي يتم تشغيله في TEE مفتوح المصدر وتتحقّق منه جهات خارجية كما هو موضّح هنا. |
Private Aggregation API
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| استخدام واجهة برمجة التطبيقات | قدرة بائعي المكوّنات على إرسال التقارير إلى خوادم تجميع متعددة ضمن بيئة آمنة للبرامج | لا تتيح حالة Private Aggregation API الحالية استخدام هذه الميزة. لقد ناقشنا هذه المشكلة بشكل مفصّل هنا. |
| الوثائق | ما هي قيمة epsilon المستخدَمة في تجارب Google؟ | بالنسبة إلى Private Aggregation API، تتوافق قيمة ε المحدّدة في طلب خدمة التجميع مع ميزانية المساهمة في المستوى 1 التي تبلغ 2^16 والتي يتم فرضها بشكل متجدّد كل 10 دقائق. تتوفّر أيضًا ميزانية مساهمة L1 "احتياطية" بقيمة 2^20 يتم فرضها على أساس متجدّد على مدار 24 ساعة. وبالتالي، تكون مَعلمة الخصوصية هي ε على أساس متجدّد كل 10 دقائق، وتكون 16ε على أساس متجدّد كل 24 ساعة (بدلاً من 144ε). تتيح خدمة التجميع حاليًا مجموعة من قيم ε للاختبار (تصل إلى 64) للسماح بالتجربة مع استراتيجيات التجميع المختلفة وتقديم ملاحظات حول فائدة النظام باستخدام مَعلمات خصوصية مختلفة لخدمة "التجميع الخاص" وواجهات برمجة التطبيقات الأخرى. نخطّط لإعادة النظر في الحد الأقصى المسموح به لقيمة مقياس epsilon بمرور الوقت عندما نتلقّى ملاحظات من المختبِرين ونضيف ميزات تتيح استخدام ميزانية الخصوصية بكفاءة أكبر. |
الحد من التتبّع الخفي
تقليل معلومات وكيل المستخدم/تعديلات برنامج وكيل المستخدم
لم يتم تلقّي أي ملاحظات هذا الربع.
حماية عنوان IP (المعروفة سابقًا باسم Gnatcatcher)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| معرّف الحلّ | يجب أن تُظهر "مبادرة حماية الخصوصية" مزيدًا من الوضوح للتأكيد على أنّ معرّفات دقة الشاشة التي تستند غالبًا إلى عنوان IP ليست مستدامة للمعلِنين. | أوضحت "مبادرة حماية الخصوصية" أنّنا نهدف إلى الحد من التتبّع على المواقع الإلكترونية. يتم الإعلان عن مبادراتنا العامة، التي تتعلّق بأكثر من ملفات تعريف الارتباط، على كلّ من privacysandbox.com وGitHub. نسعى جاهدين إلى الحدّ من التتبُّع على مستوى المواقع الإلكترونية المختلفة، بما في ذلك التتبُّع المستنِد إلى عناوين IP. ومع ذلك، يعود الأمر في النهاية إلى المواقع الإلكترونية الفردية لتحديد ما إذا كان سيتم تفعيل التتبّع على مستوى المواقع الإلكترونية بشكل استباقي. في عصر التدقيق المتزايد في الامتثال التنظيمي، من الحكمة أن تفهم الشركات الفردية الممارسات التي يعتمدها مقدّمو الخدمات. |
| Chromecast | هل ستؤثر ميزة "حماية عنوان IP" في أجهزة Chromecast أو أجهزة Chrome الأخرى؟ | لا تتوفّر حاليًا أي خطط لتطبيق ميزة "حماية عنوان IP" على أجهزة Chromecast. |
| قائمة حماية عنوان IP | هل سيتم نشر قائمة بالجهات الخارجية التي تم تحديدها على أنّها تستخدم عناوين IP على الأرجح لتتبُّع المواقع الإلكترونية على مستوى الويب؟ | سيتم نشر القائمة بعد الانتهاء من إعدادها، كما هو موضّح هنا. |
الحدّ من التتبّع الارتدادي
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| إعفاء الدخول المُوحَّد (SSO) | كيف سيتحقّق نظام BTM من حالات استخدام الدخول المُوحَّد (SSO) للحصول على إعفاء؟ | سيتم إيقاف ميزة "التتبّع بدون إنترنت" من خلال الأساليب الاستقرائية في Chrome. اطّلِع على المقالة التوضيحية للاطّلاع على التفاصيل. |
| فترة تجريبية للميزة التي سيتم إيقافها نهائيًا | هل تم تفعيل ميزة "إدارة الأداء من Google" للمواقع الإلكترونية في فترة التجربة الخاصة بإيقاف ميزة "الطرف الثالث" نهائيًا؟ | لا، تلتزم ميزة "إدارة العلامات من Google" باستثناءات ملفات تعريف الارتباط التي تم إنشاؤها من خلال فترة تجريبية لإيقاف ميزة ملفّات تعريف الارتباط نهائيًا، كما هو موضّح هنا. |
ميزانية الخصوصية
كما هو موضّح في الشرح على GitHub وموقع المطوّرين الإلكتروني، لم تعُد ميزانية الخصوصية موضع اعتبار بشكل نشط كجزء من اقتراحات "مبادرة حماية الخصوصية".
تعزيز حدود الخصوصية على جميع المواقع
مجموعات المواقع الإلكترونية المرتبطة (المعروفة سابقًا باسم "مجموعات نطاقات الطرف الأول")
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| طلب ميزة | يُسمح تلقائيًا بالوصول إلى شرائح CHIP و / أو تقسيم مساحة التخزين في RWS، بدون الحاجة إلى واجهة برمجة التطبيقات Storage Access API أو تفاعل المستخدم. | نحن ننظر في مزايا ومدى جدوى ميزة قد تؤدي هذه الوظيفة. ومن بين الاعتبارات التي يجب أخذها في الاعتبار الفجوة المحتملة في إمكانية التشغيل التفاعلي بين المتصفّحات المختلفة، والتي يعالجها RWS من خلال الاستفادة من واجهة برمجة التطبيقات Storage Access API. لا تتوفّر حاليًا وظيفة مماثلة لهذه الوظيفة المطلوبة على المتصفّحات الأخرى. نشجّع المطوّرين على إرسال حالات الاستخدام المتعلّقة بهذه المشكلة لتسهيل المناقشة هنا. |
| إزالة المجموعات غير الممتثلة | ما هي عملية إزالة المجموعات التي أصبحت غير متوافقة من المستودع؟ | نحن نعمل على تحديد عملية لذلك، وسنشارك آخر المعلومات فور توفّرها. |
| عملية تنفيذ السياسات | لا تتضح لنا طبيعة دور Google في عملية تنفيذ سياسة RWS. | بما أنّ ميزة "الاستجابة السريعة للطلبات" هي مشروع مستمر ونحن نواصل تلقّي العينات الجديدة، لا تزال بعض جوانب العملية ومعاييرنا قيد التطوير. نوافق على أنّه من المهم أن توضّح إرشادات الإرسال متطلبات الإرسال بالكامل، وسنضيف المزيد من التفاصيل إلى إرشادات الإرسال من الآن فصاعدًا لتجنّب المزيد من الغموض والالتباس. نهدف إلى أن تكون عملية الإرسال فنية قدر الإمكان حتى نتمكّن من إيقاف المراجعة البشرية تدريجيًا والاعتماد بالكامل على عمليات التحقّق الآلية. تتطلّب طلبات الدعم مثل هذه طلب المزيد من التفاعل البشري لأنّها تتضمّن سلوكيات لم نتوقّعها، ولكنها تسمح لنا بتحديد المزيد من المجالات التي يمكن فيها استخدام الأساليب المبرمَجة والطُرق التي يمكننا من خلالها تعديل إرشاداتنا لتجنّب هذه المشاكل في المستقبل. |
| مشاركة البيانات | طلب ميزة تتيح لمالكي النطاقات الإشارة إلى أنّهم يريدون أن تشارك جهة خارجية أيضًا بيانات RWS، وذلك بعد الحصول على موافقة المستخدم | تتوفّر الوظيفة المطلوبة حاليًا من خلال واجهات برمجة التطبيقات، مثل FedCM وStorage Access API، التي تتيح الوصول إلى الهوية التي تم إثبات صحتها بعد قبول المستخدم لطلب الحصول على الإذن. ونرحّب بملاحظات من المنظومة المتكاملة بشأن أيّ حالات استخدام محدّدة يعتقدون أنّها غير ممكنة. |
| طرق التخزين الأخرى | هل سيتم أيضًا تفسير المعلومات المحفوظة في التخزين المحلي أو تخزين الجلسة على أنّها ملفات تعريف ارتباط الطرف الثالث؟ | منذ الإصدار 115 من Chrome، تم تقسيم مساحة التخزين المحلية ومساحة تخزين الجلسات وأشكال التخزين الأخرى غير المستندة إلى ملفات تعريف الارتباط عند استخدامها في سياقات تابعة لجهات خارجية. يمكنك الاطّلاع على مشاركة المدونة هذه لمعرفة تفاصيل إضافية. |
| الحد الأقصى للمجموعات المرتبطة | ماذا يحدث للمؤسسات التي ترسِل أكثر من 5 نطاقات على الرغم من أنّ الحدّ الأقصى المسموح به هو "5 مواقع إلكترونية مرتبطة"؟ | سيتم قبول هذه المجموعات من خلال عملية GitHub، ولكن لن يطبّق المتصفّح (Chrome) سوى قواعد منح الأذونات تلقائيًا من خلال واجهة برمجة التطبيقات Storage Access API على أول 5 نطاقات، وسيتجاهل النطاقات المتبقية، كما هو موضّح هنا. |
| find_robots_txt | لا تعمل عملية التحقّق من find_robots_txt مع عمليات إعادة التوجيه. | تم إرسال حلّ لهذه المشكلة هنا. |
| إيماءة المستخدم | إزالة شرط إيماءة المستخدم لاستخدام accessStorage() | تم وضع هذا الشرط استنادًا إلى تصميم مشابه متوفّر في جميع المتصفحات الرئيسية لواجهة برمجة التطبيقات requestStorageAccess API. ندعوك إلى تقديم ملاحظات إضافية وحالات استخدام في هذه المشكلة على GitHub لمساعدتنا في منح الأولوية لهذا الطلب وتفعيل المناقشات على جميع المتصفّحات. |
| إيماءة المستخدم | هل يجب أن ينفّذ المستخدم إجراءً لمنح الإذن بالوصول إلى مساحة تخزين تابعة لجهة خارجية بعد إعادة تشغيل Chrome أو نظام التشغيل؟ | نعم، ولكن نرحب بملاحظات إضافية من المنظومة المتكاملة بشأن ما إذا كان يجب تغيير هذا السلوك هنا. |
Fenced Frames API
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| adComponent | عدم توفّر مستندات وإمكانية استخدام AdComponents مع الإطارات المحدود | نحن نسعى إلى مشاركة المزيد من المستندات المتعلّقة بهذه الحالة. بالإضافة إلى ذلك، تتوفّر مكوّنات الإعلانات في "اللقطات المُغلقة" باستخدام getNestedConfigs() التي تمّت الإشارة إليها في المواصفة هنا. |
| (تمّ الإبلاغ عنها أيضًا في الربعَين السابقَين) Render adComponent |
طلب نماذج رموز حول كيفية عرض adComponents في الإطار المحدود | نحن نعمل على مشاركة بعض نماذج الرموز هنا. |
| إثبات صحة المعلِنين التابعين لجهات خارجية | يحتاج دور خدمة التحقّق من الإعلانات التابعة لجهات خارجية في سياق "اللقطات المُغلقة" إلى مزيد من التفاصيل، لا سيما في ما يتعلق بأمان العلامة التجارية أو السياق. | في الوقت الحالي، تسمح ميزة "إعداد تقارير الإعلانات في الإطارات المحدود" لأنظمة إدارة العروض بإرسال بيانات على مستوى أحداث مرّات الظهور والمزادات إلى أدوات التحقّق من الإعلانات التابعة لجهات خارجية لإجراء عمليات التحقّق من أمان العلامة التجارية والفوترة بعد عرض الإعلان. |
| الإعلانات القابلة للتوسعة | طلب إتاحة الإعلانات القابلة للتوسّع | إذا كان الإعلان يحتاج إلى التبديل بين حجمَين بنسبة العرض إلى الارتفاع نفسها، ولم يكن هناك فرق وظيفي بينهما (فقط الحجم)، يمكن لمُضمِّن المحتوى تغيير حجم "الإطار المحدود" باستخدام حجم الإعلان الثاني ويغيّر المتصفّح حجم عنصر "الإطار المحدود" وفقًا لذلك. |
| (تم الإبلاغ عن ذلك أيضًا في الربعَين السابقَين) إتاحة مستودع الفيديو والإعلانات المدمجة |
هل تتيح "الإطارات المحدودَة" عرض الفيديو والمساحة الإعلانية المدمجة؟ | ردّنا مشابه للردّ الذي قدّمناه في الربع السابق: تتيح PA API عرض الفيديو باستخدام آلية تعتمد على إطارات iframe. ومع ذلك، لم نتوصّل بعد إلى حلّ لعرض الفيديو والإعلانات المدمجة متوافق مع "الإطارات المحدودَة"، وهذا هو أحد الأسباب التي دفعتنا إلى تأجيل فرض استخدام "الإطارات المحدودَة" إلى عام 2026. وهذا يعني أنّه إذا قرّر أحد الشركاء فرض استخدام "الإطارات المحدود" الآن، لن يتمكن من استخدام الفيديو والإعلانات المدمجة. |
| المجلس الاستشاري | طلب إنشاء مجلس استشاري لمورّدي الإعلانات المدمجة لضمان اتّباع عمليات تنفيذ "الإطارات المحدود" لمعايير الصناعة | لن تكون إطارات الالتفاف مطلوبة لاستخدامها في PA API قبل عام 2026. تتيح لنا هذه الفترة الإضافية مواصلة العمل مع الجهات المعنية في المجال لتصميم وتنفيذ الدعم لمجموعة أكبر من حالات الاستخدام الملحّة. لقد أعلنّا سابقًا أنّنا سنطوّر ميزة "الإطارات المحدود" قبل أن يصبح استخدامها مطلوبًا للحفاظ على إمكانية عرض الفيديو والإعلانات المدمجة باستخدام واجهة برمجة التطبيقات PA API. ووفقًا لالتزاماتنا، سنتواصل مع "اللجنة الكندية للمنافسة والمستهلكين" (CMA) لإعلامها بأي تغييرات من هذا النوع، وسنواصل التفاعل مع الملاحظات الواردة من المنظومة المتكاملة قبل فرض استخدام "الإطارات المُحيطة". يتيح نموذج التفاعل مع المنظومة المتكاملة في W3C ومؤسسات معايير الإعلان، مثل IAB Tech Lab، لخبراء المجال من جميع الأنواع توجيه التصاميم قبل أن تصبح مطلوبة. |
| (تم الإبلاغ عن ذلك أيضًا في الربع سنوية السابقة) اختلاف الحجم على جميع المنصّات |
الإبلاغ عن اختلاف حجم المحتوى المعروض في "الإطار المحدود" بين أجهزة الكمبيوتر المكتبي والهواتف الذكية | هذه مشكلة معروفة في Chromium ونحقق فيها حاليًا. نرحّب بملاحظاتك الإضافية هنا. |
| تحسين واجهة برمجة التطبيقات | هل تمّ تأجيل شرط استخدام الإطارات المُغلقة إلى عام 2025 لكي تصبح الإعلانات المدمجة متاحة الآن بموجب "مبادرة حماية الخصوصية"؟ | كما ذكرنا في الإعلان العلني الذي نشرناه بشأن تطبيق "الإطارات المُحيطة" في موعد أقصاه 2026، علمنا بوجود "جهود كبيرة للتوفّق" مع "الإطارات المُحيطة". بالتأكيد، كان أحد هذه العوامل هو استخدام اللغة الأصلية، ولكنّه لم يكن العامل الوحيد. وكان الهدف من ذلك توفير المزيد من الوقت لضمان جاهزية المنظومة المتكاملة لدعم حالات الاستخدام الرئيسية، بما في ذلك، على سبيل المثال لا الحصر، حالات الاستخدام الأصلية. |
Shared Storage API
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| الأداء | يبدو أنّ أوقات عرض Shared Storage خارج التطبيق المصغّر تعتمد على النشاط في التطبيق المصغّر. | يمكنك الاطّلاع على نتيجة الاختبار هذه هنا. |
| استخدام أوسع | يجب أن تكون "مساحة التخزين المشتركة" معيارًا على مستوى المجال متاحًا في جميع المتصفّحات. | نرحّب بهذه الملاحظات ونأخذها في الاعتبار. يواصل Chrome المشاركة بنشاط في منتديات W3C، بما في ذلك WICG، للترويج للاقتراح وطلب الملاحظات وتعزيز عملية الاعتماد. |
| وحدات عمل عروض الأسعار | هل من الممكن القراءة من مساحة التخزين المشتركة ضمن generateBid (التي يتم تشغيلها حاليًا في إحدى وحدات العمل) لتطبيق منطق القرار الإعلاني / النشاط التجاري (مثل الحدّ الأقصى لعدد مرّات الظهور) استنادًا إلى معلومات من مواقع إلكترونية متعددة واختيار مجموعة فرعية من الإعلانات؟ | لا، من المستحيل القراءة من مساحة التخزين المشتركة ضمن وحدات عمل عروض الأسعار. |
ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة (CHIPS)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| سعة التقسيم | توضيح السلوك عند تجاوز سعة القسم | عند بلوغ السعة، يتم إخراج أقدم ملفات تعريف الارتباط من ملفات تعريف الارتباط التي تم الوصول إليها مؤخرًا لتحرير الذاكرة إلى أن يتم إيقاف تجاوز الحدّ المسموح به. سيرى المطوّرون عنوان ملف تعريف الارتباط المعدَّل في الطلبات اللاحقة. |
| الوصول إلى إطار iframe التابع لجهة خارجية | يجب أن يتمكّن محتوى إطار iframe المضمّن التابع لجهة خارجية والذي يفتح علامة تبويب/نافذة جديدة للموقع الإلكتروني التابع للجهة الخارجية نفسه من الوصول إلى ملفات تعريف الارتباط المقسّمة نفسها التي يستخدمها المشغّل. | نحن نناقش حالة الاستخدام هذه ونرحّب بملاحظات إضافية من المنظومة المتكاملة هنا. |
| ملفات تعريف الارتباط المكرّرة | إذا كان هناك ملفّ تعريف ارتباط مُقسَّم وملفّ تعريف ارتباط غير مُقسَّم يحملان الاسم نفسه، ما هي قيمة المفتاح التي يقرّر المتصفّح إرسالها؟ | عند توفّر ملفَّي تعريف ارتباط يحملان الاسم نفسه (أحدهما مُقسَّم والآخر غير مُقسَّم)، ستحصل على ملفَّي تعريف الارتباط معًا، ولا يمكن التمييز بينهما. تتوفّر مواصفات RFC المتعلّقة بهذا الأمر هنا، وتوضّح أنّه لا يجب الاعتماد على ترتيب إرسال ملفات تعريف الارتباط. |
| طلب ميزة | فعِّل ملفات تعريف الارتباط المقسّمة حسب المصدر. | نحن ننظر في هذا الطلب ونرحّب بملاحظات إضافية من المنظومة المتكاملة هنا. |
FedCM
لم يتم تلقّي أي ملاحظات هذا الربع.
مكافحة المحتوى غير المرغوب فيه والاحتيال
Private State Tokens API (وواجهات برمجة التطبيقات الأخرى)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| عرض الويب | هل يتم الاحتفاظ بالرموز المميّزة للحالة الخاصة (PST) على مستوى عدّة عروض Webview على الجهاز الجوّال (الملف الشخصي) نفسه؟ | سيكون لكل تطبيق يستخدم webview مساحة تخزين محلية مختلفة، ما يعني أنّه لا يمكن لمُصدِري بطاقات PST إصدار الرموز في webview الخاص بتطبيق واحد ثم السماح باسترداد الرموز لاحقًا في تطبيق منفصل. وينطبق ذلك أيضًا على أشكال البيانات الأخرى المخزّنة محليًا في عروض الويب، مثل ملفات تعريف الارتباط. لا تتوفّر رسائل PST بالكامل بعد في WebView. نتوقع أن نُطلعك على آخر الأخبار بحلول نهاية الربع الثاني. |
| نوع الرمز المميّز الجديد | اقتراح لنوع رمز مميّز جديد | نشكرك على هذا الاقتراح والاستكشاف المستمر لتطبيقات وتعديلات رسائل طلب المساعدة، ونتطلّع إلى معرفة المزيد عن هذا الاقتراح في اجتماعات مجموعة مكافحة الاحتيال القادمة في الربع الثاني من عام 2024. |
| تحديد هوية المستخدِم | كيف يمكن منع تحديد هوية المستخدمين استنادًا إلى جداول زمنية محددة للبريد الإلكتروني يمتلكها المستخدم؟ | يتم حاليًا الحد من هذا الخطر من خلال حصر محاولات تحصيل القيمة على موقع إلكتروني بجهة إصدارَين، بغض النظر عمّا إذا كانت هناك رموز مميّزة متاحة من جهة الإصدار هذه. يجب احتساب جهة إصدار معيّنة ضمن الحدّ الأقصى حتى إذا لم تكن هناك رموز مميّزة متاحة، وإلا قد ينتقل الموقع الإلكتروني إلى جميع الجهات المُصدِرة إلى أن يصل إلى مطابقة إيجابية. |
| التسجيل | ما هي المدة التي سيظل فيها التسجيل مطلوبًا لخدمات البريد العادي؟ | وسيظلّ التسجيل مطلوبًا في المستقبل المنظور، كما هو موضّح بالتفصيل هنا. |
| التوافق مع متصفّحات Chromium الأخرى | هل سيتم إتاحة تسجيل جهة إصدار PST للمتصفّحات الأخرى المستندة إلى Chromium من خلال مستودع تسجيل جهة إصدار Chrome؟ | يُجلب Chrome العناصر الرئيسية ويوزّعها على عملاء Chrome من خلال آلية تُعرف باسم "برنامج تحديث المكوّنات". مع إضافة متصفّحات أخرى لدعم أكثر اكتمالاً لواجهة برمجة التطبيقات، ستحتاج إلى وضع عملية للحصول على الالتزامات الرئيسية للعميل، إما من خلال طريقة على غرار أداة تعديل المكوّنات أو طريقة أخرى. يمكنك الاطّلاع على مزيد من التفاصيل هنا. |