تحسين وقت استجابة المزاد في Protected Audience API

من مصلحة الجميع التأكّد من عمل 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() وتحميله.

• يجب أن تحتوي مجموعات الاهتمامات التي تمثّل المستخدمين غير المستهدَفين حاليًا لحملة إعلانية نشطة على قوائم فارغة لتصميمات الإعلانات. ويمنع ذلك Protected Audience API من تنفيذ generateBid() لمجموعات الاهتمامات بدون إعلانات ذات صلة.
• سيؤدي الجمع بين مجموعات الاهتمامات المشتركة إلى تقليل عدد المرات التي يجب فيها تنفيذ generateBid(). يمكن استخدام خاصية userBiddingSignals لمجموعة الاهتمامات من أجل تخزين بيانات وصفية إضافية عن المستخدم، وبالتالي ليس من الضروري أن يؤدي انخفاض عدد مجموعات الاهتمامات إلى استهداف أقل فعالية.
• وتتيح واجهة برمجة التطبيقات Protected Audience API الحدود التي يحدِّدها البائع لأعداد مجموعات الاهتمامات، كما توفِّر واجهة برمجة تطبيقات للمشترين لتحديد الأولوية النسبية لمجموعات الاهتمامات الخاصة بهم. يمكن استخدام هذه الحدود لتقليل عدد النصوص البرمجية لعروض الأسعار المطلوب تشغيلها بشكل كبير.

استبعاد مجموعات الاهتمامات من عروض الأسعار في خدمة المفتاح/القيمة

إذا تمكّن المشتري من تحديد خادم إشارات عروض الأسعار الموثوق بها في الوقت الفعلي أنّه يجب عدم تقديم عروض أسعار لمجموعات معيَّنة من الاهتمامات (على سبيل المثال، تم إيقاف الحملة أو إيقافها مؤقتًا أو نفادها من الميزانية أو عدم تقديم عروض أسعار لهذا الناشر تحديدًا)، يمكنه الإشارة إلى ذلك للمتصفّح من خلال استجابة priorityVector لاسترجاع إشارات عروض الأسعار الموثوق بها. إذا كان ناتج ضرب النقاط المتفرقة priorityVector وprioritySignals سالبًا، سيتخطّى المتصفّح استدعاء generateBid() لمجموعة الاهتمامات هذه. يمكنك الاطّلاع على مزيد من المعلومات عن هذه الآلية في قسم"فلترة المجموعات ذات الاهتمامات المشتركة وتحديد أولوياتها" في الشرح التوضيحي.

إعادة استخدام بيئة تنفيذ JavaScript

قبل أن يتمكّن المتصفِّح من تنفيذ generateBid()، يجب إعداد بيئة تنفيذ JavaScript جديدة. وقد يستغرق ذلك وقتًا كبيرًا، بمعنى آخر، الحد الأدنى من الوقت الذي يمكن أن يستغرقه تنفيذ generateBid(). ويمكن توفير هذا الوقت باستخدام وضعَي التنفيذ بالتجميع حسب المصدر أو السياق المجمّد.

يمكن أن يُعيد وضع group-by-origin استخدام بيئات التنفيذ في الحالات التي يتم فيها ضم مجموعات الاهتمامات على المصدر نفسه، ومن المحتمل ألّا يتطلّب ذلك إجراء أيّ تغييرات على النص البرمجي لعروض الأسعار. لمزيد من المعلومات، اطّلِع على وصف group-by-origin في الشرح. يمكن لوضع السياق المجمّد إعادة استخدام جميع بيئات التنفيذ المحتمَلة، ولكنه قد يتطلب تغييرات في النص البرمجي لعروض الأسعار. لمزيد من المعلومات، اطّلِع على وصف frozen-context في الشرح.

إعادة استخدام النصوص البرمجية لعروض الأسعار

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

إعادة استخدام trustedBiddingSignalsUrls

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

يمكن دمج عمليات استرجاع إشارات عروض الأسعار الموثوق بها عند إعادة استخدام trustedBiddingSignalsUrl من بين مجموعات اهتمامات متعددة. استخدِم السمة trustedBiddingSignalsUrl نفسها لجميع مجموعات الاهتمامات، عندما يكون ذلك ممكنًا.

حدِّد عناوين التحكّم في ذاكرة التخزين المؤقت لبروتوكول HTTP المناسبة لضمان تخزين إشارات عروض الأسعار الموثوق بها مؤقتًا في جميع الخانات الإعلانية على صفحة ويب معيّنة. تجنَّب ضبط trustedBiddingSignalsSlotSizeMode على slot-size لأنّ ذلك سيمنع التخزين المؤقت في جميع الخانات الإعلانية عندما تختلف أحجام الخانات بسبب اختلاف عنوان URL المطلوب.

يتم استرجاع إشارات عروض أسعار موثوق بها في الوقت الفعلي أصغر حجمًا

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

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

أي إشارة يمكن تعديلها يوميًا أو لفترة أطول يجب تخزينها في مجموعة الاهتمامات وتعديلها باستخدام التعديلات اليومية.

لا تعرِض إشارات عروض أسعار موثوق بها لمجموعات الاهتمامات التي تمت فلترتها على النحو الموضّح في قسم "استبعاد مجموعات الاهتمامات من عروض الأسعار في خدمة المفتاح/القيمة".

ترتيب أولوية المجموعات ذات الاهتمامات المشتركة

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

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

تجدر الإشارة إلى أنّه عندما ينفِّذ المتصفّح مجموعات اهتمامات من أعلى أولوية إلى أدنى، قد يتخلل هذا مجموعات الاهتمامات من مصادر ربط مختلفة، ما قد يؤدي إلى إلغاء تحسين group-by-origin.

أفضل الممارسات المتعلقة بالبائعين

تأكَّد من أنّك تتتبّع وتحسين كفاءة مزاد Protected Audience API.

موازاة المزادات

تؤدي اتصالات الشبكة الحديثة والمعالجات متعددة النواة عملاً رائعًا في أداء أنشطة متعددة في آنٍ واحد. ويمكن للمتصفّح تنفيذ مزاد "جمهور محمي" بالتوازي مع أنشطة أخرى. يمكن تسهيل الأمر على الرقم runAdAuction() في أقرب وقت ممكن. ندرك أنّ بعض الإدخالات إلى runAdAuction() قد لا تكون متاحة في وقت مبكر، مثل تلك التي يتم إرسالها إلى المتصفّح في الاستجابة السياقية، يسمح المتصفّح باستدعاء runAdAution() قبل توفُّرها، وتقديم هذه الإدخالات في وقت لاحق باستخدام وعود JavaScript. لتحقيق أقل وقت استجابة ممكن في المزاد، يجب استدعاء runAdAuction() عندما يكون إدخال interestGroupBuyers معروفًا. يؤدّي ذلك إلى بدء العديد من أجزاء المزاد على الفور، بما في ذلك استرجاع إشارات عروض الأسعار في الوقت الفعلي لمقدِّم عروض الأسعار.

مراقبة المزادات

جمع المقاييس في مزاداتك ويمكن للمتصفّح الإبلاغ عن مقاييس وقت الاستجابة per-buyer للبائعين الذين يقدّمون الكثير من الإحصاءات حول الوقت الذي يتم قضاؤه في مزادات البائع. يمكن للبائعين استخدام هذه المقاييس للبحث عن طرق لتحسين مزاداتهم، بما في ذلك تحديد كيفية ضبط المهلات على نحو أكثر فعالية. يمكن للبائعين مشاركة مقاييس وقت استجابة مشترٍ معيّن مع المشتري لمساعدتهم على إجراء تحسين أكبر.

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

الحماية من النصوص البرمجية لعروض الأسعار البطيئة

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

على البائعين استخدام perBuyerCumulativeTimeouts لمنع المزادات البطيئة وكذلك قبول عروض الأسعار عندما يكون المزاد بطيئًا وينتهي إلى انتهاء المهلة. يُفضّل استخدام السمتَين perBuyerCumulativeTimeouts وperBuyerTimeouts وperBuyerGroupLimits لأنّ السمة perBuyerCumulativeTimeouts لا تعبّر عن رأيها بشأن عدد المجموعات ذات الاهتمامات المشتركة أو السرعة generateBid() (على سبيل المثال، العديد من مجموعات الاهتمامات التي تقدِّم عروض أسعار بسرعة، وعدد قليل من مجموعات الاهتمامات التي تقدِّم عروض أسعار ببطء يمكن إكمالها معًا قبل انتهاء المهلة).

من المفيد أيضًا استخدام حقل signal الخاص بإعدادات المزاد لتنفيذ مهلة عامة للمزاد من أجل منع المزادات الطويلة جدًا في الحالات التي يستغرق فيها جلب إشارات تسجيل النتائج الموثوقة وتنفيذ scoreAd() وقتًا طويلاً.

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

ما هي الخطوات التالية؟

نريد المشاركة في محادثات معك للتأكد من أننا ننشئ واجهة برمجة تطبيقات تناسب الجميع.

مناقشة واجهة برمجة التطبيقات

مثل واجهات برمجة التطبيقات الأخرى في "مبادرة حماية الخصوصية"، يتم توثيق واجهة برمجة التطبيقات هذه ومناقشتها بشكل علني.

إجراء التجارب باستخدام واجهة برمجة التطبيقات

يمكنك تجربة الميزة والمشاركة في محادثة حول Protected Audience API.