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

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

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

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

بهترین شیوه های خریدار (مناقصه دهنده).

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

مالکان گروه ذینفع کمتر

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

حراج ها را موازی کنید

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

حراج های خود را زیر نظر داشته باشید

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

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

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

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

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

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

مهم: یادداشتی در مورد زمان حراج - مردم اغلب می پرسند "حراج مخاطب محافظت شده چقدر طول می کشد؟"، "فروشنده باید وقفه های زمانی را روی چه چیزی تنظیم کند؟" یا "خریدار برای چه تاخیری باید بهینه سازی کند؟" پاسخ به این سؤالات بستگی به این دارد که شرکت کنندگان در حراج چه نتیجه ای را بهینه می کنند . فروشندگان ممکن است بخواهند درآمد تبلیغات وب سایت را به حداکثر برسانند، در این صورت باید با مهلت های زمانی مختلف آزمایش کنند تا تنظیماتی را پیدا کنند که درآمد را به حداکثر می رساند. داشتن بازه های زمانی مختلف برای دسکتاپ و موبایل ممکن است مفید باشد. استفاده از مخاطب محافظت شده ممکن است در طول زمان با افزایش پذیرش تغییر کند، شرکت کنندگان در حراج منطق خود را بهینه کنند یا رایانه ها تکامل پیدا کنند، بنابراین آزمایش مداوم می تواند مفید باشد. اگر خریداران برای برنده شدن در بیشتر حراج‌ها بهینه‌سازی می‌کنند، باید تأخیر سیگنال‌های مناقصه مورد اعتماد خود را نظارت و بهینه‌سازی کنند و تأخیر generateBid() ، و اولویت‌بندی گروه‌های ذینفع خود را در نظر بگیرند تا زمانی که فروشندگان بازه‌های زمانی دقیق تعیین می‌کنند، ابتدا بهترین پیشنهادات خود را تولید کنند.

بعدش چی؟

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

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

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

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

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