گزارش بهترین شیوه ها

ابتدا گزارش های جدید را در UI بسازید

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

پس از ساختن گزارش خود، روی ویژگی "Try this API" در صفحه اسناد مرجع کلیک کنید تا یک queries.get از منبع Query انجام شود. می توانید از JSON برگشتی برای ساخت گزارش های آینده استفاده کنید.

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

برخی از مقادیر متریک و فیلتر مخصوص انواع گزارش خاص هستند. علاوه بر اینکه ابتدا گزارش‌های خود را در رابط کاربری ایجاد می‌کنید ، همچنین می‌توانید معیارها و فیلترهایی را که به مقادیر خاص ReportType تعلق دارند، بر اساس مقدار Bid Manager API شناسایی کنید.

در اینجا چند روش برای شناسایی فیلتر و مقادیر متریک مربوط به Bid Manager API وجود دارد. این جدول فهرست کاملی از فیلترها و معیارهایی نیست که بتوان در این نوع گزارش‌ها استفاده کرد. همه مقادیر را نمی توان با هم در یک گزارش استفاده کرد.

ReportType فیلترها و معیارهای مربوطه
INVENTORY_AVAILABILITY
  • فیلترهایی با پیشوند FILTER_TRUEVIEW_IAR .
YOUTUBE
  • فیلترهایی با پیشوند FILTER_TRUEVIEW ، به استثنای فیلترهایی که پیشوند FILTER_TRUEVIEW_IAR دارند.
  • معیارها با پیشوند METRIC_TRUEVIEW .
GRP
  • معیارهای با پیشوند METRIC_GRP .
YOUTUBE_PROGRAMMATIC_GUARANTEED
  • فیلترهایی با پیشوند FILTER_YOUTUBE_PROGRAMMATIC_GUARANTEED .
  • معیارها با پیشوند METRIC_PROGRAMMATIC_GUARANTEED .
REACH
  • معیارها با پیشوند METRIC_UNIQUE_REACH .
UNIQUE_REACH_AUDIENCE
  • معیارها با پیشوند METRIC_UNIQUE_REACH .

ذخیره و استفاده مجدد از گزارش ها

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

گزارش ها را برنامه ریزی کنید

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

گزارش های مشابه را با هم ترکیب کنید

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

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

سهمیه های گزارش دهی را در نظر بگیرید

استفاده مسئولانه از ویژگی گزارش‌دهی Display & Video 360 از طریق سهمیه‌های استفاده در سطح محصول زیر اعمال می‌شود.

اجرای گزارش موقت در روز

تعداد گزارش‌های موردی را که کاربر می‌تواند در یک دوره 24 ساعته اجرا کند، محدود می‌کند. برای ماندن در این سهمیه:

گزارش های برنامه ریزی شده فعال

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

گزارش های همزمان

تعداد گزارش هایی را که کاربر می تواند به طور همزمان اجرا کند محدود می کند. برای ماندن در این سهمیه:

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

اگر اجرای گزارش خود را بهینه کرده اید و همچنان متوجه می شوید که از سهمیه تعیین شده خود فراتر رفته اید، با استفاده از فرم تماس با پشتیبانی Display & Video 360 تماس بگیرید.

هنگام نظرسنجی برای وضعیت گزارش از عقب نشینی نمایی استفاده کنید

نمی توان پیش بینی کرد که یک گزارش چقدر طول می کشد تا اجرا شود. به عنوان مثال، بسته به عوامل بسیاری از جمله محدوده تاریخ و مقدار داده هایی که باید پردازش شوند، مدت زمان می تواند از ثانیه تا ساعت متغیر باشد. همچنین هیچ ارتباطی بین زمان اجرای گزارش و تعداد ردیف های برگشتی در گزارش وجود ندارد. بنابراین باید مرتباً منبع گزارش را با استفاده از روش queries.reports.get بازیابی کنید و بررسی کنید که آیا قسمت metadata.status.state منبع به DONE یا FAILED به روز شده است یا خیر تا مشخص شود که اجرای آن به پایان رسیده است. این فرآیندی است که به "نظرسنجی" معروف است.

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

عقب نشینی نمایی

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

جریان برای پیاده سازی عقب نشینی نمایی ساده به شرح زیر است:

  1. درخواست queries.reports.get را به API ارسال کنید.
  2. شی گزارش را بازیابی کنید. اگر قسمت metadata.status.state DONE نشد یا FAILED بود، این نشان می‌دهد که اجرای گزارش به پایان نرسیده است، باید نظرسنجی ادامه یابد.
  3. 5 ثانیه + تعداد تصادفی میلی ثانیه صبر کنید و درخواست را دوباره امتحان کنید.
  4. شی گزارش را بازیابی کنید. اگر قسمت metadata.status.state DONE نشد یا FAILED بود، این نشان می‌دهد که اجرای گزارش به پایان نرسیده است، باید نظرسنجی ادامه یابد.
  5. 10 ثانیه + تعداد تصادفی میلی ثانیه صبر کنید و درخواست را دوباره امتحان کنید.
  6. شی گزارش را بازیابی کنید. اگر قسمت metadata.status.state DONE نشد یا FAILED بود، این نشان می‌دهد که اجرای گزارش به پایان نرسیده است، باید نظرسنجی ادامه یابد.
  7. 20 ثانیه + تعداد تصادفی میلی ثانیه صبر کنید و درخواست را دوباره امتحان کنید.
  8. شی گزارش را بازیابی کنید. اگر قسمت metadata.status.state DONE نشد یا FAILED بود، این نشان می‌دهد که اجرای گزارش به پایان نرسیده است، باید نظرسنجی ادامه یابد.
  9. 40 ثانیه + تعداد تصادفی میلی ثانیه صبر کنید و درخواست را دوباره امتحان کنید.
  10. شی گزارش را بازیابی کنید. اگر قسمت metadata.status.state DONE نشد یا FAILED بود، این نشان می‌دهد که اجرای گزارش به پایان نرسیده است، باید نظرسنجی ادامه یابد.
  11. 80 ثانیه + تعداد تصادفی میلی ثانیه صبر کنید و درخواست را دوباره امتحان کنید.
  12. این الگو را تا زمانی که شی گزارش به روز شود یا به حداکثر زمان سپری شده برسد ادامه دهید.

اگر اجرای گزارش به پایان رسید و در حالت DONE به پایان رسید، می توانید فایل گزارش تولید شده را از Google Cloud Storage در مسیری که در قسمت metadata.googleCloudStoragePath داده شده است، بازیابی کنید.