تحسين وقت استجابة المزاد في 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، من المرجّح أن يستخدم المتصفّح عمليتَين منفصلتَين لتشغيل ملفّات برمجية bidding.

انخفاض عدد مجموعات الاهتمامات التي تقدّم عروض أسعار

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

بدون عناوين التحكّم في ذاكرة التخزين المؤقت في 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 وتحسينها.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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