بهینه سازی سهمیه

بهینه سازی سهمیه برای هر برنامه ای که از API Display & Video 360 استفاده می کند ضروری است. بهینه‌سازی استفاده از سهمیه عملکرد را با ساده‌سازی درخواست‌های API بهبود می‌بخشد و به شما کمک می‌کند هنگام تجاوز از محدودیت‌های نرخ تعیین‌شده، از خطاهای برگشتی جلوگیری کنید.

این صفحه بهترین روش‌های عمومی را شرح می‌دهد و ویژگی‌های تکمیلی در Display & Video 360 API را برجسته می‌کند که می‌تواند به کاهش استفاده از سهمیه شما کمک کند.

درخواست‌های همزمان علیه تبلیغ‌کنندگان مختلف داشته باشید

اکثر روش‌ها در Display & Video 360 API یک تبلیغ‌کننده را در URL مشخص می‌کنند. علاوه بر سهمیه کل پروژه ، محدودیت‌های نرخ محدودتر «به ازای هر تبلیغ‌کننده در هر پروژه» برای این روش‌ها هنگام برقراری تماس‌هایی که همان تبلیغ‌کننده را مشخص می‌کنند، اعمال می‌شود.

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

از پارامترهای filter و orderBy استفاده کنید

در هنگام بازیابی منابع متعدد، به جای استفاده از روش های get ، از روش های list استفاده کنید. با این حال، به دلیل محدودیت در اندازه صفحه، تماس های list همچنان می توانند سهمیه زیادی را مصرف کنند. اگر فقط نیاز به بازیابی زیرمجموعه ای از پاسخ لیست کامل دارید، می توانید استفاده از سهمیه را با استفاده از پارامترهای filter اختیاری و orderBy بهینه کنید.

پارامتر filter به شما این امکان را می دهد که منابع بازیابی شده توسط فراخوانی list را به منابعی که ویژگی های آنها مطابق با عبارات داده شده است محدود کنید. این پارامتر هنگام تلاش برای بازیابی مفید است:

  • یک منبع خاص با شناسه ناشناخته اما ویژگی های شناخته شده. اگر به دنبال یک منبع خاص هستید، می توانید لیست برگشتی را با ویژگی های شناخته شده منبع مورد نظر فیلتر کنید. نمونه‌ها شامل فیلتر کردن موارد خط با یک displayName شناخته شده، خلاقیت‌ها بر اساس creativeType مورد انتظار، و منابع موجودی توسط exchange مربوطه است.
  • منابع مرتبط منابع در Display & Video 360 اغلب با یکدیگر مرتبط هستند. می توانید از فیلترها برای محدود کردن منابع برگشتی به منابعی استفاده کنید که رابطه خاصی با دیگری دارند. مثال‌ها شامل بازیابی همه سفارش‌های درج در زیر یک campaignId خاص و همه خلاقیت‌های اختصاص داده شده به یک آیتم خطی است.
  • فقط منابعی که دارای ویژگی های عملی هستند. عملکرد API به شما امکان می دهد به راحتی وضعیت منابع را بررسی کنید و به صورت برنامه ریزی شده واکنش نشان دهید. با استفاده از فیلترها، می‌توانید از فراخوانی‌های list استفاده کنید تا منابعی را فقط در مواردی که نیاز به اقدام لازم است به دست آورید. مثال‌ها عبارتند از بازیابی همه موارد خطی که یک lineItemWarningMessage قابل عمل را نشان می‌دهند، همه سفارش‌های درج که از یک تاریخ معین به‌روزرسانی شده‌اند، یا همه خلاقیت‌هایی که approvalStatus ناموفق دارند.

پارامتر orderBy به شما امکان می دهد منابع بازیابی شده را بر اساس ویژگی های خاص مرتب کنید، صعودی یا نزولی. orderBy ، به‌ویژه زمانی که در کنار filter استفاده می‌شود، می‌تواند برای محدود کردن تعداد صفحاتی که قبل از یافتن یک منبع خاص باید طی شوند، استفاده کرد. همچنین به شما این امکان را می دهد که به راحتی مرزهای بالا و پایین لیست منابع را بدست آورید. برای مثال، سفارش‌گذاری براساس updateTime به شما این امکان را می‌دهد که به‌سرعت جدیدترین موارد خطی یا سفارش‌های درج آگهی‌دهنده را پیدا کنید.

از توابع حجیم و گسترده استفاده کنید

Display & Video 360 API تعدادی عملکرد انبوه و گسترده را ارائه می دهد که اقدامات متعددی را با یک درخواست انجام می دهد. نمونه هایی از این نوع توابع عبارتند از:

  • سایت های ویرایش انبوه متعلق به یک کانال . کانال ها می توانند هزاران سایت را به آنها اختصاص دهند. به‌جای مدیریت فهرست سایت یک کانال با درخواست‌های create یا delete جداگانه، می‌توانید از یک درخواست bulkEdit یا replace برای افزودن و حذف سایت‌های متعدد یا جایگزینی کل محتوای یک کانال استفاده کنید.
  • مدیریت کل مجموعه هدف یک تبلیغ‌کننده. مجموعه هدف یک منبع در چندین نوع هدف قرار می گیرد. توابع هدف‌یابی در سطح منبع، مانند listAssignedTargetingOptions و editAssignedTargetingOptions در سرویس advertisers ، به شما امکان می‌دهند تا در یک درخواست، هدف‌گیری را در چندین نوع هدف بازیابی، ایجاد و حذف کنید. این هزینه سهمیه تنظیم مجموعه هدف آگهی دهنده را به یک درخواست کاهش می دهد.
  • تنظیم محدودیت هدف گذاری یکسان در چندین مورد خط. اگر نیاز دارید که تغییرات هدف گذاری یکسانی را در چندین مورد خط به طور همزمان ایجاد کنید، این کار را می توان با استفاده از یک درخواست advertisers.lineItems.bulkEditAssignedTargetingOptions انجام داد.
  • فعال کردن یا توقف چند مورد خط. موارد خط باید پس از ایجاد قبل از شروع خدمت فعال شوند. اگر چندین مورد خط را پشت سر هم ایجاد می کنید، می توانید همه آنها را با یک درخواست advertisers.lineItems.bulkUpdate فعال کنید. از همین روش می‌توان برای توقف موقت چندین آیتم خط استفاده کرد تا از ارائه آنها جلوگیری شود.

شناسه هایی که به طور مرتب استفاده می شوند را کش و بررسی کنید

بسیاری از عملیات در Display & Video 360 API به استفاده از شناسه‌های منبعی نیاز دارند که از طریق خود API بازیابی می‌شوند، از جمله شناسه‌های گزینه هدف ، شناسه‌های مخاطب Google و موارد دیگر. به منظور جلوگیری از بازیابی شناسه ها از API در هر بار استفاده، توصیه می کنیم این شناسه ها را به صورت محلی ذخیره کنید.

با این حال، برخی از منابع را می توان منسوخ کرد، حذف کرد، یا در موارد دیگر برای استفاده از دسترس خارج شد. تلاش برای استفاده از شناسه‌های این منابع ممکن است با خطا مواجه شود. بنابراین، توصیه می کنیم همه شناسه های کش شده را به صورت هفتگی با استفاده از روش get یا list فیلتر شده مناسب بررسی کنید تا مطمئن شوید که هنوز قابل بازیابی است و وضعیت مورد انتظار را دارد.

پیاده سازی عقب نشینی نمایی برای عملیات طولانی مدت

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

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

می توانید استراتژی عقب نشینی نمایی اجرا شده با کتابخانه های مشتری را در نمونه های کد دانلود SDF ما بیابید. جریان گام به گام برای پیاده سازی عقب نشینی نمایی ساده به شرح زیر است:

  • یک درخواست sdfdownloadtasks.operations.get به API ارسال کنید.
  • شی عملیات را بازیابی کنید.
    • اگر فیلد done درست نباشد، نشان می دهد که باید درخواست را دوباره امتحان کنید.
    • 5 ثانیه + تعداد تصادفی میلی ثانیه صبر کنید و درخواست را دوباره امتحان کنید.
  • شی عملیات را بازیابی کنید.
    • اگر فیلد done درست نباشد، نشان می دهد که باید درخواست را دوباره امتحان کنید.
    • 10 ثانیه + تعداد تصادفی میلی ثانیه صبر کنید و درخواست را دوباره امتحان کنید.
  • شی عملیات را بازیابی کنید.
    • اگر فیلد done درست نباشد، نشان می دهد که باید درخواست را دوباره امتحان کنید.
    • 20 ثانیه + تعداد تصادفی میلی ثانیه صبر کنید و درخواست را دوباره امتحان کنید.
  • شی عملیات را بازیابی کنید.
    • اگر فیلد done درست نباشد، نشان می دهد که باید درخواست را دوباره امتحان کنید.
    • 40 ثانیه + تعداد تصادفی میلی ثانیه صبر کنید و درخواست را دوباره امتحان کنید.
  • شی عملیات را بازیابی کنید.
    • اگر فیلد done درست نباشد، نشان می دهد که باید درخواست را دوباره امتحان کنید.
    • 80 ثانیه + تعداد تصادفی میلی ثانیه صبر کنید و درخواست را دوباره امتحان کنید.
  • این الگو را تا زمانی که شی پرس و جو به روز شود یا به حداکثر زمان سپری شده برسد ادامه دهید.