تأخیر حراج API مخاطب محافظت شده را بهبود بخشید

به نفع همه است که مطمئن شوند API مخاطب محافظت‌شده به طور کارآمد عمل می‌کند:

• افرادی که در وب گشت و گذار می‌کنند می‌خواهند سایت‌ها سریع بارگذاری شوند. این بدان معناست که توسعه‌دهندگان باید با API مخاطب محافظت‌شده به طور مؤثری کار کنند تا از منابع محدود دستگاه، مانند منابع محاسباتی یا شبکه‌ای که برای بارگذاری سایت‌ها و تبلیغات تعبیه‌شده در آن‌ها ضروری هستند، بیش از حد استفاده نشود.
• ناشران می‌خواهند سایت‌هایشان سریع بارگذاری شوند و تجربه‌ای کارآمد و پاسخگو را برای کاربران فراهم کنند. ناشران همچنین برای به حداکثر رساندن درآمد خود، تبلیغات مؤثر می‌خواهند.
• تبلیغ‌کنندگان و متخصصان تبلیغات می‌خواهند تبلیغاتشان به سرعت نمایش داده شود تا بیشترین کاربرد را داشته باشد.

این سند برخی از بهترین شیوه‌ها را برای پیاده‌سازی API مخاطب محافظت‌شده تشریح می‌کند تا از عملکرد سایت شما با حداکثر کارایی اطمینان حاصل شود.

بهترین شیوه‌های خریدار (پیشنهاد دهنده)

برای اطمینان از بهینه‌سازی برای کارایی حراج API مخاطبان محافظت‌شده، این بهترین شیوه‌ها را دنبال کنید.

تعداد کمتری از صاحبان گروه‌های ذینفع

برای محافظت از پیشنهاددهندگان API مخاطب محافظت‌شده، همانطور که مرورگر از منابع مختلف در وب با استفاده از جداسازی سایت محافظت می‌کند، مرورگر از منابع گران‌قیمت (مانند فرآیندهای سیستم‌عامل) برای محافظت از مالکان گروه‌های ذینفع استفاده می‌کند.

برای به حداقل رساندن هزینه‌های این منابع بسیار گران‌قیمت، داشتن کمترین تعداد صاحبان گروه‌های ذینفع بسیار مهم است. از داشتن گروه‌های ذینفع مختلف که متعلق به زیردامنه‌های مختلف هستند، خودداری کنید. به عنوان مثال، اگر adtech.example گروه‌های ذینفع متعلق به cats.adtech.example و dogs.adtech.example داشته باشد، مرورگر احتمالاً از دو فرآیند جداگانه برای اجرای اسکریپت‌های پیشنهاد قیمت آنها استفاده می‌کند.

گروه‌های ذی‌نفع کمتری پیشنهاد قیمت می‌دهند

مرورگر قبل از فراخوانی اسکریپت generateBid() خریدار، باید تنظیمات و آماده‌سازی‌های قابل توجهی انجام دهد، مانند راه‌اندازی یک محیط اجرای جاوا اسکریپت جدید و تمیز، و تجزیه و بارگذاری کد generateBid() .

• گروه‌های ذینفع که نماینده کاربرانی هستند که هدف فعلی یک کمپین تبلیغاتی فعال نیستند، باید لیست‌های تبلیغاتی خالی داشته باشند. این امر مانع از اجرای generateBid() توسط API مخاطبان محافظت‌شده برای گروه‌های ذینفع بدون تبلیغات مرتبط می‌شود.
• ترکیب گروه‌های علاقه‌مند مشابه، تعداد دفعاتی که generateBid() باید اجرا شود را کاهش می‌دهد. می‌توان از ویژگی userBiddingSignals یک گروه علاقه‌مند برای ذخیره فراداده‌های اضافی در مورد کاربر استفاده کرد، بنابراین گروه‌های علاقه‌مند کمتر به معنای هدف‌گیری کمتر و مؤثرتر نیست.
• API مخاطب محافظت‌شده از محدودیت‌های تعیین‌شده توسط فروشنده در مورد تعداد گروه‌های ذینفع و یک API برای خریداران برای تعیین اولویت نسبی گروه‌های ذینفع خود پشتیبانی می‌کند. این محدودیت‌ها می‌توانند برای کاهش قابل توجه تعداد اسکریپت‌های پیشنهاد قیمت برای اجرا استفاده شوند.

گروه‌های ذینفع را از پیشنهاد قیمت در سرویس کلید/مقدار خود فیلتر کنید

اگر یک خریدار بتواند در سرور سیگنال مناقصه مورد اعتماد خود در لحظه تعیین کند که گروه‌های ذینفع خاصی نباید پیشنهاد قیمت بدهند (مثلاً کمپین غیرفعال، متوقف یا خارج از بودجه است، یا نباید روی این ناشر خاص پیشنهاد قیمت بدهد)، می‌تواند این موضوع را با پاسخ priorityVector به سیگنال‌های مناقصه مورد اعتماد واکشی شده به مرورگر نشان دهد. اگر حاصلضرب نقطه‌ای پراکنده priorityVector و prioritySignals منفی باشد، مرورگر از فراخوانی generateBid() برای این گروه ذینفع صرف نظر می‌کند. می‌توانید اطلاعات بیشتر در مورد این مکانیسم را در بخش «فیلتر کردن و اولویت‌بندی گروه‌های ذینفع» در توضیح‌دهنده بخوانید.

استفاده مجدد از محیط اجرای جاوا اسکریپت

قبل از اینکه مرورگر بتواند generateBid() را اجرا کند، باید یک محیط اجرای جاوا اسکریپت جدید راه‌اندازی کند. این کار می‌تواند زمان قابل توجهی طول بکشد، درست مانند زمانی که خود تابع generateBid() حداقلی برای اجرا نیاز دارد. این زمان را می‌توان با استفاده از حالت‌های اجرای group-by-origin یا frozen-context صرفه‌جویی کرد.

حالت group-by-origin می‌تواند در مواردی که گروه‌های ذینفع در یک مبدا به هم متصل هستند، از محیط‌های اجرا مجدداً استفاده کند و احتمالاً نیازی به تغییر در اسکریپت پیشنهاد شما نخواهد داشت؛ برای کسب اطلاعات بیشتر، به توضیحات group-by-origin در توضیح‌دهنده مراجعه کنید. حالت frozen-context می‌تواند به طور بالقوه از همه محیط‌های اجرا مجدداً استفاده کند، اما ممکن است نیاز به تغییراتی در اسکریپت پیشنهاد شما داشته باشد؛ برای کسب اطلاعات بیشتر، به توضیحات frozen-context در توضیح‌دهنده مراجعه کنید.

استفاده مجدد از اسکریپت‌های پیشنهاد قیمت

در صورت امکان، از یک اسکریپت پیشنهاد قیمت برای گروه‌های ذینفع استفاده کنید. این کار مانع از آن می‌شود که مرورگر مجبور به دانلود، تجزیه و کامپایل چندین اسکریپت شود (که باعث درخواست‌های شبکه اضافی می‌شود). پیشنهاددهندگان همچنان می‌توانند در حین استفاده از یک اسکریپت، بر اساس اطلاعات گروه‌های ذینفع (مثلاً name یا userBiddingSignals ) پیشنهاد قیمت خود را متمایز کنند.

بدون هدرهای کنترل حافظه پنهان HTTP ، اسکریپت پیشنهاد دهنده ذخیره نمی‌شود. هدرهای مناسب را مشخص کنید تا اطمینان حاصل شود که اسکریپت بی‌جهت واکشی نمی‌شود. اگر چندین مزایده در صفحه به صورت موازی در حال اجرا باشند، اسکریپت پیشنهاد دهنده همان پیشنهاد دهنده در صورتی که از قبل در حافظه باشد، مجدداً استفاده می‌شود و معنای ذخیره‌سازی را نادیده می‌گیرد. اگر مزایده‌ها به صورت متوالی اجرا شوند، مرورگر به مکانیسم ذخیره‌سازی HTTP پایبند خواهد بود.

توجه داشته باشید که مرورگر اسکریپت پیشنهاد قیمت را در زمان پیشنهاد قیمت (برای generateBid() ) و همچنین در زمان گزارش (برای reportWin() ) بارگذاری می‌کند. اگر هدرهای کنترل حافظه پنهان تنظیم نشده باشند، مرورگر همان اسکریپت را دو بار، یک بار برای هر دوره زمانی، بارگیری می‌کند.

بنابراین، توصیه می‌کنیم هدرهای کنترل حافظه پنهان را روی تمام اسکریپت‌های خود تنظیم کنید.

استفاده مجدد از trustedBiddingSignalsUrls

تأخیر شبکه و استفاده از منابع می‌تواند بسیار مهم باشد. دریافت کمتر سیگنال‌های پیشنهاد قیمت قابل اعتماد در لحظه می‌تواند به کاهش این تأخیر کمک کند.

سیگنال‌های پیشنهاد قیمت معتبر می‌توانند زمانی که trustedBiddingSignalsUrl بین چندین گروه ذینفع دوباره استفاده می‌شود، با هم ترکیب شوند . در صورت امکان، trustedBiddingSignalsUrl یکسان برای همه گروه‌های ذینفع استفاده کنید.

هدرهای کنترل حافظه پنهان HTTP مناسب را مشخص کنید تا اطمینان حاصل شود که سیگنال‌های مناقصه معتبر در سراسر اسلات‌های تبلیغاتی در یک صفحه وب خاص ذخیره می‌شوند. از تنظیم trustedBiddingSignalsSlotSizeMode روی slot-size خودداری کنید زیرا این کار از ذخیره شدن در اسلات‌های تبلیغاتی در زمانی که اندازه اسلات‌ها متفاوت است، به دلیل متفاوت بودن URL درخواستی، جلوگیری می‌کند.

سیگنال‌های مناقصه قابل اعتماد کوچکتر در زمان واقعی، واکشی می‌شوند

تأخیر شبکه می‌تواند بسیار قابل توجه باشد و این مستقیماً تحت تأثیر میزان داده‌ای است که در طول دریافت سیگنال مناقصه قابل اعتماد در زمان واقعی منتقل می‌شود.

ترجیح می‌دهید داده‌های مربوط به تبلیغات خاص یا گروه‌های خاص را در گروه مربوطه ذخیره کنید، نه در سرویس سیگنال مناقصه قابل اعتماد در لحظه. داده‌های سیگنال مناقصه قابل اعتماد در لحظه را فقط برای سیگنال‌های واقعاً در لحظه، مانند بودجه‌بندی کمپین یا kill-switchها، ذخیره کنید.

هر سیگنالی که بتواند روزانه یا طولانی‌تر به‌روزرسانی شود، باید در گروه علاقه‌مندان ذخیره شود و با استفاده از به‌روزرسانی‌های روزانه به‌روزرسانی شود.

سیگنال‌های پیشنهاد قیمت معتبر برای گروه‌های ذینفعی که طبق توضیحات بخش «فیلتر کردن گروه‌های ذینفع از پیشنهاد قیمت در سرویس کلید/مقدار شما» فیلتر شده‌اند را ارسال نکنید.

اولویت‌بندی گروه‌های ذی‌نفع

فروشندگان از زمان‌های انتظار برای محدود کردن نحوه استفاده از منابع مرورگر در صفحات ناشر استفاده می‌کنند. هنگامی که perBuyerCumulativeTimeouts برای محدود کردن مدت زمانی که خریداران باید سیگنال‌های پیشنهاد قیمت مورد اعتماد خود را دریافت و اسکریپت‌های پیشنهاد قیمت خود را اجرا کنند، استفاده می‌شود، برای خریداران بسیار مهم است که مطمئن شوند گروه‌های مورد علاقه خود را اولویت‌بندی می‌کنند تا کسانی که بیشترین احتمال برنده شدن در حراج را دارند، ابتدا اجرا شوند. به عنوان مثال، اگر perBuyerCumulativeTimeouts روی ۱۰۰ میلی‌ثانیه تنظیم شود و دریافت سیگنال‌های پیشنهاد قیمت مورد اعتماد یک پیشنهاد دهنده ۵۰ میلی‌ثانیه طول بکشد و هر فراخوانی generateBid() 10 میلی‌ثانیه طول بکشد و آنها ۱۰ گروه مورد علاقه در یک دستگاه داشته باشند، در این صورت فقط نیمی از گروه‌های مورد علاقه آنها فرصتی برای محاسبه پیشنهادات خواهند داشت. خریدار در این مثال باید گروه‌های مورد علاقه خود را به ترتیب از بیشترین احتمال برد تا کمترین احتمال برد اولویت‌بندی کند.

گروه‌های ذی‌نفع می‌توانند شامل اولویت‌های ایستا باشند که با فیلد priority آنها تعریف می‌شوند. گروه‌های ذی‌نفع همچنین می‌توانند از اولویت‌های پویا استفاده کنند که می‌توانند در سرویس سیگنال‌های مناقصه مورد اعتماد آنها محاسبه شوند و با پاسخ priorityVector به سیگنال‌های مناقصه مورد اعتماد واکشی شده، به مرورگر بازگردانده شوند.

توجه داشته باشید که وقتی مرورگر گروه‌های علاقه‌مندی را از بالاترین اولویت به پایین‌ترین اولویت اجرا می‌کند، ممکن است گروه‌های علاقه‌مندی از مبداهای اتصال مختلف را در هم تداخل دهد که ممکن است بهینه‌سازی group-by-origin را با شکست مواجه کند.

بهترین شیوه‌های فروشنده

مطمئن شوید که کارایی حراج API مخاطبان محافظت‌شده را رصد و بهینه‌سازی می‌کنید.

مزایده‌های موازی

اتصالات شبکه مدرن و پردازنده‌های چند هسته‌ای در انجام همزمان چندین فعالیت، عملکرد بسیار خوبی دارند. مرورگر می‌تواند یک حراج مخاطب محافظت‌شده را به موازات سایر فعالیت‌ها اجرا کند. این کار را می‌توان با فراخوانی runAdAuction() در اسرع وقت، به بهترین شکل ممکن تسهیل کرد. با توجه به اینکه برخی از ورودی‌های runAdAuction() ممکن است در ابتدا در دسترس نباشند، به عنوان مثال، آن‌هایی که در پاسخ متنی به مرورگر ارسال می‌شوند، مرورگر اجازه می‌دهد runAdAution() قبل از در دسترس بودن آنها فراخوانی کند و این ورودی‌ها را بعداً با استفاده از Promises جاوا اسکریپت ارائه دهد. برای دستیابی به کمترین تأخیر ممکن در حراج، runAdAuction() باید زمانی فراخوانی شود که ورودی interestGroupBuyers شناخته شده باشد. این امر به بسیاری از بخش‌های حراج اجازه می‌دهد تا بلافاصله شروع شوند، از جمله دریافت سیگنال‌های پیشنهاد قیمت در زمان واقعی پیشنهاد دهنده.

حراج‌های خود را رصد کنید

معیارهای مربوط به حراجی‌های خود را جمع‌آوری کنید. مرورگر می‌تواند معیارهای تأخیر per-buyer به فروشندگان گزارش دهد که بینش زیادی در مورد نحوه صرف زمان در حراجی‌های فروشنده ارائه می‌دهد. فروشندگان می‌توانند از این معیارها برای یافتن راه‌هایی برای بهینه‌سازی حراجی‌های خود، از جمله اطلاع‌رسانی در مورد نحوه تنظیم مؤثرترین زمان‌های انتظار ، استفاده کنند. فروشندگان می‌توانند معیارهای تأخیر یک خریدار خاص را با خریدار به اشتراک بگذارند تا به آنها در بهینه‌سازی بیشتر کمک کند.

پیشنهاددهندگان ممکن است از عملکرد پیشنهاددهی گروه‌های ذی‌نفع خود آگاهی داشته باشند، اما ممکن است نتوانند این را با سایر پیشنهاددهندگان مقایسه کنند. مقایسه نرخ‌های نسبی برد و نرخ‌های رد پیشنهاد برای پیشنهاددهندگان مختلف می‌تواند به شناسایی مواردی که منابع محاسباتی پیشنهاددهی به دلیل اینکه گروه‌های ذی‌نفع هرگز پیشنهادهای قابل قبولی ارائه نداده‌اند یا پیشنهادهای بیش از حد با خلاقیت‌های تأیید نشده ارائه داده‌اند، هدر رفته است، کمک کند.

محافظت در برابر اسکریپت‌های پیشنهاد قیمت کند

اسکریپت‌های پیشنهاد قیمت که زمان زیادی می‌برند، می‌توانند حراج API مخاطبان محافظت‌شده را برای همه افراد درگیر کند کنند. استفاده از مهلت‌های زمانی می‌تواند از حراج‌های کند جلوگیری کند و در عین حال درآمد را در مواقع کندی حراج بازیابی کند.

فروشندگان باید از perBuyerCumulativeTimeouts برای جلوگیری از حراج‌های کند و همچنین برای پذیرش پیشنهادها در زمانی که حراج کند است و به زمان انقضا می‌رسد، استفاده کنند. استفاده از perBuyerCumulativeTimeouts نسبت به استفاده perBuyerTimeouts و perBuyerGroupLimits ارجحیت دارد زیرا perBuyerCumulativeTimeouts در مورد تعداد گروه‌های ذینفع یا سرعت generateBid() نظر خاصی ندارد (مثلاً بسیاری از گروه‌های ذینفع که سریع پیشنهاد می‌دهند و تعداد کمی از گروه‌های ذینفع که آهسته پیشنهاد می‌دهند، می‌توانند هر دو قبل از اتمام زمان انقضا، حراج را تکمیل کنند).

استفاده از فیلد signal پیکربندی حراج برای پیاده‌سازی یک زمان‌بندی کلی حراج، ایده خوبی برای جلوگیری از حراج‌های بیش از حد طولانی در مواردی است که سیگنال امتیازدهی معتبر واکشی می‌شود و اجرای scoreAd() زمان زیادی می‌برد.

بعدش چی؟

ما می‌خواهیم با شما گفتگو کنیم تا اطمینان حاصل کنیم که یک API درست می‌کنیم که برای همه کار کند.

در مورد API بحث کنید

مانند سایر APIهای Privacy Sandbox، این API مستند شده و به صورت عمومی مورد بحث قرار گرفته است.

با API آزمایش کنید

می‌توانید آزمایش کنید و در گفتگو درباره API مخاطبان محافظت شده شرکت کنید .