من مصلحة الجميع التأكّد من أنّ واجهة Protected Audience API تعمل بكفاءة:
- يريد المستخدمون الذين يتصفّحون الويب أن يتم تحميل المواقع الإلكترونية بسرعة. وهذا يعني أنّه على المطوّرين إنشاء تطبيقات متوافقة مع Protected Audience API بشكل فعّال كي لا يتم الإفراط في استخدام موارد الجهاز المحدودة، مثل موارد الحوسبة أو الشبكة، اللازمة لتحميل المواقع الإلكترونية والإعلانات المضمّنة فيها.
- يريد الناشرون أن يتم تحميل مواقعهم الإلكترونية بسرعة، ما يوفّر للمستخدمين تجربة فعّالة وسريعة الاستجابة. يهتم الناشرون أيضًا بعرض إعلانات فعّالة لزيادة إيراداتهم إلى أقصى حد.
- يريد المعلنون ومزوّدو تكنولوجيا الإعلان عرض إعلاناتهم بسرعة لتقديم أفضل فائدة.
يوضّح هذا المستند بعض أفضل الممارسات لتنفيذ Protected Audience API، وذلك لضمان عمل موقعك الإلكتروني بأقصى قدر من الكفاءة.
أفضل الممارسات المتعلّقة بالمشترين (مقدّمي عروض الأسعار)
لضمان تحسين كفاءة المزاد الذي يستخدم Protected Audience API، اتّبِع أفضل الممارسات التالية.
عدد أقل من مالكي المجموعات ذات الاهتمامات المشتركة
لحماية مقدّمي عروض الأسعار في Protected Audience API بالطريقة نفسها التي يحمي بها المتصفّح المصادر المختلفة على الويب باستخدام عزل المواقع الإلكترونية، يستخدم المتصفّح موارد مكلفة (مثل عمليات نظام التشغيل) لحماية مالكي مجموعات الاهتمامات الفردية.
للحدّ من إنفاق هذه الموارد الباهظة التكلفة، من المهم أن يكون هناك أقل عدد ممكن من مالكي المجموعات ذات الاهتمامات المشتركة. تجنَّب أن تمتلك نطاقات فرعية مختلفة مجموعات اهتمامات مختلفة. على سبيل المثال، إذا كانت adtech.example تتضمّن مجموعات اهتمامات مملوكة من قِبل cats.adtech.example وdogs.adtech.example، من المرجّح أن يستخدم المتصفّح عمليتَين منفصلتَين لتشغيل نصوص عروض الأسعار.
عدد أقل من المجموعات التي تقدّم عروض أسعار
يجب أن يجري المتصفّح عملية إعداد وتحضير كبيرة قبل استدعاء نص برمجي خاص بـ generateBid() أحد المشترين، مثل إعداد بيئة تنفيذ جديدة ونظيفة لبرنامج JavaScript، وتحليل رمز generateBid() وتحميله.
- يجب أن تتضمّن مجموعات الاهتمامات التي تمثّل المستخدمين الذين لا يستهدفهم حاليًا أي حملة إعلانية نشطة قوائم فارغة لتصاميم الإعلانات. يمنع ذلك تنفيذ
generateBid()في Protected Audience API للمجموعات ذات الاهتمامات المشتركة بدون إعلانات ذات صلة. - سيؤدي الجمع بين مجموعات الاهتمامات المتشابهة إلى تقليل عدد المرات التي يجب فيها تنفيذ
generateBid(). يمكن استخدام السمةuserBiddingSignalsلمجموعة اهتمامات لتخزين بيانات وصفية إضافية عن المستخدم، وبالتالي، لا يعني انخفاض عدد مجموعات الاهتمامات بالضرورة استهدافًا أقل فعالية. - تتيح Protected Audience API للمورّدين تحديد حدود لعدد المجموعات ذات الاهتمامات المشتركة، كما تتيح واجهة برمجة تطبيقات للمشترين لتحديد الأولوية النسبية لمجموعاتهم ذات الاهتمامات المشتركة. يمكن استخدام هذه الحدود لتقليل عدد نصوص عروض الأسعار التي سيتم تنفيذها بشكل كبير.
تصفية مجموعات الاهتمامات من عروض الأسعار في خدمة Key/Value
إذا كان بإمكان أحد المشترين تحديد أنّ مجموعات اهتمامات معيّنة يجب ألا تقدّم عروض أسعار في خادم إشارات "عروض الأسعار الموثوقة" في الوقت الفعلي (على سبيل المثال، إذا كانت الحملة غير مفعّلة أو متوقّفة مؤقتًا أو خارج نطاق الميزانية، أو إذا كان يجب ألا تقدّم عروض أسعار لهذا الناشر تحديدًا)، يمكنه إبلاغ المتصفّح بذلك من خلال الردّ priorityVector على عملية جلب إشارات "عروض الأسعار الموثوقة". إذا كانت نتيجة ضرب النقطة المتفرقة بين priorityVector وprioritySignals سالبة، سيتخطّى المتصفّح استدعاء generateBid() لمجموعة الاهتمامات هذه. يمكنك الاطّلاع على مزيد من المعلومات عن هذه الآلية في قسم"فلترة المجموعات ذات الاهتمامات المشتركة وتحديد أولويتها" في المستند التوضيحي.
إعادة استخدام بيئة تنفيذ JavaScript
قبل أن يتمكّن المتصفّح من تنفيذ generateBid()، يجب أن يبدأ بيئة تنفيذ JavaScript جديدة. قد يستغرق ذلك وقتًا طويلاً، أي ما يعادل الوقت الذي يستغرقه تنفيذ generateBid() بسيط. يمكن توفير هذا الوقت باستخدام وضعَي التنفيذ group-by-origin أو frozen-context.
يمكن أن يعيد وضع group-by-origin استخدام بيئات التنفيذ في الحالات التي يتم فيها الانضمام إلى مجموعات الاهتمامات على المصدر نفسه، ومن المحتمل ألا يتطلّب إجراء تغييرات على نص عروض الأسعار. لمعرفة المزيد، اطّلِع على وصف group-by-origin في المستند التوضيحي. يمكن أن يعيد وضع السياق المجمّد استخدام جميع بيئات التنفيذ المحتملة، ولكن قد يتطلّب إجراء تغييرات على نص عرض الأسعار. ولمزيد من المعلومات، اطّلِع على وصف frozen-context في الشرح.
إعادة استخدام نصوص عروض الأسعار البرمجية
استخدِم نص العرض نفسه لمجموعات الاهتمامات إذا أمكن. يمنع ذلك المتصفّح من تنزيل نصوص برمجية متعددة وتحليلها وتجميعها (ما يؤدي إلى طلبات إضافية من الشبكة). سيظل بإمكان مقدّمي عروض الأسعار التمييز بين عروض الأسعار استنادًا إلى معلومات المجموعة المهتمة (مثل name أو userBiddingSignals) أثناء استخدام النص البرمجي نفسه.
بدون عناوين التحكّم في ذاكرة التخزين المؤقت في HTTP، لا يتم تخزين نص برمجي لتقديم عروض الأسعار مؤقتًا. حدِّد العناوين المناسبة لضمان عدم جلب النص البرمجي بدون داعٍ. إذا كانت هناك مزادات متعدّدة على الصفحة يتم عرضها بالتوازي، ستتم إعادة استخدام نص عروض الأسعار الخاص بالمزايد نفسه إذا كان مخزّنًا في الذاكرة، مع تجاهل دلالات التخزين المؤقت. إذا تم تشغيل المزادات بالتسلسل، سيلتزم المتصفّح بآلية التخزين المؤقت لبروتوكول HTTP.
يُرجى العِلم أنّ المتصفّح يحمّل البرنامج النصي الخاص بتقديم عروض الأسعار خلال وقت تقديم عروض الأسعار (بالنسبة إلى generateBid()) وأيضًا خلال وقت إعداد التقارير (بالنسبة إلى reportWin()). وفي حال عدم ضبط عناوين التحكّم في ذاكرة التخزين المؤقت، سيجلب المتصفّح البرنامج النصي نفسه مرّتين، مرة واحدة لكل فترة زمنية.
لذلك، ننصحك بضبط عناوين التحكّم في ذاكرة التخزين المؤقت على جميع النصوص البرمجية.
إعادة الاستخدام trustedBiddingSignalsUrls
يمكن أن يكون وقت استجابة الشبكة واستخدام الموارد كبيرًا جدًا. يمكن أن يساعد تقليل عدد عمليات جلب إشارات "عروض الأسعار الموثوقة" في الوقت الفعلي في الحدّ من هذا التأخير.
يمكن دمج عمليات جلب إشارات عروض الأسعار الموثوقة عند إعادة استخدام trustedBiddingSignalsUrl بين مجموعات اهتمامات متعدّدة.
استخدِم trustedBiddingSignalsUrl نفسه لجميع فئات الاهتمامات، إذا أمكن ذلك.
حدِّد عناوين التحكّم في ذاكرة التخزين المؤقت لبروتوكول HTTP المناسبة لضمان تخزين عمليات جلب إشارات عروض الأسعار الموثوقة مؤقتًا في جميع مواضع الإعلانات على صفحة ويب معيّنة. تجنَّب ضبط trustedBiddingSignalsSlotSizeMode على slot-size لأنّ ذلك سيمنع التخزين المؤقت في جميع مواضع الإعلانات عندما تختلف أحجام المواضع لأنّ عنوان URL المطلوب سيختلف.
عمليات جلب أصغر لإشارات "عروض الأسعار الموثوقة في الوقت الفعلي"
يمكن أن يكون تأخّر الشبكة كبيرًا جدًا، ويتأثّر ذلك بشكل مباشر بكمية البيانات التي يتم نقلها أثناء عمليات جلب الإشارات في ميزة "عروض الأسعار الموثوقة" في الوقت الفعلي.
ننصح بتخزين البيانات الخاصة بالإعلانات أو البيانات الخاصة بمجموعة الاهتمامات في مجموعة الاهتمامات، بدلاً من تخزينها في خدمة إشارات عروض الأسعار الموثوقة في الوقت الفعلي. احتفِظ ببيانات إشارات عروض الأسعار الموثوقة في الوقت الفعلي للإشارات التي يتم إنشاؤها في الوقت الفعلي فقط، مثل ميزانية الحملة أو مفاتيح الإيقاف.
يجب تخزين أي إشارة يمكن تعديلها يوميًا أو على فترات أطول في مجموعة الاهتمامات وتعديلها باستخدام التعديلات اليومية.
لا تعرض إشارات عروض الأسعار الموثوق بها لمجموعات الاهتمامات التي تمّت فلترتها كما هو موضّح في قسم "فلترة مجموعات الاهتمامات من عروض الأسعار في خدمة المفتاح/القيمة".
تحديد أولويات المجموعات ذات الاهتمامات المشتركة
سيستخدم البائعون مهلات لتحديد كيفية استخدام موارد المتصفّح على صفحات الناشرين. عند استخدام perBuyerCumulativeTimeouts للحدّ من المدة التي يستغرقها المشترون لجلب إشارات عروض الأسعار الموثوقة وتنفيذ نصوص عروض الأسعار، من المهم أن يحرص المشترون على تحديد أولويات مجموعات الاهتمامات لضمان تنفيذ عروض الأسعار التي من المرجّح أن تفوز بالمزاد أولاً. على سبيل المثال، إذا تم ضبط perBuyerCumulativeTimeouts على 100 ملي ثانية واستغرقت عملية جلب إشارات عروض الأسعار الموثوقة من مقدّم عروض الأسعار 50 ملي ثانية، واستغرقت كل عملية استدعاء generateBid() 10 ملي ثانية وكان هناك 10 مجموعات اهتمامات على الجهاز، سيتمكّن نصف مجموعات الاهتمامات فقط من حساب عروض الأسعار. على المشتري في هذا المثال ترتيب مجموعات الاهتمامات حسب الأولوية من الأكثر احتمالاً للفوز إلى الأقل احتمالاً للفوز.
يمكن أن تحتوي مجموعات الاهتمامات على أولويات ثابتة محدّدة باستخدام الحقل priority. يمكن أن تستخدم مجموعات الاهتمامات أيضًا أولويات ديناميكية يمكن احتسابها في خدمة إشارات عروض الأسعار الموثوق بها وإرجاعها إلى المتصفّح مع الردّ priorityVector على عملية جلب إشارات عروض الأسعار الموثوق بها.
يُرجى العِلم أنّه عندما ينفّذ المتصفّح المجموعات ذات الاهتمامات المشترَكة من الأولوية الأعلى إلى الأولوية الأقل، قد يؤدي ذلك إلى تداخل المجموعات ذات الاهتمامات المشترَكة من مصادر مختلفة للانضمام، ما قد يؤدي إلى إيقاف تحسين group-by-origin.
أفضل الممارسات المتعلّقة بالبائعين
احرص على مراقبة كفاءة المزاد الذي يستخدم Protected Audience API وتحسينها.
موازاة المزادات
تؤدي اتصالات الشبكة الحديثة والمعالِجات المتعددة النواة أداءً رائعًا في تنفيذ أنشطة متعددة في الوقت نفسه. يمكن للمتصفّح تنفيذ مزاد Protected Audience بالتوازي مع الأنشطة الأخرى. يمكن تسهيل ذلك بشكل أفضل من خلال الاتصال على الرقم runAdAuction() في أقرب وقت ممكن. مع العلم أنّ بعض المدخلات إلى runAdAuction() قد لا تكون متاحة في البداية، مثل تلك التي يتم إرسالها مرة أخرى إلى المتصفّح في الرد السياقي، يسمح المتصفّح باستدعاء runAdAution() قبل أن تصبح متاحة، وتوفير هذه المدخلات في وقت لاحق باستخدام JavaScript Promises. لتحقيق أقل وقت استجابة ممكن للمزاد، يجب طلب runAdAuction() عند توفّر قيمة الإدخال interestGroupBuyers. ويتيح ذلك بدء العديد من أجزاء المزاد على الفور، بما في ذلك جلب إشارات عروض الأسعار في الوقت الفعلي الخاصة مقدِّمي عروض الأسعار.
مراقبة مزاداتك
جمع مقاييس حول مزاداتك يمكن للمتصفّح إرسال تقارير per-buyer مقاييس وقت الاستجابة إلى البائعين الذين يقدّمون الكثير من الإحصاءات حول الوقت المستغرَق في مزادات البائعين. يمكن للبائعين استخدام هذه المقاييس للبحث عن طرق لتحسين مزاداتهم، بما في ذلك تقديم معلومات حول كيفية ضبط المهلات بأكثر الطرق فعالية. يمكن للبائعين مشاركة مقاييس وقت الاستجابة الخاصة بمشترٍ معيّن مع هذا المشتري لمساعدته في إجراء المزيد من التحسينات.
قد يحصل مقدّمو عروض الأسعار على إحصاءات حول أداء عروض الأسعار لمجموعات الاهتمامات الخاصة بهم، ولكن قد لا يتمكّنون من مقارنة ذلك بأداء مقدّمي عروض الأسعار الآخرين. قد تساعد مقارنة معدّلات الفوز النسبية ومعدّلات رفض عروض الأسعار لمقدّمي عروض الأسعار المختلفين في تحديد الحالات التي تم فيها إهدار موارد الحوسبة الخاصة بعروض الأسعار بسبب عدم تقديم المجموعات المهتمة عروض أسعار صالحة أو تقديم عروض أسعار مفرطة باستخدام تصاميم إعلانات غير معتمَدة.
الحماية من النصوص البرمجية البطيئة الخاصة بتقديم عروض الأسعار
يمكن أن تؤدي نصوص عروض الأسعار التي تستغرق وقتًا طويلاً إلى إبطاء مزاد Protected Audience API لجميع الجهات المعنية. يمكن أن يؤدي استخدام مهلات إلى منع المزادات البطيئة مع استرداد الأرباح عندما يكون المزاد بطيئًا.
على البائعين استخدام perBuyerCumulativeTimeouts لمنع بطء المزادات، وكذلك لمواصلة قبول عروض الأسعار عندما يكون المزاد بطيئًا ويصل إلى المهلة المحدّدة. يُفضّل استخدام perBuyerCumulativeTimeouts على استخدام perBuyerTimeouts وperBuyerGroupLimits لأنّ perBuyerCumulativeTimeouts لا يفرض أي قيود على عدد المجموعات المستندة إلى الاهتمامات أو سرعة generateBid() (على سبيل المثال، يمكن أن يكتمل كلّ من المجموعات المستندة إلى الاهتمامات التي تقدّم عروض أسعار بسرعة والمجموعات المستندة إلى الاهتمامات التي تقدّم عروض أسعار ببطء قبل انتهاء المهلة).
يُنصح أيضًا باستخدام حقل signal في إعدادات المزاد لتنفيذ مهلة مزاد شاملة من أجل منع المزادات الطويلة جدًا في الحالات التي تستغرق فيها عمليات جلب إشارات تسجيل النقاط الموثوقة وتنفيذ scoreAd() وقتًا طويلاً جدًا.
ما هي الخطوات التالية؟
نريد المشاركة في محادثات معك للتأكد من أننا ننشئ واجهة برمجة تطبيقات تناسب الجميع.
مناقشة واجهة برمجة التطبيقات
مثل واجهات برمجة التطبيقات الأخرى في "مبادرة حماية الخصوصية"، يتم توثيق واجهة برمجة التطبيقات هذه ومناقشتها بشكل علني.
إجراء التجارب باستخدام واجهة برمجة التطبيقات
يمكنك تجربة الميزة والمشاركة في محادثة حول Protected Audience API.